阶段门怎么做？PMO数据分析：项目阶段从0到1

去年冬天，我帮一家做工业设备的客户复盘一条拖了 14 个月的新产品线。项目立项时批了 780 万预算，等到量产评审，账上实际花掉 1120 万，超支 43%，上市时间比计划晚了 5 个月。老板问我一句话：”每个阶段我们不是都开会评审了吗，为什么还会这样？”我把他们 9 次评审记录调出来一看，问题很清楚：9 次评审里 8 次是”汇报式通过”，只有 1 次真正做了否决动作，而那一次否决还是在预算超支已经发生之后。

这就是阶段门最典型的失效形态，门还在，但门已经不会关了。

阶段门（Stage-Gate）本身不是什么新概念，从上世纪 80 年代 Robert Cooper 提出到现在，几乎所有做研发管理、PMO 体系建设的人都能画出一张”阶段+关口”的流程图。但流程图好画，门难过。真正的难点不在”设几道门”，而在于：每一道门用什么数据判断该不该放行？谁有权力说不？说不之后资源怎么回流？这些问题答不上来，阶段门就会退化成”项目进度汇报会”的另一个名字。

这篇文章我不讲概念定义，讲的是我这几年在制造业、软件研发、硬件集成三类项目里，怎么把阶段门从”形式流程”做成”数据决策点”。核心会用 PMO 能拿到手的量化指标来拆解每一道门的判定逻辑，也会给出从 0 到 1 搭建阶段门体系的完整路径，包括我自己踩过的坑。

一、先给结论：阶段门不是流程，是一组带阈值的决策函数

如果只能记住一句话，我希望是这句：阶段门的本质不是”到了这个阶段要开会”，而是”到了这个阶段，一组预设指标的数值必须跨过阈值，否则资源不放行”。前者是日历事件，后者是决策函数。这两者的差别，就是阶段门有效和失效的分水岭。

我见过太多 PMO 把阶段门做成了日历：立项后第 30 天开概念评审，第 90 天开计划评审，第 180 天开开发评审。会议如期召开，PPT 如期汇报，结论如期”有条件通过”。一年下来，门开了 8 次，没有一个项目被真正挡在门外，超支率照样 40%。这种体系里，门是装饰品。

有效的阶段门有三个硬特征。第一，每道门有明确的量化准入指标和阈值，比如需求变更率超过 15% 不允许进入开发阶段。第二，门有明确的否决权和否决记录，一年下来如果否决率是 0，基本可以判断这个门失效了。第三，门和资源绑定，过门才放预算、才放人，而不是先给资源再补流程。

这里要先纠正一个认知：很多人把”否决率高”当成管理混乱的表现，觉得老是卡项目说明流程不顺畅。恰恰相反。一个从不否决项目的阶段门，等于没有门。我跟踪过的一个 PMO 做得比较好的团队，他们第一阶段门的否决率长期在 15%-20%，这些被否决的项目里有六成经过整改后在下一个评审窗口通过了，四成直接终止。终止看起来是损失，实际上是止损，一个在概念阶段花掉 30 万被砍掉的项目，比拖到开发阶段花掉 300 万才被砍掉，节省的是 10 倍成本。

二、背景与真实场景：阶段门为什么在大多数公司会失效

要理解阶段门为什么容易失效，得先看清楚它在真实组织里是怎么运行的。我总结了三种最常见的失效场景，每一种我都亲身经历过。

1. 场景一：门设在流程上，没设在资源上

最普遍的问题。公司画了一张漂亮的阶段门流程图，规定每个阶段结束要评审。但预算是一次性批的，人头是提前锁定的，项目经理在立项时就已经拿到了全周期的资源承诺。这种情况下，门开不开对项目没有任何实质影响，反正钱已经到手了。

