项目阶段阶段门全流程：产品经理制度设计与一文讲清

我在 2021 年接手过一个很典型的烂摊子：公司 400 人，季度规划会上排了 23 个产品项目，六个月后还在推进的只剩 9 个，真正带来收入变化的只有 2 个。复盘的时候我发现，问题不在执行力，而在整条链路上没有任何一个节点强制回答一句话，这个项目还该不该继续投钱。

后来我们用 9 个月把阶段门（Stage-Gate）制度从零搭起来，立项数量砍掉四成，按期交付率却从 47% 涨到 78%，发布后 90 天内的功能废弃率下降了将近一半。这篇文章把我踩过的坑、改过三版的模板，以及和 6 家不同规模公司交流后总结的判断逻辑，完整写出来。

一、先给结论：阶段门不是评审会，是资源释放的开关

绝大多数公司做阶段门失败，不是因为流程画得不好看，而是从一开始就理解错了它的职责。阶段门不是”给领导汇报一下进度”，也不是”让架构师帮忙看看方案”。它的本质是一个资源释放开关：只有当前一阶段的假设被验证为真，下一阶段的预算、人力、时间才会被授权投入。

理解这一点，后面所有设计决策都会变得清晰。门不是为了评审，门是为了在信息最便宜的时候做出终止决策。

1. 门的唯一职责是回答”继续、加注、暂停还是终止”

我在第二版制度里把门的输出强制收敛成四个选项，不允许出现”基本通过””有条件通过”这类模糊结论。这四选项对应四种完全不同的资源动作，也对应四种不同的责任归属。

（1）四种结论与对应动作

第四行那个误用，是我见过最贵的错误。某个客户侧项目已经烧了 60 多人月，技术上被证明无法在多租户环境下做到承诺的隔离等级，但决策者说”都投这么多了，先上线再说”。结果又投了 40 人月，最后整个模块下线。

2. 一道能用的门只需要三个字段

我把门的定义从最初的两页纸压缩到三个字段，落地成功率反而大幅提升。字段越多，执行时的解释空间越大，解释空间越大，门就越软。

• 准入条件（Exit Criteria）：进入下一阶段前必须为真的、可被第三方复核的事实清单，通常 3 到 5 条，不允许超过 7 条。
• 决策人（Decider）：有预算权的具体一个人，不是委员会、不是”产品委员会审议后由 PM 汇总”。
• 退路（Fallback）：不通过时项目去哪里，冻结、降级为技术预研、并入其他项目，还是彻底终止。

这三个字段里，最容易被忽略的是退路。没有退路的门，执行时会自然演化成”反正不通过也没地方去，那就先通过吧”。

3. 门的数量由投入规模决定，不由流程模板决定

我见过直接把教科书里的 5 门模型照搬到 30 人团队的做法，结果每两周开一次评审会，产品经理一半时间在写评审材料。门的数量应该跟单项目的最大投入挂钩，投入越大、失败越不可逆，门才越密。

（1）按投入规模选门数量

1. 单项目投入小于 20 人月：1 到 2 个门，通常只保留”立项门”和”发布门”。
2. 20 到 100 人月：3 个门，概念门、计划门、发布门。
3. 100 到 500 人月：4 到 5 个门，在计划门和发布门之间插入开发中期门。
4. 超过 500 人月，或涉及硬件模具、合规认证、外部资金：5 到 7 个门，且必须做分层决策。

4. 产品经理是守门人，不是汇报人

这个角色定位的差别，决定了整个制度的生死。汇报人关心的是”今天讲得好不好看”，守门人关心的是”证据链是否成立、假设是否被验证”。当产品经理把自己当汇报人时，他会本能地隐藏坏消息、把不确定说成确定，门就此失效。

我给产品经理设过一个有点反直觉的考核项：本年度被你在门里主动拦下的项目数。第一年有人挂零，第二年团队里最好的产品经理拦下了 4 个，那年公司的无效投入占比下降了 19 个百分点。

二、真实场景：我用 6 个月踩完了阶段门的坑

