任务依赖梳理是把工作项之间的先后约束显性化，并落到排期上的过程。具体做法是：先圈定梳理范围和工作项粒度，再逐项识别前置、后置和外部依赖，标注依赖类型与约束条件，校验循环依赖和遗漏，最后把确认的依赖写入工作项字段并指定责任人定期复核。本文按五个步骤展开，并给出角色分工、填写示例和完成检查清单。
要点总览（TL;DR）
- 任务依赖梳理先圈定范围和工作项粒度：按迭代、里程碑或交付物选一条边界，工作项满足可独立交付、可估算、可指派再纳入清单。
- 核心操作分五步：列出工作项并编号、逐项识别前置后置与外部依赖、标注依赖类型与约束条件、校验循环依赖与孤立工作项、把确认的依赖写入工作项字段并记录状态。
- 三类角色分工明确：任务负责人申报本工作项依赖，项目或迭代负责人汇总校验并裁决冲突，依赖方负责人确认外部依赖的可行时间。
- 依赖清单要写到可核对的程度，约束说明具体到判断条件，状态区分已确认、待确认、有风险，未确认的外部依赖按风险项处理。
- 完成标准看五项：每个工作项都有依赖状态、无未处理循环依赖、外部依赖有责任人和确认时间、依赖可被排期引用、变更后有更新记录。
先定范围和粒度：哪些工作项要进入依赖梳理
依赖梳理最常见的失败，是一开始就把整个项目的工作项全部铺开，结果清单越拉越长，约束关系越理越乱。开始识别之前，先回答两个问题：这次梳理覆盖哪一段工作，每个工作项拆到什么程度。范围清楚、粒度合适，后面的识别和校验才有稳定的对象。
用一条边界圈定梳理范围
梳理范围可以按迭代、里程碑或交付物三种方式圈定，选一种作为主边界即可。按迭代圈定适合节奏稳定的团队，梳理对象是本迭代承诺完成的工作项；按里程碑圈定适合跨团队交付，梳理对象是支撑该里程碑的全部工作项；按交付物圈定适合以成果为导向的项目，梳理对象是构成该交付物的上下游工作。范围说明应写清起止时间、包含的工作项类别，以及明确排除在外的部分，避免后续反复扩大。
工作项粒度按三条标准判定
进入依赖梳理的工作项，建议满足三个条件：可独立交付，即完成后能向他人交付一个可验证的结果；可估算，即负责人能给出工作量或工期判断；可指派，即有明确的一名负责人。粒度太粗，依赖容易被藏在工作项内部而遗漏；粒度太细，依赖数量膨胀，维护成本上升。对不满足条件的工作项，先拆分或合并，再纳入清单。
准备三类输入材料
- 需求清单：说明要做什么，是识别工作项来源的依据。
- 交付物清单：说明每个工作项产出什么，用于判断工作项之间是否存在交付物层面的衔接。
- 现有排期：说明当前计划的时间安排，用于比对依赖约束与排期是否一致。
需要说明的是，本文只处理工作项之间的先后约束。项目整体进度计划的编制与跟踪、人员容量冲突的识别与调配，属于相邻主题，不在本文展开；梳理过程中遇到这两类问题，记录下来转交对应负责人处理，不混入依赖清单。
本节完成后的产物是一份梳理范围说明和一份工作项清单，清单中每个工作项都标注了粒度判定结果。
核心操作步骤：从识别依赖到写入工作项
依赖梳理可以拆成五步，每步都有明确的输入、动作、输出和完成标志。按顺序执行，前一步的输出就是后一步的输入，中途发现遗漏可以回到上一步补充。
步骤一：列出工作项并编号
输入是上一节形成的工作项清单。动作是把清单整理成统一格式，为每个工作项分配唯一编号，并补齐负责人、计划起止时间、所属交付物等基础字段。输出是一张带编号的工作项表。完成标志是所有纳入范围的工作项都有编号，且没有重复或空缺。
步骤二：逐项识别前置、后置与外部依赖
输入是带编号的工作项表。动作是由每个工作项的负责人回答三个问题：这项工作开始前必须完成什么（前置依赖）；这项工作完成后会解锁什么（后置依赖）；这项工作是否依赖团队之外的人或事（外部依赖，如跨团队交付、供应商提供、审批通过）。识别时以交付物为线索，问“我的输入从哪里来、我的输出交给谁”，比凭印象回忆更可靠。输出是每个工作项的依赖候选列表。完成标志是每个工作项都给出了依赖结论，包括明确“无依赖”的结论。
步骤三：标注依赖类型与约束条件
输入是依赖候选列表。动作是为每条依赖标注类型和约束说明。常用的依赖类型有四种：完成—开始，前置完成后后置才能开始；开始—开始，两项工作需同时启动；完成—完成，两项工作需同时完成；开始—完成，前置开始后后置才能完成。实际使用时按团队约定选取，不必全部启用，多数场景以完成—开始为主。约束条件要写具体，例如“接口文档评审通过后方可进入联调”，而不是只写“依赖接口文档”。输出是带类型和约束说明的依赖条目。完成标志是每条依赖都有类型和可核对的约束描述。
步骤四：校验循环依赖与孤立工作项
输入是标注完成的依赖条目。动作分两部分：一是循环校验，从任一工作项出发沿前置方向逐级回溯，如果回到起点，说明存在循环依赖，需要由项目或迭代负责人裁决，通过拆分工作项或调整顺序打破循环；二是孤立检查，找出既无前置也无后置、且不属于独立交付的工作项，确认它是否被遗漏了关联，或本就不应纳入本次范围。输出是校验记录和处理结论。完成标志是不存在未处理的循环依赖，孤立工作项都有明确说明。
步骤五：写入工作项字段并记录确认状态
输入是校验通过的依赖条目。动作是把确认的依赖写入对应工作项的依赖字段，使排期可以直接引用；同时记录每条依赖的确认状态，区分已确认、待确认、有风险三种情况。依赖梳理结果只有落到工作项上，才能在排期评审和后续变更中被引用，停留在表格里的清单很快会失效。输出是写入工作项后的依赖记录和确认状态。完成标志是所有确认依赖都能在工作项上查到，且状态字段完整。
这五步的产物汇总起来，就是一份可追溯的依赖清单，包含工作项、依赖对象、依赖类型、约束说明、责任人和确认状态。在工具层面，ONES 的工作项可以承载依赖关系，并支持在评审流程中流转确认，具体字段与配置以实际使用版本为准；团队也可以先用表格完成梳理，再迁入工作项。
角色与交付物分工：谁识别、谁确认、谁维护
依赖梳理涉及三类角色，职责不清时最容易出现“都以为别人确认过了”的情况。下面按角色说明各自的动作和交付物。
| 角色 | 主要动作 | 交付物 |
|---|---|---|
| 任务负责人 | 识别并申报本工作项的前置、后置和外部依赖，说明约束条件 | 本工作项的依赖申报记录 |
| 项目或迭代负责人 | 汇总各方申报，校验循环依赖和遗漏，裁决冲突，组织排期评审 | 依赖清单、校验记录、冲突裁决结论 |
| 依赖方负责人 | 确认外部依赖的可行时间，给出承诺或提出调整 | 外部依赖的确认记录（含承诺时间） |
三类角色之外，还需要明确维护节奏。依赖清单在两种时点更新：排期评审时，把新识别的依赖补充进去并复核已有依赖是否仍然成立；发生变更时，例如工作项拆分、时间调整、外部依赖延期，同步更新依赖条目和确认状态。每次更新留下变更记录，写清改了什么、为什么改、谁确认的，便于后续追溯。
职责分配的核心是让每条依赖都有且只有一个确认人。任务负责人对本工作项的依赖申报负责，项目或迭代负责人对清单整体完整性和一致性负责，依赖方负责人对外部承诺负责。三者之间通过排期评审衔接，评审通过即视为本轮依赖梳理的确认节点。
示例：一次迭代内的依赖梳理记录
以下示例为演示情景，用于说明依赖清单的填写方式和校验过程。假设一个两周迭代内有四个工作项：A 接口设计、B 前端页面开发、C 接口联调、D 测试验收。团队约定主要使用完成—开始类型。
依赖清单填写示例
| 工作项 | 依赖对象 | 依赖类型 | 约束说明 | 责任人 | 状态 |
|---|---|---|---|---|---|
| A 接口设计 | 无前置依赖 | — | — | 张工 | 已确认 |
| B 前端页面开发 | A 接口设计 | 完成—开始 | 接口字段定义评审通过后启动 | 李工 | 已确认 |
| C 接口联调 | A 接口设计、B 前端页面开发 | 完成—开始 | 页面可运行且接口可访问后开始 | 张工 | 已确认 |
| D 测试验收 | C 接口联调 | 完成—开始 | 联调用例全部通过后进入 | 王工 | 已确认 |
填写时注意两点：约束说明写到可核对的程度，例如“接口字段定义评审通过”比“依赖接口设计”更容易判断是否满足；状态字段区分已确认、待确认、有风险，不要统一填“完成”。
循环依赖的发现与处理
假设初稿中 B 的依赖写成“A 接口设计完成”，而 A 的约束里又写了“需参考 B 的页面交互稿”。沿前置方向回溯：B 依赖 A，A 依赖 B，回到起点，构成循环。处理方式有两种：把 B 的页面交互稿拆成独立的前置工作项，让 A 只依赖交互稿而不依赖 B 整体；或者调整顺序，先完成交互稿评审再并行推进 A 和 B。由项目或迭代负责人裁决后，更新清单并记录处理结论。
外部依赖未确认时的处理
假设 C 接口联调还依赖外部支付团队提供测试环境，对方尚未给出时间。此时该条依赖状态标为“待确认”，责任人为对接人，并在排期中按风险项处理：预留缓冲时间，在评审中列为跟踪事项，不把未确认的时间当作已确定约束写入计划。待对方确认后，更新承诺时间和状态，再纳入正式排期。
完成检查：依赖梳理做到什么程度算可用
依赖梳理是否可用，不看清单有多长，而看它能否直接支撑排期。下面五项检查全部通过，本轮梳理即可视为完成。
- 每个工作项都有明确的依赖状态：要么列出了具体依赖，要么明确标注“确认无依赖”，不存在空白项。
- 不存在未处理的循环依赖：所有发现的循环都已有裁决结论，并体现在更新后的清单中。
- 外部依赖有责任人和确认时间：待确认的外部依赖也写明了对接人和预计确认时点，并在排期中按风险处理。
- 依赖已写入工作项并可被排期引用：排期时能直接看到每个工作项的前置约束，而不是另查一张表。
- 变更后有更新记录：工作项拆分、时间调整或外部承诺变化后，依赖条目和状态已同步更新，并留下变更说明。
检查时可以由项目或迭代负责人逐项核对，也可以请一位未参与梳理的同事按清单抽查几条依赖，验证约束说明是否可核对、状态是否与实际一致。抽查发现的问题回到对应步骤修正，修正后重新核对相关条目即可，不必整轮重做。梳理结果进入排期后，按排期评审和变更两个时点持续维护，依赖清单才能保持可用。
常见问题
工作项拆到多细才适合做依赖梳理？
按三条标准判断：完成后能向他人交付一个可验证的结果，负责人能给出工作量或工期判断，有明确的一名负责人。三条都满足即可纳入清单。粒度太粗时，依赖容易藏在一个工作项内部而被遗漏；粒度太细时，依赖条目数量膨胀，维护成本上升。遇到不满足条件的工作项，先拆分或合并，再进入识别环节。
识别依赖时总是漏掉一些，有什么可操作的办法？
以交付物为线索逐项追问，比凭印象回忆更可靠。对每个工作项问三个问题：这项工作开始前必须完成什么，完成后会解锁什么，是否依赖团队之外的人或事。同时要求每个工作项都给出结论，包括明确标注“确认无依赖”，空白项往往就是遗漏所在。校验阶段再找出既无前置也无后置的工作项，确认是否漏了关联。
发现循环依赖后应该怎么处理？
循环依赖需要由项目或迭代负责人裁决，常见处理方式有两种：把造成循环的部分拆成独立的前置工作项，让双方只依赖拆分后的产物；或者调整顺序，先完成共同的前置评审再并行推进。裁决后更新清单并记录处理结论，确保不存在未处理的循环。
外部依赖一直没确认，排期还能往下做吗？
可以继续排期，但要把这条依赖标为“待确认”，写明对接人和预计确认时点，在排期中按风险项处理：预留缓冲时间，在评审中列为跟踪事项，不把未确认的时间当作已确定约束写入计划。对方确认后，更新承诺时间和状态，再纳入正式排期。
依赖梳理做完一次之后，还需要在什么时点更新？
主要有两个时点：排期评审时，补充新识别的依赖并复核已有依赖是否仍然成立；发生变更时，例如工作项拆分、时间调整、外部依赖延期，同步更新依赖条目和确认状态。每次更新留下变更记录，写清改了什么、为什么改、谁确认的，依赖清单才能持续被排期引用。
