阶段门落地方案：产品经理开展项目阶段的协同管理案例解析

三年前我接手一个 11 人的跨职能团队，负责一款软硬一体的工业检测产品。上线前两个月，硬件已经小批量试产，嵌入式固件冻结在 V1.3，但云端平台的需求还在改。评审会上所有人都在说”没问题”，两周后客户现场发现检测精度对不上，返工成本 47 万元，交付延期 6 周。复盘时我们才意识到：问题不是出在能力上，而是出在阶段门（Stage-Gate）根本没有真正落地，我们只有”里程碑时间点”，没有”门的准入证据”和”门的决策规则”。

这篇文章不讲 Stage-Gate 的理论定义，那套东西 1986 年 Robert Cooper 就写完了，网上一搜一大把。我要讲的是：一个产品经理，怎么把阶段门从 PPT 上的五个方框，变成团队每天真正在跑的一套协同机制。中间哪些地方会塌，哪些地方值得较真，哪些地方较真反而会毁掉节奏。

一、核心结论：阶段门的成败 80% 取决于”门前的证据包”

先给结论，后面再展开论证。我把三年里参与过的 4 次阶段门改造（两次失败、一次半成功、一次成功）的关键差异，压缩成三条判断。

1. 阶段门不是审批流，而是”证据换资源”的兑换点

绝大多数团队把阶段门做成了审批流：提交 → 领导签字 → 进入下一阶段。这种做法的结果是可以预见的，签字变成形式，因为审批人没有能力在 30 分钟内验证一份 200 页的材料。

真正跑得动的阶段门，本质是一次资源兑换：团队拿出一组可验证的证据，换取下一阶段的预算、人力和时间承诺。证据不合格，兑换失败，团队要么补充证据，要么砍掉这个方向。这个视角一换，门的重心就从”谁签字”转移到”证据是什么、谁来验、验到什么程度”。

我见过最有效的一次改造，是把立项门的决策会从 2 小时压到 40 分钟。做法很朴素：会前 48 小时，所有评审人必须在一个共享文档里对 6 项证据逐条打勾或打叉，会上只讨论”有分歧的项”。光这一条，就把决策会效率提升了一倍以上。

2. 门的数量应该跟项目风险等级挂钩，而不是一刀切

我服务过的一家 300 人规模的制造企业，最初给所有项目都配了 6 道门：概念、立项、计划、开发、验证、发布。结果是小项目被流程压死，大项目又嫌门太少。后来我们改成三档配置：

• 轻量档（2 道门）：适用于需求明确、技术成熟、投入小于 50 万元的优化型项目
• 标准档（4 道门）：适用于新产品线、新客群、涉及外部供应商的项目
• 严格档（6-7 道门）：适用于强监管、硬件开模、涉及安全合规或单项目投入超过 500 万元的项目

改完之后，轻量档项目的平均交付周期从 11 周降到 7 周，而严格档项目的重大返工次数反而下降了。这个结果有点反常识：减少门，整体质量反而提升了。原因是流程负担下降后，团队不再把精力花在”怎么把材料写得像通过”，而是花在真正该做的事上。

3. 产品经理在阶段门里的角色是”证据编排者”，不是”材料撰写者”

这是我最想强调的一条，也是最容易被误解的一条。很多产品经理把自己做成了”文档工厂”：收集各部门材料、拼成一份 PPT、在评审会上讲。这种角色在阶段门体系里是没有价值的，因为 AI 和模板都能做。

有价值的做法是证据编排：你要提前知道每一道门需要什么证据、这些证据由谁产出、产出的前置条件是什么、如果证据缺失应该走补做流程还是直接降级决策。你在编排的是”证据的产生链条”，而不是”文档的排版”。

举个具体例子。立项门需要一份”目标客户付费意愿验证”，这个证据不可能在评审前一周临时补。它的前置条件是：至少完成 12 位目标客户的深访、其中 5 位愿意签署试用意向、试用意向里包含预算区间。产品经理要做的，是在概念阶段就把这条链条拆出来，挂到具体的人和时间点上。

