阶段门怎么做？项目经理协同管理：项目阶段从0到1

“阶段门”这三个字听起来很硬，但它往往死在最软的地方，一场没人敢说“不”的评审会。我参与过 11 个研发流程治理项目，其中 6 个做过阶段门（Stage-Gate）改造，真正跑通、并且在一年之后还在用的只有 3 个。剩下 3 个失败案例的死法几乎一模一样：门越设越多，评审会越开越长，决策却越来越少。

更反常识的是，这 3 个失败案例的团队执行力都不差。他们的问题不在“不认真”，而在“太认真”，把阶段门做成了一套精密的审批流，每个门都要交 20 份文档、盖 5 个章、开 2 小时会，最后所有人都在完成动作，没有人真正在做决策。这篇文章我想把阶段门从 0 到 1 的完整做法拆开讲清楚：门该设几道、准则怎么写、项目经理在门里到底扮演什么角色、用什么工具承载才能不掉进形式主义陷阱。

一、先说结论：阶段门做的不是“门”，是决策基础设施

如果只看一句话，我的核心判断是：阶段门的成败，90% 取决于门前的准备质量和门后的动作追踪，门本身只是一次 30 分钟的表决。大部分团队把 90% 的精力花在了门本身的会议形式上，这是最典型的方向性错误。

基于这个判断，我把它拆成四条可以直接拿去做判断的结论。这四条结论贯穿全文，也是后面所有具体做法的底层逻辑。

1. 门的数量比门的形式重要十倍

我见过最夸张的一个案例：某工业设备企业的研发流程被拆成 7 个阶段、7 道门，从概念到量产要走 7 次评审。结果是每一道门的评审材料都是同一批人在同一周赶出来的，评审人看到第三份材料时已经失去了判断力，后面 4 道门全部变成“无异议通过”。

后来我们把 7 道门砍到 3 道，概念门、方案冻结门、上市准备门，其余阶段的检查改成了团队内部的轻量对齐。结果很有意思：决策质量上升了，而不是下降。因为评审人只需要在 3 个关键节点投入完整注意力，每个节点的材料质量也随之提高。门的数量减少，不等于是放松管控，而是把有限的决策注意力集中到真正不可逆的节点上。

判断标准很简单：如果一道门被否决后，团队不能实质性地转向或终止，那这道门就不该存在。它只是流程装饰。

2. 阶段门的最小可行单元是三件套，缺一不可

不管你的公司规模多大、用什么工具，一道能工作的门至少需要三个组成部分：可验证的交付物清单、可打分的准入准则、可追溯的决策记录。我把这三者叫做阶段门三要素。

缺第一项，评审会变成口头汇报，谁会说谁占便宜；缺第二项，评审变成主观感受，通过与否取决于评审人当天心情；缺第三项，门开完就散场，三个月后没人记得当初为什么批准或否决，也没人能追溯当时的风险假设是否成立。

这三件套里，最容易被忽略的是第三项。实际上决策记录的价值会随时间指数级上升，它是一个组织“决策记忆”的载体。当项目在上市阶段出了问题，回头看第二道门的决策记录，你能清楚看到当时是什么信息、谁提出的风险、为什么仍然选择继续。这才是组织学习发生的地方。

3. 项目经理的角色错位，是阶段门最大的失败源

绝大多数项目经理在阶段门里的默认动作是：收集材料、做 PPT、会上汇报、会后发纪要。这个角色定位本身就错了。它把项目经理变成了“信息的搬运工”，而不是“决策的编排者”。

我的判断是：项目经理在阶段门里真正的工作是三件事，保证交付物在会前齐套且可验证、保证评审准则被提前告知并被用于自评、保证决策之后的动作被分派且闭环。汇报只是其中最小的一部分，甚至可以让交付责任人自己讲。

这个角色转换听起来抽象，但它带来的差别极其具体：前者在会前一周就把交付物齐套率从 60% 推到 95%，后者在会前两小时还在等某个人补一份测试报告。

