跨团队依赖管理，我们用依赖矩阵

一、先讲清楚一个反常识的核心结论

绝大多数技术管理者嘴上说“依赖管理很重要”，但真到了执行层面，用的还是微信群喊话、邮件抄送、每日站会口头确认三件套。我们团队在2022年做过一次内部审计，翻看了连续四个迭代的延期工单，结果发现83%的延期根因不是技术难点没攻克，而是被其他团队卡住了。接口没ready、数据没开放、审批没走完、某个上游服务的灰度时间一拖再拖，这些才是杀死迭代的元凶。

更扎心的是：你没管住依赖，不是因为你不努力，而是因为你手里没一个能承载“跨团队承诺”的容器。口头承诺会忘，邮件会沉，IM消息会被刷走。依赖矩阵解决的就是这个问题。它不是一张表，而是一份“跨团队契约的强制可视化”。

这篇文章不讲理论，只讲我们怎么从一团乱麻里闯出来、把依赖矩阵真正用成管理利器的全过程。

二、依赖矩阵是什么？一张“白板上的网格”就够了

先别急着买软件。我们第一次做依赖矩阵，用的就是会议室白板+手机拍照。后来换了在线表格，后来又接进了PingCode的迭代管理能力。但无论工具怎么变，核心结构始终是下面这个最简单的网格：

我知道有人会问：这不就是个excel吗？区别在于，这张表必须由团队成员当着对方的面一起填充，而不是一个人关起门来凭印象填。这是依赖矩阵的第一性原则，依赖不是“我心里知道”，而是“双方确认过”。

1. 为什么说“一起填”比“填得全”更重要

我们在2023年Q1经历过一次大型项目协同，牵涉到6个团队。第一次做依赖矩阵时，我让每个组的负责人各自填好发给我汇总，结果你猜怎么着，订单组认为自己依赖了用户中心组的3项服务，但用户中心组只知道自己承担了1项。另外两项是订单组自己预想出来的“这部分应该是他们支持”。如果不拉在一起当面核对，这两项就变成虚空依赖，到时候用户中心说没承诺过，订单组说你必须给我，吵架吵到项目延期。

所以依赖矩阵的第一个价值不是记录，而是强制校准。校准到每一方对“我有多少东西握在别人手里”这件事有统一认知。

2. 依赖矩阵和RACI矩阵的根本区别

很多团队会把依赖矩阵和RACI矩阵搞混，这里明确一下：

• RACI管的是“同一件事里谁干什么角色”，负责、批准、参与、知情。
• 依赖矩阵管的是“不同团队之间谁必须给谁什么”，输入、输出、时序、承诺。

前者解决单线程内的权责，后者解决多线程间的耦合。二者不冲突，但不能互相替代。我见过有团队拿RACI来管跨团队依赖，结果开会时每个人都说“我是R，我负责”，但没人说“我这条线卡在某个外部输出上”。RACI给你角色，但给不了你时间点和交付承诺。

三、真实场景还原：一次被依赖卡死的迭代，长什么样

2023年6月，我们一个面向大客户的交付项目延期了整整两周。说出去很难听，技术复杂度不高，纯粹是被三个上游依赖拖死的。我把当时的依赖矩阵拿出来复盘，发现几乎每个团队都犯了同一个错：把“我们希望他们什么时候给”当成了“他们承诺什么时候给”。

1. 场景一：接口联调日期是“希望”还是“承诺”

订单组在规划迭代时写：6月5日联调。这个日期是他们拍脑袋倒推出来的，6月15日要上线，提前10天联调差不多足够。但用户中心组根本没承诺过6月5日能交付接口，因为他们当时正在处理另一个客户的紧急需求。订单组不知道，也没问，只是在站会上说“我们预计6月5日联调”。这个预计，在迭代看板上就变成了一个已确认的里程碑。

依赖矩阵暴露这个问题的方式极其简单：我们把每一行依赖的状态分成三个档位，“未确认、已承诺、已完成”。订单组的接口依赖那一行，状态始终是“未确认”，但迭代已经跑了两天了。这个红色标记逼着Scrum Master当场停下来拉会确认，否则不敢让开发继续往下写代码。

