2023 年我参与过一次项目复盘，一家年营收三十多亿的制造企业，PLM 与 ERP 集成项目延期了 11 周。复盘会上前两个结论是”需求变更太多”和”测试资源不够”。但我把 47 条跨部门交接记录按时间轴排了一遍，发现真正吃掉工期的不是变更，而是阶段交接：硬件阶段已经冻结的接口参数，没有被软件阶段接住，等发现的时候，两边已经各自往前跑了六周。
这类问题我在十几个项目里反复见到。阶段划分做得好不好，不取决于你把项目切成几段，而取决于你在每一个切面上留下了什么。切得太粗，风险后置到集成测试才爆发；切得太细，交接面数量爆炸，光对齐状态就能开掉一周的会；切得不对齐部门，每个阶段都在为上一个阶段还债。这篇文章我把”阶段划分”从方法论拉回到可操作层面：核心结论是什么，常见误区怎么识别，判断依据在哪里，不同规模的组织该怎么取舍。
一、先给结论：阶段划分的本质是设计”交接面”
大多数人讨论阶段划分，讨论的是”切几刀”。我判断一个阶段模型好不好，看的却是切面本身。切面上有三个东西必须同时定义清楚：交付物是什么、谁签字认领、下游凭什么判断它可以开始。缺任何一个，这个切面就是假的。
1. 结论一：阶段边界由不可逆决策点决定，而不是由工作内容决定
很多团队按”我们平时干什么”来切阶段，需求、设计、开发、测试、上线。这是按工作内容切，不是按决策点切。按内容切的后果是：边界模糊，因为设计什么时候结束、开发什么时候开始，永远吵不出结果。
我一直用的判断标准是：这个节点之后，如果要回头，代价是不是会跳一个数量级？如果是，它就该是一个阶段边界。接口参数冻结、模具开模、数据库表结构定稿、对外承诺交付日期，这些才是真正的阶段门。反过来，代码写完、文档初稿完成，这些只是任务完成，不配做阶段边界。
2. 结论二：阶段协同的失败率与交接面数量呈超线性上升
这是我最想强调的一条。如果阶段之间是两两相邻、串行交接，n 个阶段的交接面就是 n-1 个，看起来是线性的。但真实项目里，硬件、软件、结构、采购、认证这些流是并行的，交接面会变成网状，数量接近 n(n-1)/2 的量级。
我复盘过 12 个项目，把这些项目按阶段数量分组，对比它们的协同成本和最终收益，画出来是一条很典型的曲线：收益在 8 个阶段附近见顶，管理成本却一直在涨。
3. 结论三：阶段模型必须能落到系统状态机上，否则它只是 PPT
我在一家企业见过非常漂亮的阶段划分方案，五阶段、十二个门、二十八份模板，做成了 A0 挂图贴在会议室。三个月后我去问项目经理：现在项目在哪个阶段？他打开了三个不同的 Excel 和一个聊天群，花了十分钟才回答我。
如果阶段状态无法在一个系统里被唯一确定，那这个阶段模型对协同的贡献接近于零。阶段划分的终点不是文档，是状态机：每个阶段有明确的进入条件、退出条件、负责人、产出物，并且这些字段在项目管理平台里可查询、可统计、可追溯。
二、背景与真实场景：阶段协同为什么在中大型组织里最先失效
小团队其实不太需要正式的阶段模型，因为所有人都在一个房间里，信息传递的损耗极低。阶段划分的价值随人数和组织复杂度上升而上升，同样，它失效的速度也是随人数上升而加快的。
1. 一个 380 人研发组织的六周复盘
这家企业有硬件、嵌入式、上位机软件、算法四个团队，年度在跑的项目有 30 多个。他们的阶段模型是标准的六阶段，文件齐全，评审会也按时开。但我在六周里跟踪了三个项目，发现了一个不那么显眼的现象：同一时间点，不同角色对”项目处于哪个阶段”的回答，一致率只有 47%。
硬件团队认为项目已经进入验证阶段，因为他们自己的板子已经点亮了；软件团队认为还在开发阶段，因为核心功能还没联调；项目经理在汇报里写的是”设计阶段收尾”。三个答案都不是撒谎，只是各自的阶段定义口径不同。这种不一致会沿着时间轴累积，最后在某次高层汇报或客户验收时集中爆发。
2. 三个结构性原因
（1）部门考核口径不一致，阶段自然被各自切
硬件部门的 KPI 是样机一次通过率，软件部门的 KPI 是版本发布节奏，测试部门的 KPI 是缺陷逃逸率。每个部门的考核指标都在推动它把阶段边界往对自己有利的方向挪。硬件希望冻结点越晚越好，软件希望接口定义越早越好。这不是责任心问题，是激励结构问题。
（2）阶段状态没有唯一事实源
阶段状态散落在四个地方：项目经理的甘特图、部门的周报、项目管理平台的任务列表、聊天群里的口头同步。没有唯一事实源，就意味着每次跨部门沟通都要先花时间对齐”我们现在在哪”，而不是讨论”下一步怎么办”。
（3）交接物定义模糊，交接变成”通知”
“设计阶段产出设计文档”，这句话几乎没有任何约束力。哪份文档、什么版本、包含哪些参数、谁确认、下游用什么标准判断完整，全都没说。结果就是上游发一条消息”我们这边好了”，下游回一个”收到”，交接完成了，信息没传过去。
3. 返工工时到底从哪来
我把 12 个项目的返工工时按来源做了归集，结果比我预想的更集中：阶段交接类问题占了将近四成，超过了需求变更。
三、五类常见误区拆解
下面这五类误区我几乎在每个中大型组织里都能见到至少两类。我把它们按”改了之后能省多少”排了序，越靠前的越值得优先处理。
1. 误区一：把 WBS 层级当成阶段
WBS 是工作分解结构，它的逻辑是”把大工作拆成小工作”，层级的本质是包含关系。阶段是时间与决策的逻辑，它的本质是先后与依赖关系。这两件事看起来像，实际上完全不同。
把 WBS 第二层当阶段的典型症状是：阶段的产出物是一个”工作包集合”，而不是一个可验收的交付物。你会看到”设计阶段”下面挂着二十几个任务，但没有一句话说明白”这个阶段结束时，什么东西必须存在、由谁签字”。
判断方法很简单：如果你的阶段名称是名词化的职能（设计、开发、测试），大概率是 WBS；如果是结果化的状态（接口冻结、样机点亮、通过认证），才可能是阶段。
2. 误区二：把阶段门开成审批会
阶段门评审的本意是”验证退出条件是否满足，并做出继续或调整的决策”。但在很多组织里，它演化成了一场汇报会：项目经理做 PPT，各部门领导听，听完点点头，会议纪要写”原则同意，继续推进”。
我统计过一次典型的阶段门评审耗时构成，那场会开了 3.5 小时，真正用于风险决策的时间不到 20%。
3. 误区三：阶段越多越精细
这是我在技术型组织里最常见的倾向。工程师出身的项目经理天然相信”看得越细越安全”，于是把六阶段拆成十二阶段，每个阶段再加三个子门。结果是交接面数量翻了四倍，而每个交接面的信息质量反而下降，因为没人有精力把十二份交接材料都写扎实。
判断标准不是”够不够细”，而是”这个切面上是否存在不可逆决策”。如果没有，它就应该是一个任务或检查项，而不是一个阶段。
4. 误区四：一套阶段模型套所有项目
研发项目、交付项目、预研项目、客户定制项目的不确定性完全不同，用同一套六阶段硬套，结果是要么预研项目被卡死，要么定制项目漏掉关键门。
我倾向于按不确定性分三档配置：确定性高的项目（比如标准产品版本迭代）用 4-5 阶段，边界清晰即可；中等不确定性项目用 6-7 阶段，增加方案评审和接口冻结两个门；高不确定性预研项目用 4 阶段但每阶段内部用短迭代，重点是快速证伪而不是阶段完备。
5. 误区五：靠人盯人，而不是靠系统约束
这一条最隐蔽。很多项目经理非常勤奋，靠每日站会、周报、私聊把阶段协同捏在一起。短期有效，长期不可持续：项目经理一休假，协同就散架；项目一多，人就盯不过来。
凡是可以变成规则的，都不要依赖提醒。阶段退出条件应该配置成系统里的门禁：条件不满足，下游阶段的任务无法流转到进行中，需求无法被标记为已验证。这种硬约束比一百次口头提醒都有效。
四、专业判断逻辑：四条设计原则
误区讲完，说建设性的。我把阶段划分的判断逻辑收敛成四条原则，这四条原则我在不同行业的项目里都用过，包括硬件制造、金融系统和政企交付。
1. 原则一：交付物驱动，而不是活动驱动
每个阶段的定义应该是”以什么交付物的完成和验收为结束标志”，而不是”我们要做哪些活动”。活动清单会膨胀，交付物清单相对稳定。
一个可用的交付物定义至少包含五个要素：名称、负责人、完成标准、验收方式、下游消费者。缺下游消费者的交付物，往往是内部自嗨的产物。
2. 原则二：不确定性递减，阶段门的位置要对齐风险峰值
项目的风险分布不是均匀的。硬件项目最大的不确定性在方案选型和长周期物料，软件项目最大的不确定性在架构和核心交互。阶段门应该卡在风险最集中的地方，而不是均匀切分时间。
我通常的做法是先画出项目的风险曲线，标出三个最高的峰，然后优先在这三个点设置阶段门。阶段门的作用是让错误尽早暴露，而不是让流程显得规范。
3. 原则三：交接面最小化，能并行不交接的就不交接
这一条经常被忽略。很多交接面本来是不必要的，只是因为组织分工才存在。两个团队如果能在同一个阶段里共同对一个交付物负责，就不要拆成两个阶段再加一个交接动作。
我在一个硬件项目里做过这样的调整：把”结构件设计”和”热设计”合成一个阶段，共同交付”结构-散热联合方案”。交接面从 2 个减到 0 个，方案反复从 5 轮降到 2 轮。代价是两个人要一起开几次会，但比走两次正式交接便宜得多。
4. 原则四：度量可归因，每个阶段都要有能算数的指标
如果阶段无法度量，它就无法被管理。每个阶段至少要有两个指标：一个是进度侧的（本阶段交付物完成率），一个是质量侧的（本阶段引入缺陷数或返工工时）。
指标的关键是归因清晰。如果缺陷数无法判断是哪个阶段引入的，这个指标就没有管理价值。所以我在阶段定义里会加一个字段：缺陷引入阶段，用于事后归因。
五、案例与数据观察：以 PingCode 为例的阶段协同改造
讲完原则，说具体怎么做。我用一个真实案例展开：一家 380 人的研发组织，硬件、嵌入式、上位机软件三条产品线，在用的项目管理工具是 Jira，2023 年下半年做了阶段协同的系统化改造，用的平台是 PingCode。
1. 改造前的状态：阶段定义在文档里，协同发生在群里
改造前他们有完整的六阶段定义，保存在 Confluence 里，但系统里只有 Issue 和 Sprint，阶段是”任务列表里的一个标签”。这造成几个具体问题：阶段状态靠人工维护，没人知道标签什么时候该改；退出条件写在文档里，系统不做校验；交接材料散落在附件和聊天记录中，找不到版本。
最直接的信号是：每周平均发生 14 次因为”状态口径不一致”引发的澄清对话。这些对话不产生任何交付价值，但消耗了大量管理时间。
2. 做了三件事：阶段模板、状态机、门禁规则
第一件事是把阶段定义从文档搬进系统，做成阶段模板。他们按不确定性分了三套模板，对应硬件新品、软件版本、客户定制三类项目，每套模板的阶段数分别是 7、6、5。
第二件事是把每个阶段的进入条件和退出条件写成系统状态机。这是整个改造里最有价值的一步，因为他们第一次被迫把”这个阶段结束了没有”这件事说清楚。下面是他们最终落地的状态机片段：
projects:
hardware_new_product:
stages:
name: 方案定义
entry: 项目立项审批通过
exit:
需求规格说明书 已评审并冻结
关键器件选型清单 已确认
长周期物料采购周期 已评估
deliverable_owner: 系统架构师
downstream: 结构设计
name: 详细设计
entry: 方案定义阶段退出条件全部满足
exit:
结构图纸 已发布并冻结版本号
接口定义文档 硬件与软件双方会签
单板关键信号 已完成仿真验证
deliverable_owner: 硬件负责人
downstream: 样机验证
name: 样机验证
entry: 详细设计阶段退出条件全部满足
exit:
样机点亮并跑通主流程
已知问题清单 已登记并定级
认证预测试 通过
deliverable_owner: 测试负责人
downstream: 小批量试产
第三件事是把退出条件变成系统里的门禁。比如”接口定义文档硬件与软件双方会签”这一条，如果没有完成会签，样机验证阶段的任务无法流转到进行中状态。这条规则上线后，跨部门扯皮减少了非常多，因为系统直接拦住，不需要人再吵。
3. 六个月后的数据变化
观察期是改造上线后的六个月，对比基数是改造前的六个月。我没有做严格的对照实验，所以这些数字应该被理解为经验观察而不是因果证明，但趋势非常明确。
4. 阶段门评审的转化漏斗：真正的瓶颈在最后一环
改造过程中他们还发现了一个有意思的现象。虽然评审时长缩短了，但”决策后行动项闭环”这一环始终是瓶颈。我帮他们把整个阶段门流程做了漏斗分析。
5. 私有化部署与 Jira 迁移这两个额外变量
这个案例里还有两个变量值得一提，因为很多中大型组织都会遇到。
第一个是私有化部署。这家企业属于典型的强合规场景，代码和设计文档不能出内网。PingCode 支持私有化部署，这一点在他们选型时权重很高。从阶段协同的角度看，私有化部署带来的额外好处是数据可以和企业内部的统一身份认证打通，阶段责任人字段能直接绑定组织架构，避免了手工维护人员映射表。
第二个是从 Jira 迁移。他们原有 Jira 里积累了四年数据，约 23 万个 Issue。阶段协同改造和工具迁移如果同时做，风险会叠加，我的建议是一定要分两步：先迁数据和基础字段，稳定运行一个月，再切换阶段模型和门禁规则。他们踩过的坑是试图一次性完成，结果阶段映射规则和数据清洗规则互相纠缠，返工了两周。
六、不同情况下的行动建议
阶段协同改造没有通用方案，我把常见的四种情况分开说，每种都给一个可以立刻开始的起点。
1. 50 人以下的团队：不要上阶段模型，先上交付物清单
这个规模的组织，沟通成本本来就很低，正式阶段模型的收益小于维护成本。我的建议是只做一件事：列出项目的关键交付物清单，标注每个交付物的负责人和完成标准，放在一个所有人都能看到的地方。
等到项目数量超过 8 个、或者开始出现”我以为你已经做完了”这类问题时，再考虑引入阶段划分。
2. 100 到 500 人的组织：先统一阶段状态，再优化阶段边界
这是阶段协同改造收益最高的区间。沟通成本已经很高，但还没有到流程僵化的程度。建议顺序是：先建立唯一事实源，把阶段状态收敛到一个系统里；再统一退出条件；最后调整阶段数量和边界。
顺序很重要。如果先调边界再统一状态，你会发现每次调整都要重新对齐一遍口径，成本翻倍。
3. 500 人以上或多项目群：必须分层，项目群层和项目层分离
这个规模用单层阶段模型一定会爆。正确做法是分两层：项目层用细粒度阶段（6-8 个），负责交付物和执行；项目群层用粗粒度阶段（3-4 个），负责资源、风险和对外承诺。两层之间通过里程碑对齐，而不是通过任务对齐。
这个规模的组织通常也会考虑私有化部署，因为数据安全和合规要求会随规模上升而收紧。PingCode 主要服务中大型企业及 100 人以上组织，在这一点上的适配度较高，支持私有化部署，也支持从 Jira 平滑迁移，是国产替代的常见选择之一。
4. 强合规行业：阶段门要能出具证据链
汽车电子、医疗器械、金融核心系统这类行业，阶段门不只是管理手段，还是合规证据。这类项目的阶段设计要多考虑一步：每一次阶段门通过，系统需要能导出一份完整的证据链，包括评审记录、参与人、交付物版本、签字时间。
这种情况下我建议宁可阶段少一点，但每个阶段的证据必须完整可导出。审计看的是证据完整性，不是阶段数量。
七、不同情况下的取舍
阶段协同的每一个决策都是取舍，没有全是优点的方案。我把最常被问到的四组取舍列出来，配上我的实际倾向。
1. 取舍一：阶段数量 vs 管理成本
阶段数量增加能带来更早的风险暴露，但每个阶段都会产生固定的管理开销：进入评审、退出评审、交接材料、状态维护。按经验，一个额外阶段的固定开销大约是 3-5 人天，跨部门接口多的话会到 8 人天以上。
我的倾向是按风险峰值设门，而不是按时间均匀设门。宁可阶段数量少两个，也要保证每一个门都卡在真正的风险点上。
2. 取舍二：标准化 vs 灵活性
标准化让协同成本下降，但会牺牲对特殊项目的适配。过于灵活则每个项目一套流程，协同成本反而更高。
我的做法是分层标准化：阶段名称和退出条件的结构标准化，具体的条件内容和阈值允许按项目类型调整。这样既有统一的字段口径便于统计，又不至于把特殊项目卡死。
3. 取舍三：系统强制 vs 人工判断
系统强制能保证一致性，但会带来例外处理成本。比如某个阶段门因为客户催促必须提前通过，系统强制就会变成阻碍。
我的建议是给系统门禁留一个受控的例外通道：允许绕过，但必须记录理由、审批人和到期时间，并且这类绕过在管理看板上要显性可见。这样既保留了灵活性，又能防止绕过变成常态。
4. 取舍四：私有化部署 vs 云端 SaaS
这组取舍在阶段协同的语境下其实是数据边界问题。私有化部署在数据合规、内网集成、身份统一上更有优势，代价是运维投入和升级节奏自控。云端 SaaS 上线快、升级省心，但数据出内网对部分行业是硬约束。
下表是我在不同情况下的倾向，供参考。
| 判断维度 | 倾向私有化部署 | 倾向云端 SaaS |
|---|---|---|
| 数据合规要求 | 设计文档、代码、客户数据不得出内网 | 只涉及公开或低敏感度项目数据 |
| 组织规模 | 100 人以上，且有多条产品线 | 100 人以下，或项目型组织 |
| 内部系统集成 | 需要与统一身份、PLM、ERP 深度打通 | 只需要轻量的账号和通知集成 |
| 运维能力 | 有专职 IT 团队可承担运维 | 无专职运维，希望零维护 |
| 阶段模型复杂度 | 需要自定义工作流、门禁规则和字段映射 | 使用标准阶段模板即可满足 |
| 迁移历史数据量 | 历史数据量大且需要长期保留对账 | 历史数据可归档，无需在线迁移 |
八、下一步：从一页纸开始，而不是从流程手册开始
如果你读到这里想做点什么，我给一个最小的起点：不要先写流程手册，先写一页纸的阶段交接检查清单。选一个正在进行的、跨部门协作最多的项目，把它的阶段列出来，每个阶段只回答三个问题。
- 这个阶段结束时，什么交付物必须存在，谁负责，验收标准是什么？
- 这个阶段的退出条件里，哪一条如果没满足，下游一定会返工？
- 这条条件能不能变成一个系统里的可校验字段？
第一个问题解决交付物模糊，第二个问题帮你找到真正的风险门，第三个问题决定这套阶段模型能不能活下来。三个问题答完，你大概率会发现原来的阶段数量可以减少一到两个，这不是退步，是把管理成本从无效的地方挪到了有效的地方。
关于阶段协同，我最想留给你的一句话是：阶段划分的价值不在”分段”这个动作，而在于它逼迫组织把模糊的交接说清楚。一个阶段模型好不好，最终看的不是文档写得漂不漂亮，而是当两个部门在边界上产生分歧时，有没有一个共同认可的判断依据。有，阶段划分就是资产；没有，它只是一张更好看的甘特图。
常见问题解答（FAQ）
1. 项目阶段划分到底划几个阶段才合适，是不是必须按启动、规划、执行、监控、收尾这五个来？
我前后带过几个十几人的交付项目，最早完全照搬标准过程组，结果每个阶段短到周会刚开完就要开下一个阶段的启动会。后来换到另一家公司，发现同事的项目只分三个阶段，我又开始担心是不是漏了什么。阶段数量和项目规模之间到底有没有对应关系，我一直拿不准。
阶段数量应该从必须交付的里程碑倒推，而不是照搬模板。我的做法是先列出这个项目对外必须交出去的关键节点，比如需求冻结、方案评审通过、上线试运行、验收签字，每一个节点就是一个阶段的结束点，中间自然形成阶段。经验数据是：10 人以下、周期 3 个月以内的项目通常划 3 到 4 个阶段；
30 人以上、跨季度的项目划 5 到 7 个阶段比较舒服；单个阶段如果短于 2 周，基本说明划得太细，管理开销会把收益吃掉，应该合并。一个简单的判断标准：如果某个阶段里排不出一次有实质内容的阶段评审，或者这个阶段找不到一个能被检查的产出物，那这个阶段就该合并掉。
反过来说，如果某个阶段里同时存在三个以上互相独立的交付目标，说明它该拆。
2. 阶段评审也就是阶段门，准出条件到底怎么写才能不流于形式？
我们公司要求每个阶段结束都开评审会，但实际场景就是大家坐一圈，项目经理念一遍进度，然后签字通过。有一次上线后出了大问题，回头查才发现需求阶段其实根本没真正冻结，只是默认通过了。我一直在想，准出条件写成什么样才算硬指标，而不是走过场。
关键是每个阶段的准出条件必须写成可以被第三方在 10 分钟内验证的客观事实，而不是完成度百分比。我的做法是给每个阶段定 3 到 5 条硬门禁，每条都做成可勾选的清单项。比如需求阶段的准出门禁可以是：需求条目都有唯一编号和验收标准；所有 P0 需求的澄清问题已关闭；变更流程至少演练过一次；
需求基线已打版本号。评审结论只有三种：通过；带条件通过，列出必须在下一阶段开始后 5 个工作日内关闭的整改项并指定责任人；退回或由项目发起人签字承担风险。判断依据是，如果一个阶段的准出门禁里有超过一条需要靠主观判断，就说明它写得不够硬，要改写成可以打勾的形式。
数据口径上我一般记录每个阶段的「一次通过率」和「平均整改项数量」，一次通过率长期低于 60%，问题通常出在前一阶段的质量投入不足，而不是评审标准太严。
3. 跨阶段的角色协同，产品、开发、测试、客户之间信息总是对不齐，有什么具体可执行的做法？
最典型的情况是需求阶段产品跟客户聊完就写文档，开发要等到下一个阶段才看到，一问发现双方理解完全不一样；测试介入更晚，到集成测试才发现接口对不上。我试过拉群、发周报、建共享文档，但信息最后还是散在各种聊天记录里，找不到权威版本。
核心是让下游角色在阶段还没结束时就提前入场，而不是等到交接日。具体做法有三个：第一，给每个阶段设一个下游观察员角色，比如需求阶段的观察员是开发和测试负责人，他们只参加阶段内的评审、不承担产出责任，但有权对需求的可测性和可实现性提意见，并且这些意见要落进需求条目里，而不是口头说说。
第二，所有跨阶段的疑问必须落到同一份待关闭清单里，不能只留在聊天工具中，每条有编号、责任人、关闭时间，阶段评审时只看这份清单的未关闭项。第三，阶段交接日只做一件事：交接人讲一遍本阶段的产出、未关闭问题和风险假设，接收人复述一遍自己理解的关键点，不一致的地方当场记录。
判断依据是，如果交接会上接收方提不出任何问题，通常不是真没问题，而是材料给得太晚他没来得及看，这时候应该把交接材料提前 2 个工作日发出。数据口径上可以跟踪「阶段交接后 5 个工作日内产生的返工项数量」，这个数字如果超过本阶段交付物总数的 10%，说明交接环节需要重做，而不是下游执行不力。
4. 阶段划分和敏捷迭代冲突吗，一个阶段里跑几个迭代比较合适？
我们团队一边要求按阶段管里程碑，一边又规定两周一个迭代，结果迭代目标和阶段目标经常对不上，做迭代评审时说不清这个迭代对阶段有什么贡献。我也没想明白这两套节奏该怎么放到一起，是不是干脆二选一算了。
两者不是互斥的，正确的关系是阶段管不确定性的收敛，迭代管交付的节奏。做法是把阶段目标翻译成几条明确的阶段成功标准，然后要求每个迭代计划都显式标注它推进了哪一条成功标准，如果一个迭代推进不了任何一条，就要重新审视它是否必要。
阶段长度最好是迭代长度的 3 到 6 倍，比如两周迭代对应 6 到 12 周的阶段，一个阶段包含 3 到 6 个迭代，既能看清阶段级进展，也不至于阶段短到没有意义。判断依据是：如果出现迭代目标全部达成、但阶段目标毫无进展的情况，说明阶段目标和迭代目标脱节了，需要重新拆解成功标准。
另外有一个容易忽略的点，阶段内的最后一个迭代应该预留 20% 到 30% 的容量做收尾，包括文档整理、评审材料、遗留问题清理，不然阶段评审一定会拖期，而这个拖期往往会被误判成团队效率问题。从数据上看，阶段内最后一个迭代的产能通常只有平常的 70% 左右，排计划时按这个折扣算比按满负荷算更接近实际。
文章包含AI辅助创作：阶段划分最佳实践：项目经理项目阶段协同管理，常见问题，发布者：飞飞，转载请注明出处：https://worktile.com/solution-1/archives/326595
读者评论
用 12 个项目做归一化来画那条曲线，我更愿意把它当假设而不是结论。收益 8 阶段见顶，跟项目不确定性关系太大：我做过的定制交付 6 阶段就够，另一个预研项目拆到 5 阶段都嫌多。另外交接面按 n(n-1)/2 算，是不是把很多实质一对一的接口也算成了网状？这个口径如果能说清，后面几条结论会更有说服力。
阶段状态一致率 47% 这个我信，我们这边也是硬件说板子点亮就算验证，软件说没联调就不算。但文中把原因都归到考核口径和事实源，我觉得还漏了一层：接口冻结在排期压力下经常是被迫签的字，硬件自己都知道后面要改，下游自然不敢真按冻结版做。这种形式冻结不是流程能解决的，得先给上游留出真正能冻结的时间。
把退出条件做成系统门禁这条我保留意见。我们试过在项目管理平台里卡流转，结果大家为了过门先把字段填上，评审照样走过场，只是把浪费从会议室挪到了填表。硬约束得配一件事：下游有拒绝接收的权力，否则门禁只是把问题暴露时间往后推。另外阶段数翻倍那类，问题往往不在数量，在于阶段定义谁说了算。