首页 › 组织设计与治理 › 职能制、事业部制与矩阵制
组织设计与治理 · 组织结构设计

职能制、事业部制与矩阵制

按专业分还是按产品分,总有活儿落在接缝上。

Functional, Divisional and Matrix Structures◷ 约 5 分钟▤ 3 个真实故事换成 AI 要改一改在知识地图里看它和谁相连 →

2013 年 7 月 11 日,微软每一位员工都收到了首席执行官史蒂夫·鲍尔默的一封邮件,标题是「One Microsoft」(一个微软)。信里宣布了一次「影响深远的公司重组」。

那时的微软,是按业务集团组织起来的。鲍尔默要全公司站到「同一个战略」后面,作为一家公司,不再是「一堆事业部各自的战略」;要大家把产品线当成一个整体来看,「而不是一座座孤岛」。

然后,他重画了组织图:「这意味着,我们将按职能来组织公司。」市场、财务、人力资源、法务等职能各自归拢,工程分成四块:操作系统、应用、云和设备。从游戏机到移动设备、从 PC 到后台系统,所有操作系统的活儿,归进同一个工程组。

可要是一直读到末尾,这封信画的不止一张图。

一封信,三种形状

Dynamics 这块业务照旧单列,理由是它「仍需要特别关注」。负责人「照现在的样子」继续管,只是挂上了三条虚线:产品负责人虚线汇报给管应用与服务的人,市场负责人虚线汇报给管市场的人,销售负责人虚线汇报给首席运营官那一组。信里还写着:「公司的每个重大项目(一个产品,或一个高价值场景)都会有一支跨部门的团队。」

一封把微软改成职能制的信,同时留下了一个事业部,又在上面铺了一张跨部门的网。职能制、事业部制、矩阵制,三样一封信里全齐了。

按专业分还是按产品分,总有活儿落在接缝上。

后厨和美食广场

大饭店的后厨按岗位分:有人管酱汁,有人管烧烤,有人管点心,一道菜要经过好几个岗位才上桌。美食广场按档口分,每个档口从头到尾做自己的整张菜单。

职能制就是后厨。工程师和工程师坐在一起,标准统一,同一样东西做两遍的可能也小一些。麻烦在于,每个产品都得穿过每个部门,各部门真正碰头的地方,只在很高的那一层。事业部制就是美食广场:每个产品或市场,配齐自己的一整套职能,有一个人为结果负责。一位亚马逊前经理把公司的「两个披萨团队」叫作「事业部制的极致」:每个团队和高管层商定一个业务指标,按它来跑。代价是重复建设,还有鲍尔默想消灭的那些孤岛。

事业部制有个早期样本出自杜邦。按杜邦自己的说法,1921 年,公司执行委员会把管理分散下去,炸药、油漆、染料这些产品部门各自建起了应用研究。哈佛商学院的一个案例把这种结果叫作「『M 型』,即多事业部组织形式」。

矩阵想两头都要:一个人坐在产品团队里,同时还向职能负责人汇报。组织设计学者杰伊·加尔布雷斯写过:「当两项或更多的活动必须同时完成、又不能互相妨碍时,就会出现矩阵组织。」1978 年,斯坦利·戴维斯和保罗·劳伦斯在《哈佛商业评论》上写矩阵组织的「一些严重病症」,文章第一句先打了预防针:「没有哪种组织设计或管理方法是完美的。」2012 年,Spotify 的两位教练介绍他们的小队和分会时,自己替读者问了一句「这不就是矩阵制吗?」,回答是:「是。嗯,算是吧。」

三种形式里,没有哪一种放之四海而皆准。它们都是取舍,选哪种,要看这个组织最需要把什么做好。

设计师归谁

假设你带着六个设计师,公司有四个产品团队。产品经理们排队等设计排烦了,上面让你把设计师分进各个产品团队。

每个产品很可能都快了起来。可半年后,你也许会看到四个产品有了四种不同的日期选择器,你手下最年轻的设计师,做出东西来找不到人看。

折中的办法,是人坐在产品团队里,专业上仍向你汇报。这下每个设计师头上都有两个人能给她排优先级。产品的截止日期和设计标准撞车时听谁的,要是不提前说定,每个星期拍板的就是她自己,一个人。

