阶段划分管理方法大全：项目成员项目阶段效率提升落地清单

我带过一个 130 人的研发组织做阶段治理诊断，把近 18 个月的 42 个版本拉出来，按“阶段计划完成时间”和“阶段实际通过时间”做差值。结果中位数偏差 9.4 天，而其中 6.8 天并不在任何人的任务清单里，它们消耗在阶段与阶段之间的等待、返工、信息补齐，以及“以为对方会做”的灰色地带。真正拖垮项目阶段效率的，从来不是某个阶段内部干得慢，而是阶段之间的交接面没人管。这篇文章不讲教科书上的阶段定义，只讲我在中大型团队里反复验证过的阶段划分方法、判断逻辑和一份可以直接拿去用的落地清单。

一、核心结论：阶段划分管理的对象是交接面，不是时间轴

大多数团队把“阶段划分”理解成把一根时间轴切成几段，然后给每段起个名字、排个日期、挂个负责人。这个理解在 10 人以下团队基本够用，一旦组织规模超过 50 人、并行项目超过 3 个，它就会立刻失效。

我的核心结论是：阶段划分的第一价值不是排期，而是定义清楚“谁在什么条件下把什么东西交给谁”。阶段内部的效率由个体能力和任务清晰度决定，阶段之间的效率只能由接口定义决定。前者你只能优化，后者你可以设计。

1. 三个可以直接拿去用的判断

判断一：如果你们的阶段延误总是集中在某两三个阶段的边界上，问题不在执行力，而在阶段定义本身。这是我诊断过 20 多个团队后最稳定的一条规律，边界型延误占比超过 40% 的团队，几乎都犯了同一类错误。

判断二：阶段数量的合理区间大概是 4 到 7 个。少于 4 个，颗粒度太粗，风险暴露太晚；多于 7 个，管理开销会吃掉并行收益。我见过一个 300 人组织把研发流程切成 14 个阶段，结果专职做阶段协调的人就有 5 个。

判断三：阶段是否划分正确，唯一的检验标准是“阶段验收时能不能拿出一个可被第三方验证的交付物”。拿不出来，这个阶段就是虚的，它只是给甘特图增加了一行。

2. 阶段效率的三层结构

我把阶段效率拆成三层：阶段内执行效率、阶段间交接效率、阶段间返工效率。绝大多数提效工具和培训都在优化第一层，而中大型组织真正的损耗在第二层和第三层。

一个粗略的经验数值：在 100 到 500 人的组织中，这三层的损耗比例大约是 3:4:3。也就是说，你花了 100 分的精力去优化执行效率，可能只影响了 30 分的问题。

二、背景与真实场景：阶段效率问题为什么总在同一个地方复发

我先描述一个具体的场景，它是我在过去几年里见过最多的形态。某 SaaS 产品线，研发 120 人，分成 4 个特性小组加 1 个平台组，用两周一迭代、每季度一个大版本的节奏。季度初的计划会上，产品、研发、测试、运维四方的阶段计划排得很漂亮，每段都有起止日期和负责人。

1. 一个 120 人团队的真实损耗路径

第 3 周，需求阶段“基本完成”，但产品经理手上还有 7 个需求没有写验收标准，因为他在等业务方确认口径。研发按惯例先开工，把这 7 个需求按自己的理解做了。

第 6 周，开发阶段进入尾声，测试发现其中 4 个需求的实现和业务预期不一致，需要返工。返工的工作量没有被登记，因为它被“塞进了”开发阶段剩余的时间里。

第 9 周，测试阶段开始，环境不稳定，运维说环境变更没有收到正式通知。等待环境修复花了 4 天，这 4 天在甘特图上被记为“测试阶段正常进行”。

第 12 周，版本发布，复盘会上大家的结论是“这个季度执行力不够”。没有人提交接面的事。

这个案例里，真正的问题有三个：需求阶段的退出条件没有包含验收标准；开发阶段没有设置返工池；测试阶段的入口依赖（环境就绪）没有作为前置条件被显式声明。三个问题都不在任何一个阶段的内部，全部在边界上。

2. 中大型组织的三个结构性难点

第一，职能墙。产品、研发、测试、运维各自有考核口径，阶段对每个人意味着不同的东西。研发关心的是“我的编码任务是否关闭”，测试关心的是“用例是否执行完”，管理者关心的是“里程碑是否达成”。三个口径如果不统一到交付物上，阶段就只是各说各话。

