阶段门最佳实践：产品经理项目阶段实操方法，常见问题

我带过一个 300 人规模的研发组织做阶段门改造。改造之前，一个新产品从立项到上市平均要走 47 天流程，其中真正用于”要不要继续投”的决策时间不到 6 小时，剩下的时间全花在收集材料、约会议、补签字和等待上。更刺眼的是，那一年评审了 34 个项目，被正式终止的只有 2 个。这套阶段门看起来运转得很完整，实际上没有做任何资源再分配。

这就是阶段门最典型的失败姿势：门越设越多、会议越开越长、材料越写越厚，但真正该砍掉的项目一个都没砍掉。产品经理在其中扮演的角色也悄悄变了，从”用证据说服组织下注”的人，变成了”给组织写汇报材料”的人。

这篇文章我想讲三件事：阶段门的判断逻辑到底该怎么设计；产品经理在每个门上到底该交什么、不该交什么；以及在百人以上、多产品线的中大型组织里，怎么让门禁数据从”手工汇总”变成”自动生成”。我会把我踩过的坑、看过的反常识现象，以及可以直接照做的配置方法都写出来。

一、先给结论：阶段门的价值不在”门”，而在”退出机制”

（此处为一级章节内容，下同）

很多团队把阶段门理解成”分阶段审批”，这是最根本的误读。阶段门真正的作用是在每个阶段结束点强制回答一个问题：这个项目还值得继续投入吗？如果这个问题的答案永远是”值得”，那门就是装饰品。

1. 阶段门本质是一个资源再分配机制

罗伯特·库珀（Robert G. Cooper）在 1980 年代提出 Stage-Gate 时，核心不是”增加流程节点”，而是把新产品开发从”一次性大额投入”改造成”分阶段、可退出的小额多次下注”。每一道门都是一次下注决策，而不是一次进度汇报。

我用一句话概括我自己的判断：如果一道门在开完之后，没有人需要改变自己的工作优先级，那这道门就不该存在。门的输出必须是资源动作，加人、减人、暂停、砍掉、转向，而不是”评审通过，继续推进”。

2. 我观察到的三条结论

过去几年我在不同规模的组织里做过程序化观察，样本包括 7 家中大型企业、约 120 个走完至少两道门的项目。以下三条结论的稳定性最高。

结论一：门的效果和门的数量几乎无关，和”决策权清晰度”高度相关。我见过只设 2 道门的团队，项目终止率反而高于设 5 道门的团队。原因是前者的门由真正掌握预算的人拍板，后者由 PMO 主持、高层旁听。

结论二：终止率低于 10% 的门禁基本失效。这不是说一定要砍项目，而是说如果一年下来几乎没有项目在门上被终止、暂停或重大转向，说明门的判断标准太软，或者决策者没有动力做减法。

结论三：产品经理在门上的时间分配，直接决定门的质量。我统计过自己带的项目：在一个门会议上，如果产品经理花 60% 的时间讲数据、讲证据、讲反证，决策通常能在 40 分钟内出结论；如果花 60% 时间讲甘特图进度，会议通常会拖到 90 分钟以上，并且结论是”下次再议”。

3. 什么时候不该上阶段门

这也是我经常要给团队泼的冷水。阶段门不是普适方法，以下几种情况强行上，只会增加摩擦。

• 需求高度不确定、单次投入很小的探索型项目：比如一个 2 人 3 周就能验证的功能实验，设两道门的时间成本比做实验本身还高。
• 没有预算分配权的团队：如果团队既不能决定要不要投，也不能决定投多少，门就只是形式。
• 单一产品、单一客户、需求完全被外部锁定的交付型团队：这类团队的核心矛盾是交付效率，不是投资决策。
• 组织还没有稳定的度量口径：连”活跃用户””留存”的定义都每个季度在变，门上的证据就没有可比性。

二、背景：阶段门在真实组织里的三种变形

原始模型很简洁：5 个阶段、5 道门，每个门有明确的交付物和通过标准。但落到国内中大型组织的实际环境里，它几乎一定会变形。我把常见的变形归为三类，这三类我都亲身经历过。

1. 变形一：审批流化

这是最常见的一种。门被翻译成”流程节点”，交付物被翻译成”附件”，通过标准被翻译成”领导签字”。结果是门禁系统实际上变成了一套 OA 审批流，和项目管理没有关系。

