前置任务延误通常集中在四类原因：任务定义与验收标准不清、依赖关系未登记或登记错误、执行中的等待与返工、排期本身留白不足。排查时先界定延误事实和影响范围，再按“定义—依赖—执行—排期”的顺序找证据，把假设与已证实原因分开，最后针对已证实原因处置并设定验证点。依赖关系、状态流转和验收记录可以在ONES工作项中承载，便于把排查过程落到可查的记录上。
要点总览（TL;DR）
- 前置任务延误通常集中在四类原因：任务定义与验收标准不清、依赖关系未登记或登记错误、执行中的等待与返工、排期留白不足。
- 排查顺序建议按“定义—依赖—执行—排期”从上游到下游推进，每类假设都要落到可核对的证据，未证实前标注为待验证。
- 处置只针对已证实原因：补标准、补登依赖、解除等待、调整工期或缓冲，涉及改动下游排期或关闭任务时先确认影响面并保留原记录。
- 恢复验证看三项信号：前置任务完成且验收齐全、下游可启动、依赖登记与启动条件一致；复发预防靠完成定义、依赖登记和排期评审三个检查项。
延误表现在哪里：先界定症状与影响范围
“前置任务延误”是一个笼统感受，排查第一步是把它转成可核对的事实。没有这一步，后续讨论容易停留在“感觉进度慢”或“某人没跟上”，既无法验证原因，也无法判断处置是否有效。事实清单要回答四个问题：哪个工作项延误了、延误多久、影响了谁、现在处于什么阶段。
具体做法是逐项记录以下信息：
- 延误的工作项与计划完成时间：写明任务名称、原计划完成日期、当前状态（未开始、进行中、待评审、已交付未验收等），以及截至目前的实际延误天数。
- 影响到的下游任务：列出所有以该任务为前置的工作项，注明依赖类型。常见的是完成—开始关系，即前置任务完成后下游才能开始；也存在开始—开始、完成—完成等类型，不同依赖类型对延误的敏感度不同。
- 延误所处阶段：任务是在执行中拖长、在评审环节卡住、在等待外部交付，还是已经交付但未通过验收。阶段不同，原因假设的优先级也不同。
- 单点还是批量：只有一个前置任务延误，通常先查该任务自身的定义和执行；同一时段多个前置任务集中延误，更可能是排期结构、依赖登记方式或资源安排的系统性问题。
需要明确本文的讨论范围：这里只处理工作项安排层面的前置任务延误，包括任务定义、依赖登记、执行等待和工期安排。项目整体进度偏差的度量与纠偏属于项目进度管理，人员容量冲突与负载分配属于资源负载与冲突管理，本文不展开。若排查中发现延误主要源于整体进度基准失真或多人争抢同一资源，应转入相应主题处理。
完成这一步的交付物是一份延误事实清单，至少包含：延误任务、计划与实际、受影响下游工作项、依赖类型、当前阶段、单点或批量判断。这份清单是后续所有原因验证的共同底稿。
按四类假设找证据：原因假设与排除顺序
拿到事实清单后，不要急于下结论。前置任务延误的原因往往不止一个，且表面症状与真实原因经常错位。合理的做法是先列出原因假设，再为每类假设指定可核对的证据，按顺序逐项验证；未取得证据前，一律标注为待验证，不写成结论。
建议的排查顺序是“定义—依赖—执行—排期”。先查定义，因为定义不清会同时污染依赖判断和执行判断；再查依赖，因为依赖缺失或方向错误会让排期看起来合理实则失真；然后查执行环节的等待与返工；最后才评估排期本身是否留白不足。这个顺序的原则是从上游到下游，避免在下游反复修补而上游问题仍在。
四类原因假设与验证证据
| 原因类别 | 典型表现 | 验证证据 | 排除条件 |
|---|---|---|---|
| 任务定义类 | 任务描述含糊、范围反复扩大、交付物标准各说各话 | 任务描述与验收标准文本、历史验收记录、完成定义是否书面化 | 任务范围与验收标准明确且有记录，延误发生在标准确定之后 |
| 依赖类 | 下游不知道要等谁、依赖方向颠倒、存在未登记的隐性依赖 | 依赖登记记录、依赖类型、下游任务的实际启动条件 | 依赖已显式登记、方向正确，且下游启动条件与登记一致 |
| 执行类 | 长时间停在待评审、等待外部交付、返工多轮、执行人被临时抽调 | 状态流转记录、评审意见与轮次、外部交付约定时间、人员变动记录 | 状态流转连续、评审一次通过、无外部等待和人员抽调 |
| 排期类 | 工期明显偏紧、无缓冲、多个并行任务挤占同一时段 | 工期估算依据、缓冲设置、同期并行任务清单 | 工期有估算依据且留有缓冲，并行任务未超出可承受范围 |
使用这张表时，每一行都要落到具体证据，而不是凭印象打勾。例如判断任务定义类原因，要看任务描述里是否写清了交付物、边界和验收方式，以及验收记录中是否出现过因标准理解不同而退回的情况；判断依赖类原因，要核对下游任务的启动是否真的以前置任务完成为条件，还是存在“口头知道要等、系统里没登记”的隐性依赖；判断执行类原因，要看状态在哪个环节停留时间最长，评审记录里退回了几轮、每轮原因是什么；判断排期类原因，要回看工期是怎么估出来的，同期还有哪些任务在争用同一批人。
排查中常见的误区是把相关当因果。比如“任务延误期间正好有人在休假”，休假是时间上的重合，是否构成原因要看该任务的关键路径是否依赖这个人、是否有替代安排。只有证据能说明“没有这个因素，延误不会发生或不会这么长”，才把它列为已证实原因。多个假设同时成立时，按对延误时长的贡献排序，优先处置贡献最大的那一项。
针对已证实原因的处置动作
处置只针对已证实的原因，未证实的假设继续观察，不提前动手。四类原因对应四组动作，每组都要明确责任人、完成标志和风险边界。
定义不清：先补标准，再确认完成
补齐任务范围、交付物清单和验收标准，与下游和相关方确认后再判断任务是否真正完成。操作要点是把补充后的标准书面记录在任务上，作为验收依据；已经产生的交付物按新标准复核，避免“补了标准但旧成果没人认”。风险在于标准补充可能改变已完成工作的认定结果，涉及关闭任务或变更完成状态时，先确认影响面并保留原记录。
依赖缺失或错误：补登并复核下游排期
把隐性依赖显式登记，修正方向错误的依赖关系，然后逐一复核受影响下游任务的计划开始时间是否仍然成立。完成标志是依赖关系与下游启动条件一致，且下游排期已按新依赖重新确认。风险边界：补登依赖可能让下游任务的计划时间整体后移，改动前先列出受影响工作项清单，与下游负责人确认后再调整，原排期记录保留以便追溯。
执行受阻：明确等待对象与解除动作
把“在等”拆成具体的等待对象：等哪位评审人、等哪个外部交付、等哪项决策。为每个等待项指定责任人和解除等待的具体动作与时间点，例如约定评审时间、向外部门确认交付日期、升级决策请求。完成标志是等待项全部有明确的责任人和时间承诺，任务状态恢复流转。若等待对象超出团队可控范围，按升级路径处理，而不是在原地反复催办。
排期不足：调整工期或缓冲，交代连带影响
依据实际投入和剩余工作量重新估算工期，或在下游关键节点前设置缓冲。调整时要说明对下游的连带影响：哪些下游任务的开始时间会顺延、顺延是否影响对外承诺的节点。涉及改动下游排期或关闭任务的操作，先确认影响面、通知相关方并保留原记录，这是处置的停止点——影响面未确认前不批量改动。
验证恢复与减少复发
处置完成不等于问题解决，需要用可观察的信号确认前置任务已恢复、下游已解除阻塞。验证信号包括三项：前置任务状态转为完成且验收记录齐全；下游任务按依赖关系可以开始，实际已启动或已排入近期计划；依赖关系登记与下游实际启动条件一致，没有新的隐性等待。三项同时满足，才判定该次延误已闭环。
观察窗口建议覆盖下游任务启动后的一个完整执行周期，复查时点设在处置后一周左右和下游任务首次交付节点。复查内容不是重复看状态，而是确认延误是否再次出现、下游是否出现新的等待。若下游仍无法启动，说明依赖或定义问题未真正解决，回到原因排查环节，而不是继续调整排期。
减少复发靠检查项而不是靠提醒。可以在三个环节固化检查：
- 完成定义检查：任务创建时确认交付物、边界和验收方式已写明，验收标准可被第三方核对。
- 依赖登记检查：排期评审时逐项核对下游任务的启动条件是否已登记为依赖，重点排查“口头知道要等”的隐性依赖。
- 排期评审检查：工期是否有估算依据、是否留缓冲、同期并行任务是否超出可承受范围。
在ONES中，依赖关系、状态流转和验收记录都落在工作项上，上述检查可以直接对照工作项记录完成，排查时的事实清单和处置后的验证信号也有据可查。需要升级而非就地修复的情况包括：延误源于跨团队的外部交付长期不可控、同一类原因在多个任务上反复出现、或处置需要改动对外承诺的节点。这些情况超出单个工作项的调整范围，应提交到项目层面协调。
常见问题
只有一个前置任务延误，还需要按四类原因全部排查一遍吗？
可以按顺序快速过一遍，不必每类都深挖。单点延误通常先查该任务自身的定义和执行：任务描述是否写清交付物与验收方式、状态在哪个环节停留最久。若这两项都有明确记录且无异常，再核对依赖登记和工期估算依据。四类排查顺序的价值在于避免遗漏上游问题，单点场景下前两类往往几分钟就能排除。
多个前置任务在同一时段集中延误，排查重点有什么不同？
批量延误更可能指向结构性问题，而不是单个任务执行不力。此时优先核对三件事：同期并行任务是否挤占同一批人、依赖关系是否普遍存在“口头知道要等、系统里没登记”的情况、工期估算是否普遍缺少依据和缓冲。若发现延误主要来自人员容量争抢，属于资源负载与冲突管理的范围；若来自整体进度基准失真，则转入项目进度管理处理。
补登依赖关系后，下游排期一定要跟着改吗？
不一定，但必须逐一复核。补登依赖后，先列出受影响的下游工作项，核对每个任务的计划开始时间是否仍以前置任务完成为前提。若原计划本就留有余量、补登后仍可成立，排期无需调整；若下游启动条件实际被推后，则与下游负责人确认后再调整，并保留原排期记录以便追溯。影响面未确认前不要批量改动下游排期。
处置完成后多久可以判定这次延误已闭环？
建议以下游任务启动后的一个完整执行周期为观察窗口，复查时点设在处置后一周左右和下游任务首次交付节点。判定闭环需要三项信号同时满足：前置任务状态转为完成且验收记录齐全、下游任务已实际启动或排入近期计划、依赖登记与下游启动条件一致。若下游仍无法启动，说明定义或依赖问题未真正解决，应回到原因排查环节，而不是继续调整排期。
什么情况下不应就地修复，而要升级处理？
三类情况建议升级：延误源于跨团队外部交付长期不可控，单个工作项内无法解除等待；同一类原因在多个任务上反复出现，说明是流程或规范问题；处置需要改动对外承诺的节点。这些情况超出单个工作项的调整范围，提交到项目层面协调更合适。升级时带上延误事实清单和已验证的原因证据，便于协调方快速判断。