二、背景与真实场景：一次 200 人组织的阶段门改造全过程

结论讲完了，现在讲这结论是怎么来的。我把 2023 年那次改造的完整过程还原出来，包括两次失败的尝试。这段过程比结论更有参考价值，因为大多数团队会先经历失败。

1. 改造前的样子：有里程碑，没有门

那是一家做工业检测设备的企业，研发加产品约 200 人，分 4 条产品线。改造前的状态是：项目计划里写着”3 月 15 日完成方案评审””6 月 30 日进入小批量试产”，但没有人定义过”什么算完成”。

实际情况是：3 月 15 日的评审会开了，会上大家说”基本可以”，然后就进入了下一阶段。等到 6 月发现方案有硬伤，已经花了 200 万元开模费。这类事情在两年里发生了 9 次，累计损失超过 800 万元。

更麻烦的是，每次复盘都得出同一个结论：”下次评审要更严格”，然后下一次依然一样。因为“更严格”不是一个可执行的指令，它没有办法被分解成动作。

2. 第一次失败：把阶段门做成了”文档检查”

第一次尝试，我们照搬了教科书：定义了 6 道门，每道门列出 8-12 项交付物，做了一张检查清单。执行三个月后崩溃，原因有三个。

第一，交付物清单变成了文档竞赛。团队为了”清单全绿”，把大量时间花在写文档上，一个概念阶段能产出 60 页材料，但里面的关键假设依然没有被验证。

第二，检查清单没有区分”必须有”和”最好有”。所有项权重一样，导致评审时没人知道该抓什么，最后变成逐项打勾，走完流程就算通过。

第三，也是最致命的：清单是静态的。项目情况变了，清单不变。有个项目在计划阶段发现关键技术路线不可行，但因为在整改前的清单里没有”技术路线可行性”这一项，重大风险被漏掉了，直到验证阶段才暴露。

3. 第二次半成功：引入证据分级，但工具拖了后腿

第二次我们做了两件事：把交付物改造成”证据”，并且给证据分了三级。

这套分级确实有效。改造后第二个季度，立项门的 Kill 率从 0 上升到 18%，也就是说，有 18% 的项目在花大钱之前被正确终止了。按当时的项目平均投入算，这一条大概省下了 300 万元。

但工具拖了后腿。我们当时用的是自研的表格加共享盘方案，证据分散在十几个目录里，评审人要翻五六份文件才能确认某项证据是否存在。更麻烦的是版本混乱，有一次评审用的是上一周的访谈纪要，导致结论偏差。这一阶段我们付出了大量的”人工找材料”成本，每次评审前的准备时间平均要 2-3 人天。

三、拆解常见误区：产品经理在阶段门里最容易踩的七个坑

这一节我按”危害程度”排序，从最致命的开始。每一条都来自我实际踩过或者看到别人踩过的场景。

1. 误区一：把阶段门当成”卡人”的工具

这是最普遍也最致命的误解。一旦产品经理在团队眼里成了”门口的守门员”，后续所有协同都会变成对抗，团队会花精力研究怎么”过门”，而不是怎么”做出好东西”。

正确的定位是：产品经理是门的共建者，不是门的执法者。你要做的是和团队一起定义”什么样算准备好了”，并且在准备过程中提供帮助。当团队主动来问你”这个证据够不够”的时候，门才算真正立住了。

我在第二次改造失败后做过一次匿名调研，团队对阶段门的第一印象里，”浪费时间”和”形式主义”加起来占了 61%。这个数字说明当时的门已经变成了负资产。后来我们花了两个季度才把认知扭过来，方法很简单：每次被 Kill 的项目，产品经理必须亲自参与复盘，并给出”如果重来一次，哪三个动作能避免这次 Kill”。

