设计任务依赖图，核心动作是把工作项拆到能判断先后的粒度，逐条标注前置与后置关系、依赖类型和约束条件，再检查环路与关键路径，最后落到工作项字段和评审动作上。本文聚焦工作项安排层面的依赖关系，交付一套可执行的绘制步骤、角色分工、填写示例与完成检查清单。
要点总览（TL;DR）
- 先定节点口径：按可交付工作项或阶段任务二选一，同一张图内保持一致；连线用完成到开始、开始到开始、完成到完成、开始到完成四类关系表达先后约束。
- 每条依赖至少记录前置、后置、类型、约束条件、依据说明、责任人和状态，依据说明是后续变更时判断能否删除连线的关键。
- 绘制按五步推进：统一命名收集工作项、逐项识别前置条件、连线标注类型与约束、处理环路、标出关键路径与浮动时间。
- 建图、确认、维护分属不同角色，每张图设唯一维护责任人，并在范围变化、外部承诺变动、关键路径延期三类事件发生时触发更新。
- 交付前用检查清单核对节点与连线完整性、环路与孤立节点、依据可追溯性和更新责任，出现阻断项应返工补图。
先定节点粒度与依赖类型
依赖图能否指导排期，取决于画图之前是否先定好两件事：节点代表什么，连线代表什么。这两条规则不统一，图上的箭头就会失去约束力，排期时仍然要靠口头确认。
节点粒度：两种口径，选一种并保持一致
节点可以按可交付工作项定义，也可以按阶段任务定义。按可交付工作项定义，节点对应一个能验收的产出，例如“完成接口联调”“提交测试报告”，优点是便于跟踪交付结果，依赖关系直接对应交付物之间的先后；按阶段任务定义，节点对应一个过程环节，例如“需求评审”“开发”“测试”，优点是图形简洁，适合在计划早期快速搭出框架。同一张图内应保持一种口径，混用会让“完成”的含义在不同节点上不一致，导致依赖判断失真。
粒度判断有一个实用标准：如果一个节点无法回答“它完成时，什么可以开始”，说明拆得不够细；如果一个节点需要再拆三层才能说清前后关系，说明拆得过细，可以先合并到可交付层级。
依赖类型：四类先后关系与内外之分
连线表达的是先后约束，常见有四类。选择哪一类，取决于前置工作项需要推进到什么程度，后置工作项才能启动。
| 依赖类型 | 含义 | 典型场景 |
|---|---|---|
| 完成到开始（FS） | 前置完成后，后置才能开始 | 接口开发完成后才能联调 |
| 开始到开始（SS） | 前置开始后，后置才能开始 | 文档撰写开始后，同步启动评审准备 |
| 完成到完成（FF） | 前置完成后，后置才能完成 | 测试报告完成前，发布说明不能定稿 |
| 开始到完成（SF） | 前置开始后，后置才能完成 | 新流程上线开始后，旧流程才能收尾关闭 |
除类型外，还要区分内部依赖与外部依赖。内部依赖的两端都在本团队可控范围内，调整时由团队自行协商；外部依赖的一端在团队之外，例如其他团队交付的组件、供应商提供的环境、上游系统的数据接口。外部依赖需要单独标记，并在评审中确认对方的承诺时间，否则图上看似完整的链路会在执行时断裂。
依赖属性的最小字段集
每条依赖至少记录七个字段，才能支撑后续的排期与维护：前置工作项、后置工作项、依赖类型、约束条件（如提前量或滞后量）、依据说明、责任人、状态。依据说明是容易被省略却最关键的一项，它回答“为什么存在这条依赖”，例如“联调需要接口文档定稿”。没有依据说明的依赖，在变更时无人敢删，最终变成图上的冗余连线。
按步骤绘制任务依赖图
绘制过程按五步推进，每一步都有明确的输入、动作和输出，完成标志是输出物可以交给下一位角色继续处理。
第一步：收集工作项清单并统一命名
输入是需求列表、拆分后的任务和已有计划。动作是把候选工作项汇总成一张清单，统一命名规则，建议采用“动词+对象+结果”的形式，例如“完成支付模块联调”“输出上线检查表”。命名统一后，图上节点可以直接对应到工作项，避免出现“开发”“开发阶段”“后端开发”指代同一件事的情况。输出是一份去重、命名一致的工作项清单。
第二步：逐项识别前置条件并记录依据
输入是工作项清单。动作是对每个工作项提问：它开始之前，必须有什么已经发生？把答案写成前置条件，并附上一句依据。识别时优先问三类问题：需要谁的产出、需要什么环境或数据、需要哪个决策或确认。输出是每个工作项的前置条件列表，每条都带依据说明。这一步由任务负责人完成，因为他们最清楚实际开工条件。
第三步：连线并标注依赖类型与约束
输入是带前置条件的工作项清单。动作是把前置条件转成连线，为每条连线标注依赖类型、约束条件（如需要提前几天提供、允许滞后几天）以及内部或外部属性。输出是一张节点、连线、属性齐全的初版依赖图。此时不必追求美观，先保证每条连线都有类型和依据。
第四步：识别环路并拆分或调整
输入是初版依赖图。动作是沿箭头方向检查是否存在闭环，即 A 依赖 B、B 又间接依赖 A。环路通常来自三种情况：工作项拆得过大，把本可并行的部分捆在一起；依赖依据写错，把“希望同步”误记为“必须先后”；外部依赖与内部依赖混在一起。处理方式对应为：拆分工作项、修正依赖类型或依据、把可协商的依赖降级为提醒而非硬约束。输出是无环路的依赖图，以及一份环路处理记录。
第五步：标出关键路径与浮动时间
输入是无环路的依赖图。动作是从起点到终点找出最长的一条依赖链，这条链上的工作项没有推迟空间，构成关键路径；其余工作项计算其可推迟而不影响后续的时间，即浮动时间。输出是标注了关键路径与浮动时间的图。关键路径上的工作项应作为排期和风险跟踪的重点，浮动时间较小的工作项也需要关注，因为它们离变成关键路径只差一次延期。
角色分工与交付物
依赖图不是一个人画完就结束的文档，建图、确认、维护分别由不同角色承担，每个角色交付可核对的产物。
| 角色 | 主要动作 | 交付物 |
|---|---|---|
| 任务负责人 | 识别本工作项的前置条件，写明依据与所需时间 | 带依据的前置条件列表 |
| 项目或计划负责人 | 汇总各工作项依赖，统一命名与粒度，连成整图 | 完整依赖图与关键路径标注 |
| 评审角色（跨团队接口人、技术负责人） | 确认跨团队依赖的可行性与承诺时间，判断环路处理方案 | 外部依赖确认记录与评审结论 |
| 维护责任人 | 在依赖变更、工作项拆分或排期调整时更新图与字段 | 更新后的依赖图与变更记录 |
维护责任需要配一个明确的更新触发条件，否则图会停留在初版状态。建议至少在三类事件发生时触发更新：工作项范围或拆分发生变化、外部依赖的承诺时间变动、关键路径上的工作项出现延期。维护责任人可以是计划负责人，也可以按模块分派，但每张图应有唯一责任人。
一个依赖图的填写示例
以下为一个演示情景，用于说明从工作项到连线的填写过程，不对应真实项目数据。
工作项拆分
场景是一个内部系统的版本发布准备，拆出五个工作项：A 完成接口开发、B 输出接口文档、C 完成联调、D 编写发布说明、E 执行上线检查。命名统一为“动词+对象+结果”，每个工作项都有明确负责人。
依赖关系与类型标注
逐项识别前置条件后，得到如下填写结果：
| 前置 | 后置 | 类型 | 约束条件 | 依据说明 | 内外 |
|---|---|---|---|---|---|
| B 输出接口文档 | C 完成联调 | 完成到开始 | 文档定稿后 1 个工作日内启动 | 联调需要按文档约定验证字段 | 内部 |
| A 完成接口开发 | C 完成联调 | 完成到开始 | 无额外提前量 | 联调对象为已开发完成的接口 | 内部 |
| C 完成联调 | E 执行上线检查 | 完成到开始 | 联调通过后启动 | 上线检查需基于联调结果 | 内部 |
| C 完成联调 | D 编写发布说明 | 开始到开始 | 联调开始后即可起草 | 发布说明可在联调过程中同步整理 | 内部 |
| 外部环境开通 | E 执行上线检查 | 完成到开始 | 需提前 3 个工作日申请 | 上线检查依赖目标环境可用 | 外部 |
环路或冲突的处理示例
初版图中曾出现一处环路：D 编写发布说明被标注为依赖 E 上线检查的结果，而 E 又依赖 C 联调完成，C 的前置中包含 D 提供的变更清单。检查后发现，“发布说明依赖上线检查结果”这一条依据不成立，实际需要的是联调结论，于是把 D 的前置改为 C，环路解除。这个例子说明，环路往往不是排期问题，而是依赖依据写错了对象。
关键路径的识别结果
沿箭头方向计算最长链：B→C→E 与 A→C→E 两条链在 C 汇合，其中 B 的文档定稿时间最长，因此关键路径为 B→C→E。D 与 C 为开始到开始关系，具有一定浮动时间，但仍需在联调结束前完成，否则会拖住发布。外部环境开通作为外部依赖，单独跟踪其申请时间。
把依赖图接入日常协作
依赖图只有进入工作项的字段和团队的评审节奏，才会随项目推进保持有效。落地方式可以归纳为记录、变更、解除、联动四个动作。
依赖字段在工作项上的记录方式
把依赖属性落到工作项本身，而不是只存在于一张独立的图里。每个工作项上记录其前置工作项、依赖类型、约束条件和依据说明，这样任何人在查看工作项时都能看到“它在等什么”。在 ONES 中，工作项支持通过属性字段记录关联关系与状态，团队可以把前置工作项和依赖说明作为工作项信息的一部分维护，使依赖图与工作项数据保持同源。具体字段配置方式需结合团队实际使用的产品能力确认。
依赖变更时的通知与评审动作
当某个工作项的范围、时间或负责人发生变化时，维护责任人检查受影响的依赖，更新字段并通知后置工作项的负责人。跨团队依赖的变更应进入评审，由接口人确认新的承诺时间，而不是由单方在图上直接改箭头。通知的内容应包含变更对象、影响的后置工作项和新的时间约束。
依赖解除与状态更新的交接
前置工作项完成后，其负责人更新状态，后置工作项的负责人据此确认是否可以启动。依赖解除同样需要记录，说明是正常完成解除还是因方案调整取消。取消的依赖要保留依据说明的修改记录，避免后续复盘时无法解释为什么这条约束消失了。
与排期调整的联动
关键路径上的工作项延期时，排期调整应同步反映到依赖图上：重新计算关键路径与浮动时间，检查是否有原本非关键的工作项转为关键。浮动时间被消耗到接近零的工作项，应提前进入风险跟踪。这样依赖图与排期表保持一致的判断口径，而不是两套各自维护的数据。
完成检查清单
依赖图交付前，按以下条目逐项核对。每条都应有可观察的判断依据，而不是主观感觉。
- 节点完整性：每个工作项都有唯一名称、负责人和明确的完成标准；同一张图内节点粒度口径一致。
- 连线完整性：每条依赖都有前置、后置、类型、约束条件和依据说明；外部依赖已单独标记。
- 环路检查：沿箭头方向不存在闭环；曾出现的环路均有处理记录，说明是拆分、改类型还是取消。
- 孤立节点检查：不存在既无前置也无后置、且不属于独立交付的工作项；若存在，确认其确实与其他工作无先后关系。
- 关键路径：已标出关键路径，关键路径上的工作项已纳入重点跟踪；浮动时间较小的工作项已识别。
- 依据可追溯：每条依赖的依据说明能回答“为什么存在”，且能找到提出该依据的负责人。
- 更新责任落实：每张图有唯一维护责任人，更新触发条件已写明，最近一次变更已记录。
- 阻断项与返工条件：明确哪些情况视为阻断（如外部依赖承诺时间未确认、关键路径存在未处理环路），出现阻断时应返工补图而不是带图推进。
清单全部通过，说明这张依赖图具备指导排期的基本条件；后续每次范围或时间变动后，重新核对连线完整性与关键路径两项即可维持其有效性。
常见问题
依赖图里的节点应该拆到多细才合适？
判断标准是节点能否回答“它完成时，什么可以开始”。如果答不上来，说明拆得不够细，需要继续拆到可交付层级；如果需要再拆三层才能说清前后关系，说明拆得过细，可以先合并。同一张图内保持一种口径，按可交付工作项或按阶段任务都可以，混用会让“完成”在不同节点上含义不一致。
外部依赖的承诺时间一直没确认，图还能继续用吗？
可以继续用，但应把这条外部依赖列为阻断项单独跟踪，而不是当作已确认的约束进入排期。处理方式是在评审中由跨团队接口人给出承诺时间，确认前在后置工作项上标注风险；如果承诺时间迟迟不落地，后置工作项的排期应保留浮动时间，避免把未确认的时间点当成既定前提。
工作项拆分发生变化后，依赖图需要全部重画吗？
不需要全部重画，但需要做局部核对。拆分变化会影响相关节点的前置与后置关系，维护责任人应检查受影响工作项的连线是否仍然成立、依据说明是否还准确，并重新计算关键路径。范围变化、外部承诺时间变动、关键路径工作项延期这三类事件发生时，都建议触发一次更新。
环路检查发现闭环，一般是什么原因造成的？
常见原因有三类：工作项拆得过大，把本可并行的部分捆在一起；依赖依据写错，把“希望同步”误记为“必须先后”；外部依赖与内部依赖混在一起。对应处理是拆分工作项、修正依赖类型或依据、把可协商的依赖降级为提醒。环路往往反映的是依赖依据写错了对象，先核对依据比直接调整排期更有效。
依赖图需要和排期表分开维护吗？
建议保持同一套判断口径。关键路径上的工作项延期时，排期调整应同步反映到依赖图上，重新计算关键路径与浮动时间，检查是否有原本非关键的工作项转为关键。如果图和排期表各自维护，两边的先后约束会逐渐不一致，执行时仍需口头确认，图就失去了指导作用。