我经历过一个真实案例：某团队立项批了全周期预算，结果项目做到开发阶段发现市场变了，早就该砍。但因为没有资源约束，团队继续做了 8 个月，最后交付了一个没人要的功能模块。如果预算是分阶段释放的，这个概念阶段的门其实早就该关了。

2. 场景二：门有流程，没有量化判定标准

第二种失效更隐蔽。公司确实设了门，也确实在评审，但评审标准是定性的。”技术方案是否成熟””市场需求是否明确””团队能力是否匹配”，这些表述听起来合理，实际执行时全靠评审人的主观感觉。结果就是，只要项目经理汇报得足够有感染力，门就过了。

定性的问题在于不可复现。同一个项目，换一个评审人，结论可能完全相反。更麻烦的是，一旦出现争议，没人能说清楚到底是哪条标准没达到。我在做 PMO 顾问时，第一件事就是把所有定性准入标准改写成可量化指标，哪怕一开始指标很粗糙，也比纯主观强。

3. 场景三：否决权虚置，没人敢说不

第三种失效是最要命的。门设了，标准也定了，但评审会上没人真的敢投否决票。原因很复杂：可能是否决了会得罪发起人，可能是否决了要承担项目延误的责任，也可能干脆是公司文化里就没有”说不”的习惯。

我曾经旁观过一场评审会，技术负责人在 PPT 上列了 7 个未解决的技术风险，个个都是红色的。但轮到决策时，主持会议的副总说了一句：”大家都是想让项目成功，有问题边做边解决，通过吧。”那一刻我就知道，这个阶段门以后都不会再起作用了。

这三种场景有个共同点：它们都不是执行层面的疏忽，而是设计层面的缺陷。流程画出来了，但没和资源绑定；标准写出来了，但没量化；评审组织起来了，但没给否决权。所以修阶段门，修的不是执行力，是设计。

三、拆解常见误区：关于阶段门的六个想当然

在动手搭体系之前，先把几个高频误区说清楚。这些误区我几乎在每一家客户那里都能碰到至少三四个，它们会直接导致阶段门建设跑偏方向。

1. 误区一：阶段越多，管控越细

很多 PMO 一上来就想设 8 道门、10 道门，觉得门越多控制越严密。事实正好相反。门太多会导致两个后果：一是评审成本爆炸，每个门都要组织会议、准备材料、走审批，项目经理的时间大量耗在汇报上；二是门和门之间间隔太短，数据还没来得及产生实质变化，评审就成了走过场。

我的经验是：中大型项目 4-5 道门是甜点区，小型项目 2-3 道就够。门的数量应该由”资源投入的阶段性跃迁点”决定，而不是由阶段名称的数量决定。每次资源要大幅增加之前，设一道门，这才是门存在的理由。

2. 误区二：所有项目用同一套门

用统一阶段门模板管理所有项目，是另一个常见错误。一个 20 人月的内部工具开发，和一个 800 人月的新产品研发，用同一套评审标准和评审深度，结果只能是小的被拖死、大的管不住。

合理的做法是按项目规模、风险等级、不确定性分档。我通常建议至少分三档：轻量档（人月成本低、技术成熟）、标准档（中等规模）、严控档（战略级或高技术不确定性）。三档的门数量、评审深度、准入标准阈值都不一样。

3. 误区三：把评审会等同于阶段门

这是我见过最普遍的误解。很多人以为”阶段门=开会评审”，所以只要会议开了，门就算过了。但会议只是门的执行形式，门真正的价值在于会前的数据准备和会后的资源动作。

如果一场阶段门评审会前没有量化数据包，会后没有明确的资源释放或回收动作，那这场会的价值约等于零。我见过太多”会开完了，纪要发了，然后什么都没变”的阶段门。判断一场门评审是否有效，看两点：会前有没有数据包，会后资源有没有变化。满足这两个条件，才算真过了门。

4. 误区四：准入标准越严越好

有些团队走了另一个极端，把准入标准定得极高，结果所有项目都卡在门口，或者干脆所有人都在造假数据来满足标准。阈值不是拍脑袋定的，而是从历史数据里反推出来的。

