微服务化小团队集群的组织和管理

程序猿DD 2019-07-13

本文转载自公众号：思特沃克

随着微服务架构风格的流行，组织内部不可避免的产生了许多小规模团队，原来一个几十上百人的产品团队被拆分成了类似Amazon这样的2 pizza（6~10人）小团队。组织结构上也由之前的层级化职能团队设置变成了扁平的小团队集群。每个做这样调整的企业都希望借助小团队的灵活性在这个科技时代跟上市场变化和创新的脚步。

当然这样的组织方式本身就带来了一系列的挑战，技术实践方面Martin Fowler已经通过微服务的定义文章做了很形象的叙述，还用了“你必须长这么高”（You must be this tall！）来比喻在技术实践方面所需做出的投入。

在组织管理方面，越来越多的挑战被识别出来，把“自组织”当做银弹来回答这样集群小团队组织和管理中的问题是行业里存在的一个不好趋势。在最近和Matin Fowler的讨论中，我们达成共识的一点是：与其说微服务是一种技术架构，还不如说是一种企业组织架构。

希望通过本文与大家一起研讨这样服务化小团队集群的组织和管理方法。

组织原则：对齐业务

科技时代带来的最大变化就是对变化本身的认知。在上一个时代，变化被认为是高成本甚至有害的，大家总是希望能够尽量减少变化，或者能够循序渐进地变化；而现在我们会认为变化是必然的，是会给我们带来新的市场机会的，甚至是会引发颠覆式创新的。

由于这样的认知变化，企业必须具备相应的灵活性，而扁平的小团队集群组织结构被不少企业（例如Google和韩都衣舍）证明是提供这种灵活性的有效组织方式。很多企业争相效仿，但不少会发现并没有得到之前追求的灵活性，反而做事情更为复杂了，以前一个接口部门变成了现在的多个团队。

作为咨询顾问，这两年经常接触到不少人抱怨划分成小团队后需求的实现成本增加很多，以前简单的业务需求现在要分解到很多“服务”团队才能完成。有的团队觉得这是技术问题 – 架构设计前瞻性不够；有的团队觉得是管理问题 – 没有跨团队的协调机制。而我往往喜欢从组织入手，让团队从业务需求出发，分析为什么那么多“集成”。

熟悉康威定律的同学可能已经理解我的用意了，以上团队出现的问题核心症结在于团队的组织结构和市场业务没有对应关系，大量的服务集成等同于把市场需求“翻译”适配到已有的组织结构。这样的痛苦在过去职能组织结构的时候就广泛存在，而错误的“服务化”只是把这种痛苦转换成了小团队之间的集成。

所以微服务化组织结构的核心原则是： 小团队的组织结构应该和市场业务对齐，并跟随市场业务变化而改变。

稍微实例化一下以上的原则，比如最近一个客户的电商团队，100人左右规模。开始时候划分成了10人上下的小团队，每个团队负责几个服务，其中有几个“重要”服务，如customer（客户）和catalog（目录）。在一段时间里，几乎所有的需求都要经过这两个服务，工作量很大，团队实际上也根本不是十几人，而是几十人。团队告诉我：撑过这段高峰期模型就稳定了，以后就可以真正“微服务化”了（很多同学可能都有同样的幻想~）。

我用领域驱动设计的思想很快指出，就现在业务需求驱动出来的大量集成已经可以明确这些“重要”服务的划分是有问题的，新增加电子产品（比如点卡）的customer和之前的电商customer已经有不同的含义了，电子产品要求客户提供对应电子平台的账号和授权。按照上面的原则，不应该继续去扩充已有的customer服务，而应该重新分析新的业务模式下是否应该有新的服务（其中也包含新的customer模型）。

以上的例子在很多走向服务化组织结构的企业里比比皆是，而遇到问题时大家更容易从看似明确的技术或管理手段入手。这里希望读到此文的各位在遇到这样的挑战时别忘了康威定律。管理原则：适应不确定性

《大教堂与集市》这本书中对比了两种不同的组织架构模式，很多特质也能够类比到单体架构和微服务架构之上。当微服务架构落地形成生态时（如Google），好比一个繁荣的集市，中央管理固然重要，但各个经营摊位却自主在为客户提供着琳琅满目的商品和服务。

作为一个企业，不太可能完全容忍集市一样的市场化，当然也有企业如海尔，把这种市场化更大程度上地引入到了内部。假设刚刚从过去职能层级组织结构转换到扁平小团队集群结构，这个时候管理者最大挑战就是如何还能够获取过去一样的“全面”信息。管理者往往会告诉我他们感觉到随时可能失控，因为每个团队都没有统一的开发方法和流程。

