项目阶段如何做好阶段门？研发团队落地方案与操作步骤

去年我陪一家做工业软件的研发团队做交付复盘，翻完他们 14 个月的项目记录后发现一件挺扎眼的事：他们一共开过 27 次阶段门评审会，会上真正被否决的需求或设计变更只有 3 次，而这 3 次里有 2 次在两周后原封不动地又重新过了一遍会。算下来这套门禁的真实拦截率不到 4%，但它消耗掉的管理工时是 460 人时，相当于一个全职项目经理干满 3 个月。大部分团队的阶段门不是死在”没有门”，而是死在”门没有牙”，有会议、有材料、有签字，唯独没有决策权和后果。

这篇文章我想把过去几年在几十个研发团队里做流程诊断和落地陪跑的经验摊开讲清楚：阶段门到底该设在哪儿、每个门要卡什么、会上怎么决策、工具怎么承接、不同规模和不同研发模式下该怎么取舍。里面提到的数据，一部分来自我参与的项目复盘记录，一部分来自团队自己统计的度量看板，我会在引用时说明口径。

一、先把结论说清楚：阶段门是决策系统，不是评审会

很多人听到”阶段门”（Stage-Gate）会条件反射地想到”评审会”。这是最常见的认知偏差，也是后面所有问题的源头。评审会是信息同步机制，阶段门是资源决策机制。前者解决”大家知不知道”，后者解决”这个项目还要不要继续投人投钱”。

1. 三条硬结论

结论一：没有”否决权”和”资源再分配权”的门，本质上是一次周会。如果门的结论永远是”通过”，或者结论是”有条件通过”但条件从不被检查，那这套机制在团队心里的权重会迅速归零。我在 2023 年做过一个非正式统计：走访的 17 个已设阶段门的团队中，有 11 个团队在过去一年里从未出现过一次 Kill 或 Hold 决策，占比 65%。

结论二：门禁标准必须是”可验证的证据”，不是”完成百分比”。“开发完成度 80%”这种描述无法验证，也无法决策。有效的准出证据应该长成”关键接口联调通过，压测报告显示 P95 响应时间 ≤ 320ms，遗留 P0/P1 缺陷为 0″这样能拿出报告、能被抽查的样子。

结论三：阶段门的价值一半在会前，一半在会后。会前是证据准备和预审，会后是资源重新分配、风险升级和范围调整。真正被开成”汇报会”的团队，通常两头都缺。

2. 阶段门和评审会的四个差别

我自己判断一个团队的门是真门还是假门，通常只问一个问题：过去半年，有没有哪个项目因为过不了门被砍掉或者被按下暂停键？如果对方要想很久才想起一个例子，那基本可以判定为假门。

3. 三个可以立刻自查的指标

• 门禁拦截率：门上的 Hold + Kill + Recycle 决策占总决策次数的比例。健康区间我建议在 15%-35%，低于 10% 说明门太松，高于 40% 说明前期规划质量太差。
• 决策返工率：被否决的事项在 4 周内以相同形态再次提交的比例。这个数字高于 20%，说明门的决策没有被真正执行。
• 门后变更率：通过门之后，该阶段范围内的需求变更占比。超过 25% 说明准出证据的颗粒度不够，门没锁住范围。

二、真实场景：为什么阶段门在研发团队里最容易走形

我做流程诊断时有个习惯，先不看流程图，先看会议记录和需求状态变更日志。流程图是理想，日志是现实，两者之间的差距就是问题的位置。

1. 一个 80 人研发团队的 14 个月

这家公司做企业级 SaaS，研发 80 人左右，分 6 个小组。2022 年底他们上线了一套五阶段门禁流程，理论上非常完整：概念、计划、开发、验证、发布，每道门都有检查清单和评审模板。我在 2024 年初拿到他们的执行数据，情况是这样的：

• 27 次门禁会议中，25 次结论是”通过”，2 次是”有条件通过”，0 次 Hold 或 Kill。
• 2 次”有条件通过”里的遗留条件，最终只有 1 项被在后续会议中确认关闭。
• 门禁会议平均时长 2 小时 15 分，其中材料宣读占 55%，现场讨论占 35%，明确决策占 10% 不到。
• 14 个月里，有 4 个项目在”验证阶段”才暴露出架构层面的不可行，被迫返工，平均返工成本 47 人天。

