项目阶段项目阶段教程：PMO实操方法，避坑指南

2022年我接手过一个让我记忆犹新的项目审计：一个预算约 1800 万、计划 14 个月交付的制造业数字化项目，在第 11 个月时，项目经理汇报的总体进度是”完成 87%”。三周后，项目被宣布延期至少 5 个月。复盘时我们发现，那 87% 里包含了大量”已经开始但没结束”的工作：接口开发平均完成度自评 60%，但其中 40% 的接口连数据结构都没冻结。这不是个例。我统计过自己参与复盘的 47 个项目，凡是最终延期超过 30% 的，有 34 个在倒数第二个阶段都汇报过”进度正常”。

问题不在项目经理不努力，而在”项目阶段”这件事被大多数人做成了日历切分。阶段被定义成时间区间，阶段末被做成汇报会，阶段交付物被做成文档清单。这三件事一旦成立，阶段管理就彻底失效了，它从风险控制机制退化成了形式化流程。

这篇文章我会把项目阶段管理的实操方法完整拆开：阶段边界怎么定、阶段门怎么设计、交付物按什么标准验收、度量口径怎么统一、不同规模和不同行业该怎么取舍。里面的数据来自我 2021，2024 年参与的项目复盘样本（47 个项目，内部观察口径，不是行业统计），我会明确标出哪些是真实观察、哪些是推演。

一、先给结论：项目阶段管理真正在管什么

如果只让我讲三句话，就是下面这三句。理解这三句，后面所有方法都是它的展开；不理解这三句，后面所有工具都会变成形式。

1. 阶段不是日历切片，而是风险递减的承诺升级

多数人对阶段的理解是”把总工期切成几段”。这个理解的问题在于：它假设风险是均匀分布的。实际上项目风险是前高后低、且集中在少数几个关键不确定性上。

我更愿意把每个阶段看成一次承诺升级。阶段一结束时你承诺”需求范围冻结”，阶段二结束时你承诺”技术方案可行且成本可控”，阶段三结束时你承诺”核心链路可交付”。每一级承诺都消耗掉一部分不可逆资源，人力、采购、对外承诺。

所以阶段边界的正确划分依据不是”时间差不多该切了”，而是“到这里，哪一件事必须已经被证明或已经被放弃”。这个判断换过来，阶段的长度自然会不平均，前期短、后期长，或者遇到高风险模块时插入一个短平快的”验证阶段”，都是正常的。

2. 阶段门的核心作用是制造止损点，而不是审批节点

我见过太多组织把阶段门做成了审批会：材料提交、领导签字、会议记录归档、项目继续。这种阶段门的一次通过率通常是 95% 以上，但项目整体按期交付率没有任何变化。

原因很简单：一个 100% 通过的关卡，等于没有关卡。阶段门的价值不在于”批准继续”，而在于它有真实的概率说”停”。如果阶段门从来没有停过任何一个项目，PMO 应该先质疑这个门的设计，而不是庆贺项目执行力强。

我的经验值是：健康的阶段门体系，软性整改（有条件通过）的比例应该在 20%，40% 之间，硬性叫停的比例在 3%，8% 之间。低于这个区间，说明门太松；高于这个区间，说明前期定义太糙，门在替立项还债。

3. 交付物的验收标准要从”有没有”转向”下游能不能直接用”

这是我认为最被低估的一条。绝大多数阶段交付物清单是按”产物”列的：需求规格说明书、概要设计、测试报告、上线方案。检查方式就是看文件在不在。

但真正的标准应该是下游可用性：下一阶段的人能不能拿着这份东西直接开工，不需要回头找人问、补、猜。一份需求文档如果开发团队看完还要开三次澄清会，那它在阶段门上是”不合格”的，哪怕它写了 200 页。

我通常会给每个交付物定义一句”下游可用判据”。比如需求文档的判据是”开发负责人能据此拆分任务，且拆分后不需要超过 5% 的需求返工确认”。这句话比”文档完整”可执行得多。