制度设计这件事，光看方法论没用，必须看它在真实组织里怎么被扭曲。这一节我把三版制度的演化过程写清楚，包括那个让我印象最深刻的”20 个项目全过门”的下午。

1. 第一版制度：8 个门、27 份交付物

第一版是照着咨询模板改的。8 个门覆盖从机会识别到退市的全生命周期，配套 27 份标准交付物，包括商业论证、市场分析、技术可行性报告、风险评估表、资源计划、上线检查单等等。上线第一个月，产品经理平均花在文档上的时间是每周 11 小时。

问题在第 3 个月集中爆发。排期最紧的那个项目，产品经理直接复制了上一个项目的文档，改了标题和数字就提交了。评审会上没人看得出来，因为大家看的是文档结构完不完整，不是内容真不真。

2. 崩溃点：季度评审会上 20 个项目全过

那个季度的组合评审会开了 5 个半小时，20 个项目全部通过。会后我问主持人，如果今天要毙掉一个，你会毙哪个？他想了半分钟说，好像每个都有理由做。

这句话点醒了我。当所有项目都能通过时，门就退化成了排队盖章。真正的原因有三个：一是准入条件写的是”需求清晰、方案合理”这类无法证伪的话；二是决策人不在场，会议主持人是项目经理，他没有预算权；三是被毙掉的项目没有退路，团队会本能地抵抗否决。

3. 第二版：3 个硬门 + 2 个软门

第二版做了三个关键改动。第一，门从 8 个砍到 5 个，其中 3 个硬门（立项门、开发中期门、发布门）具有否决权，2 个软门（概念对齐门、方案评审门）只输出建议不否决。

第二，所有准入条件改成可验证的事实陈述，比如立项门要求”至少 8 位目标客户完成结构化访谈，其中 5 位在过去 3 个月内为同类问题付过费或投入过替代方案”，而不是”需求清晰”。

第三，明确每个门的决策人和他的预算权限上限，同时规定被否决的项目自动进入一个”观察池”，团队可以在下一季度带新证据重新申报。这一条把否决的政治成本降到了最低。

4. 一个真实项目的过门记录

2022 年 3 月立项的一个 CRM 移动端项目，初始预算 180 人月，最终花了 205 人月，晚了 9 周上线，但上线后 90 天付费转化做到 21%。这个过程里，门起了三次实质作用。

（1）四次关键决策

如果按老流程走，这个项目会在 2022 年 8 月直接全量发布，然后带着 7% 的弱网丢单率和 3.4 秒首屏，去面对已经等了半年的销售团队。那次延期 4 周的决定，后来被销售负责人称为”公司做过的最省钱的决策”。

三、拆解六个把制度做死的常见误区

接下来这六个误区，我在不同公司身上都见过至少两次。它们的共同点是：看起来都在做阶段门，实际上都在消耗组织信任。

1. 把门做成文档门

文档门的特征是：评审时间几乎全部用于检查交付物是否齐备、格式是否规范，而对核心假设是否成立几乎不做追问。这种门给团队的感觉是”在走流程”，而不是”在做决策”。

判断方法很简单：如果你的门评审会上，超过一半时间在讨论文档结构，那它就是文档门。正确的会议时间分配应该是 20% 回顾事实、60% 质询假设、20% 讨论决策。

2. 门太少或者太多

门太少会导致大额投入在无检查的状态下持续累积，等到发现问题时沉没成本已经压垮了终止决策。门太多则会让团队把大量时间花在准备材料上，同时因为每次评审都很轻，反而没人认真对待。

一个可操作的判断标准是：如果连续两个门之间的间隔少于 2 周，考虑合并；如果超过 3 个月，考虑在中间插入一个只预警不否决的检查点。

3. 决策者缺席，让产品经理主持

这是我在第一版制度里犯的最大的错。让没有预算权的人主持决策会，结果是所有人都知道这场会的结论不算数，于是没人认真准备证据，也没人敢说真话。

修复方法很直接：把决策人写进门的定义里，并且规定决策人缺席则会议顺延，而不是由他人代为决策。宁可延期两天，也不要让决策悬空。

