任务依赖规则怎么定：从识别到排期落地

2026年11月6日

任务依赖规则要解决的是“哪些工作项之间存在先后约束、由谁确认、以什么形式记录、变更时怎么处理”。本文给出一套可直接落地的规则构成：先统一依赖类型与必填字段，再按步骤识别和录入依赖，明确各角色职责，用依赖链校验排期，最后用检查清单确认规则真正被执行。

Table of Contents

要点总览（TL;DR）

依赖规则先定四件事：允许使用的依赖类型、每条依赖的必填字段、依赖与关联及父子关系的边界、适用的工作项层级，再把这些写进工作项模板。
识别依赖从里程碑和交付物倒推，录入时逐项核对方向、类型、滞后时间依据和是否形成循环，只登记真正影响排期的约束。
任务负责人提出并维护依赖，依赖对方负责人确认可行性，项目负责人裁定跨团队冲突并审批解除，解除与类型变更要留记录。
排期校验用依赖链推算最早开始时间并识别关键路径，滞后时间和外部依赖单独作为风险项跟踪。
规则是否落地，用字段完整率、确认状态比例、循环与孤立依赖、变更记录、排期同步五项定期检查。

任务依赖规则先定哪几件事

依赖规则的最小构成包括四部分：依赖类型的选择范围、每条依赖必须记录的字段、依赖与关联/父子关系的边界、规则适用的工作项层级。这四项定清楚，规则才能转成工作项模板里的字段和必填校验，而不是停留在口头约定。

依赖类型的选择范围

常用依赖类型有四种，团队应明确哪几种允许使用、默认用哪一种：

依赖类型	含义	适用场景
完成—开始（FS）	前置完成后，后置才能开始	默认类型，适用于大多数串行交付
开始—开始（SS）	前置开始后，后置才能开始	两项工作可并行推进，但后置需在前置启动后才能动工
完成—完成（FF）	前置完成后，后置才能完成	收尾工作需等待前置成果确认，如验收依赖开发完成
开始—完成（SF）	前置开始后，后置才能完成	较少使用，适用于交接班类场景

实际使用通常以完成—开始为主，其余类型只在确有并行或交叠需要时启用。类型放得越宽，录入时判断成本越高，排期推算也越容易失真，因此建议在规则中写明“默认FS，使用其他类型需在依赖说明中写明理由”。

每条依赖必须记录的字段

一条依赖记录至少包含六个字段，缺一项都会影响后续排期推算或变更追溯：

前置工作项：必须先发生的那一项，需带唯一编号。
后置工作项：受约束的那一项，需带唯一编号。
依赖类型：从团队允许的类型中选择。
滞后时间：前置满足条件后，后置还需等待的时间，如“评审通过后隔1个工作日启动”。没有等待需求时填0，不留空。
确认人：对这条约束真实性负责的人，通常是依赖对方负责人。
状态：至少包含待确认、已确认、已解除三种，用于区分“提出来的约束”和“生效中的约束”。

依赖与关联、父子关系的区别

三者容易混用，规则中应写明各自用途：普通关联只表示“有关系”，不约束先后；父子关系表示层级归属，子任务属于父任务，但不必然构成先后约束；只有依赖表达“先后约束”，会影响排期推算。录入时如果只是想标记“这两项相关”，应使用关联；只有当前置未完成会直接阻塞后置时，才建立依赖。

规则适用的工作项层级

团队需明确在哪几层允许建立依赖，例如只在任务层建立、需求层只做汇总，或允许需求与任务之间跨层依赖。同一约束在多个层级重复登记，会导致排期推算重复计算、变更时漏改。建议选定一个主层级承载依赖，其他层级通过汇总视图查看，不重复建链。

识别依赖并录入工作项的操作步骤

识别依赖的起点是交付物和里程碑，而不是任务列表本身。按以下步骤执行，每一步都有明确的输入、动作和输出。

第一步：从里程碑倒推交付物