二、背景：项目阶段在真实组织里是怎么跑偏的

要讲方法，先得知道现实长什么样。下面这些场景不是编的，是我在不同客户现场反复看到的模式。

1. 一个典型项目的阶段演进实况

我复盘过一个 9 人研发小组、周期 7 个月的产品交付项目。它的阶段计划写得很漂亮，四个阶段，每个阶段末有评审。但实际情况是这样演进的：

• 阶段一第 3 周：需求还在改，但阶段一结束时间不能动，于是把未确认需求标记为”待定项”带入阶段二。
• 阶段二第 5 周：待定项变成 17 条，架构设计只能按”兼容两种方案”来做，工作量翻了一倍。
• 阶段三第 4 周：测试发现核心流程与需求不符，此时距离交付只剩 6 周。
• 阶段四：用 4 周时间做本该在阶段一做的事，确认需求。

这个过程里，每一次阶段门都”通过”了。因为阶段门的检查项是”是否有待定项清单”，而不是”待定项数量是否低于阈值”。清单存在即合规，这就是形式化的典型症状。

2. PMO 在阶段管理里的三个真实身份

我做过甲方 PMO 负责人，也做过外部顾问。我的判断是，PMO 在阶段管理这件事上，实际扮演三种角色，而很多组织的 PMO 搞错了自己是哪一种。

第一种是流程维护者：定义阶段模板、交付物清单、评审规则，确保所有项目用同一套语言。这是基础职能，但不能停在这里。

第二种是风险裁判：在阶段门上有独立判断权，能基于证据要求整改甚至建议叫停。这个身份最难建立，因为它要求 PMO 有能力读懂交付物，而不是只数文件。

第三种是教练：帮项目经理把阶段计划做得更合理，在项目出问题前给出干预建议。这个身份决定了 PMO 是被欢迎还是被抵触。

我见过的最常见错配是：组织给了 PMO 裁判的名义，却只配备了流程维护者的能力，于是 PMO 只能靠催材料和开例会刷存在感。结果是项目经理把 PMO 当成额外负担，阶段门变成了双方心照不宣的表演。

3. 阶段失控通常发生在哪三个时间点

从我复盘的样本里，阶段失控有三个高频触发点，值得单独标记出来：

1. 阶段一中后段的需求冻结日。这一天之后如果需求还能自由进入，后面所有阶段的基线都是假的。
2. 阶段二结束前的技术方案定稿。方案没定稿就进入开发，返工是必然的，且返工量通常占该模块工作量的 30% 以上。
3. 阶段三结束前的接口/集成冻结。多方协作的项目里，接口变更的连锁成本最高，一次接口调整平均会影响 3，5 个参与方。

这三个点有一个共同特征：它们不是时间点，而是承诺点。PMO 要盯的不是”时间到了没有”，而是”承诺兑现了没有”。

三、拆解八个常见误区

下面这八条是我在不同组织里反复见到的坑。我按”危害程度 × 出现频率”排序，前三条几乎是通病。

1. 用完成百分比汇报进度

“这个模块完成了 80%。”这句话在项目管理里价值接近于零。因为百分比是自评的、不可验证的、且几乎不会下降。我做过一个统计：在未建立统一完成定义的项目里，自评完成度在 90% 附近停留的平均时长是 6.2 周，也就是所谓的”90% 陷阱”。

正确的做法是用可验证的完成定义替代百分比。比如”接口完成”定义为：代码合并、单元测试覆盖率达到约定值、集成环境联调通过、接口文档更新。四项全中才算 100%，缺一项就是 0%。

2. 阶段门做成汇报会

汇报会的形式是：项目经理讲 PPT，评委听，最后说”注意风险，继续推进”。这种会开完之后，风险一条没少，只是被记录进了会议纪要。

