依赖冲突实操方法：研发团队提升任务依赖效率的流程优化方法与模板

去年 Q2，我接手了一个已经拖了三周的联调延期。复盘会上，四个团队的结论高度一致："沟通不到位。"我没急着认这个结论，而是把这两周的群聊记录、任务状态流转和发布日志全部导出，按小时对齐了一遍时间线。结果很扎心：三周里真正因为"代码没写完"造成的等待只有 4 天，剩下 11 天全部卡在两件事上，接口字段没定，和不知道对方什么时候能把测试环境给我。

这不是沟通频次的问题。开再多的会，也没法让一个还没定义的字段变得可用。这就是我想在这篇文章里讲清楚的事：依赖冲突在研发协作里的本质，不是"人不配合"，而是依赖的接口没有被定义到"可验证"的粒度。围绕这个判断，我会给出判断标准、流程优化方法、三张可直接套用的模板，以及我自己踩过的失败阶段和适用边界。

一、核心结论：依赖冲突是"接口不确定性"问题，不是"沟通不积极"问题

我先把结论摆在前面，因为它决定了后面所有动作的方向。如果你认可"依赖冲突=沟通问题"，你的解法一定是加会议、加群、加日报；如果你认可"依赖冲突=接口不确定性问题"，你的解法会变成定契约、定验收口径、定升级时限。这两条路走三年，结果完全不同。

1. 三个基本结论

结论一：依赖冲突的本质是"信息不确定性"，而不是"意愿缺失"。绝大多数工程师并不是不想配合，而是不知道"对方需要什么才算完成"。当"完成"的定义模糊时，双方都会默认自己已经完成了，直到联调那一刻才炸开。

结论二：依赖冲突的显性成本在联调期爆发，但根因发生在需求期。联调期发现的阻塞，80% 以上的根因在需求评审和接口设计阶段就已经埋下。等到联调期再去"协调"，本质上是在为三个月前的模糊买单。

结论三：依赖治理的目标不是"消除依赖"，而是"把依赖变成可验证的契约"。研发协作天然存在依赖，追求零依赖是幻想。真正可操作的目标是：让每一个依赖都有明确的交付物定义、明确的可用时间点、明确的验收标准，以及明确的超时升级路径。

2. 为什么"加强沟通"是错的解

我做过一个粗略的统计：在一个 80 人的研发组织里，如果每个跨团队依赖都靠"临时拉群对齐"来推进，一次对齐平均消耗 35-50 分钟的多人时间。一个迭代如果有 40 个跨团队依赖，光是"对齐"这一项，就要烧掉几十人天。而这些对齐里有相当一部分是重复的，同一件事，因为信息没有沉淀，每次都要重新讲一遍背景。

更麻烦的是，沟通频率提高会带来一个负面效果：它让"依赖已经被关注"变成一种虚假的安全感。大家都觉得"我们已经天天对齐了"，于是没有人去真正推动接口定义落地。

3. 衡量单位要从"沟通次数"换成"不确定时长"

我建议把依赖治理的核心指标，从"开了几次对齐会"换成"依赖处于不确定状态的总时长"。一个依赖从被识别出来，到它的接口定义被双方确认、交付时间被锁定，这段时间就是不确定时长。它才是真正吃掉迭代周期的东西。

二、真实场景：依赖冲突在研发流程里到底长什么样

抽象地讲"依赖冲突"很容易变成空话。我在实际项目里观察到，研发团队遇到的依赖冲突基本可以归到四种形态，每种形态的解法完全不同。搞清楚你面对的是哪一种，比套用任何方法论都重要。

1. 四种典型冲突形态

形态一：排期冲突。两个团队都需要同一个后端工程师在同一个迭代内提供接口，但这个人的容量只够做一份。这是资源依赖，解法是容量对齐，不是流程优化。

形态二：接口等待。A 团队需要 B 团队提供的接口才能开始联调，但 B 团队的接口定义还没冻结。这是最常见、也最容易治理的一种，解法是接口契约前置。

形态三：信息不同步。双方都以为对方知道某个变更（比如字段类型从 string 改成 int），但没有任何地方记录过这个变更。这是变更管理问题，解法是契约版本化。