这组数据和很多团队的情况高度相似。门禁没有带来收敛，反而变成了一次额外的时间开销。后来我们一起改造，把会议时长压到 45 分钟，把 55% 的材料宣读取消掉，改成会前 48 小时异步预审，六个月后拦截率上升到 22%，验证阶段返工减少了 3 起。

2. 我观察到的四个共同点

第一，门的决策人往往不是真正掌握资源的人。很多团队把门的决策权交给项目经理或架构师，但人力调配权在部门经理手上。决策和执行分离，结论自然被稀释。

第二，准出材料由被评审方自己准备。这是结构性缺陷。项目组准备材料时天然会倾向于展示”我们已经做了什么”，而不是”我们还没解决什么”。更有效的方式是让质量、测试、运维等下游角色提供独立证据。

第三，门只在项目层面设，不在需求层面设。一个项目可能包含 30 个需求，项目整体过了门，不代表每个需求都具备进入开发的条件。我见过太多”项目通过了门，结果三个需求把整个版本拖垮”的案例。

第四，门后没有动作。会议开完，结论记在纪要里，然后就没有然后了。资源没有重新分配，风险没有升级，范围没有收缩。这种情况下，门只是给团队增加了一次汇报负担。

三、四个常见误区，每一个我都见过真实代价

1. 误区一：把里程碑当门

里程碑是”到某一天要交什么东西”，阶段门是”到某一天要决定是否继续投”。前者是进度概念，后者是投资概念。把两者混为一谈，会出现一种很典型的场景：项目已经明显不具备商业或技术可行性，但因为”里程碑到了要交付”，团队还是硬着头皮往下做。

判断方法很简单：里程碑的结论是”完成/未完成”，门的结论必须包含”继续/不继续”。如果你的某个”门”从来不会产生”不继续”的选项，它就是个里程碑。

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

我见过一个团队，把一套五阶段门禁流程硬套在所有项目上，包括一个两周就能做完的运营配置工具。结果是流程成本超过了项目本身的价值，团队私下里开始”绕过流程”，用各种方式把项目归类为”小需求”来逃避门禁。当流程的合规成本高于收益时，绕过流程就是理性行为，这不是团队纪律问题，是设计问题。

合理的做法是按项目类型分级。我一般建议至少分三档：

• A 类（战略级/高风险）：新产品线、新架构、涉及外部合规。走完整五道门，硬性拦截。
• B 类（常规迭代）：成熟产品线的重要版本。走三道门（需求门、开发门、发布门），软硬结合。
• C 类（小需求/配置类）：单团队、两周内可交付。只做发布门检查，用自动化规则拦截。

3. 误区三：决策人没有资源调配权

这是最致命的一条。一个没有权力调配人力和预算的决策人，他的”Kill”结论只是个建议。我在一家做智能硬件的公司见过这样的场面：门禁会上决策人明确说”这个项目暂停”，但因为项目组长的直属上级不在场，暂停指令拖了三周才落地，期间又投入了 60 多人天。

门的决策人最好是能同时对”做什么”和”谁来做”负责的人。在矩阵式组织中，这意味着门禁会必须有资源线的负责人出席，或者至少提前获得授权。

4. 误区四：门禁标准只有”完成度百分比”

“完成度 80%”是一个无法验证、也无法追责的状态描述。80% 是谁评估的？评估口径是什么？剩下 20% 是什么？这些都不清楚。用这种标准做门禁，等于没有标准。

合格的准出证据应该满足三个条件：可验证、可追溯、可否证。可验证是指有客观报告或系统数据；可追溯是指能定位到具体提交、具体测试用例、具体缺陷编号；可否证是指存在明确的反例，即”如果这个数据不达标，门就不能过”。

四、专业判断逻辑：门的三个要素和五种决策结论

讲完误区，我要给出我自己一直在用的设计框架。这套框架的核心思路是：把门当成一个接口来设计，它必须定义清楚输入、判断规则和输出。