比如需求变更率这个指标，如果你把上限定在 5%，可能 90% 的项目都过不了；定在 30% 又太松。正确做法是统计过去 12 个月所有项目的需求变更率分布，取一个能区分”健康项目”和”问题项目”的值作为阈值。这个值一定是组织相关的，抄别人的没用。

5. 误区五：门只用来卡项目，不用来救项目

阶段门经常被理解成”筛子”，只负责淘汰。但实际上它的另一半功能是”诊断”，通过评审数据发现项目当前的真实健康度，然后决定是继续、整改还是终止。一个只能淘汰不能诊断的门，会让团队产生对抗心理，所有人都在想办法蒙过评审，而不是借助评审改进项目。

6. 误区六：上了工具就等于落阶段门

最后一个误区。很多公司买了项目管理工具，觉得把阶段门流程配置进去，就算落地了。工具只能保证流程被记录，不能保证门的判定有效。门有没有效，取决于阈值设计、数据质量、否决权这三件事，工具只是载体。

说到工具，顺带提一句我在中大型企业里观察到的实践。像 PingCode 这类主要服务中大型企业及 100 人以上组织的研发管理平台，它的价值不在于”帮你设门”，而在于让每道门所需的数据能够被自动采集和呈现。支持私有化部署、支持从 Jira 平滑迁移，这些特性对数据敏感或正处于工具替换期的团队比较友好。但工具选得再好，阈值和否决权还是要 PMO 自己设计。

四、专业判断逻辑：每道门到底用什么数据判定

这是全文最核心的部分。我把阶段门分五道（概念门、计划门、开发门、验证门、发布门），逐道拆解准入指标和阈值逻辑。需要说明的是，下面给出的阈值是参考区间，具体数值必须用你自己组织的历史数据校准。

1. 第一道门：概念门，判断”值不值得投入研究”

概念门是整个阶段门体系里最关键也最容易被忽视的门。它决定的是要不要批准一个想法进入正式探索。这道门最大的问题是”信息最少，但决策影响最大”，因为此时什么都没有，全靠判断。

我在这道门上加的第一个硬指标是目标市场规模与预期营收的比值。经验阈值是：预期年营收至少要达到研发投入的 5 倍，才值得进入下一阶段。这个比值低意味着即使项目成功，回报也不足以覆盖机会成本。

第二个指标是战略契合度，这个可以量化。把公司年度战略拆成若干方向，每个方向打权重，项目对每个方向的贡献度打分，最后加权求和，低于某个分数不立项。这样就把”感觉这个项目重要”变成了可比较的分数。

第三个指标是初步可行性证据。不是要完整的可行性报告，而是要证明关键假设至少有一个可信的支撑点：要么有客户明确表达了购买意向，要么有技术原型验证了核心难点，要么有竞品数据证明这个市场真实存在。三者有其一即可。

2. 第二道门：计划门，判断”方案是否足够清晰”

计划门要回答的是：这个项目的范围、进度、资源、风险是不是已经清楚到了一定程度？这道门如果放水，后面所有门的质量都会崩塌，因为范围不清的项目必然在开发阶段疯狂变更。

主指标是需求基线冻结率。我通常要求进入开发前，至少 85% 的需求已经明确并有验收标准。剩下 15% 允许是待明确的探索性需求，但不能是关键路径上的。这个指标能有效防止”边做边想”。

次要指标是关键路径识别完整度和资源到位承诺率。前者看进度计划里有没有识别出关键路径和浮动时间，后者看承诺投入的人力和实际能投入的人力之间的匹配度。如果计划里写着需要 5 个高级工程师，但实际只能抽出 2 个，这道门就不该过。

3. 第三道门：开发门，判断”项目是否还在可控范围”

开发阶段的门最容易变成形式。因为这个阶段项目”正在进行中”，大家默认它就该继续。但恰恰是这个阶段，项目最容易悄悄跑偏。

