阶段任务怎么做？项目经理制度设计：项目阶段从0到1

我见过一次最离谱的项目复盘：某家 300 人的软硬件混合企业，一个原计划 6 个月交付的项目拖了 11 个月，复盘会上研发、产品、测试、交付四个部门吵了整整两小时，最后卡在一个问题上，没有人能说清楚这个项目”现在到底处于哪个阶段”。产品经理说已经进入开发阶段，研发负责人说需求还没冻结只能算设计阶段，测试说他们已经在写用例了算测试阶段，交付说客户那边设备都进场了肯定算实施阶段。

四个答案都”有道理”，但正是这四个”有道理”，让阶段任务没人认领、阶段准出没人签字、风险层层后移，最后全部堆到上线前两周集中爆炸。

这篇文章不是讲项目管理教科书里的阶段模型，而是讲一件事：当你真的要从 0 到 1 设计一套”阶段任务 + 项目经理制度”，你到底该按什么顺序做决策。下面所有内容来自我在三家公司推进阶段制度改造的实际过程，包括两次数得清的失败，以及最后跑通的那套配置逻辑。

一、先给结论：阶段任务是”风险切割 + 决策授权”，不是”时间切段”

如果只让我留一句话，那就是：阶段划分的依据不应该是”时间过去了多久”，而应该是”不确定性下降到了哪个台阶”。绝大多数做砸的阶段制度，根子都在这里，它们按日历切，而不是按风险切。

1. 阶段划分的真正依据是”不确定性骤降的那个点”

一个项目从 0 到 1 的全过程里，真正让不确定性骤降的事件其实只有那么几个：需求范围被确认、技术方案被验证可行、核心接口联调通过、业务方验收通过、生产环境稳定运行一个周期。这些事件每发生一次，项目就从”可能做不成”变成”更可能做成”一步。

所以阶段应该切在这些事件的两侧，而不是切在”第一个月底””第二个季度末”。我做过一次对比：同一个 120 人的研发组织，按时间切阶段时，阶段准出标准里 70% 是”完成了 X% 的功能”，按事件切阶段后，准出标准里 85% 变成了”某项验证通过 / 某份评审签署”。后者的阶段延期率比前者低了将近 40%，原因很简单，“完成 80%”这种表述永远可以被解释，而”接口联调通过”没法解释。

2. 阶段任务必须分成三种类型，混在一起必乱

很多人把”阶段任务”当成一个整体概念，这是第二个大坑。实际上阶段任务天然分三类，管理方式完全不同：

• 交付型任务：产出可被验收的实物或文档，比如需求规格、架构设计、测试报告、上线方案。这类任务的判断标准是”存在且合格”。
• 决策型任务：产出的是一个决定，比如”是否继续投入””是否变更范围””是否放行上线”。这类任务的判断标准是”有人签字且签字人有权”。
• 协调型任务：本身不产出交付物，但保证上下游能对上，比如跨部门对齐会、环境准备、数据迁移协调。这类任务的判断标准是”依赖方确认已就绪”。

这三类任务如果混在一张任务清单里，就会出现一种典型症状：清单上 90% 的任务都打勾了，阶段却过不去。因为打勾的都是协调型和交付型，唯独那几个决策型任务没人敢拍板。我在第二家公司推进时，第一个版本就是混着做的，结果连续两个阶段都卡在”看起来都完成了但没人签字”的状态上。

3. 项目经理制度设计决定了阶段制度能不能活下来

阶段制度是”骨架”，项目经理制度是”血液循环”。我见过不少团队阶段划分做得很漂亮，但因为项目经理没有对应的权力，阶段门形同虚设。

具体表现是：项目经理能组织会议，但不能否决阶段准出；能记录风险，但不能调动资源关闭风险；能催进度，但不能决定优先级调整。这种情况下，阶段门就变成了”建议门”，大家礼貌性地遵守一下，赶工期的时候第一个被跳过。

我的判断是：阶段制度设计必须和项目经理的授权清单同时定稿，否则就先别定阶段。授权清单至少要明确三件事，谁有权宣布阶段开始、谁有权宣布阶段准出、谁有权在准出未达成时强行推进（以及强行推进需要谁背书）。

4. 一个可以立刻自检的判断标准

如果你想快速判断自己团队的阶段制度是不是形式主义，用下面这个标准测一下就行：