第二，并行度。100 人以上的组织几乎不可能单线推进，一个成员同时处在 2 到 4 个项目的不同阶段里。这时候“阶段”对个人来说不再是时间概念，而是上下文切换的成本单位。我在一次抽样里看到，同时挂 3 个项目的成员，其有效专注时间比挂 1 个项目的成员低约 34%。

第三，信息衰减。一个决定从产品负责人传到具体执行者，经过 4 层传递后，关键约束条件的保留率会明显下降。这不是态度问题，是结构问题，只能靠显式的阶段文档和验收条件来对抗。

三、拆解常见误区：五个让阶段管理空转的坑

下面五个误区我都亲自踩过，或者在与团队复盘时反复见到。它们的共同特点是，看起来都在做阶段管理，实际上没有解决任何交接问题。

1. 误区一：阶段越细越好，切得越碎越可控

我曾经推动一个平台团队把“开发”拆成“方案设计、接口定义、编码、自测、代码评审、联调”六个阶段，想法是让风险更早暴露。三个月后的数据是：阶段数从 5 个变成 10 个，阶段平均时长从 12 天降到 6 天，但整体交付周期反而拉长了 11%。

原因是每个阶段都要走一遍状态流转、填写产出物、开一次小验收。当阶段时长降到 6 天以下时，阶段管理本身的开销开始大于它带来的可见性。我的经验阈值是：阶段平均时长不应低于 5 个工作日，低于这个数就该合并。

2. 误区二：把阶段名当成任务名前缀

“需求-登录改版”“开发-登录改版”“测试-登录改版”，看起来清晰，实际上掩盖了交接。这种命名方式下，没有人需要为“登录改版的验收标准是否完整”负责，因为这是任务，不是阶段产出物。

正确的做法是让阶段产出物独立存在，比如“登录改版需求规格（含验收标准与边界条件）”，它是需求阶段的交付物，可以被评审、被拒绝、被退回。任务可以重命名，交付物不可以含混。

3. 误区三：把里程碑当成阶段验收

里程碑是时间点，阶段验收是质量门。一个版本可以在里程碑当天“按时到达”，同时带着 12 个未关闭的高优缺陷。我在复盘时见过太多“里程碑 100% 达成、发布后一周内紧急修复 3 次”的版本。

阶段验收必须包含退出条件（Exit Criteria），而退出条件必须是可判定的布尔值，不是百分比。“代码评审完成率 90%”不是退出条件，“所有改动文件的评审记录已关联并通过”才是。

4. 误区四：阶段划分一次定终身

阶段划分应该跟产品成熟度走。0 到 1 阶段的产品，需求阶段可以极短，甚至用探索阶段替代；规模化阶段的产品，需求阶段反而要拉长，因为一次错误的成本被放大了几十倍。

我见过一个团队从 0 到 1 走到规模化，还在用早期的 4 阶段模型，结果是需求评审流于形式，每个季度都有 2 到 3 个需求在中后期被推翻。后来他们把需求阶段拆成“机会评估”和“方案定义”两段，中后期推翻率从 19% 降到 7%。

5. 误区五：把阶段管理当成向上汇报工具

这是最隐蔽也最致命的一个。当阶段状态被用来汇报而不是用来决策时，团队会本能地把状态填成“进行中”，因为“有风险”会引来追问。于是阶段看板越来越绿，实际交付越来越晚。

我的做法是给阶段状态加一列“阻塞原因”，并且规定：连续两个周期没有更新阻塞原因的阶段，视为无人负责，自动升级到项目负责人。这条规则一上线，阶段看板的可信度在两个月内明显改善。

四、专业判断逻辑：阶段划分的五条底层原则

方法可以有很多种，但判断一个阶段划分是否合理，我用下面五条原则。它们是我在多次失败后总结出来的，按重要性排序。

1. 交付物驱动原则

每个阶段必须以一个可交付、可评审、可拒绝的产出物收口。产出物的形式可以是文档、代码分支、测试报告、可运行环境、数据看板，但必须是别人能拿去用的东西。

判断方法很简单：把这个阶段的产出物拿给一个不参与该阶段的人，问他“你能基于这个继续工作吗”。如果答案是需要再问几轮才能开始，这个阶段就没有真正收口。

2. 单一责任人原则（DRI）

每个阶段有且只有一个直接责任人。注意是“直接责任人”，不是“负责人列表”。我在一个项目里见过某阶段写了 4 个负责人，结果是这个阶段延误会开了 3 次，没有人拍板。