4. 数字化工具承载的是证据链，不是审批流

这是我见过最多团队搞错的一点。很多人一提“阶段门数字化”，第一反应是去 OA 里画一个审批流程，五个节点串行审批。这样做的结果是：你得到了一条审批记录，但没有得到一条证据链。

审批记录回答的是“谁签了字”，证据链回答的是“当时依据什么信息做的判断、这些信息后来被验证了没有”。中大型企业真正需要的是后者。这也是为什么我在做流程治理时，更倾向于把阶段门承载在研发项目管理平台上，而不是通用审批工具里，因为交付物本身就产生在研发流程中，评审只是对它的一次快照。

二、背景：我经历过的三次阶段门翻车现场

光讲结论容易显得空。接下来我想讲三个真实的翻车场景。它们分别代表了三类完全不同的失败原因：流程设计过重、会议机制缺失、决策与资源脱钩。理解这三类失败，比记住任何方法论都管用。

1. 第一次翻车：七道门，全部变成签字仪式

那是 2018 年，一家做工业控制设备的公司，研发团队约 180 人，分 4 条产品线。他们的流程文档写得非常漂亮，每个阶段的交付物清单有 A4 纸三页，准入准则用了 40 多个检查项。问题就出在这里，40 多个检查项里，有 30 个是“文档已完成”“评审已通过”这种自指式描述，根本无法验证。

更麻烦的是，7 道门分布在 14 个月的项目周期里，平均每 2 个月一次评审。项目经理的时间被切成碎片，一半用来准备材料，一半用来开会。我统计过其中一位项目经理的日历：一个季度里，他参加了 23 次评审相关会议，合计 41 小时，而真正用于识别项目风险的时间不到 6 小时。

在这种结构里，项目经理不可能做“决策编排”，只能做“材料搬运”。阶段门不是被某个人毁掉的，是被流程自身的设计密度毁掉的。

2. 第二次翻车：会开了三小时，没有产生任何决策

第二个案例是一家医疗器械企业，团队规模 320 人左右。他们的门不多，4 道，但每一道门的评审会都是一场灾难。典型场景是这样：会议开始，项目经理用 40 分钟讲 PPT；然后研发负责人补充 20 分钟技术细节；然后质量负责人提出 8 个疑问；然后市场负责人说“我需要再看看数据”。

三个小时过去，会议结束时主持人的总结是：“大家的意见都很好，我们回去再完善一下材料，下次再评审。”我参加过三次这样的会，三次都是这个结局。问题不在人，在机制：会议没有预设决策选项，没有投票机制，没有明确的决策人。

当一场评审会的默认结局是“再看看”，那么它就永远不会产出“不”。而一个永远不会说“不”的门，本质上等于没有门。

3. 第三次翻车：门通过了，但资源没有到位

第三个案例最隐蔽，也最值得警惕。一家企业软件公司，阶段门流程设计得相当不错，3 道门，准则清晰，决策记录也完整。但项目仍然大面积延期，原因让人意外：门评审只审交付物，不审资源承诺。

具体表现是：方案冻结门通过了，评审结论写着“同意进入开发阶段，预计投入 12 人 4 个月”。但会上没有任何一位职能经理当场确认这 12 个人从哪里来、什么时候能到位。两个月后项目经理发现，实际到岗只有 7 人，而且其中 3 人是兼职。

这个问题的根源在于，阶段门被设计成了“技术评审”，而不是“投资决策”。一个真正的投资决策必然包含资源承诺，谁出人、出多少人、什么时候出、如果冲突优先保谁。没有资源承诺的门，通过与否对项目实际推进几乎没有约束力。

我后来在给其他团队做咨询时，把这一条列为硬性要求：任何一道门的决策记录里，必须有一段“资源承诺”，由具体职能负责人口头确认并书面留痕。缺少这一段，门不算开完。

三、拆解六个常见误区

上面三个翻车场景背后，其实是六类可以提前规避的认知误区。我把它们整理出来，你可以对照自己的流程逐条检查。这些误区不是理论推演，而是从实际项目复盘里提炼的，每一条我都能说出对应的具体场景。

