阶段门怎么做？实施团队制度设计：项目阶段从0到1

去年我帮一家做工业 SaaS 的公司做研发流程复盘，翻完他们 18 个月的项目档案之后发现一个很扎眼的事实：12 个正式立项的项目里，有 9 个走完了全部五个阶段门，但真正上线并产生营收的只有 2 个。更尴尬的是，那 9 个”全部通过”的项目中，有 6 个在第四阶段之前，团队内部已经普遍不看好，只是没有任何一个人在任何一次评审会上说”我们应该停”。

这不是评审不认真，恰恰相反，他们的阶段门会议开得非常规范：有 PPT、有签到表、有会议纪要、有评审结论签字。问题出在制度本身，他们的阶段门设计成了一个”汇报仪式”，而不是一个”决策关口”。这篇文章我想把这套东西拆开讲清楚：阶段门到底该怎么设计，实施团队的角色和权限该怎么切，从 0 到 1 落地时哪些坑一定会踩。

一、先给结论：阶段门是信息过滤器，不是权力关卡

我见过太多团队把阶段门理解成”领导审批节点”，于是所有的设计精力都花在”谁有签字权””要走几级审批””表单要填多少字段”上。这是方向性的错误。

阶段门真正的职能只有一件事：在信息还不足以支撑继续投入之前，把一个项目挡在门外。它的价值不在于”通过时盖章”，而在于”不通过时能干净利落地停下来”。一个从不否决项目的阶段门，等于没有阶段门。

1. 阶段门要解决的是沉没成本失控，而不是流程合规

项目为什么会烂尾？通常不是因为团队能力不行，而是因为”已经投了这么多，现在停太可惜了”。这是典型的行为经济学里的沉没成本谬误。阶段门存在的意义，就是在组织层面人为制造一个强制复盘点，让决策者必须在指定时间、指定信息条件下重新回答一次”如果今天从零开始，我还会投这个项目吗”。

如果一个阶段门的设计无法回答这个问题，那它就只是流程合规的装饰品。

2. 阶段门的作用对象是”资源”，不是”进度”

我判断一个阶段门设计得好不好，通常看一件事：这个门如果没有通过，团队会发生什么？如果答案是”没什么变化，继续做，只是下次再报一次”，那这个门是废的。真正有效的门，不通过就意味着人力被抽走、预算被冻结、团队被拆散重组。

也就是说，阶段门管的不是”项目现在到哪一步了”，而是”下一阶段的资源还给不给”。

二、真实场景：一个 120 人团队的五道门是怎么垮掉的

回到开头那家工业 SaaS 公司。他们的阶段门是这样设计的：立项门、需求门、设计门、开发完成门、发布门，一共五道，每道门由 CTO 主持，产品、研发、测试、市场各出一名代表评审。

听起来很完整。但执行三个月之后，五道门全部退化成了五种”固定会议”。

1. 立项门变成了”资源争夺会”

因为公司当年的立项名额和 HC 挂钩，产品线负责人为了抢人，会把立项材料写得极度乐观。评审人看到的是”预计 6 个月上线、首年营收 800 万”的 PPT，而不是”这个需求我们验证过多少真实客户、付费意愿如何”。立项门实际上变成了一个文案比赛。

第一道门就已经被污染了，后面四道门全部建立在错误的前提上。

2. 需求门和设计门变成了”文档检查”

这两道门的评审标准是”PRD 是否完整””技术方案是否覆盖异常分支”，于是团队把精力放在把文档写全，而不是把问题想清楚。我翻过他们其中一份需求文档，67 页，写了 23 个功能点，但没有一页在讲”如果只做其中 3 个功能点，能不能先验证核心假设”。

3. 开发完成门最致命：它用”代码写完”当通过标准

这是绝大多数实施团队的通病。开发完成门的通过条件被设为”功能开发完毕、测试通过、无 P0 缺陷”，于是这个门必然通过，因为只要时间给够，代码总能写完。它从来不问”写出来的东西和当初立项要验证的假设，是不是同一件事”。

4. 发布门变成了”上线动员会”

到了发布门，所有人力已经投入了，市场物料已经做了，销售已经跟客户吹过风了。这时候没有人敢说不通过，因为不通过意味着前面全部白干。阶段门越靠后，否决的政治成本越高，这是制度设计必须提前对抗的。

三、常见误区：我见过的最容易踩的六个坑

1. 所有项目用同一套门

