阶段门怎么做？管理层流程优化：项目阶段从0到1

2021 年我参与过一家 400 人规模的 SaaS 公司做流程改造。他们当时的研发流程里有 6 个阶段门评审点，每个项目平均每季度要花 11.5 人天准备评审材料。管理层觉得太重，一刀砍到 3 个。第一年的数据出来，会议室里没人说话：项目平均延期天数从 26 天涨到 41 天，需求返工率从 14% 涨到 23%。

这个结果我复盘过很多次。砍掉的 3 个评审点里，有 2 个是真正决定”要不要继续投钱”的决策点，剩下 1 个是汇报会；而保留下来的 3 个，全是汇报会。换句话说，我们把唯一的刹车拆了，把仪表盘留在了原地。

阶段门（Stage-Gate）这套方法从 1980 年代 Robert Cooper 提出到现在，被写进无数流程手册，但真正做对的团队非常少。多数公司做出来的不是阶段门，是”阶段性汇报”。这篇文章我想把这件事从 0 到 1 讲透：阶段门到底管什么、为什么大多数公司把它做成了形式主义、怎么设计、什么情况下应该放弃它。

一、核心结论：阶段门管的是决策权，不是进度

先把结论放在最前面。阶段门的本质不是流程节点，而是组织对”继续投入资源”这件事的决策权分配机制。它回答的唯一问题是：在信息还不完整的时候，谁有权拍板继续投、暂停、转向或终止。

如果你设计的阶段门不能回答这个问题，那它就只是一个汇报会。汇报会当然有价值，但它和阶段门是两种东西，不该混在一个会议里。

1. 阶段门必须回答的三个问题

我在给团队做流程诊断时，会拿这三个问题去问阶段门的实际参与人。三个都答得上来，说明这个门是活的；只答得上一个，基本可以判定是形式主义。

• 谁有权说”停”？不是谁有权提出建议，而是谁签字之后项目真的会停、预算真的会冻结。
• 停下来的代价是什么？如果暂停一个项目不会影响任何人的考核、预算和人力，那这个”停”就是假的。
• 通过的标准是什么？是”材料齐全”还是”关键假设被验证”？前者是行政标准，后者是决策标准。

2. 一个快速判断标准

我常用一个极简的检验方法：假设明天所有阶段门评审会都取消，会发生什么？

如果答案是”项目照样推进，只是少开几个会”，那你的阶段门没有决策功能。如果答案是”会有项目在明显该停的时候继续烧钱”，那说明阶段门在起作用，哪怕它的形式很粗糙。

反过来也成立：很多团队阶段门开得很勤，但从来没有一个项目在门上被真正叫停过。连续 12 个月零否决，这不是流程健康，这是决策失效的信号。

3. 阶段门和里程碑的本质区别

这张表我在内部培训里用过很多次。最常见的错误，是把阶段门当成”更正式的里程碑”来做，加了个评审会，多填了两张表，参与人还是原来那批，决策权一点没变。

二、背景：一家 400 人公司为什么把阶段门做废了

回到开头那个案例。这家公司不是没做阶段门，他们做了整整 6 个，而且还配了完整的模板、检查清单和打分表。问题出在别处。

1. 场景还原

他们的 6 个门分别是：立项评审、需求评审、技术方案评审、开发完成评审、测试通过评审、上线评审。听起来很完整，但仔细看会发现，这 6 个门全部落在”交付动作”上，没有一个是落在”投入决策”上。

立项评审是最接近决策点的一个，但它的问题在于：立项时的预算已经在这个季度被拆进了部门计划，评审即使不通过，钱也已经在花了。也就是说，这个门在最需要它的时刻，手里没有资源权。

其余 5 个门更接近质量关口。它们能发现”做得不对”，但发现不了”不该做”。

2. 三个反常数据

我们当时拉了 18 个月的数据做对比，有三个数字最反常：

