任务依赖图怎么设计：从识别依赖到落地检查

2026年11月6日

设计任务依赖图，先确定这张图要回答什么问题、覆盖哪些工作项，再按“拆工作项—识别依赖—定义依赖类型与约束—排布层级与关键路径—标注责任人与交付物—评审与维护”的顺序推进。最终产物是一张可读的依赖关系图加一份依赖清单：每个节点对应一个可交付的工作项，每条连线写清前置条件、依赖类型和验证方式。本文聚焦工作项安排层面的依赖关系，不展开项目整体进度计划与人员负载平衡。

Table of Contents

要点总览（TL;DR）

先写清图的用途、覆盖范围和节点粒度，再开始画；节点统一到“有明确完成标志、有单一责任人”的层级。
按“拆工作项—识别依赖—定义类型与约束—排层级与关键路径—标注责任人与交付物—形成依赖清单”六步推进，图负责直观呈现，清单负责精确记录。
依赖从交付物、审批、环境与资源、外部团队承诺四类来源逐项排查；类型默认用完成—开始，其他类型须写明适用前提。
每条依赖都要有前置条件、验证方式和前后双方确认人，关键路径要标注并安排缓冲。
评审解决画得对不对，维护解决还能不能用：范围变更、时间调整、依赖解除时更新，并保留版本记录。

先定图的用途与范围，再动手画

依赖图最常见的失败，是画得很完整却没人用。动手前先把三件事写清楚：这张图服务什么决策、覆盖哪些工作项、细化到什么粒度。三者确定后，图的节点数量、连线密度和维护成本才有边界。

用途决定图的读法

同一批工作项，用途不同，图的重点也不同。用于排期校验时，图要突出前后衔接和关键路径，帮助判断某个环节推迟会连带影响哪些工作；用于交接确认时，图要突出每条依赖的接口人和承诺时间，让上下游对“谁在等谁”达成一致；用于风险识别时，图要突出外部依赖、审批环节和单点依赖，把容易断链的位置标出来。建议在图的标题或说明区写明用途，避免一张图被要求同时承担三种读法。

范围与粒度要一起定

范围指图覆盖的工作项边界，常见选择是只覆盖当前迭代、只覆盖某条交付链路，或覆盖某个跨团队协作事项。粒度指节点细化到什么层级：任务级适合执行排期，故事级适合需求到开发的衔接，交付物级适合跨团队交接。粒度越细，依赖越容易识别，但图的维护成本也越高。一个实用做法是：节点统一到“有明确完成标志、有单一责任人”的层级，再细的步骤放进任务内部，不单独成节点。

与相邻管理主题划清分工

依赖图回答“谁必须先完成、谁在等谁”，项目整体进度计划和里程碑管理回答“整体何时交付”，人员容量管理回答“谁有空做”。三者可以互相引用，但不要混在一张图里。依赖图里可以标注计划时间，用于判断依赖是否可行；人员负载冲突则记录到单独的问题清单，交给相应的计划或资源管理环节处理。

这一节的产出是一页设计说明，至少包含四项：图的用途、覆盖范围、节点粒度、明确不纳入的内容。写完后请一位下游使用者确认，能看懂用途和边界再开始画。

核心步骤：从工作项拆解到依赖图成型

依赖图的成型可以拆成六步。每一步都有输入、动作、输出和完成标志，按顺序推进，避免边画边改导致返工。

第一步：拆解工作项并统一命名与编号

输入是需求说明、交付范围或上一级计划。动作是把范围拆成可交付的工作项，每个工作项有唯一编号、统一命名规则和一句话完成标志。输出是一份工作项清单。完成标志是：任意两个工作项的名称不会混淆，每个工作项都能回答“做完是什么样”。

第二步：识别依赖来源

依赖容易漏，按来源逐项排查比凭印象画线可靠。常用四类来源：