直接责任人不需要是这个阶段里干活最多的人，但必须是那个有权宣布“这个阶段通过了”或者“这个阶段不通过，退回上一阶段”的人。

3. 交接成本小于并行收益原则

并行是阶段划分的最大收益来源，但并行有成本。每增加一次跨阶段并行，就要增加接口约定、联调协调和返工风险。

我的经验判断是：如果两个阶段的并行能压缩总工期 15% 以上，且接口在开工前已经冻结，就值得并行；否则串行更省心。很多团队并行了一堆阶段，最后总共省了 3 天，却增加了 20 天的协调成本和几十个缺陷。

4. 阶段长度与不确定性匹配原则

不确定性越高的阶段，长度应该越短，迭代越快；不确定性越低的阶段，长度可以越长，因为返工风险低。

落到具体数字上，我的建议是：探索/需求定义类阶段控制在 1 到 2 周；设计类阶段 1 到 3 周；开发类阶段 2 到 4 周；测试与发布类阶段 1 到 2 周；运营与复盘类阶段可以是持续性的，不占用关键路径。

5. 可观测原则

阶段状态必须能被外部观察到，而不是靠人汇报。可观测意味着：阶段入口和出口有明确的判定信号，比如分支合并、环境部署成功、用例通过率达到阈值、评审记录生成。

这一条决定了阶段管理能不能规模化。如果阶段状态依赖某个人每周更新，那么当项目数超过 10 个，这套机制一定会崩。

五、主流阶段划分方法横向拆解

市面上讲阶段划分的内容，大多只讲一种方法，然后默认它适用于所有场景。我的经验是：不同方法适用于不同的不确定性水平和组织规模，选错方法的代价比不选方法还大。

1. 阶段门方法（Stage-Gate）

特点是把流程切成若干个阶段，每个阶段末尾设一个决策门，门通过才进入下一阶段。适合不确定性中等、合规要求高、投入规模大的场景，比如硬件、医疗器械、金融核心系统。

它最大的优点是风险控制强，最大的缺点是门本身容易变成官僚化的审批仪式。我见过一个团队把每个门的审批人设成 6 个，结果阶段平均等待审批时间 5.2 天。

2. 迭代混合方法

特点是在大阶段框架内用短迭代推进，阶段负责方向和质量门，迭代负责交付节奏。这是目前 100 到 500 人研发组织最常见的形态。

关键在于大阶段的长度要和迭代周期成整数倍关系，否则会出现“迭代做到一半阶段结束了”的尴尬。我建议大阶段是迭代周期的 3 到 6 倍。

3. 按交付物切分方法

不以时间切，而以交付物切。比如按“可演示版本、可灰度版本、可全量版本”划分。适合用户产品、To C 产品，因为可演示性是可以被真实用户验证的。

这种方法的优势是每个阶段的完成度没有歧义，劣势是交付物的定义需要很强的产品判断力。定义得太宽，阶段就太长；定义得太窄，阶段就没有意义。

4. 按风险切分方法

以“最大的未知是否被消除”为划分依据。比如一个新技术引入项目，第一阶段的目标不是写完代码，而是证明技术方案在真实数据量下可行。

这种方法在预研类、平台类、数据类项目中效果最好。它的难点在于，风险识别本身需要经验，新手团队常常识别不出真正的风险点。

5. 按职能交接切分方法

以“交付责任从哪个职能转移到哪个职能”为划分依据。研发交给测试是一个阶段边界，测试交给运维是一个阶段边界。这是最贴近中大型组织实际运作的一种切分方式。

它的优势是责任清晰、交接明确；劣势是容易强化部门墙。如果配合明确的退出条件使用，效果最好；如果只有交接没有条件，就会退化成互相甩锅。

6. 一个可以直接套用的阶段定义模板

不管选哪种方法，阶段定义本身的结构是通用的。下面这个 YAML 结构是我在团队里推行了三年多的版本，可以直接放进项目管理工具的配置里。

stage: 方案定义
order: 2

duration_days: 10

dri: 产品负责人

entry_criteria:

机会评估阶段已通过，问题定义已冻结

目标用户在上一阶段已完成访谈，样本量 >= 8

exit_criteria:

需求规格包含验收标准，且每条标准可判定

技术方案已完成可行性评审，遗留风险项 交互稿覆盖全部主流程与异常流程

deliverables:

需求规格说明书（含验收标准）

