前置任务延期后，下游任务不宜一律整体顺延。更稳妥的做法是先确认延期事实和影响范围，再按依赖类型分别处理：强依赖的下游任务更新启动条件与时间，可拆分的下游任务先做不受影响的部分，并行或弱依赖任务重排顺序，跨团队交接则重设时间与交付标准。调整后还要回写排期、通知接手人，并用下一次交接验证是否真正恢复。
要点总览（TL;DR）
- 前置任务延期后先确认事实与影响范围：完成时间已过、剩余工作量无法按期收口、交付物未达可交接状态，任一成立就进入影响评估。
- 沿依赖关系把受影响任务分为直接后置、间接后置和共享交接点三类，并区分强依赖与弱依赖，形成带责任人的受影响任务清单。
- 按依赖类型分别处置：强依赖更新起止时间与可启动条件，可拆分任务先启动不受影响部分，并行或弱依赖任务重排顺序，跨团队交接重设时间与交付标准。
- 调整后回写工作项的开始结束时间、依赖关系与状态，通知接手人并确认收到，用最近一次交接或里程碑验证是否恢复。
- 若检查点再次延误，回到原因排查重新评估，避免继续叠加缓冲时间；同时记录触发条件与处理约定供下次沿用。
先分清是哪种延期、影响哪些下游任务
“延期”在排期表上只是一个日期变化，在实际执行中有不同形态。处置之前，需要先把延期拆成可以判断的事实，否则容易把局部延误当成整体失控，直接给所有下游任务加一段缓冲时间。
确认延期事实的三个判断点
判断一个前置任务是否构成需要处置的延期，可以看三个信号：原定完成时间已过而任务仍未完成；剩余工作量按当前投入节奏无法在原时间内收口；交付物尚未达到可交接状态，例如缺少下游启动所需的输入、评审未完成或版本未冻结。三个信号中任意一个成立，就应当进入影响评估，而不是等到截止日期当天才处理。
这里要区分“时间已过”和“确实做不完”。前者是日历事实，后者需要结合剩余工作项和可用投入来判断。把两者混在一起，容易把只需一两天收尾的任务当成重大延期，也可能把真正卡住的任务轻描淡写地顺延过去。
识别受影响的下游任务
沿依赖关系向下梳理，把受影响任务分成三类，处理优先级不同：
- 直接后置任务：以延期任务的交付物为启动输入，前置不完成就无法开始。这类任务需要优先确认新的可启动条件。
- 间接后置任务：本身不直接消费该交付物，但排在直接后置任务之后，会因链条传导而受影响。这类任务先标记观察，等直接后置任务定下新时间后再调整。
- 共享同一交接点的任务：多个下游任务依赖同一次交接或同一个评审节点，即使各自内容不同，也会被同一个延期同时卡住。这类任务适合合并处理，统一重设交接安排。
区分强依赖与弱依赖
同样是下游任务，等待的必要性并不相同。强依赖指下游必须拿到前置的完整交付物才能启动，例如接口未定稿就无法联调、需求未确认就无法进入设计。弱依赖指下游只需要部分输入、或者可以先做与前置无关的准备工作，例如可以先搭框架、准备测试数据、梳理验收标准。
完成这一步后，应产出一张受影响任务清单，逐条标注：任务名称、与延期任务的关系（直接后置、间接后置、共享交接点）、依赖类型（强依赖、弱依赖）、是否可以先行动作、当前负责人。这张清单是后续分类处置的依据，也是跨团队沟通时对齐范围的共同底稿。
排查延期的真实原因与可压缩空间
确认范围之后，下一步是判断这段延期还有没有压缩余地。压缩空间取决于原因，不同原因对应的处置方式差别很大：工作量确实做不完，通常只能顺延或拆分；交接等待造成的延误，往往可以通过重设交接安排追回一部分时间。
按原因假设逐条找证据
不要凭印象下结论，可以列出常见原因假设，再为每条假设找对应证据：
| 原因假设 | 验证证据 | 常见结论方向 |
|---|---|---|
| 工作量被低估 | 剩余工作项清单、已完成比例、近期每日实际产出 | 难以压缩，考虑顺延或拆分交付 |
| 上游输入缺失 | 阻塞记录、待确认事项、输入提供方的回复时间 | 先解决输入，再判断剩余工作能否按期完成 |
| 跨团队交接等待 | 交接请求发出时间、对方确认时间、往返轮次 | 压缩等待环节，重设交接时间与标准 |
| 执行资源被临时占用 | 人员实际投入记录、被插入的临时任务 | 确认资源回归时间，或调整任务优先级 |
证据要指向具体记录，而不是“感觉来不及”。剩余工作项能说明还差多少，阻塞记录能说明卡在哪里，交接确认时间能说明等待发生在哪一段。原因判断有证据支撑，后续对下游的解释和承诺才站得住。
判断延期是否可压缩
在原因清楚的基础上，评估两种压缩方式是否可行。第一种是拆分交付：把前置任务切成两部分，先交出一部分可供下游启动的成果，剩余部分随后补齐。这要求交付物本身可以切分，且下游能在部分成果上开始工作。第二种是先交部分成果供下游准备：成果尚不完整，但足以让下游做环境准备、方案设计或测试用例编写。
两种方式都有前提条件：拆分后的接口或标准需要提前约定，下游要接受“先启动、后补齐”的工作方式，补齐时间要有明确承诺。如果交付物不可分割，或者下游在部分成果上无法开展任何有效工作，就应判定为不可压缩，直接进入顺延或改期流程。这一步的产出是一份原因与证据对照，以及“可压缩”或“不可压缩”的明确结论。
按依赖类型调整下游任务
有了影响清单和原因结论，就可以逐条给出处置动作。核心原则是按依赖类型分别处理，而不是给所有下游任务统一加同样的缓冲时间。
强依赖下游：更新启动条件与时间
对必须等前置完成才能启动的任务，调整动作包括：更新开始和结束时间，使其与前置任务新的完成时间衔接；明确新的可启动条件，写清楚下游需要拿到什么、达到什么状态才算具备启动条件；如果前置完成时间仍不确定，先设定一个复查时间点，而不是填入一个没有依据的日期。每条调整都要落到具体责任人，避免“大家都知道要顺延”却没人更新记录。
可拆分下游：先启动不受影响的部分
对可以拆分的下游任务，把工作内容分成两块：不依赖前置成果的部分立即启动，依赖前置成果的部分挂到前置完成之后。拆分时要写清楚两部分的边界和衔接点，例如“框架搭建与数据准备先行，接口联调待前置接口冻结后开始”。这样既减少了空等时间，也让下游团队在延期期间保持有效产出。
并行或弱依赖任务：重排执行顺序
对并行任务和弱依赖任务，重点不是改日期，而是调整执行顺序。把原本排在被卡任务之后的工作提前，把可以独立完成的事项集中处理，等前置任务恢复后再回到原顺序。重排时要检查资源是否真的可用，避免把任务提前了却没有人执行。
跨团队交接：重设时间、标准与确认人
跨团队场景下，交接环节最容易出现信息不同步。调整时应明确三件事：新的交接时间、交付物应达到的标准、双方各自的确认人。交接标准要具体到可检查的程度，例如交付物包含哪些内容、通过什么方式确认、由谁签收。通知接手人时，说明变更原因、新的时间点和对方需要做的准备，并要求对方确认收到，避免下游仍按旧时间安排工作。
取消或大幅改期的确认条件
如果某个下游任务因延期失去意义，或者需要大幅改期，不能由执行人单方面决定。应说明触发条件，例如前置交付物范围发生实质变化、原定时间窗口已错过且无替代窗口，然后由任务负责人、下游团队负责人和相关的项目决策人共同确认。确认前保留原排期记录，确认后再更新状态，便于后续追溯。
下表汇总依赖类型与对应处置动作，可用于跨团队对齐：
| 依赖类型 | 典型情形 | 处置动作 | 责任人 |
|---|---|---|---|
| 强依赖 | 必须拿到完整交付物才能启动 | 更新起止时间，写明新的可启动条件 | 下游任务负责人 |
| 可拆分依赖 | 部分工作可先行开展 | 拆分任务，先启动不受影响部分 | 下游任务负责人与前置负责人共同确认边界 |
| 并行或弱依赖 | 只需部分输入或可独立推进 | 重排执行顺序，提前可做事项 | 团队排期负责人 |
| 跨团队交接 | 多个团队共享同一交接点 | 重设交接时间与标准，通知并确认 | 交接双方确认人 |
回写排期并验证恢复
调整动作确定后，只有落到工作项记录上才算真正生效。口头同步和群消息容易遗漏，下游成员打开任务时看到的仍是旧时间，就会继续按旧节奏准备。
更新工作项的时间、依赖与状态
逐条更新受影响任务的开始时间、结束时间和依赖关系，确保前置任务的新完成时间与下游任务的新开始时间一致，不出现前后矛盾。状态也要同步：仍在等待的任务标记为阻塞或待启动，已经先行开展的任务改为进行中。依赖关系变更后，检查是否还有指向旧时间的关联记录。使用 ONES 这类工作项管理工具时，可以在同一工作项上维护前后置依赖、计划时间与状态，让下游成员看到的排期与调整结论保持一致，减少口头同步造成的信息差。
通知相关角色并确认收到
通知对象至少包括：下游任务负责人、跨团队接手人、受影响的评审或验收角色。通知内容包含变更原因、新的时间点、对方需要做的准备以及下一次确认时间。发出通知后要求对方确认收到，对关键交接点可以安排一次简短对齐，确认双方对新的交接标准和时间的理解一致。
用最近一次交接验证恢复效果
调整是否有效，要看下一次实际交接。选择最近的交接点或里程碑作为检查点，观察三件事：前置任务是否按新时间交付、下游是否按新时间启动、交接标准是否被双方认可。如果检查点再次出现延误，说明原因判断或压缩方案有偏差，需要回到原因排查环节重新评估，而不是继续叠加缓冲时间。
形成同类延期的处理约定
一次处置结束后，把触发条件和处理方式记录下来：什么信号出现时启动影响评估、由谁牵头梳理受影响清单、强依赖和可拆分任务分别由谁决策、交接变更需要通知哪些角色。这些约定不必复杂，但要具体到动作和责任人，下次遇到同类延期时可以直接沿用，减少重复沟通和临时判断。
常见问题
前置任务完成时间还不确定时，下游任务的时间该怎么填？
不要填入没有依据的日期。可以先为下游任务设定一个复查时间点，到点重新评估前置任务的剩余工作量和可交付状态，再决定新的开始时间。同时把下游任务标记为等待或阻塞状态，写清楚需要满足什么条件才能启动，例如前置交付物通过评审或版本冻结。这样排期表反映的是真实状态，而不是一个看起来整齐却随时会再变的日期。
下游任务已经按旧时间开始准备了，前置延期后要不要全部停下来？
通常不需要全部停下。先判断下游已经开展的工作是否依赖前置交付物：与前置无关的准备工作，例如环境搭建、测试数据准备、验收标准梳理，可以继续推进；依赖前置成果的部分则挂起，等新的可启动条件满足后再继续。把下游任务拆成“可继续”和“需等待”两块，分别更新状态，比整体暂停更能保住已有投入。
跨团队交接点延期，通知了对方但对方没有确认，怎么办？
没有确认就不能视为交接已对齐。可以升级处理：由交接双方的负责人直接沟通，明确新的交接时间、交付物标准和各自需要做的准备，并把结论写回工作项记录。对关键交接点，安排一次简短对齐会比只发消息更可靠。若对方团队仍按旧时间准备，应在下一次确认时间点前再次核对，避免到交接当天才发现双方理解不一致。
什么情况下应该取消下游任务，而不是顺延？
当下游任务因前置延期失去原有意义，或原定时间窗口已错过且没有替代窗口时，才考虑取消或大幅改期。这类决定需要说明触发条件，由任务负责人、下游团队负责人和相关决策人共同确认，确认前保留原排期记录以便追溯。仅因时间紧张就取消任务，容易把必要工作挤到更晚，反而增加后续风险。
调整后怎么判断排期真的恢复了？
看下一次实际交接，而不是看排期表是否好看。选择最近的交接点或里程碑作为检查点，观察前置任务是否按新时间交付、下游是否按新时间启动、交接标准是否被双方认可。三项都符合，说明调整有效；如果检查点再次延误，说明原因判断或压缩方案有偏差，应回到原因排查环节重新评估，而不是继续给下游加缓冲时间。
