任务依赖规则如何制定：从判定到落地的操作指南

制定任务依赖规则，核心是把“谁等谁、等到什么程度、由谁确认”写成可执行的字段：依赖类型、前置项与后置项、触发条件、责任人与确认方式、例外与延期处置。本文围绕工作项之间的先后约束展开，说明适用范围、字段结构、制定步骤、角色分工，并给出一条可直接照填的示例和落地检查清单；项目整体里程碑排布与人员容量调配不在本文范围内。

要点总览（TL;DR）

• 依赖规则要写清五个字段：依赖类型、前置项与后置项、触发条件、责任人与确认方式、例外与延期处置，让每条依赖都能被第三方核验。
• 先划定边界：只对存在交付物交接、跨角色承接的工作项建依赖；可并行、仅资源占用、无实质交接的情形通过排期或资源协调处理。
• 制定按五步推进：梳理交接点形成场景清单、定义字段并配示例、规定录入时点与责任人、建立评审与变更流程、小范围试点后推广。
• 角色分工要落到唯一责任人：后置项负责人提出并维护依赖，前置项负责人确认触发条件并给出证据，排期负责人评审合理性与裁决例外。
• 落地校验看五项：字段完整性、无意义与循环依赖、触发条件可验证、例外与延期有记录、复核节奏被执行，检查结果反馈到规则本身。

先定边界：哪些工作项之间才需要建依赖

依赖规则管的是工作项之间的先后约束：一个工作项的产出构成另一个工作项的输入，后者的启动或完成需要等前者达到某个状态。项目整体里程碑怎么排、阶段之间如何划分，属于进度规划；某个人同时被几个任务占用、要不要调整人手，属于资源调配。这两类问题即使表现为“事情卡住了”，也不应通过增加依赖记录来解决，否则依赖关系会变成一张无法维护的网。

划定边界的第一步是确定纳入依赖管理的工作项层级。层级过粗，依赖会停留在“需求阶段等设计阶段”这种无法确认的描述上；层级过细，又会把同一人连续完成的几个动作拆成互相等待的链条。常见做法是选择有明确交付物、由不同角色承接的层级，例如需求、开发任务、测试任务、发布项。团队可以只对跨角色交接的工作项建依赖，同一角色内部的连续工作通过排序解决。

以下情形通常不建依赖：两项工作可以并行推进，互不构成输入；双方没有实质交付物交接，只是时间上前后相邻；一方对另一方只是资源占用，例如共用一台设备或一名评审人。把这些情形排除后，依赖记录才对应真实的交接关系。

判定问题	纳入依赖管理	不纳入依赖管理
是否存在交付物交接	前置项产出文档、代码、环境、评审结论等，后置项需要据此开始	双方各自完成，无输入输出关系
工作项层级	需求、开发任务、测试任务、发布项等有明确交付物的层级	阶段名称、项目整体里程碑
等待原因	后置项因前置项未达到约定状态而无法开始或完成	仅因人员、设备被占用而排队
可并行性	存在真实先后约束	可以同时推进，只是习惯上排了先后

这张清单的用途是让团队在录入依赖前先做一次判定：符合“纳入”列的情形才建依赖，其余情形通过排期或资源协调处理。判定口径确定后，再进入字段设计。

核心答案：依赖规则要写清的五个字段

依赖规则的可执行性取决于字段是否具体。一条依赖记录至少要回答五个问题：是什么类型的等待、等的是哪个工作项、等到什么状态才算解除、谁确认、出现延期怎么办。字段设计应围绕这五个问题展开，并规定哪些必填、取值如何统一。

依赖类型

常用四类依赖类型，选择依据是前置项与后置项之间实际交接的状态：

• 完成—开始：前置项完成后，后置项才能开始。适用于开发完成才能提测、需求评审通过才能进入开发等场景，是最常用的一类。
• 开始—开始：前置项启动后，后置项才能启动。适用于需要同步开展、但后置项不能早于前置项启动的工作，例如环境搭建启动后联调才能开始。
• 完成—完成：前置项完成后，后置项才能完成。适用于收尾阶段相互约束的工作，例如发布说明完成才能关闭发布项。
• 开始—完成：前置项启动后，后置项才能完成。使用频率较低，适用于旧版本下线等需要以新工作启动为前提的收尾事项。

类型选择应以交付物交接的实际形态为准，避免所有依赖一律写成完成—开始，导致本可并行的工作被人为串行。

前置项与后置项

两端都应指向具体工作项编号或唯一标识，并写明标题，便于核对。写成“设计阶段”“测试环节”这类阶段名称，无法判断具体等的是哪份产出，也无法在延期时找到责任人。

触发条件

触发条件说明前置项达到什么状态才解除约束。常见取值包括：工作项状态为已完成、评审结论为通过、交付物已归档到约定位置、接口已联调通过。触发条件应当可以被第三方核验，避免使用“基本完成”“差不多可用”这类无法判定的描述。同一依赖类型下，触发条件可以进一步细分，例如完成—开始可以要求“开发完成且自测通过”，而不仅是状态变为完成。

责任人与确认方式

