项目阶段阶段门全流程：项目经理风险控制与一文讲清

去年我参与复盘一个”软硬结合”的项目：模具已经开完、首批物料已经入库，量产前评审会上，市场负责人问了一句”这个定价，渠道商为什么愿意进货”。会议室安静了十几秒。真正的问题不是技术做不出来，而是这个项目从来没有在”还能掉头”的时候被问过这个该问的问题。最终它延迟 7 个月上市，仅模具与首批物料就沉没约 360 万元，而这类钱在阶段门的语言里叫”不可逆成本”。这篇文章我不想再复述一遍教科书上的 Stage-Gate 流程图，我想讲的是：阶段门到底该怎么设计、怎么卡、卡在哪、卡多严，以及项目经理怎么用它真正控住风险而不是给自己加一层审批负担。

一、先给结论：阶段门不是审批仪式，而是风险止损点

如果你只从这篇文章里带走一句话，我希望是这句：阶段门的唯一目的是在不可逆成本发生之前，把一个项目”杀掉”或者”改写”。它不是为了让领导签字，不是为了让流程看起来规范，更不是为了让项目经理多一份汇报材料。判断一个阶段门有没有价值，标准只有一个，它是否改变过任何一个项目的走向。

1. 阶段门的本质：用可控的沉没成本，换确定性的信息

任何项目在推进过程中，信息量是不断增加的，而成本的可逆性是不断下降的。项目早期，你对市场、技术、成本的认知都很模糊，但此时改方向几乎不花钱；项目后期，你什么都清楚了，但改一个螺丝孔位可能都要重开模具。

阶段门做的就是在这两条曲线之间找一个切割点：在信息成熟度还不足以支撑下一笔大投入时，强制停下来做一次判断。它不是”检查进度”，而是”检查假设”。进度落后 20% 通常只是效率问题，而核心假设被证伪才是项目级灾难。

2. 三个反常识结论

反常识一：阶段门越少，项目反而越容易失控。很多人觉得裁掉几道门能让项目跑得更快，但如果被裁掉的是”不可逆成本发生前”的那道门，项目只是把风险推迟到了更贵的阶段兑付。我见过的真实情况是，砍掉立项门之后，返工成本反而上升，因为错误的方向被更晚发现。

反常识二：通过率过高，是门禁失效的第一个信号。如果一个组织连续两年阶段门的通过率都在 90% 以上，那基本可以断定这些门没有在做筛选，只是在做登记。健康的门禁通过率应该和行业风险水平匹配，硬件、医药类项目立项门的通过率通常低于 40%。

反常识三：阶段门的最大成本不是评审时间，而是”该停没停”。一次评审会两小时，一年开 30 次也就是 60 小时。但一个该砍没砍的项目拖到量产，代价是数百万元量级。真正贵的不是开会，是开着会却什么都不决定。

3. 阶段门真正管的是”决策权”，不是”进度”

这是我做了多年项目复盘之后最深的体会：大部分企业的阶段门文件写的是”进度要求””交付物清单”，但从来不写”谁有权在这个门上说不”。一份没有明确否决权的阶段门，本质上是进度汇报会。

所以在设计阶段门的时候，我会先问三个问题：谁有权在这个门上终止项目？终止之后资源怎么释放？被终止的项目负责人会被怎么对待？第三个问题的答案，决定了这套阶段门最后会不会变成走过场。

二、为什么大部分企业的阶段门会失效

我参与过十几家企业的研发流程诊断，从 30 人的创业团队到几千人的制造集团。阶段门这个东西，几乎每家公司都有，但真正起作用的不到三成。失效的原因高度集中，就那么几类。

1. 我见过的三类典型失效场景

第一类是”补签型”。评审会开完了，结论是”通过，但有若干整改项”，然后整改项没有任何人跟踪，下一次评审时大家默认它已经完成了。这类失败最隐蔽，因为流程记录看起来完全合规。

第二类是”缺席型”。关键决策者（通常是能调动资源、能说不的那个人）因为出差、会议冲突没有到场，委托下属代为签字。下属不敢否掉老板关心的项目，于是门就成了橡皮章。

