制定任务依赖规则，核心是回答四个问题：什么情况算依赖、依赖怎么分类记录、由谁在什么时点登记与变更、排期时如何检查。规则最终要落成一份依赖登记表和一套评审动作，让依赖从口头约定变成可追踪、可验证的工作项关系。本文聚焦工作项层面的依赖安排，项目整体进度与人员容量问题不在规则范围内。
要点总览（TL;DR）
- 依赖判定写成一句可复述的规则：前置项的交付物、决策结论或环境资源是后置项开工的必要条件；信息同步、同一负责人、同迭代无交接不登记为依赖。
- 类型以完成—开始为主，开始—开始与完成—完成只在确有并行或同步要求时使用；方向统一为前置指向后置，一条依赖只登记一次；强度区分强制与可选，滞后与提前单独记录。
- 依赖在计划会、需求评审、迭代启动前三个时点识别，登记字段固定为前置项、后置项、类型、强度、依据、责任人、登记时间与状态，变更与解除留痕。
- 排期按依赖链逐段核对前置完成时间是否支撑后置开始；冲突按调整顺序、拆分工作项、升级协调依次处置，项目整体进度与人员容量问题另行处理。
- 规则落地用完成检查清单验收，判定口径无法复述、登记字段缺失、存在双向重复登记属于阻断项，须先修正再推进。
先定判定口径：哪些工作项之间才算存在依赖
依赖判定口径决定规则的边界。口径过宽，登记表会被大量弱关联填满，排期检查失去信号；口径过窄，真正的等待关系被漏掉，延期往往在交付前才暴露。建议把判定标准写成一句可复述的规则：当前置工作项的交付物、决策结论或环境资源，是后置工作项开始或完成的必要条件时，两者之间存在依赖。
这条规则对应三类典型情形：
- 交付物输入：后置项需要前置项产出的文档、设计稿、接口、数据或组件才能开工。例如接口文档定稿是联调任务的前置条件。
- 决策前置：后置项的执行范围取决于某个评审或审批结论。例如方案评审通过后，开发任务才能按最终方案排期。
- 环境或资源就绪：后置项依赖测试环境、账号权限、第三方接入等外部条件到位。
以下情形应明确排除：仅需要信息同步、双方需要沟通对齐、由同一负责人执行、处于同一迭代但无交付物交接。这些属于协作事项，用沟通机制解决，登记为依赖只会增加台账噪音。判定时可以配反例自查：如果前置项延期一天，后置项是否真的无法推进？答案是否定的，就不构成依赖。
依赖类型、方向与强度的规则设计
判定之后要解决怎么记录。类型、方向、强度三个维度定义清楚，登记表才能被不同角色一致理解。
类型以完成—开始为主。前置项完成后，后置项才能开始，这是绝大多数交付关系的形态。开始—开始适用于两项工作必须同步启动的场景，例如联调与压测环境同步搭建；完成—完成适用于两项工作须同时收尾的场景，例如功能开发与配套文档同步完成。后两类只在确有并行或同步要求时使用，滥用会让排期计算复杂化。
方向统一为前置项指向后置项。一条依赖只登记一次，禁止双方各自登记形成双向重复。登记时明确写出“A 完成支撑 B 开始”，避免只写“A 与 B 有关联”这类无法判断方向的描述。
强度区分强制与可选。强制依赖影响排期承诺，前置项未完成时后置项不得进入执行；可选依赖只作提醒，排期检查时提示风险但不阻断。两者混记，会导致排期评审无法区分真正的卡点。
滞后与提前单独记录。前置项完成后需要等待一段时间后置项才能开始，记录为滞后时间；后置项可以在前置项完成前提前启动一部分，记录为提前量。两者都写在依赖条目上，不并入工作项工期，避免排期口径混乱。
| 维度 | 取值 | 使用条件 | 对排期的影响 |
|---|---|---|---|
| 类型 | 完成—开始 | 默认形态，前置交付物是后置开工条件 | 前置完成时间决定后置最早开始时间 |
| 类型 | 开始—开始 | 两项工作须同步启动 | 两者开始时间需对齐 |
| 类型 | 完成—完成 | 两项工作须同时收尾 | 两者完成时间需对齐 |
| 强度 | 强制 | 缺失则后置项无法执行 | 阻断排期承诺 |
| 强度 | 可选 | 缺失会增加风险但可推进 | 仅提示，不阻断 |
| 时间偏移 | 滞后 / 提前 | 存在等待期或可提前启动部分工作 | 单独记录，不并入工期 |
建立、变更与解除依赖的操作步骤
依赖规则要落到固定时点和固定字段上，否则登记行为会随项目节奏松散掉。
识别时点有三个：计划会拆解工作项时识别跨项交付关系；需求评审时识别决策前置；迭代启动前做一次依赖补录，确认本期工作项的前置条件是否已具备。三个时点各有侧重，计划会覆盖大部分交付物依赖，评审会捕捉决策类依赖，迭代启动前的补录用于兜底。
登记字段建议固定为：前置项、后置项、类型、强度、依据、责任人、登记时间、状态。其中“依据”一栏写清具体交付物或决策名称，是后续判断依赖是否仍成立的关键；“责任人”指对该条依赖的确认与跟踪负责的人，通常由后置项负责人担任。
变更与解除需要触发条件和审批。前置项范围变化、交付物内容调整、排期整体移动时，依赖条目必须同步更新类型、强度或时间偏移。解除依赖的触发条件包括：前置交付物不再被需要、后置项被取消或拆分、依赖关系被其他工作项替代。解除动作由登记责任人发起，经项目管理者确认后关闭条目，保留变更记录。
失效清理是容易被忽略的一步。迭代结束后，对本期登记的所有依赖做一次状态核对：已满足的标记关闭，未满足但已无影响的标记失效并注明原因。过期依赖留在台账里，会让下一次排期检查产生误报。
角色分工与各环节交付物
依赖规则涉及四类角色，职责边界清楚，登记和检查才不会互相推诿。
| 角色 | 主要动作 | 交付物 |
|---|---|---|
| 任务负责人 | 识别本工作项的前置条件，提出依赖登记，确认依赖是否仍成立 | 依赖登记申请、依赖状态更新 |
| 项目管理者 | 审核依赖条目，组织排期检查，处理冲突升级 | 依赖台账、排期检查记录、冲突处置结论 |
| 技术负责人 | 判断技术类依赖的类型与强度，评估拆分可行性 | 技术依赖确认意见、拆分建议 |
| 交付验收人 | 在验收环节核对依赖是否已满足、是否已关闭 | 验收结论中的依赖核对项 |
依赖确认需要双方动作：前置项负责人确认自己能按约定时间交付，后置项负责人确认该交付物确实是开工条件。口头确认容易遗漏，建议在登记条目上留下确认记录。依赖台账由项目管理者维护，更新频率与项目节奏一致，至少在每个迭代启动前和结束后各更新一次；高频交付的团队可以改为每周核对。
当依赖登记和排期检查在协作工具中完成时，工作项之间的前后置关系、责任人和状态可以直接作为台账的数据来源。ONES 支持在工作项上建立关联关系并跟踪状态，项目管理者可以据此组织排期评审，减少依赖信息在表格与工具之间反复同步的成本。
把依赖纳入排期检查与冲突处理
依赖进入排期的方式是按依赖链逐段核对：对每个后置项，检查其前置项的预计完成时间是否早于后置项的计划开始时间，并留出滞后时间。核对结果分三类：满足、存在风险、阻断。存在风险的条目在排期评审中标注，阻断的条目不得进入本期承诺。
依赖冲突的识别信号有三个：前置项已出现延期且影响后置项开工；依赖链出现循环，A 等 B、B 等 A；跨团队等待时间超过约定阈值且无明确回复。发现冲突后按顺序处置：
- 调整顺序：把后置项中不依赖前置交付物的部分提前执行，或调整两项工作的先后安排。
- 拆分工作项：把后置项拆成可独立推进的部分和必须等待的部分，前者先进入执行。
- 升级协调：前两步无法解决时，由项目管理者将冲突提交到跨团队协调会，明确新的交付时间并更新依赖条目。
需要划清边界：依赖规则处理的是工作项之间的等待关系；项目整体进度偏差归入进度管理，人员不足或负载不均归入资源管理。把容量问题登记成依赖，会让台账承担它无法解决的职能。
示例：一条依赖规则从识别到关闭
以下为演示情景。某团队本期包含两个工作项：A“支付接口文档定稿”，B“支付模块联调”。
识别与登记：计划会上，B 的负责人提出联调需要接口文档作为输入，双方确认 A 的定稿是 B 开工的必要条件。登记条目为：前置项 A、后置项 B、类型完成—开始、强度强制、依据“接口文档定稿版本”、责任人 B 负责人、状态待确认。A 负责人确认可按计划完成，条目状态改为已确认。
排期检查：项目管理者核对 A 的计划完成时间早于 B 的计划开始时间，且预留了两天滞后用于文档评审，判定为满足，B 进入本期承诺。
执行跟踪：执行中 A 因评审意见返工，预计延期三天。B 负责人更新依赖状态为风险，项目管理者按处置顺序先拆分 B：将不依赖文档的联调环境搭建提前执行，同时与 A 负责人确认新的定稿时间，更新依赖条目中的时间偏移。
关闭：A 定稿后，B 负责人确认交付物可用，依赖状态改为已满足；迭代结束核对时，该条目正式关闭并保留变更记录。整个过程体现了登记字段的填写、双方确认动作和排期检查的介入时点。
完成检查：依赖规则是否可执行
规则发布后，用以下清单逐项核对，判断它是否真正落地：
- 判定口径能被团队成员用自己的话复述，并能对具体工作项对给出“是依赖/不是依赖”的判断。
- 登记表中每条依赖都包含前置项、后置项、类型、强度、依据、责任人和状态，无空缺字段。
- 每条依赖只有一条登记记录，方向为前置指向后置，无双向重复。
- 强制依赖与可选依赖分开标注，排期评审对两者的处理方式不同。
- 本期所有强制依赖都经过排期检查，检查结论有记录。
- 发生变更或解除的依赖留有变更记录和确认人。
- 迭代结束后的失效依赖已清理，台账中不存在已无影响的过期条目。
- 验收环节包含依赖核对项，未满足的依赖不会随验收默认关闭。
阻断项是前三条：判定口径无法复述、登记字段缺失、存在双向重复登记。这三项不通过，后续排期检查和台账维护都建立在不可靠的数据上，应先修正再推进其他检查项。
常见问题
团队规模小、工作项不多，还需要完整的依赖登记表吗？
可以简化，但判定口径和登记字段不宜省略。小团队常见做法是保留前置项、后置项、类型、强度、责任人五个字段，把依据写成一句话附在条目上，更新频率改为每周一次。判定口径仍要保留，否则成员对“算不算依赖”的理解不一致，简化后的台账同样会失真。工作项数量少时，排期检查可以并入每周例会，不必单独组织评审。
前置项延期后，后置项应该直接顺延还是先拆分？
先判断后置项中是否有不依赖前置交付物的部分。如果有，优先拆分，把可独立推进的部分提前执行，等待部分按新的前置完成时间重新排期；如果后置项整体都依赖前置交付物，才考虑顺延。顺延会影响本期承诺，需要项目管理者确认并更新依赖条目中的时间偏移。两种处理都要留下记录，便于迭代结束后核对延期原因。
跨团队依赖长期没有明确回复，规则里怎么处理？
在依赖条目上设置等待阈值，例如超过约定天数未确认即标记为风险，由项目管理者升级到跨团队协调会。升级时带上三项信息：依赖的具体交付物、后置项受影响的开始时间、已尝试的沟通记录。协调会结论要回写到依赖条目，明确新的交付时间或替代方案。等待期间后置项可按拆分原则先推进不依赖该交付物的部分，避免整体停滞。
可选依赖在排期评审中要不要逐条讨论？
不必逐条讨论，但要在排期记录中列出。可选依赖不阻断承诺，评审时只需确认两点：后置项在可选依赖未满足时是否有替代方案，以及该依赖是否有可能在期内转为强制。如果转为强制，按变更流程更新类型和状态，并重新做一次排期检查。把可选依赖与强制依赖混在一起逐条讨论，会稀释评审对真正卡点的注意力。
迭代结束后，未满足但已无影响的依赖怎么处理？
标记为失效并注明原因，保留条目和变更记录，不直接删除。失效原因通常有三类：前置交付物不再被需要、后置项被取消或拆分、依赖关系被其他工作项替代。清理动作由登记责任人发起，项目管理者核对后关闭。保留记录的价值在于下次遇到相似工作项时，可以回看这条依赖当初为什么失效，避免重复登记同类无效关系。
