阶段门实操方法：研发团队提升项目阶段效率的实操方法方法与模板

我在一家 300 人规模的软硬件混合研发组织里推过三轮阶段门（Stage-Gate），前两轮都失败了，而且失败方式恰好是两个极端。第一轮我们设了 5 个门，每个门要求提交 12 份材料，结果项目组把八成精力花在”准备评审”上，Gate 会议变成了 PPT 朗读会；第二轮我痛下决心把门砍到 2 个，结果又变成了橡皮图章，一个明显该砍掉的项目在 20 分钟内全票通过。

第三轮我们才想明白：阶段门失效，几乎从来不是因为”门的数量设得不对”，而是因为门的决策权、证据标准和节奏这三件事没有对齐。这篇文章我把第三轮用过的完整方法、可复用模板、自动化规则和踩过的坑一次写出来，也包括我们最后砍掉第 4 个门的真实理由。

一、先给结论：阶段门的效率来自”决策密度”，不是”流程完整度”

如果你只有五分钟，下面四条是我用三轮实践换来的核心判断。它们和大多数流程教材写的顺序是反的。

1. 阶段门调节的是”不确定性”，不是”进度”

绝大多数团队把阶段门当成进度检查点，于是必然演化成”延期说明会”。正确的定位是：每一个门回答的是同一个问题，到这个时间点，我们对这件事的不确定性是否已经降低到可以继续投钱的程度。

进度是结果，不是门的输入。一旦你把门的输入定义成”进度完成率”，项目组就会本能地报喜不报忧，门的决策质量立刻归零。我们第三轮把所有门的输入改成”不确定性消减证据”，例如关键技术风险关闭数、目标用户验证样本量、单位成本实测值，会议的气场当天就变了。

2. 门的价值由”否决率”衡量，而不是”通过率”

一个否决率为 0 的门，等于没有门。我跟踪过 6 个研发团队共 47 个项目的 Gate 记录，否决率（含 Kill、Hold、Recycle）长期低于 5% 的门，其后续项目的返工率反而比没有门的团队高出 11 个百分点，因为它给了团队”我们已经评审过了”的虚假安全感。

健康的否决率不是越高越好。我的经验区间是 15%~30%：低于 15% 说明门太软，高于 30% 说明入口太松或者证据标准被临时提高了。

3. 门的效率瓶颈在会前准备，不在会议本身

我们统计过 120 场 Gate 评审的时间去向，发现改造前只有 10% 的会议时间用于真正的决策讨论，45% 用于复述材料里已经写过的内容。也就是说，你砍会议时长没用，要砍的是”会上才能看到信息”这件事。

4. 门必须落在工作流里，而不是落在 Excel 和邮件里

这是我最晚才想明白的一条。只要门的证据、决策、行动项分散在 Excel、邮件和会议纪要三个地方，你就永远拿不到门的历史数据，也就永远无法优化门。第三轮我们把门做成了项目管理平台里的一类工作项，所有门的输入输出都变成结构化字段，这才第一次能算出门的平均决策周期、驳回原因分布和证据准备人天。

二、背景与真实场景：门是怎么一步步变成”高级周报”的

先说我观察到的三个真实场景，它们几乎出现在每一个 100 人以上的研发组织里，只是程度不同。

1. 场景一：门退化成了”升级版周报”

典型症状是：Gate 会议的第一页 PPT 是”本阶段完成情况”，第二页是”下阶段计划”，第三页是”风险与求助”。项目组讲 40 分钟，评委问 10 分钟，最后主持人问”大家有意见吗”，没有意见，通过。

这种会议的本质问题是信息在会前没有抵达决策人。如果评委是在会上第一次看到这些内容，他不可能在 10 分钟内做出”继续投 200 万还是立刻停止”的判断，于是只能选择最安全的选项，同意。

2. 场景二：只有 Go，没有 Kill

我做过一次很粗暴的统计：把某事业部连续 14 个月的 62 次 Gate 决策记录拉出来，只有 3 次不是 Go，而且这 3 次都是”延期 Go”。也就是说，这个组织花了 62 场会议、大约 400 个人时的成本，只产出了 3 个和”默认继续”不同的结论。

