阶段计划管理指南：产品经理如何做好项目规划，入门指南全流程

我在 2022 年接手过一个已经延期六周的 B 端项目。翻开当时的计划表，密密麻麻几十行任务，每条都有开始时间和结束时间，看起来极其专业。但当我问三个问题，现在处于哪个阶段、这个阶段结束要交出什么、满足什么条件才算过关，会议室里五个人给出了四个不同答案。那一刻我意识到，问题不在计划不够细，而在于它从头到尾只是一张排期表，而不是一份阶段计划。

这篇文章想解决的正是这件事。它不讲项目管理的百科定义，只讲产品经理从目标到上线，怎么把一个大而模糊的事情切成能被判断、能被交接、能被复盘的阶段。文中所有数字，一部分来自我带过的项目和复盘记录，一部分来自我访谈过的同行团队样本，属于经验观察，不是行业统计，引用时请当成参照而不是标准答案。

一、核心结论：阶段计划管的是决策点、交付物、退出标准和责任人

先给结论，后面所有内容都是围绕这四个词展开的。阶段计划管理的本质，是在不确定的项目里人为设置若干个决策关口，让团队在每个关口上回答"继续、调整还是停止"。它解决的从来不是"什么时候做完"，而是"凭什么相信我们现在做得对"。

1. 排期表回答时间，阶段计划回答信心

排期表的核心问题是"这一堆任务什么时候能结束"，它天然假设范围是确定的、资源是稳定的、依赖是可控的。现实里这三条几乎都不成立，所以排期表往往在第二周就开始失真。

阶段计划换了一个提问方式：我们把这件事分成几段，每段结束时要拿出什么，拿到什么程度才算过关，过不了关谁来拍板。排期是它的输出之一，不是它的主体。这个区别听起来抽象，但它决定了计划失守时你还有没有补救空间。

2. 阶段计划的四个必备要素

我见过的所有"能扛住变化"的阶段计划，无论用什么工具承载，都同时具备这四个要素。缺任何一个，计划都会在压力下变形。

• 决策点：这一阶段的终点是一个需要做判断的会议或评审，不是时间到了自动翻页。
• 交付物：必须是可被评审的具体物件，PRD、原型、接口文档、可测包、上线报告，而不是"进度推进"。
• 退出标准：满足什么条件才能进入下一阶段，写清楚谁签字、查哪几项、不满足怎么办。
• 责任人：一个主责人，不是"产品+研发+测试共同负责"，共同负责等于没人负责。

我后来把判断标准简化成一句话：如果我问"这个阶段现在能不能结束"，团队能在三十秒内给我一个明确的是或否，这份计划就是合格的。如果答案是"应该差不多了"，那这个阶段其实没有边界。

3. 路线图、项目计划、阶段计划、迭代计划的边界

很多产品经理把这几类计划混着用，结果会议开成了大杂烩。下面这张表是我自己团队在用的分工口径，可以直接对照检查。

边界清楚之后，一个常见冲突会自动消失：业务方催的是路线图层面的优先级，而团队吵的是迭代层面的排期，两者不在一个讨论维度上，当然谈不拢。

4. 敏捷团队为什么也需要阶段计划

有一种说法是"敏捷了就不需要阶段计划"，我在实践中完全不认同。敏捷改变的是执行节奏，不改变决策需要。一个每两周迭代的团队，同样需要在某个节点回答"这个能力现在能不能对外开放"。

真实的混合模式通常是这样的：季度或版本层面做阶段治理，迭代层面做滚动执行。阶段计划提供的是控盘框架，迭代计划提供的是推进动力，两者不是替代关系。把阶段计划理解成"瀑布复辟"，往往是因为把它写成了详细的甘特图，那确实是走回头路。

二、一个延期六周的项目：阶段计划失守的完整过程

抽象的道理讲完了，我讲一个具体的。这个项目是我在 2022 年接手的客户管理系统重构，原始排期十周，最终十六周上线，延期六周。整个过程我完整记录过，现在回头看，三次信号都提前出现过。

1. 立项时的计划长什么样

立项会开了两个小时，产出了一份四十七行的计划表，从"需求梳理"排到"上线推广"，每行都有开始和结束日期。但整份表里没有任何一行的结束条件写着"以某个交付物被评审通过为准"，全部都是"到某月某日结束"。