第三类是”标准漂移型”。准出条件写得很模糊，比如”技术方案基本成熟””市场反馈良好”。什么叫基本、什么叫良好，每次评审的标准都不一样，最后变成看谁汇报得更有感染力。

2. 失效的根因：决策者缺席 + 准出条件模糊

把上面三类失效往回倒推，根因只有两条：该做决定的人不在场，以及做什么决定没有量化标准。剩下的都是这两条衍生出来的表象。

准出条件模糊这件事尤其致命。我见过一份门禁文件里写着”核心技术指标达到行业领先水平”，这句话在评审会上可以被解释成任何意思。真正可执行的准出条件必须带数字、带测试方法、带责任人和验证时间点，否则它就是一句口号。

3. 一个值得警惕的信号：门后返工率

如果你想快速判断自家阶段门有没有用，不用做复杂审计，看一个指标就够了，每个阶段门通过之后的 30 天内，因为该门应该发现却没发现的问题导致的返工占比。

这个指标如果超过 30%，说明门禁在前移风险这件事上基本没起作用。我给几家客户做过这个统计，做得最差的团队是 68%，也就是说三分之二的返工本可以在上一个门被发现。

三、Stage-Gate 全流程拆解：每一道门到底该卡什么

经典 Stage-Gate 理论把项目分成若干阶段和若干门，但直接照搬教科书会水土不服。下面这套结构是我在实际项目中反复调整后相对稳定的一版，你可以按自己的行业特性增减，但不要破坏”信息-成本”的对应关系。

1. 六个阶段与五道门的对应关系

我把流程拆成六个阶段：发现（Discovery）、筛选（Scoping）、立项（Business Case）、开发（Development）、测试验证（Testing & Validation）、上市（Launch）。对应五道门：筛选门、立项门、开发门、测试门、上市门。

关键不在阶段怎么划，而在每道门对应的不可逆成本阈值。筛选门之前几乎不花钱，立项门之后开始投入人力，开发门之后开始投模具、开产线、采购物料，测试门之后开始备货、铺渠道。每一次不可逆成本的跃升，都应该有一道门卡在前面。

2. 每道门的四类交付物

我把每道门需要提交的材料固定成四类，缺一类就不能开评审会。这四类的划分方式，比列一个长长的文档清单更能让人理解”为什么要交”。

• 事实类：测试报告、用户访谈原始记录、成本核算表、供应商报价单。这类材料回答”发生了什么”。
• 判断类：商业论证、竞品分析、风险清单及应对方案。这类材料回答”这意味着什么”。
• 承诺类：资源需求表、里程碑计划、责任人签署。这类材料回答”谁答应做什么”。
• 决策请求类：一页纸的决策请求，明确写清”我请你在 A/B/C 三个选项中选择”。

第四类最容易被忽略，也最重要。我见过太多评审会开完，与会者都不知道自己刚才做了什么决定。一份没有明确决策请求的评审材料，注定产出一个含糊的结论。

3. 准出条件怎么写才可执行

准出条件（Gate Criteria）是阶段门的核心资产。我用的写法是”指标 + 阈值 + 验证方法 + 责任人 + 验证时点”五要素齐全，缺一个都不算合格。

gate: 立项门 G2
criteria:

id: G2-C1

name: 目标客户付费意愿验证

metric: 目标客户中愿意预付定金的比例

threshold: ">= 15%（样本量 >= 30 家）"

method: 定向访谈 + 意向订单登记

owner: 市场负责人

verify_at: 立项评议会前 3 个工作日

id: G2-C2

name: 单位成本可达性

metric: 量产 BOM 成本

threshold: "method: 供应商正式报价单（至少 2 家）

owner: 硬件负责人

verify_at: 立项评议会前 5 个工作日

id: G2-C3

name: 关键技术风险收敛

metric: 未通过验证的高风险技术点数量

threshold: "= 0"

method: 技术预研测试报告

owner: 技术负责人

verify_at: 立项评议会前 5 个工作日

decision:

options: [批准立项, 有条件批准（限期补件）, 退回补充论证, 终止]

decider: 产品委员会（与会人数需 >= 3 且包含至少 1 名非项目组成员）

