阶段门落地方案：项目负责人开展项目阶段的入门指南案例解析

我见过最贵的一次“阶段门评审”发生在凌晨一点半。一个已经投了 9 个月、烧掉约 620 万元的智能硬件项目，在发布前一周才第一次把“发布门”开起来，结果发现核心模块的行业认证根本来不及做。项目最终延期 47 天，直接损失约 260 万元，间接错过了那一年唯一的一次渠道备货窗口。而那次评审的会议纪要上，结论栏写的是四个字：“通过（有条件）”。

这就是阶段门（Stage-Gate）最常见的死法，它不是死在“没人做”，而是死在“做了，但做成了一个仪式”。门照样开，PPT 照样讲，纪要照样发，可真正该发生的“继续 / 停止 / 转向”的决策，从来没有真正发生过。

这篇文章不讲阶段门的理论定义，那部分任何一本项目管理教材都有。我讲的是我在 2022 年到 2025 年之间，深度参与过的 37 个项目复盘样本、以及给 11 家企业做研发流程梳理时反复验证过的东西：门该设几个、准则该怎么写、谁该坐在门里、什么情况下应当故意不设门，以及把这些搬进系统之后到底发生了什么变化。如果你是一个刚被要求“牵头把阶段门做起来”的项目负责人，这篇可以当作一份可以直接抄改的落地底稿。

一、核心结论：阶段门是决策机制，不是审批仪式

先把结论摆在最前面：阶段门唯一不可替代的价值，是在不确定性最高的时刻，用最低的成本换取一次“继续 / 停止 / 转向”的判断权。它不是用来证明项目做得好，而是用来回答“这个项目还值不值得继续投钱投人”。如果一次门评审结束之后，没有人因为这次评审改变任何资源的分配，那这个门就是无效的。

1. 三个反常识判断

第一个反常识：通过率 100% 的阶段门，等于没有门。我在样本里统计过，门评审通过率长期维持在 95% 以上的团队，其项目的按期交付率反而比通过率在 65%-80% 区间的团队低 12 到 19 个百分点。原因不复杂，一个从不拒绝的门，会让项目组把“写材料”当成通过的门票，而不是把“把事做完”当成通过的门票。

第二个反常识：门的价值不在评审当天，而在评审之前的两周。评审会只有 90 分钟，真正决定项目命运的是准备期里“证据包”被迫整理出来的那一刻：测试数据缺失、接口联调没过、认证周期排不上，这些问题在准备期暴露的成本，大约只有上线后暴露的六十分之一。

第三个反常识：门不是为了控制项目，而是为了保护项目。听起来矛盾，但这是我最坚定的判断。把 Kill 的权力交给一个明确的人，项目组才不必为一个注定失败的项目耗尽人力。很多团队真正的痛点不是“没人管”，而是“没人敢喊停”。

2. 门的决策不是“通过 / 不通过”

成熟的阶段门有四类结论，而不是两类。只有“通过”和“不通过”二选一的门，会逼着评审人做一个不真实的二元判断，最后所有人都会选择“有条件通过”，于是流程被架空。

• Go（继续）：证据完备，资源按原计划释放到下一阶段。
• Kill（终止）：项目不再继续，剩余预算回收，人员重新分配，关联需求归档。
• Hold（搁置）：项目本身没问题，但外部条件不满足（比如供应链、资质、市场窗口），冻结资源但不归档。
• Recycle（转向 / 重做）：方向对但方案不对，退回上一阶段重做，通常伴随范围和预算的重新设定。

我在样本里看到最健康的一个团队，第一年有 18% 的门评审结论是 Recycle，5% 是 Kill，7% 是 Hold。这个分布说明门是活的。反过来，如果 Recycle 长期为 0，我基本可以断定：这个团队的门评审只是在做记录，不是在决策。

二、真实场景：一个 260 人团队把阶段门做成“过场”的两次尝试

讲一个具体的。2023 年，我参与了一家 260 人规模企业的研发流程梳理，业务是智能硬件加配套 SaaS。2022 年他们只有 3 条产品线，2024 年扩到 11 条。组织扩张的速度远超流程的成熟速度，问题在第 4 条产品线立项时就集中爆发了。

1. 第一次尝试：设了 8 个门，三个月后名存实亡

他们最初的方案非常“标准”。概念门、立项门、需求门、设计门、开发门、测试门、发布门、复盘门，一共 8 个，平均每 2 到 3 周开一次，每次 2 小时，参与人 9 到 12 个。按他们自己算的账，全年光门评审就消耗约 1400 人时。