技术可行性评审记录

交互原型 v1

handoff:

to: 研发负责人

artifact: 需求规格说明书 + 交互原型

acceptance_meeting: 阶段评审会（不超过 90 分钟）

rollback_rule: 若 3 个工作日内发现验收标准缺失，退回本阶段重做

这个模板里有三个关键点值得单独说。第一，entry_criteria 是很多人会忽略的字段，但没有它，阶段就只是开始时间而不是开始条件。第二，rollback_rule 必须写清楚，否则退回会变成扯皮。第三，handoff 里的 acceptance_meeting 要限时，超过 90 分钟的验收会基本都变成了问题讨论会。

六、案例与数据观察：中大型组织如何把阶段治理真正落地

前面讲的是方法，这一节讲落地。阶段治理的难点从来不是理念，而是当你有 300 人、20 个并行项目、三套历史遗留流程时，怎么把它真正跑起来。我在这里以 PingCode 的实际使用过程为例，因为它在 100 人以上组织的阶段管理场景里覆盖得比较完整。

1. 场景：一家 380 人的企业级软件公司的阶段治理

这家公司的形态很有代表性：研发 380 人，分成 6 条产品线，同时并行约 22 个项目，原来用的是自研的 Excel 加邮件流程。阶段状态靠项目经理每周手工汇总，一次汇总耗时约 6 到 8 小时。

他们最大的痛点有三个：阶段状态不可信、跨产品线依赖看不清、阶段交付物散落在各个网盘和邮件里。这三个问题都不是靠加人解决的，必须换掉承载阶段管理的底座。

2. 阶段模型如何配置成可执行的对象

他们的做法是把前面那套阶段定义模板整体搬进工具，让阶段成为一个有属性的实体，而不是甘特图上的一根条。每个阶段绑定直接责任人、入口条件、退出条件、交付物清单和回退规则。

这一步的价值在于：阶段状态不再由人填写，而是由条件满足度自动推导。需求规格没有关联验收标准，阶段的退出条件就不满足，看板上这个阶段就是黄色。这种“状态由事实驱动”的机制，是他们阶段看板可信度回升的根本原因。

3. 私有化部署与数据合规的约束

这家公司服务的是金融和制造行业客户，项目数据涉密，明确要求所有研发数据不出内网。这是选型时的一条硬约束。PingCode 支持私有化部署，这是它在这个场景里能落地的关键前提之一。

私有化部署这件事我在别的项目上也吃过亏。有的工具私有化版本和 SaaS 版本功能差了一大截，升级还要停机半天。所以我的建议是：选私有化方案时，一定要在 POC 阶段确认版本功能一致性、升级停机窗口和备份恢复演练方案，这三项比功能清单更重要。

4. 从既有工具平滑迁移的现实考量

这家公司原来有一部分团队用的是 Jira，积累了大约 4 年的历史数据，包括自定义字段、工作流、看板和几万条问题记录。他们的要求是历史数据可查、在途项目不中断、迁移期间不停工。

PingCode 支持从 Jira 平滑迁移，这一点在中大型组织的国产替代场景里是刚需。我参与的迁移项目里，迁移本身的时长通常不是问题，真正的问题是字段映射的语义对齐，比如原来的“Story Points”在新体系里对应什么，谁负责确认映射规则。我的经验是提前指定一个业务侧的数据 owner，全程负责映射口径，能把返工减少一大半。

5. 三个月后的真实变化

上线三个月后，最明显的变化不是速度，而是会议结构。跨产品线依赖对齐会的时长从每次 90 分钟降到 35 分钟，因为依赖关系在阶段规划阶段就已经被登记和确认，会议只需要处理例外情况。

另一个变化是阶段复盘的质量。以前复盘会产出的是“下次注意”这类结论，现在每一项改进都会变成下一个阶段的入口检查项，由系统在阶段启动时自动提示。这是把复盘从一次性活动变成持续性约束的关键动作，也是我认为阶段治理里最容易被忽略的一环。

需要说明的是，这类治理的收益不是线性的。前 6 周通常是摩擦期，团队会觉得填写入口条件和交付物是额外负担。真正感受到收益一般要等到第 8 到 12 周，因为那时才开始出现“因为提前发现边界问题而避免的返工”。如果没有管理层的耐心背书，这套东西大概率会在第 4 周被放弃。

七、落地清单：项目成员在四个阶段节点的动作清单