形态四：节奏错位。A 团队双周迭代，B 团队月度发布，A 团队永远赶不上 B 团队的发布窗口。这是组织节奏问题，流程文档解决不了，需要调整发布节奏或引入 feature flag。

2. 冲突在迭代周期中的时间分布

我跟踪过我们团队连续 6 个迭代的阻塞数据，发现一个相当稳定的规律：依赖冲突的"发现时间"高度集中在迭代的后 40%，而"可解决时间"其实集中在迭代的前 30%。这是一个致命的时间错配，等你发现的时候，已经来不及了。

原因也不难理解。需求评审时，大家关注的是"做什么"，很少有人关注"我需要谁先给我什么"。接口设计时，大家关注的是"我这个接口怎么写"，很少有人关注"我的接口能不能让对方先跑起来"。于是依赖被识别的时间点，被系统性地推迟到了联调。

3. 为什么大多数团队只在联调期才发现

因为"能不能跑通"是研发流程里第一个真正强制性的验证点。在它之前，所有环节都可以用"我觉得没问题"糊过去。需求评审可以点头，技术方案评审可以点头，接口文档可以写个大概。只有联调会强制要求：字段对得上、数据能流通。

所以依赖治理的关键设计原则是：在联调之前，人为制造一个强制验证点。这个验证点不需要多复杂，可能就是一份双方签字确认的接口字段表，或者一个 mock 接口能返回真实结构的样例数据。它的作用不是技术上的，而是流程上的，它把"确定性"提前到了成本最低的时间点。

三、拆解七个常见误区

在讲方法之前，我必须先把误区讲透。因为我见过太多团队，方法本身没问题，但被这几个误区带偏，最后得出"依赖治理没用"的结论。

1. 把协作依赖和技术依赖混为一谈

这是一个搜索场景里非常普遍的混淆。搜"依赖冲突"，出来的大量结果是 Maven、Gradle、npm 的包版本冲突解决。那是技术依赖冲突，解法是依赖树分析、版本仲裁、排除传递依赖。

而本文讨论的是协作依赖冲突：任务 A 需要任务 B 的产出才能继续。两者的共同点只有"依赖"这两个字，解法完全不相干。如果你拿 Maven 的思路去管跨团队协作，或者拿排期会的思路去解包冲突，都会非常挫败。写流程文档时第一件事就是把语境界定清楚。

2. 认为买了工具就能解决

我见过团队上线项目管理平台后，第一件事就是把所有任务都加上"前置任务"字段，然后就等着效率提升。结果三个月后，那个字段的填写率不到 30%，而且填的内容大量失真。

工具是放大器，不是发动机。它能放大一个已经成立的流程，但不能替你建立流程。顺序必须是：先有依赖登记的最小规则，再用工具承载；先有升级机制的责任约定，再用工具做超时提醒。

3. 用提高沟通频率替代降低不确定性

"我们每天站会都同步依赖"，这句话听起来很勤奋，但如果站会只是让大家轮流说"我还在等 XX"，那它只是把等待可视化，没有减少等待。真正有效的站会依赖环节，只问三个问题：这个依赖的接口定义冻结了吗？谁负责？什么时候能给？

4. 依赖台账做成全量登记

这是最常见的自毁式操作。我第一版依赖台账就犯了这个错误：要求每个任务都登记它的前置任务。结果第一个迭代登记了 380 条依赖，其中 340 条是"我自己的上一个任务"，真正跨团队的只有 40 条。

维护成本高到没人愿意维护，三个星期后台账彻底死掉。依赖台账只登记跨团队、跨系统、跨发布窗口的依赖，团队内部的自然顺序不需要登记。

5. 对所有任务都用关键路径管理

关键路径法（CPM）确实好用，但它的前提是任务网络足够复杂、依赖足够刚性。对一个只有 5 个人的小团队，或者一个需求高度独立的模块组，套关键路径会带来大量的无效计算和会议。