1. 随便找一个正在进行的项目，让三个不同角色的人各自说出当前阶段名称，看是否一致。
2. 让他们各自说出”这个阶段准出的条件是什么”，看是否能说出可验证的标准，而不是”差不多了”。
3. 翻一下上一个已结项项目，看看是否有任何一次因为阶段准出未通过而延迟了阶段推进。

第 3 条是最狠的。如果一个团队的项目从来没因为”阶段准出不通过”而停下过，那基本可以确定这套阶段制度只是装饰。一个从不拦人的门，不是门，是墙上的画。

二、真实场景：一套阶段制度从 0 到 1，我踩过的三个坑

下面这段是我在某家 180 人规模的 To B 软件公司（研发约 110 人，同时并行 7，9 个项目）推进阶段制度改造的真实过程。整个过程跨了约 5 个月，迭代了三个版本，我把数据和教训都留下来。

1. 起点：所有人都在忙，但没人知道”现在到哪了”

改造前的状态很有代表性：项目用工具管理，但工具里只有一张巨大的需求列表和一张巨大的缺陷列表，没有任何阶段字段。周会上项目经理汇报进度，用的语言是”这个项目大概完成了 60%”。老板问”什么时候能上线”，回答是”再过一个月应该差不多”。

我们内部统计过一次：7 个并行项目中，有 5 个在连续三周的周报里都写着”进度约 60%，70%”。这不是团队不努力，而是因为”进度百分比”是一个可以无限复用的模糊指标，没有任何阶段门约束它。

2. 第一次尝试：照抄瀑布阶段，三周后崩盘

第一版我们直接参照瀑布模型，设了六个阶段：需求、设计、开发、测试、验收、运维。每个阶段都有准出文档清单，一共 23 份文档模板。

结果三周后就崩了。崩的原因不是团队抵触，而是文档清单和实际工作流对不上。比如”概要设计说明书”这个交付物，在我们的实际开发模式里根本不存在独立环节，架构决策是在需求评审会上当场定的，会议纪要就是事实上的设计文档。但制度要求独立文档，于是团队开始补文档，补出来的文档没人看，纯粹为了过门。

三个月后统计，这 23 份文档里真正被下游角色阅读过的只有 6 份，占 26%。剩下的 17 份，是纯粹的过门成本。

3. 第二次迭代：从”时间切段”改成”决策点切段”

第二版我们换了个思路，先不定义阶段，而是先把”这个项目里必须做的决策”列出来。花了两个下午，和产品、研发、测试、交付四个角色一起，列出了一个项目从 0 到 1 需要做的重要决策，最后收敛到 9 个：

1. 这个需求值不值得做（商业价值决策）
2. 范围边界定在哪里（范围决策）
3. 技术路线选哪条（架构决策）
4. 能否进入开发（资源与方案就绪决策）
5. 范围是否冻结（变更控制决策）
6. 能否进入系统测试（质量门槛决策）
7. 能否发布到生产（放行决策）
8. 能否交付给客户（验收决策）
9. 能否关停项目并回收资源（退出决策）

然后我们把这些决策归组，发现自然形成了 4 个阶段：立项、方案、交付、收尾。注意，这里阶段是决策的”副产品”，而不是先有阶段再往里塞决策。这个顺序上的调换，是整个改造里最关键的一步。

阶段数从 6 降到 4，文档模板从 23 份降到 11 份，但决策点的覆盖反而更完整了。因为原来那 6 个阶段里，”需求”和”设计”其实共享同一批决策人，”验收”和”运维”也是同一批，拆开只是增加了过门次数。

4. 第三次迭代：把阶段门写进工具，而不是写进 PPT

第二版的阶段制度在纸面上是合理的，但落地时仍然靠人盯。我们用一个共享表格记录阶段准出状态，三周后就开始出现”表格没更新但阶段已经推进了”的情况。

第三版的核心改动是把阶段门变成工具里的强制状态流转。这里我们用的是 PingCode。选它的原因很直接：我们当时已经决定做国产替代，团队原来用的是 Jira，历史数据积累了不少，迁移成本是首要考虑；同时公司有私有化部署的合规要求，数据不能出内网。

实际配置下来，能落到 PingCode 上的阶段制度元素主要有四类：

• 工作项类型分层：把”需求””任务””缺陷””阶段准出检查项”分成不同工作项类型，避免阶段任务和普通任务混在一张列表里。
• 状态流与阶段绑定：阶段推进不是靠改一个字段，而是通过状态流流转，流转条件里挂上准出检查项。
• 检查项作为准出的硬约束：某个阶段的所有检查项未关闭时，状态流转按钮不可用。
• 看板按阶段聚合：周会不再看百分比，而是看每个阶段有多少工作项处于”准出受阻”状态。