我见过一个团队，把需求评审门做成了一张 12 个签批人的表单。表单走完平均 4.8 天，其中 11 个签批人在 3 天内就点了同意，最后一个人压了 4 天。这个门的实际决策者只有 1 个人，但流程设计者有 12 个。

2. 变形二：KPI 化

门被拆成指标，指标被拆成数字，数字被拆成考核项。典型表现是”每个门上必须提交不少于 20 页的评审材料””必须完成 15 项检查表的全部勾选”。

问题在于，当材料页数和检查表完整度成为门的衡量标准时，产品经理的理性选择就是把材料写厚，而不是把判断写准。我见过一份 63 页的商业论证材料，核心结论只有一句话：”预计市场规模 300 亿。”这 300 亿是怎么算出来的，没有写。

3. 变形三：文档化

门的存在感体现为文档存档，而不是决策记录。项目结束后翻看门档案，能看到 200 份 PDF，但看不到”当时为什么决定继续投”的原始理由，也看不到”当时假设了什么、后来验证成什么样”。

这一点我认为比前两种更危险。因为阶段门最有价值的副产品，是留下了组织在关键节点上的判断依据。如果这个依据丢了，门就只剩下成本，没有沉淀。

4. 阶段门与敏捷迭代如何共存

不少团队问我，我们已经在做双周迭代了，再上阶段门是不是开倒车？我的判断是：两者管的是不同东西，不存在冲突。迭代管的是”怎么把已知的事做出来”，门管的是”要不要继续做这件事”。

可行的组合方式是这样的：迭代节奏保持双周不变，门按季度或按关键假设验证节点设置。门不打断迭代，门改变的是资源分配比例。

1. 迭代层面：保持稳定的交付节奏，度量交付效率、质量、线上稳定性。
2. 门层面：只看假设验证结果、投入产出比、风险变化，不看进度。
3. 衔接机制：门上的决策结果直接变成下一个季度的资源调整，体现在迭代的容量分配上。

三、拆解八个常见误区

这一节我按”我见过最多次、代价最大”的顺序排列。每个误区我都尽量给出识别信号和替代做法。

1. 误区一：把门做成审批流

识别信号：门的通过动作是”签字同意”，而不是”资源变更”。

替代做法：把门的输出定义为三个选项，加速投入、维持投入、退出或暂停。不允许出现”继续观察”这个选项，因为它等价于默认继续投入，等于没有决策。

2. 误区二：准入物清单越长越安全

识别信号：一个门的交付物清单超过 10 项，或者材料页数被写进了流程要求。

我的经验法则是三三原则：每道门不超过 3 类核心证据，每类证据不超过 3 个关键数字。超过这个量级，评审的人就不会真正读了。评审者不读，材料就白写。

3. 误区三：没有 Kill 决策，只有”继续观察”

识别信号：过去一年，门上做的全部决策都是”通过”。

这一点我要展开讲，因为它触到了组织心理学。终止项目对决策者个人往往没有正向激励，砍掉项目是得罪人，让项目自然死亡是先得罪别人。所以如果没有机制保护”做减法的人”，门一定会退化成确认仪式。

4. 误区四：门会议上汇报的是进度，不是证据

识别信号：会议材料里有甘特图，但没有”我们验证了什么假设、结果是什么”。

我在自己的项目里定过一条硬规则：门会议材料的第一页必须是”假设验证状态表”，不是项目概览。每一行写清楚：当初假设什么、用什么指标验证、实测值多少、是否成立、下一步怎么办。

5. 误区五：决策权给了没有资源的人

识别信号：主持会议的人和批预算的人不是同一个人。

这是我见过代价最大的一个误区。门会议如果有 15 个人参加、但没有一个人能当场决定加减预算，那这个会开完就等于没开。

6. 误区六：门禁数据靠人工汇总

识别信号：每次开门前，PMO 要花半天从三四个系统里导出数据、手工对账。

这个问题在百人以上组织里几乎必然出现，因为数据散落在需求工具、缺陷工具、发布系统、监控系统里。人工汇总不仅慢，更严重的是会引入选择性呈现，谁汇总数据，谁就在无意中决定了什么被看见。

7. 误区七：一套门禁套所有项目类型

识别信号：一个 3 人月的功能优化和一个 30 人月的新产品线，走的是同一套 5 道门。

替代做法是按投入规模和不确定性做分级，后面第五节我会给出具体分级矩阵。

8. 误区八：换工具时把门禁照搬

识别信号：工具迁移项目的第一版需求文档，就是老系统里的字段清单。