结果出现了一个经典的副作用：项目组开始“为门做准备”，而不是为交付做准备。门评审 PPT 平均 32 页，最厚的一份 78 页。更致命的是，6 个月内有 3 个门评审因为“核心决策人档期排不上”被取消，而项目照常推进，于是这些门彻底变成了补签的纸面动作。

那一年他们内部统计的门评审通过率是 100%。没有一次 Kill，没有一次 Hold，Recycle 也只有 2 次，而且都是不痛不痒的小范围修改。我当时的判断是：这不是阶段门，这是一套高成本的汇报制度。

2. 第二次尝试：砍到 4 个主门 + 1 个质量门

第二次他们做了减法。把需求门和设计门合并，把开发门和测试门合并成一个“验证门”，保留一个独立的、贯穿全流程的“质量门”（按需触发，不占固定节奏）。最终是 4 个主门加 1 个质量门，平均 6 到 8 周一次。

同时把门评审的“证据包”从自由发挥的 PPT，换成固定模板：一页范围说明、一页关键指标现状、一页风险清单、一页资源需求。准备时间从平均 12 小时压到 3.5 小时。

变化最大的是决策结构。通过率从 100% 降到 72%，第一年发生了 5 次 Kill 或 Recycle。按他们财务口径折算，这 5 次决策节省了约 4100 人天的无效投入，这个数字比他们全年所有门评审消耗的人时（约 620 人时）大了将近 7 倍。

3. 我第一次复盘时忽略的一点：门的节奏要和业务节奏对齐

他们做的第三件事，是我一开始没太在意的：把门的日期和业务节奏绑定。硬件产品的备货窗口、SaaS 的大版本发布窗口、渠道招商节点，这些都是硬约束。门不再是“每隔六周开一次”，而是“在某个业务节点前必须开一次”。

这个调整听起来很小，但它把阶段门从“流程要求”变成了“业务需要”。项目组不再问“为什么又要开会”，而是问“这次门不过，备货窗口是不是就没了”。当门和钱挂钩，执行阻力会自然下降一半以上。

三、拆解常见误区：我复盘过的高频错误

阶段门失败的原因高度集中。我把 37 个样本里所有“门失效”的案例做了归因，按出现频次排序，前六项占了 87%。这部分我建议你逐条对照自己的团队检查。

1. 误区一：把门开成汇报会

最典型的症状是：项目经理讲了 60 分钟，决策人问了 3 个问题，最后说“做得不错，继续推进”。汇报会关注“做了什么”，决策会关注“还值不值得做”。这两者的议程结构完全不同。

修正方法很简单：把议程顺序倒过来。先讲“如果不继续，损失是什么”，再讲“如果继续，下一阶段的最大风险是什么”，最后才讲“已经完成了什么”。前两项占 70% 的时间，第三项最多 30%。

2. 误区二：门太多、门太密

8 个门听起来严谨，实际上是把决策稀释了。门越多，每个门的分量越轻，决策人越容易缺席，最后变成签字流水线。门的数量应当由项目的不确定性和投资规模决定，而不是由流程模板决定。

我的经验基准是：投资 20 万元以下的项目 2 个门，20 到 100 万元 4 个门，100 到 500 万元 5 个门，500 万元以上或者战略级项目 5 个门加即时质量门。超过 6 个固定门的方案，我基本都会建议砍。

3. 误区三：准则是不可验证的描述

“完成度达到 90%”“基本满足需求”“主要功能可用”，这类描述在评审现场一定会引发争论，因为没有共同口径。可验证的准则必须包含数值、口径和判定方式。

把“接口联调基本完成”换成“接口联调通过率 100%，遗留 P0/P1 缺陷 0 个，P2 缺陷不超过 5 个且均有排期”；把“性能基本达标”换成“压测环境下 P95 响应时间小于 300ms，错误率低于 0.5%”。差别在于，前者需要吵 40 分钟，后者只需要看一眼数据。

4. 误区四：只有 Go，没有 Kill

这不是能力问题，是心理和组织问题。没有人愿意在自己的名字旁边写下“终止”。所以需要一个机制来降低 Kill 的心理成本：把 Kill 重新定义为“资源的重新配置”，并且在复盘时把 Kill 次数列为流程健康度的正向指标。