很多团队给所有项目配同样的五个阶段门、同样的评审人、同样的文档要求。结果是一个两周就能验证的小工具，也要走完五道门，前后花掉六周；而一个涉及核心系统重构、影响 200 人协作的大项目，用的还是同一套轻量标准。

阶段门的密度必须和项目的风险等级、投入规模挂钩。这是设计阶段门的第一原则，但被违反的频率最高。

2. 评审人里没有”能拍板砍项目”的人

我经常看到评审委员会由产品经理、技术负责人、测试负责人组成。他们能评价”做得好不好”，但不能决定”要不要继续投钱”。这种评审会开完，结论永远是”建议优化后继续推进”。

能砍项目的人不在场，阶段门就不可能砍项目。

3. 通过标准是主观描述，不是可证伪条件

“技术方案合理””市场需求明确””团队准备充分”，这些标准听起来都对，但没有一条可以被判定为”不满足”。正确的写法是”Idea 阶段至少完成 8 家目标客户的付费意愿访谈，其中至少 3 家愿意签意向协议”。

4. 没有”终止动作清单”

项目被否决之后要做什么？人员怎么释放、代码怎么归档、已投入的采购怎么处理、客户怎么通知？如果这些没有预先定义，那么”否决”这个决定在落地时会被各种现实问题拖住，最后变成”先暂停看看”。

“暂停”是阶段门最大的敌人，因为它把一次干净的决策变成了一次无限期的模糊状态。

5. 把阶段门和敏捷迭代对立起来

不少敏捷团队认为阶段门是瀑布时代的遗物。我的看法相反：阶段门管的是”要不要继续投”，迭代管的是”怎么做得更好”。一个季度一次阶段门，两周一次迭代，两者不冲突。

6. 门的输入数据来自 PPT，而不是工作系统

这是最隐蔽也最致命的坑。当评审材料由项目组自己整理时，它天然带有筛选和美化倾向。我见过一个项目的进度汇报里，测试通过率是 92%，但真实的工作系统里有一组 300 多条未关闭缺陷被标记为”暂不处理”。

四、专业判断逻辑：阶段门该怎么设计

下面这套逻辑是我在多轮改造中沉淀下来的，不追求理论完整，只追求能落地。

1. 先按风险分级，再决定门的数量和重量

我建议把项目分成三档，用三套不同的门：

注意最后一列：投入上限不是”总共能花多少”，而是”这个门通过之前最多能花多少”。这是资源分批释放的核心机制。

2. 每道门必须写清三样东西：输入、判据、终止动作

我用一个结构化配置来表达阶段门的定义。下面是一个标准级项目”验证门”的示例配置：

gate:
name: 验证门

owner: 产品线负责人

reviewers:

产品线负责人 # 有权调整该产品线人力

技术负责人

财务 BP # 涉及预算变更时必须到场

inputs:

目标客户访谈记录（>= 8 家，需含具体访谈纪要）

意向协议或试用转化数据

技术可行性验证报告（含 POC 结论）

预估投入产出模型（含最坏情况）

criteria:

至少 3 家客户签署意向协议或完成付费试用

POC 关键技术指标达标（延迟 = 90%）

最坏情况下首年亏损不超过预算的 40%

outcomes:

pass:

释放下一阶段人力（上限 120 人天）

conditional:

释放 50% 人力，需在 4 周内补齐缺失数据后复审

fail:

冻结预算

人力在 5 个工作日内回归原团队

项目组提交 1 页归档说明，进入知识库

相关客户由销售负责人 3 个工作日内沟通

这份配置里最关键的是 outcomes.fail 下面的四行。没有这四行的阶段门，等于只有一半。

3. 评审数据必须可溯源到工作系统

我的硬性要求是：阶段门材料中至少 60% 的量化指标，必须能直接从工作系统导出，而不是由人工填写。包括需求验收情况、缺陷分布、迭代完成率、测试覆盖、代码提交活跃度等。

这不是为了不信任团队，而是为了减少”整理材料”这个环节带来的信息失真和巨大管理开销。

4. 决策人必须有权动资源

判断一个评审人是否合格，只问一句：他说”这个项目停”，需要请示别人吗？如果需要，他不该在这个评审席上。

5. 每道门都必须保留”否决且不解释流程”的能力

这话听起来有点强硬。我的意思是，阶段门要允许决策者基于经验直觉投反对票，而不必等到数据完全证明项目不行。等到数据证明的时候，通常已经晚了半年。

