项目阶段如何做好阶段门？产品经理入门指南与操作步骤

2023 年 Q3，我们一条投入 4 个研发小组、年度预算 380 万的产品线，在阶段门评审会上以 9:1 的票数拿到了 Go 决策。六周后功能上线，首月付费转化 0.9%，而立项材料里白纸黑字写着 4.5%。复盘时最刺眼的不是判断错了，而是那次评审的 32 页材料里，没有一页是真实付费意愿的证据，所有人都在用”功能完成度 92%””测试用例通过率 96%”当作绿灯。

那次事故之后我把阶段门的写法整个推翻重做。我发现，绝大多数产品经理做不好阶段门，不是因为不认真，而是因为从一开始就把阶段门理解成了”交付物验收会”，而不是”不可逆投入的再授权”。这两个理解之间的差距，决定了这个门到底是在挡风险，还是只是在制造一堆签字文件和会议纪要。

这篇指南写给三类人：第一次接手阶段门、手里有跨部门资源要协调的产品经理；正在从零搭建或重构产品流程的 PMO；以及在中大型组织里需要向管理层解释”为什么这个项目该停”的产品负责人。我会先给结论，再讲我踩过的坑，最后给出可以直接照做的操作步骤和取舍判断。文中的内部观察数据来自我在两家公司先后带过的产品线与 2023，2024 年的版本记录，口径会在每处标注；涉及行业基线的部分我会说明来源或明确标注为示意数据。

一、核心结论：阶段门管的不是交付物，是”不可逆投入的再授权”

在展开之前，我把最关键的几个判断先摆出来。如果你只读这一段，也应该能拿去做一次阶段门自查。

1. 阶段门唯一要回答的问题是”要不要继续投下一笔钱”

阶段门（Stage-Gate）这个概念最早由 Robert G. Cooper 在 1980 年代提出，原始语境是新产品开发：把开发过程切成若干”阶段”，在阶段之间设置”门”，由跨职能决策者根据证据决定 Go / Kill / Hold / Recycle。它的核心不是检查你干了多少活，而是决定下一阶段的资源要不要给。

所以一个门开得好不好，判断标准特别简单：这次评审会结束后，有没有出现任何一项资源的重新分配，加人、撤人、砍预算、换方向、停止项目。如果一个季度过去了，所有项目都顺利过门，没有任何一次 Redirect 或 Stop，那你的门不是严格，而是失效。它已经不产生决策，只产生仪式。

2. 好门的三件套：可验证的准入条件、有资源权的门主、明确的后续动作

我见过太多团队把精力花在”评审材料模板”上，却忽略三件真正决定门成败的东西。第一是可验证的准入条件：不是”用户调研已完成”，而是”20 个目标客户中至少 8 个完成含采购流程节点的付费意向确认”。第二是有资源权的门主：门主必须能当场决定给人、给人减、还是把项目挂起，否则他只是个会议主持。第三是明确的后续动作：Go 之后 48 小时内，谁做什么、哪笔预算释放、下一个门的日期和条件是什么。

这三件套缺任何一件，阶段门都会退化成”汇报 + 鼓掌”。我带过的第一个团队就是典型：门主是产品总监，看起来很权威，但他既不管研发排期也不控预算，每次过门只能表态”支持，希望大家加快”。结果是所有项目都过，所有项目都慢，资源永远不够分。

3. 门要开在不可逆投入点上，而不是日历上的固定间隔

很多团队的阶段门是按时间设的：每 6 周一个门。这是最省事也最无效的做法。正确的做法是找”不可逆投入点”，一旦花出去就很难收回或收回成本极高的那笔钱。

对 SaaS 产品，不可逆点通常是”招齐并培训一支 8 人的交付团队”和”对外承诺发布日期”；对硬件产品，是”开模”和”批量投料”；对平台型内部系统，是”要求其他三个业务线改造接口”。门的价值，在于它开在这些点之前，而不是开在周报的页脚上。

