跨部门协作总推不动？先分清职责再谈配合
一个跨部门项目，开会七八轮，需求反复确认，可一到交付节点，每个部门都觉得自己“该做的都做了”，出了问题的环节却无人认领。复盘会上大家各说各话，唯一的共识是“流程有问题”。如果你经历过这种场景就会明白：多数跨部门协作的失败，根源不在态度，也不在沟通技巧，而在职责边界——没有人真正“拥有”最终结果。
麦肯锡对财富500强公司的一项研究显示，管理者平均把37%的工作时间花在决策上，其中超过一半被白白浪费，折算下来每家公司每年损失约2.5亿美元。浪费的主因并非人才不足或战略不清，而是“清晰度赤字”：没人说得清一件事该由谁拍板、谁执行、谁只需知情。五个人同做一款产品时，默契靠日常闲聊就能维持；一旦项目横跨市场、产品、技术、法务与销售，非正式沟通必然失效——每个职能都觉得自己有发言权，却没人愿意为别人的延误兜底。
为什么跨部门协作天然低效
从结构上看，跨部门协作至少面临三重阻力：
- 职责真空：关键环节没人“认领”，大家默认“总会有人做”，结果往往没人做。
- 激励错位：各部门KPI不同，市场部要声量、技术部保稳定、销售部追回款，对同一件事的优先级天然不同。
- 信息断层：该被征求意见的人没被问到，该被知会的人事后才知道，误解与冲突由此滋生。
这三重阻力靠“多开会、多沟通”无法根治，因为问题出在角色定义，而非沟通频率。项目管理中的RACI矩阵正是为此而生：它把每个任务与四种角色挂钩，把“模糊的责任感”变成“明确的认领表”。
RACI矩阵：四个字母重新定义“谁负责”
RACI源于20世纪50年代的“线性责任图”，后在杜邦等大型工程企业中演化为责任分配矩阵，并被美国项目管理协会纳入项目管理知识体系，如今是跨行业通用的协作语言。它只做一件事：为每个任务标注四种角色——
- R（Responsible，执行者）：真正动手干活、产出交付物的人，一个任务可以有多名R。
- A（Accountable，责任人）：对结果最终负责、拥有拍板权的人。铁律是每项任务只能有一个A。
- C（Consulted，咨询者）：在任务完成前必须征求其意见的专家，沟通是双向的。
- I（Informed，知会者）：只需被告知进展与结果的人，沟通是单向的。
最容易用错的正是A与R的区别，一句话概括：A拥有结果，R负责执行。项目经理常常是A，写代码、做分析的工程师是R；小团队里同一人可以兼任A与R，但同一任务绝不能出现两个A。两位部门负责人同时挂A，等于把责任稀释回原点，出问题时依然互相推诿。
C与I的区分同样关键。把该当C的人写成I，等于把法务、架构评审这类专业意见排除在决策之外，合同签了才发现漏洞，补救成本远高于事前咨询；把只该当I的人写成C，则会凭空多出审批关卡，任务迟迟无法关闭。判断标准很简单：这个人的意见是否会真正改变产出？不会，就写I。
一个案例：从“无人认领”到“各就各位”
一家电商公司上线年中大促，涉及运营、技术、客服、法务四个部门。往年大促总在最后一刻出乱子：优惠规则没人复核、系统压测排不上期、客服话术上线前两小时才定稿。今年项目启动会上，项目经理拉出一张RACI表：把“优惠规则复核”的A指定给运营负责人，法务列为C；“系统压测”的A指定给技术负责人；“客服话术定稿”的A指定给客服主管，表中同时写明每项任务的交付时间。规则一改，法务该不该确认、找谁确认，流程清晰可查；哪个环节卡住，负责人一目了然。那次大促的异常工单比往年少了近六成，复盘会第一次开成了“经验会”而不是“追责会”。
常见误区：RACI用不好反而添乱
- 误区一：全员都挂A。出于“不得罪领导”的考虑，把两位负责人都写成A，等于没写。每项任务只保留一个A，其余人要么R要么C。
- 误区二：C泛滥。一项任务挂八个C，每个C都要先沟通才能推进，项目被“精细地拖慢”。用“意见是否改变产出”这一条筛掉多余的C。
- 误区三：矩阵做完就锁进抽屉。RACI的价值在于执行中被反复校准，每周例会花五分钟过一遍“谁卡住了”，比启动时做得多么精美都重要。
- 误区四：指望RACI解决能力问题。RACI只消除职责模糊，不提升个人能力；执行者能力不足、咨询者乱给意见，矩阵再清晰也没用。
行动建议
- 下周就挑一个正在扯皮的跨部门事项，用一页表格列出所有任务与参与角色。
- 先为每个任务定唯一的A，再填R、C、I，顺序不要颠倒。
- 把表格发给所有相关方，请他们在24小时内提出异议，而不是默认“沉默即同意”。
- 项目期间每周过一遍表，把新增任务及时补录，让矩阵“活”在协作里。
真正的协作不是靠态度好，而是靠边界清。一张写明白“谁拥有结果”的表格，往往比十场“加强沟通”的动员会更能推进项目——这或许是跨部门协作中最反直觉、也最有效的常识。