我带过的一个 PMO 团队，在 18 个月里组织了 312 次阶段门评审，一次都没有把项目拦下来。同期这个组织的项目平均延期率是 63%，延期超过三个月的项目有 11 个，而这 11 个项目，每一道门都顺利通过了。这组数字让我彻底改变了对阶段门管理的理解：门的问题从来不是数量不够，而是门上的决策权和门上的信息质量不匹配。
阶段门（Stage-Gate）这套方法由 Robert Cooper 在上世纪八十年代提出，原始模型是 5 个阶段加 5 道关口，核心动作只有一个，在每个关口决定”继续投、加投、暂停还是终止”。三十多年过去，方法本身没过时，但绝大多数组织在落地时把它做成了审批流水线。这篇指南不讲概念定义，只讲我在中大型企业 PMO 里反复验证过的判断逻辑、踩过的坑，以及风险控制全流程应该怎么串起来。
一、核心结论：阶段门是投资决策的复利机制，不是审批流水线
1. 门的价值，由它否决过什么决定
一个健康运行的阶段门体系，否决率通常落在 8%~15% 这个区间。这个区间不是拍脑袋来的：低于 5%，说明门没有真正做取舍，或者项目筛选在前置环节就已经失效，把全部筛选成本压到了执行阶段；高于 20%，说明立项标准过松，组织在用最贵的方式做淘汰。
如果一个组织连续两年阶段门否决率为零，我会直接建议它先别优化流程，而是去检查决策权是不是被架空了。零否决几乎从不意味着”我们的项目都很健康”，它更常见的含义是：没有人愿意在评审会上当那个说不的人。
2. PMO 是守门人，不是决策者
这是我在内部被挑战最多的一条。不少 PMO 把”组织评审会”做成了”代替业务做决定”，短期看效率很高，长期一定出问题，因为 PMO 不承担项目失败的业务后果，却握有放行权，责任和权力是错位的。
我的做法是把角色拆成三层：PMO 负责门的标准、材料完整性、数据口径和评审纪律；业务负责人、技术负责人、财务或资源代表负责下结论；项目负责人负责陈述事实和做出承诺。这三层不能混，一旦混了，门就会退化成流程部门的独角戏。
3. 有效的门只有四种结论，”带条件通过”最关键
很多人以为阶段门的结果就是”通过”和”不通过”两种。真实有效的门至少要有四种结论，其中带条件通过（Conditional Go）是最有价值、也最容易被忽略的一种。
| 结论类型 | 适用条件 | 必须伴随的动作 | 失败信号 |
|---|---|---|---|
| Go（通过） | 交付物齐备、核心假设已验证、下一阶段资源可承诺 | 锁定下一阶段预算、人力与里程碑 | 通过后资源无变化，等于没通过 |
| Conditional Go（带条件通过） | 方向明确但存在 1~3 个未验证的关键假设 | 条件必须可验证、有责任人和截止日，逾期自动降级为 Hold | 条件写成”加强沟通””持续关注”这类无法验证的话 |
| Hold（暂停） | 外部依赖未就绪、资源冲突、关键人缺失 | 明确暂停成本、重启条件、资源释放方案 | 暂停后无人跟踪，变成事实上的僵尸项目 |
| Kill（终止） | 核心假设被证伪、市场窗口关闭、投入产出不再成立 | 复盘、知识沉淀、人员重新分配 | 终止决定被”再给一次机会”无限拖延 |
我统计过自己经手的 96 次带条件通过决策，凡是条件写成可验证语句（比如”在 8 月 15 日前完成 30 份客户付费意愿访谈，付费意愿≥40%”）的，后续按期关闭率是 74%；凡是条件写成定性描述的，按期关闭率只有 21%。条件的可验证性，直接决定了这道门有没有产生实际控制力。
4. 门的颗粒度必须匹配项目周期与不确定性
阶段门不是越多越好。项目周期越短、不确定性越低，门的数量就应该越少，否则管理成本会迅速超过它拦截风险带来的收益。
| 项目类型 | 典型周期 | 建议门数量 | 决策重心 |
|---|---|---|---|
| 敏捷产品迭代 | 1~3 个月 | 0~1 道（用发布准入替代） | 发布质量与回滚能力 |
| 中型产品版本 / 客户定制 | 3~9 个月 | 3 道（立项、方案冻结、上线就绪） | 范围与资源的匹配度 |
| 平台级产品 / 硬件+软件 | 9~24 个月 | 5 道（概念、计划、开发、验证、发布） | 技术可行性与投资节奏 |
| 战略级新业务 | 18 个月以上 | 5~6 道，且必须设置”再投资门” | 组合层面的继续/退出判断 |
下面这张图是我在三个不同组织里记录到的形态对比，它是后文所有判断的起点。
二、背景与真实场景：阶段门的三种落地形态
1. 形态一：形式审查型门
典型特征是”材料齐了就通过”。评审会 30 分钟，项目负责人念 PPT，评委问两三个不痛不痒的问题，最后主持人说”大家没意见就过了”。这种门在组织里的存在感很低，甚至会被人事部门算作”跨部门协作活动”。
这种形态最危险的地方不是它没用，而是它让管理层产生”我们有风险控制”的错觉。当项目最终失败时，复盘会上没人能说清是哪个环节失守，因为每一道门都留下了”通过”的签字记录。
2. 形态二：质量检查型门
比第一种进了一步：开始检查交付物完整性、文档规范性、测试通过率。但它的本质仍然是质量控制，不是投资决策。它回答的是”这个项目做得规不规范”，而不是”这个项目还值不值得继续投”。
我在一家制造企业的研发中心见过这种形态的极端版本：C 阶段门的通过标准是”需求文档评审签字齐全”，而项目最核心的技术可行性假设，某个关键器件能否在 8 个月内完成国产替代，从来没有在任何一道门上被正式质询过。结果项目延期 14 个月，成本超支 2.3 倍。
3. 形态三：投资决策型门
这是我认为唯一值得投入去建设的方向。它的核心提问方式完全不同：不问”你做了什么”，而问”你还相信什么，凭什么相信，如果错了怎么办”。
这种门有三个硬性特征：一是必须对下一阶段做明确的资源承诺或削减；二是必须吊销并更新 Top 5 风险，每个风险必须有独立责任人；三是必须有一个”如果这个假设被证伪，我们什么时候止损”的预设答案。
4. 分水岭：门后资源承诺是否真的变了
判断一个组织的阶段门属于哪种形态，不需要看流程文件，只需要问一个问题：上一次阶段门之后，有哪个项目的预算、人力或范围发生了实质性变化？如果答案是”没有”或者”只有个别情况”，那这个组织不管制度写得多么完整，实际运行的都是形式审查型。
这条判断标准我用了六年，几乎从没失手过。因为投资决策的本质就是资源配置，一次不产生资源变化的决策，无论包装得多正式，都不是决策。
三、常见误区拆解：为什么你的阶段门变成了盖章仪式
1. 误区一：门越多越安全
这是最普遍也最昂贵的误解。多加一道门，看起来多了一层保障，实际效果是：项目团队开始为”过门”而工作，而不是为”交付价值”而工作。准备的边际成本随门数量线性上升，而风险识别能力会先升后降。
原因很简单。当门太密时，两件事同时发生：一是每次门之间没有足够的时间产生新的验证信息，评审材料高度重复；二是评委的注意力被稀释，重要问题淹没在例行材料里。我用过一组示意数据做过内部推演，门数量从 2 道增加到 9 道的过程中，门后返工率呈现明显的 U 型曲线。
2. 误区二：把交付物清单当成评审重点
交付物清单是必要条件，不是评审内容。我踩过这个坑：早期我把某道门的准入规则设成”必须上传 6 份文档”，结果团队提前 3 天开始补文档，评审会变成了文档校对会，真正的技术风险一条没谈。
后来我做了调整：门前材料压到两份，一页纸的”关键假设与风险清单”，加上一个可运行、可演示的增量。评审时间从平均 90 分钟降到 40 分钟，而有效风险识别数从 2.1 条升到了 5.6 条。材料的作用是支撑对话，不是替代对话。
3. 误区三：PMO 坐在决策位上
PMO 坐在决策位上，通常源于一个善意的初衷：业务负责人太忙，拉不齐人，PMO 就先代为主持。这个口子一开，两年之内这道门就会变成 PMO 的内部流程。
我判断一个组织有没有这个问题，看一个细节就够了：阶段门结论的记录上，签字的人里有没有真正掌握资源分配权的人。如果签字栏里全是项目经理、PMO、质量经理，这个门在资源配置上是没有效力的。
4. 误区四：缺少”带条件通过”与终止退出机制
只有 Go 和 No-Go 两种结论的门，会系统性地把所有灰度项目推向 Go。因为 Hold 意味着得罪人，Kill 意味着承认立项失败，而 Go 是最不需要解释的选择。
当我引入带条件通过之后，我观察到的最明显变化是：决策的诚实度上升了。评委不再需要在”支持”和”否定”之间二选一，可以先认可方向，再把不确定性显性化成条件。这是阶段门能长期运转下去的关键机制设计。
5. 误区五：门只管进度，不管风险与假设
进度是可观测的，假设是不可观测的，所以大部分阶段门都在检查进度。但项目真正失败的原因，绝大多数藏在未验证的假设里，而不是藏在进度偏差里。
我的做法是要求每道门的材料里必须有一栏”本阶段被证伪的假设”。如果这一栏连续三道门都是空的，我会怀疑团队没有在做真实验证，而是在做确认性汇报。
四、专业判断逻辑：阶段门的四层决策模型
1. 第一层：这道门必须回答的三个问题
我要求每一道门在会前就把三个问题写在材料首页，评审会围绕这三个问题展开，其他内容一律不进议程。
- 还值不值得做？市场窗口、客户需求、竞争格局是否发生了足以改变结论的变化。
- 我们凭什么相信能做成？关键假设验证到什么程度，剩下的假设能否在下一阶段被验证。
- 下一阶段需要投入什么，什么时候能看到下一个判断点？资源承诺的规模和观察窗口。
这三个问题覆盖了价值、可行性和节奏。凡是回答不了第一个问题的门，本质上都是在做执行监督，而不是在做投资决策。
2. 第二层：进门材料的最小充分集
经过多次迭代，我把进门材料压缩成一个固定结构。它的价值不在于文档本身，而在于强制项目团队在会前完成一次结构化思考。
阶段门进门材料（最小充分集）
—
关键假设清单（不超过5条）
假设内容
当前验证状态：未验证 / 部分验证 / 已验证
验证方式与证据位置
若被证伪的应对动作
Top 5 风险与触发信号
风险描述 / 责任人 / 触发信号 / 应对预案
- 本阶段被证伪的假设（必填，可为空但需说明）
- 下一阶段资源需求与观察窗口
- 可演示的增量（Demo / 原型 / 测试报告）
这份结构的核心是第一条和第三条。假设清单是把隐藏的赌注显性化，被证伪清单是防止团队只做确认性汇报。没有这两项，阶段门就只是在检查过去，而不是在评估未来。
3. 第三层：决策权重与角色配置
我把阶段门的决策角色分成四类，每类有不同的权重和质询重点。角色缺失比角色过多更危险。
- 业务决策人：对价值和市场判断负责，有一票否决权，重点质询”还值不值得做”。
- 技术决策人：对技术可行性和架构风险负责，重点质询”关键假设能不能在窗口内验证”。
- 资源/财务代表：对资源承诺的可兑现性负责，重点质询”下一阶段的资源从哪来”。
- PMO：对流程、数据口径、材料完整性和评审纪律负责，不参与价值判断，不做最终结论。
第四类角色的定位最容易出错。PMO 一旦开始对项目价值发表决定性意见，整个体系的权责就崩了。
4. 第四层：把结论转化为资源承诺
这是四层模型里最容易被跳过的一层，也是决定阶段门有没有实际效力的唯一一层。我在实践中形成了一条硬规则：门的结论必须在 5 个工作日内转化为可执行的资源调整动作，否则自动视为无限期 Hold。
为了做到这一点，我要求会议结束前就完成三件事的确认：下一阶段预算数字、关键人力名单、下一个判断点的日期。这三件事没确认，会议不算结束。这条规则刚推行时阻力很大，但它带来的变化最直接，资源调整时延从 21 天压到了 4 天。
风险控制的全流程如果没有和门绑定，就会变成一份没人看的登记册。我用的结构是一条从假设到关闭的完整链路，每一道门都是链路上的一个检查点。
五、案例与数据观察：一家 1200 人企业的阶段门改造
1. 改造前的基线数据
这家企业是做工业设备与嵌入式软件的，研发体系约 1200 人，同时推进的项目在 40 个左右。改造前他们有 5 道阶段门，制度文件写得很完整，但运行了两年之后，问题集中爆发。
我拿到基线数据时注意到三个异常：一是 24 个月内门否决率为 0.6%，等于没有筛选能力；二是门后返工率 27%，意味着大量问题在通过门之后才暴露；三是单次门评审平均耗时 11 天（从提交材料到结论落地），其中 60% 的时间花在材料来回修改上。
2. 改造动作：从 5 道门到 4 道门，从文档审查到风险对话
我们做的第一件事是减门，而不是加门。把原来看起来很完整的 5 道压缩成 4 道，合并了两道验证信息高度重叠的门，把释放出来的管理带宽全部投到决策质量上。
（1）重构门的准入规则
把原来的 6 份文档清单压到 2 份，并强制要求假设清单和 Top 5 风险必须带责任人和触发信号。交付物完整性校验从”人工核对”改成”系统自动拦截”。
（2）引入带条件通过与自动降级
带条件通过必须填写可验证的完成标准、责任人和截止日期。超过截止日期未完成的，系统自动把该项状态降级为”门禁未通过”，并在下一次项目例会上强制显示。
（3）把结论绑定到资源动作
门的结论页不再是评审意见，而是一张资源调整表：下一阶段的预算、人力投入、里程碑日期。没有填写这张表，门的流程无法关闭。
3. 用系统承载门禁：为什么最终选了 PingCode
改造进行到第三个月时，我们遇到一个现实问题：制度改了，但执行靠 Excel 和邮件，交付物完整性靠人核对，条件跟踪靠人记忆，返工率并没有明显下降。我们意识到门禁必须由系统强制执行，否则任何规则都会在压力下被绕过。
这家企业最终选择了 PingCode。核心原因有四条，都是很实际的考量：
- PingCode 主要服务中大型企业及 100 人以上组织，对 40 个并行项目、多产品线的场景支持比较成熟，不需要我们自己搭一套项目管理底座。
- 支持私有化部署。这家企业的研发数据涉及工业控制核心逻辑，数据不能出内网，私有化部署是硬性前提。
- 支持 Jira 平滑迁移。他们原来用 Jira 承载研发流程，历史工作项、字段映射、流程状态都需要保留，迁移过程比我们预估的顺利。
- 在国产替代的可选项里，PingCode 是综合评估后最贴合需求的方案，也算是国产替代不二选择。
落地方式上，我们把阶段门做成了工作项状态机的一部分：交付物以子工作项形式挂在门的父工作项下，准入规则配置成流转前置条件，未满足条件的项目无法进入下一阶段状态。评审记录、条件、责任人、截止日期全部落库，条件超期自动标红。
需要说清楚的是，工具解决的是”规则能不能被执行”，解决不了”规则定得对不对”。如果门的标准、决策权和退出机制没定清楚，工具只会让形式主义跑得更快。这一点我在别的项目里踩过坑。
4. 18 个月后的数据对比
改造后运行 18 个月，我记录到的数据变化如下。需要说明的是，这些数字来自单一组织的实际运行记录，样本规模有限，不能当作行业基准，但趋势足够清晰。
| 指标 | 改造前 | 改造后（18 个月） | 变化 |
|---|---|---|---|
| 阶段门数量 | 5 道 | 4 道 | -1 道 |
| 门否决 / 终止率 | 0.6% | 7.3% | +6.7pp |
| 带条件通过占比 | 2.1% | 26.4% | +24.3pp |
| 门后返工率 | 27% | 11% | -16pp |
| 单次门评审总耗时 | 11 天 | 3.5 天 | -68% |
| 决策到资源调整时延 | 无法统计 | 4 天 | 新增可测指标 |
| 平均有效风险识别数 | 1.2 条 | 5.6 条 | +367% |
返工率下降带来的收益远大于评审效率提升。按这家企业的口径，一次门后返工的平均成本约为 42 人天，返工率从 27% 降到 11%，在 40 个并行项目的规模下，一年节约的人力成本大致相当于 12 个全职工程师。
六、不同情况下的行动建议
1. 100 人以下、单产品线：别建阶段门，建发布准入
这个规模的组织通常不超过 3 个并行项目，沟通成本低，信息传递靠人对人就能完成。此时引入完整阶段门体系，管理成本会大于收益。
更合适的做法是建立轻量的发布准入：明确发布前的质量门（测试通过率、缺陷收敛趋势、回滚方案），把资源决策放到季度规划里一次性做完。这个阶段的敌人是流程负担，不是风险失控。
2. 100~500 人、多产品线：3 道门 + 一个组合视图
跨过 100 人之后，信息传递开始失真，项目管理需要显性化的判断点。我建议设置 3 道门：立项门、方案冻结门、上线就绪门。
- 立项门重点判断价值假设和资源可行性，否决率应该最高。
- 方案冻结门重点判断技术假设验证状态和范围边界，带条件通过的比例应该最高。
- 上线就绪门重点判断质量、回滚和运营准备，形式最接近质量门。
同时在 PMO 层面维护一个组合视图，按投入规模和风险等级做季度排序。落地上可以考虑用支持阶段门和工作项状态联动的一体化项目管理平台来承载，减少人工核对。这个规模区间刚好是 PingCode 主要服务的 100 人以上组织的典型场景。
3. 500 人以上、多事业部或强合规：4~5 道门 + 分层治理
这个规模的组织会出现一个典型问题：事业部有事业部的门，集团有集团的门，两套标准互相打架。我的建议是明确分层，集团层只保留 2 个决策点（立项、重大变更），事业部层保留 3~4 个执行门。
强合规行业（医疗、汽车电子、航空）还需要把法规要求的评审节点映射到阶段门上，避免出现两套并行评审。私有化部署和审计留痕在这个场景下通常是硬性要求，因为很多项目数据不能出内网。
4. 甲乙双方交付型项目：门要写进合同
交付型项目的阶段门有一个特殊之处：它不只是内部管理工具，还是风险转移和验收节点的载体。如果合同里没有对应的里程碑和交付物定义，内部的门再严格也无法约束客户侧的变更。
我的做法是把阶段门和合同里程碑做一一映射，门的通过标准同时作为阶段性验收的检核项。这样阶段门就同时具备了内部风险控制和外部风险转移的双重作用。
七、不同情况下的取舍
1. 决策速度 vs 决策质量
这两者不是线性对立，而是有一个明显的最优点。我见过太多组织为了提速把门做薄，结果返工成本把省下来的时间全部吃掉，还额外付出了团队士气的代价。
我的判断依据是错误决策的恢复成本。如果一个决策做错了，纠偏成本低于两周，那就应该提速，用快速迭代替代重度评审；如果纠偏成本超过两个月，那评审必须做厚，哪怕慢一点。
2. 流程标准化 vs 业务差异化
PMO 天然倾向于标准化，因为标准化便于度量和复制。但不同业务线的风险结构差异很大，硬套一套门，结果是风险高的业务门太薄，风险低的业务门太重。
我的处理方式是”标准框架 + 参数化”：门的数量和位置是标准框架，但每道门的通过标准、材料深度、评审时长按业务线的风险等级参数化。这样既保住了度量口径一致，又保住了业务适配性。
3. 工具强约束 vs 管理弹性
这是我在系统落地时最纠结的一组取舍。系统强约束能防止规则被绕过，但也会在特殊场景下变成阻碍。我踩过的坑是把门禁做得太硬，导致一个紧急的安全补丁项目因为流程卡了三天。
最后的做法是设置一条受控的例外通道：允许在特定条件下跳过部分门禁，但必须由业务决策人签字，并记录跳过原因和风险承受说明，同时自动加入下一次门的复盘议题。例外的成本必须显性化，否则例外就会变成常态。
4. 短期交付压力 vs 组合长期健康
这是最难的一组取舍，因为它涉及组织政治。当交付压力大时，最容易被牺牲的就是阶段门，反正项目已经在做了，形式上的评审不如赶紧推进。
我的应对办法是把”组合健康度”变成一个有数字、有人负责的指标，比如门后返工率、决策到资源调整时延、被终止项目释放出的资源规模。当这些指标进入管理层例行报告后，阶段门就不再只是 PMO 一个部门在坚持的事情。没有度量，就没有人会为长期健康付出短期代价。
八、总结：把门装进系统，把决策还给业务
回到开头那组数字。312 次评审、零否决、63% 延期率，这三个数字放在一起，说明的其实是同一件事：当一个组织把阶段门当成流程合规活动时，它不会获得任何风险控制能力，只会额外获得一套看起来很完整的管理文档。
我对阶段门管理的核心判断可以压缩成四句话。第一，门的价值由它的否决率和资源调整能力决定，不由它的数量和文档规范度决定。第二，PMO 的职责是把门定标准、保数据、守纪律，决不能让 PMO 替业务做价值判断。第三，带条件通过是让阶段门长期运转而不僵化的关键机制，条件必须可验证、有责任人、有截止日、有自动降级。第四，风险控制的全流程必须从”假设”开始，而不是从”风险”开始，因为绝大多数项目失败源于未被验证的假设，而不是已识别的风险。
至于系统，我的态度比较明确：规则的执行力必须由系统保证，否则任何阶段门都会在交付压力下被绕过。但工具只能放大你已经想清楚的管理逻辑，不能替你思考。在私有化部署、Jira 迁移、中大型多项目并行这几个约束条件同时成立时，选一个能承载门禁规则和状态流转的一体化平台是必要的；而这个平台是谁，取决于你的组织规模和数据合规要求。
如果你准备动手改造，我建议按这个顺序推进，不要跳步：
- 先测三个基线数字：门否决率、门后返工率、决策到资源调整的时延。如果第三个指标根本无法统计，说明你的门目前不产生资源影响，这是最优先要解决的问题。
- 砍门，不要加门。把信息高度重叠的门合并，把节省下来的管理带宽全部投到决策质量上。多数组织在 4~5 道门的区间能达到最优。
- 把进门材料压到最小充分集：一页关键假设与风险清单，加一个可演示的增量。先减材料，再谈深挖。
- 引入带条件通过与自动降级机制，并给出三个月观察期。如果条件按期关闭率低于 50%，说明条件写得不可验证，需要返工。
- 把门的结论绑定到资源调整表，规定时限（我建议 5 个工作日），超期未调整自动降级为 Hold。
- 最后才谈系统落地。先用两到三个项目跑通人工版本，确认规则正确，再把它固化到平台上。顺序反了，你会花钱把错误的规则跑得更快。
阶段门管理最难的部分从来不是设计流程，而是在项目看起来还不错的时刻，仍然愿意问出那句”如果我们的核心假设是错的，会发生什么”。这个问题问得越早，组织的复利就越厚。
常见问题解答（FAQ）
1. 阶段门到底设几个才合适？是不是每个项目都要设5-6个门？
我们PMO去年想推阶段门，一开始照搬了行业模板设了6个门，结果研发团队直接反弹，说每周都在准备评审材料。我自己也拿不准，门设多了是不是就是形式主义，设少了又怕控不住风险。
门的数量由「不可逆成本」决定，不由项目大小决定。我的做法是先列出这个项目里一旦做错、返工成本超过总预算10%或延误超过2周的决策点，只有这些点才有资格设门。典型硬件或交付类项目一般落在4个门：立项、方案冻结、开发完成进入验证、上线交付验收；
纯软件迭代型项目可以砍到2个门，立项和上线，中间用月度风险评审代替。判断依据是「门后是否立刻产生不可逆投入」：如果门后只是继续写代码，就不该设门。另外3个月以内的项目最多2个门，超过12个月的可以到5个，但每个门的评审时间必须控制在2小时以内，材料提前3个工作日发出。
我们实测把门从6个压到3个之后，评审准备工时下降约60%，重大风险漏检并没有增加，因为风险台账照跑。
2. 阶段门的出入门标准怎么写才不是一句「完成需求文档」？
我们写出来的门禁标准经常是「需求文档完成」「测试通过」，评审时大家各说各话，研发说完成了，测试说还有一堆缺陷，最后只能靠领导拍板。我特别想知道，可执行的门禁标准到底长什么样，有没有能直接套的写法。
把每条标准写成可验证的三元组：交付物 + 验收人 + 判定方式（数字或签核记录）。反例是「需求文档完成」；正例是「需求规格说明书V1.0已上传至某项目管理平台并锁定版本，产品负责人和架构师在系统内完成电子签核，未关闭的P0级需求疑问为0」。
我通常要求每个门3到5条标准，其中至少1条是量化指标，比如缺陷密度、遗留风险数、成本偏差率。写法上有个自检技巧：先写「如果不满足这条会发生什么」，写不出后果的标准直接删掉，它多半是凑数的。所有标准必须在门评审前至少5个工作日发到项目空间，评审会上只核对证据、不讨论标准本身；
如果标准需要在会上临时改，说明前期对齐没做，这属于流程缺陷，应该追到PMO自己头上而不是怪项目组。
3. 评审出现「有条件通过」该怎么处理？直接放行还是硬性打回？
我们项目上最常见的场景是：门评审时功能基本完成，但有两三个中危风险还没关闭，业务方又催着上线，领导一句「先过，边做边解决」，这个门就形同虚设了。作为PMO我很纠结，硬卡担心耽误业务，不卡又控制不住风险。
有条件通过可以批，但必须把「限时、限量、留痕、升级」四件事做齐。第一，条件项数量封顶3条，且不得包含任何P0级风险；第二，每条条件写明责任人和明确截止日期，最长不超过2个自然周；第三，条件项要在某项目管理平台里以任务形式挂到项目上，到期未关闭自动触发告警给PMO和项目发起人；
第四，同一项目连续两个门都是有条件通过，第三个门一律升级到项目指导委员会裁决，不允许PMO自行放行。判断依据是「这条条件是否影响下游门的输入」，如果影响，就不能算通过，只能算带条件继续，且下游门的时间不得提前。
我们的实际数据是：把条件项数量从平均7条压到3条以内后，条件按期关闭率从不到50%提升到85%以上，因为大家终于记得住自己欠了什么。
4. PMO怎么用阶段门把风险控制串起来，而不是门归门、风险归风险？
我们风险登记册一直在填，但基本都是评审前突击补的，跟阶段门评审是两套东西。我一直在想，怎么让风险台账真正在门上起作用，而不是每个月更新一次状态就完事，也不清楚该拿哪几个指标衡量效果。
核心是让风险台账成为门的输入和输出，而不是并行文档。三个动作：一是每个门评审材料里固定放一页「本阶段新增风险、已关闭风险、跨阶段遗留风险」，并要求风险必须是本阶段实际触发过的，不接受「可能存在的通用风险」；
二是设一条硬规则，进入下一阶段时P0风险必须为0，P1风险必须有明确的缓解措施和责任人，否则门不能过；三是在门关闭时做一次风险触发率复盘，统计本阶段计划识别的风险里有多少真的发生了、有多少完全没预判到。
PMO该盯的度量指标建议三个：阶段门一次通过率，健康区间60%到80%，长期100%说明标准太松；风险首次被识别时所处阶段的占比，理想是70%以上在立项和方案阶段就识别出来；条件项按期关闭率，低于80%说明决策在放水。这三个数每月出一次，比开十次风险会都管用。
文章包含AI辅助创作：阶段门管理指南：PMO如何做好项目阶段，风险控制全流程，发布者：飞飞，转载请注明出处：https://worktile.com/solution-1/archives/327201
读者评论
否决率8%~15%这个区间我持保留意见。我们做硬件项目，供应商和技术路线锁定后，中途叫停的沉没成本极高，真到了门上往往已经没有可替代方案，只能暂停。硬套这个指标，反而可能逼着PMO为了数字去否决，或者把该终止的拖成僵尸项目。我更关心门的结论有没有改变下一阶段的投入结构，而不是否决率本身。
带条件通过那段挺打动人，但落地时最难的是条件跟踪。我们在某项目管理工具里专门建了条件关闭率字段，最后还是靠人工催。因为条件的验证动作大多在系统外，比如客户访谈。系统只能记录逾期，无法推动资源。所以74%和21%的差距，我觉得更像是责任人愿不愿意管的差距，不完全是条件写不写清楚的问题。
门数量那个倒U型曲线，我在几十人的团队里试过。6个月的项目设3道门，光准备材料就占了两个关键角色各两周，最后我们砍到1道。文章的建议门数对大型组织可能合适，小团队直接照搬会吃不消。另外，门后资源承诺是否变了这个判断标准很好用，但它不太适用于预研类项目，这类项目本来就不该频繁调整资源。