下面是我们当时用的一份阶段门配置草案（简化版，实际配置比这个更细）：

stage_gate:

stage: 立项

enter_condition: 需求来源已登记

exit_items:

商业价值评估结论已签署（决策型 / 责任人：产品负责人）

范围边界说明已评审（交付型 / 责任人：产品经理）

初步资源测算已完成（协调型 / 责任人：项目经理）

force_pass_requires: [业务线负责人, 研发负责人]

stage: 方案

enter_condition: 立项阶段准出通过

exit_items:

技术选型结论已记录（决策型 / 责任人：架构负责人）

关键接口定义已完成（交付型 / 责任人：技术负责人）

测试策略已对齐（协调型 / 责任人：测试负责人）

force_pass_requires: [研发负责人]

stage: 交付

enter_condition: 方案阶段准出通过

exit_items:

范围冻结确认（决策型 / 责任人：产品负责人）

系统测试报告已通过（交付型 / 责任人：测试负责人）

上线方案与回滚方案已就绪（交付型 / 责任人：运维负责人）

发布放行决策已签署（决策型 / 责任人：项目经理 + 研发负责人）

force_pass_requires: [研发负责人, 业务线负责人]

stage: 收尾

enter_condition: 交付阶段准出通过

exit_items:

客户验收确认（决策型 / 责任人：交付负责人）

生产环境稳定运行一个观察周期（交付型 / 责任人：运维负责人）

资源回收与项目归档（协调型 / 责任人：项目经理）

force_pass_requires: [业务线负责人]

5. 落地后的量化变化

第三版上线后，我们跟踪了 6 个月的数据。需要说明的是，这里的数据来自单个 180 人组织的内部观察，样本量不大，不构成行业结论，只能作为情景参考。

这里最值得注意的不是缺陷数下降，而是决策等待天数从 6.8 天降到 2.4 天。因为阶段门的本质是”把决定提前逼到台面上”，决策型任务一旦被显式列出并有责任人，拖延的空间就小了很多。

三、五个高频误区，每一个都能让阶段制度变成形式主义

下面这五个误区，我在不同公司里见过至少三次以上。它们的共同点是：看起来都”很规范”，但恰恰是形式主义的源头。

1. 误区一：把阶段当成”大号里程碑清单”

典型表现是阶段名称后面跟着一串日期，比如”设计阶段：3/1，4/15″。这看起来很有计划性，但实际上把阶段退化成了时间盒。

问题在于：时间盒的准出标准是”时间到了”，而不是”条件满足了”。时间一到，无论设计是否真的完成，阶段都会被宣布结束，因为下一个阶段的任务已经排好了。这时候阶段门就变成了日程提醒，没有任何拦截能力。

我的判断是：阶段可以有目标时间，但准出标准里不能出现时间。时间只能是风险预警信号，”距离目标时间还剩 3 天但准出项还有 5 项未完成”，而不是”时间到了所以准出”。

2. 误区二：阶段任务等于项目经理一个人的任务

这个误区最隐蔽，因为它在纸面上看不出来。清单上的任务都写了，但仔细看责任人，发现 80% 都填的是项目经理。

后果是：项目经理变成了”阶段任务的搬运工”，每个阶段都在替研发写文档、替测试整理报告、替交付准备验收材料。表面上阶段在推进，实际上所有专业判断都被压缩到了一个人身上，质量自然下降。

正确的做法是：阶段任务的责任人必须是”能对这个交付物做专业判断的人”，项目经理的责任是”确保有人负责”和”确保决策按时发生”，而不是亲自产出。这两件事必须分开。

3. 误区三：只有阶段名称，没有准出标准

我见过最典型的一份阶段制度，全文只有一张图，四个方框写着”立项，设计，开发，上线”，加上一些漂亮的箭头。问准出标准是什么，回答是”该做的都做完了”。

“该做的都做完了”这句话，是阶段制度失效的信号灯。因为它既不可验证，也不可争议，没有任何人能证明它不对。

可验证的准出标准长这样：某个具体交付物已存在，并由某个具体角色确认合格。比如”测试报告已产出，且测试负责人确认严重缺陷数为 0、一般缺陷关闭率 ≥ 95%”。这种标准可以被反驳，也可以被验证，这才有意义。

