前置任务延期后，下游任务的处理顺序是：先确认延期事实和影响范围，再按依赖类型分别调整。硬依赖需要顺延并重排下游工作项，软依赖可以评估并行或缩小范围，跨团队交接项要重新约定交付时间与验收口径。本文聚焦工作项层面的调整与交接安排，项目整体进度基线的编制、人员容量调配不在讨论范围内。
要点总览（TL;DR）
- 先收集等待与阻塞标记、交接未确认、下游带假设开工三类信号，形成受影响工作项清单，再按依赖关系逐条核对范围。
- 原因排查从外部输入开始，再查验收标准与交接责任，最后核对工作量估算；每类假设都要有对应证据，并区分真实依赖与人为串联。
- 硬依赖顺延并沿依赖链重排后续工作项，软依赖评估并行、拆分或缩小范围，跨团队交接重新约定交付时间、验收口径与责任人。
- 压缩测试验收时间、取消交接确认、硬依赖改并行等改动需先确认再执行；调整后更新依赖、计划时间与状态，并向上下游同步变更。
- 用关键节点达成、下游从等待转为推进、交接确认记录完整三项结果验证恢复，并通过提前预警减少下次延期的影响。
延期影响出现在哪些工作项上
判断影响范围，先看信号，再看链条。前置任务延期通常不会只表现为一句口头通知，它会同时出现在几个地方：下游工作项状态停在“等待”或“阻塞”，负责人没有收到可开工的输入，交接环节的确认记录缺失，或者下游已经开始但反复返工。把这些信号收集起来，才能形成一份可核对的影响清单。
从三个信号定位受影响工作项
- 等待与阻塞标记：检查所有依赖该前置任务的工作项，看状态是否处于等待上游输入、被阻塞或长期未推进。标记本身说明工作项已感知到依赖，但还需要确认阻塞是否真实存在。
- 交接未确认：跨团队交接项如果只有“已发出”而没有“已接收、已确认”，就属于未完成的交接。前置任务延期时，这类交接项最容易被漏掉，因为双方都以为对方在推进。
- 下游已开工但输入不全：部分下游任务提前启动，靠假设或部分输入推进。这类工作项表面正常，实际风险最高，需要单独列出并核对已使用的输入是否仍然有效。
区分受影响与不受影响的工作项
影响范围要按依赖关系逐条核对，不能按团队或项目整体笼统判断。一个工作项是否受影响，取决于它是否直接或间接消费了延期任务的产出。直接依赖的前置产出未交付，属于确定受影响；间接依赖要看中间环节是否已经完成并冻结。与延期任务共享资源但无交付依赖的工作项，通常不列入本次调整范围，可另行观察。
跨团队交接场景下，判断口径要更具体：交接的是可验收的交付物，还是阶段性信息？交付物未到，下游无法开始或无法验收，应列入受影响清单；阶段性信息未到，下游可以先做不受影响的部分，列入“部分受影响”并标注可推进的边界。清单建议包含工作项名称、依赖对象、当前状态、受影响程度、责任人五项，作为后续调整的输入。
延期原因分类与排查证据
原因排查的目的是让调整有依据，避免把所有延期都当成“时间不够”处理。常见原因可以归为四类假设，每类都需要对应的证据来确认或排除。排查顺序建议从外部输入开始，再查验收标准与交接责任，最后核对工作量估算，因为外部因素往往影响面最大、确认成本最低。
| 原因假设 | 验证证据 | 排查顺序 |
|---|---|---|
| 上游工作量低估 | 实际投入工时与估算对比、任务拆分粒度记录、中途新增需求清单 | 第三 |
| 外部输入未到 | 外部依赖方的交付记录、接口或数据到位时间、等待时长记录 | 第一 |
| 验收标准不清 | 验收条款原文、返工次数、双方对完成定义的分歧记录 | 第二 |
| 交接责任不明 | 交接记录中责任人字段、确认回执、问题归属的沟通记录 | 第二 |
区分真实依赖与人为串联
排查中常会发现一种情况：下游任务标注了依赖，但实际上并不需要等前置任务全部完成。这类人为串联会放大延期影响。验证方法是问三个问题：下游真正需要的是前置任务的哪一部分产出？这部分产出能否提前单独交付？如果不等，下游会承担什么具体风险？如果风险可以接受或可以通过其他方式规避，这条依赖就应从硬依赖降级为软依赖，或在计划中改为部分并行。
原因确认后要留下记录，写清假设、证据和结论。记录的作用不只是解释这次延期，还为后续调整提供依据：外部输入问题对应的是重新约定外部交付时间，验收标准问题对应的是补充完成定义，交接责任问题对应的是明确责任人和确认方式。不同原因对应的调整动作不同，混在一起处理容易只改时间、不改机制。
按依赖类型调整下游任务
调整动作按依赖类型分开处理，避免一刀切顺延。硬依赖、软依赖和跨团队交接项的处置方式不同，风险边界也不同。以下步骤可按受影响工作项清单逐条执行。
硬依赖：顺延并重排后续工作项
- 确认前置任务新的可交付时间，并区分“最早可能交付”和“承诺交付”两个时间点，下游排期以后者为准。
- 将直接下游工作项的开始时间顺延到新交付时间之后，预留必要的接收与确认时间。
- 沿依赖链向后检查间接下游工作项，逐项重排开始与结束时间，避免只改第一层、后面仍然按旧日期排。
- 检查重排后是否出现新的时间冲突或关键节点挤压，把冲突项单独标出，交给相关责任人确认。
软依赖：评估并行、拆分或缩小范围
软依赖的调整空间更大，但需要明确取舍。常见做法有三种：一是并行推进，下游先用已有输入做不受影响的部分，等前置产出到位后再补齐；二是拆分工作项，把不依赖前置产出的子任务提前，把依赖部分单独排期；三是缩小本次范围，先交付可验收的最小部分，其余部分另行安排。三种做法都要写清前提条件，例如并行推进需要确认已有输入不会因前置任务变更而失效。
跨团队交接：重新约定交付时间、验收口径与责任人
跨团队交接项的调整不能只改日期，还要把三件事重新说清：交付时间以哪个时间点为准，验收口径是否因延期发生变化，双方各自的责任人是谁。建议以书面确认的方式完成，内容包括新的交付时间、交付物清单、验收标准和确认人。如果延期导致交付物范围变化，验收口径要同步更新，避免下游按旧标准验收、上游按新范围交付。
调整时的风险边界
以下改动建议先确认再执行：压缩下游任务的测试或验收时间、取消已约定的交接确认环节、把硬依赖直接改为并行、调整涉及外部团队的交付承诺。这些改动会影响交付质量或对外承诺，需要由相应责任人确认后再落到计划中。仅调整内部工作项顺序、补充说明字段、更新状态标记这类改动，可由工作项负责人直接执行。
调整动作落到工作项上时，依赖关系、计划时间和状态字段需要同步更新，否则清单和实际计划会脱节。在 ONES 中，工作项之间的依赖关系、计划时间与状态可以在同一处维护，交接确认也可以随工作项记录留存，便于调整后按依赖链核对哪些下游项已重排、哪些交接已重新确认。具体依赖类型的设置方式以实际使用环境为准。
调整后的同步与验证
调整完成不等于恢复完成。需要把变更同步到位，并用可核对的记录验证下游是否真正恢复推进，否则容易出现计划已改、执行仍按旧节奏的情况。
同步清单
- 更新受影响工作项的依赖关系，删除已失效的依赖，补充新识别的依赖。
- 更新计划开始与结束时间，并标注本次调整的原因和调整人。
- 更新工作项状态，把仍处于等待或阻塞的项改为可推进或明确新的等待条件。
- 向上下游及相关团队同步变更内容：改了什么、为什么改、新的时间点是什么、需要对方做什么。
- 对跨团队交接项，同步新的交付时间、验收口径和双方责任人，并取得确认回执。
恢复验证方法
验证恢复情况，看三个可观察的结果：关键节点是否按新计划达成，下游工作项是否从等待转为实际推进，交接确认记录是否完整。建议在新交付时间点之后的一个检查周期内逐项核对，发现仍未推进的工作项，回到影响清单重新判断是依赖未解除还是出现了新问题。
复盘时重点沉淀两类做法：一是在依赖建立时就写清依赖的是哪部分产出、需要什么确认，减少人为串联；二是在关键节点前设置提前预警，例如前置任务进度落后到一定比例时自动提醒下游负责人。预警阈值和检查频率可按项目节奏设定，目的是让下游在延期发生前就有调整余地，而不是等交付日才发现。
常见问题
前置任务延期后，下游任务要不要全部顺延？
不需要全部顺延。先按依赖关系逐条核对：直接消费延期任务产出的工作项属于确定受影响，需要顺延；间接依赖要看中间环节是否已完成并冻结；与延期任务共享资源但没有交付依赖的工作项，通常不列入本次调整范围。软依赖还可以评估并行推进、拆分工作项或缩小本次范围，把顺延范围控制在真正受影响的工作项上。
跨团队交接项延期，只改交付日期够不够？
不够。跨团队交接项除了交付时间，还要重新确认三件事：交付时间以哪个时间点为准，验收口径是否因延期发生变化，双方各自的责任人是谁。建议以书面方式确认，内容包括新的交付时间、交付物清单、验收标准和确认人。如果延期导致交付物范围变化，验收口径要同步更新，避免下游按旧标准验收、上游按新范围交付。
怎么判断一条依赖是真实依赖还是人为串联？
可以问三个问题：下游真正需要的是前置任务的哪一部分产出？这部分产出能否提前单独交付？如果不等，下游会承担什么具体风险？如果风险可以接受，或能通过其他方式规避，这条依赖就应从硬依赖降级为软依赖，或在计划中改为部分并行。排查时把假设、证据和结论记录下来，后续调整才有依据。
调整后下游任务仍停在等待状态，应该怎么处理？
先回到影响清单重新判断：是依赖关系没有解除，还是出现了新问题。检查前置任务的新交付时间是否已确认、依赖关系是否已更新、交接确认是否已取得回执。如果依赖已解除但工作项仍未推进，需要确认负责人是否收到变更通知、新的开始时间是否已写入计划。建议在新交付时间点之后的一个检查周期内逐项核对，避免计划已改、执行仍按旧节奏。
哪些调整需要先确认再执行？
影响交付质量或对外承诺的改动建议先确认再执行，包括压缩下游任务的测试或验收时间、取消已约定的交接确认环节、把硬依赖直接改为并行、调整涉及外部团队的交付承诺。这类改动需要由相应责任人确认后再落到计划中。仅调整内部工作项顺序、补充说明字段、更新状态标记这类改动，可由工作项负责人直接执行。