4. 门的数量：3 到 5 个通常最舒服

Cooper 本人在多篇回顾性研究中反复强调，淘汰纪律比创意数量更能区分成功者和失败者。但”淘汰纪律”不等于”门越多越好”。我在内部做过的统计是：一个 100～300 人规模的组织，阶段门从 6 个减到 4 个之后，平均立项周期缩短了约 22%，而重大返工（返工超过 2 个迭代）的比例几乎没有上升。原因很直接，多余的门并不增加信息，只增加排队时间。

二、背景和真实场景：为什么敏捷时代阶段门反而更被需要

很多人以为阶段门是瀑布时代的遗物，敏捷了就该丢掉。我的观察恰恰相反：组织越大、并行项目越多、资源越紧张，阶段门反而越被需要。因为它解决的问题不是”怎么开发”，而是”怎么分配稀缺的人和钱”。

1. 阶段门在敏捷时代存活的三个理由

第一，不可逆投入变多了而不是变少了。云成本、数据合规、多端适配、生态合作，任何一项都可能形成长期承诺。迭代可以每两周调整，但已经签下的合同、已招进来的人、已经对外发布的技术方案，调整周期是季度甚至年度。

第二，资源分配需要跨部门的公共语言。当三个产品线同时要同一批后端架构师时，靠产品经理之间私下拉通很难长期成立。阶段门提供的是一个公开、可追溯、有决策权的分配机制。

第三，合规与审计要求。金融、医疗、汽车电子这类行业，监管方要看的不是你迭代多快，而是你能不能证明”在投入放大之前做过风险评估并且有记录”。

2. 我经历的三种典型场景

场景一：企业级 SaaS 公司，180 人研发，7 条产品线共用一套中台。这里的阶段门核心矛盾是”中台排期”，门评审实际上是在抢中台资源，因此门主必须是能拍板中台优先级的人。

场景二：智能硬件公司，研发 260 人，主控板开模一次约 40～60 万。这里的门是硬门，开模前的那次评审是真正的生死线，其他门都可以轻量化。

场景三：集团内部数字化平台，需求来自 5 个业务单元。这里的门最难开，因为”客户”是内部兄弟部门，很难说 Stop。我的做法是把这个场景的门从”要不要做”改成”业务单元愿不愿意共同出资或出人”，用共同投入代替主观意愿判断。

3. 阶段门失灵的四个信号

信号一：连续三个季度没有出现一次 Stop 或 Redirect。这几乎可以确定门已经形同虚设。

信号二：评审材料的主要篇幅是进度和完成度，而不是假设、证据和风险变化。如果你的幻灯片前十页都是甘特图，说明你在开进度会。

信号三：门主在会后不签字也不批资源，或者签了字但资源迟迟不到位。这说明门主没有实际决定权。

信号四：会议时长持续超过 3 小时且议题发散。这通常意味着准入条件没有提前校验，把本该在会前解决的问题搬到了会上。

这组数据来自我 2023，2024 年跟进的一条 SaaS 产品线的内部记录，统计口径是：一次通过率 = 首次评审即获得 Go 的门次数 ÷ 总门次数；重大返工 = 单个需求返工工时超过 2 个标准迭代人天的次数占总需求数比例。样本量不大（6 个季度、11 条产品线），所以它更适合作为趋势判断，而不是行业基准。

4. 为什么”开会讨论”替代不了阶段门

有团队会说，我们不搞正式阶段门，但每次大投入之前都会开会讨论。这听起来合理，实际有三个漏洞。一是没有预设判据，讨论容易变成谁的表达能力强谁赢。二是没有记录，半年后没人记得当时是基于什么假设做的决策。三是没有资源绑定，会上说支持，会后照旧排期，决策不落地。

三、常见误区：阶段门为什么在你手里变成了形式

下面六个误区，我几乎在每个团队都见过至少三个。它们不是态度问题，而是设计问题。

1. 把阶段门做成签字仪式