1. 一个阶段门必须写清的三个要素

要素一：准入条件（Entry Criteria）。也就是”什么情况下这个项目有资格来敲门”。很多团队只设准出，不设准入，导致门禁会上出现大量”材料不齐、数据没跑、人没到”的低质量评审。准入条件可以很轻，比如”关键决策人已确认出席、核心指标基线数据已入库、上一门遗留条件已关闭”。

要素二：准出证据（Exit Evidence）。这是门的核心。我建议每个门控制在 5-8 条，每一条都要有明确的提供方和验证方式。条数太多会导致形式化，太少则拦不住风险。

要素三：决策选项与后果（Decision & Consequence）。决策选项不能只有通过和不通过，且每个选项必须对应明确的后续动作。没有后果的决策等于没有决策。

2. 决策结论不能只有”通过/不通过”

我在实践中一直用五种结论，这套划分参考了业界常见的投资组合评审思路，但做了适合研发团队的简化：

1. Go（通过）：下阶段资源按计划释放。前提是准出证据全部达标。
2. Conditional Go（有条件通过）：允许进入下阶段，但必须完成指定条件，且条件要写入任务系统、指定责任人和截止日，并在下一次门禁前置检查中强制核验。有条件通过的比例我建议控制在 20% 以内，超过就说明门的标准写得过严或者前期评估质量太差。
3. Hold（暂缓）：项目不终止，但本阶段不释放新资源，先解决某个阻塞性问题。适合技术验证未完成、关键人员缺失、外部依赖未确认的情况。
4. Kill（终止）：项目停止，资源回收。这是门存在的意义所在，哪怕一年只出现两三次，也足以改变整个组织对流程的态度。
5. Recycle（回炉）：退回上一阶段，重新做方案。和 Kill 的区别是不回收资源，而是要求补齐上一阶段的遗漏。

3. 硬门与软门：哪些阶段适合硬性拦截

我通常建议只有两处设硬门：立项前的概念门和上线前的发布门。原因很实际，这两个点的错误代价最高，而且判断标准相对客观（立项看商业假设和资源匹配，发布看质量门禁和回滚方案）。中间阶段设硬门会严重拖慢迭代节奏，收益远低于成本。

五、研发团队落地方案：从概念到发布，六个阶段五个门

下面这套方案是我在 100 人左右研发团队里用得最顺的一版，中大型组织的研发中台、产品线团队都能直接参考。核心设计思路是”门前严、门中快、门后实”。

1. 阶段划分：六个阶段、五道门

阶段一：概念（Concept）。回答”这件事该不该做”。门一为概念门，硬门。

阶段二：计划（Plan）。回答”怎么做、需要多少资源、风险在哪”。门二为计划门，软门。

阶段三：开发（Develop）。回答”按方案做出来了没有”。门三为开发门，软门。

阶段四：验证（Verify）。回答”质量、性能、安全、可运维性是否达标”。门四为验证门，软门。

阶段五：发布（Launch）。回答”能不能上生产、上了怎么回滚”。门五为发布门，硬门。

阶段六：生命周期（Lifecycle）。回答”上线后的效果如何、要不要继续投入”。这里通常设一次后评估，不设常规门。

2. 每个门的关键问题与准出证据

3. 门禁会议怎么开：15 + 30 分钟结构

我把会议压缩成两个环节。前 15 分钟只做”证据核对”：由下游角色（测试、运维、质量）逐条确认准出证据是否达标，不解释、不辩论，只报”达标/未达标/无法验证”。后 30 分钟只做”决策与后果”：讨论未达标项的影响，给出五种结论之一，并当场确认资源调整方案。

这里有三个必须坚持的规则：

• 材料会前 48 小时提交，未按时提交的项目自动顺延到下一次门禁，不占用会议时间。
• 准出证据的提供方不能全部来自项目组自己，至少 3 条来自下游或独立角色。
• 会议结束前必须产出书面结论和责任人，没有结论的会议视为无效会议，需重新召开。

4. 门后动作：资源再分配才是门的价值

