最近在思考关于软件研发效能的事情，而其中关于组织层面有一些想法和总结，如下：

康威定律和逆康威定律

在 1968年，梅尔·康威在《Datamation》杂志发表文章《How Do Committees Invent?》，探讨了组织结构和系统设计的关系。其中一句话后来被总结为康威定律:「任何组织所设计的系统架构，都不可避免的反映为该组织沟通结构的副本。」

康威在开发早期电子计算机系统的组织中观察到，组织的真实沟通路径(即价值创造架构)与最终的软件架构之间存在强相关性。这种同态力将软件架构和团队结构塑造成相同的「形状」。也就是说，构建软件需要理解团队沟通路径，以更加实际地考虑什么样的软件架构是可行的。如果理论上的系统架构与组织模型不符，就需要对其中之一做出改变。

当组织结构变化时，系统架构就会被影响，身在局中的我们感触非常深刻，本来负责 A 业务，调整后负责 B 业务，原来的工作就不想动了；本来在重构某块技术，想把历史的债务还清先，调整后也没有了动力。

作为一个技术人面对这种情况，有时也无能为力，调整后大量的时间是投入在当前的业务中，而看到的历史问题不在你的工作边界之中，只能看着历史债务越集越多，直到某一天，雪崩。

特别是后端，作为业务核心的技术部分，一个 24×7 要在线的，其稳定性，可用性都是非常重要的。

如何通过系统化的机制保障后续架构的稳定演进，并且不会随着组织结构的频繁变动而频繁变动？

要想抵抗组织结构对系统架构的影响，一种办法是适度隔离，比如采用内部开源的方式，让系统脱离具体业务组织而存在，代码由核心小组统一维护。这种虚拟组织不会随业务变动而变动，适用于底层框架、中间件等非业务模块。

但对于业务属性较高的模块，内部开源并不可行。因为其开发和维护需要对业务有深入理解，跨部门的认知成本太高。这时就需要换一个思路：利用康威定律，通过优化团队架构来引导系统架构，减少沟通和认知成本，实现理想的、高内聚低耦合的架构闭环。这就是逆康威定律的应用。

逆康威定律是 2015 年微服务兴起之际，ThoughtWorks 技术总监 James Lewis 提出的概念，即组织要根据他们想得到的软件架构来设计团队结构，而不是期望团队盲从一个被设计好的团队结构。。

其中的核心观点在于，将软件架构看作一个独立的概念，认为它可以被孤立设计，然后交由任何团队来实现，这从根本上就是错误的。软件架构和团队结构的差异在所有架构类型中比比皆是，无论是客户端-服务端、SOA 还是微服务架构。这也是为什么为了让团队聚焦，单体架构需要拆分的原因。

通过逆康威定律的应用，我们可以先设计出理想的软件架构，然后根据这个架构来调整和优化团队结构。这样做的好处是可以更好地匹配业务需求，提高系统的内聚性和可维护性，减少不必要的沟通和协调成本。

具体来说，我们可以采取以下措施：

1. 根据业务领域划分微服务，每个微服务由一个独立的团队负责开发和维护。这样可以让团队对自己的服务有更清晰的认知和掌控，减少跨团队沟通。
2. 建立跨团队的架构治理机制，制定统一的架构原则、接口规范、质量标准等，确保微服务之间的一致性和互操作性。
3. 加强团队内部的自治和责任心，鼓励团队自主决策、快速迭代、持续改进。同时赋予团队端到端的交付职责，避免因职责割裂导致推诿扯皮。
4. 建设公共的技术平台和工具链，提供标准化的开发、测试、部署、监控等功能，减轻团队的基础设施负担，提高研发效率。
5. 营造开放协作的文化氛围，打破部门墙，鼓励团队之间主动沟通和知识共享，形成学习型组织。

康威定律揭示了组织结构与系统设计的同构关系，而逆康威定律则为我们指明了一条突破之路：从组织架构入手，持续优化团队分工，才能推动系统架构向理想方向演进。这需要我们在组织设计上投入更多思考，用系统思维来对待研发效能问题。

团队的认知负载

认知负载是指在特定时间内，工作记忆中的信息负荷。对于个人而言，认知负载就是大脑需要同时处理的信息量。当我们将视角拓展到团队层面时，认知负载就变成了团队在执行任务时所承担的信息处理总量。

一个团队的认知负载并不等于团队成员认知负载的简单加总。团队协作过程中产生的交流、同步、协调等活动，都会带来额外的认知负载。同时，团队成员之间知识和技能的差异，也会影响到认知负载在团队内部的分配。

团队的认知负载也是影响软件研发效能的重要因素。

当系统复杂度超出团队的认知极限时，就会导致生产力下降、质量恶化等问题。

控制认知负载的关键，在于团队内部的”通晓全局”程度，即每个成员对系统的整体理解。

那如何判断团队是否处于认知过载状态？

可以从任务执行、团队氛围、个人状态三个维度来观察。

