依赖冲突流程与规范：实施团队任务依赖协同管理关键指标

我把过去三年经手的十余个跨团队交付项目翻了一遍台账，发现一个不太体面的规律：在延期超过两周的项目里，复盘会上被写进"根因"一栏的，八成是"依赖方交付晚"。但真正把依赖流水拉出来看，其中超过一半的问题根本不是交付晚，而是这条依赖从第一天起就没有被登记过，它只存在于某个人脑子里的待办清单上。等到它变成阻塞项时，留给双方的时间已经不足以补救。这篇文章不复述依赖管理的教科书定义，我只讲两件事：一套我和团队实际跑了两年的依赖冲突流程规范，以及一组我用来判断"这套流程到底有没有起作用"的关键指标。

读完你应该能判断，你的团队现在缺的到底是流程、指标，还是只是一个大家都愿意看的依赖台账。

一、先给结论：依赖冲突的可管理部分，八成在流程而不在沟通

在展开之前，我要先把四个结论放在前面。这四条是我从踩坑里换来的，不是从方法论书里抄的，你可以先看看认不认同，再决定要不要读后面的推演过程。

第一，依赖冲突里真正能靠"多沟通"解决的部分，不超过两成。剩下的八成是结构性的：谁在什么时候向谁承诺了什么、承诺被记录在哪里、变更后谁会被通知、超期后谁来仲裁。这些问题沟通一百次也没用，因为它们缺的是记录和规则，不是态度。

第二，依赖管理的最小可行单元只有三件事：登记、承诺、预警。把这三件事做扎实，一个二十人的团队就能消掉大部分低级冲突。反过来，如果这三件事没做，上再重的工具、开再多的同步会，效果都会在两个月内衰减回原点。

第三，指标的唯一正当用途是暴露问题，一旦用于考核个人，它会在一到两个迭代内彻底失真。我见过团队把"依赖交付准时率"挂到个人绩效上，结果是依赖被拆成极小的碎片、承诺日期被故意写宽、真正的硬依赖被藏到线下沟通里。数据好看了，交付并没有变快。

第四，流程的重量必须随团队规模和外部依赖比例递增，而不是一次性拉满。十人以下的团队用一张共享表格足够，一百人以上的多团队协同才需要平台化的登记、流转和统计能力。用错重量的代价，比不做流程还大。

二、三个真实场景：依赖是怎么一步步失控的

抽象讲依赖冲突没什么意思，我讲三个我亲自处理过的场景。它们分别对应流程缺失、承诺缺失和仲裁缺失，也是我认为最典型的三类失控路径。

1. 场景一：一条没登记的接口依赖，拖垮了整个上线窗口

某个季度，我们给一家制造企业做系统替换。前端团队按计划在第七周开始联调，结果发现后端提供的一个主数据接口字段结构和他们预想的完全不同。这不是后端做错了，需求文档里写的就是后端那个版本。问题在于，前端团队从没把"需要后端提供主数据接口"当成一条依赖登记下来，他们默认这是"本来就该有的东西"。

这条依赖被发现时是第七周周三，上线窗口在第九周周一。后端改字段结构要三天，前端适配要两天，测试回归要两天，全部串起来刚好卡死。最后我们做了一次极不体面的取舍：砍掉两个非核心报表功能保住上线。事后复盘，这条依赖如果在前三周的依赖评审里被登记，成本几乎为零。

这类问题的本质是：团队把"我要用到别人的产出"当成了理所当然，而不是当成一条需要被管理的关系。

2. 场景二：依赖被"承诺"了，但没有承诺日期

第二个场景更隐蔽。依赖被登记了，双方也都口头认可了，但登记表上没有"承诺交付日期"这一栏。于是这条依赖在实际执行中就变成了一个没有锚点的悬空项。需求方以为对方会在第四周给，供给方觉得只要在本迭代内给就行。等到第四周结束，需求方开始催，供给方说"我这周还有别的事"。