• 评审通过率高达 91%。391 次评审里只有 35 次未通过，而且其中 28 次是”材料不全，补完再来”。
• 平均每个项目的评审材料 47 页。但决策者实际阅读的部分，根据会后问卷统计，平均不到 8 页。
• 项目一旦立项，终止率为 0。18 个月里没有一个项目被正式终止，有 6 个项目事实上已经停滞，但仍在预算表里挂着。

这三组数字放在一起，指向同一个结论：阶段门在做信息汇报，没在做资源决策。

3. 根因不在流程，在权力结构

很多人第一反应是”模板不对””指标不够量化”。但我带团队复盘了两周，真正的根因是：评审会的决策权和资源权是分离的。

参加评审的是技术负责人、产品负责人、项目经理，他们能判断项目”好不好”，但不能决定”给不给钱、抽不抽人”。真正的资源决定权在季度初就已经被锁定在部门预算里了。

这种情况下，阶段门无论设计得多精细，都只能是建议性的。建议性的门，执行时间一长必然退化成汇报。

三、拆解五个最常见的阶段门误区

我见过至少二十家公司的阶段门设计，反复出现的错误其实就这么几类。每一类我都标注了它的典型症状，方便你对照自查。

1. 误区一：把评审当验收

症状是评审材料以”已完成 XX 功能”为主语，讨论焦点集中在”做得对不对”，而不是”该不该继续做”。

验收解决的是质量一致性，阶段门解决的是资源方向。把两者合并的后果是：一个方向明显不对的项目，只要质量过关，就能一直通过评审。

我的判断是：验收可以在阶段门里做，但只能是附属动作，不能是主要议题。如果一场评审会 80% 的时间在讨论 bug 和代码质量，这个门就该拆成两个。

2. 误区二：所有项目用同一套门

50 人月的大项目和 2 人月的小项目，走同样的 6 个门、填同样的模板，这是极常见的做法，也是最浪费的一种。

我们当时的统计是：小项目平均 3.2 人天/门的评审成本，占项目总预算的 6%~9%。对大项目来说这不算什么，对小项目来说，这个比例已经足以让团队倾向于”把项目做大一点”来分摊流程成本，这是个非常糟糕的激励。

3. 误区三：决策权和资源权分离

这是第二节讲的那个根因。表现很隐蔽：会议开得很认真，讨论很充分，结论也写得很清楚，但执行层面纹丝不动。

识别方法很简单：看阶段门的结论有没有真正改变过预算表。如果最近一年预算表的结构和阶段门结论完全无关，那这个门就是空的。

4. 误区四：只有”通过”和”不通过”

现实中的决策大多处于中间状态。一个项目可能方向对、节奏错，或者方案对、资源不够。如果门只有两个出口，评审人为了不背锅，几乎必然选择”通过”。

我在实践里会强制要求设置至少四档结论：通过、有条件通过（明确条件清单和复查时点）、暂停（保留团队，冻结新增投入）、终止（释放资源）。多出来的两档，是整个阶段门体系里最值钱的部分。

5. 误区五：门后没有追踪

“有条件通过”最容易被浪费。条件写了，谁在什么时候验证，没有约定，三个月后条件早就没人记得。

我们的做法是：每个”有条件通过”必须绑定一个责任人、一个复查日期和一个自动提醒。这不是流程细节，这是阶段门能不能闭环的关键。

四、专业判断逻辑：阶段门的四个设计变量

如果你只记一个框架，记这四个变量就够了。决策点密度、证据标准、否决权归属、返工成本。任何阶段门设计无非是在这四个变量上取值。

1. 决策点密度：几个门，卡在哪儿

决策点密度不是越多越好，也不是越少越好。它取决于两件事：单位时间内的资源投入强度，以及错误的可逆性。

投入强度大、错误不可逆的环节，就该设门。典型的是：需求定型前、架构定稿前、规模化开发启动前、对外发布前。反过来，内部工具改造、可灰度回滚的实验性项目，门的密度可以非常低。

我通常给的建议是：按”每消耗 15%~25% 的项目总预算”设一个门。这个比例是经验值，但它背后的逻辑很硬，门的价值来自于”在还有退路的时候停下来”，消耗到 60% 再停，损失已经很难挽回了。