我的经验是：当一个迭代内的跨团队依赖少于 5 个时，不需要关键路径，用一张表就够了。超过 15 个，才值得引入依赖图和自动化的关键路径识别。

6. 把并行化当万能解药

"我们要提高并行度"听起来非常正确，但并行度有一个隐形的天花板：团队的认知负载和沟通带宽。当一个人同时参与 3 条以上的并行依赖链，他的切换成本会急剧上升。

我观察到的经验值是：一个工程师在一个迭代内同时处理的跨团队依赖接口，保持在 2-3 个以内是健康区间，超过 4 个，交付质量会明显下降，返工率上升。

7. 把依赖冲突归因到人

这一条不是流程问题，而是管理问题。一旦依赖冲突被定性为"某人不配合"，整个团队会进入防御状态，信息开始隐藏，依赖台账会变成"甩锅证据"。依赖冲突的默认归因应该是"接口定义不充分"，而不是"人不给力"。前者可以修，后者只能吵。

四、我的判断逻辑：三层过滤，决定要不要治、治到什么程度

不是所有团队都需要做依赖治理。我见过 6 个人的小团队被要求填依赖台账，也见过 400 人的组织完全不做依赖管理而靠人肉协调。判断是否需要，我习惯用三层过滤。

1. 第一层：依赖密度

依赖密度 = 一个迭代内跨团队依赖数 ÷ 该迭代的有效任务数。这个比值最能反映协作复杂度。

• 低于 10%：依赖是偶发事件，靠个人沟通处理即可，上流程是浪费。
• 10%-25%：进入需要轻量流程的区间，一张依赖登记表加每周一次对齐就够。
• 高于 25%：依赖已经成为主要风险源，必须建立完整机制，包括契约前置和升级路径。

2. 第二层：依赖确定性

同样数量的依赖，确定性不同，成本差十倍。我判断确定性只看一个问题：这个依赖的交付物，能不能用一句可验证的话描述清楚？

"B 团队提供订单查询接口"，这是低确定性。"B 团队在 6 月 12 日前提供 GET /orders/{id}，返回包含 orderStatus、payTime 两个字段，且提供可返回真实结构的 mock 服务"，这是高确定性。低确定性的依赖数量一旦超过 8 个，迭代几乎必然延期。

3. 第三层：依赖延迟成本

延迟成本 = 依赖每延后一天，下游产生的实际损失。这个损失可以是人力空转、发布窗口错过、客户 SLA 违约，也可以是合同罚金。

延迟成本高且确定性低的依赖，是必须优先治理的对象。延迟成本低但确定性低的依赖，可以先容忍，但必须登记在案，因为它们的风险会累积。

4. 四象限与治理强度对应关系

把"依赖密度"和"依赖延迟成本"放在两个轴上，可以得到四类团队，治理强度完全不同。这也是我认为比"所有团队都要做依赖治理"更诚实的判断方式。

五、一次 80 人团队的依赖治理实测（含失败阶段）

下面这段是本文最具体的一部分，也是我最想讲的部分。因为它包含一次彻底的失败。需要先说明数据来源：这是我参与的一次内部前后对比，团队规模 80 人左右，分 4 个研发小组共用一个中台，数据来自项目管理平台看板导出后的人工脱敏统计，属于单一样本，不能外推为行业基准。

1. 背景与基线

团队情况：80 人，4 个研发小组（交易组、用户组、中台组、数据组），双周迭代，每个迭代约 120 个有效任务，跨团队依赖平均每个迭代 34 个，依赖密度约 28%。

治理前的基线数据：单迭代平均阻塞发生 41 次，平均单次阻塞时长 2.7 天，联调阶段返工率 22%，迭代按期交付率 61%。这几个数字我们连续记录了 4 个迭代，波动不大，可以作为基线。

2. 第一阶段：只做登记，失败

第一阶段我们做的事情非常"标准"：建一张依赖登记表，要求每个小组在迭代计划会上登记所有跨团队依赖，每天站会同步状态。执行了 3 个迭代。