核心指标是需求变更率。统计从开发启动到当前的需求变更数量占总需求数的比例。我的经验阈值是 15%，超过这个值说明前期理解不够，或者外部环境发生了重大变化，需要重新评估。变更率不是越低越好，完全不变更可能意味着对市场反应迟钝，但超过 15% 就必须触发复审。

第二个指标是进度偏差率，用挣值管理里的 SV 或 SPI 都行。关键是设置预警线和熔断线：偏差超过 10% 触发预警，超过 20% 触发阶段门复审。这个双线机制比单一阈值更实用，因为单一阈值容易导致要么不管、要么一刀切。

4. 第四道门：验证门，判断”质量是否真的达标”

验证门的判定核心是质量趋势，不是质量快照。一个缺陷数还很多但收敛很快的项目，比缺陷数少但收敛停滞的项目更健康。

主指标是缺陷收敛率，看每周新发现缺陷数和修复缺陷数的差值变化。健康的项目应该是发现数持续下降、修复数大于发现数。如果连续两周发现数不降，说明测试覆盖不充分或者产品本身问题严重。

辅助指标是测试用例通过率和关键性能指标达标率。前者看功能质量，后者看非功能质量。这两者都要设最低门槛，比如核心用例通过率不低于 98%。

5. 第五道门：发布门，判断”能不能交付”

发布门是最后一道防线，也是唯一一道应该”零容忍”的门。因为前面所有的判断失误，到这里如果还放水，就会直接变成客户投诉和商业损失。

主指标是遗留严重缺陷数，这个必须是 0。严重缺陷的定义要提前明确，通常包括导致数据丢失、系统崩溃、安全漏洞的缺陷。次要缺陷可以带条件放行，但必须记录并安排修复计划。

第二个指标是发布回滚预案完备度。不是所有项目都要回滚预案，但涉及关键业务系统的必须要有。判定标准是：回滚方案是否经过演练或验证。纸面上的预案不算数。

五、具体案例：一个 100 人以上研发组织的阶段门落地过程

讲完逻辑，讲一个我实际参与过的案例，这样你能看到这套东西在真实组织里是怎么落地的，以及哪里会卡住。

1. 起点：一个”有门等于没门”的现状

这家公司是某细分行业的头部厂商，研发团队 200 多人，分 6 个产品线。他们有阶段门流程，纸质文档写了整整 12 页，规定了 7 道门和每道门的评审要求。但实际执行下来，一年 40 多个项目，没有一个是真正被卡在门外的，超支率 38%，平均延期 72 天。

我先做的事是数据诊断。把他们过去一年的项目数据拉出来，逐项看每道门是否留下了可量化的判定记录。结果是：7 道门里只有 2 道留下了量化记录，其余 5 道全是定性结论。这就是问题的根源。

2. 改造第一步：砍门 + 量化

第一步不是加东西，是砍。我把 7 道门砍到 5 道，去掉了两道间隔过近、数据不足以发生变化的门。同时把保留的 5 道门全部改写成量化准入标准，每道门配一个”数据包模板”，规定了必须提供哪些指标、什么口径、由谁提供。

这一步最大的阻力不是技术，是习惯。项目经理习惯了用 PPT 讲故事，现在要提供结构化数据包，一开始很多人不适应。我们的做法是先做一个数据包样例，公开演示一场评审，让大家看到数据包反而让评审更快，以前一场评审要 3 小时，用数据包后 80 分钟就结束了，因为不用再听冗长的背景介绍。

3. 改造第二步：把门和资源绑定

第二步是动预算。原来的预算是立项时一次性批的，改成分阶段释放：概念门通过放 10%，计划门通过放 25%，开发门通过放 40%，发布门通过放剩下的 25%。这个改动一落地，阶段门的严肃性立刻上来了。因为项目组自己就紧张了，过不了门，下一阶段的资源就拿不到。