这种冲突最消耗情绪，因为双方都觉得自己有理。需求方觉得自己明明提前说了，供给方觉得自己从来没答应过具体哪天。真正的问题在于，没有日期的承诺等于没有承诺。依赖登记表上如果没有"承诺交付日期"这个必填字段，那么登记这件事只完成了一半。

3. 场景三：冲突升级到两个老板拍板，赢的一方也不是对的

第三个场景发生在两个部门之间。两个团队都要用同一个技术团队的资源，时间上无法同时满足。冲突在团队层面僵持了一周，最后升级到两个部门负责人那里。结果是嗓门大、汇报层级高的那个部门拿到了资源。但事后看，被牺牲掉的那个需求其实优先级更高，只是它的负责人不擅长在会议上争取。

这就是仲裁机制缺失的典型后果：冲突不是按规则解决的，而是按权力和表达力解决的。一个健康的依赖流程必须提前规定，当两个依赖在时间或资源上冲突时，依据什么排序、由谁拍板、多久之内必须给出结论。

三、五个常见误区：为什么你越催，依赖越乱

在给出流程和指标之前，我必须先拆掉几个流行但有害的做法。这些误区我都在真实团队里见过，有些我自己也犯过。

1. 误区一：把依赖冲突当成沟通问题

这是最根深蒂固的一个。项目一延期，管理者的第一反应往往是"要加强沟通""要建立信任""要多对齐"。这些说法没错，但它们是结果，不是手段。信任是靠一次次按时兑现承诺积累起来的，而按时兑现需要承诺被记录、被跟踪、被预警。不从流程入手谈信任，就是在要求别人凭自觉。

2. 误区二：用每日站会拉通所有依赖

我见过一个团队，每天站会二十分钟里有一半时间在同步跨团队依赖。表面上看信息很透明，实际上有两个致命问题：第一，站会是同步场景，依赖方常常不在场，说了等于没说；第二，依赖信息每天重复播报，但没有任何状态变更的强制动作，说完就过去了。

更糟的是，这种做法的边际收益衰减得极快。前两周大家还认真听，一个月后就变成了背景噪音。我用过的一个替代方案是：站会只讲"昨天新增或状态变更的依赖"，定期开一次专门的依赖评审会处理存量，效率反而更高。

3. 误区三：追求一次性把所有依赖识别完

有些团队在项目启动时组织一场大型的依赖梳理会，试图把整个项目的依赖一次性列全。这个目标很好，但几乎不可能达成。因为真正的依赖往往在设计和实现阶段才浮现，你以为两个模块没关系，做到一半才发现它们共享同一份配置。

更现实的做法是分段识别、持续补充：需求阶段识别业务级依赖，设计阶段识别接口和数据依赖，开发阶段识别资源和时序依赖。每个阶段都把新识别的依赖登记进台账，而不是指望一次会议解决全部。

4. 误区四：把依赖准时率做成个人KPI

这是我踩过的最深的坑。有一年我们把"依赖交付准时率"纳入团队考核，结果三个月后数据确实好看了，从 58% 涨到了 82%。但同期项目的整体延期率并没有下降，反而略有上升。原因很简单：大家学会了规避。承诺日期往后写、把大依赖拆成很多个能按时完成的小碎片、真正的硬依赖转到线下口头协商。

指标一旦和考核挂钩，就会从"测量工具"变成"表演工具"。我后来把这条指标从考核里摘出来，只在复盘会上公开讨论，数据反而更真实。

5. 误区五：先买工具，再定规则

顺序错了，结果一定不对。工具是规则的载体，不是规则的来源。如果团队连"依赖登记表要填哪几个字段"都没想清楚，买了再好的平台也只能建出一堆没人维护的空看板。

我推荐的顺序是：先用最轻的方式（共享表格或平台自带的简单字段）把规则跑通两个月，确认字段设计和流转节点是合理的，再迁移到正式平台并做自动化。规则先于工具，工具再反过来固化规则。这个顺序调换，成功率相差很大。

四、判断逻辑：依赖的四类分型与三类隐性成本