4. 准入条件不可量化

“方案合理””需求明确””技术可行”这三个短语，是我见过出现频率最高的伪准入条件。它们的问题在于无法证伪，任何项目都可以声称自己满足。

（1）把模糊表述改写成可复核事实

• 原表述”需求明确” → 改写为”至少 8 位目标客户完成访谈，5 位在过去 3 个月为同类问题付过费”
• 原表述”技术可行” → 改写为”完成关键路径原型验证，弱网环境丢单率低于 1%”
• 原表述”方案合理” → 改写为”最差情况下单用户服务成本不超过 3.2 元/月，已在预发环境实测”
• 原表述”用户会用” → 改写为”灰度用户 7 日留存不低于 35%，核心动作完成率不低于 60%”

5. 过门即失联，没有门后跟踪

很多公司只在门前用力，通过之后就没人再看这个项目。结果是门里承诺的指标、交付范围、资源计划全部失控，下一次出现在决策者面前时已经是一堆烂账。

我的做法是给每个通过门设置 2 到 3 个”门后观察指标”，由数据自动上报，一旦连续两周偏离超过 30% 就触发预警，不需要开会，只发一条通知给决策人和产品经理。

6. 把阶段门和敏捷对立

这是一个纯粹的认知错误。阶段门管的是”要不要继续投入”，敏捷管的是”怎么高效地把东西做出来”。前者是投资决策节奏，后者是交付节奏，两者作用在不同的维度上。

我在 100 人以上的团队里推荐的做法是：门保持季度或半年级别的粗颗粒度，门内的迭代保持两周节奏。门不会打断迭代，门只是决定下一批迭代有没有资源。

四、专业判断逻辑：一道门的准入条件到底怎么定

准入条件是整套制度里唯一真正决定成败的部分。流程图画错了可以改，决策人写错了可以换，但准入条件写虚了，整道门就是空的。我总结出一套四步判断法，在三个团队里验证过。

1. 每个阶段只锁一个最大的不确定性

阶段划分的本质，是给”最大的不确定性”排出验证顺序。概念阶段最大的不确定性永远是”这个需求是否真实存在、是否有人愿意付钱”，而不是”技术能不能实现”。计划阶段才轮到技术可行性。

（1）各阶段的核心验证对象

1. 概念阶段：需求真实性、付费意愿、目标用户规模。
2. 计划阶段：技术可行性、成本模型、依赖条件是否可获得。
3. 开发阶段：质量与成本的同步可控性，性能、稳定性、安全基线。
4. 发布阶段：用户是否真的会用、愿意续费、能否形成口碑传播。

如果某个阶段的门同时要求验证 4 个以上的假设，那说明你把它当成了万能门，实际结果一定是每个假设都验证得很浅。

2. 准入条件必须能被第三方复核

我用的检验方法是”陌生人测试”：把准入条件交给一个完全不了解这个项目的人，他能不能只凭数据和文档判断这条是否成立？如果不能，这条就需要重写。

“用户体验良好”过不了这个测试。”新用户首次完成核心操作的平均耗时低于 90 秒，样本量不低于 200″可以过。这个测试看起来很苛刻，但它能过滤掉绝大部分自欺欺人的表述。

3. 决策权限要跟着预算走

这是我在第二版里做得最对的一件事。每个门的决策人，必须拥有决策所需的预算权限，否则他的结论在执行时会打折扣。

决策时限这一列很重要。我见过一个门因为决策人出差，拖了 18 天，整个迭代计划全部作废，团队白等两周。门的决策时限应该是制度里最硬的约束之一。

4. 硬门与软门的组合公式

硬门卡的是不可逆的事：合规、安全、对外承诺、大额采购、模具投入。软门卡的是可以调整的事：方向优先级、资源分配、范围大小。

一个简单的组合公式是：凡是不通过就会造成不可逆损失的环节，用硬门；凡是只影响效率或优先级的环节，用软门。在 100 到 500 人规模的团队里，我通常建议 3 个硬门配 2 个软门，这个比例在多家公司的实践中被证明比较平衡。

