两个团队的任务互为前置条件，工作往往卡在“都在等对方”的状态。处置时先判断这是真闭环、任务拆得太粗造成的假闭环，还是可以拆成串行的先后关系；再逐条核对依赖，找出真正卡住双方的交付物；把它从循环中摘出，指定唯一负责方和完成标准，其余任务改为围绕它排期；最后用一次完整交付验证闭环解除，并把依赖登记纳入日常评审。本文只讨论工作项之间的依赖安排，项目整体进度和人员容量问题不在范围内。
要点总览（TL;DR）
- 先判断问题性质：双方任务都卡在等待对方时，可能是真闭环、任务颗粒度过粗造成的假闭环，或可以拆成串行的先后关系，三类情形的处置方向不同。
- 定位卡点靠证据：列出全部交叉依赖，逐条核对交付物是否真的必须由对方先完成，能否用接口约定、样例数据先行推进，把假设性阻塞和已确认阻塞分开。
- 处置动作是把卡点交付物从循环中摘出，指定唯一负责方和完成标准，其余任务改为依赖它或并行推进；改动前留存原排期，涉及跨团队承诺先确认。
- 验证要看一次完整交付：卡点交付物按期验收、双方任务实际进入进行中、下个周期不再互相等待，三个信号同时出现才算解除。
- 把依赖登记、计划评审时的闭环检查和定期复核固化为日常机制，复发时按预设路径回退与升级，避免重新陷入互相等待。
互为前置条件时，先判断这是不是真正的循环依赖
两个团队都标记“等待对方”，两边的任务都无法进入进行中，这是互为前置的典型表现。但症状相同，成因可能完全不同。第一步要做的是把当前问题归入下面三类之一，再决定后续动作。把排期问题误判为依赖故障，会导致拆解方向错误；把真闭环当成普通串行任务，则会在推进中反复卡住。
| 情形 | 典型特征 | 判断方法 | 处置方向 |
|---|---|---|---|
| 真闭环 | 双方各自有一个交付物必须以对方交付物为输入，缺一方另一方无法开始 | 逐条核对依赖方向，确认两个交付物之间是否形成闭环 | 拆出关键交付物，改写为单向依赖 |
| 假闭环（颗粒度过粗） | 任务名称很大，如“完成接口联调”“交付数据服务”，看起来互相需要 | 尝试把任务切成更小的交付物，看是否仍互相阻塞 | 拆细工作项，闭环往往随之消失 |
| 可拆串行 | 一方的工作确实需要另一方先完成，但另一方并不需要对方先做 | 检查反向依赖是否真实存在，还是被顺带写进了同一批次 | 按先后顺序排期，明确交接点 |
判断时抓住一个边界：只看工作项之间的依赖安排。如果两个团队的问题是整体里程碑排不下、人手不够导致任务积压，那属于项目进度或资源负载问题，需要换一套方法处理，不应在这里通过改依赖关系来解决。
区分真闭环与假闭环，有一个简单的检验动作：把双方的任务各写成一到三句话，每句话描述一个可独立验收的交付物。如果拆完后发现某一方的小交付物并不需要对方先完成，原来的“互为前置”就是颗粒度问题。拆不动、每一小块都仍然需要对方先交付，才更可能是真闭环。
逐条核对依赖，找出闭环卡点与排除证据
判断为真闭环后，不要停留在“谁先谁后”的争论上，而是把双方全部依赖关系列成清单。清单至少包含四项：依赖方向（谁依赖谁）、依赖的交付物、该交付物的完成标准、当前状态。清单要覆盖两个团队之间所有交叉依赖，而不只是争议最大的那一条，因为闭环往往由多条依赖共同构成。
| 依赖编号 | 依赖方 | 被依赖方 | 交付物 | 完成标准 | 验证证据 |
|---|---|---|---|---|---|
| D1 | 团队A | 团队B | 接口字段定义与样例数据 | 字段清单确认，样例可解析 | 已确认：A的开发任务需要该定义才能开始编码 |
| D2 | 团队B | 团队A | 业务规则说明 | 规则文档评审通过 | 待验证：B称需要A先给出规则，但B的原型工作是否真的被阻塞尚未确认 |
清单完成后，寻找闭环中最难替代、最靠近外部交付的那一环。所谓最难替代，是指这个交付物无法用约定、样例或临时方案绕过，必须由某一方真实产出；最靠近外部交付，是指它直接支撑对客户或下游的承诺。这一环通常就是卡点。卡点不一定是双方争论最激烈的那条依赖，也不一定属于话语权更大的一方。
定位卡点需要证据，而不是印象。对每条依赖问三个问题：这个交付物是否真的必须由对方先完成？能否用接口约定、样例数据、模拟环境先行推进？如果对方延迟一周，本方是否完全无法开始？三个问题的答案能把“假设的阻塞”和“已确认的阻塞”分开。例如团队B声称必须等A的规则文档才能动工，但核查后发现B的原型可以用假设规则先做，那么D2就是假设性依赖，不应写成确定阻塞。只有经过验证、确实无法绕过的依赖，才进入下一步的处置范围。
核对结束后应形成两个结论：闭环由哪几条依赖构成，以及其中哪一条是真正的卡点。每条被认定为卡点的依赖都要附上验证证据，例如双方确认的交付物清单、已完成的技术评审记录或明确的对外承诺时间。证据不足的依赖先标记为待确认，在处置时按可绕过的依赖处理。
按卡点拆解并处置：把闭环改成单向交付
处置的核心动作是把卡点交付物从循环中摘出来，让它只朝一个方向流动，其余任务围绕它排期。具体按以下顺序操作。
- 拆细工作项。把双方的大任务切成可独立验收的小交付物，每个交付物写清输入、输出和验收方式。拆到“一方完成即可交给另一方使用”的程度为止。
- 指定卡点交付物的唯一负责方。从两个团队中选定一个团队对该交付物负全责，明确完成标准和交付时间。负责方只有一个，避免双方都以为对方在做。
- 改写其余任务的依赖方向。原来互相等待的任务，改为依赖卡点交付物。另一方在等待期间用接口约定、样例数据或中间产物先行推进可并行的部分。
- 确认跨团队承诺变更。调整依赖关系会改变排期承诺，涉及对外交付时间或上下游团队时，先与相关方确认再修改，避免单方面改动造成新的断点。
改写后的依赖安排应当能用一张表说清楚：卡点交付物是什么、由谁负责、完成标准是什么、其余任务各自依赖它还是可以并行。下面是一个演示情景，仅用于说明结构，不代表真实项目。
| 工作项 | 负责方 | 依赖关系 | 完成标准 | 排期安排 |
|---|---|---|---|---|
| 接口字段定义与样例数据 | 团队B | 无前置，作为卡点交付物 | 字段清单确认，样例可解析 | 第1周内交付 |
| 业务规则说明 | 团队A | 不阻塞B的原型工作，按假设规则先行 | 规则文档评审通过 | 与B的接口定义并行 |
| 联调开发 | 团队A | 依赖接口字段定义 | 联调用例通过 | 接口定义交付后启动 |
| 数据服务开发 | 团队B | 依赖业务规则说明的最终版本 | 服务接口按规则返回正确结果 | 规则评审通过后启动 |
操作中有两个风险点需要交代。第一，调整依赖关系前先留存原排期和原依赖清单，便于出现问题时对照回退。第二，如果卡点交付物在约定时间内没有完成，不要立刻恢复原来的互相等待状态，而是按预设的升级路径处理：由负责方说明阻塞原因，双方重新确认交付时间，必要时上报共同上级协调。停止点是明确的——当卡点交付物连续两次延期且原因无法在团队内解决时，应暂停依赖改写方案，回到依赖清单重新评估卡点选择是否正确。
依赖登记、工作项拆分和状态同步需要有承载的地方。ONES 通过统一的需求池、工单与任务看板实时同步状态与信息，便于追溯需求与问题，适合把改写后的依赖安排和交付物状态放在同一处供两个团队查看；其迭代计划、任务看板等工具也可用于跟踪卡点交付物的进展。具体到工作项之间的前置/后置依赖配置与闭环检测，需结合团队实际使用的功能确认。
验证闭环已解除，并建立防复发的依赖登记机制
依赖改写是否有效，要用一次完整交付来验证，而不是看排期表是否好看。验证信号有三个：卡点交付物按约定时间完成并通过验收；双方原本无法进入进行中的任务实际进入了进行中；在下一个交付周期内没有再出现互相等待的状态。三个信号同时出现，才能判断闭环已解除。只满足第一个信号，说明交付物产出了但依赖关系可能仍未理顺；只满足第二个信号，可能是绕过了卡点而非真正解除。
验证通过后，把这次处置中形成的做法固化为日常机制，降低再次成环的概率。
- 计划评审时检查闭环。新增依赖进入计划前，沿依赖方向走一遍，确认不会回到起点。评审清单中增加一项：本次新增依赖是否与已有依赖构成闭环。
- 建立依赖登记。把跨团队依赖集中登记，记录方向、交付物、完成标准和负责人，指定一名维护人定期复核。登记表随计划变更同步更新，避免依赖关系只存在于口头约定中。
- 定期复核与状态同步。在固定的计划例会上核对依赖登记，标记已解除、延期和新增的依赖。状态同步的频率与交付节奏匹配，交付密集时缩短复核间隔。
- 明确复发时的回退与升级路径。再次出现互为前置时，先回到情形判断，确认是新闭环还是旧依赖未真正解除；无法在团队内解决的，按预设路径升级协调，不重新陷入互相等待。
这套机制的重点在于让依赖关系可见、可查、有人维护。依赖登记表本身就是下次诊断的起点：当两个团队再次出现任务互相卡住时，可以直接从登记表中找出相关依赖，核对方向和完成标准，缩短定位卡点的时间。
常见问题
两个团队都认为对方该先动，但没人能确认依赖是否真实存在，怎么快速核实？
对每条争议依赖问三个问题：这个交付物是否必须由对方先完成；能否用接口约定、样例数据或模拟环境先行推进；对方延迟一周，本方是否完全无法开始。三个问题中只要有一个答案指向“可以绕过”，这条依赖就先按假设性阻塞处理，不进入拆解范围。核实过程要留下证据，例如双方确认的交付物清单、技术评审记录或对外承诺时间，证据不足的依赖标记为待确认。
卡点交付物交给哪个团队负责，双方都想要或都不想要时怎么定？
选择依据是这个交付物最靠近谁的产出链条、谁具备完成它所需的输入和技能，而不是谁话语权更大或谁更空闲。确定后只设一个负责方，完成标准和交付时间写清楚，另一方转为使用方。如果双方都主张负责，可以让各自先产出一个最小样例，用样例质量决定归属；如果都不愿承担，说明该交付物可能仍未被拆到可独立验收的粒度，需要继续拆细再分配。
调整依赖关系后卡点交付物延期了，要不要恢复原来的互相等待状态？
不建议恢复原状。按预设的升级路径处理：由负责方说明阻塞原因，双方重新确认交付时间，必要时上报共同上级协调。设置明确的停止点——卡点交付物连续两次延期且原因无法在团队内解决时，暂停依赖改写方案，回到依赖清单重新评估卡点选择是否正确。恢复互相等待只会让双方重新卡住，问题从延期变成停滞。
依赖登记表由谁维护，多久复核一次比较合适？
指定一名维护人，通常由承担计划协调职责的角色担任，负责在计划变更时同步更新登记表。复核频率与交付节奏匹配：交付密集的阶段缩短间隔，例如每周在计划例会上核对一次；节奏平稳时可以拉长。复核时标记已解除、延期和新增的依赖，重点检查新增依赖是否与已有依赖构成闭环。
两个团队分属不同项目，依赖关系跨项目时，这套方法还适用吗？
适用，但需要额外确认两件事：一是依赖登记要覆盖跨项目的交付物，避免只在一个项目内可见；二是卡点交付物的完成标准需要两个项目的负责人共同确认，单方定义容易在验收时产生分歧。如果跨项目依赖涉及整体里程碑排期，那部分属于项目进度管理的范围，应与本文的依赖处置分开处理。