要把依赖管起来，第一步不是建流程，而是先能分清你面对的是哪一类依赖。不同类型的依赖，处理方式和成本结构完全不同。我用的是一套四分类法，不追求学术严谨，只追求现场好用。

1. 四类依赖的识别与判断标准

资源依赖指的是双方争抢同一份稀缺资源，比如同一个技术专家、同一套测试环境、同一个发布窗口。判断特征很明显：一旦某一方占用了，另一方就只能等。这类依赖的核心管理动作是"预约与排他性确认"。

信息依赖指的是我的工作必须等你的某个产出或结论才能开始，比如等需求确认、等接口文档、等数据口径对齐。它的特点是看起来不需要别人"干活"，但实际上决定了你能不能开工。这类依赖最容易被低估，因为供给方往往觉得"我只是给你个答复而已"。

时序依赖指的是顺序必须先后的关系，比如必须先扩容再压测、必须先数据迁移再切流量。它本身不是冲突，但当上游延期时，下游没有任何并行余地。这类依赖的管理重点是"缓冲设计与关键路径识别"。

决策依赖指的是要等某个决策才能推进，比如等架构选型结论、等预算审批、等商务条款确认。它的最大风险是决策没有明确的责任人和截止时间，于是无限期挂着。

2. 三类隐性成本，往往比延期本身更贵

（1）等待浪费。这是最容易被看见但仍被低估的一项。一个下游工程师因为依赖未到位而空转一天，损失的不只是一天人力，还包括他的上下文切换成本，他下次回到这个任务时，重新理解的时间可能又是半天。

（2）返工成本。当依赖的交付物边界没对齐时，下游按自己的理解先做了，等上游交付后才发现对不上，只能推倒重来。这类返工最伤士气，因为它让人觉得"白干了"。

（3）信任损耗。这一项无法直接计入工时，但影响最深远。一次两次的依赖失约，会让团队在后续协作中本能地加缓冲、留后手、不轻易承诺，整个组织的协作效率会缓慢下滑。信任损耗是不可逆的，而且它会通过"防御性排期"的形式，把成本摊到所有未来项目上。

3. 判断一条依赖是否值得纳入正式流程的三个条件

不是所有依赖都值得走正式流程，判断成本会超过收益。我用三个条件筛选：第一，它是否影响关键路径或上线节点；第二，供需双方的团队边界是否清晰（跨团队、跨部门、跨供应商）；第三，它是否可能发生变更。三条中满足两条以上，就纳入正式登记。只满足一条甚至零条的依赖，留在团队内部口头协调即可，不必让流程变重。

五、流程规范：从识别到闭环的五段式

接下来是我实际在用的流程框架。它不复杂，五个环节，每个环节都有明确的输入、输出和责任人。我把它跑在了一个四十多人的多团队协同项目上，两年下来经过三次简化，这已经是砍到不能再砍的版本。

1. 第一段：依赖识别与登记

登记的核心不是"记下来"，而是"记全"。我用一张依赖台账，字段不多，但每一个字段都有明确的填写规则。字段太少会导致后续无法跟踪，太多则没人愿意填。

依赖台账字段设计（最小可用版）
dependency_id 依赖编号，格式 DEP-YYYYMM-序号

from_team 需求方团队

to_team 供给方团队

dep_type 类型：资源 / 信息 / 时序 / 决策

description 一句话说明需要对方交付什么

acceptance 验收标准，必须是可验证的（如"接口返回字段完整"）

impact_path 是否在关键路径上：是 / 否

promised_date 承诺交付日期（必填，不允许为空）

buffer_days 下游预留缓冲天数

status 状态：已识别 / 已承诺 / 进行中 / 已交付 / 已关闭 / 已取消

owner 责任人（供需双方各一名，缺一不可）

change_log 变更记录，含变更时间、变更内容、影响评估

这里有两个字段我要特别强调。第一个是 promised_date，它必须由供给方填写，而不是需求方代为填。这个动作本身就是一种承诺仪式，能显著降低后续扯皮。第二个是 owner，供需双方各有一名责任人，缺一不可。我见过太多台账只有需求方联系人，结果供给方根本不知道这条依赖被登记了。