最典型的症状是：评审材料由产品经理单方面准备，与会者只看不读，会上一句”我没什么意见”就过。这种情况下，门的实际作用变成了”责任分摊”，出了问题大家一起承担，因为大家都签过字。

我的判断是：如果一个门的材料全部由提案方自己准备且没有任何第三方校验，这个门的信息价值接近于零。有效的做法是至少有一项关键证据由独立方提供，例如财务给出的单位经济测算、测试负责人给出的质量数据、或者客户成功给出的真实客户反馈。

2. 用完成度百分比代替证据

“功能完成度 92%”是我在评审材料里见过最危险的一句话。完成度衡量的是投入，不是价值。92% 的完成度可能对应 0% 的市场验证。

我现在的做法是把完成度从门的准入条件里彻底删掉，只保留三类内容：已验证的假设、未验证的假设、以及每条假设对应的下一步验证成本。完成度可以作为背景信息放在附录里，但不参与决策。

3. 门主没有资源否决权

这是结构性误区，产品经理个人很难解决，但必须识别出来并向上反馈。判断方法很简单：看看过去一年，门主有没有否决过一个已经投入超过 100 人天的项目。如果没有，他大概率只是个主持人。

遇到这种情况，我的建议不是硬顶，而是把门降级，既然拿不到资源决策权，就不要把它叫做阶段门，改叫”方向对齐会”，避免给团队制造虚假的安全感。同时向上申请在真正有资源权的层级重新设门。

4. 门条件被”善意地”逐步放宽

这是最隐蔽也最致命的误区。第一版门条件写的是”至少 8 个客户确认付费意向”，第一次评审时因为进度紧，改成”5 个客户表达了兴趣”，第三次直接改成”销售反馈市场有需求”。每一次放宽都有合理理由，累积起来就是门彻底失效。

门条件可以在项目开始前调整，一旦项目启动就不应再改，除非同时调整项目目标和资源承诺。我现在的做法是把门条件写进项目立项文档的”变更需审批”字段，任何修改都要留痕并说明原因。

5. 用同一套门卡所有类型的项目

合规类项目、体验优化类项目、探索型预研项目，风险结构完全不同，却常常共用一套门条件。结果是合规项目嫌门太松，探索项目嫌门太重。

6. 只测”能不能做出来”，不测”值不值得做”

研发主导的阶段门天然偏向可行性评估，而产品经理的职责恰恰是把”值不值得”这个问题摆到桌面上。我习惯在每个门固定问三个问题：这件事如果做成了，会改变哪个业务指标？这个改变值多少钱？有没有更便宜的方式验证同一个假设？

第三个问题最容易被忽略，也最能省钱。我见过一个团队花了 4 个月研发自动化配置能力，最后发现用人工运营配合一个简单的脚本就能覆盖 80% 的场景，成本不到研发投入的十分之一。

四、专业判断逻辑：怎么设计一个真能挡住烂项目的门

这一节是我实际使用的设计逻辑，顺序不能颠倒。先找不可逆点，再定判据，再定人，最后定动作。

1. 第一步：找出你项目里的不可逆投入点

做法是把项目全周期的成本列出来，标注每一项”如果决定不做，这笔投入能收回多少”。回收率低于 30% 的，就是不可逆点。

举例：招聘和培训（回收率低）、对外承诺的发布窗口（回收率极低）、技术架构的对外接口（回收率低）、已采购的云资源（中等）、已完成的用户调研（中等）。把这些点按时间排序，门就自然落在它们的正前方。

2. 第二步：把交付物清单换成假设清单

传统门的准入条件是”完成 X 文档”。我改成”验证 X 假设”。每一条假设包含四要素：假设陈述、验证方法、判据阈值、以及如果不成立该怎么办。

举例，一条好的假设是：“目标客户愿意为自动化配置能力额外支付不低于 15% 的订阅费用。验证方法：对 20 个存量客户做报价测试。判据：至少 8 个客户在报价后 2 周内进入采购流程。若不成立：降级为增值服务模块，缩减研发投入至原来的 40%。”