2. 场景二：依赖链条的传递效应

比单点延迟更可怕的是传递延迟。A依赖B的接口，B依赖C的数据管道，C依赖D的环境部署。一条链路里只要有一个节点承诺没兑现，上游所有人都在干等。那次延期就是典型：数据平台组的实时宽表权限卡在基础设施组的容器镜像更新上，基础设施组的镜像更新又卡在安全组的审批流里。一环扣一环，到最后BI组、订单组、支付组全被拖下水。

我们后来给依赖矩阵加了一个字段叫“上游阻断项”，就是当某一个依赖状态是“未确认”时，必须填出这条依赖为什么未确认、卡在哪个上游。这么一填，原本看似是用户中心的问题立刻现形，根子在基础设施组。以往这种问题要查两三天才能溯源，现在矩阵一展开，一眼看到底。

3. 场景三：评审会议上没人敢说的“跨组欠债”

迭代回顾时大家喜欢说好话，“我们组的节奏还行”、“代码质量在提升”。但跨组欠债这件事，很少有人主动提。因为一提就意味着在指责另一个团队没做好，伤感情。依赖矩阵在回顾会议上的一个特殊用法是：直接把矩阵投影出来，按“被依赖方”维度统计每一方的延误次数。不是追究人，而是追究流程，为什么这个团队总是成为瓶颈？是需求吞吐量太高？还是排期机制有缺陷？

有一次我们发现用户中心组每个迭代都要被依赖6到8次，远超其他组的2到3次。数据一出，根本不用撕，大家立刻意识到不是用户中心不努力，而是架构上很多核心能力都绑在他们身上，需要解耦。这就是依赖矩阵的另一个隐藏价值，推动架构治理。

四、常见误区清单：90%的团队跌进前三个

做依赖矩阵三年，我踩过的坑自己都记不清了。总结出五个最常见的误区，团队只要避开其中三个，效率至少提升一倍。

1. 误区一：依赖矩阵是项目经理一个人的活儿

这是最致命的。如果只有项目经理或Scrum Master在维护依赖矩阵，那这张表就会变成“PM的幻想清单”。他填的需求方和被依赖方都没确认过，填的时间也是他自己估计的。等到发生冲突时，所有人都说“我没签过字”。

正确的做法是：依赖矩阵的每一行必须由依赖方和被依赖方双方在同一个会议上确认。这可以是迭代计划会议的第二阶段，前面讲完本迭代要做什么，后面马上用20分钟拉依赖矩阵。PingCode的迭代规划里有一个步骤专门做这件事，Scrum Master打开迭代任务板，所有团队负责人一起对着看板逐条拉依赖。谁提出需求，谁承诺交付，当场定下来，当场进系统。

2. 误区二：只记技术依赖，不记非技术依赖

技术人可以精确地列出需要哪些接口、哪些数据库表，但往往忽略掉审批依赖、合同依赖、外部供应商依赖。有一次我们一个版本卡在合规审批上卡了8天。技术上早ready了，但安全团队的渗透测试报告没出来，合规官不签字。这条依赖一直没被写进矩阵里，因为项目组觉得“这是流程，不是技术”。

依赖矩阵管的是所有可能阻断交付的外部因素，管你是技术还是流程。我们后来在矩阵里专门增加了一类标签叫“非技术依赖”，包括法务审批、安全合规、财务预算释放、第三方SLA等。现在迭代开始前第一件事，就是扫一圈非技术依赖有没有被遗漏。

3. 误区三：把“进度更新”当成了“风险管理”

很多团队把依赖矩阵当成日报，每天更新状态“进行中”“进行中”“开发了80%”。这不是风险管理，这是写日志。依赖矩阵真正的风险管理价值体现在预警信号上。我们现在的规则是：

• 承诺交付日期前三天，如果被依赖方没有更新状态，系统橙色预警，Scrum Master主动去问进度。
• 承诺交付日期当天还未交付，红色预警，立刻触发升级机制，通知到技术VP。
• 一条依赖项连续两个迭代未关闭，列入回顾会议专项议题，必须输出改进措施。

