任务截止日期推迟后，需要同时完成两件事：按依赖关系重算同一链上后续任务的起止时间，并圈定受影响的任务范围。本文按“确认变更口径—逐层重算—分层识别影响—角色分工—示例演示—完成检查”的顺序展开，只处理工作项层面的排期与依赖调整，不涉及项目整体进度基线或人员负载平衡。
要点总览（TL;DR）
- 先确认推迟的是开始日期还是截止日期，并固定新完成时间、原工期、工期是否可压缩、依赖类型与依赖链边界，再开始重算。
- 重算规则是后继任务开始时间取所有前置任务中最晚的新完成时间，结束时间按自身工期顺延；能压缩或并行的先消化推迟量，再向后传导。
- 受影响范围按直接后继、间接后继、共享里程碑或对外承诺节点三层圈定，并分为必须调整、可压缩消化、仅需知会三类处置。
- 重排后逐项核对：后继开始时间不早于前置新完成时间、依赖关系未断裂、里程碑与对外承诺变更已确认、变更记录可追溯。
先定口径：推迟的是完成日期还是开始日期
重算前最容易出错的地方，是拿错了基准。开始日期推迟和截止日期推迟对依赖链的影响方向不同：前者通常整体平移该任务及其后继，后者只改变完成时间，开始时间可能不变，工期被压缩。先确认属于哪种情形，再决定后续怎么算。
建议在动手改任何日期之前，填写一张变更输入确认表，把重算所需的基准固定下来。
| 确认项 | 需要记录的内容 | 对重算的影响 |
|---|---|---|
| 变更任务 | 任务名称与唯一标识 | 确定重算起点 |
| 原起止日期 | 原开始日期、原完成日期 | 作为对比基准，计算推迟量 |
| 新截止日期 | 变更后的完成日期 | 后继任务开始时间的最早约束 |
| 工期是否可变 | 固定工期 / 允许压缩 / 允许拆分 | 决定推迟量能否在链内消化 |
| 依赖类型 | 完成—开始为主，是否存在开始—开始、完成—完成等约束 | 决定重算公式，非完成—开始依赖需单独处理 |
| 依赖链边界 | 链内任务清单、跨链共享任务、共享里程碑 | 确定重算范围和影响圈定范围 |
确认口径时有三个判断需要明确。第一，新截止日期是硬约束还是目标值，硬约束意味着后继必须让路，目标值则允许通过压缩工期回到原计划。第二，原工期是否可压缩，可压缩空间决定了推迟量是在链内消化还是向后传导。第三，依赖链的边界在哪里，一条链上的任务可能同时被另一条链的前置任务约束，重算时要把这些跨链约束一并纳入，否则算出的新排期会在执行时再次冲突。
完成标志：变更输入确认表填写完整，变更任务、新完成时间、工期弹性和依赖类型四项无歧义，可以进入重算。
重排依赖链的四步操作
重算的核心规则只有一条：后继任务的开始时间不早于其所有前置任务中最晚的新完成时间，结束时间按该任务自身工期顺延。四步操作把这个规则落到具体动作上。
第一步：标记变更任务，锁定新完成时间
输入是变更输入确认表。动作是在排期表中把变更任务的完成时间改为新日期，并标注“已变更”状态，避免后续重算时被旧数据覆盖。输出是一个明确的新完成时间锚点。如果该任务自身工期也被压缩，同步更新其开始时间。
第二步：沿后继方向逐层重算
从变更任务出发，按依赖层级由近及远处理每个后继任务。对每个后继任务，收集它全部前置任务的新完成时间，取其中最晚的一个作为最早可开始时间；若该时间晚于原开始时间，则开始时间顺延，结束时间按原工期顺延；若早于或等于原开始时间，保持原排期不变。一个任务有多个前置时，必须等所有前置都算完再定它的开始时间，否则会出现反复修改。
完成一层再进入下一层，直到没有新的后继任务需要调整。这一步的输出是每个受影响任务的新开始时间、新结束时间和顺延天数。
第三步：判断哪些推迟量可以消化
顺延传导到某个任务时，先看它能否吸收推迟量，再决定是否继续向后传。可用的手段有两类：压缩工期，即在不改变交付质量的前提下缩短该任务自身工期；并行化，即把原本串行的部分工作改为同时进行，或让后继任务在前置任务部分完成时提前启动（需确认依赖类型允许）。
判断标准是：压缩或并行后的新结束时间是否回到原计划。能回到原计划的，标记为“链内消化”，不再向后传导；不能完全消化的，剩余推迟量继续传给下一层。压缩工期需要任务负责人确认可行性，不能由排期人员单方面决定。
第四步：回写排期并记录变更
把重算结果写回排期表，同时记录变更原因、变更任务、顺延天数、消化方式和影响范围。变更记录的作用是让后续查看排期的人知道某段日期为什么和原计划不同，也便于在里程碑评审时说明影响。回写完成后，排期表应能直接回答“哪些任务变了、变了多少、为什么变”。
在工作项承载依赖关系的工具中，这一步对应的是更新工作项日期并保留变更痕迹。ONES 支持在工作项上维护日期与依赖关系，变更后可通过工作项记录追溯调整原因，便于重算结果与影响说明留存在同一处。
受影响任务怎么分层识别
重算给出的是时间结果，影响识别要回答的是“哪些任务需要有人处理”。按影响传导方式分三层圈定，再按处置方式分三类，可以避免遗漏，也能避免把所有被顺延的任务都当成同等紧急。
| 层级 | 判定标准 | 典型情形 |
|---|---|---|
| 直接后继 | 前置任务新完成时间晚于其原开始时间，产生直接冲突 | 紧接变更任务之后的开发、测试或评审任务 |
| 间接后继 | 自身前置未直接变更，但开始时间因上游顺延而被推后 | 链上第二层及以后的任务 |
| 共享节点 | 与变更任务共享里程碑、交付物或对外承诺日期 | 版本发布节点、客户交付日期、跨团队交接点 |
三层圈定后，对每个受影响任务给出处置分类：
- 必须调整：新完成时间与硬约束冲突，且无法通过压缩或并行消化，需要正式修改排期并通知相关方。
- 可压缩消化：存在工期压缩或并行空间，调整后能回到原计划，需要任务负责人确认可行性后执行。
- 仅需知会：时间有顺延但不影响其自身交付承诺，或处于缓冲期内，通知负责人知晓即可，不修改排期。
共享节点要单独检查：里程碑日期是否被突破、对外承诺是否需要重新沟通。这类节点往往不在同一条依赖链上，但影响面最大，容易在只盯链内任务时被漏掉。
完成标志：受影响任务清单包含每个任务的层级、冲突原因和处置分类，共享节点已单独列出并标注是否需要对外沟通。
角色分工与各环节交付物
重排不是排期人员一个人的事。日期能否压缩、交接条件是否成立、对外承诺能否变更，分别由不同角色判断。明确分工可以减少反复确认。
| 角色 | 主要动作 | 交付物 |
|---|---|---|
| 变更任务负责人 | 提供新截止日期，说明推迟原因，确认自身工期是否可压缩 | 变更输入确认表中的任务信息 |
| 依赖链上下游负责人 | 确认交接条件是否仍成立，评估压缩工期或并行的可行性 | 各任务的工期弹性判断与消化方案 |
| 排期或项目协调角色 | 执行逐层重算，维护依赖关系，回写排期并记录变更 | 重排后的起止时间清单与变更记录 |
| 评审确认方 | 对里程碑变更和对外承诺调整做确认 | 里程碑与承诺变更的确认结论 |
分工的关键是让“提供信息”和“做决定”分开：任务负责人提供工期弹性的事实判断，排期人员据此计算，评审确认方对超出链内范围的承诺变更拍板。三者混在一起，容易出现排期人员替业务方承诺工期的情况。
示例：一条五级依赖链的推迟重排
以下为演示情景，任务名称、天数与依赖关系均为虚构，用于说明推导过程。
原排期：任务A（需求定稿，3天）→ 任务B（接口设计，4天）→ 任务C（开发实现，6天）→ 任务D（联调测试，4天）→ 任务E（上线准备，2天），全部为完成—开始依赖，各任务首尾相接。
假设任务B的截止日期推迟3天，B的工期不变，仍为4天，开始时间相应后移3天。逐层推导如下：
| 任务 | 原起止 | 新起止 | 顺延 | 处置 |
|---|---|---|---|---|
| A 需求定稿 | 第1—3天 | 第1—3天 | 0 | 不受影响 |
| B 接口设计 | 第4—7天 | 第7—10天 | +3 | 变更源，已确认 |
| C 开发实现 | 第8—13天 | 第11—16天 | +3 | 必须调整 |
| D 联调测试 | 第14—17天 | 第17—20天 | +3 | 可压缩消化：测试用例提前编写，压缩1天，回到第19天完成 |
| E 上线准备 | 第18—19天 | 第20—21天 | +2 | 仅需知会：上线窗口有2天缓冲，仍在窗口内 |
推导过程说明三点。第一，C的开始时间取B的新完成时间第10天的次日，即第11天，结束时间按6天工期顺延到第16天。第二，D通过提前编写测试用例压缩1天，把顺延量从3天降到2天，剩余推迟量继续传给E。第三，E虽然被顺延2天，但上线窗口本身有缓冲，属于仅需知会，不需要修改上线计划。
如果该链共享一个“版本发布”里程碑，还需单独检查里程碑日期是否被突破。假设里程碑原定第20天，D压缩后第19天完成、E第21天完成，则里程碑需要评审确认方确认是否顺延或调整E的范围。
完成检查：重排结果是否可用
重排完成后，逐项核对以下清单，全部通过再对外发布新排期。
- 每个后继任务的开始时间不早于其所有前置任务的新完成时间，多前置任务取最晚值。
- 依赖关系在改期后仍然完整，没有因手工修改日期而出现断链、悬空依赖或指向已删除任务的依赖。
- 压缩工期或并行化的任务已由任务负责人确认可行，压缩后的工期有依据，不是排期人员单方面设定。
- 共享里程碑和对外承诺节点的变更已由评审确认方确认，需要对外沟通的已安排沟通。
- 变更记录包含变更任务、原起止、新起止、顺延天数、变更原因和影响范围，可追溯到具体决策。
- 受影响任务清单中的“必须调整”“可压缩消化”“仅需知会”三类均有明确责任人和后续动作。
这份清单同时适用于单条依赖链和跨链共享节点的检查。核对通过后，新排期即可作为后续执行的基准；核对中发现断链或未确认的承诺变更，回到对应步骤修正后再发布。
常见问题
如果推迟的任务同时被另一条依赖链约束，重算时应该怎么处理？
把跨链约束一并纳入重算，不能只看当前这条链。具体做法是：在确认依赖链边界时，列出该任务及后继任务的全部前置任务，包括来自其他链的前置；重算每个任务时，取所有前置任务中最晚的新完成时间作为最早可开始时间。这样算出的新排期在执行时不会因为另一条链的约束再次冲突。如果跨链前置任务本身也在调整，需要两条链的负责人对齐后再定最终日期。
压缩工期由谁决定，排期人员可以自行设定吗？
压缩工期应由任务负责人判断可行性，排期人员负责计算和记录。任务负责人最了解工作内容、质量要求和可并行空间，能判断压缩后是否仍能保证交付质量；排期人员可以提出压缩或并行的候选方案，但压缩后的工期需要任务负责人确认。评审确认方则对超出链内范围、影响里程碑或对外承诺的调整做最终确认。三者分开，可以避免排期人员替业务方承诺工期。
推迟量在链内消化后，还需要通知下游任务负责人吗？
需要区分情况。如果下游任务的新排期回到原计划，属于链内消化，通常只需在变更记录中说明消化方式，并知会相关任务负责人即可。如果下游任务仍被顺延但处于缓冲期内，归入仅需知会，通知负责人知晓、不修改排期。如果下游任务与硬约束冲突且无法消化，则属于必须调整，需要正式修改排期并通知相关方。无论哪种情况，变更原因和影响范围都应记录，便于后续追溯。
共享里程碑被突破时，应该先调整排期还是先对外沟通？
建议先完成内部确认，再对外沟通。具体顺序是：排期人员算出里程碑可能被突破的天数，评审确认方判断是否可以压缩链内任务、调整范围或顺延里程碑，形成明确结论后，再由负责对外沟通的角色与相关方沟通。这样对外传递的是经过确认的新日期和影响说明，避免在内部尚未定论时反复变更对外承诺。如果里程碑涉及客户交付或跨团队交接，沟通应尽早启动，为对方留出调整时间。
重排后如何确认没有遗漏受影响的任务？
用三层圈定加逐项核对来确认。三层是直接后继、间接后继、共享里程碑或对外承诺节点，其中共享节点往往不在同一条依赖链上，需要单独列出检查。逐项核对包括：每个后继任务的开始时间不早于其所有前置任务的新完成时间；依赖关系在改期后仍然完整，没有断链或悬空依赖；受影响任务清单中三类处置均有明确责任人和后续动作。核对中发现断链或未确认的承诺变更，回到对应步骤修正后再发布新排期。
