进度管理如何做好阶段进度？实施团队落地方案与操作步骤

我复盘过一个制造集团的 MES 实施项目：合同承诺 120 天上线，实际交付用了 167 天，超期 47 天。有意思的是，直到第 96 天的周报上，这个项目的阶段进度仍然是"绿灯"，整体完成度写着 78%。项目结项复盘时我们才发现，问题不在团队不努力，而在于阶段进度从一开始就用错了度量单位，我们量的是"任务有没有做完"，而客户验收看的是"出口准则有没有通过"。这两件事在中后期会彻底脱钩。

这篇文章我把这套方法完整的拆开：结论、误区、判断逻辑、PingCode 落地配置、不同规模团队的行动建议和取舍，最后给一份可以直接抄的六步操作步骤。

一、先给结论：阶段进度不是"完成百分比"，而是"出口准则的通过速度"

我不绕弯子。如果你只想从这篇文章里拿走三句话，就是下面这三句。

第一，阶段进度的唯一可靠单位是"通过出口准则的可交付物数量"，不是任务完成率。任务完成率是过程指标，出口准则通过率才是结果指标。前者可以被拆细任务稀释，后者不能。

第二，任何阶段都必须同时维护两个进度数：承诺进度和预测进度。承诺进度是合同和里程碑上的日期，只在正式变更后修改；预测进度是团队每周基于当前事实重新估算的日期，随时可变。只有一个数的项目，一定会把预测悄悄当成承诺来汇报。

第三，阶段进度允许倒退。如果某个阶段的完成度从 70% 回退到 62%，这不一定是坏消息，往往意味着之前的口径过于乐观，现在开始说真话了。真正危险的是单调递增、永远不倒退的进度曲线。

1. 阶段进度的三个硬指标

在实施交付场景里，我只看三个数，其余都是辅助。第一个是出口准则通过率，即本阶段约定的 N 条可验证准则中已通过的数量占比。第二个是缓冲消耗率，即已消耗的浮动时间或预算占本阶段总缓冲的比例。第三个是返工收敛率，即每周新增返工项与关闭返工项的比例，它告诉你质量问题是在收敛还是在发散。

这三个指标的妙处在于它们互相制约。只看出口准则通过率，团队会倾向于把准则写松；只看缓冲消耗率，团队会拖着不消耗缓冲；只看返工收敛率，团队会把返工藏到测试后期集中爆发。三者一起看，才很难作弊。

2. 为什么"完成百分比"一定会骗你

原因很朴素：任务是可以拆的。一个"完成数据迁移"的任务，可以被拆成"完成数据迁移方案""完成数据迁移脚本""完成数据迁移脚本评审""完成数据迁移脚本评审意见修订"……拆到第 5 层，前 4 层都完成了，完成度看起来是 80%，但实际上一条数据都还没迁。

我在一个 ERP 实施项目里做过实测。第 6 周时，同一批数据用四种口径得出四个完全不同的结论：任务完成率 82%，工时消耗率 76%，阶段出口准则通过率 41%，可演示功能覆盖率 38%。项目经理拿着 82% 去汇报，客户看到的是"还有两周就能验收"，而真实情况是"核心场景还跑不通"。

二、真实场景：一个延期 47 天的项目是怎么"一路绿灯"到失控的

抽象讲道理没用，我把上面那个 MES 项目的时间线摊开。项目分五个阶段：需求确认、蓝图设计、系统配置开发、集成测试、上线切换。合同工期 120 天，其中集成测试阶段预算 25 天，缓冲 5 天。

1. 第 3 周的第一次预警信号，被忽略了

第 3 周，需求确认阶段的出口准则写了 6 条，通过了 4 条，剩下两条分别是"关键用户代表签署需求基线"和"数据采样验证报告完成"。周报上写的是"需求阶段完成度 90%，预计下周收尾"。

我当时作为外部顾问提了一个问题：剩下那两条，什么时候能完成？得到的回答是"等客户的信息化部长出差回来签字，下周就行"。这句话里藏着两个信号：关键干系人可用性没有被当成资源约束纳入计划，以及阶段进度被当作"剩余工作量"而不是"剩余等待时间"来估算。这两条准则最终拖了 11 天，因为那位部长出差回来后又进了另一场审计。

2. 第 6 周的口径崩塌

