临近截止发现任务做不完，排查顺序应当是先查前后置依赖，再查估算偏差。依赖属于硬约束：前置任务未完成、交付物未到位或外部等待未解除时，后续工作根本无法按原计划开始，估算再准也改变不了不可行的事实。依赖链确认通畅后，再核对剩余工作量是否被低估，并同步排查范围变更和优先级调整这两类伴随原因。本文只讨论单个或一组工作项的排期与依赖，项目整体进度和人员容量冲突不在范围内。
要点总览（TL;DR）
- 排查顺序是先查前后置依赖，再查估算偏差：依赖是硬约束，前置未完成时任务无法开工，估算再准也改变不了不可行的事实。
- 依赖链排查从当前任务向上追溯，逐项确认前置状态、交付物和预计解除时间，同时把口头约定、跨团队等待等隐性依赖补登为显式记录。
- 依赖通畅后再核对估算：对比原估算与实际已投入工时，重新估算剩余工作量，并区分估算偏低与执行偏离，两者处置方式不同。
- 范围变更和优先级调整常与依赖、估算问题叠加，需用需求变更记录、描述修改历史和优先级变更记录对照确认。
- 处置按依赖解除、估算修正、范围取舍、计划重排推进；裁剪范围或延期须经需求方确认，对外承诺的截止日期变更须走审批。
症状与范围：先确认“做不完”具体指什么
“做不完”是一句笼统的判断，直接进入原因分析容易查错方向。先把当前情况归入具体症状，后续排查才有明确对象。常见症状有三类：剩余工作量明显超出剩余时间；关键前置未完成，任务迟迟无法开工；截止前范围被追加，工作量在原估算之外增长。三类症状可能同时出现，归类时按影响程度排序，优先处理让任务无法开始的那一类。
截止日期已多次调整，本身就是一个重要信号。它说明原计划在执行过程中反复被推翻，存在未被识别的不确定性，可能是依赖没有提前暴露，也可能是估算过于乐观。排查时把每次调整的时间和原因找出来，能帮助判断问题从哪一次调整开始累积。
排查边界需要提前说清。本文聚焦工作项层面的排期与依赖：某个任务为什么做不完、卡在哪里、如何重排。项目整体进度偏差属于项目进度管理的范畴，人员被多个任务争抢导致的容量冲突属于资源负载与冲突管理，这两类问题不在本文展开，遇到时应转入对应主题处理。
| 症状 | 典型表现 | 初步归因方向 |
|---|---|---|
| 剩余工作量超出剩余时间 | 任务已开工，投入后仍看不到完成点 | 估算偏差、范围变更 |
| 关键前置未完成 | 任务长期未开始或处于阻塞状态 | 前后置依赖 |
| 范围在截止前被追加 | 需求、验收标准或交付物在近期扩大 | 范围变更、优先级调整 |
为什么先查依赖：硬约束优先于工作量判断
依赖是排期中的硬约束。前置任务没有完成、上游交付物没有交付、外部审批没有通过，后续工作就没有开始的条件。这种情况下，剩余时间再多也无法转化为产出，讨论估算准不准没有意义。先查依赖，是用最低成本排除“任务根本不可能按原计划推进”这一前提；前提不成立，后面的工作量判断都建立在错误基础上。
依赖链的排查从当前任务向上追溯。打开当前工作项，逐项列出它依赖的前置工作项，确认三件事：前置任务当前处于什么状态，约定的交付物是否已经交付，预计什么时候能解除等待。追溯时不要只看直接前置，隔一层的前置如果已经延期，同样会传导到当前任务，需要一并记录。
隐性依赖是最容易被漏掉的部分。口头约定的配合、跨团队的等待、环境或数据准备，常常没有登记在工作项里，却在关键时刻卡住进度。排查时向参与执行的成员逐一确认“你还在等谁、等什么”，把口头依赖补登为显式记录，后续才能跟踪。
依赖排查需要留下证据，而不是凭印象判断。可用的证据包括：前置工作项的状态记录、交付物的签收或确认记录、当前任务处于等待状态的时长。一个典型信号是：任务长期处于未开始或阻塞状态，而估算工时并不大——这基本指向依赖受阻，而非工作量低估。
| 排查项 | 需要确认的内容 | 证据形式 |
|---|---|---|
| 直接前置任务 | 状态、交付物、预计完成时间 | 工作项状态记录 |
| 间接前置任务 | 是否已延期、延期是否传导 | 依赖链上的状态与时间 |
| 隐性依赖 | 口头约定、跨团队等待、环境准备 | 成员确认后补登的记录 |
| 等待时长 | 任务阻塞了多久 | 状态变更时间戳 |
依赖链清单整理出来后，每项前置都应有明确的状态、交付物和预计解除时间。清单里只要还有一项前置无法给出解除时间，就应先推动它，而不是转去核对估算。在ONES中，工作项可以登记前后置依赖关系，前置状态和阻塞时长在同一处可见，依赖链清单可以直接基于这些记录整理，减少口头追溯的遗漏。
依赖排除后，如何核对估算偏差
依赖确认通畅、任务具备开工条件之后，才进入估算核对。核对方法是把原估算与实际已投入工时放在一起比较，再对剩余工作重新估算，看三者是否自洽。如果已投入工时接近或超过原估算，产出却只完成一部分，说明原估算偏低；如果多个任务都出现类似偏差，则可能是系统性偏低，需要在后续排期中整体调整估算口径。
估算偏差有几个常见来源。遗漏测试与联调时间，是开发类任务最典型的低估原因；未计入评审返工，会让“完成”之后又出现一轮修改；对不熟悉的技术栈或业务领域估计过于乐观，实际耗时往往是估算的数倍。核对时逐项对照这些来源，判断本次偏差主要由哪一类造成。
估算偏低与执行偏离要分开处理。执行偏离的表现是已投入工时远超估算，但产出有限，问题出在执行过程本身，比如方向反复、返工频繁、外部干扰过多，需要单独分析执行环节。估算偏低则是工作量判断本身不准，处置方式是修正剩余工作量的估算并调整计划。两者混在一起，会导致修正估算后问题依然存在。
核对结论应包含三项内容：偏差幅度、主要来源、修正后的剩余工作量。修正后的剩余工作量是后续判断截止日期是否可行的依据，也是范围取舍讨论的输入。
范围变更与优先级调整：两类常被忽略的伴随原因
依赖和估算排查完之后，还要检查范围与优先级是否发生了变化。范围变更指截止前新增需求、验收标准提高或交付物扩展，工作量在原估算之外增长。这类变化往往以“顺便加一个”的形式出现，单次影响不大，累积起来足以让原计划失效。识别证据包括需求变更记录、工作项描述的修改历史、验收标准的版本差异。
优先级调整从另一个方向影响排期。任务被降级后，执行资源可能被抽走，可用时间被压缩；任务被升级后，截止日期可能被提前，同样压缩了可用时间。识别证据是优先级字段的变更记录，以及变更前后投入人力和时间的变化。
这两类原因常与依赖、估算问题叠加出现。范围变更会制造新的依赖，比如新增需求需要另一个团队提供接口；优先级调整会改变依赖链上各环节的可用时间，让原本可行的顺序变得不可行。因此排查时不能只看单一原因，要把变更记录与依赖链、估算结论对照，确认它们是否互相放大。
| 原因类型 | 识别证据 | 对排期的影响 |
|---|---|---|
| 范围变更 | 需求变更记录、描述修改历史、验收标准变化 | 工作量在原估算外增长，可能新增依赖 |
| 优先级调整 | 优先级字段变更记录、投入人力变化 | 可用时间被压缩或资源被抽走 |
按判断顺序处置：从依赖解除到计划重排
原因确认后，处置按依赖、估算、范围、计划的顺序推进，每一步都有明确的动作、责任人和停止点。
第一步处置依赖。对每项未解除的前置，明确推动方式：由谁跟进前置任务的完成，或者调整依赖关系绕开它。每项前置都要给出解除时间和责任人，解除时间无法确定的，视为风险项上报。这一步的停止点是：所有前置都有明确的解除时间，或已确认可以绕开。
第二步修正估算。基于重新估算的剩余工作量，判断原截止日期是否仍然可行。判断时把剩余时间按可用工作日折算，扣除已安排的评审、联调等固定环节，得出实际可用的工作时间，再与修正后的剩余工作量比较。结论只有两种：可行，或不可行。
第三步范围取舍。时间不可延的情况下，与需求方确认可裁剪的范围和验收底线。裁剪的对象优先选择对核心目标贡献小的功能和可以后置的优化项，验收底线则要明确哪些内容必须保留。这一步的停止点是：需求方书面确认裁剪后的范围。
第四步重排计划。更新工作项的截止日期、依赖关系和优先级，把新的排期同步给执行成员、需求方和下游依赖方。同步时说明变更原因和新的关键节点，避免下游按旧计划安排工作。
处置过程有明确的风险边界。裁剪范围或延期必须经需求方确认，执行方不能单方面决定；涉及对外承诺的截止日期变更，须走相应审批流程。越过这两条边界，处置结果不具备约束力，后续还会反复。
| 步骤 | 动作 | 责任人 | 完成标志 |
|---|---|---|---|
| 处置依赖 | 推动前置完成或调整依赖关系 | 任务负责人 | 每项前置有解除时间和责任人 |
| 修正估算 | 重新估算剩余工作量，判断截止日期可行性 | 任务负责人与执行成员 | 得出可行或不可行的结论 |
| 范围取舍 | 与需求方确认裁剪范围和验收底线 | 任务负责人与需求方 | 需求方确认裁剪方案 |
| 重排计划 | 更新截止日期、依赖和优先级并同步 | 任务负责人 | 相关角色收到新计划 |
这些处置动作依赖准确的记录。ONES工作项支持登记依赖关系、记录工时和变更历史，依赖解除时间、修正后的估算和范围裁剪结论可以留在同一工作项下，重排后的计划与变更原因也能对应上，便于后续复盘时还原判断过程。
验证恢复与复发预防
处置完成后，需要验证计划是否真正恢复可行。可观察的信号有三个：依赖项按约定的解除时间解除，没有再次延期；修正后的剩余工作量与剩余时间匹配，执行中不再出现明显缺口；新计划下的关键节点按期达成。三个信号中任何一个不成立，说明处置不彻底，需要回到对应步骤重新处理。
复发预防从排期环节入手。排期时显式登记依赖关系，把口头约定和跨团队等待补登为工作项之间的依赖，避免隐性依赖在截止前才暴露。对不熟悉的任务采用区间估算，给出乐观和悲观两个值，按悲观值安排时间。截止日期前设置若干中间检查点，在每个检查点核对依赖状态和剩余工作量，让问题提前暴露。
检查点的设计要与任务的实际节奏匹配。长周期任务可以按阶段设置里程碑，短周期任务至少在中期设置一次检查。检查内容固定为两项：前置是否按计划解除，剩余工作量与剩余时间是否仍然匹配。检查结果记录下来，作为下一次排期的参考。
每次处置结束后做一次简短复盘，把本次的原因归类结果沉淀为排期检查项。比如本次是隐性依赖导致阻塞，就在检查项中加入“确认所有等待对象已登记”；本次是测试环节遗漏，就在估算模板中加入测试与联调的固定工时。检查项积累起来，同类问题在下次排期时就能提前识别。
常见问题
任务长期处于阻塞状态，但估算工时并不大，这种情况该先查什么？
这种表现基本指向依赖受阻，而不是工作量低估。任务长期未开始或处于阻塞状态，说明它缺少开工条件，此时核对估算没有意义。先向上追溯前置工作项，确认状态、交付物和预计解除时间；同时向执行成员确认是否在等口头约定、跨团队配合或环境数据准备，把这些隐性依赖补登为显式记录。前置全部有明确解除时间后，再进入估算核对。
依赖已经排除，重新估算后剩余工作量仍然超出剩余时间，下一步怎么办？
先判断偏差性质。如果已投入工时远超原估算但产出有限，问题可能在执行环节，需要单独分析返工和干扰来源；如果多个任务都系统性偏低，则修正估算口径。修正后的剩余工作量仍超出剩余时间时，进入范围取舍：与需求方确认可裁剪的功能和验收底线，优先裁剪对核心目标贡献小的部分。时间不可延且范围无法裁剪时，走延期审批，由需求方确认，执行方不单方面决定。
截止日期多次调整过，排查时要不要把每次调整的原因都找出来？
需要。多次调整说明原计划反复被推翻，存在未识别的不确定性。把每次调整的时间和原因列出来，能判断问题是哪一次开始累积的：如果某次调整后任务开始阻塞，可能引入了新依赖；如果每次调整都伴随需求追加，范围变更可能是主因。这些记录也是后续复盘和设置排期检查项的输入。
范围变更和优先级调整怎么和依赖、估算问题区分开？
看证据来源。范围变更有需求变更记录、工作项描述修改历史、验收标准版本差异；优先级调整有优先级字段变更记录和投入人力变化。这两类原因常与依赖、估算叠加：新增需求可能带来新的前置依赖，优先级降级会抽走资源、压缩可用时间。排查时把变更记录与依赖链清单、估算结论对照，确认是否互相放大，不要只归因于单一原因。
处置完成后，怎么判断新计划是否真的可行？
看三个信号：依赖项是否按约定时间解除且没有再次延期；修正后的剩余工作量与剩余时间是否匹配，执行中不再出现明显缺口；新计划下的关键节点是否按期达成。任一信号不成立，说明处置不彻底，回到对应步骤重新处理。为减少复发，排期时显式登记依赖、对不熟悉的任务采用区间估算，并在截止前设置中间检查点核对依赖状态和剩余工作量。