5. 门与门之间的节奏设计

门的节奏设计有一个隐藏的陷阱：如果门之间的间隔恰好等于一个迭代周期，团队会形成”为一个门做准备”的依赖习惯，而不是持续交付。所以我通常把门安排在迭代周期的中间位置，让门的准备工作和迭代交付并行，而不是串行。

五、具体案例与数据观察：把门”焊死”在研发流程里

制度写成文档很容易，难的是让它每天真实发生。这一节讲三个季度的横向数据观察，以及我们怎么用研发管理平台把门里的关键动作固定下来。

1. 三个季度、6 家公司的横向观察

2023 年到 2024 年，我参与了 6 家公司的阶段门落地陪跑，规模从 120 人到 900 人不等，行业覆盖企业软件、智能硬件和金融科技。下面是这 6 家公司的平均数据（样本推演，非公开统计，仅供结构参考）。

这张表里最容易被忽略的一行是”单项目平均评审投入增加了 158%”。很多管理者看到这个数字会本能地抗拒，但把它和无效投入下降 13 个百分点放在一起看就明白了：多花的评审时间是投资，不是成本。按人均成本折算，每增加 1 人日的评审投入，平均减少约 11 人日的无效开发。

2. 用研发管理平台把门”焊死”在流程里

制度落地最怕的是”进系统前一套、进系统后一套”。我们的做法是把门的关键动作直接固化在工具里，让绕开制度的成本高于遵守制度的成本。以下几个做法在 PingCode 上实现得比较顺，也适用于其他同类平台。

（1）把阶段做成状态机而不是标签

最开始的错误做法是给工作项加一个”阶段”标签字段，结果所有人都可以随手改。改成状态机之后，阶段流转有了明确的准入与准出规则，跨越阶段必须触发一次评审记录。

（2）把准入条件字段化并设置校验规则

我们在需求与项目工作项上加了几个业务字段：目标客户访谈完成数、付费意向确认数、原型验证通过率、单用户服务成本实测值。当这些字段未填写或低于阈值时，状态机不允许流转到下一阶段，提交时直接报错。

这一条的效果非常直接：模糊表述在系统里无处可藏，因为系统不接受”需求清晰”这种文本。

（3）决策结论与证据留痕

每次门评审必须产出三条记录：决策结论、支撑证据链接、反对意见。第三条尤其重要，因为半年后复盘时，最有价值的往往不是当时的结论，而是当时被忽略的反对意见。

（4）自动化提醒与组合视图

门后观察指标通过看板自动刷新，一旦偏离阈值超过 30% 自动通知决策人。同时用组合视图把全部在推进项目按”阶段 × 风险等级”排布，让管理者一眼看到有多少项目卡在同一个门、有多少项目已经连续两次延期。

3. 部署方式与迁移成本的实际考量

把阶段门固化到工具里，绕不开两个现实问题：数据能不能放在自己机房，以及现有研发数据怎么迁。这两点在 100 人以上的组织里几乎是必答题。

以 PingCode 为例，它主要服务中大型企业及 100 人以上组织，支持私有化部署，也支持从 Jira 平滑迁移。我参与过的一个 600 人客户，历史 Jira 数据量约 42 万个工作项、3700 个字段自定义项，迁移加校验用了 6 周，其中真正停机时间只有 11 小时，其余都是双轨并行。

需要提醒的是，私有化部署不等于免除流程设计成本。工具解决的是执行一致性和留痕问题，准入条件写得对不对，仍然取决于产品经理的专业判断。

4. 哪些环节不该交给工具

有四件事我在任何项目里都不会用自动化替代：一是关键假设的质询，必须由真人追问”如果这个数据是错的会怎样”；二是反对意见的收集，匿名表单只能收集到表面意见；三是终止决策，必须有一个人签字承担；四是跨部门资源冲突的协调，这是政治问题不是流程问题。

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

阶段门没有通用最优解。团队规模、业务可逆性、合规要求不同，门的设计逻辑就要跟着变。下面按四种典型情况给出可直接落地的建议。

