循环依赖会让排期在看似确定的情况下反复返工：A等B完成，B又在等A，任何一方都无法真正开始。一套可执行的流程通常包含四段：先统一依赖登记口径，再在排期前做环路扫描，接着定位关键环路并组织负责人协商解除，最后复扫确认并记录变更。本文聚焦工作项安排层面的依赖关系，适用于迭代或项目排期前的依赖清理，不涉及整体进度计划编制与人员容量调配。
要点总览（TL;DR）
- 循环依赖的定位与解除分四段：统一依赖登记口径、排期前环路扫描、定位关键环路并协商解除、复扫确认并记录变更。
- 依赖登记至少包含前置项、后置项、依赖类型和依赖理由；软依赖是环路的高发来源，登记时应单独标注。
- 多个环路并存时，优先处理卡住关键交付、与其他环路共享工作项的环路，一次调整可同时解开多个环。
- 解除环路有四种手段：删除伪依赖、调整先后顺序、拆分工作项、引入中间交付物，选择取决于依赖是否为硬约束以及交付能否切分。
- 环路相关负责人在同一场合集中确认调整方案，复扫无残留环路并归档变更原因，流程才算闭环。
先统一依赖登记口径，让环路可被检出
环路检测的前提是依赖关系被完整、一致地记录下来。如果依赖只存在于口头约定或聊天记录里，扫描就无从谈起。因此第一步是把“谁依赖谁、为什么依赖”固化成字段，让每条依赖都能被追溯和判断。
依赖登记至少应包含四个字段，缺一项都会影响后续判断：
| 字段 | 填写要求 | 作用 |
|---|---|---|
| 前置工作项 | 填写被依赖的工作项编号与名称 | 确定依赖边的起点 |
| 后置工作项 | 填写发起依赖的工作项编号与名称 | 确定依赖边的终点 |
| 依赖类型 | 完成—开始、开始—开始等，注明具体约束 | 区分等待方式，避免笼统写“有依赖” |
| 依赖理由 | 一句话说明需要等待的具体交付物或信息 | 判断硬依赖与软依赖的依据 |
依赖理由这一栏最关键，它决定了依赖是硬约束还是软约束。硬依赖来自交付物本身的约束，例如接口未定义就无法联调、设计稿未确认就无法开发。软依赖来自习惯或沟通顺序，例如“想等对方先出初稿再动手”“习惯按这个顺序汇报”。软依赖是环路的高发来源，因为它在业务上并非不可调整，却常被当成必须遵守的顺序登记下来。登记时应明确标注依赖性质，软依赖单独标记，便于扫描后优先复核。
登记责任落在后置工作项负责人身上：由发起等待的一方填写前置项、类型和理由，并在排期前统一提交。这样做的原因是，等待方最清楚自己需要什么、为什么需要，由他写理由比由计划负责人代填更准确。计划负责人负责汇总和检查字段完整性，不替业务方编造理由。
依赖数量与粒度也需要控制。同一交付物只登记一条依赖，避免把“等接口文档”拆成“等字段定义”“等错误码说明”等多条重复边，否则依赖图会被冗余边淹没，环路判断失真。粒度以“一个可独立确认的交付物”为准，交付物内部的分项在依赖理由中说明即可。
排期前的环路扫描：检测步骤与判定规则
依赖登记完成后、正式排期前，是执行扫描的固定时点。此外，当依赖发生批量变更，例如多个工作项同时调整前置关系，也应重新扫描，因为批量变更最容易在无意间形成新环。
扫描方法可以概括为把工作项与依赖画成有向图：节点是工作项，边是从前置项指向后置项的依赖方向。从任一工作项出发，沿依赖方向逐级追踪，如果能回到起点，就构成一个环路。实际操作中，可以从入度为零的工作项开始逐层剥离，剥离后仍有剩余节点且彼此相连，剩余部分即包含环路；也可以对每个节点做深度追踪，记录回到自身的路径。
扫描的输出物是一份环路清单，每条记录包含：涉及的工作项编号、构成环路的依赖边（按顺序列出）、发现时间、初步判断的环路类型。清单是后续定位和协商的工作底稿，应集中维护，避免分散在多个文档中。
判定规则按环路形态区分处理：
- 自依赖：工作项依赖自身，通常是登记错误，直接修正字段即可，无需协商。
- 两点互依：两个工作项互相依赖，环路最短，处理成本低，应优先核实其中一条是否为软依赖。
- 多点长环：三个及以上工作项首尾相连，往往混合了硬依赖与软依赖，需要逐边核实理由，处理周期更长。
扫描完成后，清单中每条环路都应有明确状态：待处理、处理中、已解除。没有状态的环路等于没有进入流程。
如何定位关键环路并排定处理顺序
多个环路并存时，逐条平均用力会拖慢排期。合理的做法是先判断哪个环路对交付影响最大，再集中协商资源处理。判断可以按四个维度进行：
- 是否卡住关键交付：环路中的工作项位于关键路径或关键里程碑上，优先级最高。
- 环路长度：长环涉及的依赖边多，解除后释放的排期空间更大，但协商成本也更高。
- 涉及负责人数量：跨团队、跨角色的环路需要更多协调时间，宜早启动。
- 是否与其他环路共享工作项：共享节点意味着一次调整可能同时解开多个环，这类环路应排在最前。
共享工作项优先处理是排序中最实用的一条规则。例如工作项C同时出现在两个环路中，先调整C的依赖关系，可能让两个环路同时消失，比分别处理两个环更省事。判断时应先在环路清单中标记出现频次高的工作项，再据此排序。
排序前还要区分真实环路与假环路。假环路通常由登记错误造成，例如前置与后置填反、把同一交付物登记成两条方向相反的依赖、或者把已经完成的旧依赖保留在系统中。假环路不需要协商，修正登记即可，应在排序时先剔除，避免占用协商资源。
完成上述判断后，形成一份带优先级的待处理环路列表，每条注明优先级、判断依据、建议处理方式和预计协商时间。这份列表是后续协商会议的议程来源。
与任务负责人协商解除依赖的四种做法
解除环路的核心是打断至少一条依赖边。具体手段有四种，选择哪一种取决于依赖是否为硬约束、交付能否切分。
| 手段 | 适用条件 | 操作要点 |
|---|---|---|
| 删除伪依赖 | 核实后确认依赖理由不成立，或仅为沟通顺序 | 由双方负责人确认理由，删除依赖边并标注原因 |
| 调整先后顺序 | 一方可以先交付可用部分，另一方不必等全部完成 | 改变交付切分方式，把“等全部”改为“等首批” |
| 拆分工作项 | 环上的工作项较大，内部存在可独立交付的部分 | 拆成小项，让其中一项脱离环路，切断回边 |
| 引入中间交付物 | 双方确实互相需要对方成果，但可以先用阶段性产物替代 | 定义一份临时产物（如草案、样例、接口约定），用它替代双向等待 |
删除伪依赖是最低成本的手段，但需要谨慎核实。判断标准是：去掉这条依赖后，后置工作项是否仍能按质量要求完成。如果能，说明它本来就是软依赖；如果不能，说明它是硬约束，应转向其他手段。调整先后顺序适用于交付可以分批的场景，例如后端先提供接口约定，前端据此开发，完整接口随后补齐。拆分工作项适用于大项内部耦合松的情况，拆出的子项可以先行启动。引入中间交付物适用于双方都需要对方成果、但完整成果短期内无法产出的情况，用草案或约定先解除等待。
协商的组织方式直接影响解除效率。建议把同一环路涉及的所有负责人安排在同一场合确认，而不是两两私下沟通。原因是环路调整往往牵一发动全身，A与B私下达成的新顺序可能又给C造成新等待。集中协商时，逐条过环路清单，对每条依赖边确认性质、选择手段、明确调整后的依赖关系，并当场记录调整理由与影响范围。协商记录应包含：环路编号、调整的依赖边、采用的手段、双方确认人、调整后是否影响其他工作项。
角色分工与各环节交付物
流程能否稳定运行，取决于每个环节是否有人负责、有物可交。四类角色覆盖从登记到复扫的全过程。
| 角色 | 主要职责 | 输入 | 交付物 |
|---|---|---|---|
| 计划负责人 | 组织扫描、维护环路清单、主持协商会议 | 依赖登记表、排期草案 | 环路清单、待处理环路列表、协商记录 |
| 工作项负责人 | 登记依赖、提供依赖理由、执行调整方案 | 工作项说明、交付要求 | 完整填写的依赖登记、调整后的依赖关系 |
| 技术或业务评审角色 | 判定硬依赖是否成立，复核拆分方案可行性 | 依赖理由、交付物定义 | 依赖性质判定结论 |
| 记录与复核角色 | 复扫确认、归档变更原因 | 调整后的依赖关系、协商记录 | 复扫结果、变更归档记录 |
交接点集中在两处：一是依赖登记完成后交给计划负责人汇总，此时应检查字段完整性和软依赖标注；二是协商结束后交给记录与复核角色复扫，此时应核对调整是否已全部落到依赖关系中。两处交接都应有明确的完成标志，前者是登记表字段齐全，后者是复扫结果无残留环路。
在依赖关系集中登记、环路清单需要多人协作维护的场景中，可以借助ONES工作项依赖与排期协作能力承载：依赖登记字段随工作项维护，调整后的依赖关系与变更原因留在同一处，便于复扫时对照。具体字段配置以团队实际使用的产品版本为准。
一个环路解除的完整示例
以下为演示情景，用于说明流程如何串联，不代表真实项目数据。
背景：某迭代排期前，三个工作项形成互依环路。工作项A“订单接口开发”依赖工作项B“订单页面开发”提供的字段清单；工作项B依赖工作项C“支付流程设计”确认的交互方案；工作项C又依赖工作项A提供的接口返回结构。三者首尾相连，构成一个三点长环。
扫描发现：计划负责人在依赖登记完成后执行扫描，沿依赖方向追踪回到起点，确认环路存在，并在环路清单中记录：环路编号L-01，涉及A、B、C三个工作项，依赖边为A→B、B→C、C→A，发现时间为排期前第三天，类型为多点长环。
协商判定：集中协商时逐边核实理由。A→B的依赖理由是“需要字段清单才能定接口”，评审角色确认字段清单属于接口设计的前置输入，判定为硬依赖。B→C的依赖理由是“想等交互方案定稿再开始页面”，核实后发现页面可以先按现有交互规范搭建框架，交互方案后续补充，判定为软依赖。C→A的依赖理由是“需要接口返回结构才能设计支付回调”，属于硬依赖，但接口返回结构可以先出草案。
调整方案：删除B→C的软依赖，B先行启动页面框架开发；对C→A引入中间交付物，A先提供接口返回结构草案，C据此设计支付回调，完整结构随后对齐。调整后依赖关系变为A→B、C→A（草案级），环路被打断。
复扫与记录：记录与复核角色在调整完成后重新扫描，确认无残留环路。变更记录写明：环路L-01已解除，删除软依赖B→C，引入接口结构草案作为中间交付物，影响范围为B的启动时间提前、C的设计依据改为草案，双方负责人已确认。
完成检查：流程可用的判断标准
流程是否真正落地，可以用以下清单逐项核对。每项都应有可查验的证据，而不是口头确认。
- 排期前已完成全量扫描，并有环路清单，清单包含涉及工作项、依赖边和发现时间。
- 每条环路都有处理结论与责任人，状态从待处理推进到已解除或已确认为假环路并修正。
- 复扫结果无残留环路，调整理由与影响范围已记录归档。
- 依赖登记字段完整，前置项、后置项、依赖类型、依赖理由四项齐全，软依赖有明确标注。
- 下次排期可以直接复用同一套扫描步骤和环路清单模板，无需重新设计流程。
五项全部满足，说明检测与解除流程已经形成闭环；若其中某项反复缺失，例如软依赖始终没有标注，应回到登记口径环节修正，而不是在扫描阶段反复补救。
常见问题
依赖登记由谁负责，计划负责人需要代填理由吗？
登记责任落在后置工作项负责人身上，也就是发起等待的一方。他填写前置项、依赖类型和依赖理由，并在排期前统一提交。计划负责人负责汇总和检查字段完整性，不替业务方编造理由。这样安排的原因是等待方最清楚自己需要什么、为什么需要，由他写理由比代填更准确。
软依赖和硬依赖判断错了会有什么后果，如何复核？
把软依赖误判为硬依赖，环路会被当成不可调整，协商只能绕开它，排期继续返工；把硬依赖误判为软依赖，删除后后置工作项可能无法按质量要求完成。复核方法是问一句：去掉这条依赖后，后置工作项是否仍能按质量要求完成。能完成说明它本来就是软依赖；不能完成说明是硬约束，应转向调整顺序、拆分或引入中间交付物。技术或业务评审角色负责给出这个判定结论。
环路涉及跨团队负责人，集中协商难以凑齐时间怎么办？
可以按环路优先级分批组织：先处理卡住关键交付、与其他环路共享工作项的环路，把相关负责人的时间集中在这几条上。对于长环，可以先由计划负责人逐边收集各方的依赖理由和可调整空间，再开一次短会确认方案，减少会议轮次。需要避免的是两两私下沟通后各自改依赖，因为A与B达成的新顺序可能又给C造成新等待，环路容易反复出现。
拆分工作项和引入中间交付物有什么区别，什么时候选哪个？
拆分工作项是把环上的大项拆成可独立交付的小项，让其中一项脱离环路，适用于大项内部耦合较松的情况。引入中间交付物是双方确实互相需要对方成果时，用草案、样例或接口约定等阶段性产物替代双向等待，适用于完整成果短期内无法产出的情况。前者改变的是工作项结构，后者改变的是等待对象，两者可以同时使用。
复扫通过后，如何让这套流程在下次排期继续可用？
把扫描动作固化进排期评审：依赖登记完成后、正式排期前执行全量扫描，依赖批量变更后重新扫描。同时保留环路清单模板和协商记录格式，下次排期直接复用，无需重新设计流程。如果某项检查反复缺失，例如软依赖始终没有标注，应回到登记口径环节修正，而不是在扫描阶段反复补救。