这条假设包含了陈述、方法、阈值和退路，可以直接拿去评审，不需要翻译。

3. 第三步：设置三档以上决策，而不是通过/不通过

只有两档决策时，人们会本能地选”通过”，因为”不通过”意味着否定团队的全部工作。我通常设置四档：

1. Go：按原计划投放下一阶段资源，明确金额和人数。
2. Conditional Go（有条件通过）：批准部分资源，但必须在一定期限内关闭指定的待验证条件，到期未关闭自动降级。
3. Redirect（转向）：不停止项目，但改变目标、范围或路径，资源重新核定。
4. Stop / Hold：暂停或终止，明确已投入资产的处置方式和人力的再分配去向。

我特别推荐”Conditional Go”，因为它能在不打击团队士气的前提下保留纪律。但它有一个必要条件：条件未关闭要有自动降级的机制，不能靠人记得去查。这一点后面讲工具时会展开。

4. 第四步：把准入条件分成硬门槛和软门槛

硬门槛是一票否决项，通常不超过 3 条，直接对应最大的风险。软门槛是评分项，用于比较不同项目的优先级。

硬门槛的例子：涉及用户资金的功能必须有完整的风控评审记录；涉及个人信息的模块必须通过合规评估；单次投入超过 50 万的项目必须有财务确认的单位经济模型。

软门槛的例子：技术方案的复用度评分、团队能力匹配度、市场时机的紧迫程度。软门槛不阻止项目过门，但会影响资源分配的先后顺序。

5. 第五步：给门配上可量化的判据

定性判据在评审现场最容易被”我觉得”打败。我尽量把关键判据量化，下面是几类我常用的量化方式。

阈值不是抄来的，必须结合自己组织的实际情况校准。我一般的做法是先把历史项目的真实数据拉出来，取中位数作为起点，然后根据风险偏好上下浮动。

6. 第六步：让门主拥有”不批资源”的权力并承担后果

只有权力没有后果，门主也会倾向于放行。我的做法是给门主绑定一个可观测指标，例如”由其批准的项目在下一阶段的返工率”或”资源再分配成功率”。这个指标不用于考核个人，但要在季度流程复盘里公开。

另外，门主人数不宜过多。我参与的效率最高的门是 5 人：业务负责人（门主）、产品负责人、研发负责人、财务或运营代表、以及一位独立的质量或合规代表。超过 8 人的评审会，决策质量会明显下降。

五、具体案例和数据观察：中大型组织里阶段门为什么要靠工具承载

前面讲的都是方法。但我在 100 人以上组织里踩过最大的坑是：方法对了，工具跟不上，门照样开不起来。原因很朴素，门的质量取决于证据的完整性和可追溯性，而这两件事靠 Excel 和邮件维护，成本会随组织规模非线性上升。

1. Excel 维护阶段门的三个必然失效点

第一个失效点是数据割裂。需求在需求池里，排期在排期表里，测试结果在缺陷系统里，财务数据在另一个表里。每次评审前，产品经理要花半天到一天做汇总，一旦数据版本不一致，评审现场就会陷入”你的数和我看的数为什么不一样”。

第二个失效点是条件无法自动跟踪。上一节提到的”有条件通过”，条件是写进纪要了，但三周后没人记得去核对，条件就这么失效了。这不是责任心问题，而是任何依赖人工提醒的机制在并行项目超过 10 个时都会崩。

第三个失效点是历史无法沉淀。去年这个项目为什么被 Stop，当时的判据是什么，三个月后没人说得清。这导致同类错误反复出现。

2. PingCode 在阶段门场景中的实际用法

我在服务中大型客户的过程中，见过比较成熟的用法是把 PingCode 作为阶段门的事实数据源，而不是再单独搞一套审批系统。核心思路是：门要用的证据，尽量来自项目过程中自然产生的数据，而不是评审前临时加工的数据。