结果比预期糟糕。登记率从第 1 个迭代的 76% 下降到第 3 个迭代的 31%，而且登记的内容越来越敷衍，"依赖中台组提供接口"这种无法验证的描述占了 40% 以上。更关键的是，阻塞次数只从 41 次降到 37 次，几乎没有实质改善。

复盘时我们找到了三个原因。第一，登记表由各组的项目经理填写，而项目经理并不真正知道技术依赖的细节。第二，登记表只记录"谁依赖谁"，没有记录"依赖什么具体产出"。第三，登记这件事没有和任何既有的流程绑定，它成了一个额外的动作。

3. 第二阶段：加"契约前置"，数据开始变

第二阶段我们只改了两件事。第一，把登记责任人从项目经理改成依赖的接收方（下游），因为只有下游最清楚自己需要什么。第二，把"依赖描述"从自由文本改成固定字段：交付物名称、接口路径或产物标识、关键字段、承诺可用日期、验收方式。

同时增加一个硬性动作：任何跨团队依赖必须在被依赖方的迭代计划中体现为一个具体任务，否则视为未确认。这解决了"答应了但没排期"的问题。

执行 4 个迭代后，数据开始出现变化：登记率稳定在 84% 左右，阻塞次数降到 24 次，平均阻塞时长降到 1.6 天，联调返工率降到 13%。迭代按期交付率提升到 74%。这个阶段没有引入任何新工具，纯粹是字段和责任人的调整。

4. 第三阶段：接入项目管理平台后的变化

第三阶段我们把依赖关系从表格搬到了项目管理平台里。我们当时评估了几个选项，最终选择了 PingCode，主要原因是它支持在中大型组织里把任务依赖、阻塞标记和迭代看板放在同一套数据模型里，避免"表格和任务系统两张皮"。

对我们这种 100 人上下、需要跨 4 个小组协调的场景，几个能力比较关键：任务之间的依赖关系可以直接在迭代视图中呈现，阻塞状态可以标记并统计时长，而不需要人工填表。这直接解决了第一阶段"登记是额外动作"的问题，登记变成了任务编辑的一部分。

另外两点也值得提。一是它支持私有化部署，我们的代码和需求数据合规要求不允许出内网，这一点是硬门槛。二是它提供了从 Jira 迁移过来的路径，我们历史上有一部分项目数据在 Jira 里，需要平滑迁移而不是重新录一遍。

需要说明的是，我不认为换平台本身带来了效率提升。平台的价值是把已经成立的流程从"靠人记"变成"靠系统记"。如果第二阶段没做，直接上平台，结果大概率还是第一阶段的样子。

5. 数据对比与我的解读

我的解读有三点。第一，单据化登记几乎不产生价值，第一阶段三个迭代换来的改善在噪声范围内。第二，真正带来拐点的是"契约字段化 + 责任方转移"，也就是第二阶段，它不依赖任何工具。第三，平台阶段带来的是稳定性收益：登记率从 84% 到 94%，阻塞时长从 1.6 天到 0.9 天，这些提升主要来自"不会因为某个人休假就断档"。

顺便说一个反直觉的观察：第三阶段之后，我们对"依赖对齐会"的需求反而下降了。因为大量原本需要开会确认的信息，已经在依赖记录里写清楚了。会议数量从每周 3 次跨组对齐降到每周 1 次。

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

同一套方法，在不同规模、不同组织形态、不同迭代阶段里的落地方式差别很大。我按三个维度分别给建议，你可以直接对号入座。

1. 按团队规模

• 5-10 人：不要建台账。用一条群规替代，"任何需要别人配合的事，在群里写清楚：需要什么、什么时候要、验收标准是什么"。做到这一条，效果超过大多数流程。
• 10-30 人：建一张最简单的跨团队依赖表，字段不超过 6 个，每周迭代计划会更新一次。责任人写下游。不要引入自动化提醒，靠人盯。
• 30-100 人：建立完整的契约前置动作，把依赖变成带字段的登记项。开始考虑把依赖关系放进项目管理平台，而不是留在表格里。
• 100 人以上：必须体系化。依赖类型分类、升级路径分级、契约变更版本化、阻塞时长统计口径统一，这四件事缺一不可。这个规模下靠人盯必然漏。