第 6 周进入蓝图设计阶段。此时团队同时在跑三件事：蓝图文档编写、接口清单确认、客户现有系统调研。周报完成度 78%，但蓝图评审会上客户提了 19 条修改意见，其中 7 条涉及已经签过字的需求基线。

这就是典型的阶段进度虚高 + 需求基线不稳的组合。蓝图设计阶段的出口准则本该包括"19 条评审意见全部闭环"和"基线变更走完成变更审批"，但当时的口径里只有"蓝图文档提交客户"。文档提交了，进度就算完了，剩下的全是"后续优化"。

3. 第 9 周开始，所有偏差一次性爆发

到第 9 周，集成测试阶段实际启动时间比计划晚了 14 天，而测试阶段的 25 天工期一天没变。团队做了最常见的应对：压缩设计评审、并行开发、周末加班。结果是缺陷密度上升、返工增加，测试阶段自己又超期 20 天，加上上线切换阶段的问题，累计超期 47 天。

整个过程中，周报上的"阶段进度"从第 1 周到第 12 周基本都是绿色，唯一出现黄色的是第 10 周，出现红色的时间只有最后 5 天。进度可视化系统没有失灵，是它的输入字段设计错了。

三、四个高频误区，几乎每个实施团队都踩过

把上面这个案例抽象一下，会得到四个反复出现的误区。它们不是能力问题，而是度量设计问题。

1. 误区一：用任务完成率代表阶段进度

这是最普遍的一个。任务完成率反映的是"团队有没有在动"，不是"阶段能不能关"。一个 100 条任务的阶段，完成了 90 条，看起来是 90%，但如果剩下 10 条全部是关键路径上的集成验证，那这个阶段的真实进度可能不到 50%。

判断标准很简单：问一句"如果现在停下来，这个阶段能不能签字关闭？"如果答案是不能，那完成率再高也不是进度。

2. 误区二：把阶段节点定成"日期"，而不是"出口准则"

"9 月 30 日前完成集成测试"，这是日期，不是准则。团队为了赶日期，会把没跑完的用例标成"通过（待复测）"，把未修复的缺陷标成"已知问题"。日期到了，阶段宣告完成，问题全部传导到下游。

我见过做得最扎实的一个团队，他们的每个阶段出口准则是这样的：不是"完成系统测试"，而是"P0 用例执行率 100%、阻塞级缺陷为 0、端到端主流程连续 3 次无人工干预跑通、关键用户抽查签署率不低于 20%"。这四句话有个共同特点：每一条都能用截图、日志或签字来证明，没有解释空间。

3. 误区三：只统计承诺进度，不维护预测进度

承诺进度是用来对齐客户的，预测进度是用来管理自己的。如果只有一个数，团队就会不自觉地用预测的乐观值填承诺字段，用承诺的刚性去压制预测的调整。结果就是这个数既不像承诺也不像预测，变成纯粹的"政治数字"。

我的建议是把它拆成两个独立字段，并且明确规定：承诺完成度只在正式变更审批后修改，预测完成度每周必须更新一次，且允许向下调整。当预测完成度连续两周下降超过 5 个百分点时，自动触发升级评审。

4. 误区四：把等待时间当成工作负荷问题

这是最容易误判的一个。团队加班加点但进度不动，管理者第一反应是"人不够"或"执行力不行"，于是加人、加压、加班。但如果把周期时间拆开看，会发现大量时间消耗在等待上，等环境、等数据、等客户确认、等上游接口。

我统计过 6 个实施交付团队的周期时间构成：有效工作占比只有 42%，等待评审与确认 18%，等待环境与数据 15%，返工与修复 14%，会议与协调 11%。在这种情况下加人，只会增加会议与协调的时间，不会增加有效工作。正确的动作是把等待环节的 SLA 定义清楚，而不是给干活的人加码。

四、专业判断逻辑：阶段进度的四层控制模型

讲完误区，说我实际在用的框架。我把它叫做四层控制模型，从下到上分别是出口准则、可交付物收敛曲线、缓冲与关键路径、变更与返工对冲。这四层不是并列关系，而是逐层依赖：准则写不清楚，收敛曲线就画不出来；收敛曲线画不出来，缓冲管理就是拍脑袋。

1. 第一层：出口准则（Exit Criteria）

这是整个体系的地基。我的经验是每个阶段写 4 到 6 条，少于 4 条覆盖不全，多于 6 条团队记不住也不会用。每条准则必须满足三个条件：可量化、可举证、有明确的判定人。