4. 误区四：制度设计只做加法，不做减法

阶段制度最容易膨胀。每次出问题，第一反应就是”加一个检查项”。一年下来，一个阶段可能有 30 个检查项，没人记得全。

我们在第二版迭代时做过一次减法：把第一版的 23 份文档砍到 11 份，同时规定了一个硬规则，任何新增检查项，必须同时说明它替代或合并了哪一项。这条规则一下子把检查项增长速度压住了。

判断一个检查项是否该保留，可以问三个问题：它拦截过真实问题吗？如果没有它，最坏情况是什么？谁能读懂这个检查项的结论？如果三个问题都答不上来，就该删。

5. 误区五：把工具配置当成制度设计

这是我见过最普遍、也最贵的一个误区。很多团队认为”我们在工具里配好了状态流，制度就落地了”。

但工具只能承载规则，不能生成规则。如果工具里配的状态流，只是把原来混乱的流程用更漂亮的界面重演了一遍，那配置本身不产生任何价值。真正的制度设计工作是：定义决策点、定义交付物、定义责任人、定义准出标准、定义强行推进的代价。这五件事做完之后，工具配置只是把它们翻译成可执行的形式。

顺序反了，就会出现那种情况：工具里流程很复杂，但团队私下用群聊推进真实工作，工具只是用来”留痕”。

四、专业判断逻辑：阶段任务设计的四层结构

把上面这些教训收敛一下，我现在做阶段制度设计时，固定按四层往下推。这个顺序不能反，反了就会返工。

1. 第一层：先枚举决策，再归组阶段

找齐所有参与角色，把”这个项目从 0 到 1 必须做的决定”写在便签上，宁多勿少。然后做两件事：合并同类决策（同一批决策人、同一批信息基础），切分跨度过大的决策（比如”是否上线”和”是否交付客户”其实是两个决定，中间隔着一段生产稳定期）。

合并切分之后剩下的决策组，就是阶段。我实测下来，一个中等复杂度的软件项目，决策组通常落在 3，5 个区间。少于 3 个说明切得太粗，风险没有隔离；多于 6 个说明切得太细，管理成本会超过收益。

2. 第二层：给每个阶段定义三类交付物

每个阶段的交付物不要超过五个，并且强制分成三档：

• 准入档：进入本阶段必须先有的输入，比如上一阶段的准出结论。
• 过程档：本阶段进行中产生的关键中间物，比如接口定义、测试策略。
• 准出档：本阶段结束必须产出并签署的，数量控制在 2，4 个。

关键约束是：准出档的每一项都必须有明确的签署人，且签署人不能是项目经理本人。这一条能挡掉 80% 的形式主义，因为项目经理很难替别人签字还装作签了。

3. 第三层：把责任转移显式写出来

项目从 0 到 1 的过程，本质上是一次次责任转移：从产品转到研发，从研发转到测试，从测试转到运维，从运维转到交付。这些转移如果不显式写出来，就会在出问题时变成”我以为你已经接过去了”。

做法很简单：在每个阶段准出清单里，加一行”本阶段准出后，哪项责任转移给哪个角色”。比如方案阶段准出后，”技术方案的正确性责任”从架构负责人转移给研发负责人；交付阶段准出后，”生产环境稳定性责任”从研发转移到运维。

这一行看起来很轻，但它把隐性约定变成了显性契约。我在第二版加入这一行后，跨部门扯皮事件在一个季度内从 14 起降到 5 起。

4. 第四层：准出标准必须可测量

我把准出标准分成三档可测量性，设计时优先追求前两档：

我的经验是：一个阶段里，强可测量标准应占 40% 以上，不可测量标准必须为 0。如果某个阶段确实找不到强可测量标准，那就退到弱可测量，但一定要指定签署人的资质要求，比如”必须由独立于开发团队之外的测试负责人签署”。

五、案例与数据观察：把阶段任务落到 PingCode 这类平台上的具体做法

制度设计完之后，落地质量决定了它能不能撑过一个季度。这一节讲我们实际用 PingCode 落地的做法，包含中大型组织私有化部署和从 Jira 迁移这两个具体场景。

1. 为什么这类场景更适合用 PingCode

先说明适用边界：PingCode 主要服务中大型企业及 100 人以上组织。如果你的团队在 20 人以下、单项目为主，用轻量工具甚至一张结构良好的看板就够，引入重型平台反而增加配置维护成本。

