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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

为什么是“开工前”

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

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

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

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

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

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

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

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