1. 误区一：把阶段门当作审批流来做

这是最普遍的一个。表现是：在通用审批工具里画一条串行流程，节点是“研发经理审批→质量经理审批→总监审批→副总审批”。所有人都在审“同意不同意”，没有人在审“依据是否充分”。

为什么这是误区？因为审批流的默认语义是“合规确认”，而阶段门的语义是“投资决策”。合规确认追求的是不出错，投资决策追求的是做出正确取舍。两者的评价标准完全不同。

判断自己有没有掉进去很简单：看你的评审记录。如果记录里只有“同意/不同意”和签字，没有评分、没有风险假设、没有资源承诺，那你做的是审批流。

2. 误区二：准则用形容词，不用数字

“需求文档基本完善”“性能指标大体达标”“风险可控”，这类表述在评审材料里出现的频率高得惊人。它们的共同问题是无法验证，因此也无法否决。当所有人对“基本完善”的理解都不一样时，评审就变成了各说各话。

我的做法是把每一条准则都改写成可判定命题：把“性能指标大体达标”改成“核心接口 P95 响应时间 ≤ 200ms，且已在预生产环境完成 72 小时稳定性测试”；把“风险可控”改成“高风险项 0 个未闭环，中风险项已制定缓解方案的 ≥ 80%”。

改写之后会有个副作用：很多项目在会前自评阶段就发现自己不达标，于是主动申请 Hold 而不是硬着头皮上会。这恰恰是流程在起作用的表现。

3. 误区三：决策选项只有 Go 和 Kill

只有两个选项的时候，人的决策会严重偏向 Go。因为 Kill 意味着前面几个月的投入全部作废，心理成本太高，绝大多数人宁可选择“继续看看”。

成熟的阶段门至少要有四个选项：Go（按计划进入下一阶段）、Hold（暂缓，等待特定条件满足）、Recycle（退回上一阶段重做特定部分）、Kill（终止）。这四个选项给了评审人中间地带，让决策更接近真实判断。

我观察到的数据是：引入 Hold 和 Recycle 之后，Kill 的比例反而上升了。因为 Kill 不再是唯一一个“负面选项”，评审人不需要为了回避 Kill 而勉强通过。

4. 误区四：把项目经理当成汇报人

这个误区前面已经提过，但它值得单列，因为它直接影响协同质量。当项目经理被定位成汇报人时，其他角色会自动退到“听众”位置，研发不主动对齐交付物标准，测试不提前暴露数据缺口，职能经理不提前确认资源。

项目经理真正的价值在于“编排”：在会前把散落在各角色手里的信息和承诺收拢成一份可决策的材料。这件事做得好，会议时间可以压缩 50% 以上。

5. 误区五：门只审交付物，不审资源承诺

这一点在第二个翻车案例里已经详细讲过。补充一个我常用的检查动作：在看任何一份门的决策记录时，我会直接翻到最后一页找“资源承诺”这一段。如果没有，我会认为这道门没有真正开完，无论前面写了多少内容。

6. 误区六：门开完就散场，没有决策追踪

决策记录写完了、归档了，然后呢？如果没有“门后动作清单”和闭环追踪，阶段门对项目实际推进的影响会衰减得极快。我的经验是：门后动作如果在两周内没有开始执行，三个月后基本就没人记得了。

四、专业判断逻辑：阶段门的最小可行结构

讲完问题，接下来讲怎么搭。我给出的是一个可以直接照着做的结构，包括四要素设计、评分卡、门的节奏、协同责任矩阵，以及三个用来判断“这道门该不该设”的测试。

1. 门的四要素：准入准则、交付物、决策人、决策记录

这是我做流程设计时的标准骨架，四要素缺一不可，顺序也不能颠倒。

准入准则要在阶段开始前就明确，而不是在门评审前才定。它的作用是让团队在整个阶段里知道自己朝什么方向努力，而不是最后一天才对照标准自查。

