任务依赖规则要回答四个问题：谁先做、谁等谁、等多久、变了怎么办。本文给出一套可直接落地的最小规则集，覆盖依赖类型、必填字段、建立步骤、角色分工和检查清单。规则只处理工作项之间的先后关系，项目整体进度和人员容量冲突由其他机制负责。
要点总览（TL;DR）
- 依赖规则的最小规则集包括四类依赖关系（完成—开始、开始—开始、完成—完成、开始—完成）、六项必填字段和明确的工作项适用范围。
- 建立规则分四步：梳理常见先后关系、确定类型与字段规范、约定排期冲突处理顺序、发布并在首批项目执行。
- 任务负责人提出并维护依赖，协作方确认前置交付，项目经理确认跨团队依赖并裁决冲突，变更由提出方发起、项目经理决策。
- 排期冲突按“先查类型与滞后量、再查前置任务范围、最后调时间”的顺序处理，任何时间调整都记录原因与影响范围。
- 定期检查字段完整性、确认状态、循环依赖、悬空依赖和变更记录，用依赖导致的延期占比等指标判断规则执行效果。
依赖规则先定哪几件事：类型、字段与生效范围
依赖规则的最小规则集由三部分组成：统一的依赖类型、每条依赖必须写清的字段、明确适用的工作项层级。三部分缺一，依赖记录就会退化成口头约定，排期时无法核对，变更时无法追溯。
四类依赖关系的含义与适用场合
依赖类型决定“等什么”。类型不统一，同一组任务在不同人手里会被记成不同关系，排期结果自然对不上。四类关系的含义与常见用法如下：
| 依赖类型 | 含义 | 适用场合 |
|---|---|---|
| 完成—开始（FS） | 前置任务完成后，后置任务才能开始 | 交付型先后关系的主力类型，如接口开发完成后才开始联调 |
| 开始—开始（SS） | 前置任务开始后，后置任务才能开始 | 需要并行推进、同步启动的工作，如文档撰写与评审准备同时启动 |
| 完成—完成（FF） | 前置任务完成后，后置任务才能完成 | 需要同步收尾的工作，如发布说明定稿与版本封版同步完成 |
| 开始—完成（SF） | 前置任务开始后，后置任务才能完成 | 特定交接场景，使用较少，采用时需在依赖记录中注明理由 |
选择类型的默认顺序是：交付物交接用完成—开始；并行启动用开始—开始；同步收尾用完成—完成；开始—完成只在交接逻辑确实如此时使用。类型选错往往表现为排期“看起来能排、执行时处处卡住”，因此类型判断应作为依赖确认的一项内容。
每条依赖必须记录的字段
字段规范的目标是让一条依赖能独立回答“谁等谁、等什么、等多久、谁确认、何时复核”。建议把以下六项设为必填：
- 前置任务：被等待的工作项，需能唯一定位。
- 后置任务：等待方的工作项。
- 依赖类型：四类关系之一。
- 提前/滞后量：前置与后置之间的时间间隔，用明确的时间单位或工作日口径，避免“尽快”“稍后”这类无法核对的表述。
- 责任人：对该条依赖的准确性和及时更新负责的人。
- 确认状态：如待确认、已确认、已失效，用于区分“提出来的依赖”和“双方认可的依赖”。
滞后量需要特别注意口径统一。同一项目内混用自然日和工作日，会让排期在跨周末、跨假期时出现偏差。规则中应写明采用哪种口径，并要求所有依赖记录一致执行。
规则适用的层级与不覆盖的范围
依赖规则适用于可独立交付、可被排期的工作项，例如任务、子任务、跨团队协作事项。规则要求这些工作项之间的先后关系必须显式记录，不能只存在于聊天记录或个人记忆中。
规则不覆盖两类问题：项目整体进度的编排与里程碑管理，由项目进度管理机制负责；人员容量与资源负载冲突，由资源管理机制负责。把这两类问题塞进依赖规则，会让依赖字段承担它无法表达的信息，反而降低规则的可执行性。
从识别到生效：依赖规则的建立步骤
建立依赖规则的过程可以拆成四步，每步都有明确的输入、动作和输出。完成标志是规则发布并被首批工作项实际使用，而不只是文档写完。
第一步：梳理现有工作项与常见先后关系
输入：当前项目或团队的工作项清单、近期排期记录、协作中的口头约定。
动作：按交付物归类工作项，标出哪些任务之间存在真实的先后等待，统计高频出现的依赖场景，例如开发与测试、设计与评审、上游数据与下游分析。
输出：一份常见依赖场景清单，标注每类场景大致对应哪种依赖类型。
完成标志：团队能对“哪些关系算依赖”形成一致判断，清单覆盖主要交付链路。
第二步：确定依赖类型与字段规范
输入：第一步的场景清单、现有工作项字段设置。
动作：为每类场景指定默认依赖类型；确定六项必填字段及填写口径，特别是滞后量的时间单位；明确哪些字段允许在特定情况下留空及留空条件。
输出：依赖规则要素表，包含类型对照、字段说明、填写示例。
完成标志：任意一名任务负责人能依据要素表独立填写一条完整依赖，不需要额外询问。
第三步：约定排期冲突的处理顺序
输入：要素表、历史排期冲突记录。
动作：规定冲突处理的判断顺序——先检查依赖类型或滞后量是否设置不当，再检查前置任务范围是否过大、能否拆分，最后才考虑调整时间；任何时间调整都需记录变更原因与影响范围。
输出：冲突处理顺序说明，附变更记录模板。
完成标志：冲突发生时，处理人知道先查什么、后改什么，调整动作有记录可查。
第四步：规则发布与生效
输入：前三步的全部产出。
动作：向团队说明规则适用范围与生效时间；选取一个在研项目作为首批执行对象；在首次排期会上按新规则逐条核对依赖记录。
输出：已发布规则文档、首批按规则填写的依赖记录。
完成标志：首批工作项的依赖记录字段完整、确认状态明确，排期评审时能直接依据记录讨论，无需回头补信息。
依赖关系需要依附在工作项上，并随任务状态变化保持可核对。ONES 支持在工作项上建立关联关系并记录状态，团队可以把上述字段规范落到具体工作项的关联与属性设置中，使依赖在排期评审时有据可查。具体字段配置方式以实际产品设置为准。
角色分工与各环节交付物
依赖规则能否执行，取决于每个环节是否有人负责、有物可交。以下分工按“提出—确认—维护—变更决策”四个环节划分。
| 角色 | 主要动作 | 交付物 |
|---|---|---|
| 任务负责人 | 识别本任务的前置与后置关系，提出依赖并填写字段；任务范围或时间变化时更新依赖 | 字段完整的依赖记录、变更说明 |
| 协作方（前置交付方） | 确认自己承担的前置交付内容与时间，对不合理的依赖提出异议 | 确认状态更新、异议说明 |
| 项目经理 | 确认跨团队依赖，裁决排期冲突，决定变更是否生效 | 确认结论、冲突处理记录、变更决策 |
| 依赖提出方 | 变更时发起申请，说明原因与影响范围 | 变更申请单 |
职责边界需要写清两点。其一，任务负责人对本任务相关依赖的准确性负责，包括及时取消已不成立的依赖；其二，跨团队依赖的确认权在项目经理，避免双方负责人各执一词导致依赖长期停留在待确认状态。
依赖失效或取消时，由提出方发起取消，项目经理确认，双方负责人同步更新各自任务的排期说明。悬空依赖——指向已取消或不存在任务的依赖——应由任务负责人在例行检查中发现并清理，不能留待排期评审时临时处理。
示例：一条依赖从提出到排期生效
以下为演示情景，用于说明规则如何作用在一条具体依赖上。
某版本中，任务 A“接口开发”计划 3 月 3 日开始、3 月 10 日完成；任务 B“联调测试”原计划 3 月 8 日开始。任务 B 的负责人提出依赖：B 需要等 A 完成才能开始。
按规则填写依赖记录：前置任务为 A，后置任务为 B，依赖类型为完成—开始，滞后量为 1 个工作日（用于预留环境准备时间），责任人为 B 的负责人，确认状态为待确认。协作方即 A 的负责人核对后确认 3 月 10 日完成可行，状态更新为已确认。
排期时出现冲突：按依赖推算，B 最早 3 月 12 日开始，与原计划 3 月 8 日相差四天。处理按约定顺序进行：先检查类型与滞后量，确认完成—开始和 1 个工作日滞后均合理；再检查前置任务范围，发现 A 中包含一项可独立提前完成的配置工作，将其拆出后 A 的完成时间提前至 3 月 7 日；据此 B 调整为 3 月 10 日开始，变更原因与影响范围记入变更记录，双方负责人同步更新排期说明。
这条示例体现了规则的三个作用点：依赖记录让冲突在排期阶段暴露而非执行阶段；处理顺序避免一遇冲突就改时间；变更记录让调整可追溯。
完成检查：规则是否真的被执行
规则发布后需要定期核对执行情况。以下检查项可按周或按排期节点执行，每项都有明确的通过标准。
| 检查项 | 检查方法 | 通过标准 |
|---|---|---|
| 字段完整性 | 抽查在研工作项的依赖记录，核对六项必填字段 | 抽查记录字段齐全，滞后量口径一致 |
| 确认状态 | 统计待确认依赖的数量与停留时长 | 待确认依赖在约定时限内完成确认，无长期挂起 |
| 循环依赖 | 沿依赖链正向追踪，检查是否回到起点 | 不存在 A 等 B、B 等 A 的闭环 |
| 悬空依赖 | 核对依赖指向的任务是否仍存在且未取消 | 无指向已取消或不存在任务的依赖 |
| 变更记录 | 抽查排期调整是否附变更原因与影响范围 | 时间调整均有记录，可追溯到决策人 |
| 执行效果 | 统计因依赖未满足导致的延期占比、依赖确认平均耗时 | 指标呈下降或稳定趋势，异常时可定位到具体依赖 |
检查发现的问题应回到对应环节处理：字段缺失回到填写规范，确认积压回到角色分工，循环与悬空依赖回到日常维护责任。检查结果本身也用于判断规则是否需要修订，例如某类场景频繁出现类型误用，说明类型对照表需要补充示例。
常见问题
依赖类型选错了会有什么表现，怎么纠正？
类型选错的典型表现是排期阶段看起来能排通，执行时却频繁卡住，例如把并行启动的关系记成完成—开始，导致后置任务被不必要地推迟。纠正时先回到依赖记录核对“等的是什么”：等交付物用完成—开始，等同步启动用开始—开始，等同步收尾用完成—完成。若某类场景反复出现误用，应在类型对照表中补充该场景的示例，而不是逐条口头纠正。
滞后量用自然日还是工作日，团队口径不一致怎么办？
两种口径本身都可以，关键是同一项目内统一。口径混用会让排期在跨周末、跨假期时出现偏差。处理办法是在规则中写明采用哪种口径，并在字段说明里给出换算示例；检查时把“滞后量口径一致”列为字段完整性的通过标准之一，发现混用即回到填写规范环节修正。
跨团队依赖长期停留在待确认状态，责任怎么划分？
跨团队依赖的确认权在项目经理，这是避免双方负责人各执一词的关键安排。任务负责人负责提出依赖并保证字段完整，协作方负责确认自己承担的前置交付内容与时间，项目经理负责在约定时限内给出确认结论或裁决。检查时统计待确认依赖的数量与停留时长，长期挂起的依赖应回到角色分工环节处理。
依赖规则和项目进度管理、资源管理如何衔接而不重叠？
依赖规则只处理工作项之间的先后关系，回答谁先做、谁等谁、等多久、变了怎么办。项目整体进度的编排与里程碑管理由项目进度管理机制负责；人员容量与资源负载冲突由资源管理机制负责。衔接方式是在依赖记录中只保留先后关系字段，遇到进度编排或容量冲突时转交对应机制处理，避免让依赖字段承担它无法表达的信息。
规则发布后，怎么判断需要修订而不是继续执行？
检查结果本身就是修订依据。若某类场景频繁出现类型误用，说明类型对照表需要补充示例；若字段缺失集中出现在某几个字段，说明填写口径不够清楚；若确认积压持续存在，说明角色分工或确认时限需要调整。修订应针对具体检查项反映的问题，修订后重新在首批工作项上验证，而不是整体推翻规则。