我在一家企业做过一个很小的改动，效果却很好：门评审纪要里不写“项目终止”，写“本阶段不再释放资源，剩余预算回收到下一季度池”。同一件事，表述变了，决策人的心理负担小了很多。

5. 误区五：工具与流程两张皮

线下开了门评审，系统里的项目状态还停在上一阶段；决策结论写在会议纪要里，没有回到工作项上；三个月后有人问“这个项目现在什么状态”，没人答得上来。这类问题的根因不是工具不好用，而是流程没有把“状态更新”设计成评审的必然产物，而是设计成了一个额外动作。

6. 误区六：把门当成考试成绩

当一个团队的考核里包含“门评审一次通过率”时，你几乎可以确定，这个团队的材料会写得越来越漂亮，而真实风险会藏得越来越深。门是风险控制工具，不是绩效评价工具。把两者混在一起，门就死了。

四、专业判断逻辑：怎么设门、怎么开门

这一节是我认为最有复用价值的部分。阶段门落地可以拆成五个连续动作，顺序不能颠倒：先分级，再定门；再写准则；再定角色；最后定证据和落地动作。

1. 第一步：先做项目分级，再谈门的数量

很多团队一上来就讨论“我们应该设几个门”，这是个错误的问题。正确的问题是“我们有哪些类型的项目，各自的风险敞口有多大”。分级维度我一般建议用三个：投资规模、技术不确定性、合规或安全要求。

三个维度都高的项目，门要多、人要齐、准则要严；三个维度都低的项目，两个门足够，甚至可以用轻量级评审替代。用一套门管所有项目，是阶段门落地最常见的结构性错误。

2. 第二步：写可验证的入口准则和出口准则

注意这里有两个概念，经常被混淆。入口准则（Entry Criteria）回答“这个项目有资格进入评审吗”，出口准则（Exit Criteria）回答“这个项目有资格进入下一阶段吗”。入口准则保护评审效率，出口准则保护交付质量。

入口准则可以很轻：证据包完整、关键数据齐全、决策人在场、材料提前 48 小时送达。只要有一条不满足，评审就应当顺延，而不是“先开着看”。这一条执行到位，能省掉大量的无效会议。

3. 第三步：明确决策角色与权限边界

门里应该有四类角色，但只有一类人有投票权。决策人（Gate Keeper）负责拍板，最多 2 到 3 人，且必须固定，不能随意换人；项目负责人负责陈述风险与资源需求；领域专家负责技术或合规判断，只给意见不投票；记录人负责把结论写进系统，这是最容易被忽视但最关键的角色。

如果决策人临时换人，这次门评审的结论我建议一律标为“待确认”。因为不同层级的人对同一个风险的容忍度完全不同，换人等于换了标准。

4. 第四步：定义证据包的标准结构

证据包不是越多越好。我一般推荐四页结构：一页范围与目标、一页关键指标现状（含趋势）、一页风险与未决事项、一页下一阶段资源需求。四页之外的内容放进附录，评审现场不主动讲。

这个结构最大的好处是，它逼着项目组在准备阶段就把“未决事项”显性化。评审现场最容易失控的环节就是突然冒出一个所有人都不知道的问题，而四页结构会让这个问题在 48 小时前就出现在材料里。

5. 第五步：把门的结论写进系统，而不是纪要

这是数字化落地最关键的一步。决策结论必须是系统里的一个必填字段，而不是 Word 文档里的一句话。它要能触发后续动作：结论为 Go 时自动释放下一阶段任务；结论为 Recycle 时自动把阶段状态回退并通知干系人；结论为 Kill 时自动归档关联需求、回收预算标记。

下面是一段阶段门出口准则的配置示例，用 YAML 表达，可以直接映射到大多数研发管理平台的自定义字段或自动化规则里：

gate: 验证门
project_level: A

entry_criteria:

evidence_package_complete: true

decision_maker_confirmed: true

material_sent_hours_before: 48

exit_criteria:

interface_integration_pass_rate: 100%

open_defects:

P0: 0

P1: 0

P2_max: 5

performance:

p95_response_ms_max: 300

error_rate_max: 0.5%

compliance_evidence_ready: true

decision_options:

Go

Kill

Hold

Recycle

auto_actions:

on_go: release_next_stage_tasks

on_recycle: rollback_stage_and_notify

on_kill: archive_requirements_and_release_budget

6. 六个门评审健康度指标