交付物必须是可验证的对象，而不是一段描述。可验证的含义是：它存在于某个系统里、有明确的状态字段、有版本记录。这也是为什么我坚持把阶段门建在研发项目管理平台上，交付物天然就在那里产生，评审只是对它打一个快照标签。

决策人必须是具体的人，不能是“评审委员会”这样的模糊主体。评审委员会可以是参与者，但最终必须有一个署名的人对这次决策负责。我在实践中通常设置为产品委员会负责人或产品线总经理。

决策记录要包含五段内容：本次决策结论、依据的评分明细、未达标项及其处理方案、资源承诺、门后动作清单与责任人。

2. 准入准则怎么写：一张可打分的评分卡

我不推荐用“全部满足才通过”的一票否决制，因为它会导致两种极端：要么准则定得很松以便通过，要么大量项目卡在门口无法推进。更实用的做法是加权评分卡，总分达标 + 关键项必须达标。

下面这张表是我们在一家 400 人规模的软件企业中实际使用的评分卡结构，你可以直接参考权重分配，但准则内容要按自己的业务特点改写。

规则是：总分低于 3.5 分直接 Recycle；任一关键项低于 3 分进入 Hold 或 Recycle，不接受“整体看起来还行”的模糊判断。这套规则最大的价值不是筛选项目，而是让会前自评变成一件有产出的事，团队会在上会前自己算出结果，主动处理短板。

3. 门的节奏怎么定：跟着不可逆节点走

定节奏的原则只有一个：门要设在“一旦做错就难以挽回”的节点上。不是按时间均匀分布，也不是按开发阶段机械划分。

软件类项目典型的三个不可逆节点是：需求方向确定（投入大量研发前）、架构冻结（大规模编码前）、发布上线准备（面向真实用户前）。硬件类项目可能还会增加“模具开模前”“量产备料前”。

把这些不可逆节点找出来，门的位置自然就定了。倒是不用纠结门该叫 G1 还是 G2，名字不重要，位置才重要。

4. 协同责任矩阵：四种角色，四种责任

阶段门涉及的角色比一般项目活动更多，我用一个简化版的四角色模型来划分责任，比传统 RACI 更贴合阶段门场景。

• 交付责任人：负责某一项交付物的真实产出和质量，在评审会上负责回答专业问题。通常是各职能的技术负责人。
• 评审人：负责依据评分卡给出判断和证据，不负责做最终决策。可以是跨部门专家，需要提前拿到材料。
• 决策人：唯一，对本次门的结论负责，有权批准资源。必须有署名。
• 编排者：项目经理。负责会前齐套、会中流程、会后闭环，不负责对交付物质量做专业判断。

这四种角色的边界必须清晰。我见过最常见的越界是项目经理替交付责任人回答问题，这会让评审人对材料真实性的判断失去依据。项目经理被问住的时候，正确做法是当场把问题转给对应责任人。

5. 三个测试：判断这道门该不该设

1. 不可逆测试：如果这道门被否决，团队能不能实质性地改变方向或终止？如果不能，这道门只是装饰。
2. 信息增量测试：这道门评审时，是否掌握着上一道门没有的新信息（比如预研结论、客户反馈、成本数据）？如果没有，它只是重复评审。
3. 资源有效性测试：通过这道门之后，是否会有实质性的资源投入或释放？如果没有，它不影响任何实际动作。

三个测试里有两个不通过，这道门就应该合并或删除。我用这个标准把某个客户的 6 道门压缩到了 3 道，流程文档从 42 页降到 16 页，而项目经理的流程负担下降了约 60%。

五、案例与数据：用项目管理平台承载阶段门的完整过程

前面讲的都是方法论，这一节讲怎么落地。我以一个实际项目为例，说明如何用研发项目管理平台把阶段门从 PPT 和 Excel 搬到系统里。这里的示例平台选 PingCode，原因是它面向中大型企业和 100 人以上组织，支持私有化部署，也支持从 Jira 平滑迁移，比较贴合我接触的客户群体的实际条件。