1. 50 人以下团队：2 个门 + 轻量模板

这个阶段最大的风险是把流程做得比业务还重。建议只保留两个门：立项门和发布门。立项门的准入条件控制在 3 条以内，评审时间不超过 90 分钟，决策人就是创始人或产品负责人。

不要引入交付物清单，用一份不超过两页的项目说明书代替。发布门的核心不是文档，而是灰

度数据的预设门槛，比如”7 日留存不低于 35% 才允许全量”。

2. 100 到 500 人团队：3 个硬门 + 1 到 2 个软门

这是阶段门收益最明显的区间。组织已经大到无法靠口头同步，但又没有大到需要多层委员会。建议设 3 个硬门，立项门、开发中期门、发布门，配 1 到 2 个软门用于方向对齐。

这个规模的关键动作是把准入条件字段化并固化到研发管理平台上，否则执行会随着人员流动迅速退化。我见过最能坚持的团队，是把准入条件的校验写进了工作项流转规则，新人不需要理解制度，系统会逼着他遵守。

3. 500 人以上或多产品线：5 门分层 + 组合管理

这个规模下，单项目视角已经不够用了。除了项目层面的门，还需要一层组合决策：在所有通过立项门的项目之间，如何分配有限的研发资源。

（1）分层决策的三个层级

1. 项目层：由各产品线的门负责判断单个项目是否继续。
2. 组合层：每季度一次，在所有候选项目间按战略匹配度和投入产出比排序分配资源。
3. 战略层：每半年一次，判断是否要新开或关闭整条产品线。

三层之间必须解耦，否则会出现”战略层说要聚焦，项目层还在申报 20 个新项目”的割裂现象。

4. 特殊行业的门设计

To B 大客户定制项目、硬件项目、强合规行业的门，需要额外处理两类问题：一是不可逆投入（模具、认证、合同承诺），必须在门里设为硬性一票否决项；二是外部依赖（客户验收、监管审批），门的节奏要跟外部节点对齐，而不是跟内部迭代对齐。

硬件项目的门通常要比软件多 1 到 2 个，因为开模、试产、量产准备都是不可逆节点，一旦进入就很难回头。

七、不同情况下的取舍

制度设计到最后，几乎全部是取舍问题。没有一种设计能同时做到又快又稳又省人力，关键是清楚自己在放弃什么。下面五组取舍是我被问得最多的。

1. 速度 vs 可控

门越多、准入条件越严，可控性越高，速度越慢。反过来也是如此。判断标准不是”我们要不要快”，而是”这个项目失败一次，我们承受得起吗”。

可承受的失败，用软门快跑；不可承受的失败，用硬门慢走。把这两类项目混在一套流程里管理，一定会在其中一端出问题。

2. 标准化 vs 灵活性

标准化让流程可以复制、可以审计、可以横向对比，代价是特殊项目会被流程拖累。灵活性让团队按实际情况调整，代价是标准和数据无法沉淀。

我的做法是标准化准入条件的”结构”，而不标准化”内容”。所有项目都必须回答需求验证、成本、风险三类问题，但每类问题的具体指标可以按项目类型配置不同模板。这样既保证可比性，又保留适配空间。

3. 硬门 vs 软门

硬门的价值在于有约束力，风险在于误杀。软门的价值在于效率，风险在于形同虚设。实践中我倾向于把硬门留给三类场景：合规与安全、不可逆投入、对外承诺的交付日期。

其他场景尽量用软门，但软门必须做到一件事，结论必须落文档，且必须写明决策依据。软的是否决权，不是证据要求。

4. 自研流程 vs 工具承载

纯人工管理的阶段门，在 50 人以下还能靠习惯维持，超过 100 人就会迅速退化，因为入职培训讲不清楚、执行偏差没人发现、历史记录无法追溯。

我的判断阈值是 80 人：超过 80 人，就应该把阶段流转和准入校验固化到研发管理平台里。选型时优先看三件事：能否支持阶段状态机、能否做字段级校验、能否输出组合视图。如果团队有数据驻留要求，还要看是否支持私有化部署。

5. 数据完备 vs 决策时效

