任务依赖图把任务和前后置关系画成有方向的网络：节点是任务，箭头表示“前者完成后后者才能开始”。本文用一个软件版本发布的演示情景，完整走一遍从任务清单、依赖关系表到依赖图结构和排期顺序表的填写过程，并说明每个字段的判断依据。示例中的任务与依赖关系也可以放在ONES工作项管理中承载，便于团队共享同一份排期依据。
要点总览（TL;DR）
- 任务依赖图由节点（任务）和有向箭头（前置任务指向后置任务）组成，核心要素是任务清单、工期、负责人、依赖类型与依赖原因。
- 填写流程分四步：列任务清单、逐条核对依赖关系、按依赖正向推算计划起止日期、检查循环依赖与排期冲突。
- 示例用9项任务、12条依赖演示版本发布准备，最长路径为T1→T2→T5→T7→T9，合计10个工作日，决定整体周期。
- 依赖关系应保持最小化，只保留真实约束；关键路径上的任务优先确认工期与负责人，并显式设置缓冲。
- 依赖图适合任务数量可控、依赖明确的排期场景；人员容量冲突和项目整体进度汇报需由资源管理与进度管理承担。
示例目标：这份依赖图要解决什么排期问题
演示情景设定为一次版本发布前的两周准备期：产品、开发、测试、运维四个角色共承担9项任务，计划在同一个发布窗口上线。这个情景用于说明填写方法，属于演示案例，不代表真实客户项目。
要解决的排期问题有三个。第一，任务先后顺序不清：开发、测试、部署之间谁等谁，团队口头说法不一致。第二，开始时间难定：每项任务只知道大概要做几天，无法判断最早可以什么时候启动。第三，存在潜在冲突：同一名负责人被安排在时间重叠的两项任务上，另有一条链路因为等待时间过长把整体周期拉长。
交付物有两件：一张任务依赖图，用节点和箭头表达任务及依赖方向；一份排期顺序表，给出每项任务的计划开始日期、计划结束日期和所处顺序。依赖图回答“谁等谁”，排期顺序表回答“什么时候做”。
完整示例：版本发布任务依赖图的填写过程
第一步：任务清单表
先列出全部任务，为每项任务补齐工期、负责人和前置任务。前置任务一栏此时可以凭经验初填，下一步再逐条核对。示例假设发布日为第10个工作日，工期单位为工作日。
| 编号 | 任务名称 | 工期 | 负责人 | 前置任务 |
|---|---|---|---|---|
| T1 | 确认版本范围与验收标准 | 1 | 产品经理 | 无 |
| T2 | 完成核心功能开发 | 4 | 开发A | T1 |
| T3 | 完成辅助功能开发 | 3 | 开发B | T1 |
| T4 | 编写测试用例 | 2 | 测试A | T1 |
| T5 | 核心功能集成测试 | 2 | 测试A | T2、T4 |
| T6 | 辅助功能集成测试 | 1 | 测试B | T3、T4 |
| T7 | 缺陷修复与回归 | 2 | 开发A | T5、T6 |
| T8 | 编写发布说明与操作手册 | 1 | 产品经理 | T1 |
| T9 | 生产环境部署与验证 | 1 | 运维 | T7、T8 |
第二步：依赖关系表
把任务清单中的前置关系拆成一条条依赖记录，每条记录写清前置任务、后置任务、依赖类型和依赖原因。依赖原因一栏是后续复核的依据，缺少原因支撑的依赖应当重新确认。
| 序号 | 前置任务 | 后置任务 | 依赖类型 | 依赖原因 |
|---|---|---|---|---|
| D1 | T1 | T2 | 完成到开始 | 范围未确认，开发无法确定实现内容 |
| D2 | T1 | T3 | 完成到开始 | 同上，辅助功能同样依赖范围确认 |
| D3 | T1 | T4 | 完成到开始 | 验收标准是测试用例的设计输入 |
| D4 | T1 | T8 | 完成到开始 | 发布说明需要写明本次版本范围 |
| D5 | T2 | T5 | 完成到开始 | 核心功能未完成无法进行集成测试 |
| D6 | T4 | T5 | 完成到开始 | 没有测试用例则测试无法执行 |
| D7 | T3 | T6 | 完成到开始 | 辅助功能未完成无法测试 |
| D8 | T4 | T6 | 完成到开始 | 同上，测试用例是执行前提 |
| D9 | T5 | T7 | 完成到开始 | 测试结果决定需要修复的缺陷范围 |
| D10 | T6 | T7 | 完成到开始 | 辅助功能测试结果同样进入修复范围 |
| D11 | T7 | T9 | 完成到开始 | 缺陷未修复完成不能发布 |
| D12 | T8 | T9 | 完成到开始 | 发布说明随版本一同交付 |
第三步：依赖图结构
把依赖关系表转成有向图，节点为任务，箭头从前置任务指向后置任务。示例的图结构可以文字化表示为：
- T1 → T2、T1 → T3、T1 → T4、T1 → T8（起点任务分出四条支线）
- T2 → T5，T4 → T5（T5由两条支线汇合）
- T3 → T6，T4 → T6（T6同样由两条支线汇合）
- T5 → T7，T6 → T7（T7汇合两条测试链路）
- T7 → T9，T8 → T9（T9为终点任务）
从结构上可以直接读出三条并行支线：开发支线（T2、T3）、测试准备支线（T4）、文档支线（T8）。三条支线在T7汇合，再进入T9。图中的最长路径为T1 → T2 → T5 → T7 → T9，合计10个工作日，这条路径决定了整体周期。
第四步：按依赖关系推导执行顺序与计划日期
按“前置任务全部完成后的下一个工作日开始”的规则，从第1个工作日正向推算，得到排期顺序表。示例中T1从第1天开始，T2、T3、T4、T8在第2天同时启动。
| 顺序 | 任务 | 计划开始 | 计划结束 | 说明 |
|---|---|---|---|---|
| 1 | T1 | 第1天 | 第1天 | 起点任务 |
| 2 | T2 | 第2天 | 第5天 | 关键路径 |
| 2 | T3 | 第2天 | 第4天 | 与T2并行 |
| 2 | T4 | 第2天 | 第3天 | 与T2、T3并行 |
| 2 | T8 | 第2天 | 第2天 | 与开发并行 |
| 3 | T5 | 第6天 | 第7天 | 等待T2与T4完成 |
| 3 | T6 | 第5天 | 第5天 | 等待T3与T4完成 |
| 4 | T7 | 第8天 | 第9天 | 等待T5与T6完成 |
| 5 | T9 | 第10天 | 第10天 | 等待T7与T8完成 |
顺序编号表示依赖层级，同一编号的任务可以并行。排期结果与发布日第10天吻合，但没有任何缓冲，任何一项关键路径任务延期都会直接推迟发布。
第五步：标注循环依赖风险与排期冲突点
检查示例时发现两处需要处理的问题。
循环依赖风险出现在初稿的依赖填写中：有人提出T7缺陷修复完成后需要回头修改T4测试用例，若把“T7 → T4”也写成依赖，就会与已有的T4 → T5 → T7形成闭环。处理方式是把“补充测试用例”拆成T7之后的一项独立任务，或者明确它只影响下一轮测试，不进入本轮依赖图。
排期冲突点有两处。其一，测试A同时承担T4（第2至3天）和T5（第6至7天），时间不重叠，但T5开始时间完全取决于T2，若T2延期到第6天完成，T5将顺延，测试A在T6上的安排也需要重新核对。其二，产品经理承担T1（第1天）和T8（第2天），两项任务相邻且都不可压缩，一旦T1延期，T8随之顺延，进而影响T9。关键路径T1 → T2 → T5 → T7 → T9没有缓冲，是最需要盯住的链路。
逐项解释：每个字段和每条依赖为什么这样填
工期按“熟悉该任务的负责人完成这项工作所需的工作日”估算，示例中的1天、2天、4天都是净工作时间，不含等待和会议。计划起止日期由依赖关系推算得出，不单独拍定。示例刻意不加缓冲，是为了让关键路径清晰可见；实际使用时通常会在关键路径末端或发布前留出1至2天缓冲，缓冲应显式写成一项任务或明确标注在排期表中，避免被默认为“应该能赶上”。
依赖类型以完成到开始为主，含义是前置任务完成后后置任务才能开始，示例中的12条依赖全部属于这一类。其他类型在特定条件下使用：开始到开始适用于两项任务可以同时启动、但后一项需要前一项先开工的场景，例如文档编写与功能开发同步启动；完成到完成适用于两项任务必须同时收尾的场景，例如代码合并与配置更新需要一起完成。类型选择的原则是只写真实约束，能用完成到开始表达的就不要引入更复杂的类型。
依赖方向的判断方法是问一句“谁在等谁”。等待的一方是后置任务，被等待的一方是前置任务，箭头从被等待者指向等待者。示例中T5需要T2的代码和T4的用例，因此写成T2 → T5和T4 → T5，而不是反过来。填写时容易出错的是把“我做完后通知你”误写成后置指向自己，复核时逐条读成“X完成后Y才能开始”，读不通就说明方向写反了。
循环依赖的识别依靠沿箭头走一圈能否回到起点。发现闭环后，常见拆解思路有三种：把闭环中的某一环拆成两轮任务，例如本轮测试与下轮回归分开；把其中一条依赖降级为信息同步，不进入排期约束；或者调整任务边界，把互相等待的两项工作合并为一项。选择哪种取决于约束是否真实存在，真实约束不能靠删除依赖解决。
排期冲突通过两个动作发现。一是按负责人汇总任务时间段，检查同一人是否有重叠；示例中测试A的两项任务不重叠，但存在紧邻顺延风险。二是找出关键路径，检查路径上每项任务的工期是否被低估、负责人是否有其他占用。关键路径被拉长的典型原因是某段等待时间过长，例如T5必须等T2和T4都完成，若T4被推迟，T5即使代码就绪也无法开始。
可迁移规律：换成自己的项目怎么套用
把示例中的做法提炼成四步通用流程，适用于活动筹备、内容上线、系统迁移等任务数量可控的项目。
- 列任务清单：写出任务名称、工期、负责人，前置任务先凭经验初填。完成标志是每项任务都有明确的完成定义，而不是“做得差不多”。
- 核依赖关系：逐条确认前置任务、后置任务、依赖类型和依赖原因，读成“X完成后Y才能开始”检验方向。完成标志是每条依赖都能说出原因。
- 排执行顺序：从起点任务正向推算计划起止日期，识别并行支线和关键路径。完成标志是每项任务都有计划开始和结束日期。
- 查风险：沿箭头检查闭环，按负责人检查时间重叠，检查关键路径是否有缓冲。完成标志是循环依赖已拆解、冲突点已标注处理方式。
依赖关系最小化是控制图复杂度的关键。只保留真实约束：没有前者后者就无法开始，才算依赖。把“希望先做A再做B”这类偏好写成依赖，会让本可并行的任务串行，整体周期被无谓拉长。示例中T2和T3都只依赖T1，因此可以并行；如果额外加上T2 → T3，周期会多出3天。
关键路径上的任务应优先确认工期和负责人。这条链路上任何一项的估算偏差都会直接传导到发布日，因此需要负责人明确承诺，并在排期表中单独标出。非关键路径任务有一定浮动空间，可以适度压缩精度。
依赖图需要随任务变化更新。新增任务时补一条依赖记录并重算受影响任务的日期；任务取消时删除相关箭头并检查是否产生孤立节点；工期调整后重新确认关键路径是否转移。把依赖图和排期表放在团队共同可见的位置，任务与依赖的变更在同一处记录，能减少口头传达造成的版本不一致。ONES工作项管理可以承载任务清单和前后置关系，团队在同一处维护任务状态与计划日期，依赖变化时相关成员能看到同一份排期依据；具体字段和视图能力以实际产品配置为准。
适用边界：依赖图适合与不适合的场景
依赖图适合任务数量可控、依赖关系相对明确、需要确定执行顺序的排期场景。示例中的版本发布准备有9项任务、12条依赖，规模适中，图结构清晰可读。任务数量增加到几十项以上时，图会变得难以阅读，通常需要借助工具视图或按阶段拆分子图。
依赖图不直接解决人员容量冲突。它能发现同一负责人的任务时间重叠，但判断一个人能否同时承担两项工作、某项任务是否需要换人，属于资源负载管理的范围，需要结合人员可用工时另行评估。示例中测试A的顺延风险，最终要靠资源层面的安排来化解。
依赖图也不承担项目整体进度汇报的职责。它回答的是任务之间的先后约束和执行顺序，项目整体进度、里程碑达成情况、跨项目协调属于项目进度管理的范畴。实践中可以把依赖图作为进度管理的输入之一，用关键路径和排期顺序表支撑进度判断，但汇报口径和里程碑定义需要单独维护。
依赖图不能替代对工期不确定性的持续跟踪。图中的工期是估算值，实际执行中会出现偏差，尤其是外部依赖、评审等待和缺陷修复这类波动较大的任务。排期表需要按固定节奏与实际进展比对，偏差累积到影响关键路径时及时调整，依赖图本身只是排期的起点，不是一次画完就固定的结论。
常见问题
任务清单里的前置任务一栏，初填时凭经验写会不会出错？
初填凭经验可以接受，但必须经过第二步逐条核对。核对时把每条依赖读成“X完成后Y才能开始”，读不通就说明方向或对象写错了。同时为每条依赖补上依赖原因，说不出原因的关系通常只是习惯性顺序，应当删除或改为信息同步，避免把本可并行的任务串成一条线。
示例中所有依赖都是完成到开始，实际项目什么时候需要用其他依赖类型？
完成到开始表达的是最普遍的约束：前置完成后后置才能开始。当两项任务可以同时启动、但后一项需要前一项先开工时，可用开始到开始，例如文档编写与功能开发同步启动；当两项任务必须同时收尾时，可用完成到完成，例如代码合并与配置更新一起完成。类型选择的原则是只写真实约束，能用完成到开始表达的就不要引入更复杂的类型，否则排期推算会变得难以复核。
发现循环依赖后，直接删掉其中一条依赖可以吗？
要看这条依赖是否代表真实约束。如果确实存在“前者不完成后者无法开始”的关系，删掉依赖只是把问题藏起来，执行时仍会卡住。可行的处理有三种：把闭环中的一环拆成两轮任务，例如本轮测试与下轮回归分开；把其中一条依赖降级为信息同步，不进入排期约束；或者调整任务边界，把互相等待的两项工作合并为一项。选择哪种取决于约束的真实性。
依赖图排出的日期没有任何缓冲，实际使用时应该怎么加？
示例刻意不加缓冲，是为了让关键路径清晰可见。实际使用时通常会在关键路径末端或发布前留出1至2天缓冲，并且要把缓冲显式写成一项任务，或在排期表中明确标注，避免被默认为“应该能赶上”。缓冲加在关键路径上才有意义，加在浮动空间较大的非关键任务后面，对整体周期影响有限。
任务数量增加到几十项以后，依赖图还能直接用吗？
规模变大后，一张图会难以阅读，通常需要按阶段拆分子图，或借助工具视图分层查看。拆分时保持跨子图的依赖记录完整，避免子图内部自洽、子图之间断裂。无论规模大小，循环依赖检查和关键路径确认这两个动作都要保留，它们是依赖图真正起排期作用的部分。