还有一个实操细节：登记动作必须发生在时间点上，而不是状态上。也就是说，不能等到"需求评审通过后"再登记，而是评审会上每发现一条依赖就当场登记。这个动作的一致性，决定了台账的可信度。

2. 第二段：依赖评估与排期

登记完成不等于可以执行。评估环节要回答三个问题：这条依赖对上游意味着多少工作量？承诺日期是否留了合理缓冲？如果延期，下游的应急方案是什么？

我用的一个简单规则是：承诺日期必须包含一个显式的缓冲，且这个缓冲要在台账里写出来。比如理论上三天能完成，承诺日期就写第四天，并在 buffer_days 里填 1。这样做的意义不是给拖延留空间，而是让延期被提前消化，而不是传递到下游。凡是 buffer_days 填 0 的依赖，我会要求责任人给出理由。

另一个规则是排序。当多条依赖争抢同一资源时，需要有明确的排序依据。我通常用四个维度打分：是否影响上线节点、是否有替代方案、下游团队规模、延期后的不可逆程度。打分结果不需要精确，它的价值在于把"谁嗓门大谁先"变成"依据什么排序"。

3. 第三段：依赖交付跟踪与预警

跟踪环节的核心是状态变更驱动，而不是时间驱动。不要每天问一遍"你那事怎么样了"，而是定义清楚什么情况下状态必须更新、什么情况下必须预警。我用的预警规则有三条：

• 临近预警：距离承诺日期还剩两天且状态仍为"进行中"，系统或台账负责人自动提醒双方责任人。
• 超期预警：超过承诺日期一天仍为"进行中"，自动升级到双方团队负责人，并要求给出新的承诺日期和原因说明。
• 变更预警：任何影响交付内容、时间或验收标准的变更，供给方必须主动更新 change_log 并通知需求方，否则视为流程违规。

这三条规则的关键在于自动化。如果靠人肉提醒，一周之后就会失效。在规模较大的项目里，这恰恰是平台化工具最该发挥作用的地方，把规则写进状态流转，让预警成为系统行为而不是管理者的记性。

4. 第四段：冲突升级与仲裁

冲突升级机制必须在冲突发生之前就定好，而不是等到两边吵起来了才开始想"这事该找谁"。我的做法是定义一个三段式升级路径：

1. 第一级：双方责任人直接协商，限时两个工作日给出结论。这个层级的解决率通常能达到六成以上，前提是双方都有明确的决策权限。
2. 第二级：双方团队负责人介入，依据依赖排序规则做取舍，限时三个工作日。这一级要解决的问题是资源争抢和优先级冲突。
3. 第三级：项目级决策人仲裁，必须有书面结论和影响评估。到了这一级，通常意味着要牺牲某一方的需求，所以必须留下记录，供后续复盘。

升级机制最重要的不是层级本身，而是每一级的时限。没有时限的升级等于没有升级。我见过冲突在第二级挂了两周没人拍板，最后拖到第三级时已经没有选择余地了。

5. 第五段：复盘与改进

复盘环节最容易被跳过。大多数团队在依赖交付后就认为事情结束了，其实这里才是流程改进的输入源。我在每个迭代或每个里程碑结束后，会看三件事：哪些依赖超期了、超期的原因是什么、流程本身有没有可以改的地方。

注意第三件事，不要把复盘引向"谁没做好"，而要引向"哪条规则需要调整"。比如如果连续三个迭代都出现"承诺日期填得过于乐观"，那问题不在人，而在于评估环节缺少工作量的交叉验证。调整流程，比追责有效得多。

六、关键指标体系：用数据暴露问题，而不是考核个人

流程解决的是"该怎么做"，指标解决的是"做得好不好"。我在这一节里给出五个指标，都是我自己实际用过的，会同时说明定义、计算口径、以及在什么情况下这个指标会失真。

1. 指标一：依赖识别覆盖率

