任务依赖梳理可以按一条固定路径推进：先圈定范围并把工作项拆到能判断先后关系的粒度，再通过“产出—使用”关系找出前后置，记录依赖类型、责任人和承诺时点，随后排出执行顺序、处理循环依赖与排期冲突，最后用一份检查清单确认是否可以进入执行。整个过程的核心产物是一份带责任归属和验证时点的依赖清单，以及据此形成的执行顺序表。
要点总览（TL;DR）
- 依赖梳理从可交付成果圈定范围，把工作项拆到能判断“谁产出、谁使用”的粒度，再逐条配对前后置关系。
- 识别依赖按四步走：列输入输出、配对前后置、区分强制与软依赖、记录触发条件与可用时点。
- 依赖清单至少包含前后置工作项、依赖物、类型、提供方、接收方、承诺时点、触发条件和状态，由提供方承诺、接收方确认。
- 排出执行顺序后重点处理循环依赖与排期冲突，处置方式包括拆解工作项、调整顺序和重新约定时点。
- 用完成检查清单逐项核对，确认无模糊时点、无未处理循环依赖、清单已评审并纳入变更跟踪后再进入执行。
先定范围与工作项粒度：依赖梳理从哪一层开始
依赖梳理的第一步是确定本次梳理覆盖哪些工作，以及每项工作拆到什么程度。范围不清时，讨论很容易滑向项目整体进度或人员是否够用，这两类问题属于排期与资源安排，需要与依赖关系分开处理。本次梳理只回答一件事：哪些工作项之间存在前后产出关系。
范围建议以可交付成果为边界圈定。例如一次版本发布、一个功能模块上线、一份对外提交的材料，都可以作为一个梳理单元。圈定后列出该成果包含的主要交付物，再围绕交付物展开工作项，避免把整个项目所有事项一次性铺开。
工作项粒度以“能判断前后产出关系”为准。一个工作项应当有明确的产出物，并且这个产出物能被另一个工作项直接使用。粒度太粗时，前后关系说不清楚；粒度太细时，清单会膨胀到无法维护。可以用三个问题检验粒度是否合适：这项工作完成后能交出什么；谁会使用这个产出；使用方在什么条件下可以开始自己的工作。三个问题都能回答，粒度基本可用。
开始梳理前，建议写一份简短的范围说明，包含本次梳理的成果边界、纳入的工作项清单、明确不处理的事项。把“项目整体里程碑是否延期”“某位成员同时承担几项任务”这类问题标注为另行处理，可以让依赖讨论保持聚焦。完成标志是：参与人对梳理范围和工作项清单没有分歧，每个工作项都能说出大致产出。
识别依赖的四步操作：从产出关系找到前后置
识别依赖的核心动作是把工作项两两之间的“谁产出、谁使用”关系找出来。可以按以下四步执行，每一步都有明确的输入、动作和输出。
第一步：列出每个工作项的输入物与输出物
输入是开始这项工作之前必须具备的材料、信息、确认或环境；输出是这项工作完成后可以交给下游的成果。动作上，让每项工作的负责人用简短条目写出输入和输出，输出尽量写成可交付的实物或明确状态，例如“接口字段说明文档”“测试环境可用”“设计稿确认结论”。完成标志是每个工作项至少有一条输出，且输入项能对应到具体对象。
第二步：用产出—使用关系配对前后置工作项
把全部输出物汇总，再逐条检查它被哪个工作项作为输入使用。一条输出被另一项工作使用，就形成一条依赖：前者是前置，后者是后置。配对时只记录真实使用关系，避免把“顺序上通常先做”误当成依赖。完成标志是每条依赖都能指出具体的产出物和接收方。
第三步：区分强制依赖与可协商的软依赖
强制依赖指后置工作在没有该产出时无法开始或无法验收，例如开发依赖已确认的需求范围、上线依赖测试通过结论。软依赖指有该产出会更顺畅，但可以通过替代方案、临时约定或并行推进来缓解，例如某份参考数据晚到可以先按样例开发。区分两者的意义在于排期冲突时的处置空间不同：强制依赖需要守住时点，软依赖可以协商调整。完成标志是每条依赖都标注了类型，并对软依赖写明可接受的替代方式。
第四步：记录依赖的触发条件与可用时点
依赖不只是一条连线，还需要说明“什么时候可用”。触发条件描述前置工作需要达到什么状态才算可交付，例如“评审通过”“数据完整率达到约定口径”“环境部署完成并可访问”。可用时点则是后置工作可以开始使用该产出的时间。完成标志是每条依赖都有可核对的触发条件和时点，而不是笼统写“尽快提供”。
四步完成后，得到一份依赖清单初稿，包含前后置工作项、产出物、依赖类型、触发条件和可用时点。这份初稿是后续字段设计和排期的输入。
依赖清单的字段设计与责任人分工
依赖清单要能长期使用，字段需要覆盖“依赖什么、谁提供、谁接收、何时可用、现在什么状态”。建议至少包含以下字段：
| 字段 | 填写内容 | 填写责任 |
|---|---|---|
| 依赖编号 | 唯一标识，便于引用和变更追踪 | 梳理组织者 |
| 前置工作项 | 提供产出的工作项名称 | 提供方确认 |
| 后置工作项 | 使用该产出的工作项名称 | 接收方确认 |
| 依赖物 | 具体的文档、数据、确认结论或环境状态 | 提供方填写 |
| 依赖类型 | 强制依赖或软依赖，软依赖注明替代方式 | 双方共同确认 |
| 提供方 | 对产出负责的角色或人员 | 梳理组织者指定 |
| 接收方 | 使用产出并确认可用的人员 | 梳理组织者指定 |
| 承诺时点 | 提供方承诺产出可用的时间 | 提供方承诺 |
| 触发条件 | 判定产出可用的具体标准 | 双方约定 |
| 状态 | 未开始、进行中、已提供待确认、已确认、有风险 | 提供方更新，接收方确认 |
角色分工围绕“承诺”和“确认”两个动作展开。提供方负责按承诺时点交付依赖物，并在状态变化时主动更新；接收方负责在收到产出后按触发条件检查是否可用，确认后把状态改为已确认。梳理组织者负责维护清单完整性，检查是否存在没有责任人的依赖。
依赖发生变更时，例如时点推迟、产出范围调整或依赖类型从强制改为软依赖，提供方需要通知接收方和梳理组织者，由接收方复核自己的排期是否仍成立。变更记录保留在原依赖条目上，避免口头约定丢失。完成标志是清单中每条依赖都有明确的提供方、接收方和承诺时点，且变更路径被参与人知晓。
排出执行顺序并处理循环依赖与排期冲突
有了依赖清单，就可以按依赖关系排出执行顺序。做法是先找出没有前置依赖的工作项作为起点，再逐层展开后置工作项，形成先后顺序。把链条最长、对最终交付影响最大的路径标出来，作为重点关注的顺序线。完成标志是每项工作都能在顺序表中找到位置，且顺序与依赖清单一致。
循环依赖指若干工作项互相成为前置，导致谁都开不了工。常见情形是双方都等对方先给输入。处理方式有三种：拆解工作项，把互相等待的部分拆成更小的可先行交付单元；调整范围，先约定一个最小可用版本打破等待；重新约定时点，让一方先提供临时产出，另一方据此推进并在后续替换。处理后在清单中记录拆解结果或临时约定，确认循环已被打破。
排期冲突指依赖的承诺时点与后置工作的开始时间不匹配。处置方式同样有三类：调整顺序，把不依赖该产出的工作提前；拆分工作项，让后置工作中不依赖的部分先做；重新约定时点，与提供方协商新的承诺时点并同步给接收方。选择哪种方式取决于依赖类型：强制依赖优先守住时点或调整顺序，软依赖可以先用替代方式推进。完成标志是每条冲突都有处置记录，写明采用的方式和新的时点。
依赖清单和执行顺序需要随工作推进更新。在工具中落地时，可以把前后置工作项建成关联关系，用状态字段反映依赖是否已提供、是否已确认，让接收方在开始工作前能看到前置状态。ONES 的工作项关联与状态管理可以承载这类记录，具体配置方式按团队现有使用方式确定。关键不在于工具形态，而在于依赖状态有人更新、有人确认。
一个完整示例：需求到上线的依赖梳理
以下为演示情景，用于说明梳理过程，不代表真实项目数据。
假设本次梳理范围是一个功能模块从需求确认到上线。工作项拆分为：需求范围确认、交互设计、接口设计、前端开发、后端开发、联调、测试、上线准备。逐项列出输入输出后，可以配对出若干依赖：交互设计使用需求范围确认的结论；前端开发和后端开发分别使用交互设计与接口设计；联调同时使用前端和后端产出；测试使用联调通过的版本；上线准备使用测试通过结论。
依赖清单填写示例如下：
| 前置工作项 | 后置工作项 | 依赖物 | 类型 | 提供方 | 接收方 | 承诺时点 | 状态 |
|---|---|---|---|---|---|---|---|
| 需求范围确认 | 交互设计 | 确认后的需求说明 | 强制 | 产品负责人 | 设计负责人 | 第3个工作日 | 已确认 |
| 接口设计 | 后端开发 | 接口字段与错误码说明 | 强制 | 后端负责人 | 后端开发人员 | 第5个工作日 | 进行中 |
| 交互设计 | 前端开发 | 标注完整的交互稿 | 强制 | 设计负责人 | 前端开发人员 | 第6个工作日 | 进行中 |
| 前端开发 | 联调 | 可运行的前端页面 | 强制 | 前端开发人员 | 联调负责人 | 第10个工作日 | 未开始 |
| 后端开发 | 联调 | 可调用的接口服务 | 强制 | 后端开发人员 | 联调负责人 | 第10个工作日 | 未开始 |
| 联调 | 测试 | 联调通过的版本 | 强制 | 联调负责人 | 测试负责人 | 第12个工作日 | 未开始 |
| 测试 | 上线准备 | 测试通过结论 | 强制 | 测试负责人 | 发布负责人 | 第15个工作日 | 未开始 |
按依赖排出顺序后，可以看到联调是关键汇聚点，前端和后端任一延迟都会影响测试开始。假设接口设计推迟到第7个工作日，与后端开发的开始时间冲突。处置方式是：后端先按已确认的字段框架开发不依赖接口细节的部分，接口说明到位后再补齐；同时把联调时点重新约定为第11个工作日，并通知测试负责人调整测试准备。这个处置记录在依赖条目上，接收方确认新的时点后继续推进。
完成检查：依赖梳理做到什么程度算可用
依赖梳理是否完成，可以用以下清单逐项核对。全部满足即可进入执行；存在未满足项时，先补齐再排期。
- 每个工作项的前置依赖都已确认提供方和承诺时点，没有“待定”“尽快”这类模糊表述。
- 每条依赖都写明了依赖物和触发条件，接收方能据此判断产出是否可用。
- 强制依赖与软依赖已区分，软依赖写明了可接受的替代方式。
- 不存在未处理的循环依赖，拆解或临时约定已记录在清单中。
- 排期冲突都有处置记录，写明调整顺序、拆分工作项或重新约定时点的结果。
- 依赖清单已由提供方、接收方和相关负责人评审确认，评审结论有记录。
- 清单已纳入变更跟踪，依赖时点或范围变化时有通知和复核动作。
- 依赖状态有明确的更新机制，提供方更新、接收方确认，状态能反映当前是否可用。
这份清单同时可以作为下一次梳理的起点：把上次遗留的风险依赖和变更记录带入新一轮梳理，依赖管理就能保持连续，而不是每次排期前重新拼凑。
常见问题
工作项拆到多细才适合做依赖梳理？
判断标准是能否说清前后产出关系。一个工作项应当有明确产出物，并且这个产出物能被另一项工作直接使用。可以用三个问题检验：完成后交出什么、谁会使用这个产出、使用方在什么条件下可以开始。三个问题都能回答，粒度基本可用；回答不了说明还需要继续拆分或补充产出定义。
粒度也不是越细越好。拆得过细会让依赖清单迅速膨胀，维护成本超过收益。建议先按主要交付物拆分，梳理过程中发现某条依赖说不清时再局部细化。
软依赖在排期时应该怎么处理？
软依赖指有该产出会更顺畅，但可以通过替代方案、临时约定或并行推进来缓解的关系。处理时先为每条软依赖写明可接受的替代方式，例如先用样例数据开发、先按已确认的字段框架推进。排期冲突出现时，强制依赖优先守住时点或调整顺序，软依赖可以先用替代方式推进，等产出到位后再替换。
软依赖同样需要记录提供方和承诺时点，只是冲突时的处置空间更大。把软依赖当成可以忽略的关系，容易在后置工作推进到一半时才发现缺少关键输入。
依赖梳理的清单需要多久更新一次？
更新由事件驱动比固定周期更有效。提供方交付依赖物、承诺时点变化、产出范围调整、依赖类型改变时，都应立即更新对应条目并通知接收方复核排期。日常推进中可以按团队现有节奏检查状态字段，重点看“进行中”和“有风险”的条目。
更新机制的关键是责任明确：提供方负责更新状态，接收方负责确认产出是否可用，梳理组织者负责检查清单完整性。三者缺一，清单就会退化成排期前的一次性文档。
循环依赖一定要拆工作项才能解决吗？
不一定。常见处理方式有三种：拆解工作项，把互相等待的部分拆成更小的可先行交付单元；调整范围，先约定一个最小可用版本打破等待；重新约定时点，让一方先提供临时产出，另一方据此推进并在后续替换。选择哪种取决于循环涉及的范围和双方可接受的临时方案。
无论采用哪种方式，都要在清单中记录拆解结果或临时约定，并确认循环已被打破。只口头约定而不记录，后续排期时容易再次陷入同样的等待。
依赖梳理和项目整体进度管理如何衔接？
依赖梳理的输出是执行顺序表和带时点的依赖清单，这些结果可以作为项目进度安排的输入。依赖梳理本身只回答工作项之间的前后产出关系，里程碑是否延期、整体进度是否可控属于进度管理范畴，需要另行处理。
实际操作中，建议在依赖清单评审通过后再更新整体排期，避免在依赖关系尚未确认时反复调整进度计划。依赖时点发生变化时，同步通知进度负责人评估影响即可。
