甘特图计划与实际进度对不上，先别急着改计划。脱节通常有两类成因：一类是实际进度没有及时、准确地回填到任务上，图上的条只是旧数据；另一类是任务确实延期或范围发生变化，计划本身需要调整。纠偏的顺序是先判断属于哪一类，再定位偏差集中的工作项和依赖链，最后按原因分别处置，并在下一个更新周期验证偏差是否收敛。
要点总览（TL;DR）
- 先判断脱节类型：更新日志和时间戳显示数据陈旧，优先修更新机制；有实际产出证据表明工期或范围变化，才按真实偏差调整计划。
- 排查顺序从数据时效开始，再查任务颗粒度与依赖链完整性，最后核对估算失真和范围变更是否回写，避免直接改工期固化错误数据。
- 处置按原因分路径：更新机制类明确责任人与节奏，颗粒度类拆分或合并任务，依赖类修正前后置关系，真实偏差类调整剩余工期，范围变更类回写并重设基线。
- 调整基线前保留原基线快照，涉及多团队承诺的变更先沟通再改；结构性调整分批进行，发现连锁异常立即回退。
- 纠偏效果放在下一次更新周期结束后回看，连续两到三个周期偏差收敛、更新及时率稳定才算生效；偏差持续扩大或关键路径反复变动需升级处理。
脱节的典型症状与影响范围
判断脱节类型，先看症状出现在哪里。同样是“甘特图和实际不一致”，背后的处理方式差别很大。下表把常见症状归到两类脱节中，便于对照。
| 症状表现 | 更可能属于 | 初步判断依据 |
|---|---|---|
| 甘特图条长期不动，但团队每天都在推进工作 | 数据更新滞后型 | 任务状态、完成率长时间未变，更新记录稀少 |
| 任务已到期，状态仍停留在“进行中”或未开始 | 数据更新滞后型 | 到期日已过而无人回填结果 |
| 完成率长期停在某个整数，多个任务数值雷同 | 数据更新滞后型 | 数值像是估算填写而非按实际进展更新 |
| 依赖关系与实际执行顺序不一致，下游任务先于前置任务开始 | 两类皆可能 | 需查依赖是否维护、执行是否真的提前 |
| 部分任务明显超出原定工期，剩余工作仍然很多 | 真实进度偏差型 | 有实际产出证据表明工作量超出预期 |
| 范围新增了工作项，但计划中没有对应任务 | 真实进度偏差型 | 变更记录与计划条目对不上 |
症状归类之后，要界定影响范围，避免只修一个点而漏掉连锁影响。范围界定回答四个问题：涉及哪些工作项，是集中在某几个模块还是分散在全计划；涉及哪些角色，是单个执行者未更新，还是多个团队都未回填；是否波及关键路径，偏差项是否位于决定总工期的任务链上；是否影响下游依赖，有哪些任务以偏差项为前置条件。
范围界定可以用一个简单动作完成：在甘特图上标出所有“图面状态与实际不符”的任务，沿依赖箭头向下游追一层，记录被波及的任务清单和责任人。这份清单就是后续处置的工作底稿。需要说明的是，本文只处理进度控制本身；综合状态汇报、项目健康度管理以及里程碑达成情况属于其他主题，不在本文展开。
先分清原因：更新滞后还是真实偏差
症状只能提示方向，不能直接当结论。把可能的原因列成假设，再为每个假设找验证证据，可以避免“看到图不对就改计划”的误操作。下表给出常见原因假设与对应的验证证据。
| 原因假设 | 验证证据 | 证据能说明什么 |
|---|---|---|
| 更新责任未落实，没人负责回填状态 | 更新日志与时间戳：多数任务最后更新时间距今较久，且集中在个别人 | 指向流程问题，可基本排除大面积真实延期 |
| 更新频率过低，按周甚至按月才更新一次 | 更新记录的时间间隔分布，与任务实际推进节奏对比 | 缩小到节奏问题，但无法排除期间发生的真实偏差 |
| 任务颗粒度过粗，一个任务包含多周工作 | 任务工期分布：大量任务工期超过一个更新周期 | 说明完成状态难以判断，更新滞后与估算失真都可能存在 |
| 依赖关系未维护，前后置关系缺失或错误 | 依赖链完整性检查：关键任务是否有前置、是否存在孤立任务 | 指向计划结构问题，影响偏差传导判断 |
| 计划本身估算失真，工期定得过短或过长 | 同类任务历史实际工期与估算工期对比 | 只能缩小范围，需结合当前任务的实际产出判断 |
| 范围变更未回写，新增工作没有进入计划 | 变更记录与计划条目的比对，是否存在无对应任务的工作 | 可确认范围类原因，并定位遗漏的工作项 |
排查顺序建议从数据时效开始：先看更新日志和时间戳，确认图上的数据有多旧。如果大部分任务长期未更新，优先按更新机制问题处理，此时直接调整工期会把错误数据固化进新计划。数据时效正常，再查任务颗粒度和依赖链完整性，判断计划结构是否支持准确反映进度。最后查估算失真与范围变更，这两类原因往往需要结合历史数据和变更记录才能确认。
需要区分证据的效力。更新日志能直接排除“无人更新”这一假设，但无法证明任务没有延期；工期分布能说明颗粒度问题，但不能单独证明估算失真。多数情况下，证据只能缩小原因范围，最终结论需要结合执行者的实际产出确认。把假设和证据分开记录，后续处置才有依据。
按原因分路径处置
诊断结论不同，处置动作也不同。下面按原因类型给出动作清单，并标注操作风险。
更新机制类：把回填变成日常动作
明确每个工作项的更新责任人，通常由任务执行者负责，任务负责人复核。固定更新节奏，节奏应与任务颗粒度匹配：颗粒度细的任务按天或按隔天更新，颗粒度粗的任务至少在每个检查点更新。把状态更新纳入日常动作，例如每日站会前完成回填，或每周固定时间集中更新。这类处置的风险较低，但要注意避免只更新状态而不更新剩余工作量，否则偏差仍然看不出来。
颗粒度类：拆分过粗任务，合并过细任务
工期明显超过一个更新周期的任务，拆成可在一个周期内判断完成与否的子任务；大量半天以内、频繁变动的任务可以适当合并，减少更新负担。拆分时同步重设完成标准，让“完成”有可核验的产物，而不是凭感觉填百分比。拆分动作会改变计划结构，建议在调整前记录原任务与新任务的对应关系，便于后续追溯。
依赖类：修正前后置关系，识别被阻塞任务
逐条检查关键任务的前后置关系，补上缺失的依赖，删除与实际执行顺序不符的错误依赖。修正后沿依赖链向下游排查，列出被阻塞或可能被阻塞的任务，通知对应责任人。依赖调整会影响偏差传导路径，改动前确认关键路径是否因此变化。
真实偏差类：调整剩余工期与资源
对确认延期的任务，重新估算剩余工作量和工期，评估对关键路径的影响。如果偏差项在关键路径上，需要同步评估下游任务能否压缩或并行。调整时优先修改剩余工期，保留已完成部分的历史记录。涉及资源重新分配的，先与相关团队确认可用性再改计划。
范围变更类：回写变更并重设基线
把遗漏的变更工作补进计划，标注来源和确认人，然后重设基线。重设基线前保留原基线快照，便于后续对比变更前后的差异。涉及多团队承诺的变更，先沟通达成一致再改基线，避免单方面调整导致各方参照的计划不一致。
处置过程需要设置风险边界。调整基线前必须保留原基线快照，这是回溯和验证的前提。涉及多团队承诺的变更，先沟通再改，不能先改图后通知。当一次处置涉及大量任务的结构性调整时，建议分批进行，每批完成后检查依赖链和关键路径是否仍然完整，发现连锁异常立即停止并回退到快照。
在工具层面，这些动作可以落到具体的管理操作上。以 ONES 为例，项目计划支持按目标、交付物或项目阶段分解工作，任务可以设置前后置依赖，里程碑用于标记重要时间点；设置计划和里程碑基线后，可以对比计划与执行的偏差，并通过版本细节追溯变更。进度反馈依赖任务层级的实际状态更新，从项目到任务的多层级管理让自下而上的反馈和自上而下的监控能够对应起来。甘特图支持多时间跨度查看进度并共享给成员，便于责任人和团队按同一份计划核对。这些能力对应的是更新、依赖维护和基线对比这几个动作，具体录入方式和呈现形式以实际使用为准。
验证纠偏效果与防止再次脱节
处置完成不等于问题解决。验证要放在下一次更新周期结束后回看，而不是改完计划立即判定。判断纠偏是否有效，可以看三项指标：连续若干更新周期内，计划与实际的偏差是否逐步收敛；更新及时率是否回升，即到期任务是否在约定时间内完成状态回填；依赖链是否一致，下游任务是否还出现先于前置任务开始的情况。
验证时建议做一张简单的检查表，每个周期填写一次：
- 本周到期任务中，按时回填状态的比例是多少；
- 甘特图上的完成情况与实际产出是否一致，抽查三到五个任务核对；
- 是否存在新的无前置依赖的孤立任务；
- 关键路径上的任务偏差是扩大还是缩小；
- 本周期是否发生基线变更，变更是否经过确认并保留快照。
连续两到三个周期偏差收敛、更新及时率稳定，可以认为纠偏生效。如果偏差持续扩大，或关键路径反复变动，说明原因判断可能有误或处置不彻底，需要升级处理：重新做一轮原因排查，必要时由项目负责人组织相关团队共同复核计划与承诺。
防止再次脱节靠机制固化。把更新节奏和责任人写进项目约定，新成员加入时同步；建立基线变更规则，明确什么情况下可以改基线、由谁审批、改前是否保留快照；定期校准估算，用历史实际工期修正同类任务的工期设定。这三项机制与前面的处置动作形成闭环：更新机制保证数据新鲜，基线规则保证变更可控，估算校准减少计划本身的失真。
常见问题
甘特图上的完成率长期不动，但团队每天都在推进工作，应该先改计划还是先修更新流程？
先修更新流程。完成率长期不动、多个任务数值雷同，通常说明状态回填没有落实，图上的数据已经过期。此时直接调整工期，会把旧数据固化进新计划，后续更难判断真实偏差。建议先明确每个工作项的更新责任人，固定与任务颗粒度匹配的更新节奏，把状态回填纳入日常动作，再观察一个更新周期后的数据变化。
任务颗粒度多粗算过粗，需要拆分到什么程度？
一个实用的判断标准是：任务工期是否超过一个更新周期。如果任务工期明显长于团队约定的更新间隔，完成状态在一个周期内无法判断，就属于过粗，应拆成可在一个周期内核验完成与否的子任务。拆分时同步重设完成标准，让“完成”对应可核验的产物。反过来，大量半天以内、频繁变动的任务可以适当合并，减少更新负担。拆分和合并都会改变计划结构，建议记录原任务与新任务的对应关系，便于追溯。
调整基线时最容易出什么问题，怎么控制风险？
最常见的问题是改完基线后无法回溯，以及多团队参照的计划不一致。控制风险有两个动作：调整前保留原基线快照，作为后续对比和回退的依据；涉及多团队承诺的变更，先沟通达成一致再改基线，不能先改图后通知。如果一次处置涉及大量任务的结构性调整，建议分批进行，每批完成后检查依赖链和关键路径是否完整，发现连锁异常立即停止并回退到快照。
纠偏后多久可以判断是否生效？
放在下一次更新周期结束后回看，不要改完计划立即判定。观察连续两到三个更新周期：计划与实际的偏差是否逐步收敛，到期任务是否在约定时间内完成状态回填，下游任务是否还出现先于前置任务开始的情况。三项指标稳定，可以认为纠偏生效。如果偏差持续扩大或关键路径反复变动，说明原因判断可能有误或处置不彻底，需要重新做一轮原因排查，必要时由项目负责人组织相关团队共同复核计划与承诺。
防止再次脱节，哪些机制值得固化下来？
三项机制比较关键：一是更新节奏与责任人写进项目约定，新成员加入时同步；二是建立基线变更规则，明确什么情况下可以改基线、由谁审批、改前是否保留快照；三是定期用历史实际工期校准同类任务的估算，减少计划本身的失真。这三项分别对应数据新鲜度、变更可控性和估算准确性，与处置动作形成闭环。