这三个规则不是我们拍脑袋定的，而是在 PingCode 的迭代概览页面里能看到燃尽图趋势之后，我们发现自己总是在迭代最后三天疯狂处理依赖问题。于是反向设定了前三天预警的规则。

4. 误区四：依赖矩阵不能承载业务优先级

依赖矩阵不是孤立的“清单”，它需要和需求优先级挂钩。如果一个P0级需求卡的依赖项还在“未确认”状态，那这个需求就应该被标记为风险需求。我们现在的做法是，在PingCode里把史诗级需求的优先级字段和依赖状态做关联，当高优先级需求的依赖项进入红色预警时，产品负责人的移动端push通知立刻触发。

你可能觉得这是技术细节，但产品负责人是唯一有权力决定“要不要砍这条需求”的人。让他第一时间看到依赖风险，他就能最快做出决策，而不是等技术经理开了三天会才把消息传到他耳朵里。

5. 误区五：跨团队依赖用同一张表管理所有层级

一个组织里，CTO关心的是战略级依赖，几个大项目之间的耦合关系。团队leader关心的是迭代级依赖，这周哪个接口要就绪。开发关心的是任务级依赖，依赖项的测试用例什么时候给。

三种层级混在一张表里，表就废了。我们现在拆成三层：战略层用依赖地图，管理层用依赖矩阵，执行层用阻塞项看板。三层之间数据联动，但不混在一起展示。PingCode可以把需求拆成史诗、特性、用户故事三级，不同层级的人看不同视图，这个设计帮我们解决了之前excel时代信息过载的问题。

五、专业判断逻辑：当你面对一个混乱依赖网，先动哪一步

依赖矩阵这事最大的难点不是画表，而是已经有一堆历史欠债的情况下，从哪里切入。我分三个步骤来说。

1. 第一步：止血，别在依赖上犯重复的错误

如果你现在的团队已经深陷依赖泥潭，不要试图一次性把所有历史依赖全理清楚。你肯定理不清。正确的做法是先建一条红线：从下一个迭代开始，所有新需求在进入开发前，必须完成依赖矩阵的录入和确认。过去的旧债可以慢慢还，但不能再造新债。

我们在执行这一步时借助了PingCode的需求分级体系。需求进入迭代规划前，产品负责人必须给出优先级以及业务价值，然后Scrum Master在迭代计划会议上加一个环节，“依赖项检查”。每个用户故事在被团队认领到迭代待办列表之前，必须回答一个问题：这个故事完成是否需要其他团队配合？如果需要，依赖矩阵立刻补一行。

这个动作执行了两个月后，新迭代的依赖延期率下降了将近一半。

2. 第二步：标记，给每个依赖打“可信度”标签

不是所有依赖承诺都值得信任。我们的判断逻辑很简单：看被依赖方的历史履约率。如果一个团队过去三个迭代的承诺交付准点率低于60%，那对他们的承诺就要打折扣。我们在依赖矩阵里引入一个自定义字段叫“承诺可信度”，分A/B/C三档：

• A档：过去3个迭代准点率≥90%，按原计划执行。
• B档：准点率60%-89%，需要增加缓冲时间，一般为原估时的1.5倍。
• C档：准点率＜60%，必须建立备选方案，或升级到更高层级决策。

这不是贴标签，而是把过往数据变成排期依据。人情归人情，数据归数据。

3. 第三步：预警，设定触发条件，别等人发现

前面说了三色预警规则，这里重点讲一下预警的自动化。我们现在的依赖矩阵跟PingCode的迭代看板是打通的。当一个依赖项的承诺截止时间进入24小时倒计时，且交付状态仍为“未完成”时，系统会自动把对应的用户故事标记为风险状态，同时飞书群里推一条消息给Scrum Master和产品负责人。

这套机制上线后，我们发现一个有趣现象：被依赖方的响应速度至少快了2到3天。理由很简单，以前是依赖方去催，被依赖方可以找各种理由推；现在是系统催，而且催的同时已经通知了你的老板。