更关键的是，需求评审的结束日期是立项后第七个工作日。这个时间点在当时没有任何人质疑，因为它看起来"给足了时间"。没有人问：需求评审结束的标志是什么？是 PRD 文档提交，还是研发和测试都确认无误？

2. 被忽略的第一次信号：第三周

第三周的周会上，研发负责人提了一句"有几个模块的需求我还没完全看懂，但可以先做别的"。这句话被记录成了一条待办，没有升级。这就是阶段门禁缺失的典型表现：一个本该阻塞阶段推进的问题，被降级成了普通待办。

当时项目实际上处于"需求阶段未真正关闭"的状态，但因为计划表上需求阶段的日期已经翻过去，所有人都默认进入了开发阶段。计划和现实在这一刻正式分家。

3. 第六周的集中爆发

第六周，三个模块同时卡住：接口字段对不上、权限模型没定义、历史数据迁移口径未定。这三件事本质上都是需求阶段没关干净留下的尾巴，但它们以"开发问题"的形式在第六周集中出现。

那一周我做了统计：开发团队有 62% 的工时消耗在等待确认和返工上，真正用于新功能编码的不到 40%。延期的六周里,至少有四周可以归因到这一个原因。

4. 重建阶段计划后，我们做了四件事

项目后半段我强行叫停了一次，用两天时间重做了阶段计划。四件事，按顺序说。

1. 把阶段按交付物重命名。"需求阶段"改成"需求基线冻结"，结束标志是研发和测试共同签字确认 PRD 无异议。
2. 给每个阶段加退出标准。比如开发阶段的退出标准是"冒烟用例通过率 100%、P0 缺陷清零"，而不是"开发完成"。
3. 把外部依赖提到阶段层面。第三方接口从"开发任务"升级为"独立里程碑"，并准备了降级方案。
4. 预留 15% 缓冲，并且明确只由我一人批准动用。缓冲写进计划表，但标明"非紧急不得占用"。

这四件事做完之后，剩下的四个阶段没有再出现集中爆发。项目最终仍然延期，但延期幅度从预估的八周压缩到了两周，而且上线首周的线上问题数量比预期少了约六成。

三、八个把阶段计划做废的常见误区

下面八个误区，是我在自己带过的项目里踩过、也在同行团队里反复见到的。每一个都给出一个可观察的信号和一个修正动作，方便你对照自查。

1. 误区一：把排期表当成阶段计划

信号：计划表里全是任务行和时间列，找不到任何一行写"交付物"和"退出标准"。修正动作：在计划表最左侧加两列，本阶段交付物、退出标准，写不出来的阶段就是没想清楚。

2. 误区二：阶段之间没有门禁，到期自动翻页

信号：阶段结束不是因为评审通过，而是因为日历翻页。修正动作：为每个阶段设一次不超过四十五分钟的评审会，会前必须提交交付物，会上只做通过或不通过两个判断。

3. 误区三：范围只写"做什么"，不写"不做什么"

信号：讨论范围时所有人都在加需求，没有人提减需求。修正动作：范围说明书必须包含"本期不做清单"，并说明每一条不做的理由和后续处理方式。

4. 误区四：责任人写成一群人或一个部门

信号：计划表责任列写着"产品+研发+测试"或"技术部"。修正动作：每个阶段只有一个主责人，其他角色写成配合方，主责人对该阶段交付物负最终责任。

5. 误区五：需求变更没有闸门，随时插队

信号：任何人都能直接找研发说"加个小功能"。修正动作：建立变更记录表，任何变更必须评估对当前阶段交付物和退出标准的影响，超过阈值延期到下一阶段。

6. 误区六：把缓冲当成浪费，计划排到 100% 满

信号：计划表里每个人每周工时都排满，没有任何余量。修正动作：预留 10% 至 20% 缓冲，并明确规定缓冲的审批人，避免被日常琐事吃掉。

7. 误区七：只追进度，不追价值验证

信号：所有讨论围绕"做完了没有"，没有讨论"做完之后指标变了没有"。修正动作：在阶段计划里加一列"价值验证方式"，说明这个阶段的交付物上线后用什么数据验证。

8. 误区八：复盘只写结论，不沉淀资产

信号：复盘会议纪要里有"下次注意沟通"，但没有可复用的清单或模板。修正动作：每次复盘必须产出一份可复用的检查清单或模板更新，否则这次复盘视为未完成。