2. 按组织形态

单团队多模块：依赖主要发生在模块边界，重点是接口契约，而不是排期。建议在技术方案评审环节强制输出接口字段表。

多团队单产品：依赖主要发生在迭代节奏和发布窗口，重点是排期对齐和容量预留。建议设立跨团队的迭代对齐节奏，并把依赖确认作为进入开发的前置条件。

多产品共享中台：中台团队是最容易被依赖方拖垮的角色。我的建议是给中台团队预留固定的"需求响应配额"，比如每个迭代容量的 20% 专门用于响应其他团队的接口需求，超出配额走升舱流程。

3. 按迭代阶段

需求期：在需求评审时增加一个问题，"这件事需要谁先给我什么东西？"把答案写进需求描述。这一步做 5 分钟，能省后面 5 天。

开发期：依赖契约必须在开发启动前冻结，且被依赖方的任务必须已经进入其迭代计划。没进入计划的依赖，视为未承诺。

联调期：只处理偏差，不处理定义。如果联调期还在争论字段含义，说明契约阶段失败了，应该记录下来作为下一轮改进点，而不是当场开会解决。

发布期：确认发布顺序和回滚方案，特别是当多个团队共享同一个发布窗口时，明确谁先发、谁后发、谁负责回滚。

七、不同情况下的取舍

依赖治理本质上是一组取舍，不是一组最佳实践。我把最常被问到的四组取舍讲清楚，帮你在做决策时知道自己在放弃什么。

1. 流程 vs 工具

我的判断顺序非常明确：先验证流程在手工状态下能不能跑通，再考虑用工具承载。判断标准是：手工状态下的登记率能不能稳定在 70% 以上，且字段质量过得去。如果能，工具会把它推到 90% 以上；如果不能，工具只会让你更快地发现流程不成立，代价是几个月的迁移成本和团队信任。

2. 集中管控 vs 团队自治

集中管控的好处是口径统一、跨团队可比；坏处是响应慢、容易被绕过。团队自治的好处是贴合实际；坏处是数据无法横向对比，组织级看不到全貌。

我的建议是分层：字段定义、升级时限、阻塞判定标准由组织统一；具体怎么开会、谁登记、什么时候更新，由各团队自定。这样既有可比性，又不至于卡死。

3. 并行度 vs 认知负载

前面提到过，一个人同时处理的跨团队依赖超过 4 个，返工率明显上升。所以当你想通过"提高并行度"来压缩周期时，先算一笔账：并行带来的周期压缩，能不能覆盖切换成本和返工成本。

我的经验值是：在接口定义充分的前提下，适度并行（每人 2-3 条依赖链）通常能压缩 15%-25% 的周期；在接口定义不充分的前提下，提高并行度往往会让周期变长。

4. 登记粒度 vs 维护成本

粒度越细，信息越准确，但维护成本越高，而且存在一个临界点：超过临界点后，登记者会开始敷衍，数据质量反而下降。前面那张图已经说明了这一点，从 40 条扩到 380 条，准确率从 88% 掉到 34%。

我的取舍标准是：只登记"如果不同步就会导致返工"的依赖。任何"同步了对齐一下更好、不同步也没什么"的依赖，都不值得进入台账。

八、可直接套用的三张模板

下面三张模板我用了两年多，改过若干版本。我把字段设计的理由一起写出来，因为字段设计才是模板真正的价值所在，脱离理由照抄字段往往会失效。

1. 依赖登记表

核心设计原则有三条。第一，责任人写"下游"，只有接收方最清楚自己要什么。第二，交付物必须可验证，必须能回答"怎么判断它给了我"这个问题。第三，必须有一个承诺日期，不允许留空。

如果你打算把依赖契约落成配置文件，下面这个 YAML 结构可以直接用。它比表格更适合放进代码仓库，跟接口定义一起做版本管理。

dependency:
id: DEP-2406-013

consumer:

team: trade

owner: zhang.wei

needed_by: 2026-06-18

provider:

team: platform

owner: li.na

committed_by: 2026-06-12

type: interface            # interface | data | env | decision | release_window

