任务依赖依赖冲突全流程：管理层实操方法与一文讲清

去年我复盘过一个让我印象很深的延期事故：一个原计划 12 周交付的项目，实际用了 19 周。真正让我意外的不是延期本身，而是把 7 周延期拆开之后发现，没有任何一个人"干得慢"，其中 9 周的时间，是三支团队在互相等待对方先完成。

复盘会上每一位负责人都能给出合理解释：我们没收到接口文档、这个需求是上个月才加的、评审会上没人说要改、人已经被另一个项目占用了。每句话都是真的，但拼在一起就变成了一件事，没有人说得清，这条依赖关系当初是谁批准的，为什么变成了现在这个样子。

这就是我后来反复跟管理者讲的一句话：任务依赖冲突，很少是执行层的能力问题，绝大多数是管理层的规则缺失问题。这篇文章不打算复述 PMBOK 的定义，也不打算做工具操作手册，只讲一件事，在"任务依赖 → 依赖冲突暴露 → 冲突裁决 → 规则沉淀"这条全流程上，管理层到底该做哪些决策、在什么时间点做、做到什么程度算合格。

一、先给结论：依赖冲突的本质是管理问题

在展开细节之前，我先把三个核心结论摆出来。这三个结论是我在几家 200 到 800 人规模的研发组织里反复验证过的判断，后面的所有方法都建立在这三条之上。

1. 结论一：依赖关系是一份承诺，不是一条连线

在项目管理工具里画一条 A 指向 B 的连线，成本接近零。但这条线在现实中代表的是一份承诺：甲方团队承诺在某个时间点交付一个符合某个标准的产物，乙方团队基于这个承诺安排了自己的全部资源和排期。

一份完整的承诺需要四个要素：交付物定义、交付时间、质量门槛、违约处理。而我见过的绝大多数依赖连线，只写了第二个，时间。另外三个要素从来没被写下来过。

后果非常直接：一旦延期，上下游对"这件事到底谁该负责"的判断完全不同。甲方认为"我给了，只是晚了两天"，乙方认为"你给的东西根本不能用"。双方都没有错，因为标准从来没被定义过，冲突不是发生在延期那一刻，而是发生在依赖被创建的那一刻。

2. 结论二：代价在中后期爆发，成因在前 20% 的时间里

我在一家约 300 人的研发组织里做过一次脱敏统计：把一次 7 周延期事故的全部成本按人天拆解，结果是这样的。

再看冲突暴露的时间分布。同样是这家组织，我把 12 周项目里被记录的依赖冲突按周统计，得到一条非常典型的曲线。

3. 结论三：管理层要做的不是消灭冲突，而是让冲突可预期、可裁决、可复盘

"把依赖冲突降到零"是一个不可能完成的目标。只要有分工，就有依赖；只要有依赖，就有冲突。真正的管理目标应该换成三个更可执行的状态。

可预期，指的是依赖冲突在发生之前就已经被登记、被分级、被排入议程，而不是靠某个人的责任心去发现。可裁决，指的是冲突发生时有一个明确的拍板人和明确的判断依据，不需要靠职级和嗓门决定谁先谁后。可复盘，指的是每一次冲突解决之后，是否补上了导致它的那条规则。

这三个状态对应三个具体的管理动作：登记机制、仲裁机制、复盘机制。缺任何一个，依赖管理都会退化成"救火"。

4. 这三个结论对管理动作意味着什么

如果你认同上面三条，那么接下来的推论也很清楚。第一，依赖管理的主战场在规划期，不在执行期；第二，管理层要投入的不是技术能力，而是规则设计能力；第三，衡量依赖管理成效的指标，不应该是"冲突数量减少了多少"，而应该是"冲突被提前发现的比例提高了多少"。

最后一条尤其重要。我在很多组织里看到，管理层把注意力放在"这个月冲突少了一点"这种波动上，却从来没有统计过"冲突中有多少是在规划期就被识别出来的"。前者是运气，后者才是能力。