有效的阶段门有两个特征：一是事先公开准入条件，二是结论必须是三种之一，通过、有条件通过、不通过，且每种都对应明确的后续动作。没有第三种结论的会议，不是评审会。

3. 交付物清单无限膨胀

我在一家客户那里见过 42 项阶段交付物的清单。结果是项目经理花在写文档上的时间超过了做设计的时间，而真正的风险点，方案可行性，只由一份 8 页的设计文档承载。

我的建议是每个阶段的必交交付物控制在 3，5 项，且每一项都必须有明确的下游使用者。如果一个交付物没有任何下游角色会真正打开它，它就不应该出现在清单里，最多作为附录。

4. 阶段划分与财务、采购节奏脱节

这是最容易被忽略、后果最严重的一条。项目阶段如果跟付款节点、采购到货周期、预算释放节奏不一致，就会出现”技术上该进入下一阶段，但预算还没批”或者”设备还没到，阶段门已经过了”的荒诞局面。

我通常会在做阶段计划时同步画一条资源供给时间轴，把关键采购的长周期项（通常 8，16 周）标出来，然后反向检查阶段门是否落在供给到位的时点之后。

5. 没有基线就谈偏差

偏差率的计算前提是存在被批准的基线。很多项目的”计划”每次周会都在更新，于是任何偏差都能被解释成”计划调整了”。这不是偏差管理，这是移动球门。

规则很简单：每个阶段结束时冻结下一阶段的基线，基线变更必须走变更流程并记录原因。没有冻结动作的阶段计划，不具备度量价值。

6. PMO 越权替项目经理做决策

PMO 的裁判权和项目经理的决策权是两回事。我见过 PMO 直接在阶段门上改技术方案，然后项目出问题时责任说不清。这种模糊会迅速摧毁协作关系。

清晰的划分是：PMO 判断”证据是否充分、风险是否可接受”，项目经理决定”用哪种方案、怎么排期”。PMO 可以要求补证据、可以建议升级，但不替代做技术选择。

7. 阶段复盘变成追责会

一旦复盘会上第一个问题是”这是谁的责任”，后面所有的信息都会失真。项目经理会开始修饰数据，团队会隐瞒问题。我见过一个团队连续四个季度的阶段复盘结论都是”外部依赖影响”，直到换了主持方式才暴露出真实原因。

我的实操经验是：复盘的前 40 分钟只讨论事实和机制，不讨论人和责任。责任归属放在最后，且只针对机制失效，不针对个体。

8. 工具里的阶段和实际流程是两张皮

这是我在中大型组织里最常看到的现象：线下有一套阶段评审流程，工具里只用来记任务和工时。结果是阶段数据不完整，无法做跨项目对比，PMO 只能靠手工收表。

要解决这个问题，必须让阶段、阶段门、交付物、评审结论四类对象在工具里成为一等公民，而不是写在任务描述文本里。这个要求在早期选型时往往被忽略，代价在中后期体现得非常明显。

四、专业判断逻辑：阶段与阶段门怎么设计

这一节是全文最实操的部分。我把方法拆成四个步骤，每一步给出可执行的判断标准和模板。

1. 用决策点定义阶段边界

我的做法是：先不画时间轴，先列出这个项目所有“一旦做错、后面返工成本极高”的决策点，然后按决策的依赖关系排序，相邻两个决策点之间就是一个阶段。

举个实际例子。一个数据平台建设项目，我识别出的关键决策点是：数据源清单确认、主数据模型定稿、接入方案定稿、核心报表口径确认、性能基线达标。这五个点之间自然形成五个阶段，而不是按”需求，设计，开发，测试，上线”的传统四段切分。

这样切的好处是：每个阶段末，都必然有一件可以验证、可以说不的事情。阶段门不需要凭空创造检查项，它检查的就是这个决策点是否真的闭合了。

阶段定义模板（YAML 结构示意）
phase:

id: P3