输入是项目里程碑清单。动作是逐个里程碑列出必须交付的成果，例如“接口文档定稿”“测试环境可用”“上线包发布”。输出是一份交付物清单，每项交付物标注目标日期。完成标志是每个里程碑至少对应一项可验收的交付物。

第二步：为每项交付物找产出工作项

动作是问两个问题：“这项成果由哪些工作项产出？”“这些工作项之间谁必须先完成？”据此形成前置—后置对。输出是候选依赖对列表。此阶段只记录真实阻塞关系，弱关联先不登记。

第三步：按检查项录入依赖

录入每条依赖时逐项核对：

方向是否正确：前置与后置不能颠倒，录入后回读一遍“A完成后B才能开始”是否成立。
类型是否匹配：确认实际约束是完成后才能开始，还是开始后即可并行，避免一律套用FS。
滞后时间是否有依据：填写等待天数时写明来源，如评审周期、环境准备时间；无依据的滞后时间应改为0。
是否形成循环：录入前检查新依赖是否与已有依赖构成闭环。发现循环时回到业务实际判断哪条约束不成立，修正或删除该条，而不是简单清空全部依赖。

第四步：控制依赖数量

只登记真正影响排期的约束。判断标准是：如果这条依赖不成立，后置工作项能否按原计划开始或完成。答案是“能”的，改用普通关联表达。依赖清单膨胀会让排期推算被大量弱约束干扰，关键路径反而看不清。

第五步：确认并置为已确认

每条依赖提交后，由依赖对方负责人确认可行性，确认后状态改为已确认。完成标志是：依赖清单中每条记录都有确认人，且状态为已确认或已解除，不存在长期停留在待确认的记录。待确认依赖在排期时只能按风险项处理，不能作为确定约束参与推算。

角色分工与各环节交付物

依赖规则无人执行，通常是因为提出、确认、维护、解除四个动作没有落到具体角色。建议按以下边界分工：

角色	职责	交付物
任务负责人	识别本工作项的前置与后置约束，提出依赖并填写类型、滞后时间；依赖变化时及时更新状态	依赖提出记录、状态更新记录
依赖对方负责人	确认依赖是否真实成立、时间是否可行；对不成立的依赖提出修正意见	确认记录（含确认意见）
项目负责人	裁定跨团队依赖冲突与优先级；审批依赖解除；在排期评审中校验依赖链	依赖清单、冲突裁定记录、变更记录

确认与变更的处理方式

新增依赖采用“提出—确认”两步：任务负责人提出，依赖对方负责人确认，跨团队依赖由项目负责人知会。解除依赖和修改依赖类型属于影响排期的变更，应走审批并留记录，记录中写明变更原因、影响的后置工作项和排期调整结果。仅调整滞后时间且不影响交付日期的，可采用知会方式。

状态更新与排期调整的交接时点

依赖状态变化后，后置工作项的负责人应在当次排期调整前收到通知，项目负责人在排期评审时统一核对。交接时点建议固定在每周排期会前，避免依赖已解除但排期仍按旧约束推算。

用依赖链校验排期的示例

以下为演示情景，用于说明依赖链如何影响排期判断，数值为假设。

某版本计划包含四项任务：A“接口设计”（3天）、B“前端页面开发”（5天）、C“接口联调”（2天）、D“验收测试”（2天）。依赖关系为：C依赖A完成（FS，滞后0天）；B依赖A开始（SS，滞后1天，即A启动1天后B才能开始）；D依赖C完成（FS，滞后0天）。

按依赖链推算最早开始时间

假设A在第1天启动。B受SS约束，最早第2天启动，第6天完成。A第3天完成，C最早第4天启动，第5天完成。D依赖C完成，最早第6天启动，第7天完成。关键路径为A→C→D，决定交付日期；B虽工期更长，但受SS约束提前启动，不构成关键路径。

滞后时间与外部依赖的处理

