当两支团队都在等对方：一个依赖关系的故事
一家中型公共机构正在上线新的审批门户。两个小组分担工作：内部应用团队负责构建前端，数据团队负责搭建其背后的档案数据库。纸面上的计划很整洁。但在实际中，两支团队分处不同楼层，在转为远程办公后又位于不同时区，还各用一套项目跟踪工具。文中姓名和日期已作改动，但这个情形你一定不陌生。
它是如何停滞的
应用团队以为数据团队会在三月底前交付一个完工的 API。数据团队则以为应用团队会先发来定稿的字段需求。这两个假设都没有写在任何两支团队都能看到的地方。整整三周，双方都认为自己被对方卡住，于是各自悄悄去做优先级较低的任务。第一次有人把「被卡住」说出口，是在指导委员会上，发起人问演示日期为何延后。那时，两个冲刺已经白白过去。
这里没有谁不称职。两支团队都很忙碌、也很能干。失败之处在于：它们之间的依赖只存在于人们的脑子里——而在远程、混合的环境下，过去能在走廊里捕捉到这件事的那段对话，从未发生。
什么本可以让它更早浮现
依赖就是一个承诺：一支团队答应在某个日期、以某种约定的形式，交付另一支团队所需要的东西。解决办法是让这个承诺变得明确、可见、有人负责。几个习惯就能完成大部分工作：
把依赖写成一项双方的承诺。 写清谁需要什么、来自谁、以什么形式、在何时之前完成——并让双方都确认，而不仅仅是接收方团队。
为它指定唯一负责人。 每一条跨团队依赖，在提供方一侧都需要一位具名的人对交接负责。「数据团队」不是一个人。
把它放在同一个共享视图上。 一份简单的依赖清单或一块共享看板，胜过两套各自独立的跟踪工具。如果一条依赖不能让两支团队在同一个地方看到，它其实并不存在。
以较短的节奏复盘它。 两位负责人每周开一次 15 分钟的同步会，只聚焦即将到来的交接和变动的日期，就能在还来得及应对时发现拖延。
更深一层的教训
跨团队依赖正是项目悄然死亡的地方，因为没有任何一支团队拥有它们之间的那道缝隙。恰恰是在人员分散、非正式协调被削弱的时候，风险最高。管理这件事并不需要笨重的治理——你需要的是一份共享而诚实的清单，写明谁在等谁什么，并复盘得足够频繁，让一个滑动的日期在几天内被发现，而不是拖到演示当天。
让「我被卡住了」成为一件可以及早说出口的常态，而不是承认失败。
跟踪提供方团队承诺的日期，而不是接收方团队期望的日期。
当某个日期变动时，向下游追溯：谁的工作因此刚刚被推迟了？
如果你的交付总是卡在团队之间的接缝处，XNM 的项目群与项目交付咨询 可以帮助你让这些依赖可见，并持续推动它们前进。