name: 接入方案定稿

decision_point: 接入方案通过技术评审且成本在预算 ±10% 内

entry_criteria:

主数据模型已定稿并冻结

数据源清单已完成可用性验证

exit_deliverables:

接入方案设计书（含成本测算）

集成测试环境搭建完成证明

downstream_consumer: 开发组、采购组

downstream_usable_criteria: 开发组可据此拆分不少于 80% 的开发任务

gate_type: hard

max_duration_weeks: 6

这个模板里最关键的两个字段是 downstream_consumer 和 downstream_usable_criteria。它们强制回答”这份交付物是给谁用的、怎么算能用”，这是把交付物从文档变成资产的关键。

2. 三类阶段门，不要只用一种

我在实践中会把阶段门分三类，按风险等级匹配使用。全都用硬门会拖垮节奏，全都用软门则等于没有。

自动门是很多组织没用起来的一类。比如”单元测试覆盖率不低于约定值””静态扫描无高危问题””接口文档与代码一致性校验通过”，这些完全可以由工具自动判定，不需要开一次会。把这类检查自动化，能把阶段评审的时间压缩一半以上。

3. 三类决策结论，必须对应三种动作

阶段门的结论必须落到动作上，否则结论没有约束力。我在所有项目上推的是下面这张表。

这张表的价值在于：它把”评审意见”变成了”可追踪的动作”。我服务过的一个组织，引入这张表之后，阶段整改项的逾期率从 43% 降到了 12%，原因是每条整改项都有了明确责任人和时限，而不再是一句”请项目组关注”。

4. 偏差口径必须统一，否则数据不可比

跨项目对比的前提是口径一致。我建议至少统一这四个度量指标：

• 阶段偏差率 = （实际阶段结束日 − 基线阶段结束日）/ 基线阶段工期。注意分母是阶段工期，不是项目总工期，否则不同长度的阶段不可比。
• 阶段门一次通过率 = 无整改项直接通过的门数 / 总门数。这个指标反映前期定义质量。
• 阶段内返工工时占比 = 因返工产生的人天 / 该阶段总人天。这个指标反映技术方案和执行质量。
• 交接损耗天数 = 下一阶段实际启动日 − 上一阶段交付物通过日。这个指标最容易被忽略，但往往占总延期的三成。

四个指标里，我最看重交接损耗天数。因为它几乎不受个人能力影响，纯粹反映阶段机制的设计质量。如果一个组织的平均交接损耗超过 10 个工作日，基本可以断定阶段交付物缺乏下游可用性。

五、案例与数据观察：一个 300 人研发组织的阶段治理改造

这一节我讲一个完整案例。它是 2022 年底到 2024 年我参与的一个多项目并行组织，涉及研发与交付团队合计约 300 人，同时运行 11 个在途项目。案例中涉及工具侧落地时，我以 PingCode 为例说明，它主要服务中大型企业及 100 人以上组织，支持私有化部署，也支持从 Jira 平滑迁移，在这类组织的国产替代场景里是比较常见的选择。

1. 改造前的真实状态

改造前，这家组织的项目管理有明显的三个特征：阶段模板有，但和实际执行不一致；阶段评审开，但通过率 100%；工具里只有任务和工时，没有阶段对象。

最直接的数据表现是：11 个在途项目里，有 8 个的”计划完成时间”在过去半年里被修改过 3 次以上。跨项目对比实际上做不了，因为每个项目的阶段划分都不一样，口径没法对齐。

我们在改造前的基线测量里，抽了 6 个已完结项目做复盘，得到的基线数据是：阶段门一次通过率 46%，阶段内返工工时占比 22%，阶段间交接损耗平均 14.5 个工作日。

2. 改造做了四件事

第一件是统一阶段定义语言。 我们把原来按”需求，设计，开发，测试，上线”的通用切分，改为按各项目类型的决策点切分，最终收敛出三种阶段模板：产品研发型（5 阶段）、客户交付型（6 阶段）、平台建设型（5 阶段）。每种模板都带 downstream_usable_criteria 字段。

