本文从 Adobe 和 Spotify 的不同组织架构入手，介绍了组织架构对公司战略的意义，介绍了常见组织架构模式的优缺点和陷阱，以及架构重组的方法。原文：The Hidden Architecture of Engineering[1]
简介
大多数工程领域领导者接手的都是现成的组织，组织架构早已成型，包括各种团队、汇报关系以及过往决策等等。人们往往会将这种组织架构视为理所当然的状态而习以为常。
但组织架构无形中影响着一切，决定了信息流动方式、决策制定过程、责任落实方式，以及公司能够以何种速度（快或慢）运转。组织架构图并非仅仅是个管理工具，还是整套系统设计的一部分。
多年来，我逐渐认识到，组织设计是技术领导者手中最强大的工具之一，但也是最不为人所理解的方面之一。就像无法在组织破损的情况下进行管理一样，也无法在架构存在缺陷的情况下编写代码。
继承现有体系
我仅有几次机会从零开始设计组织架构，通常是在初创企业阶段，更多时候接手的则是随着时间推移而逐渐形成的体系。有些是经过精心规划的结果，而另一些则像是野草般迅速蔓延开来。
每个组织都反映着其自身的历史。即便是临时的组织架构，也是过去决策的产物，是谁与谁进行了交流，哪些问题需要解决，哪些危机塑造了这家公司。
这就是康威定律[2]起作用的地方：组织会设计出与其沟通架构相匹配的系统。仔细观察产品架构，就会发现其中蕴含着该组织的组织架构图。
在我领导 Adobe 公司产品工程部门时，团队是按照职能进行划分的：一组团队专门负责构建后端系统，而其他团队则负责管理客户、核心库以及基础设施。这是当时的标准团队架构，但限制了我们的工作效率。每个功能都需要经过四个不同团队的审核，每个团队都按照自己的冲刺周期进行工作。因此，一个简单的功能可能需要数月才能完成开发，因为需要依次通过各个团队的审核环节。
当我加入 Spotify 时，公司架构完全不同。各个独立的、跨职能的小团队负责整个功能的开发工作。他们独立部署，并且行动迅速。系统的模块化设计正是源于团队的组织形式。
不同的问题，不同的架构。两者在各自情境中都具有一定的合理性，但教训是不变的：必须制定出自己的组织架构。
为目标而设计，而非遵循先例
许多公司对待组织架构设计的方式就像对待模板一样。有人会说："让我们采用像亚马逊那样的双披萨团队模式[3]"，或者"让我们借鉴 Spotify 模式[4]"。这种想法本身并无问题，但却缺失了背景信息。
亚马逊和 Spotify 构建了这些系统，是因为符合其企业文化、战略和规模要求。如果只是照搬形式而不了解其功能，那就如同复制另一家公司的代码库却不知其依赖项一样。
真正的问题并非"我们应该采用何种架构？ "而是"我们旨在解决何种问题，以及什么样的设计能让团队有效解决这个问题？"
架构就是将策略具体化的过程。出色的设计会将激励机制、沟通模式以及所有权界限与目标相匹配，在需要的地方建立高效的沟通渠道，在不需要的地方实现界限划分。
而且组织架构必须不断发展。为 20 人的初创企业服务的组织，在规模扩大到 100 人时就会出现瓶颈。而服务于 500 人的组织，在规模达到 2000 人时就会不堪重负。就像软件架构一样，组织设计永远都不会完成。
诊断问题所在
你不会因为组织老旧就对其进行重新设计，而是会因为存在某些无法解决的问题而进行重新设计。
最常用的诊断方法很简单：关注工作本身。
选取一个功能或故事，追溯其从构思到实际开发的过程，会经过多少团队的处理？会有多少次交接？会处于闲置状态多久？
每一次延误都是一条线索。有时是资源分配问题，有时是团队中缺少某种技能。但通常会揭示出更深层次的不协调：职责划分不清、依赖关系过多、信任度不足。
在 Adobe 公司，这种做法让瓶颈问题变得一目了然。每个功能依次需要经过四个团队的处理，而一个简单改动可能会因为交接问题而耗时三个月。而在 Spotify 公司，各个团队负责整个开发流程，在一个冲刺周期内就能完成同样的工作。这并非什么神奇的技巧，而是经过精心设计[5]的产物。
如果想了解为何组织运转缓慢，那就深入研究一下相关情况吧。
团队拓扑架构的启示
如果康威定律解释了架构与系统为何会相互映射，那么马修·斯凯尔顿和曼努埃尔·派斯所著的 团队拓扑架构[6] 则提供了一套围绕这一现实进行设计的工具。
他们将团队划分为四种核心类型：
- 以流水线方式运作的团队能够全面负责一项产品或工作流程。
- 协助团队则帮助其他团队改进工具或提升技能。
- 复杂子系统团队负责专业领域的特定工作。
- 平台团队创建共享系统以减轻认知负担。
他们还描述了团队互动的三种方式：暂时紧密合作 、提供服务 或促进学习。
其价值并不在于框架本身，而在于其中所使用的词汇，能帮助领导者摒弃等级制度的观念，转而思考"流程"而非"层级"，并设计出能够减少阻碍的架构。
当我阅读《团队拓扑架构》一书时，发现书中所阐述的内容与我们此前在 Spotify 所采取的措施有很多相似之处。但也看到了之前工作中的一些模式，如今回过头来看，这些模式突然变得清晰起来。这本书并没有给出具体指导，而是起到了解释说明的作用。
常见模式与陷阱
大多数组织在发展过程中会遵循一些固定模式。
功能型孤岛在初期运作良好，但随后会变得脆弱不堪。该模式使得协调工作变得明确，但同时也导致效率低下。
跨职能团队能提高自主性和效率，但也会带来更高的成本。在 Spotify 公司，这意味着需要招聘比其他大多数公司都多的移动开发人员。这种方法之所以有效，是因为该公司注重提高效率而非限制员工数量。
集中式数据或基础设施团队初期表现良好，但随后会逐渐形成瓶颈。需要提前预见何时应将这些能力进行分配。
矩阵式组织在人员调换团队时能够保持业务的连续性并减少混乱，但同时也会迅速增加复杂性。只有当责任划分明确清晰时，这种组织形式才最为有效。
接下来要讲的是一种最常见的反常做法：根据个人特点进行设计。围绕某个人的长处构建组织架构，或者避开其短处，这种做法在短期内或许看起来可行。但随着时间的推移，往往会变成一种负担。
重组即重构
当某个架构无法正常运行时，应将其视为一次重构而非彻底变革。
不要把一切都搞砸。要进行小幅度、有计划的调整。要清晰说明正在解决的问题以及衡量成功的标准。要明确试图解决的问题，以及在架构改变无法解决问题的情况下该如何应对。
领导者所犯的最大错误在于，他们只是在对员工进行重组，而没有真正与员工共同参与决策。当变革的理由不为人知时，这种变革就会显得毫无道理可言。如果员工能够理解问题所在，即便他们并不喜欢这个解决方案，也会选择接受。
每一次组织架构的调整都会带来一定的社会技术方面的成本。这可不是简单的物品移动过程，而是涉及到关系的改变、沟通渠道的调整以及身份的转变。处理此类事务时，务必清晰且谨慎。
重组应被视为是对系统的重新调整，而非彻底的变革。
以设计引领
组织设计并非一次性任务，而是持续的领导行为。
首先，对当前系统进行梳理：明确谁与谁进行沟通，决策过程中出现停滞的情况在哪里，以及所有权归属是否模糊。然后根据战略和企业文化来调整这一结构。
设计清晰的团队间及角色间的交互界面，仔细进行迭代，说明理由，并收集反馈意见。
让你来到这里的那套架构或许无法带你抵达所期望的目的地，但没关系，优秀的组织就像优秀的建筑一样，会不断发展变化。
如果你不将公司描绘成一个有方向且无循环的图中的一个个方框和线条，而是将其视为信息与工作的流动状态，那会呈现出怎样的景象呢？其中会有哪些阻碍？又会有哪些地方会充满活力呢？
那幅图并非官方的组织架构图，而是一张系统图，它才是你每天所构建的真实架构。
你好，我是俞凡，在Motorola做过研发，现在在Mavenir做技术工作，对通信、网络、后端架构、云原生、DevOps、CICD、区块链、AI等技术始终保持着浓厚的兴趣，平时喜欢阅读、思考，相信持续学习、终身成长，欢迎一起交流学习。为了方便大家以后能第一时间看到文章，请朋友们关注公众号"DeepNoMind"，并设个星标吧，如果能一键三连(转发、点赞、在看)，则能给我带来更多的支持和动力，激励我持续写下去，和大家共同成长进步！
参考资料 [1]
The Hidden Architecture of Engineering: https://medium.com/@kevingoldsmith/the-hidden-architecture-of-engineering-6aa290d0b63c
2
康威定律: https://www.melconway.com/Home/Conways_Law.html
3
双披萨团队模式: https://aws.amazon.com/executive-insights/content/amazon-two-pizza-team
4
Spotify 模式: https://blog.crisp.se/wp-content/uploads/2012/11/SpotifyScaling.pdf
5
The Spotify model: how to create, dissolve, and remix teams to be more dynamic and more innovative: https://blog.kevingoldsmith.com/2015/03/23/the-spotify-model-how-to-create-dissolve-and-remix-teams-to-be-more-dynamic-and-more-innovative
6
团队拓扑架构: https://amzn.to/4nXiznc
本文由mdnice多平台发布