更严重的是，这 62 个项目里有 9 个在后续 6 个月内被无声无息地停掉了，它们没有死在门前，而是死在了资源争夺里。没有 Kill 机制的组织，Kill 不会消失，只会以更贵的方式发生：浪费的不是评审时间，而是那 9 个项目各自消耗的几个月人力和机会成本。

3. 场景三：把硬件行业的门直接搬到软件迭代上

阶段门发源于硬件和制造业，那里的门天然是”重”的：模具开下去就是几十万，所以必须在开模前设一道硬门。但很多软件团队照抄了这套结构，设了 5~7 个门，每个门要求完整的需求文档、设计文档、测试报告。

问题是，软件的一个迭代可能只有两周，一个门就要开一周，门本身成了最大的交付瓶颈。我见过最极端的案例是：一个 6 人小组做内部工具，被要求走完 4 个门，从立项到上线用了 4 个月，而实际编码时间是 3 周。

4. 一组我跟踪 6 个月的数据观察

从 2024 年下半年开始，我跟踪了 6 个研发团队（规模 40~320 人）在引入阶段门前后各 3 个月的 Gate 决策等待时间。这里的”决策等待时间”定义为：从证据包提交完整到拿到正式决策结论之间的自然日。

一个很反直觉的发现是：决策等待时间和证据包完整度呈倒 U 型关系。证据包完整度低于 60% 时，等待时间长，因为评委反复追问；完整度 60%~85% 时等待时间最短；完整度超过 85% 后，等待时间反而回升，因为项目组把大量时间花在”把文档做漂亮”上，而这些时间并没有降低不确定性。

三、拆解五个常见误区：你以为在控风险，其实在制造风险

下面五个误区，我在不同团队里都见过，而且它们经常同时出现。我按”造成的返工人天”从高到低排列。

1. 误区一：把 Gate 当作里程碑

里程碑是”我们计划在几月几日完成什么”，Gate 是”我们要不要继续投入”。前者是时间管理，后者是投资决策。当两者混在一起，就会出现”为了按时过门而凑证据”的行为。

我见过最典型的操作是：项目组提前一周把测试报告写好了，然后倒推出测试时间。这种门过了比不过更危险，因为它给了一个错误的确定性信号。

2. 误区二：把”文档齐全”当作通过标准

“文档已提交”是一个可以轻易造假的通过标准。真正难以造假的通过标准长这样：目标场景下 30 个真实用户的首次任务完成率 ≥ 70%。

区别在于：前者考核的是项目组的写作能力，后者考核的是产品的真实状态。凡是能被”写出来”的标准，都会被写成最好的样子；凡是必须”跑出来”的标准，才会倒逼真实工作。

3. 误区三：所有项目共用一套门

一个合规改造项目和一个探索性预研项目，风险结构完全不同。前者风险在”做错”，需要重证据、重评审；后者风险在”做太慢”，需要快验证、快止损。

用同一套门的结果是：合规项目嫌门太松，预研项目嫌门太重。我们第三轮做的第一件事，就是按不确定性和不可逆成本两个维度，把项目分成四类，每类走不同重量的门。

4. 误区四：评审委员会越大越权威

超过 7 个人的评审会，基本不会产生真正的反对意见。原因很简单：在一个 15 人的会议室里提出”我建议砍掉这个项目”，是一件社交成本极高的事。

我的建议是决策人不超过 5 个，且必须有一个人有权单独行使 Kill。其他人可以列席提供专业意见，但不参与表决。

5. 误区五：门只管到发布为止

发布之后的不确定性通常更大：真实用户行为、单位成本、运维复杂度、合规风险，都要在上线后才能验证。如果门在发布日就结束了，你会失去最有价值的一次复盘机会。

我们现在的做法是在发布后 30~90 天设一个轻量级的”效果门”，只回答三个问题：核心指标是否达成、单位经济模型是否成立、是否值得扩大投入。