2. 误区二：门越多越安全

很多管理者有直觉：多一道门就多一层保险。实际数据完全相反。我们对比过同一家公司内 2 道门和 6 道门的两组项目，发现 6 道门组的重大缺陷遗漏率反而更高。

解释起来也不复杂。门越多，每道门的检查就越薄；每道门的时间压力都很大，评审人容易被”流程惯性”带走，反正后面还有门，这一关先过了再说。而 2 道门的组因为门少，每一道都被认真对待。

门的价值来自”密度×严格度”的乘积，而不是门的绝对数量。三道被严格执行的门，胜过六道走过场的门。

3. 误区三：把”交付物”当”证据”

这是一条最隐蔽的坑，因为它看起来非常合理。需求文档是交付物，但它不是证据。证据是”能改变决策判断的东西”。

我见过一份 80 页的市场分析报告，肉眼可见做得极其认真，但对”这个产品该不该做”这个决策的贡献几乎为零，因为它里面全是行业总量数据，没有一条指向目标客户的具体购买行为。

判断标准很简单，可以在评审时问一句：“如果这份材料的结论完全相反，我们的决策会改变吗？”如果答案是不会，那它就是交付物，不是证据。

4. 误区四：产品经理一个人扛整个门

常见的错误分工是：产品经理负责准备所有材料，其它角色在评审会上”配合一下”。这种分工必然失败，因为产品经理不可能替代研发验证技术可行性、替代财务验证成本模型、替代销售验证客户意愿。

正确的分工是：每一类证据都有明确的产出责任人，产品经理负责的是编排、校验和汇总，而不是代笔。落到实操上，就是在阶段门的定义里写清楚每条证据的 Owner 和截止时间，并且这个 Owner 是被本人确认过的，不是被安排的。

5. 误区五：用同一套门卡所有项目

这条前面已经提到，这里补充一个具体的判断方法。判断一个项目该配几道门，可以看三个维度：

1. 不可逆成本占比：一旦做错，需要推倒重来的投入占总投入的比例。硬件开模、产线改造、合规认证都属于高不可逆
2. 需求确定性：目标客户、使用场景、付费方式是否已经过验证
3. 技术成熟度：核心技术是复用现有能力，还是需要新研发

三个维度中有两个及以上处于高风险，就应该走严格档。全都在低风险，轻量档就足够。这个判断不需要精确打分，产品经理凭经验判断通常不会差太远，关键是要显式地做出这个判断，并记录理由。

6. 误区六：门的决策只有”通过”和”不通过”

只有二元决策的阶段门会逼着评审人往”通过”上靠，因为”不通过”的社会成本太高，项目组可能面临解散，负责人会背责任。于是大家默契地选择”带条件通过”，然后条件永远不被跟踪。

成熟的阶段门至少有四个决策选项：

• Go：证据齐备，按计划投入下一阶段资源
• Conditional Go：带条件通过，但条件必须写进下一阶段的准入清单，且指定验证时间点
• Hold：方向没问题，但外部条件（客户、供应链、法规）不成熟，暂缓并设定重新评估的触发条件
• Kill / Recycle：方向不成立，终止；或者把有价值的部分回收到概念池重新组合

Hold 和 Recycle 这两个选项的存在，是阶段门能否被团队接受的关键。因为有了它们，决策不再等于”判死刑”，评审人敢于说出真实判断，团队也不会为了保命而包装材料。

7. 误区七：门通过了就没人再看

默认所有人都记得。实际上不会。项目进入下一阶段后，上一阶段的假设就被遗忘了。等到出问题再回看，才发现当初通过是有前提的。

解决方案是假设台账：每道门通过时，把当时支撑决策的关键假设列出来，标注验证方式与验证时间，挂到后续阶段的工作项上。比如”假设目标客户愿意接受 8 万元的单价”，就要在验证门之前安排 5 家客户的报价测试。