交付物依赖：下游工作需要上游的文档、设计、接口、数据或组件才能开始。
审批依赖：需要评审、签字或合规确认后才能推进。
环境与资源依赖：测试环境、账号、设备、许可证等就绪后才能执行。
外部团队依赖：其他团队或供应商的交付、排期承诺和接口人确认。

排查时对每个工作项问三个问题：开始前必须已经有什么？进行中需要谁配合？完成后要交给谁验证？答案中出现的对象，就是候选依赖。

第三步：定义依赖类型与约束

依赖类型用于说明前后工作项在时间上的约束关系。常用四类如下：

类型	含义	典型场景	使用注意
完成—开始（FS）	前置工作完成后，后续工作才能开始	设计评审通过后进入开发	排期中最常用，优先用它表达
开始—开始（SS）	前置工作开始后，后续工作才能开始	联调与冒烟测试同步启动	需写明允许的提前量
完成—完成（FF）	前置工作完成后，后续工作才能完成	文档定稿与发布说明同步收尾	容易掩盖开始时间问题，慎用
开始—完成（SF）	前置工作开始后，后续工作才能完成	交接班场景	项目排期中较少使用

选型原则是先默认使用完成—开始，只有当业务上确实存在并行或同步收尾要求时，才改用其他类型，并在依赖清单中写明适用前提。每条依赖还要写清前置条件和验证方式：前置条件是“什么状态算满足”，验证方式是“由谁、看什么、确认满足”。

第四步：排布层级、识别关键路径与并行分支

把工作项按依赖先后排成层级，同一层内没有相互依赖的工作项可以并行。沿着最长依赖链走一遍，得到决定整体最短工期的关键路径；关键路径上的工作项一旦延误，整体完成时间随之推迟，应优先配置关注和缓冲。并行分支则要检查是否存在隐藏的共享资源冲突，例如两个并行任务依赖同一位评审人。

第五步：标注责任人、交付物与计划时间

每个节点标注唯一责任人和交付物，每条连线标注依赖类型、前置条件和验证方式。计划时间用于校验依赖是否可行，不作为承诺对外发布。责任人指对该工作项完成负责的人，配合方记录在依赖清单中，不重复占用节点。

第六步：形成依赖清单

图负责直观呈现，清单负责精确记录。建议字段如下：

字段	填写要求
依赖编号	唯一编号，便于评审和变更引用
前置工作项	编号与名称
后续工作项	编号与名称
依赖类型	FS/SS/FF/SF，并写明提前量或同步条件
前置条件	可观察的状态描述
验证方式	验证人、验证材料、确认动作
责任人	前置方与后续方各一名
计划时间	前置完成时间与后续开始时间
状态	待确认、已确认、已解除、已变更

完成标志是：图中每条连线都能在清单中找到对应记录，清单中每条记录都能在图中定位。

角色分工与各环节交付物

依赖图不是一个人的作品。拆解、确认、维护分别由不同角色承担，职责清楚，图才不会在评审后无人更新。

角色	主要动作	交付物
任务负责人	拆解自己负责的工作项，说明开始前需要什么、完成后交给谁	工作项说明、前置条件与交付物描述
项目经理或计划负责人	组织依赖识别与评审，汇总依赖清单，维护图与版本	依赖图、依赖清单、评审记录
跨团队接口人	确认外部依赖内容、接口人和承诺时间，反馈变更	外部依赖确认记录
评审参与者	检查依赖完整性、类型合理性和责任人明确性	评审意见与整改项

分工时注意两点：每条依赖必须有前置方和后续方各一名确认人，避免“大家都以为对方知道”；图的维护权集中到计划负责人，其他人通过变更请求修改，防止多头编辑造成版本混乱。

示例：一条交付链路的依赖图怎么画

以下为演示情景，用于说明填写方法，不代表任何真实项目数据。

场景与工作项清单

某功能从需求到上线，拆出六个工作项：A 需求定稿、B 交互设计、C 接口设计、D 前端开发、E 后端开发、F 联调测试。每个工作项有唯一编号、责任人和完成标志，例如 A 的完成标志是“需求评审通过并归档”。

