# 跨部门老扯皮，多半不是沟通不够，是开工前有四个东西没说清

从接口和 RACI 里的两种角色说起：开工前把谁拍板、谁动手、什么算完成、卡住了找谁说清楚

> 跨部门协作 · 职责边界 · 会议沟通 · 约 6 分钟 · 10 月 02 日

## 本篇要点

1. 扯皮缺的通常不是信息，而是指定：会上大家都点头，但没人被明确到具体责任上。共识不等于约定。
2. 跨部门协作可以当成一条接口来设计，接口没定义，两边会各自按理解执行，出问题才发现对不上。
3. 需要事先说清的四件事：谁拍板、谁动手、什么算完成、卡住了找谁。
4. “谁拍板”和“谁动手”是两件事，对应项目管理里 accountable 与 responsible 两个角色；拍板的人在每件事上只能有一个，动手的人可以有多个。共同负责常见的结果是没人负责。
5. “什么算完成”要换成可核对的条件，不能停留在“能用”“上线”这类可以被两边脑补出不同版本的词。
6. 升级路径要写成条件句：什么情况下、多长时间内、找谁、做什么动作。写成“及时沟通”等于没写。
7. 这四个问题的代价平时看不见，只在压力下集中出现。
8. 不需要给每次合作都写接口协议，只处理反复出问题的那几条。
9. 问这四件事时要说成“避免返工”，而不是“确认责任”，否则容易被当成甩锅。

---

市场部提了个需求：下月初给客户演示一个新功能，需要研发配合。两周后市场部来催，研发说“我们说的是有资源就做”。于是开会。会上双方都很客气，同意了“要重视客户体验”，也同意了“要加强协作”。会开完，事情还在原地，只是下一次催的时候，多了一层“上次不是都说好了吗”。

这种场景里，绝大多数人会得出同一个结论：沟通不够，多开几次会吧。但你会发现，会开得越多，双方越累，问题还是那一个。原因不是态度，是这类会解决的是另一个问题。

## 反复开会补不上的，是指定，不是信息

开会的实际效果是让双方知道得更多：知道对方也忙，知道客户重要，知道这事确实急。这些是信息。可扯皮缺的不是信息，是**指定**——没有一个地方写着“这件事最终由谁定、交到谁手上算完”。

所以会上的常见景象是：所有人都在点头，但没有人被点到名字。点头叫共识，点名才叫约定。共识可以在事后被各自动脑补出不同版本，约定不行，它有主语和条件。

如果你写过代码，这里有个挺准的类比：两个团队之间就是一条**接口**。接口不定义好，两边各自按自己的理解传数据，跑起来才会发现字段对不上。你会先写接口，再写实现，因为你知道“等出问题了再协调”成本高得多。跨部门协作是同一条道理，只是大家习惯性地跳过设计接口这一步。

## 把“别扯皮”翻译成四个能回答的问题

真正需要开工前说清的，只有四件事。它们不难答，难的是没人专门问过。

**一、谁拍板。**这件事的最终决定权在一个人手上。注意是“最终”，不是“参与讨论的人”。公司里最贵的摩擦往往出在这里：同一个决定，产品觉得归自己，技术觉得归自己，谁也没错，因为从来没人写过。

项目管理里有一套划分角色和职责的做法，其中最值得记住的一点，是它把两种人分开写：动手把事做完的人（responsible），和对结果最终负责、有权收口的人（accountable）[1][2]。

关于“谁拍板”，有一条反直觉但被反复强调的规则：**同一件事上，拍板的人只能有一个** [1][3]。不是两个，也不是“两个部门共同负责”。原因很直接：如果最终责任在两个部门手上，那么这两个部门意见不一致时，规定本身没有给出答案，只能往上捅。共同负责在文件上看起来是平衡，常见的结果却是没人负责。

**二、谁动手。**这个可以有好几个人，也可以两边一起做。关键是它跟第一条是两件事。

很多人脑子里默认“谁做谁说了算”，这两条就黏在一起了。但在跨部门场景里它们经常分离：研发负责写这个功能，但“这次演示要包含哪几个功能”是市场拍板，因为客户关系在市场手上。分不开这两条，就会出现两种典型事故——做事的人把范围一直往自己舒服的方向改；或者拍板的人答应了时限，做事的人到点交不出来，还得背锅。

**三、什么算完成。**这一条听起来是废话，其实是最常见的事故源。

“下月初能用”不算完成标准，因为它可以被两边脑补出两个版本：市场想的是客户能自己走完整个流程，研发想的是页面上那个按钮能点开。到期一看，双方都很委屈，而且谁也说服不了谁，因为原话确实可以那样理解。