四、专业判断逻辑：阶段门的三层决策结构

讲完坑，讲方法。我给团队做阶段门设计时，会用一套固定的三层结构来推演。这三层分别是准入证据、决策规则、退出条件。

1. 第一层：准入证据（Entry Criteria）

准入证据回答的问题是：”到达这道门之前，必须已经完成什么？”这里的关键是把证据写成可验证的命题，而不是可交付的文档名。

对比一下两种写法：

• 差的写法：”提交《市场需求文档》”，无法判断内容质量，只要交了就过
• 好的写法：”至少 12 位目标客户完成深访，其中 5 位确认存在该场景下的付费意愿，且能给出预算区间”，每个人都能判断是否满足

我通常建议每道门的 A 级证据不超过 5 条。超过 5 条，评审的注意力会被摊薄，反而抓不住重点。如果发现某道门需要 8 条 A 级证据才能决策，通常说明这道门承担了过多职责，应该拆成两道门。

2. 第二层：决策规则（Go / Kill / Hold / Recycle）

决策规则要回答的是：”证据满足到什么程度，对应哪个决策？”这里最容易被忽略的是权重差异，不是所有证据都同等重要。

我的做法是给每条 A 级证据标注”一票否决”或”加权项”。以一票否决为例，硬件类项目的”核心技术可行性验证”就属于此类：无论其他证据多漂亮，这一条不通过就不能 Go。

同时要提前约定决策机制。是全体一致，还是负责人拍板？我的经验是：证据评估阶段可以集体讨论，最终决策必须单人负责。集体决策的结果通常是”带条件通过”，因为没有人愿意为 Kill 承担责任。

3. 第三层：退出条件（Exit Criteria）

退出条件常被忽略，但它其实是阶段门能否形成闭环的关键。它回答的是：”进入下一阶段后，我们在什么情况下会重新回到这道门？”

常见的退出条件包括：成本偏差超过 20%、关键技术指标未达成、目标客户验证数量不足、供应链出现重大变化。这些条件一旦触发，项目自动回到上一道门重新评审。

我们在第四次改造里为每个项目加了 3-5 条退出条件，并且在项目管理平台里做了自动触发。有意思的是，触发率并不高，6 个月里只有 4 个项目触发，但团队反馈说知道有这条线存在，做事的分寸感明显不一样。

4. 门的密度与项目风险匹配模型

把前面这些压缩成一张配置表，实际使用时可以直接对照：

需要提醒的是，档位可以动态调整。一个轻量档项目如果在执行中发现技术风险上升，就应该升级到标准档并补做中间门。反过来，标准档项目如果验证远超预期，也可以合并后两道门加快节奏。这种动态调整要在决策记录里写清楚，否则会变成”随意跳门”。

五、案例与数据观察：用项目管理平台承载阶段门协同的实操

前面提到，第二次改造我们的瓶颈是工具：证据散落、版本混乱、评审准备耗人。第三次改造时我们引入了 PingCode。这里我不做产品推荐，只讲它在承载阶段门协同时的具体用法和真实效果，你可以据此判断自己的组织是否需要类似的工具支撑。

1. 选型判断：为什么最终落在私有化部署能力上

我们当时的选型约束有三条：数据必须留在内网（硬件图纸和客户名单不能出内网）、要能和现有研发流程对接、迁移成本要可控。

PingCode 主要服务中大型企业及 100 人以上组织，这一点和我们的规模是匹配的。它支持私有化部署，这是通过安全评审的前提条件，我们的信息安全部门不接受任何涉及客户图纸数据的 SaaS 方案。同时它支持从 Jira 平滑迁移，我们当时有 3 条产品线的历史数据在 Jira 上，累计 2 万多条工作项，迁移过程大约用了两周，主要由 IT 和产品运营同学完成。