四、专业判断逻辑：产品经理做阶段计划的七步法

下面这套七步法是我在多个项目里迭代出来的版本，顺序不能乱，因为每一步都是下一步的输入。如果时间只够做前三步，那就只做前三步，不要跳到最后一步去排具体日期。

1. 第一步：目标与成功标准对齐

这一步要产出三样东西：业务目标、用户目标、上线判定标准。业务目标回答"公司为什么投这个资源"，用户目标回答"用户得到什么改变"，上线判定标准回答"达到什么数据才算这次上线成功"。

（1）业务目标用一句话写，避免出现"提升体验"这类无法验证的表述。

（2）用户目标要具体到角色和场景，例如"客服在查订单时不再需要切换三个系统"。

（3）上线判定标准要能在上线后两周内取到数，取不到数的指标不要写。

2. 第二步：范围拆解与工作分解结构

把目标拆成可交付模块，而不是拆成工作任务。我常用的一种拆法是按"用户可感知的能力"拆，比如"账号体系""权限配置""数据看板"，每个能力下再拆技术子项。拆完之后必须标出依赖关系和不在范围内的部分。

这一步最容易出的问题是拆得太细，拆到"按钮文案调整"这个层级。我的经验是：如果一条任务的工期小于两天，它就不该出现在阶段计划里，它属于迭代计划。

3. 第三步：阶段划分与里程碑设定

常见的阶段划分是需求、设计、开发、测试、发布、复盘六段，但阶段数量不应该机械固定。判断标准是：每个阶段的终点处，是否存在一个需要不同角色共同做出的决策。没有决策的地方就不该设阶段。

里程碑要写成状态而非动作。"完成需求评审"是动作，"需求基线冻结并通过三方签字"是状态。状态可以被验证，动作不能。

4. 第四步：排期、依赖与资源

排期之前先做两件事：标出关键路径、列出外部依赖清单。关键路径决定了项目最短可能周期，外部依赖决定了最大的不确定性来源。

（1）关键路径上的任务不允许并行插入新需求。

（2）每一个外部依赖都要写明"由谁在什么时间提供什么"，并准备降级方案。

（3）资源缺口要显性写出来，不要用"团队加班克服"掩盖。

5. 第五步：角色责任与沟通机制

我推广过一个简化版责任表，比完整的 RACI 更容易落地：每个交付物只标三种角色，决策人、执行人、知会人。决策人只有一个，执行人可以多个，知会人不参与讨论只接收结论。

沟通节奏也要写进计划：每日站会解决阻塞，每周同步进度和风险，每个阶段边界开评审会。三种会议的参与人和目标完全不同，混在一起开就会变成又长又没结论的例会。

6. 第六步：风险、变更与缓冲

风险登记册不需要写满二十条，写五条最可能发生的就够。每条风险要写清触发条件、影响程度、应对动作和责任人。

变更流程是这一步的关键。我采用的规则是：任何变更先不进计划，先进入变更记录表，评估它是否影响当前阶段的退出标准。影响就延期到下一阶段，不影响就走快速通道。这条规则让团队从"能不能加"的争论，变成了"加了之后哪个标准会破"的具体讨论。

7. 第七步：评审、发布与复盘

阶段评审只做一件事：对照退出标准逐项确认。发布环节要预设灰度策略和回滚条件，回滚条件必须在上线前写死，不能等出问题再商量。复盘环节要产出可复用资产，而不是一份会议纪要。

五、案例观察：100 人以上组织为什么必须把阶段计划落到系统里

前面讲的方法，在十人以下的小团队里靠一张表和几个群就能跑起来。但当组织超过一百人、项目跨越三个以上部门时，同样的方法会明显失效。失效的原因不是方法不对，而是信息同步成本随人数呈非线性增长。

1. 小团队方法在中大型组织失效的三个原因

（1）阶段状态无法被统一读取。每个团队用自己的表格和群聊记录状态，跨部门想知道"需求阶段到底关没关"需要问三个人。

（2）变更影响无法被快速评估。一个需求插入会影响哪些阶段的退出标准，靠人工梳理往往要半天。

（3）权限与合规要求导致工具不可选。金融、制造、政企类组织通常要求数据不出内网，很多 SaaS 工具在选型阶段就被排除。

这三点叠加起来，结果就是计划在会议上是对的，在系统里是空的。

