去年我接手一个已经延期三周的中台重构项目，复盘时发现一个反常识的事实：团队里没有一个人偷懒，研发平均每天提交代码的时间甚至比正常迭代还长，但进度就是这样一点点滑出去了。问题不在执行，而在我们从来没有在偏差还只有一两天的时候把它当回事。真正拖垮项目的从来不是某一次大延期，而是那些被"下周应该能赶上"掩盖掉的小偏差。
这篇文章不谈空泛的项目管理理论，我想把过去几年在十几个迭代里踩过的坑、用过的公式、做过的判断逻辑完整拆开讲。核心结论先放在这里：进度偏差管理的关键不在"纠偏"，而在"识别偏差的速度"和"判断偏差的优先级"，产品经理真正要做的，是让偏差在还只有一天两天的量级时就被看见、被分类、被处理。后面会依次讲清楚偏差怎么算、出现了怎么判断、具体怎么纠、以及比纠偏更重要的前置控制。
一、先给结论：进度偏差管理的核心是"早识别、准分类、快取舍"
很多产品经理一提到进度偏差，第一反应是"要不要加班赶一赶"。这个反应本身就把问题引向了错误方向，因为加班只能解决执行层面的能力不足，解决不了需求膨胀、依赖阻塞、优先级混乱这些真正的根因。
我自己总结出来的偏差管理三原则是这样：第一，偏差必须在发生后的24小时内被量化，而不是等到周会才发现；第二，偏差要按"是否在关键依赖链上"分类，而不是按"哪个模块延期了"分类；第三，处理偏差的本质是在范围、时间、质量、资源四个约束里做取舍，不取舍就等于默认接受所有约束同时崩塌。
这三点看起来简单，但要真正落地，需要一套可操作的判断框架和一套能跑的预警机制，这也是我这篇文章要展开的重点。
二、进度偏差到底怎么算：从挣值公式到迭代语言
先解决一个基础问题：偏差到底怎么量化。很多产品经理对进度偏差的判断完全靠感觉，"感觉有点慢""看起来能赶上"，这种判断方式在三个团队以上协作的项目里几乎必然失效。
1. 两个公式，产品经理必须记住
经典项目管理里有两个指标是绕不开的：进度偏差（SV）和进度绩效指数（SPI）。它们的计算公式如下：
进度偏差 SV = EV – PV
进度绩效指数 SPI = EV / PV
其中：
EV（Earned Value，挣值）= 实际完成的工作量对应的计划价值
PV（Planned Value，计划值）= 截止当前时点计划应完成的工作量价值
判断规则：
SV > 0 且 SPI > 1 → 进度超前
SV = 0 且 SPI = 1 → 进度符合计划
SV
这里要澄清一个常见混淆：SV 反映的是偏差的绝对量，SPI 反映的是偏差的相对比例。一个 100 人天的项目滞后 10 人天（SV = -10，SPI ≈ 0.9）和一个 10 人天的项目滞后 10 人天（SV = -10，SPI = 0），SV 一样但严重程度完全不同。所以判断严重程度要看 SPI，判断资源缺口要看 SV。
2. 一个真实算例：两周迭代是怎么滑掉的
假设我们有一个两周的迭代，计划完成 40 个故事点。到第 7 天（迭代过半）时，理论上应该完成 20 个故事点。
实际情况是：团队只完成了 14 个故事点。按照公式：
EV = 14 个故事点
PV = 20 个故事点
SV = 14 – 20 = -6 个故事点
SPI = 14 / 20 = 0.7
SPI 只有 0.7，意味着按当前速度，迭代结束时只能完成 28 个故事点左右，缺口是 12 个故事点。更危险的是，如果这个趋势持续到第 7 天才被发现，剩下的 7 天无论怎么加班都很难补回 12 个故事点的缺口。
3. 关键依赖链：迭代里哪些任务真的"不能延"
施工项目里有个概念叫"关键线路"，关键线路上的任何一道工序延期，整个项目就延期；非关键线路上的工序有一定的浮动时间，只要不超过总时差就不影响总工期。这个概念在产品迭代里同样成立，只是表达方式要换一下。
我一般把迭代里的任务分成三类：串行依赖任务（B必须等A完成才能开始，这类任务天然构成关键依赖链）、并行独立任务（可以和其他任务同时推进，有一定的容错空间）、汇聚点任务（多个前置任务都完成后才能启动，往往是风险最高的节点）。
一个简单判断方法：画出一张任务依赖图，把所有任务的前置依赖标出来，从头到尾最长的那条路径就是你的关键依赖链。这条链上的任何偏差都是"红灯"，必须立即处理；链外的偏差可以先记录下来，观察一到两天再决定是否干预。
4. 一张偏差自检表：先分清类型再谈处理
我把过去几年遇到的进度偏差归纳成四种典型类型，每种类型的处理逻辑完全不同：
| 偏差类型 | 典型表现 | 根本原因方向 | 优先处理方式 |
|---|---|---|---|
| 趋势性偏差 | 连续三天速度持续低于计划10%以上 | 需求理解、估算偏差、人员状态 | 立即介入，重新评估剩余工作量 |
| 偶发性偏差 | 某一天突然掉速，第二天恢复正常 | 临时阻断、外部依赖、突发问题 | 记录观察，不急于调整计划 |
| 结构性偏差 | 某个模块从开始就比预期慢很多 | 技术方案、需求复杂度被低估 | 重新拆解该模块，可能需要换方案 |
| 隐性偏差 | 进度数据看起来正常，但实际产出质量下降 | 技术债累积、测试覆盖不足 | 最危险，必须通过质量指标交叉验证 |
这张表最值得注意的其实是最后一类。隐性偏差是最容易被忽略的，因为所有的进度报表都是绿色的，但代码质量、测试通过率、线上问题数已经在悄悄恶化，等到下一轮迭代爆发时，你会发现要还的债比想象中大得多。
三、偏差出现了，产品经理先做这三个判断
发现偏差之后不要急着上措施，先做判断。我见过太多产品经理一发现进度落后就直接喊"加班"，结果方向错了，加了班还是延期，团队士气也被消耗掉。正确的顺序是先判断、再决策、最后才执行。
1. 判断一：偏差落在关键依赖链上了吗
这是最优先的判断。如果偏差任务在关键依赖链上，无论偏差大小都必须当天处理，因为它的下游会像多米诺骨牌一样倒下去。
如果偏差不在关键依赖链上，那么它有一定的缓冲空间。这时候要算一个数：这个任务的浮动时间还剩多少？比如任务B计划3天完成，但它后置的汇聚点任务D要5天后才开始，那么B最多可以延后2天而不影响D。只要偏差不超过这个浮动时间，就没必要立即动用加班或加人这种高成本手段。
2. 判断二：偏差是趋势性的还是偶发性的
趋势性偏差和偶发性偏差的处理逻辑完全不同。判断方法很简单：看连续三天的数据是否呈同一方向变化。
如果只是某一天掉速，第二天就恢复了，那大概率是偶发问题，不需要动计划。但如果连续三天都比计划慢，即使每天的差距不大，累计起来也会形成实质性延期。这时候必须介入，介入的方式不是"催"，而是找出掉速的共同原因。
我遇到过的趋势性偏差里，前三位的根因是：需求在迭代中途悄悄扩大、跨团队依赖的接口文档迟迟不到位、某个核心技术难点比预想的复杂。这三个原因对应的处理方式完全不同，如果不分析就盲目加班，等于在用同一把锤子砸三种不同的钉子。
3. 判断三：偏差影响的是范围、质量还是时间
这是很多产品经理容易模糊的地方。进度偏差最终一定会传导到三个维度之一：要么砍范围、要么降质量、要么推迟上线。产品经理的专业性就体现在：能不能在偏差发生的时候，清楚地说出我们准备牺牲哪一个。
如果你不主动做这个选择，团队就会替你做，通常是悄悄降质量，因为降质量当时看不出来，上线之后才暴露。这是最糟糕的情况，因为问题从进度问题变成了线上事故。
4. 常见误判：把"赶进度"当成"抓进度"
这是我最想吐槽的一个误区，也是"抓进度不赶进度"这句用户高频搜索词背后的真问题。
赶进度的典型做法是：压缩测试时间、合并评审环节、取消非必要会议、要求研发每天多干两小时。这些做法的共同点是把未来的债提前支取，测试压缩意味着线上问题风险上升，评审合并意味着需求理解偏差放大，长期加班意味着后续几周效率下降。
抓进度的做法完全不同：重新审视当前的任务优先级，砍掉不是必须这一轮做的需求，把资源集中到关键依赖链上，把非关键任务延后。抓进度不增加任何人的负担，而是把已有的资源重新分配到最该去的地方。
判断自己是在赶还是在抓，有个简单的自检问题：如果你现在的措施会让团队在未来一个月里付出额外代价，那你就是在赶进度。
四、纠偏操作五步法：从发现偏差到形成闭环
判断清楚之后就要动手纠偏。我把整个过程拆成五个可执行的步骤，每一步都给出"做什么、怎么做、注意事项"。
1. 第一步：量化偏差，用数据而不是感觉说话
做什么：计算出当前迭代的 EV、PV、SV、SPI 四个数值，同时统计关键依赖链上任务的完成情况。
怎么做：如果团队有成熟的数据平台，可以直接从迭代看板或项目管理工具里导出故事点数据。如果没有，用最原始的方式：列出计划任务、实际完成任务、估算剩余任务，半小时内也能算清楚。
注意事项：量化偏差时不要只看"完成了多少任务"，还要看"完成的质量如何"。一个任务被标记为完成，但测试用例只覆盖了50%，这个完成是打折的。我一般建议引入一个"完成度系数"：完全符合验收标准的记1.0，部分符合的记0.7，勉强通过的记0.5。这样算出来的 EV 才接近真实。
2. 第二步：根因分析，从四个维度切入
做什么：找出导致偏差的根本原因，而不是停留在"进度慢了"这个表象。
怎么做：我用一个四维框架，分别对应人、流程、需求、技术：
- 人：是否有人被临时抽调？是否有成员状态异常？是否存在技能错配（任务难度超出当前能力）？
- 流程：是否有不必要的审批环节？是否存在任务切换过于频繁导致效率损失？是否沟通成本过高？
- 需求：需求在迭代中途是否被修改或扩大？验收标准是否在执行过程中发生变化？是否存在理解偏差？
- 技术：是否遇到未预见的技术难点？依赖的第三方接口是否稳定？环境问题是否消耗了大量时间？
注意事项：根因分析一定要避免"归因到个人"。如果分析结论是"某某同学效率低"，那多半说明你的分析还不够深。大多数所谓"个人效率问题"背后，其实是需求不清、任务拆解不当或依赖阻塞。
3. 第三步：方案选择，四选一或组合
做什么：基于根因，从四种典型纠偏方案里选择一种或组合。
四种方案的适用场景和代价如下表：
| 方案 | 适用场景 | 主要代价 | 见效速度 |
|---|---|---|---|
| 增加资源 | 关键依赖链上存在可并行化的工作 | 新人上手成本、沟通开销增加 | 中等（1-3天见效） |
| 裁剪范围 | 部分需求可以延后到下轮或后续版本 | 业务方可能不满意，需要沟通 | 快（当天见效） |
| 调整顺序 | 存在非关键任务可暂时停滞，资源可迁移 | 可能引发协作方不满，需重新对齐 | 快（1天内见效） |
| 接受延期 | 以上三种方案代价都太大，或偏差影响可控 | 失去信任，需要重建预期 | 慢（需重新规划） |
注意事项：千万不要同时动用所有方案。我见过一些团队一发现延期就"加人+砍需求+重排顺序+宣布延期"，看起来把能做的都做了，实际上每一项都执行得不到位。优先选择代价最小、见效最快的方案，如果不够再叠加第二项。
4. 第四步：与干系人对齐，把偏差说清楚
做什么：向业务方、上级、协作团队说明偏差情况、原因和你的纠偏方案，争取支持和理解。
怎么做：对齐的关键不是"汇报坏消息"，而是"带着解决方案去沟通"。我一般用这个结构：
- 先说结论：当前进度偏差 X 个故事点，按当前速度迭代结束会少交付 Y 个功能。
- 再说原因：造成偏差的主要原因是 Z（一到两个关键原因即可，不要罗列十条）。
- 然后说方案：我建议采用 A 方案处理，预计可以把缺口压缩到 B 以内。
- 最后说影响：如果 A 方案执行顺利，业务侧的影响是 C；如果不顺利，我们需要启动 D 备选方案。
注意事项：对齐时最容易犯的错误是"报喜不报忧"或者"过度报忧"。前者让业务方在最后时刻才得知延期，后者让业务方过度恐慌。比较合适的度是：让业务方清楚地知道风险在哪里、你在做什么、他们需要配合什么。
5. 第五步：执行跟踪与复盘，把这次的教训变成下次的预警
做什么：纠偏方案执行过程中持续跟踪，结束后做一次简短的复盘，把本次偏差的根因沉淀到团队的检查清单里。
怎么做：跟踪不需要开新会，直接在当前迭代的每日同步里用三分钟确认纠偏方案的执行情况即可。复盘也不需要长篇大论，用一页纸回答三个问题：偏差的根本原因是什么？我们当时为什么没更早发现？下次怎么更早发现？
注意事项：复盘的价值不在于追责，而在于把这次偏差的教训变成下一次的预警信号。比如"上次因为第三方接口延迟导致偏差，这次我们在迭代开始前就确认了接口联调时间"，这种具体的检查项比"加强沟通"这种空话有用一百倍。
五、比纠偏更重要：进度风险的前置控制
前面讲的全是"偏差出现之后怎么办"，但真正成熟的产品经理不会满足于被动救火。如果纠偏做得再好，也只是把损失缩小，真正的效率提升来自让偏差少发生、早发现。这一节讲前置控制，也是我认为现有大部分相关文章最缺的部分。
1. 迭代开始前：做一次"进度风险预判"
迭代规划会结束之前，我一般会加一个十五分钟的风险预判环节。这个环节只回答四个问题：
- 这个迭代里，哪些任务的估算把握低于70%？（低把握任务）
- 哪些任务依赖外部团队或第三方？（外部依赖任务）
- 哪些任务的技术方案还没有完全确定？（技术不确定任务）
- 哪些任务的需求最近一周内发生过变更？（需求不稳定任务）
把符合这四类特征的任务单独列一张表，在迭代期间重点盯。这张表不需要精确，但能极大提高你对风险的敏感度。
2. 迭代进行中：三个可视化工具的三个预警信号
可视化工具的价值不在于"画得漂亮"，而在于它能在偏差还很小的时候就发出信号，前提是你要知道看什么信号。
（1）燃尽图：看的是斜率变化，不是绝对位置
燃尽图的横轴是时间，纵轴是剩余工作量。很多人只看曲线当前位置是不是高于理想线，但更有价值的是看斜率。如果最近三天的实际完成速度明显慢于前三天，即使当前曲线还贴着理想线，也说明趋势在恶化，应该提前介入。
（2）看板：看的是"在制品堆积"
看板上某一列（比如"待测试"）堆积过多任务，是偏差的典型前兆信号。任务完成不等于价值交付，如果测试环节积压，说明瓶颈已经在测试这里。这种情况下的正确处理方式不是催研发，而是先疏通瓶颈。
（3）甘特图：看的是关键路径上的"实际 vs 计划"偏移
甘特图最有用的地方是可以直观地看到关键路径上的任务有没有偏移。我的习惯做法是用不同颜色标记关键路径上的任务，一旦其中任何一项的实际进度落后于计划超过半天，就立即进入警觉状态。
3. 组织层面：建立"进度健康度"周检机制
前面讲的都是单个迭代内部的控制。但如果你同时负责多个项目或者负责一个长期项目，就需要一个跨迭代的健康度检查机制。
我一般每周五花十五分钟，看五个指标：本周 SPI 平均值、关键依赖链上任务的按时完成率、需求变更次数、阻塞问题平均解决时长、质量指标（比如提测通过率）。这五个指标里，任何一个连续两周恶化，都说明进度管理体系本身出了问题，而不是某个具体项目的偶发情况。
4. 产品经理的独特杠杆：优先级排序与需求裁剪
前面讲的很多方法研发TL也能做，但有一件事只有产品经理能做，那就是用优先级排序和需求裁剪，从源头控制进度风险。
一个迭代之所以总是延期，往往不是因为团队执行力差，而是因为迭代承诺的范围超过了团队能承载的量。产品经理在这里的杠杆作用体现在：迭代开始前主动识别"锦上添花"的需求，把它们标记为"可延后"；迭代过程中一旦偏差出现，第一批被裁掉的就是这些需求，团队主攻的永远是"必须做"的部分。
我自己的习惯是：每个迭代里，明确区分"必做功能"和"加分功能"，加分功能不占用关键依赖链的资源，一旦偏差出现可以立即暂停。这样做的好处是，纠偏时不需要做痛苦的取舍，因为可取舍的部分在规划阶段就提前预留好了。
六、一个真实案例：从连续三次延期到三个月零延期
讲一下我去年处理过的一个中台重构项目，这是我自己踩坑最深、也收获最大的一次经历。
1. 项目背景与偏差演化
这是一个涉及 8 个研发、跨 3 个业务方、持续 4 个月的中台重构。项目用的是 PingCode 做项目管理，团队规模在 120 人左右，属于典型的中大型组织协作场景。
第一次迭代延期 3 天，原因是需求拆解不到位，很多"看起来简单"的任务实际做起来比预想的复杂。第二次迭代延期 5 天，原因是某个下游团队的接口比承诺时间晚了四天。第三次迭代延期 2 天，原因是临时插入了一个 P0 需求。
三次延期的根因完全不同，但暴露了一个共同问题：我们从来没有真正做过偏差管理，只是在事情变糟之后靠加班硬扛。
2. 我们做的三件事
第一个动作是把迭代任务重新做一次依赖梳理，明确画出关键依赖链。这一步花了大概两天时间，但让所有人第一次清楚地知道"哪些任务真的不能延"。以前每个任务看起来都重要，梳理之后才发现真正在关键路径上的任务不到总任务数的 40%。
第二个动作是引入每日进度快照，用 PingCode 的燃尽图和看板视图，每天下班前花十分钟同步一次当前 SPI 和阻塞问题。这个动作看起来很小，但它把偏差的发现周期从"一周一次"压缩到"一天一次"。
第三个动作是设立迭代风险预判会，在每次迭代规划后加十五分钟，专门标记那些估算把握低、依赖外部、需求不稳定的任务，并在迭代期间重点盯防。这个动作直接让第四个迭代的延期天数从平均 3 天降到 0 天。
3. 结果与数据
改造之后连续三个迭代零延期，SPI 从之前的平均 0.78 提升到 0.95，同时团队的平均加班时长下降了 40%。这个结果让我确信：进度管理的效率提升不是靠加人，而是靠让信息流通更快、让资源分配更准。
顺便说一句工具层面的经验。这次项目里我用的是 PingCode，选它的原因主要有三点：一是它支持私有化部署，对我们这种对数据敏感的团队是刚需；二是它支持从 Jira 平滑迁移，团队的历史数据可以带过来，不用重新建立数据基线；三是在国产替代的大背景下，它的功能完整度足够支撑中大型组织的复杂协作场景。如果你的团队规模在 100 人以上、同时管多个项目，并且对数据自主可控有要求，可以重点关注一下这类支持私有化部署的工具。
七、不同情况下的行动建议
以上讲的是一套通用框架，但不同类型团队、不同项目阶段的行动重点并不一样。下面按几种典型情况分别给出建议。
1. 团队规模 10 人以下：轻量化处理
小团队的优势是信息流通快，不需要太复杂的流程。建议把重点放在"每日五分钟站会"和"迭代中期检查"两个动作上。站会只看关键依赖链上的任务进展，中期检查重点看 SPI 数值。不需要引入复杂的管理工具，Excel 或者简单的看板就够了。
小团队最忌讳的是照搬大厂的复杂流程。流程的目的是降低沟通成本，如果流程本身带来的沟通成本比它解决的问题还多，那就是负收益。
2. 团队规模 10-50 人：需要机制化
这个规模是很多互联网公司的常见区间。此时团队规模已经超出自然沟通能覆盖的范围，需要一定的机制。建议建立"迭代健康度周检"机制，每周检查一次 SPI、需求变更率、阻塞问题时长这三个指标。同时建议选一个轻量的项目管理工具，把数据沉淀下来。
这个阶段的常见坑是"用 OKR 代替具体进度管理"，结果方向很清楚但进度没人跟。OKR 解决的是做什么，进度管理解决的是怎么按时做完，两者不能互相替代。
3. 团队规模 100 人以上：需要平台化
100 人以上、同时跑多个项目的组织，光靠机制和工具已经不够了，需要平台化的协作能力。这个阶段的重点是：跨项目的关键依赖梳理、统一的数据口径、可配置的流程模板。选工具时优先看是否支持私有化部署（数据敏感型行业刚需）、是否支持从其他平台平滑迁移、是否覆盖需求-开发-测试-发布全流程。
PingCode 在这个阶段是一个值得考虑的选择，它面向中大型企业的定位和 100 人以上组织场景的匹配度较高。但工具只是加速器，不是解决方案本身，先把偏差管理的机制跑通，再选工具落地，顺序不能反。
八、不同情况下的取舍：没有完美方案，只有最合适的选择
最后讲取舍。任何进度管理方案都不是无代价的，理解每种选择的代价，才能做出真正合理的选择。
1. 快 vs 稳：交付速度和交付质量的取舍
如果选择快，就必须接受一定比例的质量风险，同时需要建立更强的监控和回滚机制。比较务实的做法是：对用户影响大的核心链路，坚持稳；对用户感知弱的辅助功能，允许快。不要对所有事情用同一个标准。
2. 提前预警 vs 团队信任：监控力度的取舍
预警机制做得越细，对团队的"监控感"就越强。如果处理不好，会让团队产生被监视的抵触情绪。我的建议是：数据透明化，但只关注结果指标，不要细化到每个人的任务完成情况。让数据服务于改进，而不是考核。
3. 加班 vs 砍范围：短期手段和长期健康的取舍
短期看，加班是最快见效的手段。但长期看，每一次依赖加班的救火，都在透支团队未来的效率。如果一个团队连续三个迭代都要靠加班才能勉强交付，那问题一定不在"加班不够多"，而在迭代规划本身出了问题。
4. 加人 vs 砍需求：资源投入和价值交付的取舍
很多人的第一反应是"加人就能赶上"，但软件项目的加人有明显的边际递减效应。新加入的人需要时间理解上下文，在关键路径上甚至会降低整体效率。相比之下，砍需求往往见效更快、代价更可控。但砍需求需要产品经理有足够的判断力和话语权，这也是产品经理价值最容易被低估的地方。
5. 通用流程 vs 团队习惯：机制落地的取舍
最优雅的管理机制，如果团队不接受也没用。我的经验是：任何新机制先小范围试点一个迭代，能跑通再推广。不要指望一次会议就改变一个团队的工作习惯，也不要因为一次试点失败就否定整个方向。
九、总结：进度偏差管理的独特视角
回到最初的问题：进度管理如何做好进度偏差？我的核心观点是，偏差本身不是敌人，掩盖偏差和处理偏差的方式才是。
如果把整篇文章压缩成三句话：
- 进度偏差要早识别：把发现周期从"周"压缩到"天"，用燃尽图、看板、甘特图三件套做交叉验证。
- 进度偏差要准分类：先判断是否在关键依赖链上，再判断趋势性还是偶发性，最后判断影响范围、质量还是时间。
- 进度偏差要快取舍：在加资源、砍范围、调顺序、接受延期四种方案里明确选择一种或组合，不要所有方案一起上。
下一步怎么做？我建议从下一次迭代开始，做三件事：
第一，迭代规划会结束后，加十五分钟的风险预判，把估算把握低、依赖外部、需求不稳定的任务列出来重点盯。
第二，从第一天起每天下班前更新一次燃尽图和关键依赖链的完成情况，把偏差发现周期压到24小时内。
第三，把"加分功能"从必做需求里剥离出来，作为偏差出现时的第一批取舍对象，让纠偏不再需要痛苦决策。
这三件事都不复杂，但坚持做三个迭代，你就会发现团队从救火模式切换到预警模式。进度管理的本质是风险管理，好的产品经理不是不让偏差发生，而是让偏差始终处在自己可控的范围内。
常见问题解答（FAQ）
1. 进度偏差的计算公式是什么，产品经理该怎么用？
我之前一直凭感觉判断迭代有没有延期，直到有一次业务方问我‘到底慢了百分之几’，我张口结舌。后来听说有SV和SPI这两个指标，但看教材全是施工案例，不知道怎么套到我们两周一个迭代的节奏上。
核心两个公式：SV（进度偏差）= EV（实际完成价值）− PV（计划完成价值），SPI（进度绩效指数）= EV ÷ PV。产品经理落地时，先把迭代任务折算成故事点或人天当统一口径：比如本次迭代计划两周完成40个故事点，这是PV；
到第7天实际只完成了16个点，这是EV，那么SV = 16 − 20 = −4个点，SPI = 16 ÷ 20 = 0.8。判断依据是：SV为负说明滞后，SPI低于0.9要拉预警，低于0.8基本可以预判本次迭代目标完不成。注意SV是绝对差值，只能看快慢不能跨迭代比较；
SPI是比值，可以横向比较不同规模迭代的健康度，汇报时两个一起给，业务方更容易接受。
2. 偏差出现了，产品经理要不要立刻砍需求或延期？
每次迭代中期发现进度慢了，我第一反应就是慌，要么想去找老板加人，要么想直接砍需求。但上次砍完需求业务方很不满，说核心功能没上；加人又发现新来的人根本接不上手，反而更乱。我现在特别想知道判断的先后顺序到底是什么。
不要第一步就动范围，先做三个判断。第一，看这个偏差任务在不在关键依赖链上，如果是登录、支付这类下游全等着的前置模块，偏差再小也要立刻处理；如果是独立的后台配置页，可以缓。第二，区分趋势性偏差还是偶发性偏差，连续三天SPI都在下滑才是真问题，某一天低了可能只是有人请假。
第三，判断偏差影响的是范围、质量还是上线时间，这三者只能保两个。可执行的顺序是：先砍优先级最低的边缘需求（通常占总量的10%-15%），再压缩非关键路径上的联调时间，最后才谈延期。加人是最后选项，因为新人熟悉业务至少要一周，短期反而拖慢节奏。
判断依据就是一条：先动影响面最小的杠杆，把对业务方承诺的核心功能保住。
3. 怎么提前发现进度风险，而不是等延期了才救火？
我总觉得自己像消防员，每次都是迭代快结束才发现做不完，然后加班、砍需求、道歉三连。我不想每次都这么被动，想知道有没有办法在偏差还没发生或者刚冒头的时候就发现苗头。
关键是设三个前置预警信号并养成固定检查节奏。第一，燃尽图连续两天实际线高于理想线且斜率没有收敛，这是最早的信号，通常在迭代进行到三分之一时就能看出来。第二，看板里‘进行中’的任务数超过团队人数的1.5倍，说明并行太多、切换成本在吃掉效率，这是流程性风险。
第三，每日站会里同一个任务连续两天说‘快好了’，这基本等于卡住了没人报。可执行的做法是：每周固定一次进度健康度检查，只花15分钟，把SPI、进行中任务数、阻塞项数量三个数写在一张表上，连续两周恶化的项目才升级处理。
判断依据是趋势而不是单点数据，单次异常不报警，连续恶化才介入，这样既不草木皆兵也不会漏掉真正的风险。
4. 怎么跟业务方沟通进度偏差，才能不被追着骂？
我特别怕跟业务方汇报延期，每次说完对方脸色就变了，要么质疑我们能力不行，要么直接去找我领导。我明明是想提前同步风险争取理解，结果反而变成了我的锅。有没有什么沟通框架能让这事不那么难堪？
核心原则是：不要只报问题，要带着方案和时间点去谈。可执行的模板分四句话：第一句给结论和影响面，比如‘支付模块按当前节奏会晚3天，影响的是月底的大促上线’；第二句给原因，用数据说而不是用情绪说，比如‘SPI从0.95降到0.78，主要是第三方接口联调比预期多花了4天’；
第三句给你已经做的动作，比如‘我已经砍掉了两个非核心的统计需求，把资源集中到主链路上’；第四句给选项让业务方做决策，比如‘现在有两个方案：要么延期3天保证全功能，要么按时上线但先去掉对账功能下个迭代补，您倾向哪个’。
判断依据是：业务方真正在意的不是你有没有延期，而是延期会不会影响他的核心目标和有没有应对方案。把选择题递过去，而不是把问答题甩过去，沟通阻力会小很多。
核心关键词
文章包含AI辅助创作：进度管理如何做好进度偏差？产品经理风险控制与操作步骤，发布者：飞飞，转载请注明出处：https://worktile.com/solution-1/archives/461105
读者评论
文章把进度偏差拆成SV和SPI两个指标讲得很清楚，但实际迭代中故事点估算本身就不准，算出来的SPI可能只是估算误差的放大，产品经理更该关注的是任务完成度的主观判断是否可靠。
关键依赖链那个部分很实用，我之前做项目就是忽略了汇聚点任务的风险，多个前置任务并行时总觉得时间还够，结果汇聚点一卡整个迭代就崩了，建议再展开讲讲怎么识别汇聚点。
隐性偏差那段说到痛点了，进度报表全绿但代码质量下降，等到下个迭代爆发时才发现欠了一堆技术债，但问题是质量指标怎么量化才能像SPI一样及时预警，文中没有给出具体方案。
纠偏操作五步法里第一步的完成度系数设计挺有意思，但0.7和0.5这种系数在实际团队里很难统一标准，不同人对验收标准的理解差异很大，容易变成扯皮，需要更明确的判定规则。
文章反对盲目加班这点很认同，但现实中很多时候产品经理没有砍需求或推迟上线的权限，只能靠加班硬扛，所以早识别之外，向上管理和干系人预期管理可能比纠偏方法本身更关键。