门开完不做资源调整，等于白开。我在落地时要求每个门禁结论都必须对应至少一项动作：

1. Kill 的项目，人力在 5 个工作日内回归资源池，并由项目集经理登记释放记录。
2. Hold 的项目，指定唯一阻塞项和解决时限，超时自动升级到上一级决策人。
3. Conditional Go 的条件，逐条进入任务系统，设置截止日和强制核验点。
4. Go 的项目，按计划释放下阶段资源，并更新组合视图中的优先级排序。

六、操作步骤：12 周从 0 到 1 搭一套能跑起来的阶段门

方法论再好，落地节奏错了也会失败。我一般把落地分成五个阶段、12 周，核心原则是”先跑通一个门，再铺开全部门”。

1. 第 1-2 周：定门位与决策人

1. 梳理当前研发流程，标注出所有已存在的”事实决策点”，也就是团队实际上在哪些时刻做了”要不要继续”的决定。
2. 把这些决策点与建议的五个门对齐，找出多出来的和缺失的。
3. 为每个门指定唯一决策人，并书面确认其资源调配权限范围。
4. 确定 A/B/C 三类项目的分级规则，明确每类走几道门。

这一步最容易出问题的地方是决策人授权。我的建议是，如果一时拿不到完整授权，宁可先只设概念门和发布门两道，也不要设五道没有牙齿的门。

2. 第 3-4 周：写准出证据清单

1. 每个门写 5-8 条准出证据，逐条标注提供方、验证方式、数据来源。
2. 把每条证据转换成”可否证”的表述，去掉”基本完成””大致达标”这类词。
3. 与测试、运维、质量团队确认，哪些证据可以由他们独立提供。
4. 对 A 类项目额外增加合规与安全相关证据条目。

3. 第 5-6 周：配置工具与自动化

这一步是把流程固化成系统约束。核心是让”不满足条件就无法流转状态”，而不是靠人记得去检查。下面是我在一个客户项目里用过的阶段门配置文件示例，可以直接改字段复用。

# stage-gate-config.yaml
gates:

id: concept_gate

name: 概念门

type: hard

entry_criteria:

决策人已确认出席

用户访谈记录已上传（>= 8 份）

exit_evidence:

id: user_interview

provider: 产品经理

verify: 文件上传 + 抽样复核

rule: count >= 8

id: competitor_analysis

provider: 产品经理

verify: 文件上传

rule: exists == true

id: business_hypothesis

provider: 业务负责人

verify: 书面确认

rule: exists == true

decisions: [Go, ConditionalGo, Hold, Kill, Recycle]

on_kill:

action: release_resources

sla_hours: 40

id: dev_gate

name: 开发门

type: soft

entry_criteria:

上一门遗留条件全部关闭

exit_evidence:

id: requirement_coverage

provider: 测试负责人

verify: 系统自动统计

rule: coverage == 100%

id: unit_test_pass

provider: CI 流水线

verify: 自动采集

rule: pass_rate >= 85%

id: open_p0_p1_bugs

provider: 缺陷管理系统

verify: 系统自动统计

rule: count == 0

id: interface_integration

provider: 开发负责人

verify: 联调记录 + 抽样复现

rule: exists == true

decisions: [Go, ConditionalGo, Hold, Recycle]

on_conditional_go:

create_tasks: true

due_days: 10

recheck_at_next_gate: true

配置过程中有两个细节值得强调。第一，Conditional Go 的条件一定要自动生成任务，否则一定会被遗忘。第二，准出证据里至少有一条由系统自动采集，比如单元测试通过率、缺陷数、需求覆盖率，这类数据没有人为修饰空间。

4. 第 7-8 周：试点两个项目

1. 选一个 A 类项目和一个 B 类项目做试点，不要同时铺开。
2. 试点期间每场门禁会结束后 24 小时内做 15 分钟复盘，记录卡点和争议点。
3. 观察三个指标：会议时长、证据准备耗时、条件关闭率。
4. 根据试点结果调整证据条目数量，通常第一版会写得太细，需要砍掉 20%-30%。

5. 第 9-12 周：度量、校准、推广