四、专业判断逻辑：怎么设计一个”能杀死项目”的门

这一节是全篇最实操的部分。我把它压成四个设计要素、五种出口动作、一套阈值写法和一个变档机制。

1. 门的四要素：入口条件、证据包、决策人、出口动作

任何一个门，如果这四件事没有在会前定义清楚，它就一定会退化成汇报会。我建议把这四要素直接写进平台的工作项模板里，而不是写在流程文档里。

• 入口条件：什么状态下这个项目才有资格进入评审。例如”关键技术风险已关闭 ≥ 3 项””目标用户验证样本 ≥ 30 人”。
• 证据包：不是文档清单，而是可验证的数据与产物链接。每一条证据都要能回答”它降低了哪个不确定性”。
• 决策人：明确到人名，不超过 5 人，其中至少 1 人拥有单方面 Kill 权。
• 出口动作：五种之一，并且每一种都必须绑定后续动作和时间点。

2. 五种出口动作，而不是两种

大部分团队只有”通过”和”不通过”两种结果，这是否决率低的根本原因，因为”不通过”意味着否定团队几个月的工作，社交成本太高。把它拆成五种，决策就会变得容易得多。

1. Go：按原计划进入下一阶段。
2. Conditional Go（带条件通过）：通过，但必须在下个门之前关闭指定风险项，未关闭则自动降级为 Hold。
3. Recycle（回收）：方向对但证据不足，退回本阶段补证据，通常给 2~4 周。
4. Hold（暂停）：暂不投入，但保留资源占位，等待外部条件（如供应链、政策）变化。
5. Kill（终止）：彻底停止投入，团队解散或转岗，并归档经验。

关键在于：Recycle 和 Hold 的存在，让”否决”不再等于”否定人”。我们引入这两种动作后，非 Go 决策的占比从 6% 上升到 27%，而团队对评审会的抵触情绪明显下降，因为它不再是一场”生死审判”。

3. 通过标准怎么写才算”可测量”

写通过标准有一个很好用的句式模板：在【场景/样本】下，【指标】达到【阈值】，且【反例条件】不成立。三要素缺一不可，尤其是反例条件。

举几个我自己用过的例子：

• 在真实生产环境的 7 天压测下，P95 响应时间 ≤ 200ms，且无一次超时熔断触发。
• 在 30 名目标用户的任务测试中，首次完成率 ≥ 70%，且无人需要口头引导。
• 在单条产线的试产中，单位工时成本 ≤ 预算值 110%，且不良率 ≤ 2%。

注意每个标准都有明确的样本量和阈值，并且都有一个”且”字后面的反例条件。没有反例条件的标准，等于没有上限，团队总能找到对它有利的解读方式。

4. 门与门之间的节奏怎么定

节奏是阶段门设计里最被忽视的一环。我见过的最常见的错误是”按月设门”，因为这样好排会议。正确的做法是按不确定性消减的自然周期设门。

经验值是这样：早期阶段（概念、可行性）的门间隔 2~4 周，因为不确定性最高、单位时间信息量最大；中期（开发、验证）间隔 4~8 周；后期（发布、规模化）间隔 8~12 周。门太密会导致准备成本压过决策收益，门太疏会导致错误方向的投入无法及时止损。

5. 用风险等级给阶段门做”变档”

不要追求一套门适配所有项目。我们用两个维度分档：不可逆成本（做错了要花多少钱才能回头）和技术/市场不确定性（关键假设有多少还没验证）。

这张表最大的价值不是”照抄”，而是让团队在立项时就有意识地回答：我们这件事，做错了能回头吗？如果答案是”很难回头”，那就该配更重的门；如果能随时回头，配一个轻门就够了。

五、案例：一个 300 人研发组织 90 天的阶段门改造

下面这个案例是我亲自参与的。背景是：一家做智能硬件的公司，研发人员约 300 人，分 5 个产品线，此前用某项目管理工具管理需求和任务，但阶段门评审完全靠线下会议加 Excel 记录。

1. 改造前的基线数据