很不幸的是大多数从MBA课堂走出的企业管理者们都是管理“大教堂”建设的高手，却很难驾驭集市带来的“混乱”。然而我们的管理者们又都渴望着自己的企业能够有创新的环境。根据创新理论（Edge of Chaos），集市混乱产生创新的可能要远大于大教堂的整齐划一。那么在这个你不创新就被别人创新颠覆的时代，管理者就必须正视这个挑战。

管理的原则应该改变为： 放弃对掌控全局的虚幻追求，拥抱不确定性带来的挑战和机遇。

同样实例化一下上面的原则，一个300多人的大产品经理与我谈他的困惑，自从转型成为扁平小团队结构后，他的会议比之前多了N倍，基本每天正常工作时间全部在开会。自己的产品方向和运营只能靠夜深人静的时候加班。他告诉我如果这就是所谓小团队要付出的代价，那么他觉得这事儿没法持久。

我首先肯定了他的观点，即如果作为产品经理都没有时间看产品方向和运营，那么模式上肯定是错了。进而询问最占用他时间的会议需要他做什么？很有意思的是他的答案是“我需要知道xxx信息才能保证计划的拉通”、“开会已经同步各个小团队最高效的方式了”… 这里表达出来的行为全部是希望掌控全局的急迫，和他嘴巴里说出的赋权团队、打造自组织文化大相径庭，当然知行合一本身就是困难的。于是我们花了很多时间来讨论为什么一定要有拉通的计划、为什么要中央同步各个小团队 … 这位管理者最后带着更多的困惑离开了那次讨论。

对比组织结构的调整，管理者思想和方法的转型确实任重道远。我往往给出的建议是从小处着手，比如放弃给每人安排任务，让大家自己来选择；又比如在团队之间冲突时，放弃作为管理者的“拍板权”，让团队通过快速实验来验证哪种方式更好。另一位大师级同事Jim Highsmith在八年前就总结出了适应性领导力（Adaptive Leadership），十年后的今天仍是少有管理者能够真正践行。

合作原则：简化集成关系

微服务下小团队集群的结构不可避免的需要更多的团队合作。一个运作良好的微服务生态圈背后是一个紧密协作的小团队网络，而团队之间的合作就是这个网络里无形的手。合作很多时候是团队和团队在运营过程中实时发生的，并非是预先设定或中央控制的，这个时候如何高效合作就成了一个很大的挑战。

在共同满足业务需求的过程中，大多数的合作是由于实现过程中服务之间的集成关系产生的。如前面讨论组织结构时的案例，很多组织在转型后反而集成多了，造成交流沟通成本持续增高，最后不得不安装很多会议和流程来“协调”这样的合作。结果当然是响应力越来越差，小团队名存实亡。

在团队合作方面DDD（领域驱动设计）原书中提出的（业务）限界上下文（Bounded Context）的关联关系可以借鉴。服务划分强调从业务视角出发，限界上下文提供了很好的划分指导，即可以根据限界上下文来设计相关的服务边界。由于每个服务对应一个小团队，那么实际上我们就建立了团队之间集成关系的模式。Eric Evans用了一个子章节描述了不同的基于领域模型耦合方式的关系模式（248页14.4），并零散地叙述了几个模式的演进场景，很多读者可能都不会特别关注那个章节。然而在微服务开始落地实施的时候，这些模式就变得十分重要了，因为这些模式本身也是团队之间的合作模式。

Eric Evans通过上面的矩阵总结告诉我们集成是高成本的，要尽量避免集成。同样道理在咱们团队合作的过程中，原则也是简化集成关系。在微服务架构下，显然右上角的“大泥球”（Single Bounded Context）和“共享内核”（Shared Kernel）是不推荐的；“独立自主”（Separate Ways）这种完全松耦合的关系是值得我们考虑的，但大多数情况下小颗粒度的服务之间还是会被不同的业务需求串联起来。

很多刚转型的企业会出现不少的“用户/供应商”（Customer/Suppier Teams)模式，主要是团队之间关系还是由更高层的领导在指挥，作为一个演进的合作关系应该更进一步向“开放主机服务”（Open Host Service）模式推进。现代的服务多是以API的形式更为规范的对外提供接口，所以其实在团队沟通方面的成本并非比领导中央决策高多少。

随着API规范的更进一步发展（如采用RESTful架构），很多时候服务团队之间只用做简单的翻译或遵从提供者的模型即可，耦合程度进一步下降，这个时候左下角的另外两种模式“防护层”（Anticorpution Layer）和“跟随者”（Conformist）就更为常见了。显然这两种模式集成关系更为简单，合作过程中调用服务的团队是不需要知道提供方的内部模型细节的，当然这个时候团队之间的信任关系也应该是相当高的。