这一节是可以直接打印出来贴在工位上的内容。我按阶段的生命周期分成四个节点，每个节点列出具体动作、责任人和判定标准。

1. 阶段启动前（T-3 到 T-0）

1. 确认入口条件是否全部满足。责任人：本阶段直接责任人。判定标准：入口条件清单逐条勾选，任一未满足则不得启动。
2. 确认上游交付物是否可用。责任人：本阶段直接责任人 + 上游责任人。判定标准：能用该交付物独立开展至少 1 天工作而不需要额外询问。
3. 确认本阶段退出条件的可判定性。责任人：项目负责人。判定标准：每条退出条件都能由第三方独立验证，不含百分比类模糊描述。
4. 登记跨阶段依赖。责任人：项目经理。判定标准：所有外部依赖已指定对接人和期望交付时间。
5. 明确本阶段的并行范围。责任人：技术负责人。判定标准：每个并行项都写明了接口冻结时间。

2. 阶段执行中（T+1 到阶段结束前 20%）

1. 每周更新阻塞原因，而不是只更新状态。责任人：阶段直接责任人。判定标准：任何连续 2 个周期状态未变的阶段必须有阻塞原因记录。
2. 把返工单独计入返工池，不塞回原任务。责任人：技术负责人。判定标准：返工工作量独立可见，可追溯到触发的上游原因。
3. 监控阶段进度偏差，超过 20% 触发预警。责任人：项目经理。判定标准：偏差超过 20% 时必须在 48 小时内给出调整方案，而不是等到阶段末。
4. 维护交付物清单的实时状态。责任人：阶段全体成员。判定标准：交付物在产生当天即登记，不做期末集中补录。
5. 变更走阶段变更流程，不直接插单。责任人：项目负责人。判定标准：本阶段内的新增事项必须评估对退出条件的影响并留痕。

3. 阶段收尾与交接（阶段结束前 20% 到 T+0）

1. 逐条核对退出条件。责任人：阶段直接责任人 + 下游责任人。判定标准：退出条件全部满足，或未满足项已明确记录并指派责任人与截止时间。
2. 执行阶段验收会，限时 90 分钟。责任人：项目负责人。判定标准：会议产出明确结论，通过、有条件通过或退回，不允许“基本通过”。
3. 正式移交交付物并取得下游确认。责任人：上下游双方。判定标准：下游明确回复可基于该交付物开工。
4. 记录阶段实际耗时与计划耗时的差值及原因。责任人：项目经理。判定标准：差值原因归属到执行、交接、返工三类中的至少一类。

4. 阶段复盘（T+3 到 T+7）

1. 分析偏差归因，重点是边界问题。责任人：项目负责人。判定标准：产出至少 1 条关于入口或退出条件的改进项。
2. 把改进项转为下一阶段的入口检查项。责任人：项目经理。判定标准：改进项在下一个阶段的入口条件中可见并被执行。
3. 更新阶段定义模板。责任人：流程负责人。判定标准：模板变更需经过至少 2 个项目的试用验证。
4. 沉淀可复用的交付物样例。责任人：阶段直接责任人。判定标准：该类交付物下次可基于样例起步，节省首次撰写时间。

八、不同情况下的行动建议

阶段管理没有万能方案，下面按组织规模给出我的具体建议。这些建议都带有明确的取舍，不是“都要做到”的清单。

1. 10 人以下团队

不建议做正式阶段划分。用交付物驱动的方式代替，每个交付物定一个负责人和一个可演示节点就够了。这个规模下，阶段的开销一定大于收益。

唯一值得做的是每周一次 30 分钟的交付物对齐，确认“这周能拿出什么东西”。如果一定要分阶段，3 个阶段封顶。

2. 10 到 50 人团队

建议采用按交付物切分的方法，阶段数控制在 3 到 5 个。重点建设两件事：每个阶段的退出条件，以及阶段之间的交接确认动作。

这个规模不需要专门的项目管理工具做阶段治理，用一张共享的阶段看板加明确的退出条件就能覆盖。但如果同时并行 5 个以上项目，建议尽早引入轻量级的阶段管理能力，避免后面迁移成本过高。

3. 50 到 200 人团队

这是阶段治理的关键区间。建议采用迭代混合方法，大阶段 4 到 6 个，与迭代周期保持 3 到 6 倍关系。必须做三件事：阶段状态由事实驱动、返工单独计量、跨阶段依赖显式登记。