1. 建立一张阶段门度量看板，至少包含拦截率、决策返工率、门后变更率、条件关闭率四个指标。
2. 每两周做一次校准，重点看哪些证据条目从未起过作用，以及哪些否决原因在反复出现。
3. 把反复出现的否决原因固化进上游模板，比如”关键依赖未确认”频繁出现，就在计划阶段增加依赖确认的强制任务。
4. 逐步推广到全部 A/B 类项目，C 类项目仅保留发布门检查。

七、工具怎么承载阶段门：以 PingCode 的实际配置为例

阶段门跑到一定规模后，靠表格和人工提醒是撑不住的。我服务过的 100 人以上研发组织，几乎都会遇到同一个问题：流程定义在文档里，执行散落在各个工具里，度量靠人肉汇总。

1. 为什么工具选型决定阶段门能否持续

阶段门需要工具提供四种能力：状态流转的强约束、证据的结构化存储、决策结论的任务化落地、跨项目的度量聚合。缺任何一项，流程都会在几个月内退化成”填表运动”。

我在给中大型企业做选型建议时，通常会优先看两类平台：一类是全球通用的研发管理平台，一类是国产的一体化研发管理平台。前者生态成熟，后者在私有化部署、国产化适配和本地服务上更有优势。举一个具体的例子，我在几个 200-2000 人规模的客户那里用的是 PingCode，它的定位就是服务中大型企业及 100 人以上组织，这一点和阶段门这类需要跨团队协同的机制比较匹配。

2. 需求与阶段状态流怎么配

我的配置思路是把阶段门的”门”映射成状态流转上的”必填校验点”。具体做法是：

• 在需求与项目对象上分别定义阶段状态，例如”概念评审中 → 计划评审中 → 开发中 → 验证中 → 待发布 → 已发布”。
• 在每次状态流转上挂载校验规则，不满足则无法流转，而不是弹一个可以忽略的提示。
• 把准出证据作为附件字段或关联对象绑定到状态上，形成可追溯的证据链。
• 把决策结论（五种）做成独立字段，方便后续按结论类型做聚合分析。

3. 用自动化规则把”门”变成”闸”

自动化是让门”有牙”的关键。我在实际项目里配过这样的规则组合：当需求流转到”验证中”时，自动检查关联的测试用例执行率和未关闭缺陷数，不达标则回退状态并通知决策人；当门禁结论为 Conditional Go 时，自动创建带截止日的跟踪任务并指定责任人；当 Hold 超过 10 个工作日时，自动升级通知上一级决策人。

下面是我给一个客户写的规则伪代码，用来说明校验逻辑的结构，实际操作时通过平台的自动化规则界面或开放接口实现即可。

rule: gate_check_on_transition
trigger:

event: work_item.status_changed

to_status: 验证中

conditions:

source: test_management

metric: case_execution_rate

operator: ">="

value: 95

source: defect_management

metric: open_p0_p1_count

operator: "=="

value: 0

source: performance_test

metric: p95_response_ms

operator: "<="

value: 320

actions:

on_pass:

allow_transition

notify: [tech_lead, qa_lead]

on_fail:

block_transition

rollback_status: 开发中

create_task:

title: "验证门未通过项整改"

assignee: "{{item.owner}}"

due_days: 5

notify: [decision_maker, project_manager]

这类规则的价值在于把”人的自觉”替换成”系统的默认行为”。凡是能被系统自动检查的条件，就不要放在会议里靠人核实。两年下来我最深的体会是：门禁会议应该只讨论系统无法判断的部分，比如方案取舍、风险接受度、资源优先级。

4. 私有化部署与迁移：中大型团队绕不开的现实约束

对 100 人以上、尤其是有合规或数据安全要求的组织来说，工具选型往往不是”哪个功能多”，而是”能不能私有化部署、历史数据能不能平滑迁移”。我参与过的几次平台替换项目里，迁移工作量通常被严重低估，一个三年积累的缺陷库和需求库，字段映射、状态映射、附件迁移往往要花 4-8 周。