第二件是重建阶段门规则。 按硬门 30%、软门 50%、自动门 20% 的比例重新配置，并明确硬门有否决权。为此专门调整了 PMO 的职责描述，把”评审组织者”改为”阶段门裁判”，同时给 PMO 配了两名有技术背景的成员。

第三件是把阶段对象搬进工具。 这是最费时的一步。我们在 PingCode 里把阶段、阶段门、交付物、评审结论四类对象建模，阶段门配置为准入条件清单，评审结论直接关联后续任务。

这里有个细节值得说：自动门是通过工具的流水线规则和质检配置实现的。比如代码质量阈值、接口文档一致性检查这类，配置为不达标即阻断阶段推进。这一项让阶段评审的会议时长从平均 3.5 小时降到 1.6 小时。

第四件是建立阶段复盘机制。 每个阶段结束后 5 个工作日内完成复盘，只讨论机制不讨论人，输出不超过 3 条改进项，且必须落到下一阶段的准入条件里。

阶段门准入条件配置示意（自动门生效规则）
gate: P4-integration-freeze

type: auto

rules:

metric: unit_test_coverage

operator: ">="

threshold: 75

unit: "%"

metric: static_scan_high_risk

operator: "=="

threshold: 0

unit: "count"

metric: api_doc_consistency

operator: ">="

threshold: 95

unit: "%"

on_fail: block_phase_transition

notify: [pmo, tech_lead]

3. 上线四个季度后的指标变化

改造分三批推进，第一批 4 个项目在 2023 年 Q1 上线新机制，到 2024 年 Q1 完整运行四个季度。我拿到了 9 个项目的对比数据。

有一个数据我要单独提醒：阶段门一次通过率上升，不等于门变松了。恰恰相反，同期硬门的否决率从 0% 上升到 6.2%，也就是开始真的拦下项目了。一次通过率上升的原因是前期定义质量提升，多数风险在进入阶段门前就被处理掉了。

还有一点值得注意：前三项指标的改善在第一个季度就已经很明显，但阶段偏差率的改善滞后了两个季度。原因是偏差率的改善依赖于基线稳定性，而基线稳定需要几个完整的阶段周期才能建立。这也是我常说的，阶段治理的收益不是线性的，前期快、中期慢、后期再加速。

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

同样是阶段管理，不同规模、不同行业的组织，做法差异很大。下面按四种典型情况给出建议，你可以直接对号入座。

1. 50 人以下团队：先做冻结，别做流程

这个规模的团队，做完整阶段门体系是负担。我的建议是只做两件事：需求冻结点和技术方案冻结点，其他阶段门全部省略。

具体做法是在阶段计划里明确标出这两个日期，到期时开一个不超过 1 小时的会，只问两个问题：需求清单是否冻结、方案是否通过评审。冻结之后再提的新需求，一律走变更流程并评估对交付时间的影响。

工具上不需要复杂配置，用一个阶段看板加一个变更记录表就够。重点不是工具，而是让团队形成”冻结之后不再随意改”的习惯。

2. 50，300 人组织：三类阶段门 + 统一度量口径

这个规模是阶段治理收益最明显的区间。建议完整引入三类阶段门，并把前面四个度量指标纳入项目健康度看板。

关键动作是把度量口径写进制度，而不是靠 PMO 每次手工解释。我在这个规模的组织里通常会用 2，3 个月完成第一批项目的试点，选 3，5 个中等风险项目，跑通两个完整阶段再推广。

工具侧，这个阶段通常需要把阶段对象建模进项目管理平台，否则数据无法自动沉淀。如果组织原本使用海外工具并考虑国产替代，PingCode 支持 Jira 平滑迁移，迁移过程中可以把原有的项目结构映射到阶段模型上，减少重建成本。