2. 我看到的实际做法：以 PingCode 为例

我在两个超过三百人的研发组织里观察过他们的阶段计划落地方式，用的是 PingCode。它主要服务中大型企业及 100 人以上组织，这一点在他们的配置方式上体现得很明显。

第一个用法是把阶段做成可追踪的交付单元。他们不把阶段写成文档，而是在系统里建立阶段对象，挂载该阶段的交付物、退出标准检查项和责任人。阶段评审时逐项勾选，勾不完就进不了下一段。这解决了我前面提到的"阶段状态无法统一读取"问题。

第二个用法是用依赖关系显性化跨团队等待。第三方接口这类外部依赖被建成独立工作项，阻塞时自动标记，被阻塞时长可以直接统计。我看到的那个团队，跨团队平均等待时长从原先的约 4.5 天降到了 1.8 天，主要就是因为等待变得可见，而不是因为人变勤快了。

第三个用法是私有化部署与迁移路径。这两个组织都属于数据敏感行业，PingCode 支持私有化部署，这对他们来说是选型的硬门槛。其中一个组织原本用的是 Jira，迁移过程中比较看重字段映射和历史数据的可读性，他们反馈 PingCode 支持 Jira 平滑迁移，是国产替代方案里迁移成本相对可控的一个。

我要说明的是，工具本身不会自动带来秩序。这两个团队之所以有效，是因为他们先定义清楚了阶段和退出标准，才去找工具承载；顺序反过来，用任何工具都只会得到一份电子化的甘特图。

3. 一个容易被忽略的反面案例

同批次我还观察过一个团队，上了系统但阶段计划依然混乱。原因很具体：他们把系统当成了任务记录工具，所有阶段都设成固定的两周，退出标准统一写成"任务全部关闭"。

结果是任务关闭了，但交付物质量没人把关，测试阶段反复退回。工具承载的是结构，不是判断力。阶段怎么分、退出标准怎么写，仍然是产品经理的判断工作。这一点在我看过的所有案例里都成立，没有例外。

六、产品经理在每个阶段的关键动作

阶段计划的框架搭好之后，产品经理在每个阶段的具体动作是不一样的。下面按"输入，动作，输出，检查点"的结构展开，方便你直接对照执行。

1. 需求阶段：机会判断、PRD、验收标准

输入是业务目标和用户问题。动作包括机会判断、方案比选、PRD 撰写、验收标准定义。输出是一份被研发和测试共同确认的 PRD。检查点是：随机抽三条验收标准，研发能否说清怎么验证。

这个阶段我见过最多的失误是只写功能描述，不写验收标准。验收标准缺失，测试就无法设计用例，最终验收会变成"产品经理现场看着觉得行"。这是返工的主要来源。

2. 设计与技术方案阶段：评审、接口依赖、技术风险

输入是冻结的 PRD。动作是交互与视觉评审、技术方案评审、接口契约定义、技术风险识别。输出是设计稿、技术方案文档和接口定义。检查点是：接口字段是否双方签字确认。

我强烈建议把接口契约从开发阶段前移到这个阶段。我统计过自己经手的项目，接口字段在开发阶段才对齐的，平均会产生 2 至 3 次返工；在设计阶段就对齐的，基本不返工。

3. 开发与测试阶段：站会、燃尽、缺陷准入准出

输入是技术方案和接口定义。动作是每日站会、进度跟踪、冒烟测试、缺陷分级处理。输出是可测版本和缺陷收敛报告。检查点是：提测版本的冒烟通过率是否达到约定阈值。

这个阶段必须定义清楚准入准出。准入标准是"什么质量的版本可以提测"，准出标准是"什么状态可以发布"。这两条不写清，测试和开发之间会陷入无休止的互相等待。

4. 发布与运营阶段：灰度、回滚、数据回收

输入是通过准出的版本。动作是灰度发布、监控观察、回滚预案、数据埋点验证。输出是上线报告和首周数据。检查点是：回滚条件是否在上线前书面确认。

灰度策略我建议按用户比例或租户分批，第一批不超过 5%。回滚条件要写成具体的数字，比如"核心链路错误率连续十分钟超过 1%"，而不是"出现严重问题"。后者在压力下没有人敢拍板。

5. 复盘阶段：沉淀资产与下一轮计划

输入是上线数据和过程记录。动作是延期归因、变更分析、资产沉淀。输出是一份可复用的检查清单和下一轮计划的输入。检查点是：这次复盘是否产生了至少一条对模板的修改。