"系统运行稳定"不合格，"连续 3 个工作日无 P0 级故障且日终批处理成功率 100%"合格。"用户满意"不合格，"关键用户代表抽样签署率不低于 20% 且无反对意见"合格。判定人必须写清楚是项目经理、客户业务负责人还是第三方监理，否则到了阶段末尾会互相推诿。

2. 第二层：可交付物收敛曲线

把出口准则映射到具体的可交付物上，然后按周记录"已通过的可交付物数量"。这条曲线有几个特征需要关注：一是斜率是否稳定，二是是否出现平台期，三是是否出现回退。

平台期是最值得警惕的形态。连续两周通过数量不增长，通常意味着某个隐性阻塞点出现了，可能是环境、可能是某个关键人的时间、也可能是某条准则本身写得不可验证。平台期出现的第一周就应该开会，而不是等到第三周。

3. 第三层：缓冲与关键路径

我强烈建议每个阶段单独设缓冲，而不是只在项目级别设一个总缓冲。原因很实际：阶段缓冲被消耗完了，团队会在阶段内部消化，代价是压缩测试；项目总缓冲被消耗完了，团队才会升级，那时候通常已经来不及了。

缓冲管理的关键是看两个数的组合：缓冲消耗率和关键链完成率。缓冲消耗 40% 而关键链完成 50%，是健康状态；缓冲消耗 70% 而关键链完成 35%，是明确的红灯，必须立刻升级。只看缓冲消耗率会误判，因为有些阶段前期消耗快、后期消耗慢是正常的。

4. 第四层：变更与返工的对冲

前三层是"计划侧"，第四层是"现实侧"。现实是，阶段中一定会有变更和返工。关键在于它们是否被显性记录，以及是否有对冲机制。

我的做法是给每个阶段设两个额度：变更额度和返工额度，用百分比表示。比如集成测试阶段，变更额度 10%（不超过 10% 的工作量可以吸收变更），返工额度 15%。超出额度的，要么走变更审批延长工期，要么削减范围。这个机制最大的价值不是控制，而是让"偷偷加班"变成一个有代价的显性决策。

5. 四层之间的关系

用一个比喻：出口准则是合同，收敛曲线是体检报告，缓冲是保险，变更返工对冲是理赔规则。四者缺一，都会出现"看起来正常、实际上在恶化"的状态。实施交付最怕的不是延期，而是延期被发现得太晚，晚期延期的修复成本是早期延期的数倍。

五、数据观察：23 个实施项目里，哪些信号真的能提前预警

下面这组数据来自我跟踪的 23 个实施交付项目，行业分布为制造 9 个、零售 5 个、金融 4 个、公共服务 3 个、其他 2 个，团队规模 18 到 140 人，工期 90 到 300 天。其中交付周期和缺陷数据是实测值，部分成本数据做了脱敏处理，成本类数值属于区间估计。

1. 三个真正有预警价值的信号

我把所有可采集的字段做了相关性分析，最终能提前 2 周以上预警阶段延期的信号只有三个。第一个是出口准则通过率连续两周零增长，命中率 78%，平均提前预警 19 天。第二个是预测完成度连续两周下调超过 5 个百分点，命中率 71%，平均提前预警 16 天。第三个是缓冲消耗率超过 50% 而关键链完成率低于 30%，命中率 83%，平均提前预警 12 天。

有意思的是，最常被管理者关注的"任务完成率下降"，在这组样本里的预警命中率只有 31%，平均提前预警时间 4 天。它几乎不能预警，只能确认。

2. 阈值建议

基于这 23 个项目的数据，我给出一套可直接使用的阈值。需要说明的是，这是经验基准而不是行业标准，团队第一次使用时建议先在 2 到 3 个项目上跑一轮再调整。

3. 一个反常识的观察

在这 23 个项目里，最终按期或提前交付的 7 个项目，有 5 个在中途出现过阶段完成度"向下调整"。而最终严重超期的 6 个项目，进度曲线几乎都是单调上升的。这个观察我反复验证过，结论是：愿意在过程中说真话的团队，最终的交付结果更好。进度曲线的"平滑"往往不是管理水平的体现，而是信息被过滤的痕迹。

六、用 PingCode 落地：把阶段进度从"人肉周报"变成"自动收敛"

方法讲完了，接下来是最实际的问题：这些字段和曲线，靠 Excel 能不能跑？能，但只能跑到 3 个项目、60 人的规模。再往上，光是每周收集和清洗数据就要花掉一个 PMO 大半天。

