前置任务延误时，先要分清是前置任务本身没完成，还是它的完成时间已经晚于后置任务的开始约束。两种情况影响范围不同，处理动作也不同。本文聚焦工作项层面的依赖与排期：先固定受影响范围，再用证据验证原因，按依赖强弱调整后置任务，最后用新的完成时间和依赖状态确认恢复。项目整体进度和人员容量冲突不在本文展开。
要点总览（TL;DR）
- 先固定受影响范围：列出延误的前置任务、依赖类型、受影响的后置任务及其原定开始时间，区分任务链问题与项目整体进度问题。
- 原因排查按依赖配置、执行过程、估算与承诺的顺序进行，每类假设都要有可查证据，结论只写成立、排除或待确认。
- 排期调整按依赖强弱处理：强依赖下等待或拆分前置交付物，弱依赖下并行推进，同时更新依赖关系、负责人和完成时间。
- 恢复验证看三个信号：前置任务状态已更新、后置任务按新排期启动、依赖配置与实际执行一致。
- 对影响多个后置任务的关键前置任务设置提前预警节点，并在复盘时记录原因分类，供后续估算和依赖设置参考。
先确认延误影响了哪些工作项
处理延误的第一步是把“前置任务延误”从笼统感受落到具体工作项上。需要回答三个问题：延误的是哪一个前置任务，它原计划何时完成、现在处于什么状态；哪些后置任务直接依赖它，这些后置任务是否已到计划开始时间；这次延误是单个任务链的问题，还是已经波及项目整体进度。前两类属于本文处置范围，若已影响项目整体里程碑，需要按项目级进度管理另行处理。
确认范围时，建议沿着依赖关系逐层展开，而不是只看直接下游。一个前置任务可能被多个后置任务依赖，也可能通过后置任务继续影响更下游的工作。把直接依赖和间接影响分开记录，后续调整排期时才能判断哪些任务必须等待、哪些可以先行处理。
可以用一张受影响工作项清单固定排查结果，字段建议如下：
| 前置任务 | 依赖类型 | 后置任务 | 原定开始时间 | 当前状态 |
|---|---|---|---|---|
| 接口联调完成 | 强依赖（完成后才能开始） | 前端页面集成 | 3月10日 | 未开始，已到计划开始时间 |
| 需求文档定稿 | 弱依赖（可先做部分工作） | 测试用例编写 | 3月8日 | 进行中，部分用例已编写 |
| 数据迁移脚本 | 强依赖 | 数据校验 | 3月12日 | 未开始，尚未到计划开始时间 |
清单完成后，范围就明确了：哪些后置任务已经受到影响，哪些还有缓冲时间。这份清单allon是后续原因排查和排期调整的共同输入，避免不同角色对“延误了什么”各说各话。
逐项验证延误原因，区分假设与证据
延误原因常见的有五类：工作量低估、等待外部输入、执行顺序冲突、依赖设置错误、完成标准未对齐。这些只是假设，不能直接当成结论。排查的价值在于用可查证据逐项确认或排除，而不是凭印象选一个最像的原因。
排查顺序建议从依赖配置开始，再看执行过程，最后核对估算与承诺。先查依赖配置，是因为如果依赖关系本身设置错了，后面所有关于执行和估算的分析都建立在错误前提上。例如后置任务实际并不需要等待前置任务全部完成，只是配置成了强依赖，那么真正的问题在依赖设置，而不在执行效率。
| 原因假设 | 可查证据 | 结论记录 |
|---|---|---|
| 依赖设置错误 | 依赖关系配置、依赖类型、后置任务实际所需的前置交付物 | 成立 / 排除 / 待确认 |
| 工作量低估 | 工作项变更记录、实际投入与原始估算对比、任务拆分粒度 | 成立 / 排除 / 待确认 |
| 等待外部输入 | 评论记录、附件更新时间、外部对接方的交付时间 | 成立 / 排除 / 待确认 |
| 执行顺序冲突 | 任务实际开始与完成时间、并行任务安排、负责人工作记录 | 成立 / 排除 / 待确认 |
| 完成标准未对齐 | 验收标准描述、评审记录、交付物与标准的差异说明 | 成立 / 排除 / 待确认 |
每类假设的证据来源不同。工作量低估要看变更记录和实际投入，而不是只看负责人说“比预想的多”；等待外部输入要看评论和附件的时间线，确认等待从哪天开始、对方承诺何时交付；执行顺序冲突要看任务实际起止时间，判断是否因为并行任务挤占了时间；完成标准未对齐则要对照验收标准和评审意见，确认是交付物不达标还是标准本身有歧义。
排查结论建议只写三种：成立、排除、待确认。待确认项要注明还需要什么证据、由谁提供。把假设和结论分开记录，可以避免在后续沟通中把推测当成事实，也能让复盘时有据可查。
按依赖关系调整后置任务排期
原因确认后，排期调整要按依赖类型分别处理。强依赖下，后置任务应当等待前置任务完成，或者把前置任务拆出后置任务真正需要的那部分先行交付。弱依赖下，后置任务可以并行推进，或者先做不依赖前置结果的部分，等前置交付后再补齐剩余工作。
具体处置可以按以下步骤进行：
- 判断依赖强弱。确认后置任务是否真的需要前置任务全部完成，还是只需要其中某个交付物。依赖类型与实际需要不一致时，先修正依赖关系，再谈排期。
- 能拆分前置任务时，优先拆分。把后置任务真正需要的那部分单独列出，作为先行交付项，其余部分按原计划推进。拆分后的交付物要有明确的完成标准，避免“部分完成”变成新的模糊状态。
- 更新后置任务的开始时间。强依赖下按前置任务新的预计完成时间顺延，并预留交接和确认时间；弱依赖下把可并行部分提前，把依赖部分单独排期。
- 同步更新依赖关系、负责人和新的完成时间。调整排期时，依赖关系、任务负责人、承诺时间三者要一起改，只改日期不改依赖，后续还会出现同样的判断偏差。
- 涉及取消或压缩范围时，明确风险和确认角色。压缩范围会影响交付质量或后续任务，需要由任务负责人和相关需求方共同确认，不能由执行人单方面决定。
调整后的排期方案应包含：每个后置任务的新开始时间、依赖处理方式（等待、拆分先行交付、并行推进）、需要确认的责任人。方案确定后，把新的时间写回工作项，让依赖关系和排期保持一致。在依赖关系较多、调整频繁的团队里，可以把前置任务和后置任务的依赖关系维护在工作项上，排期变化时同步更新状态和完成时间，减少口头同步造成的信息差。ONES 的工作项管理可以承载任务状态、负责人和时间字段，依赖关系的具体配置方式以团队实际使用的功能为准。
验证恢复并减少再次延误
排期调整完成不等于延误已经处置完毕。需要确认三个信号：前置任务状态已更新为实际进展，而不是停留在原计划；后置任务已按新排期启动，没有继续空等；依赖关系与实际执行一致，不存在“配置上还依赖、实际已经并行”的错位。三个信号都满足，才能判断这条任务链已经恢复。
恢复验证清单可以按以下条目逐项核对：
- 前置任务的当前状态、预计完成时间已更新，并与实际进展一致；
- 受影响的后置任务已按新开始时间启动，或已明确等待条件和预计启动时间；
- 依赖关系配置与调整方案一致，拆分出的先行交付项已单独建项或标注；
- 相关责任人都已知晓新的排期和交接安排；
- 若压缩了范围，风险已记录并由确认人签字或留痕。
减少再次延误，重点放在关键前置任务上。对影响多个后置任务的前置任务，设置提前预警节点，例如在计划完成时间前若干天检查进展，发现偏差立即启动原因排查，而不是等到后置任务开始日期才暴露问题。预警节点的时间间隔按任务周期长短确定，周期长的任务可以设多个检查点。
复盘时把本次延误的原因分类记录下来，归入依赖设置、估算偏差、外部等待、执行冲突或标准对齐中的一类。积累一段时间后，可以看到哪类原因反复出现：依赖设置问题多，说明排期时需要更仔细地核对依赖类型；估算偏差多，说明任务拆分和估算方法需要调整。原因分类记录的价值在于让下一次排期有参照，而不是每次延误都从零开始判断。
常见问题
前置任务延误后，后置任务应该继续等还是先启动？
取决于依赖强弱。强依赖下，后置任务需要等前置任务完成，或者把前置任务拆出后置任务真正需要的那部分先行交付；弱依赖下，后置任务可以先做不依赖前置结果的部分，等前置交付后再补齐。判断依据是后置任务实际需要什么交付物，而不是依赖关系上写了什么。如果依赖配置与实际需要不一致，先修正依赖关系再安排排期。
怎么判断延误是估算不准还是依赖设置有问题？
先查依赖配置，再查执行过程，最后核对估算。依赖设置问题表现为后置任务实际并不需要等待前置任务全部完成，却被配置成强依赖；估算问题则要看工作项变更记录、实际投入与原始估算的对比、任务拆分粒度。两类证据来源不同，排查顺序反了容易把配置问题误判成执行效率问题。
调整排期时只改日期可以吗？
不够。依赖关系、任务负责人、承诺时间三者要一起更新。只改日期不改依赖，后续判断哪些任务需要等待时还会出现同样的偏差；负责人和承诺时间不同步，相关角色仍按旧信息安排工作。调整后的方案应写回工作项，让依赖关系和排期保持一致。
压缩范围来追赶排期，需要谁确认？
压缩范围会影响交付质量或后续任务，需要由任务负责人和相关需求方共同确认，执行人不宜单方面决定。确认后把风险记录留痕，并在恢复验证时核对压缩范围是否已按约定执行。若压缩影响下游多个任务，还需要评估是否触发项目级进度调整。
延误处置完成后，怎么确认真的恢复了？
核对三个信号：前置任务状态已更新为实际进展，后置任务已按新排期启动或明确等待条件，依赖关系配置与实际执行一致。三个信号都满足，才能判断这条任务链恢复。之后在关键前置任务上设置提前预警节点，按任务周期长短确定检查间隔，避免等到后置任务开始日期才暴露问题。