这套写法看起来啰嗦，但它把”能不能过”从主观判断变成了事实核对。评审会的时间从争论”到底行不行”转向核对”数据是不是真的”，效率提升非常明显。

4. 门与门之间的四种决策结果

很多人以为阶段门只有”通过”和”不通过”两种结果，这是导致门禁僵化的一个重要原因。实际上一道健康的门应该给出四种结论：

1. 批准（Go）：条件全部满足，按原计划进入下一阶段。
2. 有条件批准（Conditional Go）：核心条件满足，存在少数非致命缺口，限期补齐且明确补不齐的后果。
3. 重做（Recycle）：方向没问题，但论证不充分，退回上一阶段重新准备。
4. 终止（Kill）：核心假设被证伪或战略不再匹配，立即停止并释放资源。

注意第 3 种和第 4 种的区别。”重做”意味着还有希望，”终止”意味着结束。一个组织如果一年下来从未出现过”终止”这个结论，那它的阶段门大概率只是装饰。

四、阶段门落地的五个常见误区

知道正确的做法不难，难的是避开那些看起来合理、实际上有害的做法。以下五个误区我在不同企业都遇到过，程度不同而已。

1. 误区一：门越多越安全

有些企业一听说阶段门有用，就在流程里塞进十几道门：需求评审门、设计评审门、代码评审门、测试准入准出门、发布门……结果是每个门都变得很轻，因为没人有精力认真对待十几次评审。

门的安全性与数量不成正比，与”是否卡在不可逆成本跃升点”成正比。我一般建议中大型研发组织控制在 4 到 6 道门，每道门都必须能回答”如果不设这道门，会多花多少钱”。

2. 误区二：把门当成绩效考核工具

一旦阶段门的通过率被写进部门 KPI，会发生两件坏事：一是没人愿意提报有风险但有价值的项目，二是数据开始被美化。我见过一个团队为了”立项门通过率达标”，把本该做 30 家访谈改成 8 家，因为访谈样本少，结论更容易写得漂亮。

阶段门应该考核的是决策质量，比如”立项门上被识别出的重大风险，有多少在后续阶段真正发生了””被终止的项目，资源释放是否及时”，而不是通过率本身。

3. 误区三：所有项目用同一套门

一个 30 人天的小功能迭代和一个 3000 万元的新产品线，用同一套门禁标准，只有两种结局：小项目被拖死，或者大项目被放水。正确做法是按风险敞口分级，不同等级走不同的门。

4. 误区四：只评技术可行性，不评商业假设

这是研发型组织最容易犯的错。技术评审做得非常扎实，每个接口、每个性能指标都反复验证，但”客户愿不愿意为此付钱””渠道愿不愿意进货”这类商业假设从来没人验证。

我参与的复盘里，失败项目中有超过一半的死因是商业假设不成立，而不是技术做不出来。技术风险是可以加班解决的，商业假设错了，加班只会让你更快地烧完钱。

5. 误区五：门通过之后没人跟踪承诺

评审会上的整改项、有条件批准中的待补材料、”资源承诺表”里各部门答应的人，如果没有跟踪机制，三个月后就会全部蒸发。这也是我建议把阶段门落到工具里的核心原因，流程可以靠会议推动，承诺必须靠系统跟踪。

五、专业判断逻辑：门禁设计的四个核心变量

说了这么多”应该怎么做”，接下来讲”为什么这么判断”。阶段门的松紧程度不是拍脑袋定的，它由四个变量共同决定。理解这四个变量，你就能为自己的组织设计一套合适的门禁，而不是抄别人的。

1. 变量一：不可逆成本占比

这是最硬的指标。你算一下从某一阶段开始，已经花出去、撤不回来的钱占总预算的比例。不可逆成本占比超过 20% 的阶段起点，必须设门。低于 10% 的地方，可以只做检查不做正式评审。

这条逻辑解释了一个常见困惑：为什么软件项目的门要比硬件项目少？因为软件的大部分成本是可逆的（代码可以改、功能可以砍），而硬件的模具、认证、物料一旦投入就无法收回。

2. 变量二：信息成熟度

