任务截止日期变更后，需要同时完成两件事：先沿依赖链找出会被波及的后续任务，再逐项重算开始与结束时间。推迟时优先判断能否用压缩工期或调整顺序吸收延迟，提前时则要检查前置任务是否来得及交付。本文按变更登记、范围识别、逐项处置、重算发布、完成检查五步展开，并给出一个可对照的示例。
要点总览（TL;DR）
- 截止日期变更后先固定变更登记：工作项、原日期、新日期、提前或推迟、确认人、通知状态，登记完成再动排期。
- 沿依赖链向后排查，把任务分成直接后继、间接后继和不受影响三类，追到依赖链走完或锁定节点即停止。
- 逐项判断处置方式：强依赖且无压缩空间则顺延，工期可压缩且质量可控则压缩，弱依赖或可拆分则换序，对外承诺节点则锁定并反向约束前置任务。
- 推迟时优先用压缩或换序吸收延迟，提前时先检查前置任务是否来得及交付，再确认后继能否提前启动。
- 新日期写回工作项后检查依赖倒挂，逐一通知责任人并保留变更前后对照，按七项检查表确认闭环。
先确认变更：哪些信息必须在动手改排期前定下来
排期改动最容易出问题的地方，是变更本身还没定就急着改日期，结果改到一半新日期又变了。动手之前，先把这次变更固定成一条可查的记录，后续所有排查和重算都以它为准。
需要定下来的信息包括：
- 变更对象：具体是哪个工作项，原截止日期是哪天，新截止日期是哪天。写清工作项名称或编号，避免同名任务混淆。
- 变更性质：提前还是推迟，幅度是几天还是几周。幅度直接决定后续处置的力度，推迟三天和推迟三周的应对方式不同。
- 变更来源与确认人：谁提出、谁批准。提出人和批准人可以是同一人，但必须明确，否则后续出现争议时无法追溯。
- 通知状态：直接干系人是否已知晓。这里的干系人指该任务的负责人、下游接口人以及需要据此调整安排的人。
- 传导预期：这次变更是否已经明确会传导到后续任务。有些变更只影响任务本身，比如内部整理类工作；有些则必然带动后继任务，需要在登记时就标注出来。
把这些信息整理成一份截止日期变更登记，字段包括：工作项、原截止日期、新截止日期、变更性质、变更原因、提出人、确认人、通知状态、是否预期传导。这份登记是后面识别范围和复核完成的基准，登记没写完就不要开始改排期。
沿依赖链识别受影响范围：直接后继、间接后继与不受影响任务
范围识别靠依赖关系清单，不靠印象。做法是从变更任务出发，沿依赖方向逐层向后排查，把结果分成三类：直接后继、间接后继、不受影响。
第一步：列出直接后继任务
直接后继是指以变更任务为前置的任务。排查时把强依赖和弱依赖分开标注：强依赖意味着前置不完成，后继无法开始或无法收尾；弱依赖意味着后继可以启动，但需要前置的部分产出。分开标注的原因是两者在处置时的灵活度不同，强依赖通常只能顺延，弱依赖有换序空间。
第二步：由直接后继向下追一层
直接后继的日期一旦变动，它们自己的后继也会受影响，这就是间接后继。间接后继不需要无限追下去，追到依赖链走完，或者遇到已锁定日期的里程碑节点就停止。锁定节点是对外承诺或阶段验收点，它的日期不随内部变更移动，排查到它时改为反向约束前置任务。
第三步：判断依赖类型对日期传导的影响
不同依赖类型对日期的传导方式不一样，识别范围时要一并记录：
| 依赖类型 | 日期传导方式 | 排查时的关注点 |
|---|---|---|
| 完成—开始 | 前置完成后后继才能开始，前置结束日期平移会直接带动后继开始日期 | 重点排查，通常需要顺延 |
| 开始—开始 | 前置开始后后继即可启动，可部分并行 | 关注启动时点是否仍成立，未必需要整体后移 |
| 完成—完成 | 两者收尾需对齐，前置结束变动影响后继收尾 | 关注收尾节点是否冲突 |
第四步：标记不受影响的任务
以下情况可以归入不受影响：与变更任务没有依赖关系的任务；依赖已经满足、不再受前置日期约束的任务；依赖较弱且可以独立调整顺序的任务。把这些任务明确标出来，是为了避免后续重算时误改，也为了让排查有明确的排除依据。
排查完成后，产出一份受影响任务清单，按直接后继、间接后继、不受影响三类分组，每项标注依赖类型和判断理由。这份清单只回答“谁受影响”，不回答“怎么处理”，处置放到下一步。
逐项判断处置方式：顺延、压缩工期还是调整执行顺序
受影响不等于一律后移。对清单中的每项任务，按以下四种方式判断处置，并记录判断依据和责任人。
- 顺延：后继任务的开始时间随前置完成时间平移，工期保持不变。适用于强依赖、且该任务本身没有压缩空间的情况。这是最直接的方式，但会累积延迟，用之前先看下游是否还有缓冲。
- 压缩：在工期确实可压缩、质量风险可控的前提下，吸收部分延迟。判断依据要具体，比如增加并行人手、缩减非必要环节、复用已有产出。压缩不是默认选项，需要责任人确认压缩后仍能达到验收标准。
- 换序：对弱依赖或依赖可拆分的任务，把其中不依赖前置的部分提前并行。换序的前提是拆分后各部分能独立验收，否则只是把问题往后推。
- 锁定：对外承诺日期或里程碑节点不随内部变更移动。此时不是调整后继，而是反向约束前置任务，要求变更任务或其中间产出在锁定节点前交付，必要时拆分工作项、先交付锁定节点所需的部分。
提前和推迟在处置上的差异需要单独说明。推迟时，优先判断能否用压缩或换序吸收延迟，吸收不掉的部分再顺延，这样能把延迟控制在局部。提前时，问题往往不在后继任务，而在前置任务是否来得及交付：新日期提前后，原本按旧日期安排的前置工作可能无法按时完成，此时需要反向检查前置任务，必要时调整前置安排或拆分工作项，再确认后继任务能否相应提前启动。
每项处置都填入受影响任务处置表，字段包括：任务、依赖类型、处置方式、新开始时间、新结束时间、判断依据、责任人。判断依据写具体理由，比如“强依赖且无压缩空间，整体顺延两天”，避免只写“已调整”。
重算并发布新排期：更新字段、通知与版本记录
处置表确定后，把结果写回工作项，完成一次可追溯的排期发布。这一步分四个动作。
更新字段。逐项修改受影响任务的开始时间、结束时间和依赖关系字段。依赖关系有变化的，比如换序后依赖被拆分，要同步更新依赖记录，否则下次排查会基于错误的关系。
检查冲突。更新完成后整体看一遍：是否出现同一任务开始时间晚于结束时间、后继任务开始时间早于前置完成时间这类依赖倒挂，以及同一责任人在同一时段被安排了两项无法并行的工作。发现冲突就回到处置表修正，不要带着冲突发布。
逐一通知。向受影响任务的负责人通知变更内容，包括新日期、变更原因和需要其配合的动作。通知对象以处置表中的责任人为准，避免只通知一部分人导致执行时信息不一致。
保留对照记录。保存变更前后的日期对照，记录变更登记编号、处置表版本和发布时间。对已锁定节点做二次确认，确认锁定日期未被改动、反向约束的前置安排已落实。
在工具层面，这一步依赖工作项的日期字段、依赖关系记录和变更留痕。ONES 支持在工作项上管理日期与依赖关系，变更历史可保留操作记录，适合把上述更新与对照落在同一处，便于后续回溯；具体字段设置以实际配置为准。
一个完整示例：设计评审推迟三天后的连锁调整
以下为演示情景，用于说明流程如何串起来，不代表真实项目数据。
背景。某工作项“设计评审”原截止日期为 3 月 10 日，因评审专家时间冲突推迟至 3 月 13 日，推迟三天。确认人为项目负责人，已通知设计负责人。
范围识别。直接后继有两项：“详细设计文档定稿”为强依赖（完成—开始），“开发环境准备”为弱依赖（开始—开始）。间接后继一项：“编码任务包启动”，依赖详细设计文档定稿。不受影响的任务包括“需求澄清会”和“测试用例框架搭建”，前者依赖已满足，后者与设计评审无依赖关系。
处置与重算。
| 任务 | 依赖类型 | 处置方式 | 新开始 | 新结束 | 判断依据 | 责任人 |
|---|---|---|---|---|---|---|
| 详细设计文档定稿 | 完成—开始（强） | 顺延 | 3 月 14 日 | 3 月 17 日 | 强依赖，文档需评审结论后才能定稿 | 设计负责人 |
| 开发环境准备 | 开始—开始（弱） | 换序 | 3 月 11 日 | 3 月 14 日 | 环境搭建不依赖评审结论，可先行启动 | 开发负责人 |
| 编码任务包启动 | 完成—开始（强） | 压缩 | 3 月 18 日 | 3 月 22 日 | 定稿后压缩启动准备环节，吸收一天延迟 | 开发负责人 |
通知与记录。向设计负责人和开发负责人分别通知新日期与配合动作，保存变更前后对照：设计评审 3 月 10 日→3 月 13 日，详细设计文档定稿 3 月 13 日→3 月 17 日，编码任务包启动 3 月 17 日→3 月 18 日。示例只处理工作项层面的日期与依赖安排，不涉及人员容量重新分配；如果开发负责人同期还有其他任务，需要另行评估负载。
完成检查：这次排期更新是否真的做完了
排期更新是否闭环，用下面这份检查表逐项核对，每项标注通过或不通过，不通过的回退到对应步骤修正。
| 检查项 | 通过标准 | 结果 |
|---|---|---|
| 变更登记完整 | 原日期、新日期、变更性质、原因、确认人、通知状态均已填写 | |
| 依赖链排查有停止依据 | 直接后继全部列出，间接后继追至链尾或锁定节点，未遗漏 | |
| 每项受影响任务有处置 | 处置方式、判断依据、责任人齐全，无空白项 | |
| 新日期已写回 | 开始时间、结束时间、依赖关系字段均已更新 | |
| 无依赖倒挂 | 后继开始时间不早于前置完成时间，无日期冲突 | |
| 负责人已收到通知 | 处置表中每位责任人都确认知悉新日期 | |
| 变更前后可追溯 | 对照记录已保存，锁定节点已二次确认 |
七项全部通过，才算完成一次排期更新。任何一项不通过，都说明影响范围识别或重算环节还有遗漏，按检查项对应的步骤回退处理，而不是在发布后零散修补。
常见问题
截止日期推迟和提前，在识别受影响范围时有什么不同？
排查方向一致，都从变更任务沿依赖链向后找直接后继和间接后继。区别在处置重点：推迟时，后继任务面临的是开始时间被推后，优先判断能否用压缩工期或调整顺序吸收延迟；提前时，后继任务本身通常不是瓶颈，真正要检查的是前置任务能否按新日期交付，必要时反向调整前置安排或拆分工作项，再确认后继任务能否相应提前启动。
依赖链很长时，排查到哪一层可以停？
追到依赖链自然走完，或者遇到已锁定日期的里程碑节点就停止。锁定节点是对外承诺或阶段验收点，日期不随内部变更移动，排查到它时改为反向约束前置任务，要求变更任务或其中间产出在锁定节点前交付。停止条件要在受影响任务清单里写明，作为后续复核的依据。
压缩工期吸收延迟时，需要满足什么前提？
两个前提：工期确实有可压缩的空间，压缩后仍能达到验收标准。判断依据要写具体，例如增加并行人手、缩减非必要环节或复用已有产出，并由任务责任人确认。压缩不是默认选项，质量风险不可控时应改为顺延或换序，把延迟控制在局部。
排期更新后发现有依赖倒挂，应该怎么处理？
回到受影响任务处置表修正，不要带着冲突发布。常见原因是顺延只改了后继的开始时间而没同步结束时间，或者换序后依赖关系字段没有更新。修正后重新检查一遍：后继开始时间不早于前置完成时间，同一责任人在同一时段没有被安排两项无法并行的工作。
变更只影响任务本身、不传导到后续任务时，还需要走完整流程吗？
范围识别和处置表可以简化，但变更登记和通知不能省。登记里标注“不预期传导”并写明理由，例如该任务无后继依赖或依赖已满足。这样后续复核时能看出这次判断的依据，也避免其他人误以为遗漏了排查。若之后发现实际存在传导，再补做依赖链排查。