这一步的关键是财务要配合。如果预算流程不支持分阶段释放，门和资源的绑定就落不了地。我在这家公司花了两个月才和财务对齐这个流程。如果你们公司的财务流程比较刚性，一个过渡方案是先不动预算，但把人头释放权和门绑定，门没过，下一阶段的人员投入不批。

4. 改造第三步：建立否决权机制

第三步是设计否决权。原来的决策是”集体讨论后由副总拍板”，看起来民主实际没人负责。我们改成明确单一决策人制：每道门有一个指定的门主（Gate Keeper），门主对这道门的放行决定负全责，并且必须留下书面判定依据。

同时设定了一条规则：如果门主放行的项目在下一阶段出现重大超支或失败，门主要参与复盘说明决策依据。这条规则不是为了追责，是为了让门主在放行时认真对待数据。放开这条后，第一季度的否决率从 0 上升到 22%，但同期项目质量明显改善。

5. 改造结果与遗留问题

改造一年后，这家公司的阶段门体系基本成型。超支率从 38% 降到 11%，平均延期从 72 天降到 23 天，评审耗时反而缩短了 55%。这些数字对公司高层有说服力，但我想强调的是遗留问题。

遗留问题有两个。第一，数据质量仍然依赖人工填报，有些项目组会为了过门而”优化”数据，尤其是需求变更率这种指标。后来我们增加了一个交叉验证机制：变更率不能只看项目管理工具里的记录，还要对比版本库的实际提交量和需求文档的修订历史。第二，中小项目仍然觉得流程重，因为 5 道门对 30 人月的项目确实偏重。这部分后来单独做了轻量流程。

从这个案例里，我最大的体会是：阶段门落地不是设计问题，是组织习惯问题。设计一个合理的准入指标，一周就能做完；但让一个习惯用 PPT 汇报的组织转向用数据决策，花了整整一年。

六、从 0 到 1 搭建阶段门体系的具体步骤

如果你所在的团队现在完全没有阶段门，或者有一个形同虚设的阶段门，下面这套步骤可以直接用。我把它拆成 6 步，按顺序做。

1. 第一步：盘点历史项目数据，找基线

在设任何阈值之前，先把过去 12-24 个月的项目数据拉出来。需要的数据包括：每个项目的预算、实际成本、计划周期、实际周期、各阶段的需求变更数量、缺陷数据、资源投入。如果数据不全，那就从能拿到的部分开始。

这一步的目的是算基线。比如你算出过去项目的平均需求变更率是 22%，超支率中位数是 15%，那么你的阈值就要围绕这些数字设计，而不是照抄某个理论的 10%。

2. 第二步：确定门的数量和位置

基于第一步的基线，确定设几道门。原则是：只在资源发生阶段性跃迁的地方设门。每个阶段的资源投入如果有明显的量级变化，那里就值得设一道门。一般 4-5 道，取决于项目复杂度和组织成熟度。

门设好后，给每道门写清楚：门的目标是什么（是筛选还是诊断）、准入指标有哪些、阈值是多少、谁来评审、谁有否决权。

3. 第三步：设计数据包模板

这是最容易被跳过但最重要的一步。每道门设计一个标准化的数据包模板，规定评审时必须提供的数据。模板要包含：指标名称、计算口径、数据来源、责任人、目标值。

举个例子，开发门的数据包模板可以是：

开发门数据包
├─ 需求基线：总需求数 128，已冻结 112（冻结率 87.5%）

├─ 需求变更：新增 14，删除 3，修改 9，变更率 20.3% ⚠️超阈值

├─ 进度状态：计划完成 45%，实际完成 38%，偏差 -15.5% ⚠️预警

├─ 缺陷情况：累计发现 43，已修复 31，未修复 12

├─ 资源投入：承诺 8人，实际 7人，到位率 87.5%

└─ 风险评估：3 项中风险，1 项高风险（第三方接口延迟）

