进度管理如何做好阶段进度？项目负责人数据分析与操作步骤

我带过一个 60 人的系统交付项目，第三个阶段验收前一天，进度看板上整体完成率是 91%，甘特图上一条红线都没亮。第二天客户验收，我们卡在数据迁移的接口联调上，这个任务在系统里显示"完成 80%"，已经挂了 11 天没动。延期赔付谈了两周。这件事之后，我把进度管理的重心从"看数字"改成了"看阶段的退出条件"。这篇文章想讲的是：项目负责人怎么用数据分析管住阶段进度，而不是把甘特图截图当成进度汇报。

一、先说结论：阶段进度管不好，九成不是工具问题

大部分团队不缺工具，缺的是判断口径。工具能告诉你任务卡片停在"进行中"多久，但告诉不了你"这个阶段到底能不能退出"。阶段进度失控的根因，通常藏在这句话里：你管的是任务，而客户和老板要的是阶段交付物。

1. 我的三个核心判断

第一个判断：阶段进度的最小管理单元是"阶段门禁"，不是"任务列表"。门禁的意思是，一个阶段必须有明确的交付物、验收标准、责任人和退出条件，缺一个就不能进入下一阶段。没有门禁，阶段就只是时间刻度，随时可以被下一个阶段吃掉。

第二个判断：项目负责人至少要盯三层数据，结果层、过程层、预测层。结果层告诉你到了没有，过程层告诉你稳不稳，预测层告诉你还来不来得及。只盯一层的负责人，永远在事后救火。

第三个判断：纠偏的终点是基线更新，不是改日期。改日期只是把风险往后挪，基线更新是把变更、资源和范围重新对齐一次，形成可追溯的版本记录。

2. 一个反常识观察：完成率越漂亮，风险可能越大

我统计过自己负责的 9 个项目，阶段末完成率超过 90% 的项目里，有 5 个在下一阶段出现了超过两周的延期。反而是完成率在 70%，85% 区间就主动暴露问题的项目，最终交付反而更稳。

原因不复杂：完成率是"自报数据"，越到阶段后期，团队越倾向把任务标成"快完成了"。而真正的风险从来不体现在百分比上，它体现在关键路径任务的最后更新时间和阻塞天数上。

3. 阶段进度和整体进度，差别到底在哪

很多人把这两个概念混用，结果阶段进度汇报写成了整体进度复述。两者的管理对象完全不同，判断标准也不同。

我自己的习惯是：整体进度放在月度汇报里讲，阶段进度放在每周进度会上讲。两者共用一套数据源，但判断口径必须分开，否则会出现"整体看着还行、阶段其实已经烂尾"的情况。

二、为什么阶段进度总在第三周失控

阶段进度的失控很少发生在第一天，它几乎总是发生在第二阶段走到第三周的时候。这个时间点有个共同特征：前期任务基本收尾，中后期的重活刚开工，团队进入"看起来都在忙"的状态。

1. 现场还原：一个 60 人交付项目的失控过程

回到开头那个项目。阶段二从 3 月 4 日开始，计划 6 周。第一周一切正常，第二周开始出现零星的依赖等待，第三周问题集中爆发。

第三周周一，我拉了一次全量数据，发现三件事同时成立：数据迁移接口联调卡了 11 天；报表模块有 6 个任务被标成"完成 80%"但没有一个超过 3 天没更新；测试环境准备任务显示"进行中"已经 9 天，责任人其实是空的。

更麻烦的是，这三件事在整体完成率上完全看不出来。因为大量的文档、配置、会议类任务都完成了，把整体数字抬得很高。这就是典型的"完成率被低价值任务稀释"。

2. 数据失真的三个来源

第一个来源是自报进度。任务完成百分比由执行人自己填，缺少校验规则，容易形成"完成 80% 长期不动"的僵尸任务。

第二个来源是阻塞不登记。团队在等外部接口、等环境、等审批，但不会主动把任务标成"阻塞"，因为标记阻塞往往意味着要在会上解释原因。

第三个来源是返工被隐形。已经"完成"的任务被重开，或者返工的工作量直接记进原任务，导致原任务完成度长期停在 80%，95%，永远关不掉。

3. 为什么会形成"前松后赶"的结构性节奏

我复盘过 12 个延期项目的节奏，一个规律反复出现：阶段前 40% 的时间里，团队完成的是容易的任务；阶段后 30% 的时间里，团队要完成的是难的任务，但可用时间只剩 30%。