我们先花两周时间把过去 6 个月的 23 次 Gate 评审记录整理出来，得到了一组让自己都吃惊的基线数据。

• 23 次评审中，非 Go 决策只有 1 次（4.3%）。
• 从证据包提交到拿到决策结论，平均 18.4 个自然日。
• 证据包准备平均耗时 13.6 人天。
• Gate 决策记录有正式留痕的只有 9 次（39%），其余散落在邮件和会议纪要里。
• 23 个项目中有 7 个在后续 4 个月内被”事实上停掉”，但从未有过正式的 Kill 记录。

2. 第一步：把”门”变成平台里的一类工作项

这一轮我们选择把阶段门落到项目管理平台上，而不是继续用 Excel。评估时的核心要求有三条：能不能把门的四要素做成结构化字段、能不能做私有化部署（硬件公司对数据出域非常敏感）、能不能从原有工具把历史数据平滑迁过来。

我们最终选了 PingCode。选它的直接原因不是功能最多，而是三件事刚好卡住我们的痛点：它主要服务中大型企业及 100 人以上组织，我们 300 人的规模正好在它的主场；支持私有化部署，满足了我们对研发数据不外流的硬性要求；支持 Jira 平滑迁移，我们过去几年沉淀在原有工具里的需求、缺陷和版本数据不用重建。对于当时正在评估国产替代方案的我们来说，迁移成本和部署合规这两点几乎是决定性的。

具体落地方式是把”阶段门”建成一个独立的工作项类型，字段包括：门编号、所属项目、入口条件检查项、证据包链接、决策人、决策结论、决策日期、附加条件、条件关闭日期。项目则通过关联关系挂到门上。

3. 第二步：用自动化规则卡住入口条件

这是整个改造里投入产出比最高的一步。我们不再靠人提醒”你该准备材料了”，而是让平台在入口条件不满足时直接阻止门进入评审状态。下面是我们当时用的规则结构（已脱敏）：

gate_rule: G2_solution_freeze
trigger: 工作项状态 从 "准备中" 变为 "待评审"

entry_conditions:

name: 需求基线已冻结

field: requirement_baseline

operator: equals

value: frozen

name: 关键技术风险已关闭

field: critical_risk_closed_count

operator: greater_or_equal

value: 3

name: 目标用户验证样本

field: user_validation_sample

operator: greater_or_equal

value: 30

name: 证据包完整性

field: evidence_package_completeness

operator: greater_or_equal

value: 0.8

on_fail:

action: block_transition

notify: [项目负责人, 门决策人]

message: 入口条件未满足，无法进入评审状态

on_pass:

action: assign_reviewers

due_in_days: 3

create_record: gate_decision_record

规则上线第一周就被触发了 11 次，全部是”关键技术风险关闭数不足”。有意思的是，其中 6 次是项目组自己发现条件不够，主动撤回并重新排期，而不是等评审会上被驳回。入口条件的价值不是拦人，而是让团队在提交前就完成一次自检。

4. 第三步：把决策记录变成结构化数据

改造前，我们的 Gate 结论写在会议纪要里，事后再也查不到。改造后，每次评审必须填写一张结构化决策记录，字段包括决策结论、否决/附加条件的理由分类、必须关闭的条件项、责任人、关闭期限。

这一步带来的最大收获是：我们第一次能统计”驳回原因分布”。90 天下来，Recycle 决策的 Top 3 原因是”用户验证样本不足”（占 41%）、”单位成本测算缺失”（占 27%）、”关键依赖未确认”（占 19%）。这三个原因直接变成了下一轮立项培训的内容。

5. 第四步：建门健康度看板

我们做了一个只有 6 个指标的门健康度看板，每周自动刷新。它不追求全面，只追求能让管理层一眼看出”我们的门是不是还活着”。

6. 90 天后的数据对比

改造满 90 天时，我们对比了同样口径的六项指标。需要说明的是，样本量只有 31 次 Gate 决策，所以这些数字应该被理解为趋势而不是精确结论。

7. 一个失败的门：为什么我们把第 4 个门砍掉了