五、案例与数据：一家 180 人研发团队的 12 个月改造记录

下面这个案例是我参与最深的一次，稍微展开讲，因为里面的数字和细节更有参考价值。

1. 改造前的状态

这家公司大约 180 人，研发约 110 人，做企业级数据产品。改造前他们用的是”评审 + 汇报”模式，五道门，每道门都是会议室里看 PPT。2022 年他们在跑的项目有 14 个，其中 3 个已经超期 6 个月以上。

最典型的问题：项目经理每周要花 1.5 天做汇报材料，一个阶段门的材料准备平均耗时 4.5 人天。

2. 引入工作系统作为门控数据源

他们做了一个决定：把项目全生命周期的数据都收敛到一套研发管理平台上，阶段门的数据直接从那里面取。他们选的是 PingCode，主要考虑三点：

• 私有化部署：他们的客户里有相当比例的国企和金融机构，代码和需求数据不能出内网，这一点是硬门槛。
• 支持从 Jira 平滑迁移：他们原本有一套自建的 Jira 体系，历史数据资产不想丢，迁移工具和字段映射做得比较完整。
• 国产替代选型时的合规顾虑较小：对于他们这类需要参与信创项目的公司，这一步省了很多解释成本。

我不是说这个平台适合所有团队。180 人、多条产品线、有合规要求，这个画像下它比较合适；如果是 20 人的小团队，用这一套反而是负担。

3. 阶段门数据自动化的具体做法

他们把”验证门”的输入项直接从系统里拉出来：

• 需求验收情况：目标需求在对应迭代中的完成率和验收通过率
• 缺陷分布：按严重程度和模块分布的中未关闭缺陷数
• 迭代稳定性：最近 6 个迭代的燃尽偏差
• 测试覆盖：核心模块的用例覆盖与自动化覆盖
• 变更频率：需求在最近一个阶段内的变更次数

这些指标不再是”项目经理回忆后填写”，而是评审前系统自动生成的阶段报告。材料整理时间从平均 4.5 人天压到 0.5 人天。

4. 12 个月后的结果

改造后一年，他们跑过的项目是 9 个（立项数下降，但立项质量提升）。其中：

• 2 个在验证门被终止，人力平均 5 个工作日内完成回收
• 1 个在设计门被终止，节省预算约 210 万元
• 5 个走到发布门并上线，其中 4 个当年产生营收
• 1 个走到发布门但选择不发布商业化，转为内部工具

立项数减少 36%，但产生营收的项目从 2 个增加到 4 个。这个对比很有意思，好的阶段门不会让团队做更多项目，反而会让团队做得更少但更准。

5. 一个我想特别强调的细节

改造半年后，他们做了一次反向复盘：把两个被终止的项目拿出来，让原项目组重新评估”如果当时继续做，会怎样”。结果项目组成员自己给出的判断是：其中 1 个确实该停，另外 1 个如果能在终止前先做一轮客户访谈，可能会发现需求其实是成立的。

这个反思很有价值。它说明阶段门的”终止”不一定是最终结论，有时候因为输入信息不足而误杀。所以我在设计里加了一条：被终止的项目允许在被终止 6 个月内，以更低资源上限重新立项（例如原来是标准级项目，可以按轻量级重新提）。这把”终止”从”判死刑”变成了”退回重审”，团队对阶段门的心理抵触明显下降。

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

阶段门没有万能模板，我按三种常见组织形态给建议。

1. 50~100 人的成长型团队：先做两道门

这个阶段团队最大的问题是”什么都想做”。建议只设两道门：立项门 + 发布门。立项门重点砍掉”没验证需求的”，发布门重点确认”上线条件是否具备”。

中间不要设门，让团队自己跑。这个阶段效率比控制重要。

2. 100~300 人的多产品线团队：三到四道门，必须分级

这个规模是阶段门价值最大的区间。建议：

1. 按风险分级，三档项目用三套门
2. 每道门必须有资源所有权人在场
3. 所有评审输入绑定到统一的工作系统
4. 设置”季度资源复盘”，把终止项目的资源重新分配

这套体系下，我观察到的典型收益是：无效投入占比从 30% 以上降到 15% 以下，评审材料准备工时下降 70% 左右。

3. 300 人以上或强合规行业：阶段门要和项目治理体系合并

这个规模下，阶段门不能孤立存在，必须和预算管理、人力盘点、合规审计打通。建议：

