研发交付依赖是指一个交付单元（任务、版本、接口、环境或外部交付物）的完成，必须以另一个交付单元先达到约定状态为前提的关系。它描述交付链路中的先后约束与交接条件，关注“谁先完成、达到什么状态、后一方才能继续”。本文给出可直接使用的定义、范围边界、形成与传递机制，并用一个具体例子说明如何判断和记录依赖。
要点总览（TL;DR）
- 研发交付依赖是一个交付单元的完成必须以另一个交付单元先达到约定状态为前提的关系，关注交付链路中的先后约束与交接条件。
- 一条可执行的依赖包含四个要素：前置对象、后置对象、可核验的完成状态、交接条件，缺一项就容易在交付中产生歧义。
- 接口联调、环境就绪、上游组件交付、外部供应商交付属于典型依赖；项目整体计划编排与产品版本内容取舍不在本文范围。
- 依赖是关系，阻塞是结果状态，前置任务是排期顺序；依赖未满足描述条件缺失，任务延期描述承诺时间被突破。
- 依赖记录应写清完成状态判定标准与交接物，并在待满足、已满足、已失效之间持续更新，变更时沿依赖链检查下游影响。
研发交付依赖的准确定义
把研发交付拆成可管理的单元后，单元之间常出现先后约束：后一个单元要开始或完成，前一个单元必须先达到某个约定状态。这条约束关系就是研发交付依赖。它回答的是交付条件问题，即后置对象在什么前提下才能推进。
一条可执行的依赖由四个要素构成，缺一项就容易在交付中产生歧义：
- 前置对象：必须先达到约定状态的交付单元，例如某个接口、某个环境、某个上游组件版本。
- 后置对象：受约束的交付单元，例如依赖该接口的前端页面、依赖该环境的联调任务。
- 完成状态：前置对象达到什么程度才算满足，例如“接口契约冻结并经双方评审确认”，而非笼统的“接口做完”。
- 交接条件：满足状态后如何交接，例如提供契约文档、示例报文或可访问的测试环境。
依赖与普通任务关联的区别在于约束强度。普通关联只表示两个任务相关，便于查找和汇总；依赖则表示后置对象的完成条件受前置对象状态制约，前置对象状态变化会直接影响后置对象能否按计划交付。记录依赖时，应把完成状态写成可核验的判定标准，让团队能明确回答“满足了没有”。
哪些属于研发交付依赖，哪些不属于
判断一条约束是否属于研发交付依赖，可以看它是否构成交付单元之间的完成条件。属于依赖的情形通常出现在交付链路的交接点上：
- 接口联调：前端页面依赖后端接口契约冻结或接口可用，契约未定则页面无法稳定联调。
- 环境就绪：测试任务依赖测试环境部署完成，环境未就绪则测试无法执行。
- 上游组件交付：业务模块依赖基础组件或公共库的新版本发布。
- 外部供应商交付：系统集成依赖第三方提供的接口文档、证书或联调窗口。
以下议题与依赖相邻，但不属于本文讨论的依赖范畴：项目整体计划的编排方法，例如如何排定多个迭代的起止时间；产品版本内容的取舍与规划，例如某个功能是否进入本版本。这些议题影响交付安排，但它们处理的是计划结构和内容决策，依赖处理的是交付单元之间的完成条件。
| 概念 | 关注点 | 与依赖的关系 |
|---|---|---|
| 研发交付依赖 | 交付单元之间的完成条件 | 本文讨论对象 |
| 里程碑 | 关键时间点与阶段成果 | 依赖可能落在里程碑前后，但里程碑本身是时间节点，不描述单元间条件 |
| 风险 | 可能发生的不利事件及影响 | 依赖未满足会形成风险，风险是可能性判断，依赖是已记录的条件关系 |
| 项目整体计划 | 多单元的时间与资源编排 | 计划会参考依赖，但依赖不等于排期方式 |
依赖在交付链路中如何形成与传递
依赖主要产生于拆分交付单元的过程。团队把需求拆成任务、把版本拆成模块、把系统拆成接口时，会自然形成交接点：一个单元的输出成为另一个单元的输入，依赖随之出现。拆分越细，交接点越多，需要显式记录的依赖也越多。
依赖一旦形成，会沿交付链路传递。多个依赖首尾相接构成依赖链，链上任何一环未满足，后续单元都无法按原条件推进。当依赖链与关键路径重合时，单点延迟会放大为整体交付风险：一个接口契约推迟冻结，可能同时影响前端开发、联调排期和测试窗口。识别依赖链的价值在于找到那些“一断全断”的交接点，优先保障其状态。
依赖状态通常有三种，需要在交付过程中持续更新：
- 待满足：前置对象尚未达到约定状态，后置对象处于等待或可部分推进的状态。
- 已满足：前置对象达到可核验的完成状态，交接条件已落实，后置对象可正常推进。
- 已失效：前置对象被取消、范围变更或交付方式调整，原依赖不再成立，需要重新评估后置对象的条件。
依赖变更时，影响会沿链路传递。前置对象的完成状态、交付时间或交接方式发生变化，后置对象的开始条件、验收标准甚至是否需要该依赖都会改变。因此依赖变更不能只通知直接相关方，还要沿依赖链检查受影响的下游单元，更新其状态和计划。依赖记录与状态跟踪属于协作管理动作，可以在承载任务与迭代的工具中完成。ONES 支持 Scrum、Kanban 等敏捷开发模式，通过迭代计划、任务看板等工具承载任务流转（依据 F3），团队可在此基础上把依赖的前置对象、完成状态和交接条件随任务一并记录和更新；具体依赖字段与视图的可用范围以实际产品配置为准。
依赖、阻塞与前置任务的区别
这三个词在日常沟通中常被混用，记录和汇报时用错词会导致信息失真。核心区别是：依赖是一种关系，阻塞是一种结果状态，前置任务是排期中的顺序安排。
| 概念 | 本质 | 典型表述 | 使用场景 |
|---|---|---|---|
| 依赖 | 交付单元之间的完成条件关系 | “页面联调依赖接口契约冻结” | 记录条件、跟踪状态、评估影响 |
| 阻塞 | 任务无法推进的结果状态 | “联调任务当前被阻塞” | 描述现状、上报问题、协调资源 |
| 前置任务 | 排期中的先后顺序 | “先做需求评审，再做开发” | 安排工作顺序、分配时间 |
依赖未满足与任务延期也需要区分。依赖未满足描述的是条件尚未具备，此时后置任务可能尚未开始，也可能在等待中；任务延期描述的是已承诺的完成时间被突破。依赖未满足可能最终导致延期，但两者不是同一件事：前者是条件判断，后者是时间结果。汇报时先说明依赖状态，再说明对时间的影响，能让协作方准确判断该解决条件还是该调整计划。
前置任务与依赖的区别在于约束性质。前置任务是排期上的先后，调整顺序后仍可能完成；依赖是完成条件，前置对象不达标，后置对象即使排在最前也无法真正完成。把排期先后一律写成依赖，会让依赖清单失去筛选价值；把真正的完成条件只当作排期顺序，则容易在交付后期才发现条件缺失。
一个具体例子与常见误解
以下为演示情景，用于说明依赖的判断与跟踪方式。某团队计划交付一个订单查询页面，前端页面需要调用后端提供的订单查询接口。团队记录了一条依赖：前置对象为“订单查询接口契约”，后置对象为“前端订单查询页面开发与联调”，完成状态为“契约文档经前后端双方评审确认并冻结”，交接条件为“契约文档归档，附请求与响应示例”。
这条依赖的跟踪过程如下：契约评审前，依赖状态为待满足，前端可先做页面框架但无法锁定字段；契约冻结并归档后，状态更新为已满足，前端进入联调；若后端调整字段范围，契约需重新评审，依赖回到待满足，前端联调条件随之变化。整个过程的关键动作是状态更新和影响检查，而非一次性登记。
常见误解集中在以下几处：
- 把排期先后当成依赖：仅仅因为两个任务在计划中一前一后，就登记为依赖，导致依赖清单膨胀，真正影响交付的条件被淹没。
- 把依赖写成口头约定：依赖只存在于聊天记录或会议口头确认中，交接时无人能说清完成状态，条件是否满足靠回忆判断。
- 依赖满足后不更新状态：前置对象早已达标，依赖仍显示待满足，下游任务被误判为受阻，协调资源被浪费。
- 完成状态写得过于笼统：只写“接口完成”，未说明是契约冻结、接口可用还是通过测试，双方对“满足”的理解不一致。
为减少上述问题，依赖记录建议包含以下字段：前置对象及其负责人、后置对象及其负责人、完成状态的判定标准、交接条件与交接物、当前状态（待满足、已满足、已失效）、计划满足时间、最近一次状态更新时间。字段不必多，但完成状态和交接条件必须可核验，状态变更要有记录。这样在交付评审或跨团队协调时，团队能直接依据记录判断条件是否具备，并把依赖变化对下游的影响说清楚。
常见问题
依赖的完成状态写到什么程度才算可核验？
完成状态要能让第三方对照判断，而不是靠双方回忆。把“接口完成”改成“契约文档经前后端双方评审确认并冻结，文档已归档”，就具备了可核验性。判断标准可以问三个问题：谁来判断、依据什么材料判断、判断结果记录在哪里。三个问题都能明确回答，状态更新才有依据。
对于环境类依赖，可写成“测试环境部署完成并通过冒烟检查”；对于外部交付，可写成“供应商提供接口文档与联调窗口确认邮件”。标准不必复杂，但要指向具体交付物或检查动作。
依赖链很长时，团队应该优先保障哪些环节？
优先保障与关键路径重合的依赖环节。判断方法是看某个前置对象未满足时，会同时影响多少个下游单元、是否卡住整体交付时间。影响面大且位于关键路径上的交接点，应安排更早的状态确认和更频繁的跟踪。
依赖链上的非关键环节可以按常规节奏跟踪，但状态变更仍需记录，避免下游误判。若关键路径本身发生变化，依赖的优先级也要重新评估，不能沿用旧清单。
依赖已满足后还需要继续跟踪吗？
需要保留状态记录，但跟踪频率可以降低。已满足的依赖仍可能因前置对象范围变更、交付方式调整而回到待满足，因此要保留判定标准和交接物，便于变更时快速复核。
实际操作中，可在交付评审时抽查已满足依赖的交接物是否仍然有效，例如契约文档是否被后续修订覆盖。状态更新要有时间记录，让下游能判断依据的新旧。
跨团队协作时，依赖记录放在哪里比较合适？
放在双方都能访问、且随任务流转的位置比较合适，例如承载任务与迭代的协作工具。关键是前置对象和后置对象都能看到同一条记录，状态变更不需要靠转发消息同步。
ONES 支持 Scrum、Kanban 等敏捷开发模式，通过迭代计划、任务看板等工具承载任务流转（依据 F3），团队可在此基础上把依赖的前置对象、完成状态和交接条件随任务一并记录和更新；具体依赖字段与视图的可用范围以实际产品配置为准。若团队使用其他承载方式，也应保证记录可查、状态可更新。
把排期先后登记成依赖会带来什么问题？
依赖清单会膨胀，真正影响交付的条件被淹没。排期先后调整顺序后通常仍可完成，而依赖是完成条件，前置对象不达标时后置对象即使排在最前也无法真正完成。两者混在一起，团队在交付评审时就难以快速识别哪些条件必须先解决。
建议在登记时先问一句：前置对象不达标，后置对象能否真正完成？答案是否定的，才登记为依赖；只是时间上先后，按排期顺序管理即可。