若C还依赖外部供应商提供测试账号，该外部依赖应单独标注为风险项，并给出承诺到位日期。滞后时间填“账号到位后1天”，而不是凭感觉填3天。外部依赖未确认前，D的排期只能按风险区间给出，不能当作确定日期。

示例暴露的风险与调整动作

该示例的风险在于：A一旦延期1天，C、D顺延，交付日期直接受影响；B的SS约束若被误录为FS，B将推迟到第4天启动，排期被虚增。调整动作包括：为A增加前置评审确认、把B的依赖类型核对为SS、将外部账号依赖列入风险跟踪并在到位后更新滞后时间。这说明依赖类型和方向录错，会直接改变排期结论。

在工具层面，依赖字段、确认状态和依赖链视图需要由工作项管理承载。ONES 工作项管理可用于记录工作项之间的依赖关系与状态，具体字段配置和依赖视图呈现方式，建议按团队实际使用的版本核验后再写入模板。

规则落地后的完成检查

规则是否被执行，可以用以下清单逐项核对，建议每月或每个版本结束时检查一次：

字段完整率：抽查依赖记录，前置、后置、类型、滞后时间、确认人、状态六项是否齐全，滞后时间是否留空。
确认状态比例：统计已确认依赖占全部依赖的比例，长期待确认的记录是否已推动确认或关闭。
循环依赖排查：用依赖链视图检查是否存在闭环，闭环中的每条约束是否都有业务解释。
孤立依赖排查：检查是否存在指向已关闭工作项、或后置工作项已取消但依赖未解除的记录。
变更记录：抽查解除和类型变更的依赖，是否留有原因、影响范围和排期调整记录。
排期同步：对比依赖状态与排期日期，确认已解除的依赖不再影响后置工作项的排期，新增依赖已反映在最新排期中。

检查发现的问题应回到对应环节修正：字段缺失补录、循环依赖回到业务判断、变更无记录则补充审批动作。检查结果可作为下一轮规则修订的依据，例如某类依赖反复出现方向录错，就在模板中增加方向校验提示。

常见问题

依赖类型选得越多越好吗？团队只允许完成—开始可以吗？

类型多少取决于团队实际的并行方式，不取决于工具支持多少种。只允许完成—开始（FS）是可行的起点，适合大多数串行交付；当出现“后置工作必须等前置启动后才能动工”这类真实场景时，再放开开始—开始（SS）。类型放得越宽，录入时的判断成本越高，排期推算也越容易失真。建议在规则中写明默认使用FS，使用其他类型需在依赖说明中写明理由，并定期抽查理由是否成立。

发现循环依赖时，应该删掉哪一条？

循环依赖说明至少有一条约束与业务实际不符，处理方式是回到业务判断，而不是简单清空。逐条问“如果去掉这条约束，后置工作项能否按原计划开始或完成”，能的那条就是弱关联，应改为普通关联或删除；两条都成立时，说明排期本身存在矛盾，需要项目负责人裁定优先级或调整交付日期。修正后重新检查闭环是否解除，并在变更记录中写明原因。

外部供应商或第三方交付的依赖怎么登记？

外部依赖同样按前置—后置记录，但要把“承诺到位日期”和“滞后时间”分开填写：滞后时间写前置满足条件后还需等待的时长，例如“账号到位后1个工作日”，而不是凭感觉填一个总天数。外部依赖未确认前，后置工作项的排期只能按风险区间给出，不能当作确定日期参与关键路径推算。建议把外部依赖单独列入风险跟踪，到位后及时更新状态和滞后时间。

依赖已经解除，但排期没改，会有什么后果？

已解除的依赖如果仍留在排期推算中，后置工作项会被一个不存在的约束拖住，交付日期被虚增，团队也可能因此误判关键路径。处理办法是把依赖状态更新与排期调整绑定在同一时点：依赖状态变化后，后置工作项负责人应在当次排期调整前收到通知，项目负责人在排期评审时统一核对。检查时对比依赖状态与排期日期，确认已解除的依赖不再影响后置工作项。