定义：在依赖实际暴露之前被登记进台账的比例。计算方式是"提前登记的依赖数 ÷ 项目结束后统计的全部依赖数"。这个指标衡量的是流程的前置能力。

判断标准：我认为六十人以上的多团队项目，能做到 75% 以上就算健康。低于 50% 说明登记动作流于形式。这个数字我给的是经验区间，具体基线需要各团队自己跑两三个项目后确定，不要直接照搬。

失真情况：如果团队把"提前"的定义无限放宽（比如联调前一天登记也算提前），这个指标就会虚高。所以我在统计时会区分"阶段内登记"和"阶段末登记"。

2. 指标二：依赖交付准时率

定义：按承诺日期（含 buffer）交付的依赖数，除以已到期依赖总数。注意分母是"已到期"，未到期的依赖不计入。

判断标准：我观察到的健康区间在 70%-85% 之间。低于 70% 说明承诺环节过于随意；长期高于 90% 反而值得警惕，可能是承诺日期被系统性放宽，或者真的硬依赖被封杀。

失真情况：前面说过，这个指标一旦进入绩效考核，会立刻失真。我的做法是只在小范围复盘会上公开，不挂到个人。

3. 指标三：冲突解决周期

定义：从冲突被显式提出到冲突状态关闭的平均时长，单位是人天。这个指标衡量的是升级与仲裁机制的效率，而不是依赖本身的难度。

判断标准：如果三段式升级路径的时限被严格执行，理论上的最坏情况是 5 个工作日。我见过比较健康的团队稳定在 2.5 至 3.5 人天。

失真情况：如果团队倾向于"私下解决完再登记"，这个指标会显得很短，但实际的等待时间没有被记录。所以要同时看"冲突登记数量"，如果数量长期为零，说明登记动作没做。

4. 指标四：依赖变更响应时间

定义：依赖发生变更到下游团队收到通知并调整计划之间的时长。这个指标最容易被忽略，但它是协作质量的核心体现。

判断标准：我的经验是，能在 1 个工作日内完成通知和影响评估的，算优秀的协作水平。超过 3 个工作日，下游的调整成本会显著上升。

失真情况：通知的定义要明确，是发出消息就算，还是下游确认收到并评估完影响才算。我倾向于后者，虽然数据会难看一些，但更真实。

5. 指标五：跨团队协作满意度

定义：定性指标，通过每季度一次的简短问卷采集，问题聚焦在"依赖信息是否及时、承诺是否可靠、冲突是否被公正处理"三个维度。

判断标准：不需要追求高分，更值得关注的是趋势和分歧。如果两个团队的评分差异很大，说明冲突处理过程中存在立场偏差，这比绝对分数更有诊断价值。

失真情况：如果问卷和考核挂钩，一定会被刷分。这个指标只能在匿名且不影响绩效的前提下采集。

6. 指标使用的四条原则

原则一：指标必须能追溯到具体条目。如果一个数字不好看，但没人能说清是哪几条依赖导致的，这个指标就没有诊断价值。我要求所有指标都能下钻到依赖级别。

原则二：指标数量宁少勿多。五个已经是我能接受的上限。超过七个，团队就会开始选择性关注，最终所有指标都变成背景噪音。

原则三：指标只用于改进，不用于考核。这一条我重复了三遍，因为它是整篇文章里最容易被忽略、代价也最大的一条。

原则四：指标的基线必须自己跑出来。网上流传的各种"行业基准值"（比如"依赖准时率应达 85% 以上"）参考价值有限，因为行业、团队规模、外包比例、技术栈差异太大。我给的区间只是起点，真正有用的是你自己团队连续四个季度的趋势线。

七、工具落地：先把规则跑通，再让平台固化规则

流程和指标讲完之后，才轮到工具。我把它排在最后，是因为顺序真的不能反。下面这部分我会结合我在中大型组织里的实际经验，说明工具该承担什么、不该承担什么。

1. 工具应该承担的三件事