二、真实场景：依赖冲突在组织里到底长什么样

接下来我把依赖冲突拆开来看。管理层不需要理解技术细节，但必须能在一堆模糊的描述里，快速判断出这是哪一类冲突，以及该类冲突应该用什么手段处理。

1. 四种典型形态及其识别信号

我把过去几年遇到的依赖冲突归成四类。这个分类不是为了学术完整，而是因为四类的处理路径完全不同：有的靠重新切分需求，有的靠仲裁，有的靠同步机制，有的只能靠预留缓冲。

这四类里，只有循环依赖是"结构问题"，可以通过重新拆分解决；另外三类都是"规则问题"，靠拆分解决不了，只能靠机制。这也是我在实际工作中最主要的判断依据：如果一类冲突反复出现却总是换不同的人、不同的项目，那它一定是规则问题，不是人的问题。

2. 一个 300 人研发组织的一周

我拿一个具体的周来举例，这样比抽象描述更容易对号入座。这是一家 300 人左右、三条产品线、九支研发团队的组织，我在里面跟过完整的一周。

周一上午，A 团队发现上游接口未按约定时间提供，临时串联了三个会，最后结论是"再等两天"。周一下午，B 团队发现自己依赖的数据表结构被改了，改动方认为"这是优化，不影响"。周二，C 团队的两个工程师被抽走支援 D 团队的紧急需求，C 团队本周计划整体后移，但没有人通知下游。

周三的例行会上，这三个问题都被提起，结论是"大家再对齐一下"。周四继续等。周五，三条产品线的负责人分别向管理层反映"进度有风险"，管理层临时召开协调会，会上做出了决定，但决定只落在了会议纪要里，没有任何一条进入任务系统。

这一周里发生的事情很典型：冲突的发现是随机的，冲突的处理是临时的，冲突的结论是不留痕的。下周同一类问题还会再来一遍，只是换一批人。

3. 为什么工具里的依赖连线解决不了问题

很多人会问，项目管理工具里明明有"依赖关系"功能，画一条线不就行了吗？我做过验证，单靠连线解决不了问题，原因有三条。

• 连线不承载承诺要素。线上只有一个箭头，写不下交付物定义、质量门槛、违约处理，而这些恰恰是争议的源头。
• 连线不承载优先级。当一个资源同时被两条依赖占用时，系统会告诉你"存在冲突"，但不会告诉你"哪条更重要"，因为这个信息在组织里从来没被定义过。
• 连线不记录变更责任。依赖被改了，谁改的、什么时候改的、有没有通知下游，这些信息不在连线上，导致复盘时只能靠回忆。

所以工具的位置很清楚：它负责把依赖变得"可见"。而"可见"只是起点，从可见到可裁决，中间隔的是一整套规则。

4. 依赖冲突的三个隐藏成本

直接成本（延期、加班）大家都会算，真正被低估的是三个隐藏成本。第一个是等待成本：人在等待期间不是完全空闲的，但产出一定低于正常水平，而且这种损失不会出现在任何报表里。

第二个是切换成本：一个工程师被临时抽走处理依赖问题，回来之后重新进入原来的上下文，通常要半天到一天。依赖冲突越多，切换越频繁，效率损耗是叠加的。

第三个也是最难量化的，是信任成本。当一支团队连续几次被上游"放鸽子"，它下次排期时就会主动加缓冲，而这个缓冲是加在管理者看不到的地方的。三年下来，组织会形成一种"谁老实谁吃亏"的隐性文化。

三、四个常见误区，以及它们各自的代价

在讲具体方法之前，我想先拆掉四个高频误区。这四个误区有个共同特点：它们都"看起来很有道理"，所以很难被纠正。

1. 误区一：把依赖管理等同于排期管理

最常见的一种做法是，一发现依赖冲突，就打开甘特图调整时间。上游延了两天，下游就往后推两天，看起来问题解决了。

