分类: 组织运营变革

[摘要]

科技狂欢的时代,市场响应力是决胜法宝,小型化、微型化的组织结构成为了这个时代的主旋律。很多企业争相效仿Google扁平的小团队集群组织结构,却发现组织反而越来越低效。本文结合企业服务化转型的案例,给出小型化组织治理的三条基本原则,相信你能从中得到启发。

组织结构的小型化

站在第四次工业革命的风口,每天被各种创新和变化刷新着,从我们的工作到我们的生活都在改变,“唯一不变的是变化”。这似乎是一个科技狂欢的时代,却给我们这些企业管理者带来了巨大的挑战。“自组织”的救赎并没有那么容易实现,现实是从有章可循变成了“定制化”多元管理。深知市场响应力是这个时代的决胜法宝,但庞大的组织结构却成为了沉重的掣肘,以至于我们开始怀疑过去辛苦打造的管理体系是否多余。小型化、微型化成了这个时代的主旋律,从Amazon到海尔,组织的架构和管理也在同样经历着颠覆。

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

组织的两种基本模式示意

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

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

组织原则:对齐业务

科技时代带来的最大变化就是对变化本身的认知。在上一个时代,变化被认为是高成本甚至是有害的,大家总是希望能够尽量减少变化,或者能够循序渐进地变化;而现在我们会认为变化是必然的,它会带给我们新的市场机会,甚至会引发颠覆式创新。 由于这样的认知变化,企业必须具备相应的灵活性,而扁平的小团队集群组织结构被不少企业(例如Google和韩都衣舍)证明是提供这种灵活性的有效组织方式。很多企业争相效仿,但会发现并没有得到预期的灵活性,反而做事情更为复杂了,以前一个接口部门变成了现在的多个团队。

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

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

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

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

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

不同业务空间的Customer概念

以上的例子在很多走向服务化组织结构的企业里比比皆是,而遇到问题时大家更容易从看似明确的技术或管理手段入手。遇到这样的挑战时,别忘了康威定律。

管理原则:适应不确定性

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

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

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

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

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

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

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

合作原则:简化集成关系

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

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

在团队合作方面,《领域驱动设计》一书中提出的业务限界上下文的关联关系可以借鉴。服务划分强调从业务视角出发,限界上下文提供了很好的划分指导。由于每个服务对应一个小团队,那么实际上我们就建立了团队之间集成关系的模式。在微服务开始落地实施的时候,其中描述的基于领域模型耦合方式的关系模式,就变得十分重要了,因为这些模式本身也是团队之间的合作模式。

限界上下文关系模式要求矩阵(领域驱动设计,248页14.4)

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

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

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

结语

采用微服务架构后,自然会产生小团队扁平化组织结构,我们应该意识到在组织、管理、合作的原则及思维观念上都应该发生转变,忽略任何一个方面最终都会造成转型的失败。

  • 在组织结构上,团队划分要面向业务能力,持续提供市场价值。
  • 在企业管理上,管理者要拥抱不确定性,持续提升管理适应力。
  • 在团队合作上,考虑跨团队领域模型的耦合,持续简化集成关系。

无论我们是否采用微服务架构,组织想要持续响应外部变化、获得灵活性,就必须在组织级架构上“小型化”。组织管理上,我们必须适应和促进这样的架构落地和持续演进。起步必然是痛苦的,正如老子千年前指出“一生二 二生三 三生万物”,包容多样性是全局管理的精髓。

同海尔张瑞敏的认知一样,我认为有着这种全局视角基因的中国哲学,可能在这个时代的组织管理上大放异彩。


更多精彩商业洞见,请关注微信公众号:ThoughtWorks商业洞见

Share

发表评论

评论