从国产替代的角度看，它在私有化和迁移这两点上是少数能做到的选项之一。但我要强调的是，工具解决的是”证据可见性”问题，不解决”证据质量”问题。如果你门前的证据本身就是拍脑袋的，换成任何工具都不会变好。

2. 落地方法：用工作项类型映射阶段门

我们的映射策略是：

• 阶段门本身建为一个独立的史诗（Epic）类型，命名为”Gate 3 ， 验证门”，状态为待评审/通过/带条件通过/暂缓/终止
• 每条 A 级证据建为一个需求或任务，挂在对应门下面，明确 Owner 和截止时间
• 门的准入条件用子任务的完成状态自动汇总，A 级证据未全部完成时，门的状态不允许流转到”通过”
• 假设台账用自定义字段承载，包括假设内容、验证方式、验证时间点、当前状态

配置一个门的工作项结构大致如下：

Gate: 验证门 (Epic)
├── A级证据 (必须全部完成)

│ ├── 客户现场实测报告 (Owner: 硬件测试负责人, 截止: 8月12日)

│ ├── 第三方精度检测报告 (Owner: 质量工程师, 截止: 8月15日)

│ ├── 5家客户报价接受度测试 (Owner: 产品经理, 截止: 8月10日)

│ └── BOM成本核算表 v2 (Owner: 采购负责人, 截止: 8月8日)

├── B级证据 (缺失需标注风险敞口)

│ ├── 竞品同场景性能对比

│ └── 产线节拍模拟报告

├── 决策记录 (自定义字段)

│ ├── 决策结论: Conditional Go

│ ├── 决策人: 产品线负责人

│ ├── 附加条件: 精度指标需在9月5日前达到0.02mm

│ └── 退出条件: 成本偏差 > 20% 或 客户验证数量 └── 假设台账

├── 假设: 客户接受 8 万元单价 → 验证节点: 9月10日

└── 假设: 单台检测耗时 ≤ 45 秒 → 验证节点: 9月5日

这套结构最大的价值不是”管理”，而是让评审人可以在 10 分钟内看清项目的真实状态。以前需要翻五份文档，现在打开一个工作项就能看到所有证据的存在状态、负责人和截止时间，未完成的项会自动标红。

3. 数据观察：三个阶段的变化

我们用同一套口径记录了改造前、改造中、改造后三个阶段的数据。需要说明的是，这是单一组织的观察，样本量有限（涉及 42 个项目），不能直接外推到所有团队，但趋势是清晰的。

有两组数据值得单独说。第一，评审准备耗时的下降幅度最大（2.1 人天降到 0.6 人天），因为它直接消除了”找人问材料在哪”这类无效劳动。按 42 个项目、每个项目平均 4 道门计算，一个季度省下约 250 人天。

第二，假设台账的按时验证率从 34% 提升到 76%，这个指标比决策会时长更有价值。因为假设不被验证，意味着阶段门的决策基础在悄悄失效，等到问题暴露时代价已经很高。这个提升主要来自自动提醒机制，验证时间点到了，系统会自动创建任务并通知 Owner。

还有一个反向观察：上了工具后的头两个月，A 级证据齐备率一度下降。原因是以前”齐备”是靠人工判断的模糊标准，现在系统把每条证据都具象化了，很多以前被算作”已完成”的项被暴露出来其实没做。这个阵痛期大概持续了 6 周，之后就一路回升。

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

阶段门没有通用方案，落到具体组织要按规模和业务特性调整。这里按四种典型情况给出可以直接上手的动作。

1. 20-50 人团队：先做”证据清单”，不要做工具

这个规模的团队最忌讳的就是先上工具。人少，沟通路径短，很多事一两句话就能对齐，上工具反而增加负担。

建议动作：

1. 只设 2 道门：立项门和发布门。中间过程用周会同步即可
2. 为每道门写不超过 3 条 A 级证据，写在共享文档里，谁都能看到
3. 决策结论只记三件事：结论是什么、理由是什么、下一步做什么。不用做正式会议纪要
4. 把”假设台账”简化成一个表格，每次例会花 5 分钟过一遍