需要明确两个角色：前置项负责人负责在触发条件达成时给出确认和完成证据；后置项负责人负责接收并启动后续工作。确认方式可以是状态变更、评审记录、交付物链接或书面确认，规则中应指定其中一种作为默认方式，避免依赖解除靠口头通知。

例外与延期处置

规则要预先写明前置项延期时后置项如何处理：是保持等待并更新预计时间，还是允许有条件启动，还是升级给排期负责人裁决。同时明确谁有权调整依赖类型、删除依赖或变更触发条件。例外记录应保留原因和决策人，便于后续复核。

字段名	取值示例	必填性	填写说明
依赖类型	完成—开始、开始—开始、完成—完成、开始—完成	必填	按交付物交接形态选择，默认完成—开始
前置项	工作项编号与标题	必填	指向具体工作项，不写阶段名称
后置项	工作项编号与标题	必填	指向具体工作项
触发条件	状态为已完成且自测通过；评审结论为通过	必填	可被第三方核验，避免模糊描述
前置确认人	前置项负责人	必填	负责给出完成证据
后置接收人	后置项负责人	必填	负责接收并启动后续工作
确认方式	状态变更、评审记录、交付物链接、书面确认	必填	指定一种默认方式
例外处置	保持等待并更新预计时间；升级排期负责人裁决	选填，延期时必填	记录原因与决策人

字段表确定后，规则文档应附一到两个填写示例，说明每个字段在真实场景中怎么写。字段与示例一起发布，才能减少执行时的理解偏差。

操作步骤：从起草到生效的五步

规则制定可以按五个步骤推进，每一步都有明确的输入、动作、输出和完成标志，避免规则停留在讨论层面。

第一步：梳理交接点，形成依赖场景清单

输入是现有工作项类型和近几个周期的实际流转记录。动作是找出跨角色、跨工作项类型的常见交接点，例如需求到开发、开发到测试、测试到发布，并记录每次交接的交付物和等待状态。输出是一份依赖场景清单，列出场景名称、前置项类型、后置项类型和交接物。完成标志是清单覆盖团队主要交接路径，且每个场景都能对应到具体工作项类型。

第二步：确定依赖类型与字段，写成规则文档

输入是场景清单。动作是逐场景选择依赖类型，确定触发条件、确认方式和例外处置，并配一条填写示例。输出是规则文档，包含字段表、类型说明和示例。完成标志是团队内任意成员能依据文档独立填写一条依赖记录，且不需要额外解释。

第三步：规定录入时点与录入责任人

输入是规则文档。动作是明确依赖在什么时点录入：创建后置项时、排期评审时，还是两者都允许；同时指定由谁录入，通常由后置项负责人在提出排期需求时录入，前置项负责人确认。输出是录入要求说明。完成标志是抽查一批新建工作项，依赖记录在约定时点前完成录入的比例达到团队约定水平。

第四步：建立评审与变更流程

输入是已录入的依赖记录。动作是规定评审节点，例如排期会上集中检查依赖是否合理、是否存在循环；明确调整权限，谁可以修改类型、触发条件或删除依赖；规定延期时的升级路径。输出是评审与变更流程说明。完成标志是每次排期评审都有依赖检查环节，变更留有记录。

第五步：小范围试点并校验，再推广

输入是规则文档和流程说明。动作是选择一个团队或一条业务线试点一到两个周期，收集填写困难、触发条件争议和例外处理问题，据此修订字段和说明。输出是试点结论和修订后的规则版本。完成标志是试点范围内依赖记录可被独立核验，且团队反馈的主要歧义已在规则中澄清，之后进入推广。

角色与交付物：谁建、谁确认、谁维护

依赖规则能否运行，取决于每个动作是否有明确承担者。以下分工可作为起点，团队可按规模调整，但每类动作都应有唯一责任人。

角色	主要动作	交付物
后置项负责人（任务负责人）	提出依赖需求，填写依赖类型、触发条件和期望时间；依赖变化时及时更新	依赖记录、变更说明
前置项负责人	按触发条件确认完成，提供交付物或评审结论作为证据	完成确认、交付物链接或评审记录
排期负责人或项目经理	评审依赖合理性，识别循环依赖和无意义依赖，裁决冲突与例外	评审结论、例外决策记录
团队	按约定节奏复核依赖，清理已失效或已完成的依赖	复核记录、清理结果

团队约定部分需要写清复核节奏，例如每个排期周期检查一次跨团队依赖，每个迭代结束时清理已完成依赖。复核的对象是依赖记录本身：触发条件是否仍然成立、前置项是否已变更、后置项是否已取消。没有复核机制，依赖记录会逐渐失真，后续排期依据也会失效。

当依赖记录需要与工作项状态联动时，可以在工作项管理中承载这些字段：后置项负责人录入依赖并关联前置工作项，前置项负责人通过状态变更或评审记录确认触发条件，排期负责人在评审中查看依赖分布并处理例外。ONES 的工作项管理可用于组织这类工作项、状态与关联关系，具体字段配置和依赖关系设置方式以团队实际使用的产品版本为准。

示例：一条开发到测试的依赖如何写

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