最纠结的一组取舍。等数据齐全再决策，往往错过窗口期；数据不足就决策，等于拍脑袋。

我用的规则是：为每个门预先定义”最低证据集”，只要最低证据集齐备就开会，不追求数据完备。比如发布门的最低证据集可以是”灰度样本量达到 200、核心指标置信区间已知、无 P0 未修复缺陷”，其他数据可以后续补充，但不影响本次决策。

八、一页纸模板：阶段门制度设计检查清单

最后给出我实际使用的检查清单模板。它的形式是一段结构化的门定义，可以直接交给产品经理填写，也可以转换成研发管理平台里的字段配置。

gate:
名称: 开发中期门

阶段: 开发阶段 -> 发布准备

决策人: 事业部总经理（预算权限 300 人月以内）

决策时限: 5 个工作日

最低证据集:

关键路径性能实测报告（样本量 >= 200 次请求）

单用户服务成本实测值（含最差情况）

P0/P1 缺陷清单及修复计划

灰度范围与回滚方案

准入条件:

弱网环境下核心动作失败率 < 1%

首屏加载 P95 < 2.0 秒

单用户月均服务成本 < 3.2 元

结论枚举: [继续, 加注, 暂停, 终止]

退路:

暂停: 冻结开发资源，保留 1 人做方案验证，最长 6 周

终止: 沉淀技术复盘，组件资产并入公共库

门后观察指标:

迭代按期完成率（阈值 85%，偏离 30% 触发预警）

缺陷逃逸率（阈值 3%，连续两周超标触发预警）

这份模板有两个设计细节值得说明。第一，”退路”里给暂停设了最长时限，避免暂停变成无期限搁置。第二，”门后观察指标”只有 2 条，因为指标越多越没人看。

九、总结与下一步：把这套制度用 30 天跑起来

回到最初的问题。阶段门真正解决的问题，不是让流程更规范，而是让组织在投入还小的时候，有勇气承认一个方向是错的。我见过太多团队，决策质量随着投入增加而下降，因为沉没成本会绑架判断。

阶段门的本质是一套制度化说”不”的机制。它用固定的时间节点、可复核的证据要求、明确的决策人和预设的退路，把”止损”从一件需要政治勇气的事，变成一件例行公事。

我在实践中得到的最反常识的结论是：好的阶段门制度，会让立项变难、让终止变容易。如果你的制度效果正好相反，立项很容易、终止几乎不可能，那不管画了多少个门，它都只是一套装饰。

1. 30 天落地路线

1. 第 1 周：梳理过去 4 个季度的项目数据，算清楚当前的按期交付率、无效投入占比、返工成本占比，作为基线。
2. 第 2 周：确定门数量和硬软门组合，为每个门写清决策人、决策时限、最低证据集和退路。
3. 第 3 周：把准入条件改写成可复核的事实陈述，逐条做”陌生人测试”，通不过的重写。
4. 第 4 周：在研发管理平台里配置阶段状态机与字段校验，同时准备门后观察指标的自动上报。

第 5 周开始试运行，建议先选 3 个项目做试点，观察一个完整周期再全面推开。全面推开时最重要的一件事是公开宣布：本季度至少要有项目被门拦下来。如果第一个季度一个都没拦，说明门还是虚的。

2. 下一步你可以做的三件事

第一，翻出你手上投入最大的三个项目，问自己一个问题：如果今天重新决策，我还会立项吗？如果答案是否定的，说明你已经缺了一道有效的门。

第二，把现有的准入条件逐条拿出来做陌生人测试，凡是无法被第三方复核的，全部重写成可验证的事实陈述。这一步通常只需要半天，但收益立竿见影。

第三，如果你所在的团队超过 100 人，把阶段流转和准入校验固化到研发管理平台里。制度靠培训维持的时间上限大概只有 6 个月，靠系统维持才能跨过人员流动的周期。

阶段门不是让组织变慢的官僚机制，它是让组织在正确的方向上跑得更久的机制。做对了，你会发现砍掉的项目越多，留下来的项目成功率越高。