任务依赖规则要解决的是“谁等谁、等到什么程度才算完成”。一套可执行的规则通常包含四部分：依赖类型与必填字段、建立与变更的操作步骤、角色分工、上线前的检查标准。本文按这四部分给出可直接套用的定义表、流程清单和验收清单，范围限定在工作项之间的安排关系，项目整体进度与人员容量冲突另行管理。
要点总览（TL;DR）
- 任务依赖规则先回答三个问题：依赖属于强制还是自由、必须记录哪些字段、什么条件下才算成立。
- 最小字段集包括前置任务、后置任务、依赖类型、触发条件、责任人和建立与变更记录，触发条件要写成可观察的状态。
- 依赖的建立、变更与解除都要有输入、动作、输出和完成标志；强制依赖的变更与提前解除需要更高层级确认。
- 提出人、确认人、变更审批人和规则维护人各对应明确交付物，确认人不宜由提出人兼任。
- 上线前用字段完整性、类型一致性、流程责任人、异常处理和阻断项逐条检查，通过后再发布规则。
依赖规则先定哪几件事：类型、字段与判定口径
起草依赖规则时，先回答三个问题：这条依赖属于哪一类、必须记录哪些信息、什么情况下才算成立。把这三项写成条目，规则就有了可执行的基础，后续流程和角色才有判断依据。
强制依赖与自由依赖的区分标准
区分两类依赖，看的是“前置任务未完成时，后置任务能否通过调整方式继续推进”。
- 强制依赖：由交付物本身的技术或业务逻辑决定，前置产出是后置工作的必要输入。例如接口定义未确认，前端联调无法开始；需求评审未通过，开发排期无法确定。这类依赖不能靠沟通绕过，只能等待或调整范围。
- 自由依赖：由团队约定、资源安排或风险偏好形成，前置任务未完成时，后置任务仍可通过替代方案、临时假设或分批推进的方式启动。例如“先等设计稿定稿再开发”属于团队约定的顺序，若设计稿只差非关键页面，开发可以先做已定稿部分。
判定口径可以统一为一句：前置任务未达到触发条件时，后置任务是否存在合规的替代推进方式；不存在则为强制依赖，存在则为自由依赖。分类结果要写进依赖记录，因为它直接决定变更时的审批强度——强制依赖的解除通常需要更高层级确认，自由依赖可由双方负责人协商调整。
每条依赖必须记录的字段
字段设计的目标是让任何人在不看聊天记录的情况下，也能判断这条依赖是否成立、是否已满足、由谁负责。建议的最小字段集如下表。
| 字段 | 填写要求 | 作用 |
|---|---|---|
| 前置任务 | 工作项编号与名称，指向唯一对象 | 明确“等谁” |
| 后置任务 | 工作项编号与名称，指向唯一对象 | 明确“谁在等” |
| 依赖类型 | 强制 / 自由，二选一 | 决定变更审批强度 |
| 触发条件 | 前置任务达到什么状态才算满足，如“评审通过”“提测完成”“文档发布” | 明确“等到什么程度” |
| 责任人 | 提出人、确认人各一名，写姓名而非岗位 | 明确谁对这条依赖负责 |
| 建立时间与变更记录 | 建立日期；每次变更记录时间、原因、影响范围、审批人 | 保留可追溯的过程证据 |
触发条件是最容易被写虚的字段。“前置任务完成”这种写法无法验收，应改成可观察的状态描述，例如“接口文档评审通过并归档”“测试环境部署完成并可访问”。
依赖成立与不成立的判定口径
一条依赖成立，需要同时满足：前置与后置任务都是已登记的工作项；触发条件可观察、可验证；责任人为具体人员；类型划分有依据。缺少任一项，视为记录不完整，不能进入排期依据。
依赖不成立或应解除的典型情形包括：触发条件已被满足；后置任务范围变更导致不再需要该前置产出；前置任务被取消且无替代交付物。这些情形要在规则中写明处理方式，避免依赖长期挂起、失真。
规则覆盖范围只针对工作项之间的安排关系。项目整体里程碑与关键路径的安排归入项目进度管理，人员是否忙得过来、多项目争抢同一角色归入资源负载与冲突管理，两类问题不在本规则内处理，但依赖记录可以作为这两类管理的输入。
建立、变更与解除依赖的操作步骤
规则落到动作上，每一步都要说清输入、做法、输出和完成标志。以下流程适用于单个依赖的全生命周期，团队可按规模裁剪审批层级，但动作本身不宜省略。
建立依赖
- 输入：已登记的前置与后置工作项；对触发条件的初步判断；提出人的判断依据（如交付物清单、技术方案）。
- 做法：提出人填写依赖记录的全部必填字段，标注类型并说明理由；确认人核对触发条件是否可观察、类型划分是否与判定口径一致；双方对触发条件表述达成一致后记录生效。
- 输出：一条字段完整的依赖记录，状态为“已确认”。
- 完成标志：确认人签署或回复确认，记录中不再有空白必填字段。
变更依赖
变更包括调整触发条件、更换前置或后置任务、修改类型。变更时先由提出人写明变更原因和影响范围，例如“前置任务拆分，触发条件改为两个子项均完成”，再按类型走审批：自由依赖由双方负责人确认，强制依赖需增加上一层级的确认。变更完成后更新记录并保留原内容，形成变更历史。
- 输入：原依赖记录；变更原因；受影响的工作项与排期范围。
- 做法：提交变更说明，按类型完成审批，更新字段并追加变更记录。
- 输出：更新后的依赖记录，含变更历史。
- 完成标志：审批人确认，变更记录中时间、原因、影响范围、审批人四项齐全。
解除或关闭依赖
依赖关闭有两种路径：触发条件满足后正常关闭；因范围变更、前置取消等原因提前解除。正常关闭需附满足触发条件的证据，如评审结论、部署记录、交付物链接。提前解除需说明依据，并由原确认人或其上级确认，强制依赖的提前解除应记录对后置任务排期的影响。
- 输入：触发条件满足的证据，或解除依据与影响说明。
- 做法：责任人提交关闭或解除申请，确认人核验证据，更新状态并归档。
- 输出：状态为“已关闭”或“已解除”的记录，附证据或依据。
- 完成标志：证据可被第三方查看，状态与后置任务的实际安排一致。
当依赖记录需要随工作项一起流转时，可以在 ONES 的工作项中建立关联并记录依赖字段，让前置任务的状态变化与后置任务的排期判断在同一处查看，减少依赖信息散落在聊天记录里的情况。
谁负责哪一环：角色分工与交付物
规则无人执行，通常是因为角色不清。依赖管理至少涉及四类角色，每类角色对应明确产出，避免“大家都觉得对方在跟”。
| 角色 | 职责 | 交付物 |
|---|---|---|
| 提出人 | 识别依赖、填写记录、说明类型理由与触发条件 | 字段完整的依赖记录 |
| 确认人 | 核对触发条件可观察性、类型划分一致性，确认依赖成立 | 确认意见与签署记录 |
| 变更审批人 | 按依赖类型审批变更与提前解除，评估对排期的影响 | 审批记录，含原因与影响范围 |
| 规则维护人 | 维护字段定义与判定口径，定期复核依赖记录质量，处理争议 | 规则文档版本、复核报告、争议处理结论 |
提出人与确认人可以是同一团队的两人，也可以是跨团队对接人，但不应由同一人兼任，否则类型划分和触发条件失去校验。规则维护人建议由项目管理或研发管理角色承担，按固定周期（如每两周或每个迭代结束）抽查依赖记录的字段完整性和关闭证据，把遗漏依赖和长期挂起的依赖列入复核报告。
一个完整示例：从提出依赖到关闭
以下为演示情景，用于说明字段填写与状态流转，不代表真实项目数据。
场景：某产品迭代中，后端任务“订单查询接口开发”与前端任务“订单列表页开发”存在依赖，前端需要接口定义确认后才能联调。
依赖记录填写：前置任务为“订单查询接口开发”，后置任务为“订单列表页开发”；类型为强制依赖，理由是接口字段未定则联调无法进行且无替代方案；触发条件写为“接口文档评审通过并归档，字段清单可访问”；提出人为前端负责人，确认人为后端负责人；建立日期记录在案。
状态流转：记录建立后状态为“已确认”；开发过程中接口字段调整，提出人提交变更，将触发条件细化为“接口文档评审通过且变更后的字段清单同步至前端”，经双方负责人确认后更新记录；接口文档评审通过并归档后，提出人附评审结论链接申请关闭，确认人核验后状态改为“已关闭”。
关闭证据：评审结论记录、归档文档链接、确认人核验意见。三者齐全，后置任务的联调排期才有依据。
规则上线前的完成检查
规则是否可用，靠逐项核对而不是靠感觉。以下清单建议在规则发布前由规则维护人组织一次检查，全部通过再上线。
- 字段完整性：随机抽取若干条依赖记录，检查前置任务、后置任务、类型、触发条件、责任人、时间与变更记录是否齐全；触发条件是否写成可观察状态。
- 类型划分一致性：同一类场景由不同人判断，类型结论是否一致；强制依赖是否都有明确的“无替代推进方式”理由。
- 流程动作与责任人：建立、变更、解除三个动作是否都有对应责任人和完成标志；审批层级是否与依赖类型匹配；是否存在无人确认即可生效的路径。
- 异常与遗漏处理：规则是否说明依赖不成立、前置取消、长期挂起时的处理方式；是否有定期复核机制发现遗漏依赖。
- 通过标准与阻断项：字段缺失、触发条件不可观察、强制依赖无审批记录属于阻断项，须整改后复检；复核周期未定、争议处理人未指定属于改进项，可限期补齐。
检查通过后，规则文档应包含类型定义表、字段表、操作步骤、角色表和本清单，作为后续复核的基准版本。规则运行一段时间后，用复核报告中的遗漏依赖数量和变更频率判断规则是否需要调整，而不是等到排期冲突集中爆发再回头补。
常见问题
强制依赖和自由依赖判断不一致时怎么处理？
先回到判定口径：前置任务未达到触发条件时，后置任务是否存在合规的替代推进方式。双方各自写出判断依据，由规则维护人组织一次简短复核，结论记入依赖记录并作为同类场景的参照。若争议反复出现，说明判定口径需要补充示例，应更新规则文档而不是逐条临时裁决。
前置任务被取消，后置任务的依赖怎么关闭？
按提前解除处理：提出人说明前置取消的依据、后置任务是否仍有替代输入、对排期的影响范围，由原确认人或其上级确认。强制依赖的提前解除要额外记录后置任务的排期调整结论。若后置任务因此不再需要该前置产出，直接解除；若仍需类似输入，应新建一条指向替代工作项的依赖，避免在原记录上反复修改。
依赖记录建立后长期没有关闭，规则里怎么约束？
在规则中设定复核周期，由规则维护人定期抽查处于“已确认”状态的依赖，核对触发条件是否已满足、后置任务是否仍在推进。对超期未关闭的记录，要求责任人给出说明：条件已满足则补证据关闭，条件不再适用则走提前解除。复核报告记录超期数量和原因，作为调整规则或排期的输入。
团队规模较小，角色能否合并？
可以合并部分角色，但提出人与确认人建议保持分离，否则类型划分和触发条件缺少校验。变更审批人可由确认人兼任，规则维护人可由项目管理角色兼任。合并后要在规则文档中写明谁承担哪项职责、对应什么交付物，避免出现无人复核的情况。
依赖规则和项目进度管理如何衔接？
依赖规则只处理工作项之间的等待关系，产出是字段完整、状态可查的依赖记录。项目进度管理把这些记录作为排期输入，用于判断关键路径和里程碑风险。两者衔接点在依赖记录的触发条件和关闭证据：进度管理读取这些信息，但不改变依赖本身的判定口径。人员容量冲突同样以依赖记录为输入，归入资源负载管理处理。