从任务执行的角度看，如果团队在面对新需求时响应速度明显变慢，对变更的适应能力下降，出现更多交付物质量问题，需要更多的返工和修复，这就是认知过载的典型信号。团队投入了更多的时间和精力，但产出的绩效却在下降，说明认知资源已经难以支撑高质量高效率的工作。

从团队氛围的角度看，如果团队成员之间的沟通变得低效和困难，产生更多的误解和冲突，知识共享和协作的意愿下降，整个团队的创新能力和解决问题的能力下降，团队士气低落，抱怨和消极情绪在蔓延，这也提示团队正在经历认知过载。当团队的认知资源捉襟见肘时，成员往往会降低对他人和整体的关注，转而专注应对自己的工作压力。

从个人状态的角度看，如果团队成员普遍感到疲惫和倦怠，对工作失去热情和主动性，工作与生活难以平衡，出现失眠、健康问题等身心状况，这往往是认知过载的结果。当个人长期处于高认知负荷状态，既要应对本职工作，又要参与大量协调和沟通，还要不断学习新知识，就很容易产生持续的压力感，陷入职业倦怠。

团队认知过载不是孤立的问题，而是会从任务执行、团队氛围、个人状态等方面综合反映出来。作为团队管理者，需要保持敏锐的洞察力，及时捕捉这些危险信号，采取针对性的优化措施，从而保障团队的可持续发展。

为了降低认知负载，我们可以从组织设计和架构设计时都做一些考虑。

在组织设计时，可以考虑如下几点：

1. 适度聚焦。每个团队应该有明确的、聚焦的职责范围，避免过度分散精力。职责范围要与团队的认知能力相匹配，既不能太窄导致产能不足，也不能太宽导致认知过载。
2. 职责自治。团队对自己的职责范围应该有较大的自主权，可以独立做出决策和优化。过多的外部依赖会增加认知负载。
3. 边界清晰。团队之间、系统模块之间应该有清晰的边界和接口，减少耦合和认知依赖。
4. 知识共享。鼓励团队之间主动分享知识和经验，建立共同的认知基础。但要注意，知识共享不等于职责共担。
5. 弹性冗余。在关键领域，适当保留一定的冗余和备份，避免单点依赖。这样可以在保证产出的同时，降低认知负载的风险。

在架构设计时，可以考虑如下几点：

1. 模块化和解耦。将系统划分为逻辑清晰、职责单一的模块，并通过松耦合的方式连接，减少模块之间的认知依赖。每个团队只需深入理解自己负责的模块。
2. 接口驱动。通过定义清晰、稳定的接口规范，将模块的内部实现和外部用途解耦。调用方只需了解接口，而无需关心内部细节。
3. 领域建模。从业务领域出发，识别出稳定的核心业务概念和流程，并据此设计系统模型。让软件架构尽量贴近真实世界，减少认知转换。
4. 约定优于配置。通过制定统一的架构原则、编码规范、工具约定等，在团队之间形成一致的认知基础，减少沟通成本。
5. 演进式架构。架构不是一成不变的，而是随着业务和技术的发展而不断演进的。因此要为变化留出空间，通过持续重构等手段，让系统在可控的范围内优化，避免大规模的推倒重来。

通过对认知负载的有效管理，我们可以显著提升团队的工作效率和整体协同能力。

认知负载，说到底是对人的真正尊重。而尊重，恰恰是最好的管理。

三种常见的团队组织

业务交付团队

业务交付团队，是组织中最主要和基础的团队组织。

业务交付团队是围绕清晰目标和职责，匹配持续变化的业务价值交付任务，形成独立高效工作流的长期、稳定、跨职能团队。

一个业务交付团队通常对应一条单一、完整的价值交付流，可以是一个产品、服务、功能集合、用户故事或用户画像等。团队拥有端到端的能力，能够独立完成从概念到交付的全部工作，快速、安全地持续创造用户价值，而无需依赖其他团队。

业务交付团队要尽可能贴近最终用户，通过生产环境实时监控，获得快速反馈，并据此迅速响应变化和问题。团队规模适中，由高素质的跨职能成员组成，保持长期稳定性，而不是随项目起起落落。

组织内通常存在多种业务交付团队，各自负责不同的业务流，如特定用户、业务领域、地理区域、产品条线等。无论承接何种业务流，团队都应围绕明确的待办事项和优先级开展工作，确保工作流的清晰和聚焦。

一个高效能的业务交付团队应该是这样的：

• 他们的工作就像一条流水线，特性开发的各个环节衔接顺畅，没有太多卡壳和浪费
• 团队时刻关注用户反馈和业务变化，能够灵活调整开发计划和优先级
• 他们勇于尝试新事物，通过小步快跑的试错方式来推动改进，并善于从成功和失败中吸取教训
• 团队内部各司其职、协同高效，很少需要跟其他团队交接工作
• 他们交付的速度又快又稳，代码质量也有保障，还能兼顾技术升级和团队成员的健康
• 团队会投入时间优化系统架构和代码，「修修补补」以防「房子」越来越破
• 他们懂得借助专业团队的力量，定期跟架构、基建、工具等团队沟通，补齐短板，让自己更专注
• 团队成员有足够的自主权，在技能上精益求精，工作目标明确，从而获得成就感和价值感

