设计任务依赖图，先拆出可独立交付的工作项，再写清每个工作项的前置条件与交付物，只连接真实存在的前后置关系，最后用关键路径和冲突检查验证排期。整个过程按“拆节点—定依赖—推排期—定维护—做校验”推进，核心产物是一张节点、连线、依赖属性齐全的依赖图，以及配套的依赖登记表和校验记录。
要点总览（TL;DR）
- 依赖图设计按“拆节点—定依赖—推排期—定维护—做校验”推进，先保证节点和关系正确，再处理时间推算。
- 节点以可独立交付、有明确完成标志、可由单一角色负责为标准；过细合并，过粗按交付物拆分。
- 依赖分完成—开始、开始—开始、完成—完成、开始—完成四类，连线前确认上游输出是下游输入且缺一不可；资源共用和审批等待不写成任务依赖。
- 排期用正向推算最早时间、反向推算最晚时间，浮动时间为零的链路即关键路径；环路、断链、时间倒挂是主要冲突信号。
- 依赖图需要指定维护角色和依赖登记表，变更时同步更新连线与时间，并在排期调整、依赖变更和里程碑前复审。
先定节点：工作项拆到什么粒度才能画依赖
依赖图的节点是工作项，节点粒度直接决定图能不能用。判断标准有三条：能独立交付一个可验收的产物；有明确的完成标志，能回答“做到什么程度算结束”；能由单一角色负责，不需要多人共同签字才算完成。三条同时满足，就适合作为节点；缺一条，就要考虑合并或继续拆分。
拆得过细的典型表现是节点数量膨胀、大量节点只持续半天到一天、节点之间全是串行连线，图看起来密但推不出有意义的顺序。调整方法是把同一交付物下的连续动作合并成一个节点，把检查、修改类动作并入产出它的工作项。拆得过粗的表现是一个节点横跨数周、负责人写了两三个角色、完成标志只能写“基本完成”。调整方法是按交付物切分：一个节点对应一份可评审的文档、一个可测试的版本、一次可确认的评审结论。
每个节点至少记录以下字段，缺字段的节点在后续排期和校验中会成为盲点：
| 字段 | 填写要求 | 用途 |
|---|---|---|
| 工作项名称 | 动宾结构，指向具体产物 | 识别节点、避免同名混淆 |
| 负责人 | 单一角色，可含备份人 | 依赖确认与变更对接 |
| 预计开始与结束 | 带日期，注明是承诺还是估算 | 排期推算的输入 |
| 交付物 | 可指认的文件、版本或结论 | 判断依赖是否成立 |
| 验收标准 | 可核验的完成条件 | 确定完成—开始依赖的触发点 |
节点清单完成后先做一次自检：随机抽三个节点，看负责人能否在不询问他人的情况下说清交付物和完成标志。说不清就说明粒度或字段还没到位，此时连线只会把模糊放大。
写清依赖关系：四类前置条件与连线规则
连线之前先判断依赖是否真实成立。必要条件只有一条：上游的输出是下游的输入，且缺了它下游无法开始或无法完成。满足这条才连线；只是时间上先后发生、或者双方需要沟通，都不构成任务依赖。
依赖分四类，适用场景和表达方式不同：
| 依赖类型 | 含义 | 典型场景 | 连线表达 |
|---|---|---|---|
| 完成—开始（FS） | 上游完成后下游才能开始 | 设计评审通过后才能进入开发 | 最常用，默认类型 |
| 开始—开始（SS） | 上游开始后下游才能开始 | 联调开始后测试环境搭建才能启动 | 标注提前量 |
| 完成—完成（FF） | 上游完成后下游才能完成 | 回归测试完成才能关闭发布单 | 标注滞后量 |
| 开始—完成（SF） | 上游开始后下游才能完成 | 交接班场景，较少使用 | 谨慎使用，易误设 |
提前量与滞后量用来表达两类真实情况：上游产出部分可用时，下游可以提前介入，设置负的提前量；上下游之间需要留出稳定期、观察期或冷却期，设置正的滞后量。设置依据应写进依赖属性，例如“接口文档初稿完成后测试可提前两天编写用例”，而不是凭感觉填数字。没有依据的提前量会让排期看起来更紧凑，实际执行时反复返工。
两类常见误连需要排除。资源共用，比如两个任务由同一人执行，属于资源约束，应通过资源安排或调整负责人解决，写成依赖会让图失去顺序含义。审批等待，比如等待某个会议或签字，属于流程等待，可以作为约束说明或单独设置缓冲节点，不宜混入任务依赖，否则审批一延迟，整条链路都被误判为任务阻塞。
画图与排期：从依赖图推导执行顺序
依赖关系确认后，把图转成时间安排。正向推算从起点节点开始，按依赖类型计算每个节点最早开始和最早结束时间：完成—开始依赖下，下游最早开始等于上游最早结束加滞后量；开始—开始依赖下，下游最早开始等于上游最早开始加提前量。逐层推到终点，得到项目的最短可能工期。
反向推算从要求的交付日期倒推，计算每个节点最晚开始和最晚结束时间。最晚时间与最早时间的差就是浮动时间。浮动时间为零的节点连成的链路是关键路径，这条链路上任何节点延迟一天，整体交付就延迟一天；浮动时间较大的节点有一定调整空间，可以用于吸收估算误差。
依赖图与甘特视图、里程碑的对应关系要一致：甘特视图中的条形长度对应节点工期，条形之间的箭头对应依赖连线，里程碑对应浮动时间为零的关键节点或外部承诺节点。三者不一致时，以依赖图为准排查，常见原因是甘特图中手工拖动过日期而没有同步依赖。
排期完成后先做三类冲突识别。环路：沿连线走一圈回到起点，说明依赖设置自相矛盾，必须拆解或改为约束。断链：某个节点没有任何前置也没有任何后续，且不属于起点或终点，通常是漏连或该节点应独立管理。时间倒挂：下游的最早开始早于上游的最早结束，说明依赖类型或提前量设置与工期不匹配，需要复核。
角色分工与依赖登记：谁维护、谁确认、谁变更
依赖图失效通常不是画得不好，而是画完没人管。需要明确三类角色：任务负责人对本节点的交付物、完成标志和对外依赖负责，发现上游无法按时交付时第一时间提出；项目协调人维护整张图和依赖登记表，组织排期推算与复审，处理跨节点的冲突；评审人在依赖确认和变更时把关，判断依赖是否真实、变更是否影响关键路径。
依赖登记表是图的配套台账，建议记录以下字段：
| 字段 | 说明 |
|---|---|
| 依赖编号 | 唯一标识，便于引用 |
| 上游工作项 / 下游工作项 | 两端节点名称与负责人 |
| 依赖类型 | FS / SS / FF / SF，含提前量或滞后量 |
| 依赖依据 | 上游输出是什么、为何缺一不可 |
| 确认人 / 确认时间 | 上下游负责人共同确认的记录 |
| 变更记录 | 变更内容、原因、影响评估、审批人、生效时间 |
依赖变更的触发条件包括：上游交付物范围变化、交付日期移动超过约定阈值、依赖类型调整、关键路径上的节点增减。触发后由提出方发起变更，项目协调人评估对关键路径和里程碑的影响，评审人确认，变更记录写入登记表并同步更新连线与排期。跨团队依赖需要指定双方对接人，确认方式建议采用书面确认加登记表留痕，口头约定在人员变动后极易丢失。
当依赖关系数量增多、跨角色协作频繁时，依赖登记和状态流转需要有承载的地方。ONES 方案围绕需求、基线、版本和变更建立统一管理对象，可支撑需求变更影响分析、过程状态追踪和交付结果回溯；其数字线程能力用于连接需求、开发、测试、变更和发布等环节，需求变化时可沿关联关系分析受影响的任务、测试和交付内容。对于依赖登记表中的确认人、确认时间和变更记录，可以在同一平台内随工作项状态流转保留过程记录，减少图与台账两张皮的情况。具体依赖关系的图形化呈现方式，需结合组织实际流程和工具配置评估。
示例：一次版本发布任务的依赖图设计
以下为演示情景，用于说明方法，不代表真实项目数据。某团队计划发布一个版本，要求在某月月底上线。
拆解结果。拆出六个节点：需求冻结（负责人：产品）、接口设计评审（负责人：架构）、开发联调（负责人：开发）、回归测试（负责人：测试）、发布说明编写（负责人：产品）、上线发布（负责人：运维）。每个节点都写明了交付物，例如需求冻结的交付物是签字版需求清单，接口设计评审的交付物是评审结论与接口文档。
连线与类型标注。需求冻结→接口设计评审为完成—开始；接口设计评审→开发联调为完成—开始，并设置两天提前量，因为接口文档初稿完成后开发可先搭框架；开发联调→回归测试为完成—开始；回归测试→上线发布为完成—完成，回归测试全部通过才能关闭发布；需求冻结→发布说明编写为开始—开始，需求确定后即可同步编写说明。
排期推算。正向推算得到各节点最早时间，反向推算从月底上线倒推。结果显示开发联调与回归测试浮动时间为零，构成关键路径；发布说明编写浮动时间约五天，可吸收需求微调带来的延迟。
发现的问题与调整。初版图中曾把“测试环境准备”与“开发联调”连成依赖，复核后发现两者只是资源共用同一台服务器，属于资源约束，改为在排期中错开使用时间，不再画依赖线。另有一处时间倒挂：回归测试的最早开始早于开发联调的最早结束，原因是提前量设置过大，调整为按联调完成节点触发。调整后重新推算，关键路径未变，但排期可执行性得到确认。
完成检查：依赖图可执行性的验收清单
依赖图交付前逐项核对，每项都要有可指认的证据，而不是凭印象判断。
| 检查项 | 通过标准 | 证据 |
|---|---|---|
| 节点完整性 | 每个节点字段齐全，负责人能说清交付物与完成标志 | 节点清单与抽查记录 |
| 依赖真实性 | 每条连线都能说明上游输出是下游输入且缺一不可 | 依赖登记表中的依赖依据 |
| 无环路 | 沿连线任意走一圈不能回到起点 | 图遍历结果或人工走查记录 |
| 无断链 | 除起点和终点外，节点均有前置或后续 | 节点出入度清单 |
| 时间一致性 | 不存在下游最早开始早于上游最早结束的倒挂 | 正向推算表 |
| 关键路径明确 | 浮动时间为零的链路已标出并通知相关角色 | 关键路径标注图 |
| 登记表同步 | 登记表条目与图中连线一一对应 | 比对记录 |
更新频率与复审时点建议：每次排期调整、每次依赖变更、每个里程碑节点前各复审一次；项目周期较长时，至少每周核对一次关键路径上的节点状态。常见返工原因集中在三类：节点粒度过粗导致依赖无法判断、把资源约束和审批等待误写成依赖、变更后只改日期不改连线。这三类问题都会让图在评审时看起来完整、执行时却推不动，应作为阻断项处理，未通过检查的依赖图不进入排期承诺。
常见问题
两个任务由同一个人负责，需要画依赖线吗？
通常不需要。同一人负责两个任务属于资源约束，画成依赖会让图失去顺序含义，也会把人员安排问题误判为任务阻塞。处理方式是在排期中错开执行时间，或调整负责人，让资源冲突在资源安排层面解决。只有当上游任务的产出确实是下游任务的输入、缺了它下游无法开始时，才应连线。
等待审批或等待会议结论，算不算任务依赖？
审批等待属于流程等待，与任务依赖不同。把它画成依赖线，一旦审批延迟，整条链路都会被误判为任务阻塞。更稳妥的做法是把审批作为约束说明，或单独设置一个缓冲节点并标注等待时长，让排期能看出这段等待占用了多少时间。若审批结论本身是下游工作的必要输入，可以在依赖依据中写明，但仍建议与任务依赖分开管理。
依赖图排完发现关键路径太长，可以怎么调整？
先确认关键路径上的节点是否都存在真实依赖。常见可调整的方向有三类：把可以并行的节点改为并行，例如上游产出部分可用时设置合理的提前量；把粒度过粗的节点按交付物拆分，让不互相等待的部分同时推进；复核关键路径上是否存在被误连的资源约束或审批等待，改为约束说明后重新推算。调整后需要重新做环路、断链和时间一致性检查，确认排期仍然可执行。
依赖图多久更新一次比较合适？
建议在三个时点固定复审：每次排期调整后、每次依赖变更后、每个里程碑节点前。项目周期较长时，至少每周核对一次关键路径上的节点状态。更新时同步修改连线、时间和依赖登记表，避免只改日期不改关系。复审记录可以作为依赖图可执行性的证据保留。
跨团队依赖怎么确认和留痕？
跨团队依赖需要双方各指定一名对接人，确认方式采用书面确认并在依赖登记表中留痕，记录上下游工作项、依赖类型、依赖依据、确认人和确认时间。口头约定在人员变动后容易丢失，也不便于变更时追溯。发生变更时，由提出方发起，双方对接人确认影响范围，再更新连线与排期。
依赖关系多了以后，用什么方式承载登记和变更记录？
依赖数量增多、跨角色协作频繁时，登记表和状态流转需要有统一的承载位置。ONES 方案围绕需求、基线、版本和变更建立统一管理对象，可支撑需求变更影响分析、过程状态追踪和交付结果回溯；其数字线程能力用于连接需求、开发、测试、变更和发布等环节，需求变化时可沿关联关系分析受影响的任务、测试和交付内容。依赖登记表中的确认人、确认时间和变更记录可以随工作项状态流转保留过程记录。具体依赖关系的图形化呈现方式，需结合组织实际流程和工具配置评估。