这不是执行力问题，是任务排序问题。容易的任务先做，能快速让看板变好看，但它不会降低风险。真正需要前置的是高不确定性任务：外部依赖、联调、环境准备、数据迁移、性能验证。

所以我现在做阶段计划时，会强制把"不确定性最高的 20% 任务"排进阶段前 40% 的时间窗口。哪怕它们当时没有资源，也要先启动、先暴露依赖。

三、四个反复见到的误区

下面这四个误区，我在不同公司、不同项目类型里都见过，而且它们往往同时出现。

1. 误区一：把甘特图当成进度管理

甘特图只是计划的可视化，不是管理动作。我见过团队每周更新甘特图的条形长度，但从来不更新任务的实际开始、实际结束和剩余工期。

结果就是：图很漂亮，数据是空的。判断甘特图有没有被真正用起来，有一个简单标准，你能不能从图上直接读出哪些任务已经偏离基线超过 3 天。读不出来，它就只是装饰。

2. 误区二：用任务完成数代替阶段交付物

"我们阶段二完成了 128 个任务，进度良好。"这句话在进度会上几乎没有任何信息量。客户和老板关心的是交付物：接口文档齐了没有，数据迁移验证报告出了没有，验收用例跑通了没有。

我的做法是，每个阶段先列交付物清单，再把任务挂到交付物下面。进度汇报时先讲交付物状态，再讲任务状态。顺序反了，会议就会变成任务流水账。

3. 误区三：所有阶段用同一套指标

需求阶段的核心风险是需求不稳定，用"需求变更次数"比用"任务完成率"更有意义。开发阶段的核心风险是集成和返工，用"返工率、阻塞任务数"更有效。测试阶段的核心风险是缺陷收敛速度，用"缺陷关闭率、重开率"更直接。

一套指标打到所有阶段，结果就是每个阶段都测不准。阶段指标要跟着阶段风险走，而不是跟着模板走。

4. 误区四：把纠偏等同于改日期

发现偏差后直接改计划结束日期，是最省事也最危险的动作。它会让基线失去意义，也会让团队形成"反正可以改"的心理预期。

正确的顺序是：先判断偏差是否影响关键路径，再判断影响总工期的天数，然后才在赶工、快速跟进、调资源、缩范围、升级决策这五个动作里选，最后才更新基线。改日期是结果，不是动作。

四、专业判断逻辑：三层数据加四个问题

这一节是我认为全文最核心的部分。项目负责人的数据分析能力，不在于会算多少公式，而在于知道每一层数据回答什么问题，以及什么时候该停下来。

1. 结果层：回答"到没到"

结果层是给管理层和客户看的，指标少而稳定。我常用的三个是：里程碑达成率、阶段完成率、阶段门禁通过率。

里程碑达成率按"按期达成的里程碑数 ÷ 计划里程碑数"计算，统计口径要明确是按自然日还是工作日。阶段完成率建议按交付物加权，而不是按任务数平均，否则一个 1 人天的配置任务和一个 20 人天的联调任务权重一样，数据会失真。

2. 过程层：回答"稳不稳"

过程层是项目负责人自己用的，指标更多、更新更频繁。核心包括：计划完成率、关键路径浮动时间、阻塞任务数与阻塞天数、返工率、资源负荷率。

这里我要特别强调阻塞天数。我自己的经验阈值是：关键路径任务阻塞超过 3 天必须升级到项目负责人，超过 7 天必须进入管理层视野。这个阈值不是标准，是我在多个项目里试出来的相对稳定的分界线。

3. 预测层：回答"还来不来得及"

预测层包括预计完工时间、剩余工期、以及挣值类指标。预计完工时间最简单的算法是：用过去 3 周的实际完成速率外推剩余工作量。它不精确，但能提前两周给出方向。

至于 SPI、SV 这类挣值指标，我的判断是：它们适合有明确基线、可量化 EV 的项目，不适合探索型和创意型项目。需求频繁变更、交付物难以量化的项目，强行套用挣值指标，只会得到一堆"看起来专业但没人信"的数字。

4. 判断偏差是否致命的四个问题

数据出来之后，项目负责人真正要做的是决策，而不是继续算。我通常用四个问题快速判断：