具体来说，需求从提出到上线的全链路都留在 PingCode 里，阶段门评审时直接引用已有工作项，而不是重新做一份 PPT。评审记录、决策结论、条件和关闭情况都挂在与该项目关联的工作项下，形成一条可追溯的时间线。对于需要”有条件通过”的门，条件可以拆成独立工作项并设置截止日期，到期未关闭能在项目视图中直接看到，不需要任何人去翻纪要。

这套用法对中大型组织的价值尤其明显，因为跨部门协作多、并行项目多、人员流动也相对频繁。当项目负责人换人时，接手的人能在半小时内看清历史决策依据，这在 100 人以上组织里是实打实的效率。

3. 私有化部署在强合规场景里的必要性

金融、医疗、能源、汽车电子等行业的阶段门材料往往包含未公开的产品规划、财务数据和客户信息。这类组织通常不接受研发管理数据放在公有云上。PingCode 支持私有化部署，数据留在企业内网，这是它能进入这类客户评审清单的前提条件之一。

我自己参与过一次金融客户的选型，合规部门提出的问题很具体：审计时能不能导出完整的操作日志，能不能证明某条决策记录在某个时间点之后未被修改。这类需求不是功能清单能回答的，必须由工具的数据留痕能力和部署形态共同支撑。

4. 从 Jira 迁移到 PingCode 时，阶段门数据怎么保

我参与过多次迁移，最大的教训是：迁移不是把工作项搬过去就完事，而是要让历史决策仍然可读。PingCode 支持 Jira 平滑迁移，这一点对于已经用过多年 Jira 的中大型组织很关键。但工具支持是一回事，策略对不对是另一回事。

我的迁移经验是分三步走。第一步，先做字段映射审计，把 Jira 里所有自定义字段按”迁移、合并、归档、丢弃”分类，尤其注意那些被当成阶段门判据用的字段。第二步，设置双轨期，通常 2～4 周，两个系统并行运行但只在一个系统里做出正式决策，避免出现两套互相矛盾的历史。第三步，迁移完成后做一次抽样回溯验证，随机抽 10 个已结束项目，检查从立项到结项的证据链是否完整可读。

代码块里是我实际用过的一份迁移字段映射检查清单，可以直接拿去用。

{
"migration": "jira_to_pingcode_stagegate",

"phase": "field_mapping_audit",

"rules": [

{

"source_field": "customfield_10101",

"semantic": "gate_decision",

"target": "workitem.property.stage_gate_decision",

"values_map": {

"Approved": "go",

"Approved with Conditions": "conditional_go",

"Rework": "redirect",

"Rejected": "stop"

},

"keep_history": true

},

{

"source_field": "customfield_10202",

"semantic": "gate_owner",

"target": "workitem.assignee.gate_owner",

"keep_history": true

},

{

"source_field": "customfield_10303",

"semantic": "entry_criteria_status",

"target": "workitem.checklist",

"split_by": "criterion_id",

"keep_history": true

},

{

"source_field": "comment",

"semantic": "decision_rationale",

"target": "workitem.comment",

"filter": "contains('gate') or contains('stage')",

"keep_history": true

}

],

"excluded": [

{"source_field": "customfield_10999", "reason": "internal_scratch_deprecated"}

],

"validation": {

"sample_size": 10,

"check": "evidence_chain_complete",

"pass_threshold": ">= 9"

}

}

这段配置的关键点在于 keep_history: true 和 validation.pass_threshold。前者保证决策历史不被覆盖，后者保证迁移不是”搬完就算”，而是有可验证的验收标准。

5. 工具化前后的数据观察

下面的数据来自我在一家 200 人左右研发规模的企业中参与的一次流程与工具调整。调整前的状态是：阶段门条件用 Excel 维护，评审材料靠人工汇总，条件关闭靠会议纪要提醒。调整后把评审记录、条件跟踪和项目证据链统一放到 PingCode 中管理。观察窗口是调整前后各 6 个月，样本分别为 23 个和 26 个过门项目。