3. 300 人以上、多项目并行：模板化 + 自动门 + 组合视图

达到这个规模后，最大的挑战不是单个项目的阶段做得好不好，而是跨项目可比性。如果每个项目的阶段划分都不一样，PMO 就无法做组合层面的资源调度和风险排序。

这个阶段的必备能力有三项：一是收敛出 3，5 种标准阶段模板，所有项目必须选用其一；二是把可自动校验的检查项全部做成自动门，降低人工评审成本；三是建立项目组合视图，能按阶段、按风险等级筛选在途项目。

涉及私有化部署需求的组织，通常会对数据主权和系统集成有更高要求。PingCode 支持私有化部署，这对需要与内部统一身份、CI/CD 流水线、数据平台打通的中大型组织是必要能力。

4. 强监管与交付型项目：阶段门要与合规证据绑定

金融、医疗、政务这类行业的项目，阶段门不仅是管理工具，还是合规证据的一部分。这类项目的阶段交付物清单不能随意精简，但可以优化组织方式。

我的建议是把合规要求的证据项与项目管理要求的交付物合并为一份清单，而不是维护两份。否则项目组要为同一件事准备两套材料，重复劳动严重。同时在阶段门结论里明确记录合规检查项的结论，方便后期审计追溯。

七、不同情况下的取舍

方法讲完之后，更重要的是取舍。我列四组我认为最实际的权衡，每组都给出我的倾向和理由。

1. 治理强度 vs 交付速度

这是最根本的一组取舍。增加阶段门、增加交付物、增加评审，一定会在短期内降低交付速度。问题不是”要不要治理”，而是”治理强度应该匹配多大的失败代价”。

我的判断标准是失败代价的可承受性。如果项目失败的成本主要是内部返工和一次时间延误，治理可以轻一点，阶段门少设、交付物精简。如果失败会导致对外违约、监管处罚、客户流失或重大资金损失，治理强度必须提上去，宁可慢一点。

这里有个常见的错误：很多组织对所有项目用同一套治理强度，结果是小项目被流程压死、大项目流程不够。正确做法是按项目分级配置治理强度。

2. 阶段粒度 vs 管理成本

阶段越多，风险暴露越早，但每个阶段的固定管理成本也越高。我算过一笔账：一个阶段从准备评审到复盘闭环，平均消耗 20，35 人天（含项目经理、评审人、参会人的时间折算）。

这意味着，如果一个 3 人月的小项目切成 6 个阶段，光阶段管理成本就占掉了 10% 以上的人力。这种情况下，宁可切粗也不能切细。我的经验阈值是：单个阶段的计划工期不应短于 3 周，否则阶段的固定成本会高于它的风险控制收益。

3. 私有化部署 vs SaaS

这个取舍取决于三件事：数据敏感度、集成需求复杂度、运维能力。

如果项目数据涉及客户敏感信息、行业监管要求，或者需要与内部统一身份、内网 CI/CD、数据仓库深度集成，私有化部署几乎是被迫的选择。代价是运维投入和升级成本，一个 300 人规模的组织，私有化部署的年均运维投入通常在 15，30 人天加硬件成本。

如果对数据主权和深度集成要求不高，SaaS 的成本和迭代速度优势明显。我的建议是先明确未来三年的合规要求和集成清单，再决定部署形态，不要在选型时只看当下的功能对比。

4. 迁移成本 vs 长期可控

很多组织在考虑国产替代时，最先卡在迁移成本上：历史数据怎么办、字段怎么映射、团队要不要重新培训。我的观察是，迁移的一次性成本和”继续忍受不适配流程”的长期成本，通常不在一个量级上。

一个 300 人规模的组织，从海外工具迁移到国产平台，如果流程梳理得当，通常可以在 2，3 个月内完成主体切换，包括项目结构映射、权限重建、自动化规则重建。真正的风险不在技术迁移，而在数据模型不兼容导致的流程妥协，比如原来用工作流表达阶段门，新平台不支持，只能退回线下评审。