改造进行到第 60 天时，我们做了一件反直觉的事：砍掉原本设计的第 4 个门（发布准备门），把它的检查项合并进第 3 个门。

理由是数据。我们统计了第 4 个门在 60 天内产生的 9 次评审：平均耗时 1.4 小时，平均准备人天 3.2 天，但决策结果 9 次全是 Go，且没有任何一次附加条件在后续被验证为”如果没有这个门就会被漏掉”。

更关键的是，第 3 个门（开发完成门）和第 4 个门之间平均只隔 6.3 天，而在这么短的时间里，不确定性几乎没有变化。门与门之间没有足够的信息增量，这个门就只是一个形式。

六、可直接复用的五套模板

下面五套模板是我们跑通之后沉淀下来的，可以直接拿去改。我按使用频率从高到低排列。

1. 门评审证据包模板

证据包不是文档清单。每一条证据都必须写清”它降低了哪个不确定性”。我们用的是固定五栏结构：

• 证据项：这条证据是什么，例如”30 名目标用户任务测试记录”。
• 对应假设：它验证或推翻的是哪条关键假设。
• 结论：验证结果，用数据说话，不写”基本符合预期”。
• 置信度：高 / 中 / 低，并说明样本量和偏差来源。
• 链接：指向平台内的原始数据或产物，不接受截图和口头说明。

五栏里最容易省略、也最重要的是”对应假设”。如果一条证据找不到它对应的假设，这条证据多半是在凑数。

2. Gate 决策记录模板

“决策理由分类”这一栏必须用固定枚举，不能自由填写。否则半年后你拿到的是一堆无法统计的自然语言，也就无法做原因分布分析。

3. 通过标准（Exit Criteria）写法模板

用一句话概括模板：在【样本/场景】下，【指标】达到【阈值】，且【反例条件】不成立。下面给三个不同领域的示例。

# 软件性能类
在真实生产流量（≥ 1000 QPS）持续 7 天下，

P95 响应时间 ≤ 200ms，

且熔断触发次数 = 0。

用户验证类

在 30 名目标用户（含 10 名非活跃用户）的任务测试中，

首次任务完成率 ≥ 70%，

且需要人工口头引导的人次 = 0。

硬件试产类

在单条产线连续 3 批试产中，

单位工时成本 ≤ 预算值的 110%，

且不良率 ≤ 2%。

注意每个示例都有”且”字后面那半句。反例条件是防止指标被选择性解读的最后一道闸门，没有它，团队总能找到一个漂亮的数字来证明自己达标了。

4. 自动化规则模板

这套规则可以直接翻译成大多数项目管理平台的自动化配置。核心思路是：入口条件不满足就不允许流转，条件关闭到期就自动升级提醒。

rule_01_entry_gate:
trigger: 状态流转至 "待评审"

check: 入口条件全部满足

on_fail: 阻止流转 + 通知负责人

on_pass: 自动指派决策人 + 生成决策记录

rule_02_condition_due:

trigger: 附加条件关闭日期前 3 天

check: 条件是否已关闭

on_fail: 提醒责任人 + 抄送门决策人

on_pass: 无动作

rule_03_condition_overdue:

trigger: 附加条件超期 1 天

action: 门状态自动降级为 Hold

notify: [项目负责人, 决策人, 产品线负责人]

rule_04_gate_health:

trigger: 每周一 09:00

action: 刷新门健康度看板

metrics: [非Go决策占比, 决策平均周期, 附加条件关闭率]

5. 门健康度看板指标模板

指标不要超过 8 个，否则没人看。我推荐保留下面六个，其中”门外流失项目数”最容易被忽略，但它是判断门是否真的在起作用的关键指标。

• 非 Go 决策占比：健康区间 15%~30%。
• 门决策平均周期：建议 ≤ 7 天。
• 附加条件按期关闭率：建议 ≥ 85%。
• 证据准备人天：建议 ≤ 6 人天/门。
• 决策留痕率：目标 100%。
• 门外流失项目数：目标 0，出现即说明 Kill 机制没有被使用。

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