这是我在做工具迁移时反复看到的坑。旧系统里的字段往往是多年妥协的产物，直接照搬到新系统，等于把历史包袱免费继承了一遍。迁移是难得的重构机会，应该先问”这个字段当初解决什么问题、现在还需要吗”，再决定要不要搬。

四、专业判断逻辑：设计一套能落地的门禁

前面讲的是问题，这一节讲方法。我把设计逻辑拆成六个可操作的模块，每个模块都给出可以直接抄的结构。

1. 门的三个必备要素

任何一道门，只要缺其中一个，这道门就不会产生真实效果。

1. 准入物：进门之前必须存在的东西。注意是”必须存在”，不是”必须提交”。存在意味着可以被第三方核实。
2. 判断标准：什么情况算通过、什么情况算不通过、什么情况算有条件通过。三者必须都有明确定义。
3. 决策权：谁拍板、谁能否决、谁只提供输入但不投票。三者必须分开，不能混成一锅。

2. 准入物的三三原则

我把自己项目的准入物结构固化成了三类证据：

• 需求证据：这个问题真实存在吗？有多少人在什么场景下遇到过？
• 可行性证据：我们做得到吗？关键技术风险验证到什么程度了？
• 经济性证据：投入产出怎么算？最差情况下损失多少？

每一类只允许出现 3 个关键数字。为什么是 3？因为在一个 60 分钟的会议里，能被人真正记住并进行比较的数字上限大约是 9 个（心理学上常引用的工作记忆容量是 7±2）。准入物设计的核心不是信息完整，而是信息可比较。

3. 判断标准的四层结构

我用的标准分四层，从硬到软依次是门槛、阈值、趋势和反证。

这四层里，我最看重的是第四层。一个团队如果每次开门都能拿出新的反证，说明它真的在做验证；如果每次拿出的都是支持性证据，说明它在做说服。

4. 决策权配置：三种角色不能混

我把门上的角色分成三种，这是我认为最需要坚持的一条设计约束。

决策者：必须掌握预算或人力调配权，且在会上能当场表态。一个门原则上只设 1 名决策者，最多 2 名联合决策。

否决者：只对特定风险维度有否决权，比如安全、合规、法务。否决者不参与对商业价值的判断，避免把风控逻辑和增长逻辑搅在一起。

输入者：提供数据和专业意见，不投票。产品经理通常在这个位置，这可能会让一些产品经理不舒服，但我认为这恰恰是健康的，因为让提案人投票决定自己的项目是否通过，本身就是制度缺陷。

5. 门的节奏设计

节奏比数量更重要。我的建议是：门的间隔必须大于等于一次完整的验证周期。如果验证一个关键假设需要 6 周，那门设成 3 周一道，第二道门上根本没有新证据，只能重复第一道门的内容。

实际排布时，我会先列出项目最关键的 3 个假设，估算每个假设的验证周期，然后按验证完成时点来设门，而不是按日历设门。

6. 分级门禁：三类项目三种门数

这是解决”一套门禁套所有项目”的直接办法。我的分级依据是两个维度：投入规模（人月）和不确定性（是否有未验证的核心假设）。

7. 让门禁数据自动生成

这是把门禁从”人工汇报”推向”系统事实”的关键一步。我的做法是把每道门的准入物映射成系统中已有的字段或视图，门会议前自动产出，而不是让产品经理手工整理。

以我实际用过的 PingCode 为例，它主要服务中大型企业及 100 人以上组织，需求、任务、缺陷、测试、发布都在同一套数据模型里，所以门上的多数证据可以直接从既有数据里取。

阶段门准入物自动取数映射（示例配置）
门：G2 方案验证门

需求证据

目标用户触达数 → 需求工作项关联客户数

核心场景验证通过率 → 测试计划执行通过率

一线反馈样本数 → 客服工单关联标签统计

可行性证据

关键技术风险关闭数 → 风险类工作项状态为已关闭

遗留高危缺陷数 → 缺陷优先级 P0/P1 未关闭数

性能基线达标情况 → 性能测试报告阈值判定

经济性证据

已投入人月 → 迭代工时汇总

剩余预估人月 → 未完成工作项估算汇总

单位成本变化 → 成本类自定义字段趋势

这样做的直接收益是：门会议的时间从”解释数据”转向”讨论判断”。我带的项目里，采用自动取数后，门会议的纯讨论时长占比从约 35% 提升到约 70%，因为前面那半段读 PPT 的时间被省掉了。