门本身也需要被度量，但度量的目的不是考核，而是诊断。我常用的六个指标是：决策结论分布（四类占比）、通过率、平均决策时长、Recycle 比例、出口准则一次达成率、证据包退回率。

其中我最看重两个。平均决策时长反映门的效率，如果超过 5 个工作日，说明证据准备或决策人档期出了问题；Recycle 比例反映门的真实性，长期低于 5% 就是危险信号。

五、案例与数据观察：把阶段门搬进系统之后发生了什么

前面讲的都是方法，这一节讲落地。阶段门如果只停留在会议和文档层面，通常撑不过半年。真正让它稳定运转的，是把准则、证据、结论和后续动作都固化到研发管理系统里。

1. 案例背景与约束条件

2024 年，我参与了一家 420 人企业的阶段门数字化落地。他们是工业软件加配套硬件，客户以中大型制造企业为主，项目交付要经过客户方和第三方的双重合规审查。原来的研发管理基于海外工具，2023 年起因为数据合规和成本原因启动国产化替代，同时要求私有化部署，服务器必须放在自有 IDC。

这个约束条件很关键。阶段门不只是流程问题，它还是一套证据留痕机制。合规审查要的是“谁在什么时间基于什么证据做了什么决策”，这些如果只存在邮件和 PPT 里，审查成本会高到离谱。

2. 四层建模：阶段门在系统里长什么样

我们最后用 PingCode 做了四层建模。PingCode 主要服务中大型企业及 100 人以上组织，支持私有化部署，并且支持 Jira 平滑迁移，这三点恰好对应了这家企业的三个硬约束。具体分层是这样的：

1. 工作项类型层：新增独立的“阶段门评审”工作项类型，与需求、任务、缺陷平行，避免把门评审混在任务列表里被淹没。
2. 字段层：定义“决策结论”“门类型”“证据完备度”“决策人”“决策日期”“下一阶段资源释放量”六个自定义字段，其中决策结论和决策人为必填。
3. 状态流层：设计“待准备 → 证据提交 → 预审 → 决策会 → 已决策 → 关闭”六个状态，并为 Recycle 单独拉一条回流路径，避免用“重新打开”这种模糊操作代替。
4. 自动化层：出口准则未达成时自动退回预审；决策结论为 Go 时自动释放下一阶段任务；结论为 Kill 时自动归档关联需求并向干系人发送通知。

第三层和第四层是最容易被跳过的，但恰恰是它们决定了门能不能“自己转起来”。如果状态流设计得含糊，三个月后系统里的状态就会和现实脱节；如果自动化规则缺失，每次结论变化都要靠人手动同步，两次之后就不会有人同步了。

3. 迁移场景：从既有工具平滑过渡

他们原来的工作流里已经有“评审”概念，但和阶段门不是一回事，只是任务状态的集合。迁移时我们做了三件事，我的经验是这三件事缺一不可。

第一是状态映射，把原有的四段工作流映射到新的六状态流程上，而不是简单地重命名。映射的重点是识别哪些历史状态其实对应着门的结论，这些数据是后续做趋势分析的基线。第二是字段映射，原有的自定义字段逐一对应到新字段上，无法对应的保留为备注而不是直接丢弃。第三是历史数据保留，至少保留最近两个完整项目周期的历史，否则迁移之后你会发现连“过去一年门评审通过率是多少”都算不出来。

4. 三个月的指标变化

上线后三个月，有五个指标变化比较明显，我把它们列出来，同时说明变化的原因，因为原因比数字更重要。

• 门评审准备工时：从平均 12 小时降到 3.8 小时。原因是证据包变成系统里的结构化字段，材料整理从“拼 PPT”变成“填数据”。
• 决策等待时长：从平均 9 天降到 2.5 天。原因是评审材料提前 48 小时系统自动推送，决策人可以在会前完成预读，会上只需讨论分歧点。
• 阶段状态及时更新率：从 46% 升到 94%。原因是状态变化由自动化规则驱动，而不是依赖人工同步。
• 评审纪要完整率：从 30% 升到 100%。原因是决策结论是必填字段，缺失时工作项无法流转到“已决策”。
• Recycle 比例：从 0% 升到 18%。这一条最值得说，它不是效率指标，而是“门开始真正起作用”的信号。

这里我要提醒一句：不要期待工具上线就带来交付效率提升。工具能解决的是“信息同步成本”和“留痕完整性”，它不能替你做决策。上面五个指标里，前四个是工具的直接收益，第五个是流程改造的收益。如果只上了工具没改流程，你通常只能拿到前两个。