但在我们当时的场景下（110 人研发、7，9 个并行项目、私有化合规要求、需要从 Jira 迁移历史数据），PingCode 有三个点直接匹配需求：

• 支持私有化部署：数据不出内网，满足合规评审要求，这一点在当时是硬门槛。
• 支持 Jira 平滑迁移：我们积累了几年的历史项目数据，迁移时保留了工作项类型映射和历史状态，重新建库的成本被压到了可接受范围。
• 工作项类型可自定义分层：能把”阶段准出检查项”作为独立工作项类型管理，不污染需求列表和缺陷列表。

需要客观说明的是，任何平台都只是承载规则。我们迁移初期曾经把 PinkCode 的状态流配得过于复杂，导致一线人员要记 6 个状态和 4 种流转路径，两周内就出现绕过工具用群聊推进的情况。后来把状态从 6 个压缩到 4 个，流转路径从 4 种压缩到 2 种，工具使用率立刻回升。这条经验我写在这里，是想说明：平台能力再强，配置复杂度必须匹配团队的实际执行力。

2. 阶段配置的四个具体动作

落到配置层面，我们主要做了四件事，按优先级排序：

1. 建独立的工作项类型”阶段准出检查项”。它挂在项目下，但不进入迭代，不参与燃尽，只参与阶段门判断。
2. 把状态流和阶段绑定。阶段推进通过状态流转完成，流转的前置条件是该阶段所有准出检查项已关闭。
3. 给强行推进留一个显式出口。允许强行推进，但必须由授权清单里指定的角色操作，并自动生成一条记录。这一点很关键，完全禁止强行推进会让制度在紧急情况下被整体抛弃，留出口反而保护了制度本身。
4. 看板改为按阶段聚合。周会只看两列：”本阶段准出受阻项”和”本阶段决策待办项”，其余不看。

3. 从 Jira 迁移时容易踩的坑

迁移这件事，工具层面通常不难，难的是语义映射。我们踩过的坑有三个：

第一个是把原来的 Jira 状态直接一对一映射到新平台的状态。结果因为原来有 11 个状态，新平台阶段门只认 4 个，映射后大量历史工作项落在”无法归类”的中间态。正确做法是先定义目标状态模型，再反向映射历史状态，把无法映射的归入一个”历史归档态”而不是硬塞。

第二个是历史数据的字段污染。原来的自定义字段在新平台可能没有对应含义，直接带入会让报表失真。我们的做法是只迁移有明确业务含义的字段，其余字段统一标记为”迁移历史数据，仅供检索”。

第三个是迁移后的双系统并行期。我们让新旧系统并行了两周，但规定以新系统为唯一事实来源，旧系统只读。这条规定避免了”两个地方数字不一致”的争论。

4. 一个可以复用的迁移验证清单

迁移完成后，我们用下面这张清单做验收，一共五项，任何一项不通过就回退重做：

• 历史工作项总数与新系统导入数一致（允许有明确记录的丢弃项）
• 至少抽检 3 个已结项项目，其时间线和状态变化可完整还原
• 当前进行中的项目在新系统中的阶段字段与实际阶段一致
• 权限模型映射正确，无越权可见或该可见不可见
• 报表数据与迁移前基线对比，偏差在可解释范围内

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

阶段制度的形态和团队规模、项目并行度、合规要求强相关。下面按四种典型情况给建议，你可以直接对号入座。

1. 20 人以下 / 单项目为主的团队

这个阶段最忌讳上重制度。我的建议是阶段数控制在 3 个（立项、交付、收尾），准出检查项每阶段不超过 3 个，文档交付物每阶段不超过 2 份。

决策点方面，只显式定义两个关键决策：范围冻结和发布放行。其余决策交给日常沟通，不进入阶段门。过早引入完整阶段体系，最大的风险是团队把精力用在维护制度而不是交付上。

工具方面，一张结构清晰的任务看板加上阶段字段就够了，不需要专门的项目管理平台。

2. 50，150 人 / 多项目并行的团队

这是阶段制度收益最明显的区间。建议阶段数 4 个（立项、方案、交付、收尾），每阶段准出检查项 3，5 个，且必须包含至少一个决策型检查项。

同时必须建立两样东西：一是项目经理的授权清单，明确谁能宣布阶段准出、谁能强行推进；二是跨项目视角的阶段看板，让管理层能一眼看到多少个项目卡在同一个阶段门上。