有了这个模板，项目经理准备评审时有据可依，评审人判断时有数可看，会后复盘时有档可查。

4. 第四步：绑定资源释放机制

这一步需要和财务、人力部门协同。核心是让资源释放和门挂钩：门通过才释放下一阶段资源，门不通过则资源冻结或回收。如果一次性批预算的流程改不动，退一步的做法是把”人力资源投入审批”和门绑定。

5. 第五步：明确决策人与否决权

为每道门指定一个门主，明确门主有否决权，也承担相应的决策责任。门主人选应该是有专业判断能力的中层，而不是纯管理岗。同时建立”放行后追溯”机制，让门主在放行时更加审慎。

6. 第六步：跑通一个项目，再推广

不要一开始就全公司推广。选一个中等复杂度、团队配合度高的项目做试点，跑通一轮完整的阶段门流程，把遇到的坑记下来。试点成功后，用这个项目的真实数据做样板，向其他项目组推广。推广时最容易遇到的阻力是”我们项目特殊”，应对方法是把流程分档，给不同类型项目提供差异化的门配置。

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

阶段门没有万能方案，不同规模、不同成熟度的组织应该采取不同的路径。下面按四种典型情况给建议。

1. 情况一：完全没有阶段门，第一次建

建议从最精简的版本起步，只设 3 道门：立项门、开发前门、发布门。每道门配 2-3 个量化指标就够，先跑起来。关键是让团队先经历”门会真的关”这件事，建立对门的敬畏感，然后再逐步细化。

起步阶段最大的风险是设计得太复杂导致无人执行。宁可先用一个粗糙但能跑的系统，也不要设计一个完美但推不动的系统。

2. 情况二：有阶段门但形同虚设

这种情况不需要重建，需要的是给现有的门”通电”。优先做两件事：一是给每道门补上量化准入标准，把定性描述全部改掉；二是把资源释放和门绑定。这两件事做完，门通常就活了。

如果做完这两件门还是关不上，那问题在决策机制上，需要动否决权设计。可以考虑引入独立于项目组的门主，或者建立放行追溯机制。

3. 情况三：组织规模大、项目类型多

100 人以上的研发组织，项目类型往往差异很大，单一流程必然出问题。这时应该建立分档的门体系，比如轻量档、标准档、严控档，每档的门数量、准入指标、评审深度都不同。分档的依据可以是项目预算、技术不确定性、业务影响范围等。

这类组织在工具层面的需求也更明确。像前文提到的 PingCode 这类平台，支持私有化部署和从 Jira 平滑迁移，对需要数据自主可控、又正在做工具国产化替换的中大型组织有一定适配性。不过工具只是让数据采集和呈现自动化，门怎么设、阈值怎么定，仍然是 PMO 自己的判断活。

4. 情况四：处于敏捷转型中，担心阶段门和敏捷冲突

这是很多团队的真实困惑：敏捷强调快速迭代，阶段门强调阶段评审，两者是不是矛盾？我的判断是不矛盾，但需要重新设计。敏捷场景下的阶段门应该”门轻、频次低、指标偏结果”，比如只在重大投资决策点和发布点设门，指标聚焦在价值验证和用户反馈上，而不是需求文档的完备度。

Scrum 里的 Sprint Review 和阶段门不是一回事。前者是团队内部的迭代检视，后者是投资方对资源继续投入的决策点。两者可以共存，只要不把阶段门的重流程强加到每个迭代上。

八、不同情况下的取舍

做阶段门必然要做取舍，因为管控和灵活本身就是一对矛盾。以下是我认为最需要想清楚的几组取舍。

1. 取舍一：管控力度 vs 执行效率

门越多、门槛越严，管控越强，但执行效率越低，团队越容易产生对抗情绪。这个取舍没有标准答案，取决于你的项目失败成本有多高。如果项目失败成本极高（比如涉及安全、合规、巨额投入），那就应该偏向管控；如果是快速试错型业务，就应该偏向效率。