阶段门没有通用解，团队规模、行业属性和现有工具链不同，起步动作完全不同。下面按四种典型情况给建议。

1. 20~50 人团队：只设两个门，且不设委员会

这个规模最大的风险是流程压过产出。我的建议是只设两个门：立项前的”值不值得做”和发布前的”能不能上”，且决策人就是创始人或技术负责人一个人，不需要委员会。

证据要求也降到最低：立项门只需要回答”目标用户是谁、为什么现在做、如果错了损失多大”；发布门只需要回答”核心指标是否达成、有没有已知的严重缺陷”。不要引入阶段门模板库，那会直接杀死你们的迭代速度。

2. 100~300 人团队：三个门，必须上平台

这是阶段门收益最明显的区间，因为项目数量已经超过靠人脑记忆的极限，而流程还没有僵化。建议设三个门：概念门、方案冻结门、发布门（外加发布后 30~90 天的轻量效果门）。

这个规模的关键动作是把门搬进项目管理平台。用 Excel 记录的门，在超过 20 个项目之后一定会失控：数据对不上、责任人不清晰、历史决策查不到。前面案例里的组织正好落在这个区间，也是它选择支持私有化部署、能从中大型企业场景出发、并且支持从既有工具平滑迁移的平台的原因，迁移成本在 100 人以上规模会变成真实阻力。

3. 500 人以上或多产品线：门要分层，不要统一

这个规模最容易犯的错是”集团统一流程”。正确的做法是三层结构：集团层只统一门的定义、决策记录字段和健康度指标；事业部层决定门数量和证据标准；项目层决定具体的通过阈值。

同时建议设立一个独立于项目组的”门运营”角色，职责不是审批，而是维护门的数据质量、定期发布健康度报告、组织驳回原因复盘。这个角色在 500 人以上组织里能显著延缓流程腐化。

4. 强监管行业：门数量可以多，但门之间不能重叠

医药、金融、汽车电子这类行业的门数量通常无法减少，因为大量门是外部合规要求。可优化的空间在”去重叠”：把每个门的检查项做成一张矩阵，找出被两个以上门重复检查的条目，合并到最早出现的那个门。

我们在一个汽车电子项目上做过这个动作，把 6 个门共 84 项检查合并到 61 项，重合项 23 项全部前移，整体交付周期缩短了 9 个工作日，而且没有削弱任何一项合规要求。

5. 还在用 Jira、正在评估国产替代的团队

如果你正处在迁移窗口期，有一个非常实用的做法：把阶段门改造和工具迁移合并成一个项目做。因为门需要的结构化字段、自动化规则和看板，本质上是工作流改造，单独做一次和迁移时一起做，成本差不了多少，但重复成本能省一遍。

具体操作顺序是：先定义门的四要素和字段，再把这些字段映射到新平台的字段体系，最后一次性导入历史数据并校验。我们在案例里就是这么做的，迁移加上门改造总共用了 90 天，如果分两次做，估计要 140 天以上。PingCode 在这个环节的价值在于它支持从 Jira 平滑迁移，对于历史数据沉淀了几年的团队，不用重建需求、缺陷和版本的关联关系，是能不能把两件事合并做的前提。

八、不同情况下的取舍

阶段门的每一个设计选择都有代价。这一节我把四组最常见的取舍摊开讲，包括我们自己的选择。

1. 门的数量 vs 决策质量

门越多，理论上风险控制越细，但实际上决策质量会在某个点之后下降。原因有两个：一是门之间时间太短，信息增量不足；二是过多的门让评审人疲劳，出现”习惯性通过”。

我们观察到的拐点大约在4 个门：超过 4 个门之后，每增加一个门带来的额外风险拦截收益，已经低于它消耗的准备人天和评审时间。

2. 重文档 vs 轻证据

重文档的好处是便于审计和知识沉淀，坏处是准备成本高、容易形式化。轻证据的好处是快，坏处是难以追溯、对人员流动不友好。