不让测试员看代码

AI 智能体也会碰到同一个问题。2023 年 12 月首次发布的一篇论文里,香港大学的 Dong Huang 和同事介绍了 AgentCoder:写代码这件事,拆给三个智能体,一个写程序,一个设计测试,一个跑测试、把失败结果退回去。设计测试的那个,不看完整的代码就写测试,用作者的话说,免得测试「被代码带偏、受代码影响」。

他们拿它和另一种做法比:同一个智能体,在一段对话里先写代码、再写测试。在 HumanEval 基准上,以每道题的标准答案来检验,单个智能体写的测试正确的占 61.0%,单独的测试设计智能体是 87.8%。作者给了两个可能的原因:一身兼两职,可能分散注意力;紧跟着代码写出来的测试,会沾上代码里的毛病。他们的测试设计智能体还有专门设计的提示词,所以拆开并不是唯一的差别。

和质检部门一样,拆开换来的是独立;它也有老问题,接缝还在:测试设计者只知道需求,需求写得含糊,测试也就含糊。下回智能体替你写了代码又写了测试,开一个新会话,只给它需求,让它写测试,两套都跑一遍。两边结果对不上,是一条该拿需求去核对的线索,不是定论;模型每次跑的结果会不一样,多试几次。

退回老样子

鲍尔默的信并没有说新组织图已经画完。「这个组织的许多细节我们已经定了,但还有更多工作要做。」整个过程要持续到年底。他还补了一句:「在我自己的管理层会议上,我们在示范这些新特质,可也发现自己偶尔会退回老样子。」

六个星期后,8 月 23 日,微软宣布鲍尔默将在 12 个月内退休。「我们已经踏上了新的战略,有了新的组织,」他说,「我们需要一位能在更长时间里带着公司走这个新方向的 CEO。」

先看几件事

玩一玩

出处

  1. Steve Ballmer,One Microsoft(致全体员工邮件),微软,2013 年 7 月 11 日
  2. 微软,Microsoft CEO Steve Ballmer to retire within 12 months,2013 年 8 月 23 日
  3. 杜邦,History of the DuPont Company(特拉华州公共档案馆转载)
  4. 哈佛商学院案例,Du Pont: The Birth of the Modern Multidivisional Corporation(案例简介)
  5. Stanley M. Davis、Paul R. Lawrence,Problems of Matrix Organizations,《哈佛商业评论》,1978 年 5 月
  6. Jay R. Galbraith,The Star Model(概要),Galbraith Management Consultants
  7. Henrik Kniberg、Anders Ivarsson,Scaling Agile @ Spotify with Tribes, Squads, Chapters & Guilds,2012 年 10 月
  8. Jason Crawford,Amazon's "two-pizza teams": The ultimate divisional organization,2013 年 7 月 30 日
  9. Dong Huang、Jie M. Zhang、Michael Luck、Qingwen Bu、Yuhao Qing、Heming Cui,AgentCoder: Multi-Agent Code Generation with Effective Testing and Self-optimisation,arXiv 2312.13010(v3,2024 年 5 月)
  10. Henrik Kniberg and Anders Ivarsson, Scaling Agile @ Spotify with Tribes, Squads, Chapters & Guilds, October 2012
  11. Henrik Kniberg, Spotify engineering culture (part 1), Spotify Engineering, March 27, 2014
  12. Henrik Kniberg, No, I didn't invent the Spotify model, Crisp's Blog, June 7, 2015
  13. TalentLMS, Keep It Simple podcast with Henrik Kniberg (transcript)
  14. Jeremiah Lee, Spotify's Failed #SquadGoals, April 19, 2020
  15. Alan Deutschman, Inside the Mind of Jeff Bezos, Fast Company, August 2004 (archived)
  16. Jason Crawford, Amazon's "two-pizza teams": The ultimate divisional organization, July 30, 2013
  17. Werner Vogels, Modern applications at AWS, All Things Distributed, August 28, 2019
  18. AWS Executive Insights, Amazon's Two Pizza Teams