所以迁移前的第一件事不是导数据，而是核对关键流程对象在新平台上的建模能力。四项必须能建：项目阶段、阶段门与准入条件、交付物与验收状态、跨项目组合视图。这四项能建，迁移就是可控的；建不了，再便宜的迁移方案也会在半年后付出更大的重构代价。

八、下一步：30 天可执行的落地清单

如果你认同前面的判断，可以从下面这个 30 天计划开始。它的设计原则是：不改造全流程，只在一个项目上跑通一个完整阶段。

1. 第 1，7 天：识别决策点，重画阶段边界

1. 选一个中等风险、周期在 4，8 个月的在途项目。
2. 列出这个项目所有”做错后返工成本极高”的决策点，目标 4，6 个。
3. 按依赖关系排序，相邻决策点之间即为一个阶段。
4. 为每个阶段写出 downstream_consumer 和 downstream_usable_criteria。
5. 把结果与项目组对齐，允许调整，但要求每个阶段的验收标准必须可验证。

2. 第 8，14 天：配置阶段门与准入条件

1. 给识别出的阶段门分类：硬门、软门、自动门，比例参考 3:5:2。
2. 为每个门写准入条件清单，条件必须是可判定的（有或无、达标或不达标）。
3. 挑出可自动校验的条件，配置为自动门规则。
4. 明确三类结论（通过、有条件通过、不通过）对应的动作和时限。
5. 在项目管理平台上把阶段、阶段门、交付物、评审结论建成独立对象。

3. 第 15，21 天：跑第一个阶段门

1. 按新规则组织第一次阶段评审，严格按准入条件逐条判定。
2. 允许出现”有条件通过”，并当场列出遗留清单和责任人。
3. 记录四项度量：阶段偏差率、一次通过率、阶段内返工工时占比、交接损耗天数。
4. 会议结束后 5 个工作日内完成复盘，输出不超过 3 条机制改进项。

4. 第 22，30 天：校准与推广判断

1. 对比新机制与旧流程的实际耗时差异，确认管理成本是否可接受。
2. 检查交付物的下游可用性：下一阶段是否还需要回头澄清。
3. 根据第一个阶段的运行情况调整准入条件的严格程度。
4. 决定是否推广到第二批项目，建议第二批控制在 3，5 个。

这四步里，最容易失败的环节是第 3 步，因为第一次严格执行阶段门时，大概率会出现”不通过”或者大量”有条件通过”，会有人觉得是流程太严。我的经验是，前三到五个阶段门是最难的，一旦团队发现通过门槛是稳定的、可预期的，抵触会快速下降。

九、总结：关于项目阶段，我最想让你记住的三件事

第一，阶段是承诺结构，不是时间结构。判断一个组织的阶段管理是否有效，最简单的检验方式是问一句：”你们上一个阶段门，有没有拦下过任何东西？”如果答案是从来没有，那这套阶段管理体系大概率是装饰品。

第二，阶段管理的最大收益来自交接损耗的下降，不是来自进度汇报的改善。前面案例里，交接损耗从 14.5 个工作日降到 5.8 个工作日，这一项的收益就超过了所有其他措施的加总。而它几乎完全取决于交付物是否有明确的下游可用判据。

第三，阶段治理存在明显的规模适配关系。50 人以下做冻结就够，50，300 人值得完整建设三类阶段门，300 人以上重点是模板化和跨项目可比性，强监管项目要把合规证据和交付物清单合并。用同一套强度打所有项目，必然一半被压死、一半管不住。

如果你现在就要动手，我建议只做一件事：把你手上最重要的那个项目的阶段交付物清单拿出来，给每一项补上”下游使用者”和”下游可用判据”两个字段。填不出来的那一项，就是你可以从清单里删掉的。