任务依赖是指一项任务的开始或完成，需要以另一项任务的开始、完成或产出为前置条件的关系。它描述工作项之间的先后约束，与工期长短、人员忙闲无关。本文围绕这一定义说明判断规则、常见类型、概念边界，并用一个示例演示如何识别和记录依赖。
要点总览（TL;DR）
- 任务依赖是指一项任务的开始或完成，需要以另一项任务的开始、完成或产出为前置条件的关系；判断时看前置状态变化是否真正影响后续任务能否开展。
- 先后排期、人员容量冲突、项目阶段划分不属于任务依赖，应分别归入任务排期、资源负载管理和项目进度管理。
- 常见类型可按约束方向分为完成到开始、开始到开始、完成到完成、开始到完成，按来源分为产出交接、审批确认和外部条件。
- 依赖链决定排期的关键路径，依赖环会让所有任务都无法启动，需要先拆解关系再排期。
- 记录依赖要写清前置任务、依赖的具体交付物或状态、未满足时后续任务的状态，并在排期评审时复核。
任务依赖的准确定义
任务依赖（Task Dependency）可以表述为：当一项任务的启动或结束必须以另一项任务的启动、结束或交付物为条件时，两项任务之间就存在依赖关系。其中，提供条件的一方称为前置任务，等待条件的一方称为后续任务。前置任务的状态发生变化，后续任务能否开展也随之变化，这条依赖才成立。
把这个定义拆开，可以用三个要素对照自己的任务列表：
- 有两个明确的工作项。依赖发生在两项具体任务之间，而不是一项任务与一个部门、一个阶段或一句目标之间。如果说不清前置任务具体是哪一项，这条依赖通常还没有被识别清楚。
- 存在可指认的前置条件。前置条件可以是前置任务完成、前置任务开始，也可以是前置任务产出的文档、设计稿、接口、审批结果等交付物。条件要能被具体描述，例如“拿到接口文档”比“等研发准备好”更容易判断。
- 前置状态变化会实际影响后续任务。这是判断依赖是否成立的核心。如果前置任务延期一周，后续任务仍然可以照常启动，那么两者之间多半只是时间上的先后，而非真正的依赖。
用一句话概括判断方法：问自己“前置任务没完成或没开始，后续任务是否真的做不了”。回答为“是”，并且能指出具体缺什么，这条依赖就成立；回答为“否，只是习惯上排在后面”，则应归入排期安排而非依赖。
任务依赖包括什么、不包括什么
任务依赖的边界可以用“约束是否来自前置任务的交付或状态”来划分。属于依赖的情形，后续任务的开展条件掌握在前置任务手中；不属于依赖的情形，先后顺序来自计划安排、资源数量或整体节奏，前置任务本身并不构成后续任务的开展条件。
| 情形 | 是否属于任务依赖 | 判断依据 | 应归入的管理范畴 |
|---|---|---|---|
| 后续任务必须等前置任务交付设计稿才能开始 | 属于 | 存在明确的产出交接，缺少交付物就无法开展 | 任务依赖 |
| 上线任务必须等测试通过确认后才能执行 | 属于 | 前置任务的状态（通过确认）触发后续任务 | 任务依赖 |
| 合同评审通过后才能启动付款流程 | 属于 | 审批结果构成后续动作的前置条件 | 任务依赖 |
| 两项互不相关的任务，只是计划上排在前后两周 | 不属于 | 前置任务的状态不影响后续任务能否开展 | 任务排期 |
| 同一名成员手上的两项任务只能依次做 | 不属于 | 约束来自人员容量，而非任务之间的交付关系 | 资源负载管理 |
| 项目整体按阶段推进，第一阶段结束后进入第二阶段 | 不属于 | 属于项目层面的阶段划分与里程碑安排 | 项目进度管理 |
这张对照表也说明了分工：任务依赖回答“谁在等谁的什么”，进度管理回答“整体何时到哪个节点”，资源管理回答“人和时间够不够”。三者会相互影响，但记录和调整的对象不同。把资源冲突误记为依赖，会让依赖链虚增，排期看起来处处受限；把真实依赖当成普通排期，则容易在交接处出现空等。
任务依赖的常见类型与形成机制
依赖的产生通常来自三种机制：交付物流转、状态确认和外部条件。围绕这三种机制，可以从约束方向和来源两个角度对依赖分类。
按约束方向区分
- 完成到开始：前置任务完成后，后续任务才能开始。这是最常见的一类，例如“数据库迁移完成”之后才能“切换线上读写”。判断示例：前置任务未完成时，后续任务没有任何可执行的部分。
- 开始到开始：前置任务启动后，后续任务才能启动，两者可以并行推进。例如“压测方案开始执行”后，“监控告警配置”才能开始联调。判断示例：后续任务需要前置任务先进入运行状态才有输入。
- 完成到完成：后续任务只有在某项前置任务完成后才能宣告结束。例如“上线公告发布”需在“变更窗口关闭”之后才能收尾。判断示例：前置任务未结束，后续任务即使主体做完也不能关闭。
- 开始到完成：前置任务开始后，后续任务才能完成。这类关系在实际工作中较少见，多出现在交接班或新旧流程切换的场景。
按来源区分
- 产出交接：一方交付文档、代码、素材、数据等，另一方在此基础上继续工作。判断示例：交付物是否已进入可被使用的状态。
- 审批确认：后续动作需要某个评审、签字或验收结论。判断示例：结论未出时，后续动作是否会被合规或流程要求挡住。
- 外部条件：依赖供应商交付、第三方接口开放、客户提供资料等外部输入。判断示例：外部输入的时间是否不受项目团队控制。
多条依赖首尾相连就形成依赖链。链上任何一环延期，都会顺延其后的任务；在排期中，决定项目最短完成时间的往往是这样一条最长链，也就是关键路径。依赖链越长，交接点越多，排期的脆弱性越高。另一种需要警惕的结构是依赖环：A 等 B、B 等 C、C 又等 A，形成闭环。依赖环意味着没有任何一项任务具备启动条件，排期无法推进，必须先拆解或调整其中一条关系才能继续。
任务依赖与相关概念的区别
依赖容易与优先级、排期顺序、资源冲突、里程碑混在一起，因为它们都会表现为“某件事要排在另一件事之后”。区别的关键在于各自回答的问题不同，调整时改动的对象也不同。
| 概念 | 回答的问题 | 与任务依赖的区别 | 调整时改动的对象 |
|---|---|---|---|
| 任务依赖 | 后续任务开展需要前置任务的什么 | 基准概念，约束来自交付物或状态 | 前置条件、交付方式、依赖关系本身 |
| 任务优先级 | 多项任务中先做哪一项 | 优先级是选择顺序，依赖是能否开展；高优先级任务也可能因依赖未满足而无法开始 | 任务的重要程度排序 |
| 任务排期顺序 | 任务安排在哪个时间段、以什么次序出现 | 排期是计划安排，依赖是排期的输入之一；没有依赖的任务也可以人为排出先后 | 开始与结束时间 |
| 资源冲突 | 同一时间人力、设备或预算是否够用 | 资源冲突来自容量不足，依赖来自任务间的条件关系；增加人手可能缓解冲突，却无法消除依赖 | 人员分配、容量与负载 |
| 项目里程碑 | 项目整体到达了哪个关键节点 | 里程碑是整体进度标记，依赖是工作项之间的具体约束；里程碑常由多条依赖链共同支撑 | 阶段目标与节点日期 |
用同一口径检验：如果前置任务换了人、加了时间就能让后续任务开始，问题多半在资源；如果前置任务无论谁做、做多久，后续任务都必须等它的产出，问题就在依赖。优先级高但依赖未满足的任务，正确做法是推动前置条件，而不是把它强行提前。
具体例子与常见误解
以下为演示情景，用于说明依赖的识别与表达，不代表真实项目数据。
某团队要完成一次产品版本发布，任务列表中有“整理发布说明”“翻译发布说明”“发布到帮助中心”三项。整理人完成初稿后交给翻译，翻译完成后由运营发布。这里的依赖关系是：翻译任务依赖整理任务的产出（完成到开始），发布任务依赖翻译任务的产出（完成到开始）。而“整理发布说明”和“准备演示环境”之间只是计划上排在同一周，演示环境不需要发布说明，二者不构成依赖。
在任务字段中记录时，通常需要写清三件事：前置任务是哪一项、依赖的是它的完成还是某个交付物、缺少该条件时后续任务处于什么状态。例如在后续任务上标注“前置：发布说明翻译稿；条件：终稿确认；未满足时保持待启动”。这样记录的好处是，前置任务状态变化时，后续任务的责任人能直接判断是否可以开始，而不必反复口头确认。
依赖关系记录清楚后，交接环节往往还需要状态联动：前置任务标记完成时，后续任务从待启动转为可开始，责任人收到通知。ONES 可以通过工作项之间的关联关系承载这类前后置约束，并在工作项状态变化时让相关人员看到交接进展；具体字段与配置方式以实际使用环境为准。对于依赖链较长的项目，把关键交接点放在同一视图里查看，有助于在排期评审时发现空等和闭环。
常见误解纠正
- 把时间先后当依赖。两项任务只是按周次排开，并不代表前者是后者的条件。纠正方法：追问“前者没做完，后者是否真的做不了”，答不上具体缺什么就不记为依赖。
- 把依赖当阻塞。依赖是计划中的条件关系，阻塞是任务当前无法推进的实际状态。依赖未满足时任务处于等待，属于正常安排；只有条件本应具备却迟迟不到位，才需要按阻塞处理并升级协调。
- 依赖越多越严谨。把资源冲突、习惯顺序都记成依赖，会让依赖链虚长、关键路径失真，排期调整时难以判断真正受限的环节。纠正方法：只保留能指出具体交付物或状态条件的依赖，其余放回排期或资源管理中处理。
- 依赖一旦建立就不再复核。交付方式变化、前置任务拆分或合并后，原依赖可能已不成立。在排期评审和阶段复盘时复核依赖，能避免按过时的约束安排工作。
常见问题
两项任务在计划上一前一后，怎么判断是依赖还是普通排期？
追问一句：前置任务没完成或没开始，后续任务是否真的做不了。如果答“是”，并且能指出具体缺的是哪份文档、哪个审批结论或哪个接口，就属于依赖；如果只是习惯上按周次排开，前置任务换人、延期都不影响后续任务开展，就属于排期安排。判断时把“缺什么”写出来，比凭感觉判断更可靠。
依赖未满足导致任务卡住，应该按依赖处理还是按阻塞处理？
依赖是计划中已知的条件关系，前置任务尚未完成时后续任务处于等待状态，属于正常安排。阻塞通常指条件本应具备却迟迟不到位，需要升级协调。区分的关键是这条依赖是否在计划中已记录、前置任务的进度是否在预期内。如果前置任务本身已经延期且影响交付，应把它作为风险在排期评审中提出，而不只是让后续任务一直等待。
依赖链很长时，排期应该先关注哪一段？
先看决定项目最短完成时间的那条最长链，也就是关键路径。链上任何一环延期都会顺延其后所有任务，因此排期评审时优先确认关键路径上的交接点是否清晰、交付物是否明确。非关键路径上的依赖可以保留，但调整优先级时不必与关键路径同等对待。依赖链越长，交接点越多，越需要在每个交接点写清条件和责任人。
发现两个任务互相等待形成闭环，应该怎么处理？
依赖环意味着没有任何一项任务具备启动条件，排期无法推进。处理时先找出环上哪一条关系是真正必要的，把其中一条拆开：可以拆分任务，让部分工作先启动；也可以调整交付方式，例如先提供初稿而非终稿；还可以把其中一项改为外部条件或审批节点，单独跟踪。闭环不解决，增加人手或压缩工期都无法让任务开始。
任务依赖记录后，还需要在什么时点复核？
至少在排期评审和阶段复盘两个时点复核。交付方式变化、前置任务拆分或合并、外部条件时间调整后，原依赖可能已不成立，继续按旧约束排期会造成空等或虚长的依赖链。复核时逐条确认前置任务是否仍是同一项、依赖的交付物是否仍是当前需要的、未满足时的状态是否还准确。