这个区间也是引入 PingCode 这类平台的合适时机，并行项目一多，靠表格同步阶段状态会迅速失控。

3. 100 人以上中大型企业 / 强合规要求

这个区间段的核心矛盾是：制度要全，但执行要轻。我的建议是分两层设计，制度层保留完整阶段定义和完整准出清单，执行层只暴露当前阶段需要的检查项。

具体做法是把准出清单按阶段切分，团队只看到自己当前阶段的 3，5 项，历史阶段的记录归档但不常驻视野。这样既满足了合规审计的完整性要求，又不会让一线人员被几十项检查淹没。

合规场景还建议加上”阶段准出记录不可篡改”的要求，包括强行推进的记录。这类要求通常只能在支持私有化部署、且具备完善操作日志能力的平台上实现，这也是当时我们选择 PingCode 的原因之一。

4. 正在做国产替代、需要从 Jira 迁移的团队

给三条实操建议。第一，先固化目标阶段模型，再做迁移，不要指望在迁移过程中顺手重构流程，两件事并行做几乎必然失控。第二，迁移分两批，先迁历史归档数据（只读），再迁进行中项目（可写），中间留出验证窗口。第三，迁移完成后的两周内保留旧系统只读权限，但公告明确唯一事实来源是新系统。

PingCode 支持 Jira 平滑迁移这个能力在我们的场景里确实减少了工作量，但我要强调：迁移的难点在语义映射和流程重定义，工具只解决了搬运问题。把这两件事分开看，项目会顺利很多。

七、不同情况下的取舍：轻制度与重制度的成本收益对比

阶段制度设计本质上是一次取舍，不存在”既要又要”。我把三档方案的成本收益摊开，你可以按自己的约束条件选。

如果只能给一条取舍原则，我会说：宁可从轻量方案开始逐步加，也不要一次上重型方案再往下减。因为加制度是”发现问题，加一条”的渐进过程，团队有适应期；减制度则意味着承认之前的做法有问题，阻力大得多。

另一个容易被忽略的取舍是阶段数与阶段时长的关系。阶段越多，单个阶段的时长越短，看起来控制更细，但每个阶段都要走一遍准出流程，管理开销和阶段数量大致成平方关系增长，因为阶段之间的交接界面数量是阶段数的组合。这条规律是我在第三次迭代里才意识到的，也是我们把阶段从 6 个砍到 4 个的根本原因。

八、结语：阶段制度好不好，只看三件事

回到最开始那个复盘会上的问题，四个人给出四个阶段答案。这件事的本质不是沟通问题，而是阶段定义没有和决策权绑定。当阶段只是一个名字，谁都可以对它有自己的理解；当阶段背后挂着明确的决策点、交付物和签字人，答案就只有一个。

如果让我用一个独特视角总结这篇内容：阶段任务的真正难点不在”任务怎么拆”，而在”决定由谁做”。绝大多数阶段制度失败，不是因为拆得不够细，而是因为拆出来的东西不涉及任何人的决策权，于是谁都不需要对它负责。

判断你自己的阶段制度是否成立，看三件事就够了：

1. 过去半年里，有没有哪个项目因为阶段准出未通过而被拦下过？如果没有，制度还没生效。
2. 每个阶段的准出清单里，是不是至少有一个”必须由非项目经理签署”的检查项？如果没有，责任还在项目经理一个人身上。
3. 阶段推进的动作，是在工具里完成的，还是在一份表格或一次口头确认里完成的？如果是后者，制度随时会被绕过。

下一步具体怎么做，我建议按这个顺序推进：

• 本周内：找四个角色（产品、研发、测试、交付）各一人，用两小时把”这个项目必须做的重要决定”列出来，先不定义阶段。
• 两周内：把决策归组，形成 3，5 个阶段，并给每个阶段写出 3，5 个准出检查项，其中至少一个必须是决策型、且签署人不是项目经理。
• 一个月内：把阶段准出检查项配置到工具里，让状态流转和检查项绑定，并给强行推进留一个需要授权的显式出口。
• 一个季度后：统计”因阶段准出未通过而改变决策”的次数。这个数字从 0 变成 3 以上，说明制度开始起作用了。

最后提醒一句：阶段制度的价值不在于它写得有多完整，而在于它有没有真的拦住过一件不该继续的事。如果一个季度下来一次都没拦过，那该检查的不是团队的执行力，而是你的准出标准是不是写得太温柔了。