1. 这个偏差落在关键路径上吗？不在关键路径上的偏差，影响的是资源，不是总工期。
2. 关键路径上还有多少浮动时间可以吸收？浮动时间被吃掉多少，风险就有多大。
3. 这个偏差是趋势性的还是一次性的？连续三周扩大，就是趋势性的。
4. 纠正它需要消耗的是时间、人力，还是范围？三者中必须有一样让步。

这四个问题的价值在于，它能把"我们进度有点慢"这种模糊表述，转化成"关键路径浮动时间只剩 2 天，需要用加班或缩范围来吸收"的可决策信息。

5. 指标口径表（可直接抄）

指标打架的根源是口径不统一。下面这张表是我自己在用的版本，每个指标都写清楚了定义、计算方式、数据源和更新频率。

五、数据看板与最小采集机制

看板的复杂度不是越高越好。我见过把 40 个指标全堆在一屏的看板，结果没人看。真正被用起来的看板，通常不超过 12 个指标，但每个都有明确的责任人和更新节奏。

1. 结果指标怎么算才不失真

阶段完成率最容易失真。我的做法是给交付物分配权重，权重按预估人天来定。一个 20 人天的联调任务，权重就是 8 个 2.5 人天文档任务的 8 倍。

另外，交付物的完成度建议只允许填四个值：0%、30%、70%、100%。这比让团队填 0，100 的任意数字要可靠得多。原因很简单，人对"完成一半"的判断是不稳定的，但人对"能不能交付"的判断是稳定的。

2. 过程指标怎么算才可用

阻塞任务是过程指标里最容易被忽略、也最有价值的一个。我要求团队在任务卡住超过 24 小时后必须标记阻塞，并填写三个字段：阻塞原因、影响范围、预计解除时间。

返工率需要区分两类：需求变更引起的返工，和质量问题引起的返工。前者反映变更控制，后者反映质量债。把两类混在一起算，得到的数字既不能指导质量改进，也不能指导变更管理。

3. 数据采集的最小字段集

采集字段越多，填报成本越高，数据质量越差。我推荐的最小字段集是 9 个：任务名称、所属阶段、所属交付物、责任人、计划开始、计划结束、实际开始、实际结束、阻塞原因。

关键路径标记、优先级、前置依赖可以按项目复杂度决定是否增加。但请记住一条：任何需要人工额外维护的字段，三个月后都会变成空值。所以字段设计的第一原则是"能从已有数据推出来的，就不要新增字段"。

4. 谁填、谁审、何时冻结

我的规则是：执行人填实际状态，负责人审偏差原因，项目负责人审影响判断。三个角色各管一段，避免一个人既当运动员又当裁判。

冻结时间点很关键。我建议在每周进度会开始前 4 小时冻结数据。原因很实际：如果允许会上改数据，会议就会变成数据校对会，讨论不清真正的风险。数据一旦冻结，会上只讨论偏差和决策，不讨论数据本身。

六、四步偏差分析：从数字到原因

偏差分析是有固定顺序的，顺序错了，就会跳步。我总结的四步是：对比基线、分层定位、归因分类、影响判断。

1. 第一步：对比基线，先搞清楚偏差是多少

这一步只做一件事：把实际进度和基线做差。差的单位建议用天，不要用百分比。原因很实际，"完成率落后 8%"没人知道意味着什么，"关键路径落后 6 天"所有人都懂。

对比时要区分三种偏差：进度偏差（时间）、工作量偏差（人天）、范围偏差（交付物数量）。三者混在一起讲，讨论就会失焦。

2. 第二步：分层定位，哪个阶段、哪个交付物、哪个责任人

定位的顺序是：先看阶段，再看交付物，最后看任务。不要一上来就钻到任务级别，那会淹没在细节里。

我常用的判断口径是：如果一个阶段的偏差超过该阶段工期的 10%，就要单独开专题会；如果集中在某一个交付物上，那就是交付物级别的问题，找责任人；如果分散在多个交付物，那就是资源或需求层面出了问题。

3. 第三步：归因分类，按五类归因

归因必须分类，否则每次讨论都会变成"沟通不畅"。我固定用五类：需求（变更、理解偏差、验收标准不清）、资源（人力不足、技能不匹配、被抽调）、依赖（外部接口、上下游团队、环境、审批）、质量（缺陷、返工、技术债）、外部（政策、客户决策、供应商）。