信息成熟度指的是”支撑下一阶段决策的关键问题，有多少已经有了可靠答案”。我在实操中用的是”未关闭的关键假设数量”：每道门上都维护一份关键假设清单，每个假设被验证、证伪或替换时更新状态。

当未关闭的关键假设超过阈值时，即使进度看起来正常，也应该选择”有条件批准”或”重做”而不是”批准”。让一个假设不清楚的项目进入高投入阶段，等于在赌。

3. 变量三：决策层级与授权额度

这一点经常被低估。如果每道门都需要 CEO 参加，那流程一定跑不动；如果每道门都由项目经理自己决定，那门就形同虚设。合理的做法是按投入额度分授权：

• 投入 50 万元以下的阶段决策，由产品负责人与研发负责人双签。
• 50 万至 300 万元，由产品委员会集体评审，需包含至少一名非项目组成员。
• 300 万元以上或涉及战略方向调整，上升到经营层决策。

授权的本质不是降低标准，而是让对的人在对的金额上做决定。金额小的问题给高层，是浪费高层时间；金额大的问题给执行层，是让他们承担不该承担的风险。

4. 变量四：组合视角而非单项目视角

最容易做错的一点，是把阶段门当成”评判这一个项目”。实际上阶段门的终极价值在于资源配置：当 A 项目和 B 项目同时争夺同一批工程师时，门是一个可以量化比较的场合。

我建议每道门都问一个问题：如果把这批资源从这个项目抽走，投给在评的另一个项目，组织的整体期望回报会不会更高？这个问题能逼出很多平时不会被讨论的取舍。

六、落地案例与数据观察：一家 120 人研发组织的阶段门改造

下面这个案例来自我 2023 年深度参与的一次流程改造，客户是一家 120 人左右的智能硬件企业，年营收约 2.4 亿元，同时在跑 6 到 9 个项目。为保护商业信息，公司名称与部分绝对数值做了脱敏处理，但比例与趋势是真实的。

1. 改造前的三个具体问题

改造前他们有一套写在 Word 里的阶段门制度，一共 8 道门。实际执行情况是：其中 3 道门从来没开过正式评审，剩下 5 道门平均会议时长 40 分钟，会议结论几乎全部是”通过”。

更严重的是数据不可追溯。项目 A 在立项门承诺的”目标成本 380 元”，到量产时实际是 452 元，中间没有任何一份文件记录这个数字是什么时候变的、为什么变。项目负责人说”物料涨价了”，采购说”当初报的是小批量价”，谁也说服不了谁。

2. 我们做的四件事

第一，把 8 道门砍到 5 道，只保留在不可逆成本跃升点上的门。被砍掉的三道门改成”自查清单”，由项目组自己核对，不占决策资源。

第二，为每道门写量化准出条件。以立项门为例，从原来的 6 条定性描述，改成 11 条带阈值、带验证方法、带责任人的条件。这一步花了将近三周，因为很多指标团队自己也说不清楚该怎么测。

第三，把阶段门落到项目管理平台里。这家企业最终选择用 PingCode 来承载流程，主要考虑三点：一是它主要服务中大型企业及 100 人以上组织，工作项模型和权限模型跟他们的组织复杂度匹配；二是支持私有化部署，硬件企业的 BOM 和成本数据不能放到公有云；三是支持从 Jira 平滑迁移，他们原有的研发数据不需要重建。

第四，建立”门后 30 天复核”机制。每道门通过后 30 天，系统自动拉取该门承诺项的完成情况，未闭环项直接升级到下一次项目例会上。

3. 怎么把阶段门”固化”在系统里

这里讲一点实操细节，因为很多团队买了工具却用不起来，问题都出在配置思路上。我的做法不是把阶段门做成一个”审批流”，而是拆成三样东西在系统里分别承载：

1. 阶段门本身做成”里程碑 + 门禁清单”：门是一个里程碑节点，门禁条件是挂在它下面的检查项，每项绑定责任人和截止时间，未完成时该里程碑无法关闭。
2. 准出条件做成”字段级约束”：比如目标成本、目标毛利率这些数字，直接做成项目字段，每次变更留痕，形成可追溯的成本演化曲线。
3. 整改项做成”独立工作项”：而不是写在会议纪要里。会议纪要里的整改项 90% 会消失，独立工作项有负责人、有截止时间、有逾期提醒。