这套做法我在一个 26 人的团队里验证过，落地成本大约 3 天，不需要任何采购。等团队规模超过 80 人、或者同时并行项目超过 5 个，再考虑工具化。

2. 50-200 人团队：做证据分级 + 档位匹配

这个阶段的核心矛盾是：项目开始变多，产品经理的注意力不够用。必须靠机制而不是靠人盯。

建议动作：

1. 建立 A/B/C 三级证据体系，明确 A 级证据的判定标准
2. 建立风险档位表，每个项目在立项时显式选择档位并记录理由
3. 引入四选项决策（Go / Conditional Go / Hold / Kill），把 Hold 和 Recycle 用起来
4. 每季度做一次”门的复盘”：统计各道门的退回原因分布，看前三大原因是否可预防

工具选择上，这个规模通常处在临界点。如果项目并行数在 5-15 个之间，协作工具配合规范的文档结构就能撑住；如果超过 15 个，或者有跨产品线复用需求，就该考虑专业项目管理平台了。

3. 200 人以上或多产品线：把门做成可复用的组织资产

到了这个规模，”每个团队自己定门”会带来严重的协同问题，A 产品线的验证门和 B 产品线的验证门标准不同，导致跨产品线的资源调配没有依据。

建议动作：

1. 由产品委员会统一制定门的模板，包括证据条目、决策规则、退出条件
2. 各产品线可以裁剪，但裁剪必须在模板上显式标注，并说明理由
3. 阶段门的状态与证据进度必须在统一平台上可视化，支持跨产品线横向对比
4. 季度做一次跨产品线的门效率对比，找出异常高或异常低的团队，深入复盘

这正是一开始那家 300 人企业最需要的。它的四条产品线里，有一条的阶段门退回率是其它三条的两倍多。把数据拉齐之后发现，那条线的立项门几乎没有 A 级证据要求，全凭负责人的经验判断。这不是人的问题，是门的标准问题。

4. 硬件或强监管行业：把不可逆成本单独设为门

如果你的业务里存在”一旦投入就无法回收”的环节，比如开模、产线改造、注册检验、临床样本，那这些环节必须单独设门，且门的准入条件要格外严。

建议动作：

1. 先梳理出所有不可逆成本节点，标注每个节点的金额区间
2. 为每个不可逆节点设一道门，A 级证据必须包含”该节点失败的兜底方案”
3. 门的审批层级与不可逆金额挂钩，超过某个金额必须上升到更高层决策
4. 对合规认证类节点，提前把认证路径和所需时长写进证据清单

七、不同情况下的取舍

阶段门落地从来不是一个”做不做”的问题，而是一组”怎么换”的问题。下面四组取舍，我给的都是我在实际情况里做过的选择，以及选择的代价。

1. 门禁严格度 vs 交付速度

这是最根本的一组取舍。严格度高，返工少，但前期慢；严格度低，前期快，但中后期容易翻车。

我的判断依据是“错误的可逆性”。如果做错了可以低成本改回来（比如界面文案、运营活动配置），就该放开门禁换速度。如果做错了代价很高（开模、数据迁移、对外承诺的交付日期），就必须严格。

实际操作中，我会把这条判断落到一个具体问题上：“如果这个阶段出了错，我们能在两周内修正吗？”能，就放行；不能，就补证据。这个问题比抽象地讨论”要不要严格”有效得多。

2. 标准化 vs 灵活性

标准化让跨团队对比和资源调配成为可能，灵活性让团队能根据实际情况调整。两者本质上是矛盾的。

我的取舍是：标准化的对象是”证据类型和决策规则”，灵活的对象是”证据的具体形式和验证方法”。

也就是说，”立项门必须有目标客户付费意愿验证”这条必须标准化，所有项目都要做；但具体是用深访、是用问卷、还是用小规模付费测试，团队可以自己决定。这样一来，跨项目的数据是可比的，团队的发挥空间也保住了。