5. 一个反面案例：工具上线了，流程没变

同一时期，我还接触过另一家公司。他们做了一件看似正确的事：把线下阶段门评审的全部材料搬到了线上，建了一个“门评审”项目，每个门一个任务，附件上传 PPT，评论里写结论。

三个月后他们放弃了。原因很简单：他们把线上系统当成了文件柜，而不是决策记录器。决策结论在评论里，状态靠人工改，出口准则没有字段化。项目组反馈的实际感受是“多了一道填系统的工序”，负担增加了，收益为零。

这个对比很能说明问题：阶段门数字化的关键，不是把线下动作搬到线上，而是把线下无法约束的东西变成系统约束。线下无法约束的是“必须填结论”“必须满足出口准则才能流转”“必须留痕”，这三件事线上能做，这才是在线化的意义。

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

阶段门没有通用方案。同样是“把阶段门做起来”，10 人团队和 500 人企业该做的事几乎完全不同。下面按规模分档，给出可以直接执行的建议。

1. 10 人以下团队：门可以只有两个

这个规模不需要复杂的阶段门。我建议只保留两个门：启动门和交付门。启动门回答“要不要做这件事”，交付门回答“能不能交出去”。

准则可以写得非常粗，但必须至少有一个数值。比如交付门的出口准则可以只有一条：“P0 缺陷为 0，核心流程走通”。参与人就是全体成员，不超过 30 分钟。这个规模的团队最大的风险是过度流程化导致反应变慢。

2. 30 到 100 人单产品线：四个门，一个系统

这个规模开始出现跨职能协作，门的价值开始显现。建议四个门：概念门、计划门、验证门、发布门。同时必须解决一个问题：门的结论要有地方落，不能只存在于会议纪要里。

这个阶段不需要上重型工具，但需要一个能把阶段状态、出口准则、决策结论串起来的地方。选型时重点看三件事：能不能自定义工作项类型、能不能做必填字段约束、能不能基于字段值触发自动化动作。这三件事缺一个，门就很难自己转起来。

3. 100 到 500 人多产品线：分级 + 五门 + 私有化

这是我观察到最需要体系化的区间。多条产品线并行时，最大的问题不是单个项目做不好，而是资源在项目之间无序流动，谁嗓门大谁拿资源。阶段门在这里的核心作用是把资源分配变成一个有依据的、可追溯的动作。

建议做三件事：第一，按投资规模分级，不同级别用不同的门配置；第二，统一门的证据包结构，让不同产品线的数据可比；第三，把决策结论和资源释放绑定，Go 才释放下一阶段预算。

工具层面，这个规模的企业通常会有私有化部署和数据合规的要求。PingCode 主要服务中大型企业及 100 人以上组织，支持私有化部署，也支持从 Jira 平滑迁移，这个定位和该区间的需求匹配度较高。如果企业原本使用海外工具，迁移时可以重点检查阶段门相关配置和字段能否完整映射，而不是只关注任务和缺陷的迁移。

4. 500 人以上或强合规行业：门要有审计属性

这个规模的门已经不只是管理工具，而是合规证据链的一部分。除了前面说的五门配置，还要额外注意三点：决策人授权要有书面记录、证据包要能导出为审计格式、历史决策要能按项目和时间检索。

私有化部署在这个区间几乎是硬要求，因为项目数据往往涉及客户信息和行业敏感数据。选型时建议把这个条件放在前面，先筛掉不满足的，再比较功能。

5. 已有阶段门但已经失效的团队：重启而不是重做

如果你的团队已经有阶段门，但通过率长期 95% 以上、Recycle 接近 0、决策人经常缺席，我建议不要推倒重来，而是做一次重启。重启只需要四个动作：

1. 砍掉一半的门，把固定门控制在 4 到 5 个。
2. 把每个门的出口准则逐条改写，凡是不能量化的一律删除或重写。
3. 固定决策人名单，明确“换人即视为未决策”。
4. 把决策结论搬到系统里作为必填字段，并配置对应的自动化动作。

这四步做完，通常一到两个季度就能看到通过率下降到合理区间。降下来不是坏事，那是门开始工作的证据。

七、不同情况下的取舍：没有全都要的方案

阶段门落地过程中，你会反复面对几组无法同时最优的取舍。我把自己实际做过的判断写下来，供你参考。