2. 证据标准：什么算”验过了”

这是最容易被做成形式主义的地方。很多公司的阶段门证据标准是”提交了需求文档”，这等于没有标准。

我坚持的证据分级是这样的：

1. 观点级：某人认为可行。除非是领域专家，否则不作为通过依据。
2. 数据级：有历史数据或用户调研支撑。可作参考，需注明样本量和偏差。
3. 验证级：做过小规模真实实验，有可复现结论。这是阶段门通过的基本门槛。
4. 承诺级：有外部客户或业务方的明确承诺（合同、预算、排期）。可以直接支撑重大投入决策。

大部分阶段门事故，都是拿观点级证据去支持验证级决策。

3. 否决权归属：谁能真的叫停

这一条最难，因为它触动的不是流程，是权力。我的经验是：否决权必须给到那个”资源被释放后会受益的人”或”资源被浪费后会受损的人”。

前者通常是另外一个业务线的负责人，后者通常是财务或高层。把否决权给到项目发起人自己，等于没有否决权。

实际操作里，很多公司会让 CTO 或研发负责人掌握否决权，但他们的考核又和”研发产出量”绑定。这种情况下，否决权会被系统性虚置。要么改考核，要么换人掌握否决权，二选一。

4. 返工成本：决定门该设多严

返工成本是阶段门设计里最被低估的变量。同一个错误，在需求阶段被发现和在发布后发现，成本差着一个数量级。

看到这组数字，很多管理者的第一反应是”那我把门设密一点”。但这会撞上另一个约束：门的边际成本也会累积。每次评审消耗的不仅是会议时间，还有团队的上下文切换成本和等待排期的机会成本。

（1）四种典型配置及其适用边界

我个人最推荐的是动态门，但前提是你的组织已经能比较准确地评估项目风险等级。如果风险评估本身就不靠谱，那动态门会变成”想严就严、想松就松”的橡皮筋。

五、具体案例：100 人以上组织怎么把阶段门从 0 到 1 跑起来

讲完逻辑，说一个我做过的完整落地案例。这家公司约 260 人，其中研发 140 人，做的是 B 端 SaaS，同时并行 9~14 个项目。他们的痛点是：项目多、资源紧、优先级天天吵，但没有一个机制能真正把某个项目停下来。

1. 第一步：把”决策点”和”汇报点”分开

我们做的第一件事不是设计新流程，而是把现有 7 个评审会逐个过筛，只问一个问题：这个会上，有没有人真的能决定”不给钱、不给人”？

筛完的结果是：7 个会里，2 个是真决策会，3 个是跨部门对齐会，2 个是质量验收会。我们保留了全部 7 个会，但把它们标注成三种不同类型，各自用不同的议程模板和不同的参与人名单。

这一步的价值被严重低估。很多流程优化之所以失败，是因为一上来就砍会议，而不是先给会议分类。分类之后你会发现，很多会其实不需要砍，只是被当成了错误的角色在用。

2. 第二步：只设 3 个决策门，但每个门都有资源后果

他们最终保留了 3 个决策门：立项门、方案定型门、规模化投入门。每个门都有明确的资源开关。

• 立项门不通过：不分配专属人力，只允许用探索额度（每月上限 3 人日）。
• 方案定型门不通过：项目停留在探索状态，不能进入正式排期池。
• 规模化投入门不通过：不批规模化开发人力，已投入的资源转入复盘而非继续。

关键在于这三条都能被执行。它们不依赖评审人的主观意愿，而是挂在资源分配系统里，不通过就取不到资源。

3. 第三步：用工具把”有条件通过”变成可追踪的对象

前面说过，有条件通过最容易烂尾。这家公司当时的做法是用邮件记录条件，然后就没有然后了。后来他们把决策结论、责任人、复查日期和条件清单全部结构化，放进 PingCode 的项目阶段管理里，每个只等复查的条件自动生成待办并指派到人，到期未处理会在管理层的项目视图里标红。