业务交付团队是组织的一线力量和价值核心，其他辅助型团队如技术智囊团和基建平台等，都是为了补齐能力短板、降低认知负载，让业务交付团队得以更高效地运转和创新。这种以业务交付为中心的团队组织模式，是相对于传统的职能式、项目式组织的一种进化。

组建长期、稳定、高度自治的业务交付团队，打造清晰的端到端业务流，是实现快速、频繁、可靠价值交付，适应快速变化的关键所在，代表了现代软件开发组织的进化方向。

平台团队

平台团队的目标是赋能业务交付团队，使其能够高度自治地交付工作。平台团队提供的内部服务，使业务交付团队无须开发底层服务，降低了认知负荷。这里的平台是指其作为公司内部的基础产品，向开发团队提供自服务的 API、工具、服务、知识和支持。借助平台，业务交付团队获得了自主性，可以更快地交付产品特性，减少开发过程中的各种协调、沟通。

业务交付团队可以方便地使用平台团队提供的自服务的网站门户和/或编程API（而非厚厚的使用手册）。「方便使用」是采纳平台的基本要求，并且平台团队必须将他们所提供的服务视为一种产品，无论这些服务是被内部还是外部用户所使用，要具有可信赖的、易用的、量身定做的特征。

平台团队可以提供不同级别的服务，但如果所有业务交付团队都要求高等级服务（如零停服务时间、自动扩缩容、自动修复），平台团队则难以支持。为避免人人都要求高等级服务，可以为这些内部基础设施和服务定价，向使用团队收费。

作为基础设施工程团队，平台团队需要聚焦于开发团队的工作流，以及应用和基础设施的改变如何影响用户。为了帮助开发团队用户更高效地使用平台，平台团队需要做到：

1. 把内部平台视为线上/生产系统，计划和管理维护时间
2. 引入软件产品管理和服务管理技术

一个高效能的平台团队应该有以下行为和产出：

• 与业务交付团队密切协作，理解其需求
• 依赖快速原型，尽早引入业务交付团队以获得快速反馈
• 重点关注服务的可用性和可靠性，将平台视为产品，定期回访用户以确认服务是否满足需求
• 自己也应是所提供服务的用户，与业务交付团队并肩战斗
• 明白新的内部服务将像创新曲线那样被逐步引入，而非一蹴而就

平台团队和传统的基础设施团队略有不同，突破了传统基础设施团队与业务团队之间的隔阂，通过提供自助式的平台服务，赋能业务团队快速构建和交付应用。与传统基础设施团队相比，平台团队更加贴近业务，团队成员除了技术能力外，还需要具备产品管理、用户体验设计等技能。

专业系统团队

在软件开发过程中，有一些模块或逻辑涉及高深专业领域知识而显得特别复杂，开发和维护都需要相关领域的资深专家（人也特别贵），对于这样的专业系统，我们通常会单独构建团队，称为为「专业系统团队」。

专业系统团队的成员都是某个领域的能手，精通子系统涉及的核心技术。比如 AI 算法模型、视频编解码、特定数学模型、实时交易算法、财务报表系统、人脸识别引擎等，都是典型的复杂子系统，需要专业系统团队来专门负责。

组建专业系统团队的主要目的，是为了给使用这些核心子系统的业务团队减负。本来这些「绝世武功」需要专业系统团队的「武林高手」倾囊相授，现在业务团队只管安心用就行了，不必自己还得练上几年。这样不仅能让每个团队专注自己最擅长的事情，也能节省组织的时间和成本。

需要注意的是，专业系统团队和传统的「组件团队」有本质区别。后者的设立往往是为了让多个团队共用同一个组件，而专业系统团队纯粹是为了「解决疑难杂症」，和代码复用无关。

那么，一个高效能的专业系统团队应该是什么样的呢?

• 在子系统的设计开发阶段，专业系统团队要和相关业务团队齐心协力，共同定义需求、制定计划、开发功能、测试验证，即「同进同出、战略合作」。到了后期子系统逐渐稳定了，专业系统团队就可以相对独立，专注于系统演进、接口优化等核心工作，和其他团队的互动会少一些。
• 有了专业系统团队的加持，子系统的开发质量和速度都要明显好于单靠业务团队的情况。这可以作为考核专业系统团队绩效的一个重要指标。
• 专业系统团队的工作安排要以服务好业务团队为宗旨。要紧贴一线，及时响应需求，灵活调整计划，按业务优先级来排期交付。

一些观点

• 并非所有的沟通和协作都是有价值的。
• 保持团队规模的相对稳定。
• 在实现软件交付之前，先统一团队语言和共同协作方式。
• 团队的代码所有权并非是在划分地盘。团队对代码的责任，不应该是「这是我的地盘，别人不能进来」，而应该是「这是我负责打理的一亩三分地，要让它生机勃勃」。
• 软件设计不是非黑即白的选择题，而是一种平衡，如在选择架构时，不是要在单体架构和微服务架构之间做出选择，而是要适配团队的最大认知负载。

以上。