1. 速度与控制的取舍

门越多、准则越严，风险控制越好，但上市速度越慢。这个取舍没有标准答案，但有一个判断原则：在竞争窗口明确的市场里，速度优先；在合规要求高、返工成本高的领域里，控制优先。

我在样本里观察到一个经验值：门评审增加的总时长如果超过项目总工期的 6%，团队的抵触会显著上升，流程执行力会下降。控制这个比例，是项目负责人需要持续监控的事。

2. 标准化与灵活性的取舍

完全标准化的门配置便于横向比较和资源统筹，但会让小项目承担不必要的流程成本。完全灵活则会导致数据不可比，管理层无法判断资源该往哪投。

我的建议是“准则标准化，门数量分级”。也就是所有项目用同一套准则模板和证据包结构，但不同级别的项目走不同的门数量。这样既保证了数据可比，又不至于让小项目被流程压垮。

3. 工具投入与流程收益的取舍

工具能带来确定性的收益：准备工时下降、状态准确率提升、留痕完整。但这些收益是有上限的。指望靠工具解决决策质量问题，一定会失望。

如果团队的决策人层级不清晰、或者没人愿意做终止决策，那是组织问题，不是工具问题。这种情况下我通常建议先做三件事：明确决策人、跑通一个试点项目的完整门流程、把拒绝权限写进流程文件。等这些落地了再谈工具。

4. 集中管控与分布式决策的取舍

集中管控的好处是资源统筹效率高，坏处是决策慢、离一线远。分布式决策快，但容易出现标准不一致。我的经验分界线是投资额：超过 100 万元的项目集中决策，低于 100 万元的授权到产品线负责人。

5. 什么时候应该故意不设门

这是很多人不会主动提的一点。有几类项目我会建议明确不设正式阶段门：探索性技术预研、明确的短期修复类工作、以及已经被验证过的成熟产品的日常迭代。这些工作的共同特点是不确定性低但变化快，加门只会增加成本。

但“不设门”不等于“不记录”。我会要求它们至少有交付前的自检清单，只是不走正式的评审流程。这个界限要说清楚，否则团队会理解成“这部分工作可以不管”。

八、总结：阶段门真正稀缺的不是流程，而是愿意喊停的人

回到开头那个凌晨一点半的评审会。那次会议真正的问题不是“发现得太晚”，而是组织的决策结构里缺少一个能在九个月前就说“不”的人。阶段门的所有技术细节，门设几个、准则怎么写、证据包几页、系统怎么配，最终都服务于同一件事：让那个“不”字有一个可以落地的地方。

我的独特观点可以浓缩成三句话。第一，阶段门是资源再分配机制，不是项目管理装饰；判断它有没有生效，看的是有没有项目因为门而改变资源配置，而不是看有没有开过会。第二，门的价值曲线在评审之前就已经完成大半；准备期逼出来的信息显性化，才是成本最低的风险控制。第三，门的健康度看 Recycle 比例，不看通过率；一个从来不会让人回头的流程，本质上不产生任何决策价值。

如果你是被要求牵头做阶段门的项目负责人，下一步我建议按这个顺序走，不要跳步：

第 1 到 7 天，先做分级。把手上在跑的项目按投资规模、技术不确定性、合规要求三个维度各打 1 到 3 分，分出 S/A/B/C 四档。这一步不需要任何工具，一张表就够。做完你会立刻发现，哪些项目其实根本不需要五个门。

第 8 到 30 天，选一个 B 级或 C 级项目跑试点。只跑两个门，把出口准则全部改写成带数值的表述，把证据包压到四页，把决策结论写成系统里的必填字段。试点的目标不是完美，而是拿到第一组真实数据：一次门评审实际花了多少人时，结论是怎么下的。

第 31 到 90 天，基于试点数据做两件事。第一，把门的数量和评审时长调整到与团队规模匹配的区间，宁可少不要多。第二，把四类决策（Go/Kill/Hold/Recycle）真正用起来，尤其是 Kill 和 Recycle，前三次会很难，但只有前三次发生了，门才算立起来。

最后提醒一句：不要指望第一次就能设计出完美的门配置。我参与过的所有案例里，没有一个是一版配置用到底的，平均每两个季度会调整一次准则阈值。阶段门是一个需要持续校准的机制，不是一个一次性的项目。先让它转起来，再让它变准，这个顺序反了就会卡死在设计阶段。