我自己的做法是分层处理：核心项目严控，探索项目轻控。不要用一套标准管所有项目。

2. 取舍二：数据完备性 vs 决策时效

理想情况下，每道门都应该有完备的数据支撑。但现实中，等所有数据都齐了，市场窗口可能都过了。这时就要做取舍：哪些数据是必须的，哪些是可以用估算替代的。

我的原则是关键指标的精度不能妥协，辅助指标可以接受估算。比如发布门的严重缺陷数，必须精确到确认为 0；但市场预测这类指标，用合理区间的估算完全可接受。

3. 取舍三：统一标准 vs 因项目而异

统一标准便于横向比较和统一管理，但因项目而异更贴合实际。我的折中方案是：门的框架统一，阈值分档。也就是说，所有项目都走同样的门流程，但每道门的阈值根据项目档位不同而调整。

这样既保证了流程的一致性，又给了差异化的空间。执行时也比较容易沟通，不是”你这个项目特殊所以不用过门”，而是”你这个项目适用轻量档的阈值”。

4. 取舍四：工具自动化 vs 人工判断

工具能自动化采集数据、自动计算指标、自动预警阈值超标，效率很高。但工具不能替代人的判断，尤其是涉及战略方向、技术路线这类需要综合判断的决策。

合理的分工是：工具负责”数据采集、指标计算、阈值预警”，人负责”综合判断、权衡取舍、最终决策”。把工具当决策的输入，而不是决策本身。

九、几个来自一线的经验补充

最后补充几条零散但实用的经验，这些都是我在实际项目里踩出来的。

1. 经验一：第一道门的否决率应该最高

五道门里，概念门的否决率理论上应该是最高的，因为这是筛选成本最低的时机。如果你的数据显示否决都集中在后期门，说明前面的门在放水。我观察过的健康体系里，概念门否决率往往能到 30%-40%，而发布门否决率接近 0（因为不合格的根本走不到发布门）。

2. 经验二：门的判定要留”整改通道”

不是所有不达标都要直接否决。设计一个”有条件通过+限期整改”的中间状态很有必要。比如某项目需求变更率 18%，超过 15% 的阈值但没到熔断线，可以判为”有条件通过”，要求两周内完成范围重新确认，否则转为否决。这个中间状态能避免一刀切造成的过度僵化。

3. 经验三：定期回顾阈值本身

阈值不是定下来就不变的。每半年或每年应该回顾一次：现有的阈值是否还能区分健康项目和问题项目？如果某个指标长期 90% 的项目都超标，可能是阈值定错了，而不是项目都变差了。阈值本身也需要迭代。

4. 经验四：小心指标被博弈

只要指标和资源挂钩，就会出现博弈行为。需求变更率被博弈的方式是”不记录变更”，把变更偷偷做掉。应对方法不是加强监管，而是设计交叉验证，比如对比需求文档版本和代码提交记录。指标设计时要先想清楚：这个指标可以被怎么绕过？

5. 经验五：给门主做培训

门主的判断质量直接决定门的价值。但很多公司指定了门主就不管了。我建议对门主做针对性培训，内容包括各类指标的含义、常见的误导性数据、如何提问、如何识别汇报中的水分。一个有经验的门主，能把门的有效性提升一个档次。

回到文章开头那个 14 个月超支 43% 的项目。如果当时他们有一套带量化阈值的阶段门，在需求变更率达到 30% 的那个节点就该触发复审，而不是等到量产评审才发现问题。阶段门真正的价值，不是它看起来有多规范，而是在项目要跑偏的早期就把它拦住，越早拦，成本越低。

下一步我建议你先做一件事：把过去半年到一年的项目数据翻出来，算三个基线，平均超支率、平均需求变更率、缺陷收敛速度。有了这三个数，你才有力气去设计第一道门。不要急着画流程图，先让数据说话。