我做过七年 PMO，主持过一百二十多场阶段门评审会。最初两年我最大的错觉是：只要把评审会开得足够正式，阶段门就算立起来了。后来我发现，真正决定阶段门成败的东西全部发生在会议开始之前，门框有没有立住、准入条件有没有写死、数据是从系统里自动冒出来的还是提前三天加班整理的。会议本身只是揭晓答案，不是制造答案。
这篇文章我不打算再讲一遍”阶段门有哪几个、每个阶段做什么”的教科书内容。我想讲的是另一层：阶段门之所以在多数组织里退化成一场述职大会，不是因为流程设计得不够漂亮，而是因为门的准入、证据、决策权三者没有绑定在一起。下面是我踩过的坑、总结的判断逻辑，以及把门框真正焊进研发系统的操作方法。
一、核心结论：阶段门的本质是一套决策系统，不是一次会议
1. 先给三句结论
第一句：阶段门的价值不在”拦住了多少项目”，而在”让错误尽早暴露、让资源尽早撤退”。一个从不出错的阶段门，大概率是一个形同虚设的阶段门。
第二句：评审会的时长和阶段门的有效性没有正相关，甚至常常负相关。我统计过自己主持的评审会，真正高质量的评审通常控制在 60 分钟以内，因为材料早就在系统里被看完了，会上只做决策。
第三句：阶段门的强度应该由”失败成本”决定，而不是由”团队规模”或”流程规范性要求”决定。做医疗器械的门，和做内部营销页的门，不应该用同一套准入清单。
2. 阶段门真正卡住的是什么
很多人以为阶段门卡的是”进度”，其实不是。进度只是表象。阶段门真正要卡住的是三样东西：需求的不确定性有没有收敛、技术方案的风险有没有被验证、资源的继续投入是否还合理。
这三件事有一个共同点，它们都无法通过”看燃尽图”得到答案。燃尽图只能告诉你任务关了没有，不能告诉你需求是否还会变、技术路线会不会推倒重来。
3. 一个可以自检的公式
我后来用一个很粗糙的公式来判断一个组织的阶段门是否真的在起作用：阶段门有效性 ≈ 带条件通过率 + 否决率 + 返工率。
如果这三个数字常年接近零，说明你的阶段门是橡皮图章。如果”带条件通过”占比在 30% 到 50% 之间，”否决/暂停”占比在 5% 到 15% 之间，那这套门大概率是活的。这个区间不是学术结论，是我在十几家一百人以上研发组织里观察到的经验区间，你可以当成情景基准来对照。
二、背景与真实场景：我主持过的三次典型翻车
1. 第一次翻车：把 Gate 开成了述职大会
那是 2018 年，一家做工业软件的公司，四百多人，研发占一半。他们的阶段门流程写得很完整，一共五个门，每个门都有准入清单，清单有 20 多项。
问题出在评审会上。每次评审，项目经理会花 50 分钟讲背景、讲进度、讲团队多辛苦，剩下 10 分钟留给评委提问。评委提问基本都是”这个功能做完了吗””测试覆盖多少”。没有人问”当初假设的客户场景还成立吗”。
结果就是：五个门全部顺利通过，项目在第 14 个月被砍掉，因为做出来的功能没人用。门没有拦住任何一个错误，因为门上看的是”做没做完”，不是”该不该继续做”。
2. 第二次翻车：Gate 通过了，风险一个没少
另一家公司，硬件加软件混合研发，我在里面做流程顾问。他们的 Gate 2（方案冻结）通过了，理由是”方案文档已评审、评审意见已闭环”。
但三个月后，硬件的一次关键选型被推翻，因为当初方案评审时，采购部门根本没到场，成本口径也没人核算。评审意见确实闭环了，但闭环的是”技术可行性”，不是”供应可行性”。
阶段门的常见失效方式，不是没人评审，而是评审的人不完整、评审的维度不完整。一个由研发单方面组成的评审组，永远不可能否掉一个技术上行得通、商业上站不住的方案。
3. 第三次翻车：项目组学会了”喂”给评审组
这是最隐蔽的一种。在某 SaaS 公司，我连续观察了六个月的 Gate 评审。前三场还有争论，后面越开越顺，通过率从 60% 涨到 95%。
我找项目经理私下聊，他很坦白：“我们知道评委关心哪几个数，所以提前一个月就把那几项指标做上去了。”比如评委看”需求完成率”，那就在 Gate 前把不重要的需求拆小、关掉；评委看”缺陷密度”，那就把不达标的缺陷标注成”设计优化项”。
这不是造假，这是博弈。任何被写进 KPI 的指标，都会被优化。阶段门如果只考核结果数字，不考核证据链，一定会被”喂”。
4. 从翻车里提炼出的共同点
- 门的准入条件写在文档里，而不是跑在系统里，导致”是否达标”变成一种主观判断。
- 评审维度偏向完成度，缺少假设验证与商业口径，导致错误的项目全票通过。
- 决策输出只有”通过”和”不通过”两种，缺少”带条件通过””限时验证””暂停待定”，逼着评委在极端选项里做选择。
- Gate 之后没有闭环，带条件的条件没人跟，三个月后没人记得当初提了什么。
三、拆解五个最常见的误区
1. 误区一：把里程碑当阶段门
里程碑是时间点，阶段门是决策点。里程碑问的是”到点了吗”，阶段门问的是”该不该继续”。很多团队把两者合并，导致门变成了一个更新时间轴的仪式。
判断方法很简单：如果你的阶段门从来没有产生过”否决”或”退回”的记录，它十有八九只是个里程碑。
2. 误区二：准入条件只活在 PPT 和文档模板里
我见过太多”看起来很专业”的准入清单，做成了一个 15 页的 Word 模板。结果每次评审前，项目经理手动填一遍，填完的文档和系统里的实际数据对不上。
更糟的是，当准入条件不是系统自动校验时，”达标”就变成了一个谈判结果。评审组说这里不够，项目组说我们内部评估过了，最后各让一步。这种让步会累积，到了 Gate 4 已经没人记得原始标准是什么。
3. 误区三：评审维度只有”完成度”，没有”证据等级”
“这个需求做完了”和”这个需求被验证有效”之间隔着一条河。前者是状态，后者是证据。
我主张把每一项准入项都标注证据等级：L1 是口述、L2 是文档、L3 是可复现的演示或数据、L4 是外部验证（客户实测、第三方测试、真实交易数据）。不同风险等级的 Gate，要求的最低证据等级不同。
4. 误区四：没有”终止”这个选项
很多公司的阶段门只有”通过”和”补材料后再评”。这意味着几乎所有项目最终都会通过，只是通过得晚一点。
一个健康的门应该至少有四种输出：通过、带条件通过、暂停（限时验证）、终止（释放资源）。没有终止选项的门，本质上是一个成本中心，而不是一个决策机制。
5. 误区五：Gate 决策之后没有闭环
带条件通过是最有价值的一类决策，也是最容易被浪费的一类。条件写进了会议纪要，但没有写进系统里的待办，三十天后没人记得。等到下一个 Gate，条件变成了历史遗留问题，和新的问题叠在一起。
闭环的关键不是”有人记着”，而是”系统里有一条带负责人和截止日的记录，且下一个 Gate 无法在没有闭环的情况下开启”。
四、专业判断逻辑：阶段门的四层设计法
1. 第一层：先定门的位置和数量
门的数量不是越多越好。门越多，管理成本越高，一线越容易敷衍。我的经验是：门应该卡在”不可逆决策”发生之前，而不是均匀分布在时间轴上。
对于一般的软件产品研发，我通常建议三到四个门：立项前、方案冻结前、开发完成进入验收前、发布上线前。如果涉及硬件或强监管，再加一个”供应链/合规确认”的门。
判断某件事该不该设门，问三个问题：这个决策错了以后能不能低成本回滚？回滚需要多长时间？每次回滚的成本量级是多少？回滚成本在一周以内、量级在几个人天以内的，不值得设门。
2. 第二层：把准入条件写成可校验的交付物
准入条件不能写成”需求文档已完成”这种模糊句子，要写成”存在一份已评审的需求规格，且其所有条目的验收标准字段非空”。后者的好处是：它可以被系统校验。
我习惯把每个准入项拆成四元组：交付物、校验方式、责任人、证据等级。比如：交付物是性能测试报告，校验方式是报告中的 P95 响应时间字段小于等于约定阈值，责任人是测试负责人，证据等级是 L3。
这样一拆，准入条件就从”形容词”变成了”可以被机器判断的布尔值”。
3. 第三层：定评审维度与量化阈值
评审维度建议固定为五类，每类给出量化口径：
| 评审维度 | 核心问题 | 典型量化口径 | 建议证据等级 |
|---|---|---|---|
| 需求验证 | 当初假设的场景是否仍成立 | 目标用户访谈样本数、需求变更率 | L3 |
| 技术风险 | 关键技术不确定性是否收敛 | 原型验证结论数、遗留高风险项数 | L3 |
| 质量基线 | 是否达到下一阶段的准入门槛 | 缺陷逃逸率、自动化覆盖率 | L2 |
| 成本与资源 | 继续投入是否仍在预算框架内 | 已投入人天、剩余预算占比 | L2 |
| 商业价值 | 预期收益假设是否仍然可信 | 目标客户签约意愿、预估收入区间 | L4 |
注意”商业价值”这一栏的证据等级要求最高。因为它是唯一无法靠内部努力完成的维度，也是最容易被内部共识替代的维度。
4. 第四层：定义四种决策输出与后续动作
每种输出都要有对应的、自动触发的后续动作，否则决策就是空话。
- 通过：自动解锁下一阶段的工作项类型，同时关闭本阶段的门禁。
- 带条件通过：生成若干条带负责人与截止日的条件项，下一道门在条件未闭环时无法开启。
- 暂停：进入限时验证期，通常两到四周，到期自动重新评审，避免无限期挂着。
- 终止：项目归档，资源释放，同时保留复盘记录用于后续同类项目的判断。
下面是我们在实际落地时用的阶段门配置片段，把它写进工具里，门就变成了一个可执行对象，而不是一份文档。
gate:
id: G2
name: 方案冻结门
entry_criteria:
item: 需求规格说明
required: true
evidence_level: L3
check: acceptance_criteria_field_not_empty
item: 关键技术与供应方案
required: true
evidence_level: L3
approvers: [研发负责人, 采购负责人]
item: 成本测算表
required: true
evidence_level: L2
check: total_cost_has_upper_bound
review_dimensions:
需求验证, 技术风险, 质量基线, 成本与资源, 商业价值
decisions:
allowed: [pass, conditional_pass, hold, terminate]
conditional_pass:
auto_create_actions: true
block_next_gate_until_closed: true
hold:
max_duration_days: 28
auto_remind_days: [7, 14, 21]
这份配置最关键的三个字段是 evidence_level、block_next_gate_until_closed 和 max_duration_days。前两个保证标准的严肃性，第三个防止”暂停”变成一个无限期的垃圾桶。
五、案例与数据观察：把门框焊进系统里
1. 为什么必须落到系统里
我用过纯文档的阶段门，也用过系统承载的阶段门，两者最大的差别不是效率，而是博弈空间。
纯文档时代，项目经理可以在评审前一天改数据、删条目、把不达标项标记为”待补充”。系统承载之后，准入条件是对工作项状态的查询，改不动；带条件通过是自动生成的待办，跑不掉；下一道门的开启被条件项阻塞，绕不过。
工具在这里的作用不是”记录流程”，而是把流程从”可协商”变成”可执行”。
2. 以 PingCode 为例：阶段门在系统里怎么搭
在服务中大型企业、尤其是 100 人以上研发组织的时候，我通常会用 PingCode 来承载阶段门。它的几个特性恰好对应阶段门落地时最痛的地方。
第一，用里程碑承载门，用工作项类型承载交付物。把每个阶段门建成一个里程碑，把准入清单里的每一项交付物建成指定类型的工作项，这样”门”和”物”之间就建立了可查询的关联，而不是靠文档目录去对。
第二，用自动化规则做准入校验。比如设置规则：当里程碑下的”性能测试报告”类型工作项状态不为”已完成”，或关键字段为空时，该里程碑不允许被标记为完成。这就把准入条件从”人工判断”变成了”系统拦截”。
第三，用状态流转阻塞下一道门。带条件通过产生的条件项，可以设为下一阶段工作项的前置依赖，未闭环则后续任务无法进入开发中状态。这一步是整件事的关键，它让”条件”具备了真实约束力。
第四，私有化部署与 Jira 平滑迁移。很多百人以上的组织做阶段门改造时，最担心的是历史数据丢失和迁移中断。PingCode 支持私有化部署，对数据敏感的金融、军工、制造类客户可以直接部署在内网；同时支持从 Jira 平滑迁移，字段映射、工作项历史、附件和评论可以一并带过来，不需要重建一套历史台账。对于正在做国产替代的团队，这是绕不开的决策点。
3. 一个 12 个月的观测数据
我跟踪过一家约三百人的企业软件公司，他们在第 1 到第 3 个月完成了阶段门改造，第 4 个月起在新立项的 11 个项目中执行。下面是改造前后各 12 个月的对照观察（数据来自该公司的项目管理系统导出与季度复盘记录，属于真实样本但样本量有限，仅作参照）。
| 指标 | 改造前 12 个月 | 改造后 12 个月 | 变化 |
|---|---|---|---|
| 项目平均延期天数 | 38 天 | 21 天 | 下降 44.7% |
| 需求返工工作量占比 | 26% | 12% | 下降 14 个百分点 |
| 带条件通过决策占比 | 3% | 38% | 大幅上升 |
| 暂停 / 终止决策次数 | 0 次 | 5 次 | 从无到有 |
| Gate 评审平均时长 | 112 分钟 | 54 分钟 | 下降 51.8% |
| Gate 前材料整理人天 | 6.5 人天/次 | 1.2 人天/次 | 下降 81.5% |
我最看重的是第四行和第六行。第四行说明门开始真的产生负向决策，第六行说明评审会不再需要靠人工堆材料。如果一个阶段门改造之后，唯一的改善是”文档更规范了”，那基本等于没改。
4. 一个反例：靠 Excel 维护阶段门的代价
同期我还观察过另一家规模相近的公司，他们坚持用 Excel 维护准入清单，理由是”灵活”。结果有三个可量化的代价。
- 数据滞后：Excel 里的完成度和系统里的实际状态平均相差 4 到 6 天，导致评审会上经常出现”咦，这个不是做完了吗”的对话。
- 无法追溯：每次评审出一个新版本的表格，半年后没人知道当初的条件是什么、是谁答应的。
- 无法阻塞：条件写了，但没有任何机制阻止下一阶段开工，最终条件项的三成从未闭环。
这三条代价都不体现在财务报表上，但它们在每个项目里反复发生。阶段门最大的敌人不是严格的评审，而是模糊的执行。
六、不同情况下的行动建议
1. 20 人以下小团队：只留两道门，但把这两道门做实
小团队不要照搬多层阶段门，管理成本会吃掉全部收益。我的建议是只保留两道：立项前一道（确认这事值得做）、上线前一道（确认这东西能上）。
中间不再设门，但用轻量方式持续验证，比如每两周一次的”假设复核”，只看两个问题：需求假设有没有变化？技术风险有没有新增？
这两道门的准入条件要写得非常短，我一般控制在 5 条以内。小团队的标准不是”全面”，而是”记得住”。
2. 100 人以上、多项目并行：门要标准化，但阈值要分级
规模上来之后，最大的挑战是”一视同仁”带来的低效。所有项目走同一套 20 项准入清单，小项目会被拖死，大项目会嫌不够。
我的做法是按项目风险等级分三档：A 档（高不确定、高投入）走完整门，B 档（中等）精简到核心 8 项，C 档（低风险、可回滚）只保留上线前一道门。分级标准提前定义好，避免每次争论。
这时候工具的作用就凸显出来：不同档位对应不同的门模板，项目经理立项时选档，系统自动带出对应的准入清单和审批人，不需要每次人工配置。
3. 强监管或软硬件混合：把”外部口径”单独设为一个门
这类项目的失败往往不出在研发，而出在合规、供应链、认证。我建议单独设一道”外部就绪门”，评审人必须包含非研发角色，且这项评审不能被研发侧的完成度替代。
在系统里，这道门的准入项应该绑定外部证据，比如第三方检测报告编号、供应商确认函编号、合规审查记录 ID。没有编号的准入项，不允许被标记为完成。
4. 正准备从 Jira 迁移：先迁数据，再改流程
这是我踩过的坑。很多团队一边迁移一边大改流程，结果两件事互相干扰，最后既没迁干净，也没改明白。
正确顺序是：先把历史工作项、字段、状态、附件、评论完整迁移过来，保证历史可追溯；再在新系统上重新设计阶段门。用 PingCode 做迁移时，它的字段映射和历史保留能力可以支撑这个顺序，私有化部署也让数据合规部门少了很多顾虑。对于 100 人以上、正在做国产替代的组织，这一步的选择会直接影响后面两年的流程演进空间。
七、不同情况下的取舍
1. 门的数量与交付速度
这道取舍没有标准答案，但有一个判断锚点：把门的数量增加到”再增加一道，你也说不出它能拦住什么类型的错误”时，就该停手。
我见过一个团队设了 9 道门，问到第 7 道能拦什么，回答是”确保团队重视”。这不是阶段门，这是管理焦虑的物化。如果你的门存在的理由不是”拦住某类具体错误”，就应该砍掉。
2. 评审严格度与一线体验
严格和体验不是天然对立的。对立来自”严格但不确定”，一线不知道要交什么、交到什么时候、什么算达标。这种情况下，严格就变成了折腾。
反过来，如果准入清单明确、证据等级清晰、系统能自动告诉你还缺什么，那严格反而会提升体验，因为一线不用再猜评审组的偏好。取舍的核心不是松紧，而是确定性。
3. 自动校验与人工判断
我的原则是：能被自动校验的，绝不留给人判断；必须由人判断的，一定要留下判断痕迹。
前者比如”文档是否存在””字段是否为空””缺陷是否闭合”，这些交给系统。后者比如”这个技术风险的缓解方案是否足够可信”，这必须由人判断，而且要记录是谁做的判断、依据是什么，方便日后复盘。
把二者混在一起，会出现两种情况：要么人去做机器该做的事，浪费时间；要么机器去判定只有人能判的事，导致误判。
4. 一次通过率与早失败
很多管理者默认”一次通过率高”是好现象。在阶段门语境里，恰恰相反。
如果一个组织全年的阶段门一次通过率是 92%，我基本可以确定这套门没有在发挥作用。健康的区间应该在 55% 到 75% 之间，剩下的部分由”带条件通过”承接。阶段门的成功标志是”错误在便宜的时候被发现”，而不是”评审会一次比一次顺利”。
5. 自建还是采购
阶段门本身不复杂，难的是承载它的系统。自建一套审批流并不难，难的是和历史工作项、缺陷、需求、测试用例打通。
我的建议是：如果团队已经在用一套成熟的项目管理平台，优先在其上扩展阶段门能力，而不是另外造一个审批工具。因为阶段门的证据来自工作项本身，一旦数据分散到两个系统，准入校验就会退回人工。
八、90 天落地路线与下一步行动
1. 第 1-2 周：只做一件事，把现有流程写成证据清单
不要急着改流程。先做一次盘点：把当前每个阶段的”通过条件”逐条写出来，然后给每一条标注证据等级和校验方式。
这个动作通常会让团队第一次意识到，自己原来的准入条件里有多少是”形容词”。我在一个项目里做过统计，原本 42 条准入条件中，有 29 条无法被客观校验，占比 69%。
2. 第 3-6 周：定门的数量与决策输出
根据项目风险分档，确定每档的门数量、准入项数量、决策人范围。同时确认四种决策输出全部可用，特别是”暂停”和”终止”。
这一阶段最重要的产出是一份《阶段门定义表》，它应该能被直接翻译成系统配置，而不是一份供人阅读的说明文档。
3. 第 7-10 周：在系统里落地并做一次演练
选一到两个真实项目，把新的门配置跑一遍。重点验证三件事：准入条件能否被系统自动校验、带条件通过能否自动生成并阻塞后续、暂停期到期能否自动提醒。
演练期间一定要统计”Gate 前材料整理人天”这个指标。如果它没有明显下降，说明你只是把文档从 Word 换到了系统里，流程本身没有变化。
4. 第 11-12 周及以后：建立门的健康度看板
把前面提到的五个信号做成看板，每月回顾一次。这五个信号是：一次通过率、带条件通过占比、暂停/终止占比、条件项 30 天闭环率、Gate 评审时长。
不需要更多指标。阶段门的管理成本一旦超过它拦住错误所节省的成本，这套门就该重建了。
5. 你要带走的三件事
- 阶段门是决策系统，不是汇报仪式。它的成功标志是产生过真正的负向决策，而不是通过率保持漂亮。
- 准入条件必须能被系统校验。凡是需要人工判断”是否达标”的条目，都会在博弈中被稀释。
- 门后闭环比门本身更重要。带条件通过是最有价值的一类决策，也是最容易烂尾的一类，必须用系统阻塞来保证执行。
下一步，我建议你不要先改流程文档。先打开你们当前的项目管理系统，看看能不能对任意一个已完成的里程碑，用一条查询拉出它的全部准入证据。如果拉不出来，那么无论流程文档写得多完备，你的阶段门都还停留在 PPT 阶段。
把这一步做完，剩下的就是配置和坚持。阶段门没有那么多技巧，它考验的是一个组织愿不愿意在”事情还来得及的时候”说一句”停一下”。
常见问题解答（FAQ）
1. 阶段门评审到底该由谁来拍板，PMO在其中扮演什么角色？
我们公司刚成立PMO，老板让我把阶段门管起来，但真到评审会上，项目经理觉得应该由他决定，技术总监又觉得该他签字，我作为PMO夹在中间很尴尬，不知道到底谁说了算。
阶段门的决策权必须归属于有资源调配权的业务负责人，通常是项目发起人或其授权的 steering committee，PMO的角色是流程设计者、数据校验者和会议组织者，而不是最终拍板人。
可执行做法是：在项目启动时就用一页纸的‘阶段门决策矩阵’写清楚每个门禁的评审人、决策人、咨询人和知情者，由发起人签字确认。PMO负责在评审前72小时收集交付物、核对准入清单、标注风险项，评审中只呈现事实和差距，不替业务做判断。
判断依据是：如果PMO既组织评审又最终拍板，一旦项目失败，责任无法归属，阶段门就会退化成走流程。数据口径上，建议每个阶段门至少保留三项记录：准入检查表得分、评审纪要中的决策结论、未关闭风险的负责人和截止日。
2. 阶段门的准入清单应该包含哪些硬性指标，怎么避免变成形式主义？
我照着网上的模板做了一套准入清单，结果项目经理每次都是临时补文档，评审会开成了挑刺会，大家越来越抵触，我怀疑是不是清单本身就有问题。
准入清单要区分‘硬门槛’和‘软观察项’，硬门槛不超过5条，且必须是可客观验证的交付物或数据，软观察项用于讨论但不作为否决依据。常见硬门槛包括：上一阶段关键交付物已基线化并归档、核心风险已更新且高优先级风险有应对方案、下一阶段所需关键资源已确认或已进入采购流程、成本与进度偏差在预设阈值内。
避免形式主义的关键是让清单在阶段开始时就公开，而不是评审前才发，项目经理从第一天就知道要交什么。操作上，PMO可以在每个阶段启动会上逐条确认清单，并在阶段中期做一次预检，把问题提前暴露。判断依据是：如果某个检查项连续三个项目都轻松通过且从未触发讨论，就应该删掉或降级为观察项。
3. 阶段门评审会上，项目经理和业务方意见不一致时，PMO怎么推动形成可执行的结论？
上周的阶段门评审，项目经理说进度可控可以进入下一阶段，业务方却说关键需求还没验证不能放行，两边僵住了，会议开了三个小时没结论，我作为PMO不知道该怎么收场。
PMO的核心动作是把‘意见分歧’转化为‘条件与验证’的讨论，而不是在会议上强行投票。具体做法是：会前让双方各自提交一页纸的放行条件和担忧点，PMO提前比对差异，把分歧点聚焦到可验证的事实上，比如‘关键需求验证’到底缺哪份测试报告、由谁在什么时间完成。
评审会上，PMO引导达成‘带条件的放行’或‘有条件的不放行’：如果放行，必须列出待办项、负责人和截止日，并约定在下一个检查点复核；如果不放行，必须明确补齐什么、谁来补、什么时候再评。判断依据是：阶段门的目的不是二选一，而是让风险可见、责任到人。
数据口径上，建议记录每次评审的分歧点数量、带条件放行比例和条件关闭率，用于评估阶段门是否真正在控风险。
4. 阶段门通过后，下一阶段刚开始就发现重大风险，PMO应该怎么处理？
我们有个项目刚过阶段门两周，就发现技术方案有致命缺陷，如果推翻重来成本很高，项目经理希望继续走，但我觉得应该回头重新评审，不知道PMO在这种情况下的标准动作是什么。
阶段门通过不等于风险消失，PMO需要建立‘触发式回评’机制：当出现预设的触发条件时，自动启动一次轻量级阶段门回评。常见触发条件包括：关键技术指标未达标且无可行替代方案、成本偏差超过基线15%、核心资源流失、合规或安全事件。
操作步骤是：项目经理在发现风险后24小时内提交风险触发单，PMO在48小时内组织一次不超过90分钟的回评会，只聚焦三个问题，风险是否影响上一阶段的放行假设、是否需要退回上一阶段、如果继续走需要什么额外控制。判断依据是：回评不是追责，而是修正假设。
数据口径上，建议跟踪‘阶段门回评触发次数’和‘回评后项目走向’（继续、调整范围、暂停、终止），作为PMO成熟度的指标。
文章包含AI辅助创作：项目阶段如何做好阶段门？PMO实操方法与操作步骤，发布者：飞飞，转载请注明出处：https://worktile.com/solution-1/archives/326783
读者评论
带条件通过率 30%~50% 这个区间我有点存疑。我们这边这个比例不低，看着门是活的，但条件是拖到下一道门前补，最后几个门一起爆雷，30 天内闭环的不到一半。所以我更想知道分母怎么定，是只看当次决策分布，还是把未闭环的条件也计入门的有效性。否则高条件通过率只说明问题被推迟了。
做过一轮准入条件系统化，最大的阻力不是配置，是数据源。字段非空这类能校验，涉及成本口径、客户签约意愿就麻烦了，系统里没有可信数据，最后还是人工填，只是换了个地方填。证据等级的分级思路挺好，但 L4 在发布前基本拿不到，很容易变成又一个走形式的必填项。
作为一线项目经理说句实话，文章里‘喂’指标那段是常态。只要门的通过率跟团队考核挂钩，大家就会去猜评委看哪几个数。另外‘终止’这个选项实际很难用起来，因为拍板终止的往往就是当年立项拍板的人。流程再漂亮，决策权和责任不对齐，门还是那扇门，就是没人愿意关。