1. 为什么不用表格加邮件

很多团队初期用表格管理阶段门：一张交付物清单表、一份评分卡、一堆邮件附件。在前 3 个月通常是有效的，因为人数少、沟通半径短。但当项目数超过 5 个、参与人数超过 40 人时，表格方案会快速失效。

失效的具体表现有三个：交付物状态靠人工更新，平均滞后 3-5 天；评分卡分散在各人手里，无法横向对比；决策记录以邮件形式存在，检索成本极高。我统计过一个客户的情况：查找一次 6 个月前的门决策记录，平均需要 25 分钟，最后往往是问某个人，而不是查系统。

2. 对象建模：把三要素映射成系统对象

把阶段门搬进系统的第一步是对象建模。核心思路是：不要为阶段门单独建一套体系，而是复用研发管理平台已有的工作项模型。这样交付物和研发活动在同一数据空间里，评审时可以直接追溯来源。

我的建模方式是这样的：

• 阶段交付物用独立的工作项类型承载，必填字段包括：所属阶段、责任人、状态、验证方式、关联需求。
• 门评审用另一种工作项类型承载，关联该阶段的全部交付物，并挂载评分卡字段。
• 门后动作用任务类型承载，关联到对应的门评审工作项，形成从决策到执行的链路。

这种建模让“某一项交付物是哪一个决策依据的”这个问题变成了可查询的，而不是靠人回忆。这一点在项目复盘时价值极高。

3. 准入校验：用规则替代人工检查

交付物齐套与否，不该靠项目经理在会前逐条核对。可以在系统里配置准入校验规则，让门评审工作项在条件不满足时无法进入“待评审”状态。下面是一段示意配置，格式参考通用规则引擎的表达方式：

gate: G2_方案冻结
preconditions:

check: deliverable.requirements_spec.status

must_be: approved

on_fail: "需求规格未完成评审"

check: deliverable.architecture_design.attachments

min_count: 1

on_fail: "架构设计文档缺失附件"

check: risk_register.high_level.open_count

max: 0

on_fail: "存在未闭环高风险项"

check: resource_commitment.signed_count

min: 3

on_fail: "职能经理资源承诺未齐"

decision_options: [Go, Hold, Recycle, Kill]

on_decision:

create: next_stage_tasks

notify: [project_manager, function_managers, sponsor]

archive: decision_record_snapshot

这段配置的价值不在于技术实现，而在于它把“准入准则”从文档里的一句话变成了一个可执行的判断。规则一旦可执行，它就不再依赖人的自觉。

4. 三段式流程：会前、会中、会后

系统承载之后，阶段门的运行可以清晰地切成三段，每段有明确的产出。

会前 3 个工作日：交付物锁定，系统自动生成齐套率报告和评分卡自评结果。评审人收到材料并完成预读，预读意见录入系统。项目经理只处理异常项，不做材料搬运。

会中 30-45 分钟：不重复材料内容，只讨论预读中标记的分歧项和未达标项。逐条走评分卡，当场记录决策与条件。决策人确认资源承诺。

会后 1 个工作日：系统自动生成决策记录并归档，同时创建门后动作任务并分派责任人。项目经理在 2 周内跟踪闭环。

这个结构在一家 260 人的企业里跑通之后，门评审的平均会议时长从 108 分钟降到 38 分钟。更重要的是，会议产出的动作清单数量从平均 1.2 条上升到 6.4 条，说明会议真正在解决问题，而不是在完成一个仪式。

5. 数据观察：上线前后 6 个月的对比

我在一个 260 人规模的软件研发组织中跟踪了阶段门上线前后各 6 个月的数据。这里需要说明：这些数据来自单一组织的观测样本，不是行业统计，仅用于说明改善方向，不能直接外推到其他团队。

6. 踩过的坑

工具落地过程中有几个坑值得提前说。第一个坑是字段设计过度：一开始我们给交付物工作项加了 18 个自定义字段，结果一线人员填写负担过重，数据质量反而下降。后来精简到 6 个必填字段，填写率立刻回升。