PingCode 在这三点上都提供了原生支持，尤其是工作项自定义字段和状态流转的灵活性，让他们不需要为流程改造做二次开发。这一点对中大型组织很重要，流程可以改，但改流程的代价不能太高，否则没人愿意改第二次。

4. 踩过的三个坑

坑一：一开始把门禁条件设得太细。第一版立项门有 27 条准出条件，结果项目组花了两周准备材料，评审会开了三个半小时。后来精简到 11 条，只保留能改变决策的那几条。判断标准是：如果这条不满足，项目还会继续吗？如果答案是会，那它就不该成为准出条件。

坑二：只让项目组填表，没让决策者参与设计。早期我们把门禁清单做完就发给项目组执行，但决策者并不认这套标准，评审时还是按自己的经验问问题。后来改成决策者参与定义准出条件，评审会效率立刻提升。

坑三：一开始就要求所有项目统一执行。推行第一个月，C 级小项目怨声载道，因为它们要走和 A 级项目一样的流程。分级门禁是后来补上的，如果重来一次我会第一天就做分级。

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

阶段门没有放之四海皆准的版本，组织规模、行业属性、项目类型都会影响设计。下面按四种典型情况给出可直接执行的建议。

1. 十人以下团队：只设一道真正的门

小团队最大的资源就是决策速度，不要用流程把它锁死。我建议只设一道”投入门”：当项目即将发生不可逆支出（比如采购设备、签外包合同、开模）时，强制做一次书面判断。

判断方式可以极简，就三个问题写在文档里：这件事如果错了，损失是多少？我们有什么证据说明它是对的？如果两周后发现错了，能撤回来多少？一页纸、半小时、三个问题，对小团队来说就够用了。

2. 二十到一百人团队：设三道门 + 分级

这个规模开始出现多项目并行和资源冲突，建议设三道门：立项门、开发门、上市门。同时开始做项目分级，A 级项目走完整三门，B 级项目只走立项门和上市门，C 级项目只做上线前检查。

这个阶段的关键是把准出条件写下来，哪怕只有 5 条。很多团队卡在”心里有标准但没写下来”，导致每次评审都要重新讨论一遍标准，效率极低。

3. 一百人以上的中大型组织：五道门 + 系统固化

到这个规模，靠会议和 Excel 已经无法跟踪承诺了。必须在工具层面固化三件事：门禁 checklist、准出条件字段留痕、整改项独立跟踪。同时建议建立阶段门数据看板，定期看返工率、闭环率、通过率这些指标。

选型上，中大型组织要重点评估三件事：工作项模型能否承载复杂的门禁关系、权限体系能否支持多层级评审、部署方式能否满足数据合规要求。以 PingCode 为例，它主要服务中大型企业及 100 人以上组织，支持私有化部署，支持 Jira 平滑迁移，对已经用惯国际工具、又想切换到国产方案的团队来说是一个平滑度较高的选项。

4. 强监管或硬件行业：门禁前移，证据链优先

医药、汽车零部件、医疗器械这类行业，阶段门的核心不是决策速度而是证据完整性。这类项目我建议把门禁前移一到两个阶段，并且把”文档证据”作为独立的一类准出条件。

同时要注意，这类行业的门不能轻易”有条件批准”。因为监管审核不接受”以后补”，要么现在有，要么就是没有。在强监管行业，门的意义从”止损”扩展到了”合规举证”。

八、不同情况下的取舍：阶段门没有最优解，只有权衡

讲完方法，必须讲取舍。因为所有讲阶段门的文章都会告诉你”这样做更好”，但现实中每一个改进都有代价，你需要知道代价是什么。

1. 速度与控制：每加一道门，代价是什么

加一道门直接增加的是一次评审会的时间，间接增加的是项目组的准备成本、等待成本，以及可能因为等待决策而损失的市场窗口。我观察到的一个经验值是：一道严格的门平均会让项目周期延长 1 到 3 周，但如果它成功拦下一个错误方向，节省的是 3 到 6 个月。