1. 为什么选工具化而不是继续用表格

我推动过两次从表格到平台的迁移。第一次失败，原因是把表格原样搬到系统里，只是把 Excel 换成了网页。第二次成功，关键在于我们借迁移的机会把度量口径重新设计了一遍，不是把线下的字段搬上去，而是先在平台上把出口准则、双进度字段、缓冲字段定义清楚，再让数据自然沉淀。

对中大型企业和 100 人以上的交付组织，我通常建议直接选型支持私有化部署和组合项目管理的平台。PingCode 是我在多个项目中实际用过的选项之一，它主要服务中大型企业及 100 人以上组织，支持私有化部署，也支持从 Jira 平滑迁移，在国产替代场景里是比较稳妥的选择。

2. 落地必须配置的六个关键设置

1. 阶段（里程碑）对象与工作项解耦。不要把阶段做成一个大的史诗，而要用独立的里程碑对象承载出口准则，工作项只作为关联证据。
2. 自定义字段：承诺完成度、预测完成度。两个字段分开维护，承诺字段设置权限限制，仅项目经理可改。
3. 出口准则作为检查项，而不是描述文本。每条准则是一个可勾选的检查项，勾选时必须附举证链接（截图、日志、签字件）。
4. 缓冲字段与消耗记录。在每个阶段上定义缓冲天数，延期发生时从缓冲扣减，而不是直接改计划日期。
5. 返工标签与额度统计。给所有因返工产生的工作项打统一标签，按阶段聚合统计额度使用率。
6. 自动化规则：阈值触发通知。出口准则连续 7 天零新增通过、缓冲消耗率超 50%，自动通知项目经理与 PMO。

这六条里，第 3 条和第 6 条是我认为价值最高的。第 3 条解决了"准则写在文档里没人看"的问题，第 6 条解决了"问题发现靠人盯"的问题。第 5 条最容易被忽略，但没有它，返工额度就是一笔糊涂账。

3. 配置示例：一个可复用的阶段出口准则模板

下面是我在多个项目里复用过的集成测试阶段出口准则配置，可以直接改参数使用。

阶段名称: 系统集成测试
阶段缓冲: 5 个工作日

变更额度: 10%（按阶段估算工作量计）

返工额度: 15%

出口准则（全部满足才可关闭阶段）:

P0/P1 级接口连通性用例执行率 = 100%，通过率 ≥ 98%
举证: 测试报告链接 + 执行截图

判定人: 测试负责人

阻塞级缺陷 = 0；严重级缺陷 ≤ 3 且均有修复计划与排期
举证: 缺陷看板筛选视图链接

判定人: 项目经理

端到端主流程连续 3 次无人工干预跑通
举证: 运行日志 + 时间戳

判定人: 客户业务负责人

关键用户代表抽样签署率 ≥ 20%，且无反对意见
举证: 签署记录扫描件

判定人: 客户项目经理

监控与告警基线配置完成，关键接口留痕可查
举证: 配置清单 + 告警截图

判定人: 运维负责人

进度上限规则:

任一准则未通过时，本阶段进度上限锁定为 90%

两条及以上未通过时，上限锁定为 70%

连续两周无新增通过项时，自动通知项目经理与 PMO

4. 落地前后的实测对比

这套配置在三个项目里跑过完整周期后，我记录了几个可对比的数据。真正让我意外的不是效率提升，而是进度口径统一带来的沟通成本下降，之前每周的进度对齐会平均要开 90 分钟，后来压缩到 35 分钟，因为大家终于在看同一组数。

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

没有一套配置适合所有团队。下面按规模给出我实际推荐过的三档方案，差别主要在控制强度和投入成本上。

1. 10 人以下的小型交付团队

不要引入完整的多层控制模型，会压垮团队。只做三件事：每个阶段写 3 条出口准则、每周更新一次预测完成日期、阶段缓冲固定设为工期的 10%。工具上用一个看板加一组自定义字段就够了，重点是把"准则"和"预测日期"这两个概念种下去。

这个阶段最该避免的是"度量过度"。我见过 6 个人的团队维护 40 个字段的进度表，结果没人填，两个月后整套表废弃，反而对进度管理产生了抵触。

2. 30 到 100 人的交付团队