工具层面，这个区间开始需要承载阶段属性、交付物关联、依赖关系的能力。如果同时存在合规要求、历史数据迁移需求和多产品线并行，就应该认真评估私有化部署和迁移能力。PingCode 在这个区间是比较贴合的选择，主要原因是它把阶段、需求、缺陷、测试和依赖放在同一个数据模型里，不需要靠人工汇总打通。

4. 200 人以上组织

建议采用阶段门加职能交接的混合模型，阶段数 5 到 7 个，并设置明确的决策门。必须做四件事：阶段定义标准化、阶段变更受控、阶段数据可审计、复盘机制制度化。

这个规模下，阶段治理已经不是项目层面的事，而是组织能力建设。我会建议设立一个流程负责人角色，专门负责阶段定义模板的演进和跨项目的一致性，而不是让每个项目组自己定义一套。

九、不同情况下的取舍

阶段管理里的每一个决定都是取舍，没有“既要又要”的选项。下面四组取舍是我最常被问到、也是最需要提前想清楚的。

1. 速度与可控性的取舍

阶段划分得越细、门禁越多，可控性越高，速度越慢。这个取舍没有中间答案，你必须根据业务类型来定。

如果产品处在探索期，错一次的代价小，那就牺牲可控性换速度，阶段数压到最少，退出条件只保留最关键的 2 到 3 条。如果产品处在强监管、高客单价、错一次代价巨大的领域，那就必须牺牲速度换可控性，阶段门一个都不能省。

2. 标准化与灵活性的取舍

统一阶段模板便于跨项目对比和数据汇总，但会牺牲项目差异性。我的判断是：在 100 人以上的组织里，标准化的收益大于灵活性的收益，因为跨项目的数据可比性本身就是管理资产。

但标准化应该只覆盖“阶段结构”和“退出条件类型”，不应该覆盖具体每个阶段的时长和交付物内容。前者统一，后者允许项目组自定义，这是我认为比较合理的边界。

3. 工具建设与流程建设的取舍

很多团队踩的坑是：流程没想清楚就上工具，结果把混乱自动化了。我的建议顺序是先把阶段定义、退出条件和交接规则在文档层面写清楚，用一个项目试跑一轮，再决定要不要配置到工具里。

但反过来也有坑：流程想得很完美，却没有工具承载，靠人维护。阶段数超过 5 个、项目数超过 10 个时，纯人工维护的阶段状态基本不可信。

4. 自建与采购的取舍

自建阶段管理系统的团队很多，成功的很少。核心问题是维护成本会随时间线性上升，而业务需求会持续变化。我见过一个自建系统维护了 4 年，最终因为最初的设计者离职而无人敢动。

我的判断标准是三条：如果阶段管理只是你们的一个内部工具、如果你们的研发流程高度特殊且无法用通用模型表达、如果你们有稳定的内部工具团队，可以考虑自建。否则，采购成熟方案并做适度配置，长期总成本更低。

在评估阶段管理类平台时，我会重点看四件事：阶段模型能否自定义且支持条件驱动、交付物能否强绑定到阶段、跨项目依赖能否显式登记、历史数据能否平滑迁移。这四项里任何一项缺失，都会在运行 6 个月后变成瓶颈。

十、总结与下一步

回到最开始那个案例。那 9.4 天的偏差里，有 6.8 天不在任何人的任务清单上，这件事本身就是答案。项目阶段效率的提升，不是让人干得更快，而是让阶段之间的东西不再掉在地上。

我的核心观点可以浓缩成三句话。第一，阶段划分的对象是交接面，不是时间轴，如果你们的阶段定义里没有入口条件和退出条件，那它只是排期表。第二，阶段状态必须由事实驱动，而不是由人填写，只要状态依赖汇报，它在规模化的那天就一定会失真。第三，阶段治理的收益不是线性的，前 6 周是摩擦期，8 到 12 周才见收益，中途放弃是这类项目最常见的失败方式。

下一步我会建议做一件很小但很具体的事：挑一个正在进行的项目，把它现在的阶段列出来，然后逐条问三个问题，这个阶段的入口条件是什么？退出条件是什么？交付物是什么？如果三条里有一条答不上来，这个阶段就有问题。

把这个动作在 3 个项目上跑一遍，你大概就能判断出你们组织的阶段管理处在什么水平。如果发现超过一半的阶段都答不上三元组，那说明问题不在执行层，而在阶段定义本身，这时候再考虑方法选择和工具承载，顺序才是对的。