团队拓扑：软件与组织之间的完美融合 - Matthew Skelton

Matthew Skelton与 Manuel Pais 合著了《团队拓扑：组织业务和技术团队以实现快速流程》一书，这是一篇开创性的文本，讲述了如何围绕软件对您的特定组织的角色构建最佳团队结构。
Matthew 在 2018 年、2019 年和 2020 年被 TechBeacon 评为 DevOps 最值得关注的 100 人之一。他在 devopstopologies.com 上策划了著名的 DevOps 团队拓扑模式。他还是 Conflux 的咨询主管，专门研究现代软件系统的持续交付、可操作性和组织动态。
在这次谈话中，马修帮助强调了数字化转型对公司的真正影响，以及它对团队协调的意义。
 
重要见解：
1. 交付和运行软件已成为企业或组织取得成功的一个非常重要的方面。Matthew 指出了组织考虑更高层次、更高水平的创新的重要性，并真正考虑组织在 IP 上的投资，完全所有业务流程推向商品低代码或无代码平台，存在真正的危险，即该组织实际上没有任何有用的知识产权；而传统经验法则是围绕核心业务使命集中精力制作软件。这需要对组织的哪些方面真正重要或独特（或接近独特）保持诚实和现实。如果这些方面不是您的组织特有部分，那么你不应该围绕它构建软件；这些是您应该从软件即服务的生态系统中提取的东西。（banq：核心子域与通用、支持子域区别）
 
2. 康威定律基于以下观察：组织内部的通信形式与所生产的软件形式之间存在“镜像效应”。这进一步意味着组织的沟通路径的形状是对其解决方案搜索空间的限制。传统上，由于组织在功能方面非常孤立，这限制了他们可以找到的解决方案类型，以及找到解决方案的速度。为了避免康威定律的这些负面影响，Matthew团队拓扑提倡零交接的跨职能团队，以“确保我们的组织沟通不会与我们想要找到的解决方案冲突”。这进一步使组织能够快速响应市场环境。
 
3. 团队拓扑确定了四种主要的团队类型，以实现快速流程。

• “流对齐团队”是起点，一个最多 15 人的团队（最好是 8-9 人），具有“端到端的职责，没有交接，非常接近客户，并长期负责特定部分业务领域、服务、产品、用户旅程等”。其他团队类型为流对齐的团队服务。
• “支持团队”有助于弥合能力差距，这可能有助于流对齐团队了解如何更好地使用某种机器学习或数据、基础设施或技术实践。
• “复杂的子系统团队”很少见，但可以形成以从流对齐的团队中消除非常专业的认知负担。
• 最后，“平台团队”（称为内部平台）带走了数据、机器学习、基础设施或部署功能方面的流对齐团队的一些非差异化细节。同样，这种支持团队类型的决策标准是减少认知团队的负担，由流对齐的团队来采用它。