依赖识别与类型判定

逐项排查后得到四条主要依赖：B 依赖 A（设计需要定稿需求），类型为完成—开始；C 依赖 A，类型为完成—开始；D 依赖 B 和 C，类型为完成—开始；F 依赖 D 和 E，类型为完成—开始。若联调要求前后端同时具备条件，可在 F 与 D、E 之间补充开始—开始关系并写明同步条件，但默认仍以完成—开始表达更清晰。

依赖清单填写示例

依赖编号	前置	后续	类型	前置条件	验证方式	责任人
R1	A 需求定稿	B 交互设计	FS	需求评审通过并归档	设计负责人查阅归档记录后确认	A、B 负责人
R2	A 需求定稿	C 接口设计	FS	需求评审通过并归档	后端负责人核对需求版本号	A、C 负责人
R3	B 交互设计	D 前端开发	FS	设计稿评审通过	前端负责人在评审记录中确认	B、D 负责人
R4	C 接口设计	D 前端开发	FS	接口文档评审通过	前端负责人核对接口文档版本	C、D 负责人
R5	D、E 开发完成	F 联调测试	FS	前后端自测通过并提交提测单	测试负责人核对提测单	D、E、F 负责人

图形排布与关键路径标注

按层级排布：第一层 A，第二层 B 和 C 并行，第三层 D 和 E 并行，第四层 F。从 A 到 F 的最长链为 A—B—D—F 或 A—C—D—F，取实际工期较长的一条作为关键路径，用加粗连线或颜色标出。并行分支 B 与 C 之间若共享同一位评审人，应在图中加注共享资源提示。

常见错误与修正

把“沟通”画成依赖：修正为具体交付物，例如“接口文档评审通过”。
依赖类型全部写成完成—开始却存在实际并行：修正为补充开始—开始并写明同步条件。
只画线不写验证方式：修正为每条依赖补充验证人和验证材料。
关键路径未标注：修正为沿最长链标注，并在评审时说明缓冲安排。

评审、维护与完成检查

依赖图的价值在于持续可用。评审解决“画得对不对”，维护解决“还能不能用”，检查清单用于逐项验收。

评审检查项

完整性：每个工作项的开始条件是否都已识别，外部依赖是否有接口人确认。
类型正确性：依赖类型与业务约束是否一致，非完成—开始的依赖是否写明前提。
责任人明确：每条依赖是否有前置方和后续方确认人。
可验证：前置条件是否可观察，验证方式是否落到具体人和材料。
关键路径：是否标注，关键路径上的工作项是否有缓冲安排。

更新触发条件与版本记录

出现以下情况时触发更新：范围变更导致工作项增减、计划时间调整、依赖被解除或新增、外部团队承诺变化。每次更新记录版本号、变更内容、变更原因和确认人，旧版本保留可查。依赖状态从“待确认”推进到“已确认”，解除时标记“已解除”并注明依据，避免已失效的连线继续影响排期判断。

完成检查清单与阻断项

交付前逐项核对：设计说明中的用途、范围、粒度是否已确认；工作项是否都有唯一编号和完成标志；依赖清单与图是否一一对应；每条依赖是否都有类型、前置条件、验证方式和责任人；关键路径是否标注；评审意见是否闭环；版本记录是否建立。其中，依赖缺少验证方式、外部依赖无接口人确认、关键路径未标注，应作为阻断项，整改完成后再发布。

当依赖关系需要多人持续维护时，可以把工作项和依赖记录在项目管理工具中，让依赖状态随工作项进展同步更新。ONES 支持在工作项之间建立关联关系并记录状态，计划负责人可以据此汇总依赖清单、跟踪确认与解除情况；具体字段配置和可视化方式以实际使用版本的官方说明为准。这样图与清单共用同一份数据来源，评审和变更记录也有据可查。