PingCode 主要服务中大型企业及 100 人以上组织，这个案例里它的作用不是”做流程”，而是把流程里最容易腐烂的那一段变成有状态、有责任人的对象。同时它支持私有化部署，对于有数据合规要求的研发组织来说，这一点在阶段门落地时经常是硬性前置条件，因为评审材料里往往包含未公开的产品规划和客户信息。

他们迁移的过程也值得一提。原来用的是 Jira，历史项目里有大量和阶段门相关的自定义字段和状态。PingCode 支持 Jira 平滑迁移，他们把需求、缺陷、迭代和历史评审记录一起迁过来，避免了两套系统并行半年、数据对不上的典型困境。对国产替代场景来说，这是比较实际的一条路径。

4. 第四步：跑 6 个月，看四个数字

落地后我们跟踪了 6 个月。这里必须说明：这是单一样本的组织观察，不是行业统计，不能直接外推到其他公司。但变化的方向和幅度仍然有参考价值。

我想特别强调第三项。项目终止次数从 0 变成 4，在很多管理者眼里是”变差了”，但在我看来这是这套流程第一次真正工作。一个从来不停任何项目的组织，不是项目都很好，而是没有刹车。

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

阶段门没有通用最优解，只有匹配当前组织状态的解。我按组织阶段和项目类型分几种情况给出建议。

1. 30~80 人的团队：先别急着设门

这个规模的组织，沟通成本本身就低，信息不对称问题不严重。硬套一套阶段门，大概率是增加负担而不是提升决策质量。

我的建议是：只设两个门，立项前的一个”要不要做”讨论，和一个”要不要规模化投入”的检查点。不要写模板，不要打分表，用一页纸回答三个问题：目标是什么、怎么验证、如果不对什么时候停。

关键是第三个问题。哪怕只有一句话，只要每次真的问了，效果就出来了。

2. 100~500 人的组织：这是阶段门收益最高的区间

这个区间最典型的症状是：项目并行度高、跨部门沟通成本陡增、资源冲突频繁、决策靠会议而非机制。阶段门在这个规模能带来最明显的边际收益。

建议路径是：

1. 先做会议分类（决策会 / 对齐会 / 验收会），不砍会，先贴标签。
2. 识别出 3 个真正的资源决策点，给每个点明确资源开关。
3. 把结论分成四档，重点建”有条件通过”的追踪机制。
4. 建立决策台账，每季度回看一次否决记录和推翻记录。

第 4 步很少有人做，但它是判断流程是否活着的唯一方式。如果连续两个季度没有任何否决或暂停，先怀疑流程，不要怀疑项目质量。

3. 500 人以上：要处理的是”门与门之间的信息失真”

到这个规模，问题往往不再是”有没有门”，而是”门上的信息还能不能代表真实情况”。层层上报会让证据衰减，传到决策层时，验证级证据经常已经被磨成了观点级。

我的建议是引入两个机制：原始证据直连机制（关键指标从系统直接取，不经过人工汇总）和反向陈述机制（每个项目必须指定一个人负责陈述”这个项目可能失败的理由”）。

第二个机制听起来有点反直觉，但它在实践中非常有效。它把”唱反调”变成了正式职责，而不是政治不正确的行为。

4. 强监管或对外承诺型业务：门的密度向前移

这类业务的错误往往不可逆，返工成本曲线极陡。策略不是简单加门，而是把门的重心前置，在需求和合规评审阶段投入更多评审资源，后期反而可以适度放宽。

我见过的最失败的做法是：前期评审从简，后期层层加码。这会导致团队在错误的方向上跑得更远，然后被一堆验收标准拦住，最后既不快也不对。

七、不同情况下的取舍

流程优化的本质是取舍。想着”既要又要”的方案，通常在落地三个月内就会失效。下面是我认为最难回避的三组取舍。

1. 标准化 vs 速度

标准化让管理成本可控、数据可比、经验可复用；速度要求流程给项目让路。两者不可能同时最大化。

我的取舍原则是：对项目分类，而不是对流程打折。把项目明确分成标准流程和快速通道两类，快速通道有明确的准入条件和数量上限（比如不超过项目总数的 20%），并且需要更高层级的人签字进入。