但依赖冲突的核心往往不是时间，而是交付标准不明确。我见过一个典型案例：上游按时交付了接口，下游却无法使用，因为双方对"完成"的定义不同。上游认为文档写完就算完成，下游认为要能在沙箱环境跑通一百笔真实数据才算完成。这种冲突调十次排期也解决不了。

2. 误区二：用工具替代规则

第二类误区是采购一套依赖管理功能更强的平台，然后期待问题自动消失。工具确实能让依赖关系从"没人知道"变成"一目了然"，这本身有价值。

但如果组织里没有"依赖变更需要谁批准""资源冲突时谁优先"这两条规则，那么工具上呈现出来的只是一张更漂亮的冲突图。工具解决的是"看不见"，规则解决的是"判不了"，两件事不能互相替代。

3. 误区三：只在冲突爆发时介入

这类管理者的响应速度其实很快，冲突一出现就能拉到人、拍下板。表面上看处理效率高，但代价是同类问题会反复发生，因为每一次处理都是个案，没有沉淀成规则。

我统计过一组数据：在只做救火式处理的团队里，同一类依赖冲突在 90 天内的复发率超过 70%。也就是说，管理者花在处理冲突上的时间，大部分是在为上一次的"临时决定"还债。

4. 误区四：把外部依赖当成内部依赖来管

外部依赖包括客户方提供的接口、监管审批、第三方供应商、集团内其他事业部。很多管理者会用管理内部团队的方式去管理它们，定时间、安排对接人、每周跟进。

问题在于，这些对象不受你的绩效体系约束，你对他们的"强制力"接近于零。可行的做法不是加频次，而是加缓冲和加备选：对外部承诺预留额外时间，同时准备替代方案。这一点我在后面的取舍部分会展开。

四、专业判断逻辑：依赖冲突的分级、仲裁与变更规则

前面讲的是"是什么"和"为什么"，这一部分讲"怎么判"。我把自己在实践中最常用的判断框架整理成三维分级加三段仲裁，管理层可以直接拿去用。

1. 三个判断维度：影响面、可逆性、时间窗

面对一起依赖冲突，我不建议管理者先问"谁的责任"，而应该先问三个问题。

影响面：这个冲突影响几条交付线、几个团队、是否涉及对外承诺。影响面决定它需要谁来拍板。可逆性：如果现在做出让步，改回来的成本有多高。越难回滚的决策，越应该由更高层级来做。

时间窗：距离下一个不可移动的节点还剩多少天。时间窗决定响应时限，剩余三天和剩余三周的冲突，处理路径完全不同。

这三个维度组合起来，就能把一堆看起来同样紧急的冲突排出真正的优先级。我经常跟管理者说，依赖冲突管理的核心不是"谁先谁后"，而是"用同一把尺子量谁先谁后"。

2. 四级分级与响应规则

基于这三个维度，我通常把依赖冲突分成四级。分级的意义不在于贴标签，而在于让所有人知道"这个级别的冲突该找谁、多久内必须回话"。

这张表最容易被忽略的是最后一列：升级条件必须量化。"缓冲被消耗超过一半"比"情况严重时升级"有用一百倍，因为前者可以被执行，后者只能被解释。

3. 谁拍板：仲裁机制的三条设计原则

分级解决了"多急"，仲裁解决的是"谁定"。我在设计仲裁机制时坚持三条原则。

第一条，每个层级都有一个明确的最终拍板人，而不是一个委员会。委员会在依赖冲突上几乎总是失效，因为它的默认结论是"再研究研究"。拍板人可以是项目集负责人、产品负责人或技术负责人，取决于冲突性质，但必须是一个人。

第二条，拍板人必须在规定时限内给出结论，哪怕结论是"维持现状"。"不做决定"本身也应该是一个决定，并且要记录理由。我最常设置的一条规则是：超过时限未决策，视为默认按下游团队方案执行，责任由未决策方承担。