需要说明的是，这次调整同时包含流程重新设计和工具承载两部分，所以数据变化不能全部归因于工具。但有一个观察我认为值得强调：调整后”条件按期关闭率”的提升最明显，而这恰恰是最依赖人工提醒、最容易在规模扩大后崩溃的一环。

六、行动建议：不同规模、不同阶段的落地路径

阶段门没有标准答案，只有匹配答案。下面按组织规模和场景给出我认为可直接执行的做法。

1. 研发规模 30 人以下：先做减法，别做流程

这个阶段最大的风险不是流程不严，而是流程压死速度。我的建议是只保留一个门，位置放在”从验证性投入到规模化投入”之间，判据不超过 3 条，评审会控制在 60 分钟内。

具体的三条判据可以是：目标用户中完成真实使用（而非试用）的人数、这项功能或产品是否已经带来任何形式的付费或等价资源投入、以及团队是否清楚下一阶段要花多少钱和多少人。这三条足够挡掉大多数拍脑袋决策。

2. 研发规模 100 人以上：门的数量、门主、数据源三件事一起定

这个规模的组织，阶段门失效通常不是因为条款不好，而是因为没有单一数据源和没有明确的资源决策人。我的建议顺序是：先确定门主并明确其资源权限，再确定门的位置和数量，最后确定证据从哪里来。

证据来源这件事，我倾向于尽量依赖项目管理平台的自然数据，减少人工汇总。PingCode 这类面向中大型组织的平台在产品形态上覆盖需求、迭代、测试、发布等环节，能把大部分门需要的证据落在同一套工作项体系里，同时支持私有化部署，适合对数据边界有要求的企业。对于从 Jira 迁过来的团队，平滑迁移能力也意味着历史决策记录可以延续，不需要为了换工具而丢掉审计链条。

3. 强合规行业：门要经得起外部审计

合规场景下，门的首要目标不是效率，而是可举证。我的做法是给每个门建立”证据包”：准入条件的原始数据、评审参与人、决策结论、后续动作、以及每次变更的原因和时间戳。证据包要能被非项目成员在 30 分钟内读懂。

另外，合规场景建议把”独立验证”写成硬门槛。例如涉及资金的功能必须由不参与开发的第三方完成风险评估并签字。这一条在出问题时能起决定性作用。

4. 从零开始搭建阶段门的七个步骤

如果你现在就要动手，我建议按下面顺序推进，每一步都有明确的产出物。

1. 盘点不可逆投入点：列出项目全周期的支出项，标注回收率，产出物是一张不可逆点清单。
2. 确定门的数量和位置：把门放在不可逆点之前，产出物是阶段门路线图。
3. 定义每个门的准入条件：每条条件包含判据、阈值、数据来源，产出物是门条件表。
4. 指定门主与决策权限：明确能批多少钱、多少人，产出物是决策授权说明。
5. 设计决策档位与升级机制：Go / Conditional Go / Redirect / Stop 四档以及各自触发条件。
6. 选定证据承载方式：确定数据从哪来、存在哪、怎么追溯，产出物是数据源映射表。
7. 试运行并校准阈值：用最近 3 个已结束项目做回放演练，看现有判据能不能得出与当时一致的结论。

第七步最容易被跳过，但价值最高。回放演练能在不付代价的情况下暴露判据设计问题。我做过的一次回放里，发现原本设定的”LTV/CAC ≥ 3.0″门槛会误杀两个后来表现很好的项目，于是把阈值调整为分阶段适用，早期用更宽松的 1.5，规模化门前才提升到 3.0。

下面是一段我实际用过的门条件配置示例，可以直接改成你项目的版本。

gate: G3_规模化投入门
gate_owner: 产品线总经理

decision_options: [go, conditional_go, redirect, stop]

entry_criteria:

id: E1

name: 付费意愿验证