第一，状态流转的强制约束。承诺日期为空不允许进入"已承诺"状态，超过承诺日期自动触发预警，变更必须填写影响评估。这些规则如果靠人执行，三个月后一定走形。

第二，跨团队的可视化。依赖台账的价值在于它跨团队可见。如果每个团队只能看到自己的部分，依赖就还是隐形的。这也是为什么在超过百人的组织里，共享表格会很快触到协作上限，权限、并发编辑、数据一致性都会成为问题。

第三，数据的自动汇总。前面那五个指标，如果靠人工统计，光是每季度的数据整理就要消耗好几天。工具的价值是把这些计算变成默认输出。

2. 工具不应该承担的三件事

第一，不该替代规则的制定。我见过团队引入平台后第一件事就是问"这个工具支持哪些流程"，而不是"我们需要哪些规则"。工具支持什么，不等于你的团队需要什么。

第二，不该成为新的汇报负担。如果为了维护依赖台账，每个责任人每周要额外填半小时的表，这个流程活不过三个月。好的工具设计应该让登记动作嵌入到已有的工作流里，而不是额外增加一层。

第三，不该被当作信任问题的解药。工具能让依赖可见，但让依赖被兑现的仍然是人的承诺。把工具当成"监控手段"来推行，往往会激起抵触。

3. 中大型组织的工具选型判断

我在服务中大型企业（一百人以上、多团队并行、存在外部供应商协作）的项目里观察到一个共性需求：数据要可控、权限要可配、跨组织协作要能隔离。这类组织往往不能接受核心协作数据完全放在外部，需要私有化部署能力；同时因为历史原因，很多团队已经在用其他项目管理工具积累了多年数据，迁移成本是选型时的关键变量。

以 PingCode 为例，它主要服务中大型企业及 100 人以上组织，支持私有化部署，同时提供从 Jira 平滑迁移的能力，对于正在做国产替代的团队来说是一条相对低风险的路。我在这里提它，不是因为它能解决依赖冲突，而是因为它的定位，中大型、多团队、数据可控、可迁移，恰好匹配前面说的那类场景。如果你的团队只有十几个人，用一张表格就够了，引入重型平台反而会拖累落地。

需要说明的是，工具只提供能力，不提供执行。我把依赖台账搬进平台后，第一个月的数据质量依然很差，原因是登记动作没有被纳入评审会的固定议程。直到我们把"每场需求评审必须当场登记新发现的依赖"写进流程，数据质量才真正起来。

4. 迁移过程中的三个实操注意点

（1）不要一次性迁移全部历史数据。把正在进行中的依赖迁过去就够了，历史已关闭的依赖按需查询即可。全量迁移会稀释新台账的信号强度。

（2）字段映射要重新设计，而不是照搬。旧工具里的字段往往是多年累积的结果，很多已经没人用了。借迁移的机会重新梳理一遍，只保留真正驱动决策的字段。

（3）迁移后设立一个月的观察期。看依赖登记量、状态更新频率和预警触发情况，如果登记量在第二周就断崖式下跌，说明流程设计有问题，要立刻调整而不是硬推。

八、行动建议：不同团队规模该怎么起步

方法讲完，最后落到行动上。我按团队规模给出四套起步方案，因为不同规模的团队，能承受的流程重量差别很大。

1. 十人以下团队：只用一张表和一个规则

不要建流程，不要上工具。你需要的是一张共享的依赖表，加一条规则：任何需要等别人的事情，必须在当天写进表里，并写清楚对方什么时候给。每周花十分钟过一遍未关闭的依赖就够了。这个阶段追求的是习惯，不是覆盖率。

2. 十到五十人团队：把登记嵌入评审会

这个规模开始出现跨团队依赖，需要固定的识别机制。我的建议是：在需求评审和设计评审中增加一个固定环节，"本次涉及哪些跨团队依赖"，当场登记。同时启用临近预警和超期预警两条规则，用最简单的提醒方式（群消息或表格自动化）实现。

指标方面，先只看两个：依赖识别覆盖率和依赖交付准时率。连续跟踪四个迭代再决定是否增加。