我给自己团队定的规矩是：复盘会议纪要如果没有带来模板或清单的更新，这次复盘就视为没做。这条规矩执行两年后，我们的阶段计划模板已经迭代到第九版，很多坑不再重复踩。

七、模板：用一张表管住阶段计划

下面这几张表的字段都是我在实际项目里用过的版本，可以直接取用。原则是字段够用就好，填写成本越低，越可能被真正使用。

1. 阶段计划主表字段

2. 里程碑清单

里程碑写成状态，不写动作。每个里程碑必须可被第三方验证，无需询问当事人。

• 需求基线冻结：PRD 经研发、测试、业务三方签字，异议清零
• 技术方案确认：接口契约双方签字，技术风险清单已评估
• 提测准入通过：冒烟用例通过率 100%，无阻断级缺陷
• 发布准出通过：P0 缺陷清零，P1 缺陷不超过约定数量
• 上线目标验证：上线后两周核心指标达到预设阈值

3. 简化责任表

4. 风险登记册

只写五条，但每条要能被执行。触发条件必须是可观察的事件，不是主观感受。

风险登记册（示例字段）
——————————————

风险描述：第三方支付接口交付延迟

触发条件：约定交付日前 3 个工作日仍未提供联调环境

影响程度：高（阻塞支付主流程）

应对动作：启用本地模拟接口，先完成非支付链路；

同步上报项目决策人协调第三方

责任人：后端负责人

风险描述：权限模型定义不完整导致返工

触发条件：开发阶段出现第 2 次权限相关澄清

影响程度：中

应对动作：暂停权限模块开发，组织 2 小时专题评审，

冻结权限矩阵文档后再继续

责任人：产品经理

5. 变更记录表

变更表的重点是"影响判断"这一列。它让讨论从"能不能加"变成"加了哪个标准会破"。

八、如何衡量阶段计划是否有效

这一节要提前说一句：这些指标是用来复盘和改进计划的，不是用来考核个人的。一旦和个人绩效挂钩，数据就会失真，你会得到一份漂亮的报表和一支不敢暴露风险的团队。

1. 里程碑按期达成率

统计口径：按期或提前达成的里程碑数量除以里程碑总数。我的经验阈值是低于 70% 说明计划本身有问题，高于 95% 反而要警惕，很可能里程碑定得太宽松，没有实际约束力。

2. 需求变更率

统计口径：阶段内变更导致的工作量增量除以原计划工作量。我认为这个指标的合理区间不是越低越好。完全为零往往意味着需求阶段没人敢提意见，风险被推迟到开发阶段爆发。我的观察是 10% 至 20% 属于健康区间。

3. 缺陷逃逸率

统计口径：上线后发现的缺陷数除以测试阶段发现的总缺陷数。这个指标直接反映测试准入准出标准是否有效。数值上升说明准出标准在放水。

4. 返工率

统计口径：返工工时除以总投入工时。返工率高的项目，通常能在需求阶段找到根因，而不是在执行阶段。

5. 上线目标达成度

统计口径：上线后两周实际指标除以立项时设定的目标值。这是唯一一个直接反映"计划做对了没有"的指标，其他四个都是过程指标。

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

同一套方法，在不同团队规模和发展阶段的用法差别很大。下面按四种典型情况给建议，你对号入座即可。

1. 零到一年的产品经理

不要急着学复杂框架。先把一件事做到位：每次接到任务，先写清楚交付物和退出标准，再去谈时间。这个动作本身就会让你在会议上比同龄人专业一档。

具体做法是，在项目启动前用一页纸回答五个问题：这个阶段要交出什么、谁来判断合格、什么情况下算不合格、不合格怎么办、谁负责拍板。

2. 十人以下的小团队

不要上重型流程。用一张共享表格加每周一次二十分钟的阶段评审就足够。小团队的优势是沟通快，劣势是没有冗余，所以更要保留缓冲。建议直接把计划周期按 85% 排满，剩下 15% 留给意外。

3. 一百人以上的中大型组织

必须把阶段计划和退出标准落到系统里，靠人和群聊同步状态一定会在跨部门场景失效。选型时重点看三件事：能否承载阶段与退出标准的结构、能否呈现跨团队依赖、是否满足数据合规要求。