把它换成**可核对的条件**就好了：不是“功能上线”，而是“客户能在页面上自己走完申请到出结果这一整条路，中间不需要我们的人在旁边点”。这样一句话，说出来的当天你就能发现分歧——研发多半会立刻说“那得再要三天”。发现分歧是好事，越早发现越省事。

**四、卡住了找谁。**最后一条是前三条的保险。

合作一开始说得好好的，中途出变化几乎一定发生。没有升级路径的团队会走向两个极端：要么一点小事都往上捅，领导成了专职调解员；要么都憋着不说，等爆发时已经来不及。

所以升级路径要写成条件句，不是写成心态。像这样：“如果演示前三天还有子功能没完成，市场部直接找研发负责人，当天必须给出砍功能的方案。”有触发条件、有时间、有具体的人和动作，才叫路径。写成“有问题及时沟通”，等于什么都没写。

## 为什么是“开工前”

上面这四条，平时不写也常常没事——大家配合一下、多跑两趟，就过去了。这也是它们容易被忽略的原因：边界不清的代价，在没人施压的时候看不见。

真正的账单在压力下才到。演示日期逼近、客户那边变了要求、有人休假，这时候才发现：没人敢拍板砍功能，因为不知道谁有这个权力；没人知道交出去的东西算不算合格；想升级也不知道找谁，只能一路开到总监。同一种含糊，平时像是灵活配合，压力一大就集中变成了返工、延误和相互抱怨 [4]。它跟欠技术债的逻辑很像——不还，利滚利，只是体现在人而不是代码上。

## 怎么开口，不显得自己在推责任

这四问最容易被误解成甩锅：“你是不是不想干？”所以问法要选一选。不要问“这事谁负责”，那句话听起来就是要把锅递给别人。换成这种：

“我想跟您对两件事，免得后面返工：这个功能如果时间不够，最终由谁来定砍哪块？以及演示当天您希望客户能走到哪一步，算这次合格？”

把它说成“避免返工”，而不是“确认责任”，对方的防御会低很多，这跟前面几篇讲过的思路是一样的：先说共同目标，再落具体条件。

最后说清边界，免得用力过猛。第一，不需要给每一次合作都写接口，只需要处理**反复出问题的那几条**——同样是催了三次还没动静的事，才值得停下来对一次。第二，边界清楚不等于不协作，它只是把“谁都能插一句”和“谁必须给结论”分开；贡献照旧，只是决定有人收口。

一句话收束：跨部门扯皮不是人跟人的问题，是接口没设计的问题。开工前把这四句问完——**谁拍板、谁动手、什么算完成、卡住了找谁**——后面省下的返工，比你为此花的十分钟多得多。

## 术语表

- 接口：两个团队之间工作交接的那条缝，包括传什么、什么时候传、什么标准才算合格。写代码要先定义接口，跨部门协作也一样。
- accountable 与 responsible：对结果最终负责、有权收口的人，和动手把事做完的人。前者每件事只能有一个，后者可以多个，两者不一定重合。
- 可核对的完成标准：用能被检查的条件说明“做完了”，例如“客户能自己走完整个流程”，而不是“功能上线”“基本可用”。
- 升级路径：卡住时按规定升到上一级的规则，写成条件句——什么情况、多长时间、找谁、做什么。

## 来源

1. [Wikipedia: Responsibility assignment matrix — RACI 中 Responsible 与 Accountable 的定义，以及每项任务只应指定一个 Accountable](https://en.wikipedia.org/wiki/RACI_matrix)
2. [MindTools: The RACI Matrix — Responsible 是做事的人、Accountable 是签字负责的人，以及“有且只有一个 Accountable”的规则](https://www.mindtools.com/agn584l/the-raci-matrix/)
3. [Atlassian: RACI Chart — RACI 图在项目中的用法，包括每项任务只设一个最终负责人以避免方向冲突](https://www.atlassian.com/work-management/project-management/raci-chart)
4. [Boundary Debt in Teams — 职责边界模糊的成本平时不显，在期限、事故或客户压力下集中爆发](https://nat.io/blog/boundary-debt-teams-hidden-cost-unclear-ownership)

---

原文：https://pangzhengboyin.com/articles/cross-team-friction-four-things-to-settle-upfront-2d960b4f

> **庞征博引** · 想学的，慢慢都会
>
> 庞征博引是把想学的东西写成连载的 AI 学习工具。说出想学什么，它会先了解你的基础，再把主题写成一篇篇 5–10 分钟能读完的文章；边读边问，接下来学什么跟着你走。这篇就是这样写出来的。
>
> 开始你自己的连载 → https://pangzhengboyin.com