I）TL;DR

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

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

II）Why

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

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

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

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

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

III）How

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

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

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

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

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

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

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

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

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

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

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

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

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

以上。

I）TL;DR

节前有位同学写邮件问了我一些管理上的问题，其中一部分是跟流程优化相关的。

我们每个人都在流程中。如果是管理者，不断地关注和优化流程是工作内容之一；如果是个人贡献者，流程有问题自己也会干得很痛苦，要学会去推动去优化。

这位同学的处境也挺有代表性：入职新团队，带来几个人。老板只告诉 Ta，你去看看现在有什么问题，优化它。

如何下手？其实有一个框架：区分两种价值和两种浪费。

II） Why

大部分人，大部分组织，没有真正理解每天的工作哪些有「价值」哪些是「浪费」。

从制造业的年代开始，管理者就会开始区分工作里面哪些是「value-add」的，那些是「non-value-add」的，但它的标准一直很模糊。

到了 2003 年，James Womack 和 Daniel Jones 在《Lean Thinking》里给了个框架，我觉得很清晰：用户愿意付费的那部分工作，就是「value-add」的。

很明显，任何公司都不可能只做「value-add」的这部分。因为哪怕你搭建一个生产线，要让它稳定、完全、可靠地生产产品，也涉及到大量的装配、调试和维护工作。这种分类法只是让你明确花在两部分工作的成本，然后尽量提高前者，降低后者。

举个例子。做过金融或者数据系统的同学应该都遇到过一类需求叫做「合规」。这部分需求显然不是用户愿意付费的功能，但是它却是产品能上线运营，公司能够不触犯法律的保障。这部分工作，就应该尽量控制花费的成本，包括时间和精力成本。

有了这个分类，怎么优化流程？下面就来具体说说。

III）How

1）关注两种浪费

在精益起源地，日本的制造行业里，有三个术语：muri（过载）、mura（波动）和 muda（不必要的工作量）。

最后这个 muda 也就是我们这里要讨论的，浪费。

它有两种。第一类浪费是把时间花在了不创造价值的事情里，比如开会，比如合规。第二类浪费更狡猾，是那些因为组织里的历史原因带来的制度性的浪费，比如，你发现某个事情虽然带来客户价值，但成本很高或者很费时间，然后问同事怎么是这样的，同事说：「我也说不上为什么，但一直都是这样的」。

大部分行业，花在不直接作用于产品交付的时间比制造业高得多，所以，如果你仔细梳理一下两种类型的浪费有多少，通常是惊人的。

比如以软件行业为例。很多 CTO 或者产研负责人常常以自己的团队有多大，基础设施有多豪华（复杂）为傲，或者把代码行数、Git 提交数、code review 的严谨度等等作为自己的绩效指标。很多人在自己被干掉的时候，都没有算过团队究竟花了多少的时间创造真正的用户价值。

2）处理两种浪费

你梳理了现有流程，分析了两种浪费上花的时间，要怎么处理它们？

处理第二种浪费相对简单，就是立刻停止。

比如我们为什么出差完了要回来花那么多时间贴发票？如果结论只是「一直都这样」，我们就切到滴滴企业版或者类似的服务，从此财务和员工都没有这项工作了。

比如我们为什么在业务这么早期，大家每天都有密集的交流时，有一个固定的周会？如果结论就是「一直都这样」，我们就停止这个会议，没有人会抱怨，没有工作会被影响。

处理第一种浪费要麻烦很多，因为你需要「尽力减少」在这上面花的时间，但它不可能是 0 。

这往往需要你学会问正确的问题。

不要开会讨论「我们怎么优化测试覆盖率」，而是问「我们有没有可能提高系统的弹性和可观测性，让线上的问题影响可控，减少测试开销？」，因为所有的测试活动本质上不带来「value add」，用户默认它付钱买来的产品或者服务是「工作」的。

不要开会讨论「我们怎样才能开好每日站会」，而是问「我们有没有可能不开站会，也能通过其他办法比如更清晰的 Jira 流程，达成站会希望达成的目标？」。

我经历过的真正被组织和领导认可的流程优化，都是通过无情地识别浪费，解决浪费，让团队专注于为用户创造价值的事情来达成的。

以上。