这样做的好处是，流程的严肃性保留了，速度也有了出口。坏处是快速通道一定会被滥用，所以数量上限和定期审计是必须的配套动作。

2. 数据完整 vs 决策及时

完美的证据标准意味着更晚的决策。很多组织的阶段门卡在这里：要么等数据等到错过窗口，要么拍脑袋决策然后反复推翻。

我的处理方式是按决策类型分档：

• 可逆决策：允许数据级证据，快决策，错了改。
• 不可逆决策：要求验证级或承诺级证据，慢决策，宁可晚。

关键是提前明确哪些决策属于不可逆。等到会上争论”这算不算不可逆”，就已经晚了。

3. 集中决策 vs 一线自主

集中决策保证了资源一致性，代价是响应慢、信息失真。一线自主响应快，但容易造成资源重复投入和方向分散。

这张图我想说一个反直觉的判断：决策被推翻率会随集中度上升而上升。原因不复杂，越往上走，信息越失真，决策建立在不完整的现实之上，执行时自然会被迫调整。

所以真正的取舍不是”集中还是分散”，而是哪些决策必须集中、哪些必须下沉。我的划分标准是：涉及跨项目资源重新分配的，集中；涉及单一项目内部实现路径的，下沉。

八、下一步：一个可以马上启动的 90 天最小方案

如果你认同一部分的判断，我建议不要一次性重做流程，先用 90 天验证一个最小闭环。这套方案我在两个组织里跑过，规模分别是 180 人和 260 人。

1. 第 1~3 周：只看不改

把现有的所有评审会列出来，标注三件事：谁能决策、能决策什么、会后有没有可追踪的动作。不要动任何流程，先看清现状。

这一步最容易被跳过，但也最重要。我见过太多团队在没看清现状的情况下改流程，改完之后发现改的其实是不重要的那几个会。

2. 第 4~6 周：选出 3 个门，配资源开关

从现有会议里选出 3 个最能影响资源分配的，给它们加上明确的资源后果。注意是”加上”，不是”新增”，尽量复用已有的会议，减少组织摩擦。

3. 第 7~9 周：把结论结构化，跑通一次闭环

四档结论、责任人、复查时点、自动提醒。哪怕只在一个项目上完整跑一次，也要跑通。闭环的价值远远大于覆盖面。

这一阶段工具的作用会变得明显。如果条件允许，用项目管理平台承载结论和复查动作，比用邮件和表格靠谱得多。像前面提到的私有化部署能力，在有数据合规要求的组织里可以省掉很多后期的返工。

4. 第 10~13 周：复盘四个数字

跟踪四个指标：决策周期、有条件通过按期复查率、项目终止或暂停次数、资源重新分配周期。这四个数字给你的信号，比任何流程评估报告都直接。

结语：阶段门真正的门槛，是承认有些项目该停

写了这么多，我最想留下的一个判断是：阶段门做不起来，绝大多数时候不是流程设计能力问题，而是组织不愿意面对”项目该停”这件事。

否决一个项目，意味着承认之前投入的资源不会回来，意味着要有人为当初的决定负责，意味着短期内可交付的成果会变少。这些代价都是真实的，也是为什么大量阶段门最终变成了盖章流程。

但反过来说，一个不能停项目的组织，实际上也没有真正的项目管理，它只有执行管理。项目的价值恰恰体现在资源可以被配置到更值得的地方，而配置的前提，是有一套机制允许资源被收回。

如果你准备下一步行动，我的建议是按这个顺序：先花三周把现有的评审会分类，找出那 3 个真正的资源决策点；然后给它们绑上资源开关，让”不通过”产生真实后果；最后，把”有条件通过”变成有责任人、有复查日期的可追踪对象。不要一开始就追求流程完整，先让它真的能刹住一次车。

三个月后回看，如果你发现从来没有项目被暂停或终止过，问题不在流程文档里，在决策权归属上。那时候要改的，是权力结构，而不是模板。