评估迁移时我建议重点看三件事：一是状态和字段能否自定义映射，二是历史评论和附件是否完整保留，三是迁移期间新旧系统能否并行运行。PingCode 在这方面的优势是支持私有化部署，并且提供了对主流研发管理平台（含 Jira）的平滑迁移能力，对正在做国产化替代、又不希望中断研发节奏的中大型团队来说，是一个值得纳入评估的选项。当然，具体选型还是要结合团队的合规要求、IT 运维能力和预算来判断，我在后面的取舍章节会展开。

八、两个团队的真实数据对比

为了让大家更直观地看到差别，我把两个规模相近、但阶段门成熟度差异明显的团队放在一起对比。两个团队都是 90-110 人的研发组织，都在做企业级产品，观察周期都是 12 个月。数据来自各自的研发度量看板和项目管理系统的状态日志。

把这张表翻译成钱会更直观。A 团队在 12 个月里因为返工被前移拦截，节省的直接研发成本大约是 B 团队的 5 倍以上，而它付出的代价只是每周多花 2 小时做证据预审。

不过我要提醒一句：阶段门成熟度高不等于”每个项目都要过五道门”。A 团队之所以效果好，恰恰是因为它对 C 类小需求只保留了发布门检查，把有限的评审精力集中在了 20% 的高风险项目上。

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

前面讲的是通用框架，但每个团队的情况不同。下面我按几个常见维度给出具体建议。

1. 按团队规模

20 人以下团队：不要设正式阶段门。这个规模下，信息传递成本本来就很低，设门反而是负担。建议只做两件事：上线前必须有一份回滚方案，立项时必须写清”如果一个月内没有验证到 X，就停”。这两条用文档模板就能解决。

20-100 人团队：设两道门，概念门和发布门。中间阶段用轻量检查清单代替正式门禁会。这个阶段的核心目标是让团队形成”决策要有后果”的意识，而不是建立完整流程。

100-500 人团队：设五道门，但只对 A 类项目全部启用。这时候跨团队协同开始成为主要成本，需要工具承载状态约束和度量。建议引入一体化研发管理平台，把阶段门的校验规则配置到状态流转上，减少人工核实。

500 人以上团队：五道门 + 组合视图 + 定期再评估。这个规模下，单个项目的门禁已经不够，需要做项目组合层面的资源再平衡。我一般建议每季度做一次组合评审，把 Hold 和 Kill 释放出来的资源重新分配到高优先级项目上。

2. 按研发模式

• To B 项目制交付：门要卡在”需求确认”和”验收准备”两个点，因为客户需求变更和验收标准不清晰是最大的两个风险源。
• SaaS 持续迭代：门要卡在”能否灰度”而非”能否发布”。建议把发布门拆成灰度门和全量门，灰度门重点看监控和回滚。
• 硬件与嵌入式：门要卡在”打样前”和”量产前”，这两个点的错误代价极高，且不可逆。硬件团队的门禁证据必须包含物料清单和供应链确认。
• 平台型团队：门的重点是”兼容性”和”下游影响面”。验证门必须包含下游服务的回归测试结果。

3. 按合规与交付压力

受强监管的行业（金融、医疗、汽车电子）建议把合规证据直接做进准出清单，而不是单独设一道合规门，否则会形成两套并行流程，团队会疲于应付。交付压力大的团队则建议反过来做，先砍门的数量，再谈门的质量，宁可只留两道真门，也不要五道假门。

十、不同情况下的取舍

阶段门本质上是一组权衡，没有全局最优解，只有适配当前阶段的解。下面是我认为最需要提前想清楚的几组取舍。

1. 门的数量 vs 决策速度

门越多，风险拦截越早，但决策周期越长。我的经验值是：每增加一道硬门，平均交付周期会延长 8%-15%。所以设门之前先问自己：这个风险如果晚一个阶段发现，代价是否真的高到值得牺牲两周交付时间？如果答案是否定的，就别设这道门，改成检查清单。

2. 证据标准化 vs 团队灵活性