背景：某需求拆分为开发任务 DEV-102 和测试任务 TEST-215，测试需要在开发完成并自测通过后开始。

字段	填写内容
依赖类型	完成—开始
前置项	DEV-102 订单查询接口开发
后置项	TEST-215 订单查询接口测试
触发条件	DEV-102 状态为已完成，且自测记录已附在任务中
前置确认人	DEV-102 负责人
后置接收人	TEST-215 负责人
确认方式	状态变更并在任务中附自测记录
例外处置	DEV-102 延期超过一个工作日时，TEST-215 标记为等待并更新预计开始时间；是否调整测试范围由排期负责人裁决

流转过程：DEV-102 负责人完成开发并提交自测记录，将状态改为已完成，触发条件达成；TEST-215 负责人核对自测记录后启动测试，依赖解除。若 DEV-102 延期，TEST-215 保持等待状态并记录新的预计时间，排期负责人在评审中决定是否先安排其他测试任务或调整范围。

从这个示例可以迁移出几条填写规律：触发条件要绑定可核验的证据，而不仅是状态名称；确认方式要与证据形式一致；例外处置要写明触发延期的判断标准和决策人。其他类型的依赖可以按同样结构填写，只替换类型和触发条件。

完成检查：规则是否真的可执行

规则发布后，需要用一组可核对的检查项判断它是否落地。以下清单可按周期执行，每项给出通过标准。

检查项	检查方法	通过标准
字段完整性	抽查一批依赖记录，核对必填字段	必填字段无空缺，依赖类型取值在约定范围内
依赖合理性	检查是否存在无意义依赖和循环依赖	无相互等待的循环；无交付物交接的依赖已清理
触发条件可验证	随机抽取依赖，核对前置完成证据	每条依赖解除时都有可查证的记录或交付物
例外与延期记录	查看延期依赖的处理记录	例外有原因说明和决策人，后置项状态已更新
复核节奏执行	核对复核记录的时间与范围	按约定周期完成复核，失效依赖已清理

检查结果应反馈到规则本身：如果某类字段反复填写错误，说明说明文字或示例需要补充；如果循环依赖频繁出现，说明依赖录入时点或评审环节需要前移。规则经过一到两轮检查和修订后，再扩大适用范围，执行成本会更可控。

常见问题

前置项负责人认为工作“基本完成”，后置项负责人认为还不能开始，这种分歧怎么处理？

这类分歧通常源于触发条件写得模糊。处理方式分两步：先按规则中约定的触发条件逐项核对，例如状态是否为已完成、自测记录是否已附、评审结论是否已出，用可查证的证据代替主观判断；如果规则本身没有写清，由排期负责人在当次评审中裁定，并把裁定结果补充进规则文档的示例或说明。反复出现同类争议时，说明触发条件需要细化，例如把“开发完成”改为“开发完成且自测通过并附记录”。

团队规模较小、角色由同一人兼任时，依赖规则还需要保留全部字段吗？

字段可以精简，但关键信息不能省。小团队中同一人可能既是前置项负责人又是后置项负责人，此时“前置确认人”和“后置接收人”可以合并填写，但依赖类型、前置项、后置项和触发条件仍应保留，因为它们决定了工作项之间的先后关系是否成立。例外与延期处置可以简化为一句约定，例如“延期时由本人在排期会上说明并更新预计时间”。精简的前提是团队能独立核对每条依赖，而不是靠记忆维持先后顺序。

依赖关系建好之后，前置项范围变了或者后置项被取消，旧依赖怎么处理？

依赖记录需要跟随工作项变化同步维护。前置项范围调整时，由前置项负责人判断原触发条件是否仍然适用，不适用则通知后置项负责人更新触发条件或调整依赖类型；后置项被取消时，由后置项负责人删除对应依赖并说明原因。团队按约定节奏复核依赖，重点检查触发条件是否仍成立、前置项是否已变更、后置项是否已取消。没有清理机制的依赖记录会逐渐失真，后续排期依据也会失效。

试点阶段应该选什么样的团队或业务线，试点多久比较合适？

试点对象优先选择交接点清晰、跨角色协作较多的一条业务线或一个团队，这样能较快暴露字段填写和触发条件上的歧义。试点周期通常覆盖一到两个完整的排期周期，确保经历一次从录入、评审到延期处置的完整流程。试点期间重点收集三类问题：哪些字段填写困难、哪些触发条件产生争议、例外处理是否有人裁决。试点结束以“依赖记录可被独立核验、主要歧义已在规则中澄清”为完成标志，再扩大适用范围。

依赖规则和项目整体进度计划是什么关系，会不会重复管理？

两者管理对象不同。依赖规则管的是具体工作项之间的先后约束，回答“谁等谁、等到什么程度”；项目整体进度计划管的是里程碑排布、阶段划分和整体时间线。依赖记录可以作为排期时的输入，帮助判断某项工作能否按计划启动，但里程碑调整、阶段划分仍按进度管理的方式处理。把两者混在一起，容易出现用依赖记录代替进度规划，或者把阶段名称写成前置项导致无法确认的情况。人员容量冲突同样不通过依赖规则解决，应走资源协调。