3. 五十到两百人团队：建立明确的升级路径

这个规模下，冲突会从"人对人"变成"团队对团队"，需要书面的仲裁规则。核心动作有三个：明确三段式升级路径和每级时限；为关键路径依赖设置独立看板；把依赖相关指标纳入季度的项目复盘，但不进个人考核。

工具方面，建议评估平台化的方案。这个阶段共享表格的并发编辑和权限控制会成为瓶颈，而依赖数据的统计成本会快速增长。

4. 两百人以上或存在外部供应商：需要平台与制度双轨

这个规模下，依赖管理已经不只是流程问题，而是组织协同问题。除了流程和指标，还需要考虑数据主权、跨组织权限隔离、以及与既有工具生态的迁移衔接。前面提到的私有化部署能力和 Jira 迁移能力，在这类场景里会变成硬性要求而不是加分项。

同时要注意，大组织的流程推行一定要有试点。我见过的失败案例几乎都有一个共同点：试图在全体团队同时推行同一套规范。正确的做法是先在一到两个项目上跑通，把规则和字段设计打磨到位，再逐步铺开。

九、取舍：流程的轻重、指标的多少、工具的选型

任何管理动作都是取舍。这一节我把三个最容易纠结的取舍讲清楚，方便你在实际场景里做判断。

1. 取舍一：流程覆盖率与流程重量的平衡

流程覆盖得越全，执行成本越高；执行成本越高，遵守率就越低。我的判断是：宁可覆盖 70% 的依赖但 100% 被执行，也不要覆盖 100% 但只有一半被认真执行。被认真执行的部分会产生真实价值，形式化的部分只会消耗信任。

具体操作上，我用"三个条件筛两条"的规则来界定哪些依赖必须进流程（见第四节）。剩下的依赖留在团队内部口头处理，不强求登记。

2. 取舍二：指标数量与数据可信度

指标越多，看得越全面，但每个指标被认真维护的可能性越低。五个是我认为的上限，而且这五个里，我建议新团队先只上两个，稳定后再加。

另一个取舍是数据的严格程度。比如"变更响应时间"到底是发出消息就算，还是下游确认评估完才算。严格口径数据难看但真实，宽松口径好看但没用。我选严格口径，因为我需要的是诊断信息，不是汇报材料。

3. 取舍三：工具能力与组织执行力的匹配

能力强的工具往往需要更高的配置成本和更强的执行力。如果团队当前的流程成熟度还停留在"登记表经常没人填"的阶段，引入一个需要复杂配置的平台，结果大概率是建了一堆漂亮的空看板。

判断标准很简单：如果你的团队连共享表格都维护不好，先别买工具，先把登记动作变成习惯。反过来，如果你的团队已经在用表格认真跑流程，并且开始遇到权限、并发、统计效率的问题，那就是引入平台的正当时机。

十、结语：让依赖可见、可管理、可改进

回到开头的那个规律。我后来意识到，"依赖方交付晚"之所以会成为最常被写进根因栏的一句话，是因为它看起来像是一个可以归因于他人的结论，而流程缺失和度量缺位是看起来像在自我批评的结论。前者让人舒服，后者才有用。

依赖管理的本质不是提高沟通频率，而是降低协作摩擦。它由三件事构成：让依赖关系可见（登记），让承诺有约束力（日期与责任人），让问题被及时发现（预警与指标）。这三件事做扎实，你会发现需要开会解决的依赖冲突自然变少了，因为大部分冲突在变成冲突之前就已经被消化掉了。

如果你打算从这篇文章里带走一个动作，我建议是这个：在下一次需求评审会上，增加一个固定环节，把本次涉及的所有跨团队依赖当场登记，并让供给方当场给出承诺日期。就这一个动作，坚持四个迭代，然后对比一下你的依赖交付准时率。数据会告诉你，流程和指标到底值不值得投入。

至于要不要上平台、上什么平台，那是第二步的问题。先把规则跑通，工具才有意义。