I）TL;DR

我们在公司里面开会，经常会有「鸡同鸭讲」的感觉。这是因为参与讨论的各方，可能在不同的层面，用着各自的语言。

组织跨部门会议，最重要的技巧就是把讨论的问题拉到同一个抽象层次，用同样的语言体系进行讨论，从而让过程更加高效，结果更可执行。

II）Why

大家会不会有个感觉：同部门讨论，比跨部门容易很多，甚至很多时候会感觉外面的部门有「墙」。

有人把这个归于「文化」和「政治」。

但我的观察，很多时候，是因为大家技能不够。

销售关心的是自己的客户满意度，渠道费用，commit 的数字能不能完成；研发关心的是这个需求是不是成立，需要花多少成本和时间，是痛点还是痒点应该有什么样的优先级。

几乎在所有的公司，这类在不同层面操着不同语言体系的讨论，都很容易吵架。所以，把参与各方带入同一个结构再进行讨论，是非常重要的技能。

III）How

一个问题讨论的层次可以定义为三层：用户层、中间层和实现层。

用户层是为了用户能够轻松愉快地使用产品做的那部分工作：门把手、咖啡机上的触屏菜单、自动扩容的带宽、系统数据那个导出报表的按钮等等…

实现层是由成本和物理化学技术规律约束下产生的具体实现：芯片架构、光伏供电、5G 网络、钢化玻璃等等…

中间层位于前面两层之间。很多时候我们感觉自己工作在这层：代码编写、环境搭建、磨刀砍柴等等…但其实并不是。

举个例子，程序员「写代码」的工作其实三个层次都会涉及到：

• 实现层：代码是在它运行的软硬件平台能够良好工作并且高效的；
• 中间层：代码是所有同事能够看懂并且很好去修改维护的；
• 用户层：代码是完成了需求并且暴露的功能使用起来舒适方便；

一个成熟的开发者应该能够根据项目实际情况分配自己在不同层次上的投入比重，有侧重点。比如，一个政府项目，偏一次性交付为主，可能就应该花足够多的时间在用户层上。

同时，在讨论的过程中要避免只在自己熟悉或者说可控的层面做讨论，而刻意回避自己不熟悉不可控的层次——这很难，甚至有点反人性，所以往往需要讨论组织者干预。

比如大家开会，如果销售说，用户想要一个按钮实现「一键外发」，研发说这个开发工作量太大了或者说这个功能我们的产品实现不了，这就是典型地不在一个层次。

组织者应该调整大家，先回到某一个层次。比如研发来到销售讨论的「用户层」，先关注用户为什么想要「一键外发」？为什么是要一个按钮来一键外发？如果做到别的地方或者做成浏览器插件在任何地方都可以外发是不是更好？

把这些问题讨论清楚，往往都会得出双方都可以接受的结果：要不就是不做或者可以有更好更低成本的做法，要不就是确实很重要工作量也很大那就调整现在的其他功能的排期。

或者销售先来到「中间层」：目前的实现框架是什么？计划做什么样的扩展？用户的这个功能有没有手动或者其他替代方案？很多时候销售容易有「怎么实现我不管，这个需求我就要」的心理。在没有冲突的时候这没问题，就跟你平常用家里的微波炉不需要看说明书一样。但是如果微波炉出问题了，你肯定会通过电话客服或者阅读说明书来解决问题。

这其实就是把自己先放到中间层——虽然心里面可能是一万个 f*ck，但你知道，只有这样才能解决问题。

以上。