任务依赖规则示例的价值，在于把“接口联调要等接口文档评审通过”这类口头约定，写成一条可执行、可校验的字段记录。本文用一份虚构的版本发布计划演示填写过程：四类依赖（完成—开始 FS、开始—开始 SS、完成—完成 FF、开始—完成 SF）分别用在什么位置，滞后1天怎么表达，条件说明写到什么颗粒度才算可判断，并给出换项目时可直接套用的填写规则与适用边界。
要点总览（TL;DR）
- 一份合格的依赖记录需要写清四项：依赖两端的具体工作项、依赖类型、可判断的完成条件、确认方与承接方。
- 四类依赖中完成—开始（FS）是默认选择，适用于交接关系；开始—开始（SS）用于可并行推进的环节；完成—完成（FF）约束收尾同步；开始—完成（SF）作为辅助约束谨慎使用。
- 滞后量用于评审、审批、外部响应等可预期的等待期，填写时把等待原因写进条件说明；提前量会让后置任务在前置未完成时启动，没有明确并行依据时不填。
- 条件说明要写到第三方能判断的程度，包含可观察的产物或状态，以及谁确认、记录在哪里。
- 依赖规则只约束工作项之间的先后关系，整体进度预测归项目进度管理，人员容量冲突归资源负载与冲突管理。
示例要解决什么问题：依赖规则写到什么程度才算可用
排期讨论里最常见的依赖描述是“联调要等文档”“测试得等开发提测”。这类说法在会议上能达成共识，落到计划里却无法校验：等的是哪份文档、等到什么状态算完成、由谁确认。依赖规则示例要示范的，就是把这种模糊先后关系转成一条字段完整、可被他人复核的记录。
判断一条依赖记录是否合格，可以用四项标准逐条对照：
- 对象明确：依赖两端都是具体工作项，能定位到唯一负责人和交付物，而不是“前端那边”“测试阶段”这类笼统指代。
- 类型明确：写清是完成—开始、开始—开始、完成—完成还是开始—完成，避免双方对“等”的理解不一致。
- 条件可判断：前置任务的完成状态或交付物有客观判定口径，任何人看到都能回答“满足了没有”。
- 责任人有归属：明确谁确认前置完成、谁承接后置启动，出现延期时知道找谁对齐。
下文示例设定为一个虚构的版本发布计划，涉及需求评审、接口文档、接口联调、回归测试、上线检查等任务，团队与时间均为演示假设，不对应任何真实客户或实测数据。示例只讨论工作项之间的先后约束，不涉及整体进度预测与人员负载分配。
完整示例：一个版本发布计划中的依赖填写
示例背景：某版本计划在两周内完成从需求确认到上线检查的全过程，共拆出六个工作项——需求评审、接口文档编写、接口文档评审、接口联调、回归测试、上线检查。团队希望把其中影响排期的强依赖显式记录下来，作为排期评审和延期判断的依据。
按上述背景填写出的依赖记录如下表，共6条：
| 编号 | 前置任务 | 后置任务 | 依赖类型 | 提前/滞后 | 条件说明 | 责任人 |
|---|---|---|---|---|---|---|
| D1 | 需求评审 | 接口文档编写 | 完成—开始（FS） | 无 | 需求评审结论已记录，待开发事项清单已确认 | 产品负责人确认，后端负责人承接 |
| D2 | 接口文档编写 | 接口文档评审 | 完成—开始（FS） | 无 | 文档已提交评审，覆盖本期全部接口 | 后端负责人提交，技术负责人评审 |
| D3 | 接口文档评审 | 接口联调 | 完成—开始（FS） | 滞后1天 | 评审意见已闭环，文档定稿版本已发布 | 技术负责人确认，前后端联调负责人承接 |
| D4 | 接口联调 | 回归测试 | 开始—开始（SS） | 滞后2天 | 联调环境可用，核心接口已跑通首轮 | 联调负责人通知，测试负责人承接 |
| D5 | 回归测试 | 上线检查 | 完成—完成（FF） | 无 | 回归用例全部执行完毕，遗留缺陷已分级处理 | 测试负责人确认，发布负责人承接 |
| D6 | 接口文档评审 | 回归测试 | 开始—完成（SF） | 无 | 评审启动后，测试方可按定稿范围准备用例 | 技术负责人确认，测试负责人承接 |
关键路径上的依赖链为：需求评审 → 接口文档编写 → 接口文档评审 →（滞后1天）→ 接口联调 →（滞后2天）→ 回归测试 → 上线检查。这条链上任一环节延期，都会顺延后续任务，因此D1至D5被列为强依赖，纳入排期评审重点跟踪。D6属于辅助性约束，用于说明测试用例准备可以提前启动，不进入关键路径。
逐项解释：每条依赖为什么这样填
完成—开始（FS）：默认选择，适用于串行交接
D1、D2、D3都采用完成—开始，因为前置任务的产出是后置任务的直接输入：需求结论决定文档写什么，文档定稿决定联调按什么约定进行。FS的含义是前置任务完成后后置任务才能开始，它对应最常见的“交接”关系，也是示例中占比最高的类型。凡是后置任务必须拿到前置产出才能动手的场景，优先用FS，理解成本最低，校验也最直接。
开始—开始（SS）：用于需要并行推进的环节
D4把联调与回归测试设为SS并滞后2天，理由是回归测试不必等联调全部结束：联调环境可用、核心接口跑通首轮后，测试即可开始编写并执行部分用例，两边并行能压缩整体周期。滞后2天表达的是“联调开始两天后测试再介入”，给联调留出环境准备和首轮验证的时间。SS的适用前提是后置任务确实能基于前置任务的部分产出启动，如果测试必须等全部接口稳定，就应改回FS。
完成—完成（FF）：约束收尾同步
D5采用FF，含义是回归测试完成时上线检查也应完成。上线检查包含配置核对、发布单确认等收尾动作，这些动作可以在测试执行期间同步准备，但两者需要在同一时点收口，避免测试结束而上线检查尚未就绪。FF适合这类“同时结束”的收尾型约束，数量不宜多，否则会让排期失去弹性。
开始—完成（SF）：少见的辅助约束
D6用SF表达“接口文档评审一启动，测试就可以按定稿范围准备用例”。SF表示前置任务开始后后置任务才能完成，实际项目中用得较少，通常用于后置任务的收尾依赖前置任务的启动信号。示例保留它是为了说明四类依赖都能落到具体场景，但日常排期里SF出现频率低，填写时应确认没有更简单的FS或SS可以替代。
滞后1天：为评审意见闭环留出等待期
D3的滞后1天不是随意设定的缓冲，而是对应评审后的实际等待：评审意见需要整理、分工修改、再确认闭环，文档定稿版本发布存在一天左右的周转。滞后量适合表达这类可预期的等待期，如评审、审批、外部响应。填写时要把等待的原因写进条件说明，让后来者知道这一天在等什么；如果等待期无法预估，宁可先不填滞后量，在排期评审时再定。提前量则表示后置任务可以早于前置完成状态启动，风险较高，示例中未使用。
条件说明：写到能被第三方判断的程度
示例中每条条件说明都指向可核验的状态，例如“评审意见已闭环，文档定稿版本已发布”，而不是“评审差不多了”。可判断的条件通常包含两个要素：一个可观察的产物或状态（定稿版本、用例执行完毕、遗留缺陷已分级），以及一个确认动作（谁看过、记录在哪里）。条件说明写得越具体，依赖到期时越不需要反复沟通。
责任人：区分确认方与承接方
每条依赖都写了两类角色：确认前置完成的人，和承接后置启动的人。D3中技术负责人确认评审闭环，联调负责人据此启动联调。分开写的好处是延期时责任清晰——前置没完成找确认方，后置没启动找承接方，避免双方互相等待。
可迁移规律：换一个项目怎么套用这套写法
把示例中的选择提炼成规则，换到其他项目时可按以下五条执行：
- 先定对象再定类型：依赖两端必须是可交付、可指派的工作项。如果一端只能描述成“某个阶段”，先拆分工作项，再谈依赖类型。
- 默认用完成—开始：大多数交接关系都是FS。只有确认后置任务能基于前置任务的部分产出启动时，才改用SS；FF用于收尾同步；SF作为辅助约束谨慎使用。
- 滞后量用于等待期，提前量慎用：评审、审批、外部响应等可预期的等待用滞后量表达，并在条件说明中写明等待原因。提前量会让后置任务在前置未完成时启动，除非有明确的并行依据，否则不填。
- 控制依赖数量：只保留影响排期的强依赖，辅助性约束单独标注、不进入关键路径。依赖过多会让排期图难以维护，也会掩盖真正的瓶颈。
- 变更时留记录并通知双方：依赖的类型、滞后量或条件发生变化时，更新记录并通知确认方与承接方，避免一方按旧约定推进。
这套字段结构落到协作工具里，通常体现为工作项之间的依赖设置：在任务上登记前置工作项、选择依赖类型、填写提前或滞后时间与条件说明，排期视图据此展示先后关系。以ONES为例，工作项支持建立依赖关系并在计划中体现前后顺序，团队可以把上述表格中的字段对应到工作项依赖记录中，让排期评审直接基于系统内的依赖链核对，减少口头同步。具体可用的依赖类型与填写方式，以团队实际使用的工具配置为准。
适用边界：哪些情况不该用这套依赖写法
依赖规则约束的是工作项之间的先后关系，它的作用范围有限，以下情形需要交给其他管理动作处理：
| 情形 | 是否适用依赖规则 | 应采用的处理方式 |
|---|---|---|
| 两个工作项存在明确的交付先后 | 适用 | 按本文示例填写依赖记录 |
| 需要预测整体进度、判断能否按期发布 | 不适用 | 归入项目进度管理，结合关键路径与里程碑整体分析 |
| 多人争抢同一资源导致排队 | 不适用 | 归入资源负载与冲突管理，调整人力分配 |
| 依赖跨团队、跨组织 | 部分适用 | 记录依赖之外，额外约定确认机制与对接人 |
| 依赖链过长、环环相扣 | 需简化 | 合并或拆分工作项，只保留关键路径上的强依赖 |
人员容量冲突是典型的边界外问题：两个任务都依赖同一位工程师，这不是任务先后规则能解决的，需要从资源分配入手。跨团队外部依赖则要在依赖记录之外补充约定，例如固定的确认时点和升级路径，因为外部团队的完成状态不受本项目直接控制。当依赖链长到难以维护时，简化处理比继续叠加记录更有效——把连续的小任务合并为一个工作项，或只保留影响关键路径的依赖，其余用日常沟通跟进。
常见问题
依赖记录里的条件说明写到什么程度，才算可判断？
判断标准是：一个没参与讨论的人看到这条说明，能直接回答“满足了没有”。可判断的条件通常包含两部分：一个可观察的产物或状态，例如定稿版本已发布、用例全部执行完毕、遗留缺陷已分级；以及一个确认动作，例如谁看过、记录在哪里。像“评审差不多了”“文档基本可用”这类表述无法校验，应改成具体状态加确认人。
滞后量填了之后，前置任务提前完成，后置任务能不能提前开始？
滞后量表达的是可预期的等待期，例如评审意见闭环、外部响应周转。如果前置任务提前完成，等待期是否缩短需要由确认方和承接方共同判断：等待的原因消失了，可以调整滞后量并更新记录；等待的原因仍然存在，例如外部审批有固定时点，提前完成前置任务也不会让后置任务提前启动。变更后要通知双方，避免一方按旧约定推进。
跨团队的外部依赖，用这套依赖记录够不够？
不够。依赖记录能表达“哪个工作项等哪个工作项”，但外部团队的完成状态不受本项目直接控制，需要额外约定确认机制，例如固定的确认时点、对接人、延期时的升级路径。记录本身仍然要填，作为排期评审的依据；确认机制则补充在记录之外，两者配合使用。
依赖链太长、环环相扣，是继续补记录还是简化？
优先简化。依赖链长到难以维护时，继续叠加记录会让排期图失去可读性，也容易掩盖真正的瓶颈。常见处理方式有两种：把连续的小任务合并为一个工作项，减少节点数量；或者只保留影响关键路径的强依赖，其余辅助性约束用日常沟通跟进。简化后重新核对关键路径，确认没有遗漏影响交付的约束。
两个任务抢同一位工程师，能不能用依赖关系表达先后？
依赖关系表达的是工作项之间的交付先后，不是资源排队。两个任务都依赖同一位工程师，本质是人员容量冲突，需要从资源分配入手，例如调整投入顺序、拆分任务或补充人力。把它写成依赖记录，只会让排期看起来有约束，实际冲突仍然存在。这类问题归入资源负载与冲突管理处理。