第三条，仲裁依据要写下来。通常是三条：是否影响对外承诺、是否影响收入相关功能、是否涉及合规与安全。这三条之外的因素，原则上不进入仲裁考虑范围，否则每次讨论都会变成部门利益博弈。

4. 依赖变更的审批路径与变更窗口

依赖冲突里有相当一部分不是"没做"，而是"改了没通知"。解决这个问题最有效的办法，不是加强沟通意识，而是设置变更窗口。

我通常设置每周两个固定变更窗口，比如周二和周四下午。所有非紧急的依赖变更必须在这两个窗口内提出并完成审批，非窗口期的变更申请一律推迟到下一个窗口。

这条规则看起来增加了摩擦，实际效果是让变更变得可预期。下游团队知道"每周有两次可能收到变更"，就可以把跟进动作集中安排，而不是全天候被打断。紧急变更保留例外通道，但需要 P0 或 P1 级别的判定背书。

5. 依赖登记表该有哪些字段

登记是全部规则的基础。字段设计的原则是：宁可少，但每个字段都必须能用于决策。下面是我在多个组织里反复迭代后稳定下来的字段结构，可以直接拿去改。

dependency_id: DEP-2026-0371
upstream_team: 支付中台

upstream_task: 对账接口 v2 联调完成

downstream_team: 订单履约

downstream_task: 结算页灰度发布

deliverable: 接口文档 + 沙箱环境 + 100 笔真实样本对账通过

commit_date: 2026-03-18

owner: 支付中台产品负责人

quality_gate: 联调报告签字 + 连续 3 天无 P1 缺陷

risk_level: P1

buffer_days: 3

change_policy: 变更需提前 3 个工作日申请，PMO 审批

change_window: 每周二、周四 14:00-17:00

escalation: 超期未交付自动升级至项目集负责人

这十四个字段里，真正决定成败的是三个：deliverable（交付物定义）、quality_gate（质量门槛）、escalation（升级规则）。前两个解决"标准不一致"，最后一个解决"没人推动"。

我见过太多登记表只填了 commit_date 和 owner，结果这张表变成了一个更精致的甘特图，冲突该发生还是发生。

五、案例与数据观察：一次 12 周的依赖治理落地

这一部分我拿一个完整案例来讲。这是一家约 300 人的研发组织，三条产品线，九支研发团队，年研发投入在数千万级别，属于典型的中大型企业规模。以下数据均为脱敏后的内部统计口径，不是行业统计数据。

1. 起点：依赖关系在系统里，但没人在例会上看

这家组织当时用的是某海外项目管理工具，需求、迭代、缺陷都在里面。依赖关系也有人画，但九支团队里只有两支在用，而且画完之后没人看。

真正的痛点是三个：跨团队依赖登记覆盖率只有 23%；依赖阻塞平均时长 5.8 天；每个迭代因为依赖问题产生的返工约 42 人天。迭代延期率 47%，接近一半。

更麻烦的是，因为工具是海外 SaaS，数据存在合规与访问稳定性上的顾虑，集团层面已经提出国产替代的要求。这构成了这次治理的双重目标：机制建设和平台替换。

2. 动作一：依赖登记表 + 每周 30 分钟依赖同步会

第一个动作不是买工具，而是定规则。我们先把依赖登记范围收窄到"跨团队依赖"和"影响交付节点的依赖"，其他的不登记。这一步很关键，早期我们试图登记所有依赖，结果是登记表迅速变成形式主义。

然后是会议规则。每周三上午 30 分钟，只处理三件事：新增依赖、变更依赖、阻塞依赖。每件事的汇报格式固定为三句话：上下游是谁、承诺什么、现在卡在哪。讨论超过 5 分钟未达成一致，直接升级，不在会上纠缠。

会议时长从原来的 90 分钟降到 30 分钟，但决策密度反而提高了。这是因为议题被收敛了，之前 90 分钟里有大半时间在同步信息，而不是做决策。