归因的价值在于，不同类别对应的纠偏动作完全不同。资源问题调资源，依赖问题升级协调，需求问题走变更流程。归错类，纠偏动作一定错。

4. 第四步：影响判断，是否影响关键路径和总工期

这一步决定要不要升级。判断逻辑是：偏差任务在关键路径上吗？关键路径还剩多少浮动时间？偏差会吃掉多少浮动时间？

如果浮动时间足够吸收，就记入风险清单持续观察；如果浮动时间被清零，就必须立即启动纠偏，并进入管理层视野。

七、七步操作：从建基线到闭环纠偏

前面讲的是判断逻辑，这一节讲具体动作。我把它整理成七个步骤，每一步都写清楚动作、输出物和常见坑。

1. 步骤一：建阶段基线

动作：为每个阶段定义目标、交付物、验收标准、责任人、依赖关系、计划起止时间和退出条件。输出物是一张阶段基线表。

常见坑：把阶段目标写成"完成开发"这类废话。阶段目标必须可验收，比如"完成数据迁移接口联调，通过 200 条样本数据的双向校验，错误率低于 0.1%"。

2. 步骤二：定数据口径

动作：为每个指标定义计算方式、数据源、更新频率和责任人，形成指标口径表。输出物是口径表，前面第四节已经给出了模板。

常见坑：口径表只写结果指标，不写过程指标。结果是过程指标才是提前预警的来源，只写结果指标等于放弃了预警能力。

3. 步骤三：固定节奏采集

动作：把数据采集嵌进已有的会议节奏里，不要新增流程。每日站会更新阻塞状态，周会前更新计划与实际时间。

常见坑：为采集单独开发一套填报系统。我试过，三个月后填报率降到 30% 以下。最好的采集机制是"顺便填"，而不是"专门填"。

4. 步骤四：分层做看板

动作：做两层看板。项目负责人看阶段级结果指标和风险清单，执行层看任务级状态和阻塞情况。两层共用数据源，但展示粒度不同。

常见坑：所有人都看同一张大看板。结果管理层看到太多细节，执行层看到太多汇总，两边都不满意。

5. 步骤五：偏差归因

动作：按第六节的四步法做偏差分析，形成归因结论。输出物是一张偏差归因表，包含偏差项、偏差天数、归因类别、影响判断、责任人。

常见坑：归因结论写成"沟通不畅""资源紧张"这种无法执行的话。归因的检验标准是，看你能否从归因直接推出一个具体动作。

6. 步骤六：纠偏决策

动作：在五个动作里选：赶工、快速跟进、调资源、缩范围、升级决策。每个动作都要明确负责人、完成时间和验证方式。

常见坑：默认选赶工。赶工有明确的边际递减，加班的第 5 天新增产出通常不到第 1 天的一半，而且会推高返工率。当偏差在关键路径上且浮动时间已耗尽时，缩范围往往比赶工更划算。

7. 步骤七：跟踪复盘并更新基线

动作：跟踪纠偏动作到闭环，复盘效果，然后更新基线版本。输出物是更新后的基线表和一条版本变更记录。

常见坑：纠偏动作没有闭环跟踪。我自己的规则是，任何纠偏动作必须有下一次检查时间，没有检查时间的动作等于没做。

八、进度会怎么开：会前数据包、会中议程、一页纸汇报

阶段进度管理的成效，最终要落在进度会上。我见过太多进度会开成"逐项念进度"，两小时过去，没有一个决策。

1. 会前：数据包必须提前发

会前 4 小时冻结数据，提前 2 小时把数据包发给参会人。数据包只包含三样东西：阶段看板快照、偏差清单、需要决策的事项清单。

不要发甘特图全图，也不要把任务列表全贴上去。会前数据包的作用是让参会人带着判断进会，而不是带着问题进会。

2. 会中：议程按偏差，原因，影响，方案，决策走

我固定的议程是五段：第一段过偏差清单（10 分钟），第二段讲归因结论（15 分钟），第三段讲影响判断（10 分钟），第四段讨论纠偏方案（20 分钟），第五段做决策并明确责任人（15 分钟）。

整场控制在 70 分钟以内。超过这个时长，讨论质量会明显下降，而且会挤占执行时间。

3. 一页纸进度汇报模板

我用的模板只有 6 个区块，可以截图直接发给客户或管理层：