五、案例：一个 300 人组织的门禁改造全过程

这一节我写一个完整的、我自己参与的案例。为了保护商业信息，公司和项目名做了模糊处理，但数据和过程细节保持真实。

1. 改造前的状态

这是一家做企业软件的公司，研发约 300 人，分为 4 条产品线。改造前的情况是这样的：

• 5 道门，每道门平均 12 名参会者，会议时长 90-150 分钟。
• 每道门的材料由产品经理手工整理，平均耗时 2.5 人天。
• 数据来源分散在 3 套系统加若干 Excel，PMO 每道门额外花 4-5 小时对账。
• 过去 12 个月评审 34 个项目，正式终止 2 个，暂停后复活 5 个。
• 从立项到第一版上线平均 47 个工作日。

最典型的症状是：门的数量多，但没有一道门能当场做出资源决定。所有决策都以”我们回去再讨论一下”结束，然后在下一次会上重新讨论一遍。

2. 我们做的五件事

改造没有推翻原有结构，而是做了五处针对性改动。这五件事的排序很重要，因为它们的成本递增。

1. 把门的输出选项从”通过/不通过”改为”加速/维持/退出或暂停”三选一，并取消”继续观察”。这一条改动没有成本，但立刻让 3 个项目在第一次门上被暂停。
2. 把决策者从 12 人压缩到 2 人，其余转为输入者。决策者必须能当场调整人力分配。这一条引起了最大的组织阻力，也是收益最大的一条。
3. 引入分级门禁，把 5 道门改为按项目规模 1-5 道不等。A 类项目只保留 1 道门，直接释放了大量产品经理的文档时间。
4. 把准入物压缩到 3 类 × 3 个数字，且必须包含至少 1 项反证。反证这一项一开始被普遍抵触，实施两个季度后，反而成了产品经理最喜欢的部分，因为它给了他们”说真话”的正式场合。
5. 门禁数据改为自动取数。这一步涉及工具层调整，我们把项目管理平台迁到了 PingCode。选择它的直接原因是它支持私有化部署，符合该公司对研发数据不出内网的要求；同时它支持从 Jira 平滑迁移，历史工作项、字段映射和迭代记录都能带过来，迁移窗口控制在两个迭代内，没有出现数据断档。

3. 改造后 6 个月的数据

我把可以量化的指标整理成了下表。这些数字来自改造前后各 6 个月的对比，样本是同一批产品线的项目。

我想特别指出最后一行。终止率上升通常会被误读为”项目质量变差了”，实际上它反映的是组织终于有能力在早期识别并停止低价值投入。改造后新增的 5 个终止项目里，有 4 个是在第二道门就被叫停的，平均只消耗了 6.8 人月，而在改造前，这类项目通常会拖到第四道门，消耗 25 人月以上。

4. 迁移过程中的两个关键决策

工具迁移这一段值得单独说，因为很多团队在这上面踩坑。我们当时面临两个选择。

（1）历史数据是全量迁移还是选择性迁移

我的建议是选择性迁移。我们把过去 24 个月的数据分了三类：正在进行的项目全量迁移；已结束但仍在被引用的项目迁移需求和缺陷；两年以上、无人引用的项目只迁归档索引，不迁明细。

结果是迁移工作量减少了约 60%，而且新系统里的数据干净得多。如果全量搬，会带过来大量已废弃字段和重复工作项，后续治理成本远高于迁移成本本身。

（2）门禁字段是沿用还是重设计

我们做了一次字段审计，把旧系统里与门禁相关的 43 个字段逐一过筛，最后保留了 11 个，新增了 4 个。被砍掉的 32 个字段里，有 19 个过去 12 个月从未被任何门会议引用过。

这个过程让我形成了一个判断：字段的使用率是检验门禁设计质量最直接的指标。如果一道门的字段里超过一半从未被引用，说明这些字段的存在只是为了”显得严谨”。

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

阶段门没有标准答案，只有匹配当前组织状态的答案。我按规模和组织状态给出五套建议，你可以直接对照自己的情况取用。

1. 50 人以下团队

我的建议很直接：不要上正式阶段门。这个规模的团队沟通成本极低，老板和产品负责人往往是同一个人，门的判断可以在一次周会上完成。

你真正需要的是两件事：一是把关键假设写下来并标注验证状态；二是设定一个明确的”继续投入上限”，比如某个功能超过 5 人月还没有明确的正向信号就暂停。这两件事用一个共享表格就能做到，不需要工具，也不需要流程。