第二个坑是把门做成纯审批流。最初我们在系统里配了一条串行审批链，结果又回到了“签字仪式”的老路。后来改成“评审工作项 + 评分字段 + 会议纪要附件”的结构，才真正承载了决策过程。

第三个坑是忽略历史数据迁移。如果团队此前使用某海外工具管理需求与缺陷，迁移时要注意关联关系不能丢。我们在一个项目里因为迁移时只搬了工作项没搬关联，导致门的交付物无法追溯到原始需求，后来不得不重新做一次映射。支持平滑迁移的平台在这里会省很多事，但迁移方案本身仍然要提前设计，工具只是降低了成本。

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

方法论相同，落地路径差异很大。这一节我按组织规模和业务特点分几类，给出可以直接采用的行动建议。你可以先找到最接近自己情况的那一类，再参考相邻类别做调整。

1. 100 人以下团队：轻量化，别急着上系统

这个规模下，沟通半径短，信息传递成本低，上重型流程反而是负担。我的建议是只做三件事：定义 2-3 道门、写一张不超过 15 个条目的评分卡、用最简单的看板记录交付物状态。

决策记录可以先用统一的文档模板，不必急于系统化。判断何时该上系统，看一个信号：当项目经理每周花在收集交付物状态上的时间超过 4 小时，就到了该工具化的临界点。

2. 100-500 人组织：这是阶段门收益最明显的区间

这个规模是阶段门价值最大化的区间。跨部门协同开始出现明显的信息损耗，靠会议和口头约定已经不足以保证交付物按时到位。此时应该做的是：3 道门、加权评分卡、明确的决策人、系统化承载。

这类组织通常已经有研发管理平台，建议直接在其上建模，不要另起一套。选择平台时重点看三点：是否支持自定义工作项类型和字段、是否支持状态流转校验、是否支持私有化部署。对于有数据合规要求的中大型企业，私有化部署能力往往是硬性条件，这也是很多 100 人以上组织在选型时的现实约束。

3. 500 人以上多产品线：先统一框架，再允许差异

这个规模最大的风险是各产品线各自为政，导致数据无法横向对比。我的建议是先定一个统一框架，门的位置、评分卡维度、决策记录结构这三项必须统一，其余细节允许各产品线自定义。

同时建议在组合层面增加一次季度级的组合评审，把所有产品线的门决策结果放在一起看，重点关注资源在 Hold 和 Recycle 项目上的沉淀情况。我见过的一个案例是：某企业 12 个在研项目中，有 4 个长期处于 Hold 状态却不释放资源，占用的人力相当于 1.5 个完整团队。这种问题只有组合层面才看得见。

4. 强监管行业：把合规证据做成副产品

医疗器械、汽车电子、航空等行业的阶段门，天然要与法规要求的评审活动对齐。我的建议是不要把阶段门和合规评审做成两套独立的活动，而是让阶段门成为合规证据的产出过程。

具体做法是在交付物清单里直接纳入法规要求的文档类型，决策记录的结构按审计要求设计。这样一次评审同时满足内部决策和外部审计两种需求，避免重复劳动。

5. 从海外工具迁移过来的团队：先对齐概念，再搬数据

很多团队此前使用某海外项目管理工具，迁移时容易犯的错误是“照搬字段”。不同工具的模型语义不同，直接映射往往会导致阶段门结构在新平台上变形。

正确的顺序是先在新平台上重新设计阶段门对象模型，明确工作项类型、字段和状态流转，然后再做数据映射。迁移的重点不是把历史数据一条不落地搬过来，而是保证在研项目门相关数据的关联关系完整。已经归档的历史项目，保留只读快照通常就足够了。

七、不同情况下的取舍

阶段门落地过程中，几乎每一个决策都是在两难中做选择。这一节我列出四组最常见的取舍，并给出我的判断倾向和理由。