3. 动作二：仲裁规则与变更窗口

第二个动作是把第四节讲的分级与仲裁落地。我们设定了三位拍板人：跨产品线冲突由项目集负责人裁决，产品范围类冲突由产品负责人裁决，技术方案类冲突由技术负责人裁决。

同时设置每周两个变更窗口，并明确规定：超期未决策的，默认按下游方案执行。这条规则刚推出来时争议很大，但正是它把决策从"无限期等待"变成了"有时限选择"。

三个月后回头看，这条"默认执行"规则贡献了最大的变化：依赖变更响应时长从 3.4 天降到 0.8 天。

4. 动作三：工具侧承接，以 PingCode 为例

规则定了之后，需要系统承载。这家组织最终选择了 PingCode。选择理由有三条，我认为对同类规模的组织有参考意义。

第一条是规模匹配。PingCode 主要服务中大型企业及 100 人以上组织，这家组织 300 人、九支团队、三条产品线，正处在"轻量工具管不住、重型平台用不满"的区间，产品形态与组织阶段比较匹配。

第二条是支持私有化部署。研发数据、需求文档、代码关联信息全部留在内网，满足了集团的数据合规要求，也能和内部 SSO、CI 流水线做打通。对中大型企业来说，这一条往往是决策的分水岭。

第三条是支持 Jira 平滑迁移。这家组织原本在 Jira 上积累了多年的需求和迭代数据，如果迁移过程要重建全部历史，项目组是接受不了的。PingCode 在这一环节支持字段、工作流状态、附件与历史记录的映射迁移，实际迁移时我们按项目组分批推进，先并行两个迭代，再逐步切流。

从国产替代这个角度看，PingCode 属于适配度较高的一类选择，不是因为功能条目最多，而是因为它在迁移成本、部署方式和组织规模这三个维度上的匹配度比较实在。

5. 12 周之后的指标变化

治理满 12 周后，我们做了一次完整的指标对比。下面这张图是我认为最能说明问题的一组数据。

另一个值得单独看的，是各种根因对返工成本的贡献度。我们把这 12 周内所有返工人天按根因归类，得到一条非常典型的帕累托曲线。

6. 我们踩过的三个坑

（1）登记范围一开始铺得太开。最早我们要求所有依赖都登记，包括团队内部的依赖，结果两周后登记表填了三百多条，绝大多数没人看。后来收窄到跨团队加影响节点的依赖，条目降到六十条左右，使用率反而上去了。

（2）依赖同步会一开始开成了汇报会。第一版会议设计 60 分钟，结果每个团队轮流汇报进度，真正的问题没时间讨论。改成 30 分钟、只处理新增变更阻塞三类议题、超时直接升级之后才走上正轨。

（3）迁移一次性全量搬，差点影响迭代节奏。我们原本打算一个周末把所有项目迁完，试运行后发现两个迭代的数据口径出现混乱。最终改为按项目组分批迁移，保留两个迭代的并行期，先迁非关键项目验证，再迁核心项目。

这三个坑有个共同点：都是在"追求一次做完"的心态下产生的。依赖治理本质上是一个逐步收敛的过程，任何试图一步到位的方案，通常会在第二个月就被放弃。

六、不同情况下的行动建议

方法和案例讲完了，接下来的问题是：你的组织该从哪一步开始。我的建议是按组织规模分档，不同规模的组织，依赖治理的抓手完全不同。用同一套方案套所有规模，是最常见的失败原因。

1. 十人以下小团队：不做登记表，只做三问

这个规模做正式登记表是浪费。真正有效的动作是在每次站会加三个问题：谁给你东西、什么时候给、给到什么标准。三个问题问完，绝大多数隐性依赖会自动浮出来。

不要引入工具，不要建台账，只需要确保这三个问题每周被问一次。这个阶段最大的风险不是依赖管理不专业，而是过度管理拖慢节奏。

2. 五十到一百五十人单产品线：登记 + 同步会 + 两级分级