六、以PingCode为例：依赖矩阵如何在百人以上组织中落地

写到这里必须讲具体工具，否则前面的方法论没法变成日活。我所在的团队规模在120人左右，13个开发小组，每条产品线三到四个团队交叉协作。PingCode是我们从2022年开始使用的研发管理平台，依赖矩阵不是它单独的一个模块，而是嵌在整个Scrum流程里的能力。

1. PingCode为什么适用大团队做依赖管理

第一是需求分级机制。PingCode用史诗/特性/用户故事三级来管理需求。依赖矩阵可以直接挂在史诗级别，跨季度战略依赖；也可以挂在特性级别，跨迭代依赖；还可以拆到用户故事级的任务依赖。这个分层设计让120人的组织不会出现CTO和一线开发看同一张表的尴尬。

第二是与迭代计划会强制绑定。在PingCode的Scrum流程里，迭代规划阶段有一个动作叫“形成迭代待办列表”，产品负责人讲解高优先级需求后，整个团队一起拆分用户故事和开发任务。这个环节天然适合同时拉依赖矩阵。因为故事拆分时必然会暴露出“这块需要用户中心配合”、“那个字段需要数据平台开放权限”，当场确认当场录入，不会遗漏。

第三是数据打通能力。依赖矩阵里的一条依赖项可以关联到Testhub的测试用例、Wiki的设计文档、Insight的数据看板。当被依赖方完成交付时，依赖方不需要再去另一套系统里找验收材料，点开这条依赖就能看到关联的测试报告和文档。

2. 一个迭代周期内的依赖矩阵工作流

我给一个我们日常使用的标准流程，可以对照着看：

1. 迭代计划会议（周一上午）：产出迭代待办列表，同步拉依赖矩阵。产品负责人讲解需求优先级，各团队认领故事，当场确认依赖项并录入PingCode。
2. 迭代开发（两周）：每早站立会议由Scrum Master打开迭代任务板和依赖矩阵，每位成员汇报与依赖相关的阻塞。依赖状态更新后，风险阈值触发会自动通知相关人员。
3. 进度跟踪：迭代概览页面实时显示迭代进度、燃尽情况和依赖项完成率。团队可以一眼看到哪些依赖项正在拖累燃尽曲线。
4. 评审与回顾（迭代最后一天）：先评审完成的工作成果，再回顾迭代过程。依赖矩阵数据直接投影，本迭代依赖总数、按时交付数、延期数、延期原因分类，全部拉出报表。

这个流程在PingCode里跑了大半年之后，我们基本做到了依赖问题不过迭代。不是说不发生依赖延期，而是发生之后能在同一个迭代内被识别、被升级、被处理，不会藏到下一个迭代才爆炸。

3. 一个真实数据观察：依赖密度与团队规模的关系

我把过去18个月我们团队的数据拉出来做了一个分析，发现一个规律：当组织超过80人，依赖项数量不是线性增长，而是指数级增长。50人时平均每个迭代依赖项在4到6条，100人时涨到14到18条，150人时已经到了30条以上。

这个数据告诉我们：100人以上的组织如果还在用excel手动维护依赖矩阵，每个迭代光是维护依赖关系就要花掉Scrum Master整整一天。而PingCode把依赖信息集成在需求管理和迭代管理流程里，减少了大量切换和录入成本。这是规模效益带来的工具刚性需求。

七、不同情况下的行动建议：按团队规模和成熟度分级

不是所有团队都适合一口气上全套依赖矩阵。我根据实际经验给出三个档位的行动建议：

1. 20-50人小规模团队：从一张共享表格起步

这个阶段的团队，组织复杂度还不高，一张飞书/钉钉在线表格完全够用。核心做好三件事就够了：

• 每个迭代开始时花15分钟集体填充依赖项，依赖方和被依赖方双方确认。
• 每天站会打开这个表格过一遍当前阻塞。
• 回顾会议统计一次各团队被依赖频次，发现隐形的架构瓶颈。

不要追求自动化预警、不要搞三层视图、不要上任何工具平台，这个阶段的关键是把“依赖可见”变成肌肉记忆，而不是系统化。

