任务依赖规则要解决四个具体问题：什么情况算依赖、依赖怎么记录、谁能建立和变更依赖、依赖如何影响排期与状态。把这四项写成可执行的字段、权限和动作，团队才能在排期时对依赖有统一判断。本文聚焦工作项层面的依赖安排，项目整体里程碑编制与人员负载分配不在讨论范围内。
要点总览（TL;DR）
- 依赖判定只认一条口径：前置任务的产出是否为后置任务开展工作的必要输入；时间相近、同一负责人、同一模块但无输入输出关系的情形不登记为依赖。
- 依赖类型同时标注时序关系（完成到开始、开始到开始、完成到完成）与强度（强依赖、软依赖），强依赖硬约束排期，软依赖只作提醒。
- 依赖登记至少包含前置任务、后置任务、依赖类型、依赖内容、期望满足时间、责任人六项字段，用统一标识和固定位置记录，保证可查询。
- 建立依赖由后置任务负责人发起、前置任务负责人确认；延期、取消、替换前置任务都要留痕并告知受影响方，跨团队依赖设固定对接人与升级时限。
- 规则落地后按月抽查字段完整性、类型使用、变更留痕、阻塞关闭与排期一致性，出现反复误判或长期阻塞时修订规则条款。
先定依赖判定标准：什么算依赖、分哪几类
依赖判定的核心口径只有一条：前置任务的产出是否为后置任务开展工作的必要输入。如果后置任务在缺少该产出时无法开始、无法完成或只能返工，就构成依赖；如果两者只是时间接近、由同一人负责或属于同一模块，但没有输入输出关系，就不登记为依赖。这条口径需要在规则中写明，并配一两个团队内的正反例，避免成员凭感觉登记。
判定之后要分类。分类有两个维度，建议同时使用：时序关系和依赖强度。
| 维度 | 类型 | 含义 | 排期处理 |
|---|---|---|---|
| 时序关系 | 完成到开始（FS） | 前置任务完成后，后置任务才能开始 | 后置任务开始时间不早于前置完成时间 |
| 时序关系 | 开始到开始（SS） | 前置任务开始后，后置任务才能开始 | 约束后置任务的启动时点，允许并行推进 |
| 时序关系 | 完成到完成（FF） | 后置任务完成需等待前置任务完成 | 约束后置任务的收尾时点 |
| 依赖强度 | 强依赖 | 缺少前置产出则后置任务无法交付 | 作为硬约束写入排期，前置延期必须触发后置调整 |
| 依赖强度 | 软依赖 | 前置产出影响质量或效率，但可通过替代方案推进 | 作为提醒跟踪，不强制锁死后置开始时间 |
需要明确排除的情形包括：两个任务排在同一周但互不消费对方产出；同一负责人承接的多项任务；同一模块下并行开发、接口尚未约定的任务。这些情形登记为依赖会虚增阻塞数量，让真正的依赖淹没在噪音里。规则中可以规定，登记依赖时必须能说清“后置任务消费前置任务的哪项具体产出”，说不清的不予登记。
依赖规则的字段与登记方式
依赖要能被查询和追踪，就必须从口头约定变成结构化记录。建议规定以下必填字段，缺一不可：
| 字段 | 填写要求 | 示例 |
|---|---|---|
| 依赖标识 | 统一前缀加序号，全局唯一 | DEP-0142 |
| 前置任务 | 填写任务唯一编号与名称 | REQ-231 支付接口联调完成 |
| 后置任务 | 填写任务唯一编号与名称 | REQ-245 订单结算页验收 |
| 依赖类型 | 时序关系加依赖强度，两项都填 | 完成到开始，强依赖 |
| 依赖内容 | 后置任务具体消费的产出物 | 联调通过的接口文档与测试环境 |
| 期望满足时间 | 前置产出最晚可用日期 | 3月18日 |
| 责任人 | 前置任务负责人与后置任务负责人各一名 | 前置：张工；后置：李工 |
| 状态 | 待满足、已满足、已阻塞、已解除 | 待满足 |
登记位置要统一。可以在后置任务的工作项关联中建立依赖链接，同时在任务描述里保留一行摘要，写明依赖标识、前置任务编号和期望满足时间，方便不打开关联面板的人快速看到。命名约定建议采用“DEP-序号”格式，与任务编号体系区分开，避免与需求号、缺陷号混用。依赖方向以后置任务为视角书写，即“本任务依赖某任务”，不写反向表述，减少阅读歧义。
当团队使用工作项管理工具承载任务时，依赖登记可以直接落在工作项关联上。例如在 ONES 工作项管理中，可以将后置任务与前置任务建立关联，把依赖类型和期望满足时间记录在任务信息里，使依赖随任务一起被查询和跟踪。工具承载的是记录与查询动作，字段口径和填写规范仍需团队在规则中自行定义。
建立、变更与解除依赖的权限和流程
依赖的建立由后置任务负责人发起，因为后置方最清楚自己需要什么输入；前置任务负责人确认，确认的内容是产出物范围与可满足时间。双方确认后依赖生效，状态置为待满足。规则中应写明：未经前置方确认的依赖只能标记为待确认，不能作为排期依据。
变更分三种情形，处理路径不同：
- 延期：前置任务预计无法在期望满足时间交付时，前置负责人应在发现当天更新期望满足时间并说明原因，后置负责人确认后调整自身排期；影响交付里程碑的，同步给项目负责人。
- 取消：后置任务不再需要该产出，或改用其他输入时，由后置负责人发起解除，注明替代方案，前置负责人确认后关闭依赖。
- 替换前置任务：产出改由另一任务提供时，先建立新依赖并确认，再解除旧依赖，保证任一时刻依赖链不断档。
跨团队依赖需要固定对接人。建议每个团队指定一名依赖对接人，负责本团队对外依赖的登记确认与进度同步；当双方对可满足时间无法达成一致时，升级路径为：双方对接人协商，协商不成提交项目负责人裁决，裁决结果记录在依赖条目中。升级时限也要写清楚，例如两个工作日内未达成一致即触发升级，避免依赖长期悬空。
依赖如何联动排期与状态
强依赖对排期是硬约束：后置任务的计划开始时间不得早于前置任务的计划完成时间，前置任务延期时，后置任务的开始时间随之顺延，并在排期表中体现调整记录。软依赖只作为提醒，后置任务可以按原计划启动，但需在任务中注明所依赖的产出尚未就绪及应对方式。开始到开始类依赖约束的是启动时点，后置任务可以在前置开始后并行推进，但不得提前启动。
状态处理要明确：前置任务未完成时，后置任务保持未开始；如果后置任务已排入当前迭代但无法启动，标记为阻塞，而不是置为进行中。阻塞状态需要附带阻塞原因和依赖标识，便于汇总统计。前置任务完成后，由前置负责人将依赖状态更新为已满足，后置负责人确认收到产出后再启动任务，形成交接闭环。
跟踪节奏建议固定：每日站会查看当日到期和已阻塞的依赖，每周例会上汇总本周新增、解除和逾期未满足的依赖数量。阻塞超过约定天数（例如三个工作日）未推进的依赖，自动进入升级清单。在 ONES 工作项管理中，阻塞任务可以通过状态标记和筛选视图集中呈现，配合迭代视图查看依赖对排期的实际影响，让跟踪动作有固定的查看入口。
示例：一条跨团队依赖从登记到关闭
以下为演示情景。背景：产品团队负责订单结算页改版（任务 REQ-245），需要支付团队完成接口联调（任务 REQ-231）并提供联调通过的接口文档与测试环境。角色包括：后置任务负责人李工（产品团队）、前置任务负责人张工（支付团队）、双方团队依赖对接人、项目负责人。
登记过程：李工在 REQ-245 下发起依赖，填写依赖标识 DEP-0142，前置任务 REQ-231，依赖类型为完成到开始、强依赖，依赖内容为联调通过的接口文档与测试环境，期望满足时间3月18日，责任人分别为张工和李工，状态待确认。张工确认产出范围与时间后，状态改为待满足，李工据此将 REQ-245 的计划开始时间排在3月19日。
阻塞处理：3月16日张工发现联调环境准备延迟，预计3月21日才能交付。张工当天更新期望满足时间为3月21日并注明原因，李工确认后将 REQ-245 开始时间顺延至3月22日，同时把 REQ-245 标记为阻塞并关联 DEP-0142。由于顺延影响版本发布节点，双方对接人将情况提交项目负责人，裁决结果为压缩验收周期两天，裁决记录写入依赖条目。3月21日张工交付产出，依赖状态改为已满足；李工确认收到文档与环境后启动 REQ-245，阻塞标记解除。任务验收通过后，DEP-0142 关闭并保留完整变更记录。
规则落地后的完成检查
规则是否真正运行，可以按以下清单逐项核对，建议每月抽查一次：
- 字段完整性：抽查的依赖条目中，前置任务、后置任务、依赖类型、依赖内容、期望满足时间、责任人六项是否全部填写，缺失率是否为零。
- 类型使用正确性：抽查强依赖条目，确认后置任务确实无法在缺少前置产出时交付；抽查被排除情形是否仍被误登记为依赖。
- 变更留痕：延期、取消、替换前置任务的依赖是否都有变更记录、原因说明和受影响方确认。
- 阻塞跟踪与关闭：统计阻塞依赖的平均持续天数，确认超过约定天数的依赖是否都进入升级清单并得到处理，已满足的依赖是否及时关闭。
- 排期一致性：对比依赖约束与任务实际计划时间，确认强依赖没有被排期绕过。
规则本身也需要修订触发条件。出现以下情况时应启动复盘：同一类依赖反复被误判，说明判定口径需要补充示例；阻塞依赖数量持续上升或平均持续时间明显变长，说明确认与升级环节失效；依赖变更频繁且无记录，说明权限与流程未被遵守。复盘输出应落到规则文本的具体条款修改，而不是停留在提醒层面。规则修订后同步更新字段表和检查清单，保证三者一致。
常见问题
两个任务由同一个人负责，是否应该登记为依赖？
通常不登记。依赖的判定标准是前置任务的产出是否为后置任务的必要输入，负责人相同只说明排期需要协调，不构成输入输出关系。把同一负责人的任务都登记为依赖，会让阻塞数量虚增，真正的依赖反而不容易被看到。如果确实存在产出交接，例如同一人先完成接口设计再进入编码，则按产出关系登记，并在依赖内容中写清消费的具体产出物。
软依赖在排期时要不要锁死后置任务的开始时间？
不需要锁死。软依赖表示前置产出影响质量或效率，但后置任务可以通过替代方案推进，因此只作为提醒跟踪。规则中可以要求后置负责人在任务中注明所依赖的产出尚未就绪及应对方式，例如先用模拟数据开发、后续再联调。当前置产出实际无法按时提供且没有替代方案时，应把该依赖调整为强依赖，再按硬约束顺延排期，避免软依赖长期掩盖真实风险。
跨团队依赖双方对可满足时间谈不拢，怎么处理？
按预设的升级路径处理：先由双方团队的依赖对接人协商，协商不成提交项目负责人裁决，裁决结果记录在依赖条目中。规则里要写明升级时限，例如两个工作日内未达成一致即触发升级，避免依赖长期悬空。裁决后由后置负责人据此调整排期，前置负责人按裁决时间交付，双方在依赖条目中确认，后续变更仍走同一路径。
前置任务延期后，后置任务应该保持未开始还是标记为进行中？
前置任务未完成时，后置任务保持未开始；如果后置任务已排入当前迭代但无法启动，标记为阻塞，并附上阻塞原因和依赖标识。置为进行中会让进度统计失真，也无法区分“在做”和“在等”。前置任务完成后，由前置负责人把依赖状态更新为已满足，后置负责人确认收到产出后再启动任务，形成交接闭环。
规则执行一段时间后，什么情况下需要修订依赖规则本身？
出现三类信号时启动复盘：同一类依赖反复被误判，说明判定口径需要补充正反例；阻塞依赖数量持续上升或平均持续时间明显变长，说明确认与升级环节失效；依赖变更频繁且没有记录，说明权限与流程未被遵守。复盘输出应落到规则文本的具体条款修改，并同步更新字段表和检查清单，保证三者一致，避免规则与实际执行脱节。