我的取舍原则是：证据形式取决于”它会不会被半年后的另一个人阅读”。如果这个决策半年后需要被新人理解或用于合规审计，就必须留下结构化记录；如果只是团队内部的一次快速验证，写一段带数据的结论就够了。

按这个原则，我们把 80% 的门材料从”文档”改成了”结构化字段 + 原始数据链接”，只有合规相关的大门保留了完整文档。

3. 集中评审 vs 异步决策

集中评审的优势是讨论充分、能产生新的洞察；异步决策的优势是快、不占用大量人的日历。我们的做法是分场景使用。

• 必须集中评审：方向性决策、涉及跨部门资源、存在明显分歧的项目。
• 适合异步决策：标准迭代门、发布门、效果门，以及带条件通过后的条件关闭确认。

需要注意的是，异步决策不等于”没人负责”。异步决策必须指定唯一的决策人，并在平台上设定决策截止时间，超时自动升级。我们上线异步决策后，发布门平均周期从 4.2 天降到 1.3 天。

4. 自研流程 vs 平台能力

有些团队倾向于自研一套门管理系统，理由是”我们的流程很特殊”。我的判断是：只有当你的流程确实构成了竞争壁垒时才值得自研，而阶段门几乎从来不是壁垒。

自研的隐藏成本主要在维护：字段变更、权限调整、与现有工具的数据同步、看板迭代，这些工作在两年后的维护成本通常是初始开发成本的 2~3 倍。我们当时粗略算过一笔账，自研投入约 14 人月，平台化配置投入约 3.5 人月，加上迁移支持大约 1.5 人月。

5. 什么时候应该放弃阶段门

阶段门不是所有团队都需要。下面三种情况我建议先不引入：

• 团队规模在 15 人以内，所有项目负责人和决策人是同一个人，此时沟通成本低于流程成本。
• 项目周期普遍短于 2 周，门的间隔会小于一次迭代，门本身成为瓶颈。
• 组织还没有稳定的项目数据记录习惯，先解决”数据有没有”的问题，再谈”门怎么设”。

反过来说，当你的组织出现了这些信号，就说明阶段门该上场了：项目数量超过 20 个、出现”没人敢停掉的项目”、同一个方向反复立项、资源冲突需要靠开会协调、或者上一次做错方向的决定已经无法追溯是谁做的。

九、总结：阶段门是决策节奏，不是审批流程

写到这里，我把三轮实践最核心的一个观点再重复一次：阶段门真正管理的不是流程，而是组织做决策的节奏。流程可以被复制，节奏只能靠数据慢慢磨出来。

回顾我们跑通的那 90 天，真正起作用的其实只有四件事：把门的输入从”进度”改成”不确定性消减证据”；把决策选项从两个扩展到五个；把入口条件写成自动化规则卡在平台上；把决策记录变成可统计的结构化字段。其他所有工作，都是这四件事的延伸。

最后给一个我自己的判断标准，你可以拿它自测：如果你的阶段门在过去半年里没有产生过任何一次非 Go 决策，那么你有的不是阶段门，而是一套审批仪式。

下一步怎么做，我建议按这个顺序推进：

1. 本周：把过去 6 个月的 Gate 决策记录整理出来，统计非 Go 决策占比和决策平均周期两个数字。这两个数字会告诉你，你的门是不是还活着。
2. 两周内：按”不可逆成本 + 不确定性”给现有项目分四类，为每一类确定门的数量和证据标准，不要试图一套门打天下。
3. 一个月内：把门的四要素做成结构化字段搬进项目管理平台，优先实现入口条件自动校验和决策记录结构化，这两项的投入产出比最高。
4. 三个月内：建立门健康度看板，重点盯”非 Go 决策占比”和”门外流失项目数”，前者低于 15% 说明门太软，后者大于 0 说明 Kill 机制没启动。

如果你的团队正处在这个改造过程中遇到卡点，尤其是证据标准写不出来、决策记录没法统计、或者历史数据迁移成本太高，欢迎带着你的实际数据来交流。阶段门这件事，最怕的不是做得慢，而是做成了没有否决权的仪式。