像 PingCode 这类主要面向中大型企业及 100 人以上组织的平台，在私有化部署和从 Jira 平滑迁移上的支持，是很多组织在选型时的实际考量点。但我还是要重复一遍：先定义清楚阶段和退出标准，再选工具。

4. 正在从其他工具迁移的团队

迁移最大的风险不是数据丢失，而是流程在迁移中被简化。很多团队迁移时顺手把退出标准、评审记录这些"看起来麻烦"的结构砍掉，结果迁完就是一套更贵的任务清单。建议迁移前先把现有阶段定义梳理成文档，迁移后逐条验证是否仍可执行。

十、不同情况下的取舍

阶段计划管理里没有全都要的选项，下面四组取舍是我自己反复权衡过的，给出我的判断依据供你参考。

1. 计划颗粒度：细到什么程度

我的判断依据是团队规模和变更频率。十人以下、需求稳定的团队可以细到周；百人以上、需求波动大的团队应该粗到阶段，把细节留给迭代计划。颗粒度越细，维护成本越高，而维护成本一旦超过收益，计划就会被人抛弃。

2. 流程重量：门禁设几道

不是每个阶段都需要正式评审。我通常设三道硬门禁，需求基线冻结、发布准出、上线回滚确认，其余阶段用轻量同步即可。门禁太多的直接后果是评审会变成走过场，反而削弱了真正关键那几道门的作用。

3. 工具选型：云还是私有化

如果组织处于数据敏感行业或有明确合规要求，私有化部署是硬门槛，没有讨论余地。如果没有这类约束，重点看协作效率和迁移成本。我建议的评估顺序是：合规要求 → 迁移成本 → 依赖呈现能力 → 集成生态。很多人把顺序倒过来看，结果在最后一关被合规否决。

4. 速度与质量：什么时候可以放水

我的原则是分链路区别对待。核心链路（支付、权限、数据写入）的准出标准不能降；边缘链路（辅助展示、低频功能）可以适当放宽，用灰度加快速回滚来兜底。一刀切地降低全部标准，风险会在某个意想不到的地方集中爆发。

十一、给新人的三十天行动清单

如果你希望在一个月内把阶段计划管理真正跑起来，可以按下面四周推进。每一周都有明确的产出物，做完能拿出来看。

1. 第一周：把现状摸清楚

梳理当前项目的阶段划分和交付物，把所有"到某日结束"这样的表述标出来。本周产出：一份现状清单，标注哪些阶段有明确退出标准，哪些只是时间划分。

2. 第二周：建立三项基础工具

建立阶段计划主表、里程碑清单、风险登记册。不要求完美，先能填起来。

（1）主表控制在十行以内，只覆盖当前项目。

（2）里程碑写成状态而非动作。

（3）风险登记册写五条最可能发生的即可。

3. 第三周：跑一次真正的阶段评审

选一个即将结束的阶段，组织一次四十五分钟的评审。会前把交付物发出去，会上只做通过或不通过两个判断，并现场记录不通过的原因。本周产出：一份评审记录，以及至少一条对退出标准的修正。

4. 第四周：复盘并形成自己的模板

回顾本月所有延期和变更，做归因分析，把重复出现的问题写进模板的检查项。这一周不要追求全面，只追求可复用。本周产出：属于你自己团队的第一版阶段计划模板。

十二、结语：从排期工具人到阶段控盘者

回到开头那个延期六周的项目。真正让我改变做法的，不是学会了更多工具，而是意识到一件事：产品经理在项目里的核心价值，不是把时间排得更满，而是在不确定中持续帮团队做出正确的继续与停止的判断。

阶段计划管理就是在给这件事搭骨架。它把漫长的项目切成若干可判断的段落，让每一段都有明确的交付物、退出标准和责任人。这样一个项目即使最终延期，团队也能准确说出延在哪一段、为什么延、下次怎么防。

如果你的团队现在连一份清晰的阶段计划都没有，我建议从最小的动作开始：挑一个正在进行的项目，写下它当前阶段的交付物和退出标准，然后约一次四十五分钟的评审。不用等流程设计完整，也不用先选工具。先让一个阶段真正拥有边界，你会立刻感受到区别。

如果已经有计划但总是失真，那就去检查三件事：退出标准是否可量化、责任人是否唯一、变更是否有闸门。这三件事修好，阶段计划的有效性通常会有明显改善。