2. 50-150人中等规模组织：将依赖矩阵嵌入研发流程

这个阶段，团队数量开始跨过10个，依赖项量级显著上升，靠表格已经管不住版本和状态同步的问题了。强烈建议使用像PingCode这样原生支持Scrum流程、并且能在需求管理和迭代管理中打通依赖关系的平台。

关键动作：

• 把依赖确认变成迭代计划会的固定环节，相当于给每个用户故事加一个“依赖体检”。
• 建立三色预警规则，用流程而不是靠人去追。
• 开始分层：管理层看依赖矩阵，执行层看阻塞看板。

3. 150人以上大型组织：引入依赖地图和架构治理

大型组织里，依赖管理的瓶颈不是信息不对称，而是架构耦合度本身。当依赖项数量大到Scrum Master处理不过来时，必须从源头解决，为什么这么多依赖？能不能解耦？哪些模块应该独立？

这个阶段依赖矩阵的使用方向开始转型：不再只是“记录依赖”，而是用依赖数据推动架构重构。PingCode的Insight模块可以把依赖数据汇总成趋势图表，管理层每季度review一次依赖密度报告，对依赖最密集的模块启动解耦专项。

八、不同情况下的取舍：当依赖矩阵和一个“面子问题”冲突时

依赖矩阵有一个很难量化的敌人，叫团队面子。

你有没有想过，为什么很多团队嘴上同意依赖矩阵，背地里却不愿往上面填东西？因为每一行依赖都在暴露“我做不到自闭环”。尤其是那些技术实力很强的团队，最怕被人说“你们组怎么老是依赖别人”。

我在推动依赖矩阵时就遇到过强烈的抵触。某位后端负责人直接说：“我们组所有能力都是自闭环的，没什么要填的。”实际查了一下，光他们的接口调用就依赖了三个基础服务组。他不是不知道，他是不想承认。

1. 取舍一：强制与共识之间，优先共识

我的判断是：在成熟度不够的团队里，不要一开始就要求100%覆盖所有依赖项。可以接受渐进式推送：头两个迭代只要求填写“跨部门依赖”，不要求“跨组依赖”。等大家适应了，再放开范围。

强迫一开始就填全，只会逼着大家乱填或抵制，反而搞崩了团队氛围。

2. 取舍二：暴露风险与保护士气之间，用专项复盘代替当众批评

依赖矩阵确实会让某些团队不太好看，尤其是在回顾会议上数据一拉，谁延迟多一目了然。我的处理方式：不在大群里艾特，不公开点名，而是在回顾会议上把延迟最多的依赖项拉出来，带到专项复盘里，由Scrum Master和当事人一对一沟通。

公开数据但不公开处罚，保持透明但不制造对立。

3. 取舍三：矩阵维护成本与收益之间，允许一定模糊度

依赖矩阵不是API文档，不求100%精确。80%的依赖项清晰、状态准确，就已经足够撑起风险预警和排期决策。剩下20%的边缘依赖可以允许模糊处理，例如标为“待确认”持续跟进。

追求完美的依赖矩阵只有一个结果，维护它的人会恨死你，然后它再也没有人更新。

九、最后说三句话，留给想推动这件事的人

跨团队依赖这件事，说到底不是一个技术问题，是一个组织透明度问题。依赖矩阵解决的就是“把欠条放在桌面上”这个动作。

第一句话：不要把依赖矩阵当成命令，它是跨团队安全协作的凭证。一旦你的团队上了依赖矩阵，别人的承诺就有了载体，你的交付也有了底气。

第二句话：工具是壳，流程是骨，文化是魂。PingCode可以帮你把壳和骨都撑起来，但在组织里真正让依赖矩阵活起来的，是一群愿意承认“我需要你”、并且对承诺负责的人。

第三句话：如果你今天只做一件事，就在下一次迭代计划会上，试着用白板画出第一个依赖网格。不用任何工具，只需要让每个人面对别人写下的“我需要你帮我做xxx”，并获得对方的一句“我承诺这个时间给你”。从这句承诺开始，你的依赖管理才算真正上了路。