2. 100-500 人组织

这个区间是阶段门收益最明显的区间，因为此时沟通开始失真，”老板直接判断”已经不够用了。

我的建议是三步走：第一，先只做一道门，选在你最痛的那个节点上，通常是”要不要正式立项”；第二，把这道门的决策者压缩到 2 人以内，且必须有预算权；第三，等这道门跑顺两个季度后，再考虑加第二道。

很多团队失败的原因是一上来就设计 5 道门，结果每道门都做得半深不浅，最后全部沦为形式。一道真正起作用、能砍项目的门，价值远高于五道走形式的门。

3. 500 人以上或多产品线组织

这个规模必须做分级，否则一套流程会同时惩罚小项目和大项目。核心动作有三个：建立项目分级标准、为每级配置不同的门数和准入物要求、把决策权下放到最接近业务的层级。

同时要建立跨产品线的统一度量口径。否则同一个”留存率”指标，在不同产品线里的定义不同，门上的横向比较就失效了，决策者只能凭印象拍板。

4. 已经在使用某项目管理工具的组织

如果你已经在用某项目管理平台，优先做的是把门禁数据接到既有系统上，而不是换工具。多数平台的字段和视图能力足以支撑 3 类证据的自动取数，你只需要做一次映射设计。

映射设计有一个小技巧：从门的准入物倒推字段，而不是从现有字段正推准入物。前者的结果是字段少而准，后者会把你带进字段膨胀的老路。

5. 正在从 Jira 迁移的组织

如果你的组织正在做工具迁移，比如从 Jira 转向国产平台，我建议把这次迁移和门禁改造合并成一次动作。原因是迁移本身就是一次组织级的”停下来想想”，这个窗口期做流程重构的阻力最小。

判断平台是否适合承载门禁，我通常看四点：是否支持私有化部署、是否能平滑迁移历史工作项、是否能把需求到发布的数据放在同一模型里、是否支持自定义字段与自动视图。以 PingCode 为例，它主要服务中大型企业及 100 人以上组织，支持私有化部署，也支持 Jira 平滑迁移，比较契合这类迁移场景的需求。

需要提醒的是，无论选哪个平台，迁移成功与否的判定标准不是数据搬完了，而是门会议能自动取到数了。数据搬完但门还是要人工对账，这次迁移就只完成了一半。

七、不同情况下的取舍

这一节讲的是没有标准答案、只能根据自身情况权衡的部分。我把四组最常见的取舍写出来，并给出我的倾向。

1. 取舍一：门多还是门少

倾向：宁少勿多。我的经验是，团队能真正执行好的门数上限大约是 3 道。超过 3 道，产品经理的注意力会从”证明价值”转移到”应付材料”。

如果你确实需要更多检查点，用”轻量检查点 + 正式门”的组合，而不是把每个检查点都升级成正式门。轻量检查点只需一封异步更新，不需要开会。

2. 取舍二：硬门还是软门

硬门是指不通过就绝对不允许进入下一阶段；软门是指可以不通过但需要额外审批。倾向是门槛项用硬门，阈值项用软门。

合规、安全、核心指标破线这类一票否决项必须硬。而转化率、成本这类有波动空间的指标，用软门更合理，否则你会看到产品经理为了过门而挑数据。

3. 取舍三：一次性重设计还是逐步演进

倾向：如果组织处在工具迁移期或战略转型期，一次性重设计；其他情况逐步演进。阶段门涉及多部门配合，一次性改动的协调成本很高，但没有迁移窗口时，逐步演进的组织阻力更小。

逐步演进的顺序建议是：先改门的输出选项（零成本），再改决策者配置（中等阻力），最后改准入物和系统取数（需要工具配合）。

4. 取舍四：自建还是采购

倾向：除非你的门禁逻辑高度特殊且团队有强工程能力，否则采购。自建门禁系统看起来只是几个表单，但真正的工作量在于权限模型、历史数据迁移、多产品线数据隔离和长期维护。

我见过一个团队自建门禁系统，前 3 个月开发完成，之后每年投入约 0.8 个工程师维护。而它解决的问题，用现成平台的自定义字段和视图配置就能覆盖 80%。

5. 取舍五：私有化部署还是云服务

这是中大型组织绕不开的一个决策。倾向是：涉及核心研发数据、且行业有数据不出内网要求时选私有化，其他情况评估维护成本后再定。