• 阶段门的资源释放节奏直接对应财务预算科目
• 门控数据同时作为内审的输入
• 私有化部署的工作系统，保证数据不出内网，避免合规风险

特别强调最后一条。我见过一家公司因为合规要求，把项目评审数据放在外部 SaaS 上，结果被内审要求全部迁回内网，前后折腾了四个月。选型时的部署方式，在阶段门这种场景下就是硬约束，不是加分项。

七、不同情况下的取舍

1. 严格 vs 灵活：优先保”资源不被误用”

很多团队纠结于”阶段门太严会不会压制创新”。我的经验是，把”严”放在资源释放上，把”松”放在探索方式上。

具体说：你可以允许团队用任何方式探索（用户访谈、原型、A/B 测试、竞品拆解），但不能允许在不明确的证据下持续占用人力。前者是创新，后者是资源黑洞。

2. 人工判断 vs 系统数据：系统做体检，人做决策

我见过两个极端。一个是完全依赖系统数据自动判定通过与否，结果出现了”指标好看但方向错了”的项目照样过关；另一个是完全依赖专家判断，结果出现了”专家看好的项目反复烧钱”。

我的取舍是：系统负责生成事实，人负责解释事实并承担后果。系统给出”目标客户访谈 3 家、POC 达标、缺陷密度 1.2/千行”这样的客观描述；人判断”3 家访谈够不够支撑继续投入”这样的价值判断。

3. 增加门的数量 vs 减少门的数量：少比多好

门越多，每次评审的信息量越少，评审质量越低。我见过有团队设了七道门，结果每道门平均 20 分钟就过，因为没人有精力认真看。

我建议的标准是：每道门对应一次”资源释放决策”，不对应”项目进度节点”。按这个标准，大部分团队的门数会减到 2~4 道。

4. 私有化部署 vs 云服务：按合规红线决定

这不是技术偏好问题，是合规边界问题。如果你的客户里有金融机构、政府、军工、大型国企，那么评审数据能否出内网就是红线。这类团队选工作系统时，私有化部署应该作为第一筛选条件，而不是”如果支持就更好”。

反过来，如果团队完全是互联网业务、没有这类客户约束，云服务的迭代速度和运维成本优势明显，没必要为了”看起来更安全”上私有化。

八、给一个可以直接抄走的落地清单

如果你打算从下周开始动手改阶段门，按这个顺序推进，两周可以跑出第一版。

1. 第一周：定义和分级

1. 列出当前所有在跑的项目，按投入人天分成三档
2. 为每一档定义门的数量、评审人、投入上限
3. 为每道门写出”输入、判据、终止动作”三件套
4. 找两个即将到门的项目做试点

2. 第二周：数据源和工具准备

1. 确定哪些指标从工作系统自动导出，哪些需要人工补充
2. 把补充类指标压缩到不超过总量的 40%
3. 为”终止动作”设计一份一页纸的模板，包含人员释放、预算冻结、客户沟通、知识归档
4. 在试点项目上跑一遍完整流程，收集评审人反馈

3. 一个月内：小范围推广

1. 把试点中暴露的问题（尤其是”数据不好取””评审人不在场”）解决掉
2. 把解决后的流程固化到工作系统中，作为默认模板
3. 建立季度资源复盘机制，把终止项目的资源重新分配

4. 三个月内：形成组织习惯

阶段门真正起作用的标志，不是流程跑通了，而是团队开始主动在立项前问”这个能不能通过验证门”。当团队开始用”门的标准”来反向约束自己的立项材料时，这套制度才算活着。

如果三个月后你发现团队还是在”想办法让项目过门”，说明你的门设计得还不够”重”，重到让团队意识到，与其花心思过门，不如花心思把项目做扎实。

九、一个我反复验证过的观点

阶段门从 0 到 1 的难点，从来不是流程设计，而是组织对”主动终止项目”这件事的心理接纳程度。

我见过流程设计得最完整的团队，阶段门执行得最差；也见过流程简单到只有一页纸的团队，阶段门执行得非常好。差别就在一点：他们的管理层是否公开表扬过”及时终止项目”的团队。

如果你想让阶段门真正运转起来，我的建议是：第一次成功终止一个项目时，一定要在全员会上讲清楚，并明确肯定项目组的复盘质量。这一件事的效果，胜过十份流程文档。

因为阶段门要对抗的，不是流程混乱，而是人性里”不甘心”这三个字。