很多公司或者团队，在工作推进不顺畅的时候，会考虑调整部分组织架构或者更改一些工作流程，来提升效率。这篇主要讲一下 Jan Bosch 提出的 BAPO 方法论，以及为什么大部分公司知道这个道理但还是做成了 OPAB 。
一、前言
如何协同各个部门齐心协力在产品全生命周期发挥各自的功效，是行业里面普遍存在的问题。因为这个问题并无统一解，从业者大都对这个话题有自己的鲜明看法和强烈感受。
我的结论是：
- BAPO，即 Business → Architecture → Process → Organisation，是更合理的思考顺序。组织架构当然是重要的，但当我们讨论产品研发的机制搭建时，它应该是最后考虑的，而不是最先考虑的。
- 回归最佳实践，以业务策略和产品策略的对齐为前提，跑好 OKR +KPI 牵引的目标对齐和复盘，运行基础的敏捷流程（Scrum+Kanban）抓执行，已经足够搭建起比较高效的组织协同机制了。
二、BAPO, not OPAB
1. Why BAPO
BAPO 是我认为为数不多整明白了 Software Engineering 的前 Nokia VP，研究院院长 Jan Bosch 提出的（他的书都值得一读）。
这个模型看起来是非常 straightforward 的：顺着箭头的方向，应该先有业务战略，业务战略决定产品技术架构，然后产品技术架构决定流程机制，流程机制决定采用什么样的组织形式和权责分配。里面没有箭头的线表示，会有相互的关联，但不是谁决定谁的。稍微有点经历的人也都知道，有大量找对了商业模式和产品策略的团队，组织能力一般也活得还不错。但一群非常优秀的人用了非常好的流程，只要做了错误的商业上产品上的决定，也只能白辛苦。
然而就在提出这个模型的文章里，Jan Bosch 也说，虽然道理很简单，但大量的公司都是 OPAB 的：现有的组织来定义了一个不完善的流程，用没有经过深思熟虑的架构开发了产品和系统。这使得公司一直受过去的「债务」所限，不能面向未来，于是只能有非常有限的商业选择内做战略。
2. Why OPAB is everywhere？
核心是因为难度：
- B、A是高度开放的问题：
- 本质上需要回答解决了什么人的什么需求，为什么比先有的解决方案好
- 大部分时间连个参考都没有，并且涉及大量自己不可控的外部依赖
- 市场、用户、供应链、竞对…
- P、O 则容易找到现成的参考，并且基本内部闭环
- 只要管理层决定，流程和组织马上可调可改
- 这是看到「Spotify Model」，关注点很容易落在 Squads, Chapters, Tribes, Guilds上的原因
所以，作为管理者，在发现整个组织或者某个局部有推进缓慢合作不畅等问题时，要有意识的从 B 开始，而不是从 O 开始。先讨论希望实现的业务目标和商业策略，然后讨论通过什么样的产品和系统给内外部用户交付什么样的价值，然后才允许讨论这在内部意味着什么样的流程调整和组织变更。
只要大家在这点上达成一致，具体的从 B 到 O 的讨论、规划和落地机制，反而是有很多参考的。我们可以看到，比较成熟的组织会花很多心思设计适合自己组织风格的，定期的关于 B、A 的讨论机制：Amazon 的 6-paper，Uber 的 ERD，美团的班委制，阿里那大家体验过的让人死去活来的共创会（实际上 Spotify 也是基于 BAPO 原则进行的设计）。讨论的过程也许很有压力但也非常坦诚，最终都强调要形成一定周期内B、A 层面可执行的结论，来指导日常工作。