3. 工具治理 vs 团队自治

统一平台能带来可视化和自动化，但也会带来”所有团队必须按同一套结构填”的刚性。我见过一些团队为了规避这种刚性，把重要信息记在个人文档里，平台上的数据反而失真。

我的做法是分级强制：门的状态、A 级证据的完成状态、决策记录这三项必须在平台上；B 级证据、过程文档、会议纪要可以放在团队自己习惯的地方。这样既保住了管理视角的关键数据，又不至于让团队觉得被绑死。

需要提醒的是，分级强制的边界要写清楚并且被反复强调。我们当时有一个团队把”决策记录”也挪到了外部文档，理由是”平台字段填不下”，结果季度复盘时那条线的数据缺失，只能靠人工补。这种情况下要坚持要求：字段不够就改字段，不能改承载位置。

4. 自建 vs 采购

这是 100 人以上组织绕不过去的一个决策。三条判断线索供参考：

• 如果核心诉求是数据不出内网，就要优先看是否支持私有化部署的能力
• 如果已经有大量历史数据在别处，迁移成本可能会超过采购成本本身，要提前评估
• 如果阶段门的结构还在快速调整，先不要自建，自建系统改一次结构的成本远高于配置一个现成平台

我们当时的选择是采购而非自建，主要理由是第三条。阶段门的结构在改造过程中调整了 5 次，如果自建，每次调整都要排研发资源，实际上根本跑不起来。代价是接受平台已有的字段和流程约束，在某些细节上做了妥协，比如自定义字段的数量限制、工作项类型的可配置范围。

这个妥协我认为是值得的。因为阶段门落地最难的部分从来不是工具能力，而是能不能在结构反复调整的过程中保持执行不断档。任何能让你快速改结构的方案，都优于功能更强但改不动的方案。

八、把阶段门从方法变成习惯：三个具体的起点

写到这里，我想回到开头那个 47 万元返工的案例。那次事故之后，我们做的事情并不复杂，只是把三件事固定下来并且坚持了六个季度。这三件事，我认为是任何团队都可以立刻开始的。

1. 把”证据”这个词替换掉”交付物”

语言会塑造行为。当评审清单上写的是”交付物”时，团队想的是”交东西”；写的是”证据”时，团队想的是”证明什么”。

具体的做法是：把现有清单上的每一条，都改写成”能改变决策判断的命题”。改不动的那条，直接删掉。我们当时删掉了大约 40% 的条目，评审清单从 32 项降到了 19 项，但评审质量反而上升了。

2. 给每道门加一行”如果不通过，我们损失什么”

这一行字的作用是让评审人意识到决策的分量。如果这一行写的是”损失很小”，那这道门其实不该存在，这是一个非常好的删门依据。

我们用这个方法砍掉了两道门：一道是”UI 设计评审门”，因为即使设计有问题，改动成本也很低；另一道是”内部技术分享门”，因为它本质上不是决策点，而是一个分享活动，不该用门的形式承载。

3. 每个季度做一次门的”体检”

体检只看四个数字：各道门的退回率、退回原因 Top 3、假设台账按时验证率、门的平均决策时长。这四个数字能覆盖绝大部分问题。

如果某道门的退回率长期低于 5%，说明这道门要么标准太松，要么根本没必要设。如果某道门的退回率长期高于 40%，说明准入条件没有提前对齐，团队在评审时才第一次知道要求。

作者注：本文中的案例数据来自我参与的四个阶段门改造项目（涉及制造业、企业软件、工业检测三个领域），其中 2023，2024 年那次改造的完整数据样本为 42 个项目、跨 4 条产品线。涉及工具能力描述的部分，依据的是项目期间的实际使用记录。不同组织基线差异较大，建议把文中数据当作量级参考，而不是目标值。