1. 门的数量 vs 决策质量

这是最核心的一组取舍。门越多，理论上风险拦截点越多；但门的数量超过评审人的注意力容量后，每一道门的质量都会下降。我的判断是：宁可少一道门，也不要多一道形式门。

具体到数字，我的经验区间是 2-3 道。超过 4 道就需要有非常明确的理由，比如强监管行业有法规强制的评审节点，或者技术复杂度极高、每个阶段都有不可逆投入。

2. 流程刚性 vs 执行效率

流程越刚性，一致性越好，但灵活性越差。我见过两种极端：一种是把所有项目都塞进同一套门，导致小项目被大流程压垮；另一种是完全放开，每个项目自定流程，导致数据无法横向对比。

我的取舍倾向是：框架刚性，细节弹性。门的位置、评分卡维度、决策记录结构这三项统一；交付物清单、评审参与人、会议形式可以按项目类型调整。这样既保证数据可比，又不至于让轻量项目背上重流程。

3. 工具化 vs 轻量化

工具化带来可追溯性和自动化，但也带来建模成本和维护成本。轻量化上手快，但在规模扩大后会遇到瓶颈。这组取舍的关键变量是人数和项目数。

我的判断基线是：项目数超过 5 个、核心参与人超过 40 人，工具化的收益就开始超过成本。低于这个规模，用文档和表格反而更灵活。不过要注意，工具化的投入主要集中在前期建模，收益是长期累积的，所以决策时不要只看第一个季度的投入产出。

4. 统一流程 vs 因地制宜

多产品线组织经常会遇到这个问题：不同产品线的研发模式差异很大，硬套统一流程会引起反弹。我的做法是允许差异化的执行层，但保留统一的度量层。

具体来说：产品线可以用不同的交付物清单和评审形式，但必须产出结构相同的决策记录，并上报相同的核心指标（齐套率、闭环率、返工率、决策分布）。这样既尊重业务差异，又能在组合层面做对比和资源调配。

八、总结：阶段门真正的独特价值在哪

回到最开始那个反常识的判断。阶段门的价值不在于“控制”，而在于“让组织有机会在正确的时点承认自己判断错了”。一个只会通过的门，实际上剥夺了组织纠错的机会。

我见过最健康的一个例子，是一家 200 人左右的企业。他们在一次方案冻结门上，用 35 分钟把一个已投入 4 个月的项目判为 Recycle，原因是关键技术预研数据显示性能目标无法达到。项目重做后延后 2 个月上线，但因为方向正确，最终成为该公司当年营收贡献最高的产品之一。评审会上没有人觉得这是失败，反而觉得这次 35 分钟价值极高。

这就是阶段门真正独特的地方：它把“止损”从一个痛苦的个人决策，变成了一个被组织流程支持的集体决策。当 Kill 和 Recycle 有了明确的操作路径、有了制度化的记录方式、有了资源释放的配套动作，人们才敢做这些决策。反过来，如果流程只允许 Go，那么所有人都会选择 Go。

如果你现在正准备从 0 到 1 搭阶段门，我建议下一步按这个顺序做四件事。

1. 先找不可逆节点，不要先画流程。拿一张纸，列出你们项目从立项到交付过程中一旦做错就难以挽回的 3 个时点，门就设在这里。
2. 把评分卡写出来，每条准则都要能被判定。删掉所有形容词，换成数字、比例或状态。写不出来说明准则还没想清楚。
3. 指定唯一的决策人，并明确四类决策选项。没有唯一决策人和多选项结构，门就是表态会。
4. 确定承载方式，先跑通一次完整流程再谈优化。用文档或平台都可以，关键是完整走一遍门前的齐套检查、会中的评分表决、会后的动作追踪。

跑完一次之后，你会立刻发现哪些环节在空转。那时候再决定要不要上系统、要不要调整门的数量，判断会比现在准确得多。阶段门从来不是一次设计就能定稿的东西，它更像一套需要持续校准的判断机制，而校准的前提，是你先真的跑过一次。