• 当前阶段与基线时间：阶段三，基线 3 月 4 日，4 月 12 日
• 里程碑状态：3 个里程碑，2 个按期达成，1 个预计延期 5 天
• 关键偏差：数据迁移联调延期 5 天，归因外部依赖
• 影响判断：关键路径浮动时间由 8 天降至 3 天，暂不影响总工期
• 需要决策：是否提前引入第三方接口团队现场支持
• 下一步动作：责任人 × 完成时间 × 验证方式

这 6 个区块看起来简单，但它强制你把"数据，判断，决策"三件事写清楚。写不清楚的汇报，本质上就是还没想清楚。

九、案例演示：一个虚拟软件交付项目的阶段纠偏

下面这个案例是我根据多个真实项目抽象出来的情景模拟，人员、时间和数据均为示意，用于演示分析路径，不代表任何具体企业的真实数据。

1. 场景设定

某软件交付项目，团队 80 人，阶段三为"系统集成与数据迁移"，基线工期 5 周，关键路径浮动时间 8 天。第三周周一做数据快照。

2. 数据发现

整体完成率 58%，看起来在正常区间。但三个异常信号同时出现：关键路径完成率只有 33%，与整体完成率相差 25 个百分点；数据迁移接口联调任务阻塞 9 天未解除；测试环境准备任务责任人字段为空。

按第六节的四步法分析：偏差集中在集成和迁移两个交付物上（分层定位）；归因是外部依赖加资源空缺（归因分类）；联调任务在关键路径上，浮动时间已被吃掉 5 天（影响判断）。

3. 纠偏动作与结果

我们做了四个动作：把接口联调和技术方案评审改为并行，回收 2 天；把报表模块验收后置到阶段四，回收 3 天；从另一个项目临时借调 2 名数据工程师，缩短联调时间；把外部接口延迟升级到双方管理层，争取到供应商现场支持。

最终结果：净延期从 13 天压缩到 8 天，关键路径浮动时间从 3 天恢复到 5 天，阶段四的范围扩大了一项，但总工期未受影响。这个案例的关键不在动作本身，而在于所有动作都是从归因结论直接推导出来的。

4. 工具层面的落地方式

上面这套方法要跑起来，工具需要满足三个条件：能承载阶段和交付物层级，能记录任务的实际起止时间和阻塞原因，能按阶段出报表而不是只出任务列表。

在服务中大型企业、100 人以上组织的项目管理场景里，PingCode 这类平台通常会把需求、迭代、测试、缺陷放在同一条链路上，阶段和里程碑可以作为独立层级管理，实测比较适合需要跨部门对齐的交付型项目。对于有数据合规要求的企业，PingCode 支持私有化部署，这点在金融、制造、政企类项目里是硬性前提。

另一个常见场景是从既有的海外工具迁移过来。我参与的两次迁移都涉及甘特图、自定义字段和工作流的对应关系，PingCode 提供 Jira 平滑迁移能力，字段映射和历史数据的保留程度是迁移成败的关键，建议在迁移前先做一轮字段盘点和样例验证，不要一次性全量切换。

如果团队正在做国产替代评估，我建议的验证顺序是：先验证阶段与里程碑的层级表达能力，再验证数据导出和报表能力，最后验证权限与私有化部署条件。顺序反了，很容易选到一个"功能很多但阶段管不起来"的工具。

十、不同情况下的行动建议与取舍

方法不能一套打天下。不同类型的项目，阶段进度的管理重点和取舍点完全不同。

1. 研发型项目：优先管返工和集成

研发型项目的阶段风险集中在集成和返工。建议把"返工率"和"集成任务完成率"作为阶段核心指标，把联调、集成类任务强制排到阶段前 40% 的时间窗口。

取舍点在于：如果需求还在变，就不要追求精确的完成率，改用"交付物是否可用"来判断阶段状态。在需求不稳定的环境里追求精确进度，本身就是一种浪费。

2. 交付型项目：优先管依赖和变更

交付型项目有合同节点约束，阶段风险主要来自外部依赖和需求变更。建议建立依赖清单，每个外部依赖都要有责任人、承诺时间和备选方案。

取舍点在于：当客户要求插入新需求时，必须在"延期、加人、减范围"三者中选一个，不要三个都答应。三个都答应的项目，最后一定三项都保不住。

3. 探索型项目：优先管假设和验证节点

探索型项目不适合用完成率管理，因为没有稳定的基线。建议改为阶段假设验证制：每个阶段定义一个待验证假设和一个验证标准，通过了就进入下一阶段。

