任务拆解完成后，执行到一半被卡住、多人重复返工，或验收时出现“做完了但不算完成”的争议，通常说明拆解中漏了依赖或验收条件。本文给出一条定位路径：先把症状归入缺口类型，再用输入输出关系、完成定义、交付物对应三条证据线交叉核对，定位到具体工作项后补齐并验证恢复。
要点总览（TL;DR）
- 先按症状归类：执行中途停滞、等待外部输入、重复返工多指向依赖遗漏；验收时出现“做完了但不算完成”的争议多指向验收条件缺失；范围反复扩大、环节无人承接多指向关键交付物漏拆。
- 用三条证据线交叉核对：工作项之间的输入输出关系、每个工作项的完成定义、交付物与上游目标的对应关系，任一条出现断点即为候选缺口。
- 定位顺序从受阻工作项反向追溯前置输入，再逐项核对完成定义并标记无法判定的工作项，最后对照交付物清单检查无人承接的环节；排查期间先记录、不修改。
- 补齐后重跑受阻环节确认输入输出闭环，验收条件与验收方确认口径，并把依赖与验收条件检查项固化到拆解评审中。
- 补齐过程中涉及交付范围变更时，先确认边界再调整，超出可执行工作项层面的范围问题回到项目范围管理处理。
遗漏依赖或验收条件时会出现哪些症状
“好像漏了什么”本身无法排查，需要先转成可观察的症状。遗漏依赖和遗漏验收条件在表现上有明显差异，把症状归类，可以缩小后续排查范围。
依赖遗漏的典型表现是执行中途停滞：某个工作项已经分配负责人、也进入了进行中状态，却迟迟无法产出结果，原因是等待另一份设计稿、接口约定、数据或审批。另一种表现是多人重复返工，两个工作项各自按自己的理解推进，合并时才发现输入不一致，只能回退重做。还有一种是前置产出无人负责：大家都认为某份材料“应该有人做”，但在工作项列表里找不到承接人。
验收条件缺失的表现集中在交付环节。工作项被标记为完成，评审时却被指出缺少必要内容，形成“做完了但不算完成”的争议；或者不同角色对同一交付物的合格标准理解不同，反复修改仍无法收敛。范围反复扩大也常与拆解缺口有关：关键交付物没有被单独拆出，执行中不断有人补充“还差这一块”，任务边界持续变化。
下表把常见症状与初步对应的缺口类型放在一起，便于快速归类。归类只是缩小范围，不能直接当作结论。
| 可观察症状 | 初步指向的缺口类型 | 需要进一步核对的证据 |
|---|---|---|
| 工作项进入进行中后长期停滞，等待外部输入 | 依赖遗漏 | 该工作项的输入来自哪个工作项，该工作项是否存在且有负责人 |
| 两个及以上工作项合并时输入不一致，导致返工 | 依赖遗漏或接口约定缺失 | 工作项之间的输入输出关系是否明确 |
| 某份前置产出找不到承接人 | 依赖遗漏或关键交付物漏拆 | 交付物清单中是否有对应条目 |
| 标记完成后评审不通过，争议集中在“算不算完成” | 验收条件缺失 | 该工作项是否有可判定的完成标准 |
| 执行中不断补充内容，任务边界持续变化 | 关键交付物漏拆 | 交付物与上游目标的对应关系是否完整 |
归类时要注意，同一症状可能对应多种缺口。例如“等待外部输入”既可能是依赖没写，也可能是前置交付物根本没被拆出来。因此症状对照表的作用是确定排查方向，最终结论要靠下一节的证据核对。
按原因假设逐条排查拆解缺口
把症状归入方向后，需要以假设的方式逐条验证，而不是直接认定“就是漏了依赖”。每条假设都应有对应的验证证据，证据成立才转为确认结论；证据不足时保留为待查项，继续收集。
假设一：依赖遗漏
验证方式是检查工作项的输入输出是否闭环。逐个查看受阻工作项，问三个问题：它需要什么输入才能开始或继续；这份输入由哪个工作项产出；那个工作项是否存在、是否有负责人、是否已排入计划。三个问题中任一答不上来，就构成依赖遗漏的候选证据。特别要关注“无人负责的前置产出”，这类缺口在列表中往往完全不可见，只能通过反向追问输入来源发现。
假设二：验收条件缺失
验证方式是检查每个工作项是否有可判定的完成标准。可判定的标准应当能让第三方在没有额外解释的情况下判断“达到”或“未达到”，例如明确的交付物清单、需要通过的评审、需要满足的指标口径。如果完成标准只写了“完成开发”“优化体验”这类无法判定的表述，就属于验收条件缺失的候选证据。核对时还要注意标准是否与提出验收的角色一致，避免开发按一种口径完成、验收方按另一种口径检查。
假设三：关键交付物漏拆
验证方式是对照交付物清单与上游目标，检查每个目标是否有工作项承接。做法是从目标出发逐条向下对应：这个目标需要哪些交付物，每个交付物对应哪个工作项。出现“目标有、交付物没有”或“交付物有、工作项没有”的断点，就是漏拆的候选证据。范围反复扩大的任务，往往在这一步能发现缺失的整块内容。
下表把三类假设、验证证据和确认条件并列，便于排查时逐条打勾。需要强调的是，表中“确认条件”满足之前，只能记为假设，不能写进结论或直接据此修改计划。
| 原因假设 | 验证证据 | 确认条件 | 常见误判 |
|---|---|---|---|
| 依赖遗漏 | 受阻工作项的输入来源、对应产出工作项及其负责人 | 存在必要输入但无对应产出工作项，或产出工作项无负责人 | 把“进度慢”直接当成依赖缺失 |
| 验收条件缺失 | 工作项的完成标准文本、验收方口径 | 完成标准无法判定，或与验收方口径不一致 | 把“评审意见多”直接当成标准缺失 |
| 关键交付物漏拆 | 交付物清单与上游目标的逐条对应 | 目标或交付物在工作项列表中无承接 | 把“范围变大”直接当成漏拆，未核对原始目标 |
三类假设可能同时成立。例如一个任务既缺前置依赖，完成标准也写得模糊，此时应分别记录，不要合并成一条模糊结论，否则后续补齐时容易只处理其中一类。
定位缺口的具体操作顺序
排查需要按固定顺序推进，避免边查边改导致计划混乱。建议先只记录、不修改，等缺口清单成型后再统一处置。
第一步，从受阻工作项反向追溯前置输入。选取当前停滞或返工的工作项，逐个追问“它需要什么才能继续”，把每项输入写下来，再标注该输入由谁产出。找不到产出方或产出方无负责人的，记为依赖缺口候选。追溯时沿着链条向上走，直到抵达已有明确产出和负责人的环节为止。
第二步，逐项核对完成定义，标记无法判定的工作项。对清单内每个工作项检查完成标准，凡是无法让第三方直接判断是否达成的，标记为验收条件待补。标记时记录当前标准的原文和无法判定的原因，便于后续与相关角色确认口径。
第三步，对照交付物清单检查是否有环节无人承接。从上游目标列出应交付的成果，与工作项列表逐条比对，找出没有工作项承接的交付物，以及没有对应目标的孤立工作项。后者可能意味着拆解时凭习惯添加了环节，也值得在评审中确认。
第四步，记录缺口并标注影响范围。每条缺口记录四项信息：缺口类型、涉及的工作项、影响的下游环节、初步处置建议。影响范围要写到具体工作项，而不是笼统写“影响整体进度”。排查期间保持计划不变，等缺口清单完整后再决定补齐顺序，可以避免改一处引发新的不一致。
记录表可以采用如下结构，排查时逐行填写：
| 缺口编号 | 缺口类型 | 涉及工作项 | 证据 | 影响的下游环节 | 处置建议 |
|---|---|---|---|---|---|
| G-01 | 依赖遗漏 | 接口联调任务 | 需要接口文档，但无对应产出工作项 | 联调、测试 | 补建文档工作项并指定负责人 |
| G-02 | 验收条件缺失 | 报表模块开发 | 完成标准为“开发完成”，无法判定 | 验收评审 | 与验收方确认可判定的交付清单 |
| G-03 | 关键交付物漏拆 | 上线准备 | 回滚方案无工作项承接 | 上线执行 | 补拆回滚方案工作项 |
排查过程中如果发现缺口涉及交付范围本身的调整，例如需要新增一个原目标中不存在的模块，应先暂停并确认边界，回到范围层面处理，不在执行层面直接扩大任务。
补齐依赖与验收条件后的验证与防复发
补齐缺口不等于问题解决，需要验证受阻环节是否恢复，并把检查动作固化到拆解评审中，降低再次遗漏的概率。
验证恢复
补齐依赖后，重跑此前受阻的环节，确认输入能够按时到位、输出能够被下游直接使用。验证的标志是输入输出闭环：每个工作项需要的输入都有明确产出方和交付时间，每个产出都有明确的下游使用方。如果重跑后仍出现等待或返工，说明依赖链上还有未发现的断点，需要回到上一节的追溯步骤继续排查。
补齐验收条件后，与验收方确认口径。可判定的标准应当写成具体条目，例如需要交付哪些内容、需要通过哪些检查、由谁确认。确认口径时最好让验收方直接参与，避免执行方单方面拟定标准后再次出现争议。确认完成后，用新标准回看已完成的工作项，判断是否需要返工。
防复发检查项
把本次发现的缺口类型转化为拆解评审的固定检查项，在每次拆解完成后逐条核对：
- 每个工作项的输入是否都有明确的产出工作项和负责人；
- 是否存在无人负责的前置产出；
- 每个工作项的完成标准是否可被第三方直接判定；
- 完成标准是否已与验收方确认口径；
- 交付物清单中的每一项是否都有工作项承接；
- 每个工作项是否都能对应到上游目标；
- 涉及范围调整的内容是否已确认边界后再进入执行。
这些检查项适合放在拆解评审的固定议程中，由评审人逐条确认，而不是依赖执行中临时发现。对于跨角色协作较多的任务，还可以在评审时邀请下游使用方参加，提前暴露输入输出关系上的分歧。
在工具层面，拆解结果需要能被持续查看和核对。ONES Project 支持将需求和相关任务规划至迭代并分配负责人，看板和燃尽图可用于实时掌握进度，任务工时统计有助于估算任务持续时间；排查缺口时，可利用全局筛选与项目内筛选按多重条件快速定位相关工作项。完成定义、验收口径和缺口记录可以放在 ONES Wiki 文档中并与任务关联，文档内还能插入 ONES Project 的工作项列表，使拆解清单与说明保持在同一处。工作项之间的显式依赖设置与完成定义的强制校验，需结合所选版本的实际能力确认后再纳入流程。
需要明确的停止点是：补齐过程中一旦涉及交付范围变更，先确认边界再调整计划；超出可执行工作项层面的范围问题，回到项目范围管理处理，不在本次排查中一并解决。
常见问题
任务拆解后执行受阻，怎么快速判断是依赖遗漏还是验收条件缺失？
看受阻发生在哪个环节。工作项进入进行中后长期停滞、等待外部输入，或多人合并时输入不一致导致返工，通常指向依赖遗漏；工作项被标记完成却在评审时被指出不达标，或不同角色对合格标准理解不同，通常指向验收条件缺失。范围反复扩大、执行中不断补充内容，则更可能是关键交付物漏拆。症状归类只用于确定排查方向，最终结论要靠输入输出关系、完成定义、交付物对应三条证据线核对。
排查缺口时，为什么建议先记录、不边查边改？
边查边改会让计划在排查过程中持续变化，容易改一处引发新的不一致，也会让后续缺口难以判断是原有遗漏还是修改引入的。建议先把缺口类型、涉及工作项、证据、影响的下游环节和处置建议逐条记录，等缺口清单成型后再统一决定补齐顺序。这样处置时能看清缺口之间的关联，避免重复调整同一环节。
验收条件写成什么样才算可判定？
可判定的标准应当让第三方在没有额外解释的情况下判断“达到”或“未达到”，例如明确的交付物清单、需要通过的评审、需要满足的指标口径。只写“完成开发”“优化体验”这类表述无法判定。确认口径时最好让验收方直接参与，避免执行方单方面拟定标准后再次出现争议；确认完成后，用新标准回看已完成的工作项，判断是否需要返工。
补齐依赖后重跑仍然卡住，下一步查什么？
说明依赖链上还有未发现的断点。回到反向追溯步骤，从仍然受阻的工作项继续追问“它需要什么才能继续”，沿链条向上查找产出方，直到抵达已有明确产出和负责人的环节。重点检查是否存在无人负责的前置产出，这类缺口在工作项列表中往往完全不可见，只能通过追问输入来源发现。
在工具中如何承载拆解清单、缺口记录和验收口径？
ONES Project 支持将需求和相关任务规划至迭代并分配负责人，看板和燃尽图可用于实时掌握进度，任务工时统计有助于估算任务持续时间；排查缺口时，可利用全局筛选与项目内筛选按多重条件快速定位相关工作项。完成定义、验收口径和缺口记录可以放在 ONES Wiki 文档中并与任务关联，文档内还能插入 ONES Project 的工作项列表，使拆解清单与说明保持在同一处。工作项之间的显式依赖设置与完成定义的强制校验，需结合所选版本的实际能力确认后再纳入流程。
什么情况下应停止排查，转去处理范围问题？
当缺口涉及交付范围本身的调整，例如需要新增一个原目标中不存在的模块，或补齐动作会改变已确认的交付边界时，应先暂停并确认边界，回到项目范围管理处理，不在执行层面直接扩大任务。可执行工作项层面的依赖补齐和验收条件补充，可以在本次排查中一并完成。
