任务依赖梳理要解决的是“谁在等谁”的问题：把工作项之间的前后置关系写清楚，再放到时间轴上验证顺序是否成立。梳理结果应形成一份可维护的依赖清单，记录前置项、后置项、交付物、责任人和确认时点。当依赖需要随工作项状态和排期联动更新时，ONES 的工作项关联与排期管理可以承载这份清单。
要点总览（TL;DR）
- 任务依赖梳理分四步走：先界定范围与颗粒度，再拆出可独立交付的工作项，然后逐条识别依赖并标注类型与强度，最后用关键路径和排期冲突校验顺序是否成立。
- 依赖识别要落到“前置项—后置项”的配对，并记录依赖类型（完成—开始、开始—开始、完成—完成）、强度（硬依赖或软依赖）和来源（交付物、审批、外部输入），依据说明写清依赖存在的原因。
- 排期校验沿依赖链推算最早开始与最晚完成时间，浮动时间为零的链条即关键路径；循环依赖通过拆出更小先行交付物或改为软依赖打破，时间放不下时优先压缩关键路径或并行化软依赖。
- 梳理负责人、工作项责任人和评审角色分工明确，变更时由工作项责任人第一时间更新依赖条目；定稿前逐项核对孤立工作项、字段完整性、循环依赖和关键路径确认情况。
- 依赖条目需要随工作项状态和排期联动维护时，可在 ONES 中为工作项建立关联关系，把前置项、后置项和计划时间放在同一视图里，减少清单与执行脱节。
先明确梳理对象与边界
依赖梳理开始前，先写一份范围说明，回答三个问题：这次梳理覆盖哪些工作项、颗粒度到任务还是子任务、覆盖哪个时间窗口。范围说明的作用是防止梳理过程被两类问题带偏：一是把项目整体进度压缩当成依赖问题处理，二是把人员忙闲导致的排期冲突混入依赖关系。这两类问题需要单独的资源与进度管理手段，放进依赖清单会让前后置关系失真。
范围说明建议包含以下字段：
- 覆盖范围：列出纳入梳理的工作项集合，例如某个版本、某个模块或某条业务链路上的任务。
- 颗粒度：明确梳理到任务层还是子任务层。颗粒度一旦确定，本次梳理内保持一致。
- 时间窗口：起止日期，以及窗口外的工作项如何处理（例如只登记为外部输入，不展开内部依赖）。
- 排除项：明确本次不处理的事项，如人员容量调配、跨项目资源争抢。
范围说明的完成标志是：团队能据此判断某个工作项是否属于本次梳理，边界争议在梳理开始前解决，而不是在清单评审时反复拉扯。
拆出可判断依赖的工作项
依赖关系能否被识别，取决于工作项拆得是否合适。拆分标准是“可独立交付”：一个工作项对应一份可被他人接收的成果，有明确的完成标志，完成后后置工作项可以据此开始。拆分过粗，一个工作项内部混着多个交付物，依赖关系无法落到具体对象；拆分过细，工作项之间产生大量形式上的先后关系，清单被噪音淹没。
工作项清单建议包含四个字段：
| 字段 | 填写要求 | 示例 |
|---|---|---|
| 工作项名称 | 动宾结构，指向一个成果 | 完成订单接口联调 |
| 交付物 | 可被接收的具体产物 | 联调通过的接口清单与测试记录 |
| 完成标志 | 可核验的状态描述 | 测试环境全部接口通过，缺陷清零 |
| 负责人 | 对交付物负责的单一角色 | 后端开发负责人 |
拆分时可以用一个简单检验：如果某个工作项的完成标志无法用一句话描述，或者交付物需要拆成两份分别交接，说明它还应继续拆分。反过来，如果两个工作项的负责人相同、完成标志相同、交付物是同一份，应合并为一项。完成标志是后续判断依赖是否满足的依据，写“基本完成”“大致就绪”这类描述会让依赖校验失去基准。
识别依赖并标注类型与强度
识别依赖的动作是逐条追问：这个工作项开始之前，必须已经拿到什么？答案可能是一份交付物、一次审批通过，或一个外部输入。把答案落到“前置项—后置项”的配对上，再补充依赖类型和强度。
常见依赖类型包括：
- 完成—开始：前置项完成后，后置项才能开始。这是最常见的一类，例如接口联调完成后才能进行端到端测试。
- 开始—开始：前置项启动后，后置项才能启动，两者可并行推进。例如数据迁移脚本开始编写后，校验方案可以同步开始设计。
- 完成—完成：后置项的完成取决于前置项的完成。例如上线公告的发布完成，取决于灰度发布完成。
强度区分硬依赖与软依赖。硬依赖是技术上或规则上不可绕过的约束，例如未通过安全审批就不能上线；软依赖是经验上的优先顺序，提前开始会带来返工风险但并非不可能，例如界面设计稿定稿前开发可以先搭框架。标注强度的意义在于排期冲突时知道哪些顺序可以协商、哪些必须保留。
依赖来源也要记录，便于后续追溯：交付物依赖（等一份文档、一个接口、一批数据）、审批依赖（等评审或签字）、外部输入依赖（等供应商、等上游团队）。依赖清单初稿建议包含字段：前置项、后置项、依赖类型、强度、来源、依据说明。依据说明写清楚“为什么存在这条依赖”，避免清单变成无人理解的历史遗留。
用关键路径与排期冲突校验顺序
依赖清单只说明顺序，排期校验要回答“按这个顺序，时间上来得及吗”。做法是把每条依赖当作时间约束，沿依赖链推算每个工作项的最早开始时间和最晚完成时间。最早开始时间由所有前置项的最晚完成时间决定；最晚完成时间由后置项的最早开始时间倒推。两者之差就是浮动时间。
浮动时间为零的工作项连成的链条就是关键路径。关键路径上的任何延误都会直接推迟整体交付，梳理时应重点检查这条链上的依赖是否都是硬依赖、是否有可以并行化的空间。浮动时间较大的工作项在排期调整时有腾挪余地，可以优先用来吸收上游延误。
校验过程中常见两类问题及处理方式：
- 循环依赖：A 等 B、B 又等 A。处理方式是找到循环中的交付物，判断能否拆出一个更小的先行交付物打破循环，或把其中一条改为软依赖并约定阶段性交付。
- 排期冲突：依赖顺序成立，但时间窗口放不下。处理方式包括压缩关键路径上的工作项、把软依赖改为并行、或将部分工作项移出本次范围。调整后要重新推算一遍，确认没有产生新的冲突。
校验的输出是一张带时间约束的依赖网络和一份冲突清单，冲突清单逐条记录问题、涉及工作项、处理方案和确认人。依赖网络不必画成复杂图形，用表格列出每个工作项的前置项、最早开始、最晚完成、浮动时间即可支撑校验。
角色分工与交付物确认
依赖梳理需要明确三类角色。梳理负责人通常由项目经理或技术负责人担任，负责组织梳理、维护清单和推动冲突解决。各工作项责任人对本人工作项的前置条件最清楚，负责提出和确认与自己相关的依赖条目。评审角色由下游接收方或技术把关人担任，负责确认依赖是否真实存在、强度标注是否合理。
| 角色 | 职责 | 确认时点 |
|---|---|---|
| 梳理负责人 | 组织梳理、汇总清单、跟踪冲突处理 | 梳理启动与清单定稿 |
| 工作项责任人 | 提出前置条件、确认依赖条目、报告变化 | 清单初稿形成时 |
| 评审角色 | 确认依赖真实性与强度、参与排期校验 | 清单评审与排期校验后 |
变更时的更新责任要事先约定：工作项完成标志变化、交付物范围调整或外部输入延期时，由该工作项责任人第一时间更新依赖条目并通知梳理负责人；梳理负责人负责判断是否影响关键路径，并组织相关方重新校验。没有约定的更新责任，清单会在几周内失效。
一个依赖梳理的填写示例
以下为演示情景，用于说明依赖清单如何填写与校验。某团队准备上线一个订单查询功能，范围说明确定覆盖开发、测试、上线三个阶段共六个工作项，颗粒度到任务层，时间窗口为四周。
| 前置项 | 后置项 | 类型 | 强度 | 来源 | 依据说明 |
|---|---|---|---|---|---|
| 接口设计评审通过 | 订单接口开发 | 完成—开始 | 硬 | 审批 | 接口契约未定，开发无法启动 |
| 订单接口开发完成 | 接口联调 | 完成—开始 | 硬 | 交付物 | 联调需要可调用的接口 |
| 测试数据准备完成 | 接口联调 | 完成—开始 | 软 | 交付物 | 可先用少量样例数据启动，全量数据后补 |
| 接口联调完成 | 端到端测试 | 完成—开始 | 硬 | 交付物 | 联调未通过时端到端测试无意义 |
| 端到端测试通过 | 上线审批 | 完成—开始 | 硬 | 审批 | 测试报告是审批的必要材料 |
排期校验时发现：接口设计评审比计划晚了两天，导致订单接口开发的最早开始时间顺延，而这条链上浮动时间为零，属于关键路径，整体上线日期受影响。处理方案是把测试数据准备从串行改为与接口开发并行，因为该依赖标注为软依赖，提前准备不增加返工风险；同时与评审方确认后续评审不再延期。调整后重新推算，端到端测试获得一天浮动时间，上线日期保持不变。这个例子说明强度标注的价值：软依赖是排期调整时的可用空间，硬依赖则需要通过压缩工期或调整范围来解决。
完成检查与后续维护
依赖清单定稿前，逐项核对以下检查项：
- 每个工作项至少有一条入边或出边，或明确标注为独立工作项。孤立工作项要么是拆分遗漏，要么确实无依赖，需要给出说明。
- 每条依赖都有前置项、后置项、类型、强度、来源和依据说明，字段无空缺。
- 不存在循环依赖，或循环已按约定方式打破并记录处理方案。
- 关键路径已识别，路径上的硬依赖已逐条确认。
- 冲突清单中的每一项都有处理方案和确认人。
- 所有工作项责任人和评审角色已完成确认，确认记录可查。
维护节奏建议与项目节奏对齐：每周或每个迭代结束时复核一次依赖清单，重点检查已完成工作项的后置项是否按时启动、外部输入是否按期到位、新增工作项是否补登依赖。发生范围变更、关键人员调整或外部输入延期时，触发一次临时复核。复核结果更新到同一份清单中，保留变更记录，便于回溯排期偏差的原因。
当依赖条目需要与工作项状态、排期联动时，可以在 ONES 中为工作项建立关联关系，把前置项、后置项和计划时间放在同一视图里维护，工作项状态变化后依赖链上的排期影响更容易被看到，减少清单与执行两张皮的情况。
常见问题
依赖梳理应该做到任务层还是子任务层？
取决于本次梳理要支撑的排期决策。如果排期按任务层安排，梳理到任务层即可；如果某个任务内部有多个可独立交接的交付物，且这些交付物的先后顺序会影响排期，才需要下钻到子任务层。关键是同一份清单内颗粒度保持一致，避免部分工作项拆到子任务、部分停在任务层，导致依赖配对时口径不一。范围说明里写明颗粒度，梳理过程中不随意变更。
软依赖在排期里应该怎么用？
软依赖表示提前开始会带来返工风险、但顺序可以协商的关系。排期校验时，软依赖是调整顺序的可用空间：当关键路径上出现延误，可以优先把软依赖改为并行推进，用提前启动换取时间。使用前要评估返工风险是否可接受，并在清单中记录调整理由和确认人。硬依赖则不能这样处理，只能通过压缩工期、增加投入或调整范围来解决。
外部输入延期导致依赖链断裂，清单怎么更新？
由依赖该外部输入的工作项责任人发起更新：在依赖条目中记录延期事实和新的预计到位时间，通知梳理负责人。梳理负责人判断该延期是否落在关键路径上——如果在，组织下游工作项责任人重新推算排期，评估是否需要调整范围或压缩后续工作项；如果不在，更新浮动时间即可。更新结果写入同一份清单并保留变更记录，便于后续回溯排期偏差的原因。
梳理完成后，依赖清单多久复核一次？
建议与项目节奏对齐，每周或每个迭代结束时复核一次，重点检查已完成工作项的后置项是否按时启动、外部输入是否按期到位、新增工作项是否补登依赖。此外，发生范围变更、关键人员调整或外部输入延期时触发一次临时复核。复核不必全量重做，按变更影响范围检查相关依赖链即可，但关键路径上的条目每次都应确认。
循环依赖一定要打破吗？
循环依赖意味着两个或多个工作项互相等待，按原样无法排出可执行的顺序，需要处理。常见做法是找到循环中的交付物，拆出一个更小的先行交付物让其中一方先启动；或者把其中一条改为软依赖，约定阶段性交付后另一方即可开始。处理方案要记录在清单中，说明打破了哪条边、依据是什么，避免后续维护时重新陷入同样的循环。