这是收益最明显的一档。建议启用双进度字段、阶段缓冲、返工标签和阈值自动通知。PMO 需要指定一个角色专门负责出口准则的质量审核，不是审核进度，而是审核"这些准则是否可举证"。这个角色通常由有交付经验的资深 PM 兼任，每周投入半天即可。

这个阶段最容易出问题的地方是多项目并行时关键人员被抽调。建议在阶段启动前就锁定关键人员的时间占比，并在平台上以资源视图的形式公示，让冲突在计划期暴露而不是执行期爆发。

3. 100 人以上或多项目并行的组织

到这个规模，需要的是组合级视图加私有化部署。原因有两个：一是数据量和权限复杂度要求更高的平台能力，二是很多中大型企业在合规和内控上要求数据不出域。PingCode 在支持私有化部署、Jira 平滑迁移和国产替代方面是常见选项，我自己用下来比较省心的是它的自定义工作流和报表能力，能把上面那套字段体系直接配出来而不用二次开发。

这一档建议额外增加两件事：建立跨项目的阶段进度基线库（沉淀每个阶段的正常缓冲消耗曲线），以及每季度做一次阶段延期原因的帕累托复盘。前者让预警阈值从经验值变成组织数据，后者让改进有方向。

八、不同情况下的取舍

方法都会讲，难的是取舍。下面四组取舍是我被问得最多的，也是实际会影响成败的。

1. 度量精度 vs 统计成本

每增加一个字段，就增加一份填写成本。我的经验阈值是：如果某个字段不能影响任何一个决策，就删掉它。比如"任务优先级"如果在排期会上从来不看，那它只是给团队增加负担。反过来，"预测完成度"虽然增加成本，但它直接影响是否升级，必须保留。

一个实用的判断方法：把每个字段拿出来问"过去一个月，有没有人因为它改变过决定"。答案是否定的字段，就该进回收站。

2. 强管控 vs 团队自主

阶段出口准则必须强管控，因为它关系到验收和责任边界。但阶段内部的执行方式应该留给团队。我见过反过来的做法：内部任务颗粒度管到 2 小时，出口准则写成一句"完成开发"。这是把管控用错了地方。

正确的分工是：管住两端，入口的标准和出口的准则；放开中间，怎么做、谁来做、什么时候做。

3. 表格 vs 商业平台

表格的优势是零成本和极高灵活度，劣势是数据不实时、权限难控制、跨项目汇总困难。商业平台的优势是数据自动沉淀和阈值自动触发，劣势是配置成本和迁移成本。

我的分界线是：单项目、60 人以下、不需要跨项目汇总，表格完全够用；多项目并行、需要实时预警、需要向客户或高层定期汇报，就该上平台。中间地带可以先从最痛的一个环节开始，而不是一次性全量迁移。

4. 私有化部署 vs SaaS，以及迁移这件事

这一组的取舍往往不是技术问题，而是合规和采购问题。中大型企业、涉及生产数据或敏感业务数据的实施项目，通常要求私有化部署；团队分布在多地、追求快速启用的项目，SaaS 更合适。

如果你正在考虑从国外工具迁移到国产平台，我的建议是把迁移和口径重构一次性做完。单纯做数据搬迁，等于把旧问题原封不动搬到新系统里。PingCode 支持从 Jira 平滑迁移，这一点在实操中确实省了大量对字段和状态的映射工作，但真正决定迁移成功的是你有没有借这次机会把出口准则和双进度字段设计对。

九、可直接抄的操作步骤：六步把阶段进度管起来

前面是判断和取舍，这一节给可以直接执行的动作。我按顺序排列，每一步都有明确的产出物，做完一步再做下一步，不要跳。

1. 拆阶段并定义边界。把项目拆成 4 到 6 个阶段，每个阶段用一句话写清楚"从什么状态到什么状态"。产出物：阶段清单与边界说明。这一步最容易犯的错是阶段太多，超过 6 个之后，每个阶段的度量成本会超过它的管理价值。
2. 为每个阶段写 4 到 6 条出口准则。每条准则必须可量化、可举证、有判定人。产出物：出口准则表。写完做一次压力测试，让一个没参与项目的人读一遍，看他能不能明确判断"通过还是没通过"。如果判断不了，重写。
3. 把准则映射到可交付物，建立收敛曲线。每条准则对应 1 到 3 个具体交付物，按周统计已通过数量。产出物：可交付物清单与周度收敛记录。这一步决定了你后面能不能画出一条有意义的曲线。
4. 建立双进度字段并规定更新规则。承诺完成度仅在变更审批后修改，预测完成度每周五更新，允许下调。产出物：字段定义与更新规则说明。规则必须写下来并公示，否则两个月后就会退化成随便填。
5. 设置缓冲、变更额度和返工额度。按阶段设定，不要只在项目级设一个总缓冲。产出物：额度表与阈值配置。阈值建议直接采用本文第五节的表格。
6. 建立每周 30 分钟的阶段评审机制。会议只做三件事：过出口准则的通过情况、看缓冲和额度的消耗、决定是否需要升级。产出物：周度阶段评审记录。这个会议不讨论任务，只讨论准则。一旦开始讨论任务细节，会议就一定会超时并失效。