deliverable:

kind: http_api

path: /api/v1/orders/{orderId}

fields_required:

orderStatus          # enum: CREATED/PAID/SHIPPED/CLOSED

payTime              # unix timestamp, seconds

refundableAmount     # decimal(18,2), 单位元

mock_required: true      # 必须提供可返回真实结构的 mock

acceptance:

mock_callable: true

field_contract_reviewed: true

integration_case_passed: true

contract_version: v3       # 契约变更必须递增版本

escalation:

after_hours: 24

escalate_to: platform_lead

next_after_hours: 48

next_escalate_to: cto_office

2. 联调前 checklist

这张清单的作用不是"检查"，而是把联调期才有可能暴露的问题提前到开发中段。我要求它在联调开始前 3 个工作日完成，任一项不通过就不进入联调。

1. 上游提供的 mock 服务可以调用，且返回结构与契约一致（字段名、类型、可空性全部核对）。
2. 契约中的枚举值已经确定，不存在"先按 string 处理，后面再改"这类临时方案。
3. 异常场景已定义：超时、限流、空数据、字段缺失时下游如何处理。
4. 测试环境双方都可以访问，账号和权限已开通，不依赖某一个人手动开启。
5. 联调数据准备就绪，不需要在联调当天临时造数据。
6. 双方各有一名明确的技术对接人，且已在依赖记录中登记。
7. 契约版本号已确认，任何一方后续变更需要通知对方并递增版本。

3. 阻塞升级单

升级单的核心不是"单"，而是时限和责任人。我采用的规则是三级升级：阻塞超过 24 小时升级到双方组长，超过 48 小时升级到研发负责人，超过 72 小时升级到产品与业务负责人联合决策。

{
"blockId": "BLK-2406-007",

"dependencyId": "DEP-2406-013",

"blockedSince": "2026-06-12T09:30:00+08:00",

"blockReason": "contract_field_change",

"impact": {

"blockedTasks": 4,

"blockedPeopleDays": 6.5,

"affectsReleaseWindow": true

},

"escalation": [

{ "afterHours": 24, "notify": ["trade_lead", "platform_lead"], "action": "双方组长确认新交付时间" },
{ "afterHours": 48, "notify": ["rd_director"], "action": "决定是否调整迭代范围或插入资源" },
{ "afterHours": 72, "notify": ["product_lead", "business_owner"], "action": "决定是否降级交付或推迟发布" }
],
"resolution": {

"closedAt": "2026-06-13T15:10:00+08:00",

"actualBlockedHours": 29.6,

"rootCause": "字段 refundableAmount 精度未在契约中约定",

"preventiveAction": "接口契约模板新增精度与单位必填项"

}

}

最后那个 preventiveAction 字段是我最看重的一项。如果一张升级单只有"解决了"，没有"下次怎么避免"，那它只是一次救火记录。我们后来把这类预防动作汇总到迭代复盘里，两年下来沉淀了 40 多条契约模板的必填项，这才是组织真正的资产。

九、落地的四个坑与纠偏信号

流程设计得很漂亮，落地死掉的原因通常是固定的那几个。我把自己踩过的四个坑和对应的纠偏信号整理出来，你可以提前预警。

1. 台账没人维护

纠偏信号：连续两个迭代的登记率下降超过 10 个百分点，或者出现大量"依赖中台组提供接口"这类无法验证的描述。

应对动作：不要靠催，要靠绑定。把依赖登记绑定在迭代计划会的固定议程里，而不是作为会后的额外动作。另外检查责任人是不是写成了上游，如果责任人是上游，上游没有动力去描述"对方需要什么"。

2. 升级机制形同虚设

纠偏信号：阻塞超过 48 小时但没有产生任何升级记录，或者升级后没有任何决策产出。

应对动作：升级机制失效通常有两个原因：一是没有明确"超过多久自动升级"，全靠人判断；二是升级后管理者不决策，只回复"我知道了"。解决办法是把时限写成硬规则，并明确每一级必须产出一个决策：要么调整范围，要么追加资源，要么接受延期。不允许"知道了"这种空响应。