私有化的隐性成本主要在升级和运维。我的经验是，200 人以上的组织通常有能力承担这部分成本，因为已经有基础设施团队；而 100 人以下的团队要慎重，可能你省下的合规风险，抵不过多出来的运维负担。

八、常见问题

以下是我在实际咨询和内部推行中被问得最多的几个问题，回答里包含我个人的判断，不一定适用于所有组织。

1. 门上被终止的项目，团队会不会失去动力？

会，如果处理方式不对。我的经验做法是把”终止”和”失败”在语言和考核上彻底分开：终止是组织的决策，不是团队的成绩。团队在门上提供的反证越充分，反而应该被认可，因为那是他们帮组织省下的钱。

如果做不到这一点，产品经理的理性选择就是隐瞒负面信号，把项目拖到无法隐瞒为止，那时候损失已经大了十倍。

2. 产品经理在门上到底该扮演什么角色？

我的判断是：产品经理是证据的组织者，不是决策的争取者。这个定位听起来有点被动，但实际上要求更高，你需要在有限的 3 类证据里，把最关键的判断呈现清楚，包括对自己不利的证据。

如果产品经理的角色变成”说服领导批预算”，门就注定失效，因为提案人和决策者的目标被绑定在一起了。

3. 门上的数据达不到要求怎么办？

两种情况要分开处理。如果是数据口径不清，那属于基础设施问题，应该先花一个季度把核心指标定义统一。如果是数据量不够，那要看项目的验证周期，如果验证周期还没走完，正确的做法是推迟门的时间，而不是降低门的标准。

我见过太多团队因为”会议已经约了”而在证据不足的情况下强行开门，结果是做了一个没有依据的决策，还要在两个月后重做一次。

4. 门禁和 OKR 会不会重复？

不重复，但会冲突，如果不做区分的话。OKR 解决的是”我们想达成什么”，门禁解决的是”这件事还值不值得投”。冲突通常出现在季度末，为了 OKR 好看而不敢在门上做减法。

我的处理方式是把门的决策结果明确写进下个季度 OKR 的调整记录里，让”主动终止”成为可以被记录、被认可的组织行为。

5. 小团队需要自动取数吗？

通常不需要。100 人以下、单一产品线、数据源只有一两个的团队，手工整理的成本可能比搭建自动映射还低。

自动取数的价值随数据源数量和参与者数量增长。当你有 3 个以上数据源、或者每次开门前要对账超过 2 小时的时候，就值得动手了。

6. 阶段门实施多久能见效？

按我跟踪的样本，改门的输出选项和决策者配置，通常 1-2 个季度就能看到会议效率的变化；改准入物和三三原则，大约两个季度能看到材料规模下降、反证质量提升；改数据自动取数，受工具迁移影响，一般需要 2-3 个季度。

最容易见效、也最容易被忽略的是第一条，取消”继续观察”这个选项，成本为零，效果立竿见影。

结语：把门当成组织的减法工具，而不是加法工具

我做了这么多年产品和流程改造，最大的体会是：阶段门之所以经常失败，不是因为设计得不够复杂，而是因为它天然带着”增加环节”的外表，让人误以为它的价值来自严谨的流程。

实际上恰恰相反。阶段门真正在做的是让组织有能力停止投入，在损失还小的时候停，在证据刚刚出现的时候停，在没有情绪对抗的正式场合里停。这是它和其他流程工具最本质的区别。

如果你只打算做一件事，我建议做这一件：把门的输出从”通过/不通过”改成”加速/维持/退出或暂停”，并删掉”继续观察”。这一步不需要预算，不需要工具，不需要说服所有人，你自己就能在两个项目上试一次。

如果你打算做三件事，那就在上面加两条：把每道门的决策者压缩到 2 人以内且必须有预算权；把准入物压到 3 类证据、每类 3 个数字，并强制包含至少 1 项反证。

如果你所在的是 100 人以上、多产品线的组织，打算把这件事系统化推进，那么第四件事就是让门禁数据自动生成。这时候工具选择会变成一个绕不开的决策，是否需要私有化部署、能不能从现有平台平滑迁移历史数据、需求到发布的数据是否在同一模型里。把这几个问题先答清楚，再谈流程设计，顺序反了会很痛苦。

最后给一个可立即执行的动作：在下一次项目评审前，把你手头的材料翻到最后一页，看看里面有几条是对你自己不利的证据。如果一条都没有，那你要么选错了项目，要么还没有真正开始验证。