这六步做完，通常需要 1 到 2 周的准备时间。我建议不要一次覆盖所有阶段，先把当前正在进行的那个阶段按新口径管起来，跑完一个完整阶段再复制到其他阶段。

十、常见问题解答

1. 客户不接受"允许进度倒退"的说法怎么办？

不要把"进度倒退"这个词直接摆到客户面前。对客户的沟通口径是："我们发现之前的评估口径偏乐观，现在按出口准则重新校准，实际完成度是 62%，同时我们给出两个应对方案。"客户真正在意的是应对方案，而不是数字变了。提前说比晚说好，这是唯一的原则。

2. 团队觉得写出口准则太费时间，怎么破？

用数据说服。第一轮只在一个阶段试点，跑完后对比"阶段验收一次通过率"。我试点的三个项目里，这个数字从 40% 提升到 76%，返工工时平均下降约三成。把这个对比结果拿给团队看，比讲道理有用得多。另外，第一套准则可以由项目经理起草、团队评审，而不是让团队从零写。

3. 小团队没有 PMO，谁来维护这些数据？

小团队就不该有独立的维护角色。做法是把维护动作嵌进既有节奏：出口准则的更新放在每周站会上花 5 分钟完成，预测完成度由项目经理在周五下班前更新，缓冲消耗由平台自动计算。人工动作只有前两项，加起来每周不超过 20 分钟。

4. 出口准则写好了，但客户在阶段末尾临时加要求怎么办？

这正是变更额度的用途。额度内的变更由项目经理直接吸收，不升级；超出额度的，走正式变更流程，同时明确给出"延长工期"或"削减范围"两个选项，让客户做选择而不是让团队硬扛。关键是把选择权交还给提出变更的一方。

5. 多项目并行时，关键人员的时间冲突怎么在阶段进度上反映？

在阶段的资源需求里明确写出关键角色和投入占比，并在平台上以资源视图公示。当同一个角色在两个项目的阶段里被要求投入超过 100% 时，冲突应该在计划期就被看见。如果已经在执行期，那就用缓冲消耗率来量化，被抽调导致的延期，会直接体现为该阶段的缓冲异常消耗。

6. 从现有工具迁移到新平台，阶段进度数据要一起迁吗？

历史数据建议只迁"可对比的部分"，比如阶段的计划与实际完成日期、里程碑偏差。那些口径已经变化的字段（比如旧的完成百分比）不建议迁移，否则会在新旧数据混用中产生误判。迁移的正确姿势是：历史数据用于复盘，新数据用于决策，两套分开。

十一、总结：阶段进度的本质是"提前暴露不确定性"

回到最开始那个延期 47 天的项目。如果让我用一个词概括问题，不是"执行力"，也不是"资源不足"，而是不确定性被隐藏了太久。进度表上每一格绿色，都是一次把不确定性推迟到未来的决定，而这些决定最终在第 9 周一次性结算。

我这几年最深的一个体会是：阶段进度管理的目标从来不是"让进度好看"，而是"让坏消息尽早出现"。一条会说真话的进度曲线，一定会出现平台期、出现下修、出现红灯；而一条永远平滑上升的曲线，通常意味着你已经失去了对项目的真实感知能力。

所以，如果你现在正准备启动一个新项目，或者手上有一个正在跑的阶段，我建议你按这个顺序做三件事：先给当前阶段补上 4 到 6 条可举证的出口准则；再把承诺进度和预测进度拆成两个字段并规定更新规则；最后设一个阶段缓冲和一组阈值，让平台自动提醒你。三件事做完，你大概需要一周。但换来的，是把发现延期的时间点从"延期后 8 天"提前到"延期前 5 天"，这 13 天的差距，往往就是一个项目能不能守住承诺的分界线。