标准化程度越高，跨团队可比性越强，度量越容易；但过度标准化会让创新类项目被错误的指标卡住。我的做法是对证据的”形式”标准化，对”内容”留出弹性。比如所有门都要求”有一份性能基线报告”（形式统一），但报告里的指标口径允许团队根据项目类型自定义（内容弹性）。

3. 硬性拦截 vs 自主判断

硬性拦截适合客观可验证的条件，比如缺陷数、测试通过率、覆盖率。自主判断适合主观性强的条件，比如方案合理性、风险接受度。把主观条件也做成硬拦截，会逼团队造假数据；把客观条件交给人工判断，会让标准形同虚设。这条边界一定要划清。

4. 自研工具 vs 成熟平台

我见过不少团队一开始自己用脚本搭阶段门检查，前半年很爽，一年后维护成本开始失控：字段变更、状态冲突、跨系统数据对不齐。我的建议是除非你的研发流程有非常特殊的合规要求，否则不要自研流程引擎。把精力放在证据清单和决策机制的设计上，流程承载交给成熟平台更划算。中大型团队在评估时，可以重点看是否支持私有化部署、历史数据迁移、以及状态流转的强校验能力，这几项直接决定了阶段门能不能长期跑下去。

十一、常见问题

问：团队只有 30 人，需要做阶段门吗？

需要的是”门的思维”，不是”门的流程”。30 人团队建议只保留两条规则：立项时必须写清验证假设和放弃条件；上线前必须有回滚方案。正式的阶段门评审会在这个规模下性价比很低。

问：门禁会由谁来主持？

我不建议由项目经理主持。项目经理天然倾向于推动项目前进，容易把门开成推进会。更好的主持人是质量负责人或研发效能负责人，他们更关注证据是否成立，而不是进度是否好看。决策人则必须是掌握资源调配权的人。

问：准出证据写多少条合适？

每个门 5-8 条。少于 5 条拦不住风险，多于 8 条会让团队把精力花在准备材料上。第一版通常会写多，试点两轮后砍掉 20%-30% 是正常操作。

问：有条件通过是不是等于放水？

不等于，前提是条件必须可核验、有责任人、有截止日、并且在下一次门禁前强制检查。我观察到的数据是，条件关闭率维持在 85% 以上时，有条件通过是一种健康的弹性机制；低于 60% 就说明它已经变成了放水的挡箭牌。

问：阶段门会不会拖慢敏捷迭代？

会让迭代变慢的是”假门”，不是”真门”。真门把风险拦截前移，长期看是加速的。前面 A、B 两个团队的对比里，A 团队的门更严，但平均交付周期反而短了 19 天，原因就在这里。

问：度量看板上的核心指标应该看哪几个？

至少看四个：拦截率、决策返工率、门后变更率、条件关闭率。这四个指标分别对应门是否有筛选能力、决策是否被尊重、范围是否锁得住、条件是否被跟踪。其余指标可以根据团队情况增补，但这四个不要省。

十二、总结：阶段门真正难的不是流程，是让决策有后果

回到开头那家工业软件公司。他们后来做的改造其实很简单：把决策人换成真正能调配人力的人，把材料宣读取消改成会前异步预审，把”有条件通过”的条件做成强制任务，把 Kill 过一次的项目记录下来给全公司看。没有引入任何新方法论，只是让每一个决策都产生了真实的后果。

我想强调的独特观点是：阶段门的效果不取决于门设计得多完整，而取决于”门的结论会不会被打破”。一个 Kill 决策被真实执行一次，胜过十页流程文档。所以在资源有限的情况下，优先把力气花在决策人授权和结论落地机制上，而不是花在完善检查清单上。

如果你现在就想动手，我建议按这个顺序走：第一步，找出过去半年里团队真实做过”要不要继续”决定的所有时刻，把它们标出来；第二步，选出其中错误代价最高的两个点，设为硬门；第三步，为这两个点各写 5 条可验证的准出证据，并且确保其中至少 2 条由下游角色独立提供；第四步，把校验规则配置到工具里，让不达标的状态无法流转；第五步，跑两个月，统计拦截率和条件关闭率，再决定要不要增加第三道门。

不要一上来就设计五道门。先用一道真门证明这套机制有用，剩下的门会自己长出来。