任务截止日期提前后，重排依赖链的关键是先确认新的最晚完成时间，再从被改动的任务出发，沿依赖关系逐级向后推算每个紧后任务的最早开始与结束时间。本文聚焦工作项层面的排期重排，给出推算规则、操作步骤、顺序调整判断、受影响范围清单与完成检查项，帮助你在变更后得到一份前后一致、可追溯的新排期。
要点总览（TL;DR）
- 重排的起点是变更任务：用新的最晚完成时间减去剩余工期，得到新的最晚开始时间；再沿依赖链向后逐级推算。
- 紧后任务的最早开始时间取所有前置任务完成时间的最大值，结束时间等于开始时间加工期；存在其他依赖类型时按对应约束校验。
- 新结束时间未突破下游承诺日期的任务只需平移时间；突破时在该节点选择压缩、并行或拆分，并重新校验依赖关系。
- 受影响范围沿依赖链向后圈定，同时检查跨链引用；变更说明包含原日期、新日期、原因和影响范围，关键角色确认后留痕。
- 提交前逐项核对起止时间与依赖一致、承诺日期未被突破、跨链引用已覆盖、变更记录与通知已完成。
先算清重排的起点与传播规则
重排的起点是变更任务本身。先确认两件事：新的最晚完成时间由谁提出、依据是什么；该任务剩余工期还有多少。新的最晚完成时间减去剩余工期，得到变更任务新的最晚开始时间。如果这个开始时间已经早于当前日期，说明仅靠平移无法消化，需要在起点任务上先做处理，再向后传播。
传播规则的核心是：紧后任务的最早开始时间，取它所有前置任务完成时间的最大值；结束时间等于开始时间加本任务工期。这条规则决定了重排不能只看直接前置，还要看同一任务是否有多个前置，取最晚的那个完成时间。
依赖类型会影响取哪个时间点。完成—开始是最常见的类型，前置完成后紧后开始，按上述规则计算。存在开始—开始、完成—完成等类型时，需要按对应约束分别校验开始或结束时间，不能一律套用完成—开始的口径。重排前先确认链上每条依赖的类型，避免算错传播方向。
遇到固定日期约束时，处理顺序是：先按依赖关系推算，再与约束日期比对。推算结果满足约束，直接采用；超出约束，就在该节点做压缩、并行或拆分，处理完再继续向后传播，避免把冲突原样传递给下游。
| 输入字段 | 计算方式 | 输出字段 |
|---|---|---|
| 变更任务新的最晚完成时间、剩余工期 | 最晚完成时间 − 剩余工期 | 变更任务新的最晚开始时间 |
| 紧后任务的全部前置任务完成时间 | 取所有前置完成时间的最大值 | 紧后任务最早开始时间 |
| 紧后任务工期 | 最早开始时间 + 工期 | 紧后任务结束时间 |
| 依赖类型 | 完成—开始按前置完成推算；其他类型按对应约束校验开始或结束 | 校验后的起止时间 |
| 固定日期约束 | 推算结果与约束日期比对，超出则在该节点压缩、并行或拆分 | 处理后的起止时间与处理方式 |
按依赖链逐级重排开始与结束时间
规则清楚后，按从变更任务到链尾的顺序推进。每一步都留下明确的输入、动作、输出和完成标志，便于中途交接和事后核对。
第一步：标记变更任务并冻结其新日期。输入是变更来源说明和剩余工期评估；动作是更新该任务的最晚完成时间与最晚开始时间，并在任务上标注“排期已变更”；输出是带有新日期的起点任务；完成标志是该任务的起止时间已更新，且变更原因有记录。
第二步：找出直接紧后任务并重算起止时间。输入是起点任务的新完成时间和依赖类型；动作是列出所有直接紧后任务，逐个取前置完成时间的最大值作为最早开始时间，加上工期得到结束时间；输出是直接紧后任务的新起止时间；完成标志是每个紧后任务的开始时间不早于其全部前置的完成时间。
第三步：逐级向后推进直至链尾。输入是上一层已更新的任务及其新完成时间；动作是把上一层任务当作新的前置，重复第二步的计算，直到没有紧后任务为止；输出是整条链的新起止时间；完成标志是链上每个任务的起止时间都已更新，且与其前置一致，链尾任务没有遗漏。
推进过程中，如果某个任务有多个前置且其中一条来自另一条链，要等所有前置的新时间确定后再计算该任务，避免用旧数据算出偏早的开始时间。跨链引用的任务在下一步的受影响范围识别中单独核对。
判断哪些任务需要调整执行顺序
逐级推算完成后，把每个任务的新结束时间与它已承诺的下游截止日期比对，据此区分两类处理方式。
新结束时间不晚于下游承诺日期的任务，只需平移时间：更新起止时间，执行顺序、负责人和交付物保持不变。这类任务占多数，处理成本低，重点是把新日期同步到位。
新结束时间突破下游承诺日期的任务，仅平移无法解决，需要在该节点选择一种处理方式：压缩工期，即缩减范围或增加投入以缩短工期；并行，即把原本串行的部分工作改为同时推进；拆分，即把任务拆成可分别交付的部分，让关键部分先完成。选择哪种方式取决于该任务的可压缩空间和下游对交付内容的要求，处理后再从该节点继续向后传播。
顺序调整后必须重新校验依赖关系：原来串行的任务改为并行后，是否产生了新的前置约束；拆分后的子任务与原紧后任务的依赖是否仍然成立；被压缩的任务是否影响其自身的质量检查环节。校验不通过时回到该节点重新选择处理方式。
以下情况超出工作项排期重排的范围，应转交处理：需要调整项目整体基线或阶段划分的，转交项目进度管理；需要跨团队调配人员、解决容量不足的，转交资源负载与冲突管理。本文只处理工作项层面的起止时间与执行顺序调整。
| 判断条件 | 处理方式 | 后续动作 |
|---|---|---|
| 新结束时间 ≤ 下游承诺日期 | 仅平移时间 | 更新起止时间并同步 |
| 新结束时间 > 下游承诺日期，任务有可压缩空间 | 压缩工期 | 重新校验依赖并向后传播 |
| 新结束时间 > 下游承诺日期，工作可拆开推进 | 并行或拆分 | 重新校验拆分后的依赖关系 |
| 涉及项目基线或阶段划分调整 | 转交项目进度管理 | 由对应流程处理 |
| 涉及人员容量不足 | 转交资源负载与冲突管理 | 由对应流程处理 |
识别受影响范围并通知相关角色
受影响范围沿依赖链向后圈定，同时检查跨链引用。具体做法是：从变更任务出发，把所有直接和间接紧后任务列入清单；再检查这些任务是否被其他链上的任务、需求或交付物引用，被引用的对象一并纳入。只沿一条链向后看，容易漏掉跨链依赖带来的二次影响。
圈定范围后，明确每类角色的职责与交付物。任务负责人负责确认本任务新起止时间是否可执行，并反馈无法满足的情况；依赖方负责确认其任务的前置时间变化已被纳入自己的排期；评审人负责核对变更后的排期与交付要求是否仍然匹配。每类角色的确认结果都应留痕，作为重排完成的依据之一。
变更说明应包含四个字段：原日期、新日期、变更原因、影响范围。原日期与新日期成对出现，便于对照；变更原因说明是谁提出、依据什么；影响范围列出受影响的上下游任务和角色。说明发出后，要求关键角色回复确认，未确认的列入跟踪项。
通知与确认的完成标志是：受影响清单上的任务负责人均已确认或提出异议并得到回应，变更说明已归档，跨链引用的对象已同步。在工具层面，这类同步通常依托工作项的依赖关系与状态更新来完成：变更任务更新日期后，依赖它的工作项在列表中体现新的前置时间，负责人据此确认自己的排期。ONES 支持在工作项之间建立依赖关系并跟踪状态，可用于承载上述受影响范围的识别与变更同步动作；具体操作方式以团队实际配置为准。
| 角色 | 职责 | 交付物 |
|---|---|---|
| 变更发起人 | 说明新的最晚完成时间与原因 | 变更说明（含原日期、新日期、原因、影响） |
| 任务负责人 | 确认本任务新起止时间可执行 | 确认结果或无法满足的反馈 |
| 依赖方 | 确认前置时间变化已纳入自身排期 | 更新后的自身起止时间 |
| 评审人 | 核对排期与交付要求是否匹配 | 评审结论 |
一个依赖链重排的示例
以下为演示情景，用于说明推算过程，数字为假设值。
原排期：任务 A（需求定稿）工期 3 天，计划 3 月 2 日至 3 月 4 日；任务 B（方案设计）依赖 A，工期 4 天，3 月 5 日至 3 月 10 日；任务 C（开发实现）依赖 B，工期 5 天，3 月 11 日至 3 月 17 日；任务 D（测试验收）依赖 C，工期 3 天，3 月 18 日至 3 月 20 日。下游对外承诺 3 月 20 日交付。
变更：A 的最晚完成时间被提前到 3 月 3 日，剩余工期仍为 3 天，则 A 新的最晚开始时间为 3 月 1 日，实际排期调整为 3 月 1 日至 3 月 3 日。
推算：B 的最早开始时间取 A 的完成时间 3 月 3 日，加 4 天工期，结束于 3 月 7 日；C 的最早开始时间为 3 月 7 日，加 5 天，结束于 3 月 12 日；D 的最早开始时间为 3 月 12 日，加 3 天，结束于 3 月 14 日。整条链比原计划提前，未突破 3 月 20 日的承诺，四个任务均只需平移时间。
若换一种情况：C 的工期实际为 8 天，则 C 结束于 3 月 15 日，D 结束于 3 月 18 日，仍在承诺范围内；若 C 工期为 10 天，D 将结束于 3 月 20 日之后，此时在 C 节点选择压缩或拆分，例如把 C 拆为两个可分别交付的部分，让 D 的测试准备工作提前介入，处理后再向后传播，并重新校验 D 与拆分后子任务的依赖关系。
| 任务 | 原起止时间 | 重排后起止时间 | 处理方式 |
|---|---|---|---|
| A 需求定稿 | 3 月 2 日—3 月 4 日 | 3 月 1 日—3 月 3 日 | 变更起点，冻结新日期 |
| B 方案设计 | 3 月 5 日—3 月 10 日 | 3 月 3 日—3 月 7 日 | 平移时间 |
| C 开发实现 | 3 月 11 日—3 月 17 日 | 3 月 7 日—3 月 12 日 | 平移时间 |
| D 测试验收 | 3 月 18 日—3 月 20 日 | 3 月 12 日—3 月 14 日 | 平移时间，未突破承诺 |
重排完成前的检查项
提交重排结果前，逐项核对以下内容，确认结果一致、可追溯、已同步。
- 起止时间与依赖关系一致：链上每个任务的开始时间不早于其全部前置的完成时间，依赖类型与计算口径匹配。
- 下游承诺日期未被突破：每个任务的新结束时间与已承诺日期逐一比对，被突破的节点已有压缩、并行或拆分处理并重新校验。
- 跨链引用已覆盖：被其他链引用的任务已纳入受影响清单并完成同步。
- 变更记录留痕：变更说明包含原日期、新日期、原因、影响范围，已归档可查。
- 通知与确认完成：受影响任务的负责人已确认或异议已回应，未确认项列入跟踪。
- 遗留风险有跟踪项：压缩工期或并行带来的质量、返工风险，以及依赖方尚未确认的部分，明确责任人和复查时间。
检查全部通过后，重排结果即可作为新的执行依据；存在未通过项时，回到对应环节处理，避免带着冲突进入执行阶段。
常见问题
变更任务的剩余工期已经不够用，还能按依赖链向后推算吗？
可以推算，但起点需要先处理。新的最晚完成时间减去剩余工期，如果得到的开始时间早于当前日期，说明仅靠平移无法消化。此时先在变更任务上做压缩、并行或拆分，确定一个可执行的起点日期，再沿依赖链向后传播。把无法执行的起点直接向后推算，只会把冲突原样传给下游。
链上某个任务有多个前置，其中一个来自另一条链，应该怎么算开始时间？
取所有前置任务完成时间的最大值，包括来自另一条链的前置。实际操作中要等另一条链的前置新时间确定后再计算该任务，避免用旧数据算出偏早的开始时间。这类跨链引用的任务还应单独列入受影响范围清单，确认另一条链的负责人已知晓时间变化。
下游承诺日期被突破时，压缩、并行和拆分应该优先选哪种？
取决于该任务的可压缩空间和下游对交付内容的要求。任务范围有可缩减部分、团队能增加投入时，压缩工期较直接；原本串行的工作之间没有严格先后约束时，改为并行可以缩短整体时间；交付物能分成可独立验收的部分时，拆分能让关键部分先完成。无论选哪种，处理后都要重新校验依赖关系，确认没有产生新的前置约束或影响质量检查环节。
截止日期被推迟而不是提前，重排方法一样吗？
推算规则相同，方向相反。推迟后变更任务的新完成时间变晚，紧后任务的最早开始时间随之变晚，沿链向后逐级更新即可。需要注意的是，推迟可能让某些任务与固定日期约束之间出现空档，也可能影响与其他链的衔接；这些变化同样要纳入受影响范围清单，并通知依赖方确认新的时间。
重排涉及项目整体基线调整或人员不足时，工作项层面还能处理吗？
工作项层面只处理起止时间与执行顺序的调整。需要调整项目整体基线或阶段划分的，转交项目进度管理；需要跨团队调配人员、解决容量不足的，转交资源负载与冲突管理。转交时把已完成的推算结果和受影响范围清单一并带上，便于对应流程直接接续处理。
