任务依赖是指一项任务的开始或完成，需要以另一项任务的开始、完成或产出为前置条件。它约束的是工作项之间的先后关系，回答“谁在等谁、等什么产出、何时可以开始”。在跨团队交接中，依赖关系写得清楚，交接双方就能按同一份约定推进，减少口头催办和反复确认。
要点总览（TL;DR）
- 任务依赖是指一项任务的开始或完成需要以另一项任务的状态或产出为前提，约束的是工作项之间的先后关系，而非人员忙闲。
- 按被约束的状态可分为完成—开始、开始—开始、完成—完成、开始—完成四种类型，类型选错会导致后置任务过早启动或过度等待。
- 依赖属于工作项安排层面；项目整体进度归项目进度管理，人员容量冲突归资源负载与冲突管理，依赖只提供排期所需的约束输入。
- 依赖是计划内的约束，阻塞是执行中的异常；依赖记录应写清方向、条件和交付物，便于交接双方核验。
- 跨团队交接时把前置任务、后置任务和交付物写进同一条工作项记录，依赖才能从口头约定变成可查的任务信息。
任务依赖的直接定义
任务依赖是两项或多项工作项之间的一种计划约束：后一项任务的启动或收尾，必须以前一项任务达到某个状态为前提。这个前提可以是前置任务已经开始、已经完成，也可以是前置任务产出了某个可交付物。依赖关系成立时，后置任务在条件满足前不具备正常推进的基础。
依赖关系中有两个基本角色。前置任务是被等待的一方，它提供状态或产出；后置任务是等待的一方，它消费前置任务的结果。两者构成一条有方向的关系：前置任务在前，后置任务在后。方向写反，交接就会错位，因此记录依赖时首先要确认“谁等谁”。
需要强调的是，依赖约束的对象是工作项，而非人员。一条依赖描述的是“任务B要等任务A的接口文档”，而不是“张三要等李四有空”。人员忙闲会影响任务何时被处理，但那是资源安排问题；依赖关系本身只关心工作项之间的先后条件。把依赖写成人员等待，会让交接失去可核验的交付物，也无法在任务状态变化时自动反映进度。
任务依赖包括什么、不包括什么
任务依赖属于工作项安排层面，解决的是“这件事能不能开始、什么时候算具备条件”。它与项目进度管理、资源负载管理相邻但分工不同。把边界划清，团队在遇到问题时才知道该改依赖、改排期，还是调资源。
| 情形 | 是否属于任务依赖 | 判断要点 |
|---|---|---|
| 任务B要等任务A的接口文档完成后才能开发 | 属于 | 两个工作项之间存在明确的先后条件与交付物 |
| 联调任务要等前后端各自开发完成才能开始 | 属于 | 后置任务的启动以前置任务完成为条件 |
| 整个项目比原计划晚两周，需要重排里程碑 | 不属于 | 属于项目整体进度管理，处理的是全局时间安排 |
| 两名工程师同时被排了满负荷任务，需要调配人手 | 不属于 | 属于资源负载与冲突管理，处理的是人员容量 |
| 两个需求都想先做，需要决定先后顺序 | 不属于 | 属于优先级排序，处理的是价值与取舍，依赖只描述条件关系 |
这张表的核心判断标准是：问题能否归结为“某个工作项在等另一个工作项的状态或产出”。能归结的，用依赖关系表达；不能归结的，交给进度、资源或优先级机制处理。依赖关系也不负责计算项目整体工期，它提供的是排期所需的约束输入。
任务依赖的四种常见类型与形成机制
按前置任务与后置任务各自被约束的状态，任务依赖通常分为四种类型。类型决定了“等的是开始还是完成”，写依赖时选错类型，后置任务可能过早启动或过度等待。
| 依赖类型 | 含义 | 典型场景 | 跨团队交接示例 |
|---|---|---|---|
| 完成—开始 | 前置任务完成后，后置任务才能开始 | 上游交付物完成后再启动下游工作 | 接口文档定稿后，后端开始按文档开发 |
| 开始—开始 | 前置任务开始后，后置任务才能开始 | 两项工作需要同步推进、边做边对齐 | 后端开发启动后，测试团队同步开始编写测试用例 |
| 完成—完成 | 前置任务完成后，后置任务才能完成 | 收尾工作需等待配套工作收尾 | 联调报告要等安全扫描任务完成后才能关闭 |
| 开始—完成 | 前置任务开始后，后置任务才能完成 | 交接班式场景，新任务启动后旧任务才可结束 | 新版本部署任务启动后，旧版本下线任务才可标记完成 |
依赖关系的形成主要有两种方式。一种是人工标注：任务负责人或项目管理者在创建任务时，明确指定前置任务和后置任务，并写清等待的条件。另一种是从交付物推导：当一项任务的产出被另一项任务直接消费时，两者之间自然形成依赖，例如文档、设计稿、数据表、接口定义等交付物的流转。人工标注适合显式约定，交付物推导适合在梳理流程时发现隐性依赖。
多条依赖串联起来会形成依赖链。依赖链越长，任一环节延迟向后传导的范围越大。项目排期中识别关键路径时，依赖链是重要输入：位于关键路径上的任务一旦延迟，会直接影响整体完成时间；不在关键路径上的依赖链则有相对宽松的缓冲。理解这一点，团队在跨团队交接时就能判断哪些依赖必须优先保障。
任务依赖与相关概念的区别
任务依赖常与阻塞、关联任务、子任务、里程碑混用。它们描述的现象不同，处理动作也不同，区分清楚有助于在任务记录中选对表达方式。
| 概念 | 与任务依赖的区别 | 判断要点 |
|---|---|---|
| 阻塞 | 依赖是计划内的先后约束，阻塞是执行中出现的异常 | 依赖在排期时就已知；阻塞是任务本应推进却因意外原因停住，需要被识别和解除 |
| 关联任务 | 关联表示两项任务有关系，依赖表示其中一项受另一项条件约束 | 关联可以是参考、同类、相关讨论；只有存在“等状态或等产出”时才构成依赖 |
| 子任务 | 子任务是父任务的拆分，依赖是平级或跨团队工作项之间的约束 | 子任务回答“这件事由哪些部分组成”；依赖回答“这件事要等谁” |
| 里程碑 | 里程碑是时间点上的标志性节点，依赖是工作项之间的条件关系 | 里程碑用于标记阶段成果；依赖用于约束任务何时可以开始或完成，二者可配合使用但不可互相替代 |
实际工作中，依赖可能演变为阻塞：前置任务迟迟未交付，后置任务被迫停住。此时应同时保留依赖记录并标注阻塞原因，前者说明计划约束，后者说明当前异常，便于交接双方和项目管理者分别处理。把两者混为一谈，容易导致依赖被当成临时问题反复催办，而真正的计划约束没有被复盘。
跨团队交接中的一个具体例子与常见误解
以下为演示情景：产品团队负责输出接口文档，后端团队依据文档开发接口，测试团队随后进行联调。三个团队分属不同负责人，交接点清晰，适合用依赖关系管理。
第一步，识别依赖。后端开发任务依赖接口文档任务，联调任务依赖后端开发任务和前端开发任务。第二步，记录依赖。在后端开发任务上写明前置任务是“接口文档定稿”，等待条件是“文档评审通过并给出最终版本”，交付物是文档链接或版本号；联调任务同样写清等待的是前后端开发完成，而非“等大家有空”。第三步，跟踪与解除。接口文档状态变为完成后，后端开发任务的依赖条件满足，负责人确认收到的是约定版本，再启动开发；联调开始前核对前后端完成状态，条件齐备后解除依赖并进入联调。
这个例子可以迁移到设计交付、数据准备、合同审批等交接场景，关键是把方向、条件和交付物三件事写清楚。围绕这个例子，有三条常见误解需要纠正。
- 把依赖当成催办。依赖是计划约束，记录的是条件关系；催办是执行中的沟通动作。依赖写清楚后，催办才有依据，但依赖本身不替代沟通。
- 把依赖当成人员等待。写成“等某某人”会让交接失去可核验的产出，也无法随任务状态变化而更新。应写成“等某项任务的某个状态或产出”。
- 依赖不写交付物。只写“等接口文档”而不写版本和评审状态，后置任务可能拿到未定稿内容就开工，返工风险上升。交付物、版本和验收条件应随依赖一起记录。
当交接涉及多个团队和较多工作项时，依赖关系需要落在团队共用的任务记录中，而不是散落在聊天消息里。ONES 支持在工作项之间建立关联并跟踪状态流转，团队可以把前置任务、后置任务和交付物写进同一条工作项记录，交接双方看到的是同一份约定；前置任务状态变化后，后置任务的负责人可以据此判断条件是否满足，再决定启动或继续等待。这样，依赖从口头约定变成可查、可交接的任务信息，跨团队协作的衔接点也更清晰。
常见问题
任务依赖和阻塞可以同时存在吗？应该怎么记录？
可以同时存在。依赖是排期时就已知的计划约束，阻塞是任务本应推进却因意外原因停住的执行异常。当前置任务迟迟未交付，后置任务被迫停住时，建议同时保留依赖记录并标注阻塞原因：依赖说明“本来要等什么”，阻塞说明“现在卡在哪里”。两者分开记录，交接双方和项目管理者才能分别处理——前者用于复盘计划约束是否合理，后者用于推动当前异常解除。
跨团队交接时，依赖的交付物写到什么颗粒度才算清楚？
判断标准是后置任务负责人能否据此确认“条件是否已满足”。通常需要写清三件事：交付物的具体对象（如接口文档、设计稿、数据表）、版本或状态（如评审通过、定稿版本号）、验收方式（如由谁确认、以哪份记录为准）。只写“等接口文档”容易让后置任务拿到未定稿内容就开工，返工风险上升。颗粒度不必细到每个字段，但要足以支撑一次明确的交接确认。
依赖链很长时，跨团队交接应该优先保障哪些依赖？
优先保障位于关键路径上的依赖。依赖链串联后，任一环节延迟会向后传导；位于关键路径上的任务一旦延迟，会直接影响整体完成时间，而不在关键路径上的依赖链通常有相对宽松的缓冲。实际操作中，可以先梳理出影响最终交付时间的依赖链，对链上的交接点明确交付时间和确认人，其余依赖按常规节奏跟踪。这一判断依赖排期信息，属于项目进度管理的范畴，依赖关系本身只提供约束输入。
两个任务之间只是内容相关，需要建成依赖吗？
不需要。关联表示两项任务有关系，可以是参考、同类或相关讨论；依赖要求其中一项受另一项的条件约束，即存在“等状态或等产出”的关系。如果后置任务在前置任务未完成时也能正常推进，就属于关联而非依赖。把关联误记为依赖，会让后置任务被不必要地挂起，也会让依赖清单失去筛选价值。判断时问一句：前置任务没完成，后置任务是否真的无法开始或无法收尾。
依赖条件满足后，后置任务是否应该立即启动？
条件满足只说明依赖约束解除，是否立即启动还要看资源安排和优先级。依赖解决的是“能不能开始”，人员是否有空、这件事是否该优先做，分别属于资源负载与冲突管理和优先级排序的问题。跨团队交接中较稳妥的做法是：前置任务状态变化后，由后置任务负责人确认收到的是约定版本和状态，再结合当前排期决定启动时间，并把确认结果回写到任务记录中。