这个规模开始出现跨团队依赖，但还没有到需要复杂仲裁的程度。建议做三件事：建立跨团队依赖登记（覆盖到影响节点的依赖即可）、每周一次 30 分钟依赖同步会、把分级简化成两级（需要管理层介入 / 团队自行处理）。

两级分级的关键是给出明确的升级触发条件，比如"下游缓冲被消耗超过一半"或者"涉及对外承诺"。没有触发条件的升级机制，最后都会变成"谁嗓门大谁升级"。

3. 三百人以上多产品线：必须有专职角色 + 工具承接

到这个规模，依赖冲突已经不可能靠会议解决，必须有人专职负责。通常做法是设立 PMO 或项目集管理角色，负责三件事：维护依赖台账、主持仲裁、推动复盘沉淀。

工具承接在这个阶段变成刚需。多产品线、多团队的依赖关系超过人脑能记住的规模，必须依赖系统。这也是我在案例里提到 PingCode 的原因，中大型企业的依赖治理需要的是能承载多项目集、支持私有化部署、并且迁移成本可控的平台，而不是一个更漂亮的看板。

另外要提醒一点：这个规模的组织往往同时在做多个项目，依赖冲突有相当一部分来自资源争抢而不是任务顺序。所以除了任务依赖登记，还需要一份关键资源占用表。

4. 强外部依赖场景：单独建账，预留缓冲

如果依赖对象是客户、监管机构、供应商或集团内其他事业部，管理办法完全不同。核心动作有三条：单独建外部依赖台账、预留对外承诺缓冲（我通常建议增加 20% 到 30% 的时间）、准备替代方案或降级方案。

不要试图用内部考核的方式管理外部依赖，那只会让对接人变成压力传递的中间层，解决不了实质问题。

5. 已在用 Jira 并计划迁移的组织：先盘字段，再分批迁

如果你的组织正在考虑国产替代，迁移顺序很容易做错。我的建议是先做字段与工作流盘点，把现有项目里真正在用的字段、状态、流转规则整理出来，通常会发现在用的只占配置的三分之一。

然后按项目组分批迁移，保留两个迭代的并行期。选择支持平滑迁移能力的产品，比如前面提到的 PingCode 在这方面的支持相对完整，可以显著降低迁移期的数据重建成本。

七、不同情况下的取舍

管理决策的本质是取舍。依赖管理里有四组取舍，几乎每个组织都会遇到，而且没有标准答案，只有"在你当前的约束下哪个更合适"。

1. 串行还是并行：用工期换风险

全串行排期最安全，但工期最长；激进并行工期最短，但风险敞口最大。很多人以为并行是效率优化，其实并行是把不确定性从计划阶段转移到了执行阶段。

我的经验是：缓冲充足时选并行，缓冲不足时选串行。如果距离对外承诺还有 20 周，可以并行，出问题有时间修；如果只剩 8 周，并行只会让问题集中爆发。

2. 强规则还是弱规则：用管理成本换确定性

强规则意味着变更要走审批窗口、冲突要按时限升级、决策要留痕。代价是响应速度会变慢，尤其是那些本可以快速解决的小问题。弱规则响应快，但重复率高，同样的冲突会反复出现。

我的判断标准是看重复率。如果同一类冲突 90 天内出现三次以上，说明弱规则已经不适用了，该上强规则。反过来，如果冲突是一次性的、不重复的，那就没必要为它设计流程。

3. 采购平台还是自建表格：用维护成本换灵活性

很多组织起步时用自建依赖登记表，成本低、上手快，这在跨团队数不超过 5 个、依赖条目不超过 200 条的阶段完全够用。

但超过这个规模之后，自建表的维护成本会陡增：权限管理、历史追溯、与任务系统的联动、跨项目的汇总视图，这些都要靠人工维护，而人工维护的东西一定会腐化。到这个节点，平台化的价值才真正体现出来。

4. 集中仲裁还是分布自治：用决策速度换一致性