取舍点在于：探索型项目要接受"阶段可能被整体推翻"，所以不要投入过多资源去维护精细的进度数据，把精力放在验证速度上更有价值。

4. 多项目并行：优先管关键角色的负荷

多项目并行时，阶段延期的主要原因常常不是任务多，而是关键角色被多个项目同时占用。建议按角色做负荷视图，超过 100% 负荷的角色必须提前两周预警。

取舍点在于：关键角色的负荷不能靠加班解决，只能靠排优先级或补人。如果两条都做不到，那就只能接受某个项目的阶段延期，并提前告知相关方。

5. 四个必须做的取舍

十一、常见问题 FAQ

1. 阶段完成率 100% 就代表阶段安全吗？

不代表。完成率是自报数据，需要交叉验证。我的验证方式是看三个东西：交付物是否全部通过验收标准、关键路径任务是否全部关闭、返工任务是否已清零。三项都满足，完成率才有意义。

2. 阶段延期了，是不是一定要加班？

不一定，而且加班往往是效果最差的一个选项。加班有明确的边际递减，还会推高返工率。优先考虑的顺序是：缩范围、调资源、快速跟进、赶工、升级决策。加班应该排在后面，而不是第一个想到的动作。

3. SPI 偏低是不是就意味着项目要失败？

不是。SPI 依赖基线和工作量估算的可靠性。如果基线本身被反复修改，或者 EV 的估算本来就不可信，SPI 的参考价值非常有限。我建议把 SPI 当作趋势指标看，而不是当作判断指标。

4. 引入项目管理工具能自动解决阶段进度问题吗？

不能。工具解决的是数据采集和展示效率，解决不了阶段定义不清、归因不准、决策不及时这三个问题。我的经验是：先定门禁和口径，再选工具，顺序反了就会买一堆用不上的功能。

5. 团队不愿意标记阻塞任务怎么办？

这通常不是意愿问题，而是机制问题。如果标记阻塞会带来质疑和压力，团队自然选择沉默。我的做法是把"上报阻塞"列入正向评价，并在进度会上公开感谢提前暴露风险的成员。只有让上报阻塞变成安全的行为，阻塞数据才会真实。

6. 阶段划分多少个比较合适？

我的经验是 4，6 个阶段比较实用。少于 4 个，阶段太长，问题暴露太晚；多于 6 个，门禁评审成本过高，团队会把评审当形式。具体数量还是要按项目复杂度和合同节点来定。

7. 多小的项目还需要做阶段门禁吗？

两周以内的小项目，可以简化门禁，但至少要有两个：开工门禁（交付物和验收标准明确）和交付门禁（验收通过）。中间的阶段评审可以合并。门禁的核心作用是防止"没想清楚就开工"和"没做完就交付"。

十二、总结与下一步行动

回到最开始那个 91% 完成率却延期的项目。问题从来不是数据不够多，而是数据没有指向决策。阶段进度管理的本质，是用最少的数据回答三个问题：这个阶段能不能退出、偏差会不会影响总工期、我现在必须做什么决策。

我自己的独特判断有三条，也是这篇文章最想留给你的东西。

第一，阶段进度的最小管理单元是门禁，不是任务。没有退出条件的阶段，不叫阶段，只叫时间区间。

第二，完成率是最不可信的单一指标。它的价值只在于触发追问，而不在于给出结论。真正决定阶段健康度的是关键路径完成率、阻塞天数和返工率这三项组合。

第三，纠偏的质量取决于归因的质量。归因错了，动作一定错；归因对了，动作往往只需要两三个就能把偏差收回来。

下一步我建议你按这个顺序做四件事。第一，把当前项目的阶段基线补全，重点补退出条件和验收标准，一天之内能完成。第二，从现有工具里导出最近三周的原始数据，人工算一次关键路径完成率和整体完成率的差值，看是否超过 20 个百分点。第三，把偏差最集中的三个交付物做一次五类归因，形成一张归因表。第四，在下次进度会前 4 小时冻结数据，按"偏差，原因，影响，方案，决策"五段议程开一次会，把时长控制在 70 分钟以内。

做完这四件事，你会得到两样东西：一张属于你自己项目的阶段进度看板，以及一套可以持续运转的纠偏闭环。剩下的，就是按周重复它，并在每个阶段结束时更新基线版本。