本文从 Adobe 和 Spotify 的不同组织架构入手，探讨组织架构对公司战略的意义，分析常见组织架构模式的优缺点与陷阱，并分享架构重组的方法。原文：The Hidden Architecture of Engineering [1]
大多数技术领导者在接手团队时，面对的都是一个已经成型的组织：固定的团队划分、明确的汇报关系以及一系列历史决策。我们很容易将这种结构视为理所当然，甚至是一种“自然状态”。
然而，组织架构绝不仅仅是管理图上那些方框和线条。它在无形中塑造着一切——信息如何流动、决策如何制定、责任如何归属，以及整个公司能以多快的速度运转。从某种意义上说，组织结构图本身就是一套复杂的系统设计。
我逐渐意识到，组织设计是技术领导者手中最强大，但也最容易被误解的工具之一。这就像你无法在破损的组织上实现有效管理，也无法在一个存在架构缺陷的系统上顺畅地编写代码。
继承的体系：从 Adobe 到 Spotify
我很少有从零开始设计组织架构的机会，那通常只发生在初创阶段。更多时候，我接手的都是一个随着时间推移自然生长的体系，有些是精心规划的成果，有些则像野草般蔓延。
每个组织都镌刻着自身的历史。即便是看似临时的架构，也是过去一系列决策的产物：谁和谁讨论过问题，哪些挑战被优先解决，哪些危机塑造了公司的今天。这正是康威定律 [2] 发挥作用的地方：组织设计出的系统，其结构会复制该组织的沟通结构。仔细观察一个产品的技术架构，你往往能从中窥见其组织架构的影子。
在领导 Adobe 的产品工程部门时，团队是按照职能划分的：一组团队专门构建后端系统，其他团队则分别负责客户管理、核心库和基础设施。这在当时是标准做法，但它极大地限制了我们的效率。每个新功能的开发都需要流经四个不同的团队，每个团队都有自己的开发冲刺周期。结果呢？一个简单的改动可能需要数月才能完成，因为它必须排队等待每个团队的“审核”。
当我加入 Spotify 时，情况完全不同。这里由一个个独立、跨职能的“小团队”构成，每个团队都能负责一个完整功能的端到端开发。他们可以独立部署，行动迅速。整个系统的模块化特性，正是源于其团队的组织形式。
不同的问题，催生了不同的架构。两种模式在各自的背景下都有其合理性，但教训是共通的：你不能被动接受现成的架构，而必须主动设计它。
为目标而设计，而非盲目模仿
许多公司在设计组织架构时，像是在套用模板。比如有人说：“我们采用亚马逊的双披萨团队模式 [3]吧”，或者“直接借鉴 Spotify 模式 [4]”。借鉴本身没错，但问题是常常忽略了背后的上下文。
亚马逊和 Spotify 构建这些模式，是为了匹配其独特的企业文化、战略目标和公司规模。如果只复制形式而不理解其功能，就像复制了另一家公司的代码库却不知道它依赖哪些库一样。
真正的问题不应该是“我们应该采用哪种架构？”，而应该是“我们要解决什么问题？什么样的设计能让团队最高效地解决它？”
架构是将战略具体化的过程。优秀的设计会让激励机制、沟通模式和权责边界与目标对齐——在需要高效协作的地方建立通道，在需要清晰界定的地方划清界限。
而且，组织架构必须持续进化。服务于20人初创公司的架构，在团队增长到100人时就会出现瓶颈；而能支撑500人的架构，在规模达到2000人时可能会彻底失灵。和软件架构一样，组织设计也永远没有“完成”的一天。
如何诊断组织的问题？
你不会因为架构“旧了”就重组，而是因为存在某些无法解决的问题才会考虑重组。
最有效的诊断方法其实很简单：追踪工作的实际流动路径。
挑选一个具体的功能或用户故事，从构思开始，追踪它直到上线的全过程。它流经了多少个团队？经历了多少次“交接”？又在哪些环节被闲置了多久？
每一次延迟都是一条线索。有时是资源分配问题，有时是团队缺少某项关键技能。但更多时候，它会揭示更深层次的结构性失调：职责划分模糊、依赖关系过多、或是团队间缺乏信任。
在 Adobe，这种方法让瓶颈一目了然。一个功能需要依次经过四个团队，一次简单的交接失误就可能导致三个月的延迟。而在 Spotify，由于团队能够端到端负责，同样的工作可能在一个冲刺周期内就完成了。这不是魔法，而是精心设计 [5] 的结果。
如果你想弄明白组织为何运转缓慢，不妨深入追踪一下工作的实际旅程。
团队拓扑的启示
如果康威定律解释了架构与系统为何会相互映射，那么马修·斯凯尔顿和曼努埃尔·派斯所著的 《团队拓扑》 [6] 则提供了一套围绕这一现实进行设计的实用工具。
他们将团队划分为四种核心类型：
- 以流水线方式运作的团队：能够全面负责一项产品或工作流程的端到端交付。
- 协助团队：帮助其他团队改进工具或提升特定技能。
- 复杂子系统团队：处理需要专业知识的特定领域或复杂模块。
- 平台团队：构建共享的内部平台或服务，以降低其他团队的认知负担和重复工作。
此外，他们还定义了团队互动的三种基本模式：为特定目标协作、以明确接口提供服务、或促进知识与学习的流动。
这套框架的价值不在于其规定性，而在于它提供了一套通用词汇。它帮助技术领导者超越传统的层级思维，转而从“工作流”和“交互模式”的角度思考，从而设计出能够减少摩擦和阻碍的架构。
当我阅读《团队拓扑》时，发现其中很多理念与我们在 Spotify 的实践不谋而合。同时，我也以一种全新的视角看清了过去工作中的一些模式。这本书没有给出标准答案，但它提供了解释和设计语言，关于系统设计与团队协作的思考总能在这里找到共鸣。
常见的架构模式与陷阱
大多数组织在发展过程中都会不自觉地滑向一些常见模式。
- 功能型孤岛：初期运行良好，但会逐渐变得僵化。它使协调工作变得明确，但也导致了效率低下和沟通壁垒。
- 跨职能团队：能极大提升自主性和交付速度，但代价是更高的资源成本（例如，Spotify 需要比一般公司招聘更多的移动开发者）。这种模式成功的关键在于，公司更看重产出效率而非单纯控制人数。
- 集中式数据或基础设施团队：在初期能有效保证一致性和质量，但极易随着公司规模扩大成为瓶颈。关键在于要预见到何时需要将这些能力下放或去中心化。
- 矩阵式组织：在人员需要跨项目流动时能保持业务连续性，减少混乱，但也迅速增加了管理的复杂性。只有当“虚线”和“实线”汇报关系中的责任无比清晰时，它才能良好运作。
还有一种最常见但也最应警惕的反模式：围绕个人特质进行设计。根据某个人的长处来构建团队，或者为了避开其短处而扭曲架构，短期内或许可行，但长远来看，这几乎总会变成一个沉重的包袱，影响高并发与复杂项目的稳定推进。
重组如同重构
当一个架构开始失效时，应将其视为一次重构，而非一场革命。
不要全盘推倒重来。应该进行小规模、有计划的调整。清晰地阐明你正在解决什么问题，以及你将如何衡量调整是否成功。明确如果架构改变未能解决问题，后备方案是什么。
领导者常犯的最大错误是：只对“人员”进行重组，却没有让“人员”参与到决策过程中。当变革的理由不为人知时，变革本身就会显得武断和毫无道理。如果团队成员理解了问题所在，即使他们不完全喜欢这个解决方案，也更容易接受。
每一次组织调整都会带来社会与技术层面的双重成本。这不是简单地移动棋盘上的棋子，而是改变人际关系、沟通渠道乃至个人身份认同。处理此事，必须清晰且富有同理心。
重组应被看作是对系统的校准与调优，而非推倒重建。
以设计思维引领
组织设计不是一劳永逸的任务，而是一种持续的领导实践。
首先，梳理你现有的系统：弄清楚信息在谁与谁之间流动，决策在哪里停滞，权责归属在何处变得模糊。然后，根据你的战略和文化来调整这个结构。
设计清晰的团队间、角色间的“交互接口”。进行小步迭代，充分说明理由，并积极收集反馈。
带你走到今天的那套架构，很可能无法带你抵达明天想去的地方。但这没关系，优秀的组织就像优秀的建筑，本身就应该具备可演进性。
如果你不再将公司看作组织结构图上那些静态的方框和线条，而是将其视为信息流与工作流的动态网络，那会是怎样一幅图景？其中哪些地方存在淤塞？哪些地方又充满了活力？
那幅动态的网络图，才是你每天在构建和运维的、真实的工程架构。在云栈社区的技术讨论中，我们经常探讨如何让这幅“图”更清晰、更高效。
参考资料
[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
发表于 3 小时前
|
查看: 3|
回复: 0