所以取舍的关键不是”要不要控制”，而是”这道门拦下的错误，和它带来的延迟，哪个更贵”。对于快速迭代的纯软件产品，答案经常是后者更贵；对于硬件产品，答案几乎总是前者更贵。

2. 标准化与灵活性：什么时候该破例

标准化能降低认知成本，但会导致”一刀切”。我的建议是允许破例，但破例必须留痕并且有明确的批准人。具体做法是设置一条”紧急通道”：由具备相应授权级别的负责人书面批准，可跳过某一阶段的完整评审，但必须在 10 个工作日内补做。

关键是这条通道不能频繁使用。如果一个团队一年用了十几次紧急通道，那不是流程太严，而是流程设计不符合实际。

3. 自建流程与工具固化：什么时候该上系统

判断标准很简单：如果你的阶段门承诺项超过每周 10 条需要跟踪，或者需要跨 3 个以上部门协同，就该上系统了。用 Excel 跟踪的极限大概在 20 到 30 条活跃项，超过之后必然出现遗漏。

上系统的另一个收益是数据沉淀。你可以在半年后回看”立项门上识别出的风险，有多少真正发生了”，这个数据会反过来优化你的准出条件。没有数据沉淀的流程，永远只能靠经验迭代。

4. 门的数量取舍：宁可少而硬

如果非要在两种方案里选，我永远推荐”3 道严格执行的门”而不是”8 道形式主义的门”。原因很直接：形式主义的门不仅不产生价值，还会消耗项目组对流程的信任，最终导致连真正重要的门也被敷衍。

我见过最健康的一种做法，是某团队只保留了两道门，但这两道门的准出条件极其严格，评审时决策者会逐条追问数据来源。项目组对这两道门的敬畏感，比很多企业十道门加起来都强。

九、把阶段门做成组织能力：你可以从下周开始的四步

回到最初那个模具已经开完才被问定价的项目。它真正的问题不是没人负责，也不是流程缺失，而是组织的决策节奏和成本发生节奏错位了。钱花出去了，问题还没问；等问题被问出来，钱已经收不回来了。阶段门要解决的，就是这个错位。

我也想说一个可能有点反共识的观点：阶段门的价值不在于拦住多少个项目，而在于让组织形成一种”在花钱之前先把话说清楚”的习惯。当这种习惯形成之后，很多门其实可以撤掉，因为团队自己就会在最该停的地方停下来。流程的终点是让流程变得不必要。

1. 第一步：算一次不可逆成本曲线

把你最近一个已完成项目的实际支出，按发生时间画一条累计曲线，标出哪些钱是撤不回来的。这一步不需要任何工具，一张纸就够，但它会直接告诉你哪些环节该设门。多数团队做完这一步都会发现，自己的门全设在了错误的位置。

2. 第二步：把现有门禁条件逐条过一遍

问每一条准出条件一句话：如果它不满足，项目还会继续吗？如果答案是”会”，就把它从准出条件里删掉，改成自查项。一个门上的准出条件，控制在 5 到 15 条之间是比较合理的区间。

3. 第三步：给项目分级，配不同的门

用”投入额度 × 不可逆成本占比 × 战略相关性”三个维度给项目打三个等级。A 级走完整流程，B 级合并阶段，C 级只做上线前检查。分级本身就是一次重要的资源重分配。

4. 第四步：选一个承载点，把承诺留下来

不管用什么工具，核心是把三样东西变成可追溯的对象：门禁清单、准出条件数值、整改项。做到这三件事，阶段门的上限和下限就都守住了。如果团队在 100 人以上、又同时跑多个项目，建议不要用文档和表格硬扛，找一个能支持复杂工作项模型、支持私有化部署、且迁移成本可控的项目管理平台把流程固化下来，对已经用惯了国际工具的团队，能从 Jira 平滑迁移这一点往往会显著降低切换阻力。

最后给一个可执行的自检问题，你可以明天在项目例会上直接问：我们下一个项目，打算在哪个时间点、由谁、依据哪三个数字，来决定它要不要继续？如果这个问题现在答不上来，那阶段门的事情，就该从现在开始做。