3. 契约变更没有版本

纠偏信号：联调期发现字段含义与最初约定不一致，但追溯不到是谁在什么时候改的。

应对动作：契约必须带版本号，任何变更递增版本并通知下游。变更通知不能靠"我在群里说过了"，必须落在依赖记录里。这是我见过最容易造成返工的一类问题，在第五节的帕累托图里，它占了残留阻塞的 31%。

4. 工具依赖过重

纠偏信号：团队开始讨论"怎么在系统里操作"而不是"依赖什么时候能解决"，或者有人反馈填依赖的时间超过做需求的时间。

应对动作：回退到最小可用字段集。我的建议是永远保留一个"降级方案"，如果平台出问题或者字段太复杂，团队可以用一张固定格式的表格继续工作，不中断流程。

十、效果怎么衡量：指标、口径与适用边界

最后讲衡量。这一节我特别想强调口径，因为我在不止一个团队见过同一套流程因为口径不同，得出完全相反的结论。

1. 五个可观察指标

• 阻塞发生次数：一个迭代内进入"已阻塞"状态的依赖次数，按次计，不按任务计。
• 平均阻塞时长：从标记阻塞到解除阻塞的小时数均值，建议同时看中位数，因为长尾会拉高均值。
• 依赖契约按时确认率：契约在承诺日期前被双方确认的比例，反映流程的前置能力。
• 联调返工率：因依赖问题导致的返工任务数 ÷ 联调任务总数。
• 迭代按期交付率：最终结果指标，但要注意它受需求变更影响很大，必须和"需求变更次数"一起看。

2. 口径统一的三条规则

规则一：阻塞的起算时间必须统一。是"下游发现无法继续"的那一刻，还是"依赖承诺日期已过"的那一刻？我们最终选了后者，因为它更客观、更容易系统自动判定。

规则二：阻塞时长是否扣除非工作时间要统一。是算自然时长还是工作时长？跨周末的阻塞会显著影响结果。我们选了工作时长，因为更贴近人力损失。

规则三：样本口径要固定。统计所有依赖还是只统计跨团队依赖？如果中途换了口径，数据就不能前后对比。我们把口径写进了流程文档的第一页。

3. 什么团队不适合做依赖治理

我必须把这一条讲清楚，因为不是所有团队都需要它。

第一，5 人以下团队。成员之间信息完全透明，上流程只会增加负担。结构化表达比流程更重要。

第二，需求高度独立、几乎不发生跨团队协作的团队。如果依赖密度低于 10% 且延迟成本低，依赖治理的收益接近于零。

第三，处在极早期探索阶段的产品团队。此时需求方向本身每天都在变，把依赖契约冻结反而会阻碍探索。这个阶段应该接受一定程度的混乱，把精力放在验证方向上。

第四，团队信任度已经严重受损的组织。依赖台账在这种环境里会被当成追责工具，加剧防御。这种时候要先解决信任问题，或者由更有权威的角色引入，并明确声明"台账不用于绩效评估"。

结语：从"管依赖"到"管预期"

写了这么多，我最想留下的其实是一个视角转换。依赖治理的终点不是一张完美的台账，而是团队之间对"什么时候交付什么"形成了稳定预期。台账、模板、升级机制都只是达成这个预期的手段。

回到开头那个拖了三周的联调延期。如果我们当时做的不是加会，而是把"接口字段定义"提前到需求评审后一周内完成，那三周的等待大概率会压缩到一周以内。这不是沟通能力的问题，是流程设计的问题，把不确定性暴露在成本最低的时间点，是所有依赖治理方法的共同内核。

如果你准备动手，我建议下一步只做三件事，不要贪多。先统计一个迭代的跨团队依赖数量和平均阻塞时长，得到你自己的基线；再把依赖登记的责任人改成下游，字段固定为五个必填项；最后给阻塞设一个 24 小时的自动升级时限。跑两个迭代，拿着前后数据再决定要不要引入平台、要不要扩大范围。

依赖冲突不会消失，它只会换一种形式出现。你能做的，是让它每次出现时的解决成本，比上一次更低。