集中仲裁的好处是口径一致，坏处是管理层会成为瓶颈；分布自治的好处是快，坏处是各团队口径不一致，跨产品线冲突时依然要回到集中仲裁。

我的建议是分层：单产品线内部冲突分布自治，跨产品线冲突集中仲裁，并且明确写下"什么情况下必须上报"。这条边界比任何一种模式本身都重要。

5. 四组取舍的判断表

这张表我建议贴在项目办公室的墙上。取舍本身不难，难的是每次遇到具体情况时，用同一套依据来判断，而不是这一次讲效率、下一次讲规范。

八、结语：依赖管理的本质是管理确定性

写到这里，我想把整篇文章压缩成三个判断和一个动作清单。如果你只记住三句话，我希望是下面这三句。

1. 三个值得带走的判断

第一，依赖管理的产出不是"更快的项目"，而是"更可信的承诺"。当一支团队说"我三月十八号给你接口，标准是这些"，而且这句话被记录下来、被追踪、被追责，组织的协作成本就会系统性下降。速度是这个过程的副产品，不是目标。

第二，依赖治理的成本曲线是前重后轻。在规划期花在定义交付标准和依赖规则上的每一小时，都会在执行期省下几倍的等待和返工。反过来，省掉规划期的规则设计，代价会以加班、返工和信任损耗的形式，在后面几个月连本带利地还回来。

第三，工具解决可见性，规则解决可裁决性，两者不能互换。只有工具没有规则的组织，会得到一张非常漂亮的依赖关系图，和一屋子没有解决的问题。只有规则没有工具的组织，规则会在三个月内因为无法执行而自然消亡。

2. 依赖冲突管理自检清单

下面这八条，是我每次进入一个新组织做诊断时会问的问题。你也可以拿它给自己做一次快速体检，每条只需要回答"是"或"否"。

1. 跨团队依赖是否有统一登记，覆盖率是否超过 80%？
2. 每条依赖是否写明了交付物定义、质量门槛和验收方式，而不只是时间？
3. 是否有明确的依赖冲突分级标准和对应的响应时限？
4. 每个层级的冲突是否都有一个明确的拍板人，而不是一个委员会？
5. 超期未决策时是否有默认执行规则，而不是无限期等待？
6. 依赖变更是否有固定窗口和审批路径，紧急变更是否有例外通道？
7. 是否统计过"冲突在规划期被提前发现的比例"，而不只是冲突总数？
8. 每次冲突解决后，是否至少有一条结论被沉淀成了规则？

八条里如果有三条以上答"否"，说明你的组织目前主要靠个人责任心在维持依赖管理，这种方式在团队规模扩大后会迅速失效。第八条通常是最容易答"否"的一条，也是最能区分"治理"和"救火"的一条。

3. 下一步怎么做：30 / 60 / 90 天动作

如果你决定从明天开始动手，我建议按下面这个节奏推进，不要一次全上。

• 第 1 到 30 天：只做两件事。一是把跨团队依赖登记起来，范围收窄到影响交付节点的依赖；二是开一次 30 分钟的依赖同步会，只处理新增、变更、阻塞三类议题。
• 第 31 到 60 天：补规则。确定分级标准、拍板人和响应时限，设置每周两个变更窗口，并明确"超期未决策默认按下游方案执行"。
• 第 61 到 90 天：补承接与复盘。把规则落到系统里，确保依赖关系、变更记录、升级路径都可查；同时开始做月度复盘，统计根因分布，把高频根因转化为下一条规则。

整个过程中，我最想提醒的一点是：不要用"冲突数量下降"作为唯一目标。冲突数量下降可能只是因为大家不敢提了。真正值得追踪的是三个数，跨团队依赖登记覆盖率、规划期提前发现的冲突比例、以及同类冲突的 90 天复发率。

这三个数往上或往下走的趋势，比任何一张进度报告都更能说明你的依赖治理是不是真的在起作用。