evidence: 目标客户报价测试记录

threshold: "确认付费意向客户数 >= 8 / 20"

七、取舍：阶段门设计中没有免费午餐

所有阶段门设计决策本质都是取舍。我把最常遇到的五组矛盾摆出来，并给出我的倾向，但你要根据自己的场景调整。

1. 严谨与速度

门越严，暴露风险越早，但立项周期越长。我的经验是：把严谨集中在不可逆点上，其他环节尽量轻。一个硬件项目，开模前的门可以开三天，其他门开两小时就够；一个 SaaS 项目，规模化投入前的门值得花一周，界面改版的门不值得。

如果非要给一个数字，我建议单次阶段门评审控制在 90 分钟以内，材料准备时间控制在 4 小时以内。超过这个数量级，说明你在门里塞了不该由门解决的问题。

2. 统一门与差异化门

统一门的好处是管理成本低、横向可比；差异化门的好处是贴合实际。我倾向于框架统一、条件差异化：所有项目用同一套决策档位和评审形式，但准入条件按项目类型定制。这样既保留了组织层面的可比较性，又不至于让探索项目被合规项目的门槛卡死。

3. 工具化与轻量流程

工具化能解决可追溯和自动化跟踪，代价是配置成本和迁移成本。我的判断标准很简单：当你同时进行的过门项目超过 8 个，或者条件关闭率连续两个季度低于 70%，就该考虑工具承载了。在这两个条件都满足之前，用结构化文档加固定模板可能更划算。

4. 门主集中与分布式授权

集中决策的好处是资源分配全局最优，坏处是门主成为瓶颈。分布式授权的好处是快，坏处是容易各管一摊。我的建议是分层：小额投入（例如不超过 20 人天）由产品负责人自行决策并事后备案，中等投入由门主决策，超过一定金额或涉及跨三条以上产品线的，升级到更高层级的投资评审。

5. 数据留痕与团队负担

留痕越完整，审计和复盘越容易，但数据录入负担会上升。我见过最失败的做法是要求团队为阶段门单独填一套表，结果数据和实际工作脱节，变成纯粹的行政负担。

正确的方向是让留痕成为工作过程的副产品。评审记录、条件状态、决策结论都挂在项目工作项上，而不是另建一张表。如果一项留痕工作不能在日常协作中自然产生，它长期一定会被敷衍。

八、结语：阶段门的价值在于它敢于说”停”

回到开头那条产品线。我们在复盘之后做了三件事：把门条件从”完成度”改为”付费意愿验证 + 单位经济 + 技术可行性”三条硬门槛；把门主换成拥有研发排期和预算双重权限的产品线总经理；把评审记录和条件跟踪统一到项目管理平台里，条件到期未关闭会自动出现在项目看板上。

接下来的一年里，我们一共开了 31 次阶段门评审，其中 Go 19 次、Conditional Go 7 次、Redirect 4 次、Stop 1 次。那个唯一被 Stop 的项目，如果在过去会被”再给它一个季度”。省下来的两个研发小组人力，被投进了一条最终贡献了当年约三分之一新增收入的业务线。

所以，如果你正在设计或改造自己的阶段门，我最想给你的建议不是先去找模板，而是先回答三个问题：你项目里最不可逆的那笔投入是什么？谁能真正决定停还是继续？过去一年有没有任何一个项目因为这个门被停掉或转向？

三个问题如果都能给出具体答案，说明你的门已经在工作；如果答不上来，那就从第一问开始，用两周时间把不可逆点清单列出来。这是投入最小、回报最直接的一步。

下一步可以这样做：本周内拉上研发负责人和财务，用 90 分钟列出你当前主项目的前三个不可逆投入点；两周内为每个点写出一到三条可验证的准入条件，判据要带数字；一个月内挑一个正在进行的项目做一次完整回放演练，检验这套条件是否能在事后得到与当时一致的判断。演练结果比任何流程文档都更能说明问题。