组织结构决定了信息流动、资源分配和决策过程的效率。在研发效能的提升中,扁平化的管理层级、跨功能的团队配置以及灵活的人员动态管理,都能够促进创新和加速决策过程。
最近在思考关于软件研发效能的事情,而其中关于组织层面有一些想法和总结,如下:
在 1968年,梅尔·康威在《Datamation》杂志发表文章《How Do Committees Invent?》,探讨了组织结构和系统设计的关系。其中一句话后来被总结为康威定律:「任何组织所设计的系统架构,都不可避免的反映为该组织沟通结构的副本。」
康威在开发早期电子计算机系统的组织中观察到,组织的真实沟通路径(即价值创造架构)与最终的软件架构之间存在强相关性。这种同态力将软件架构和团队结构塑造成相同的「形状」。也就是说,构建软件需要理解团队沟通路径,以更加实际地考虑什么样的软件架构是可行的。如果理论上的系统架构与组织模型不符,就需要对其中之一做出改变。
当组织结构变化时,系统架构就会被影响,身在局中的我们感触非常深刻,本来负责 A 业务,调整后负责 B 业务,原来的工作就不想动了;本来在重构某块技术,想把历史的债务还清先,调整后也没有了动力。
作为一个技术人面对这种情况,有时也无能为力,调整后大量的时间是投入在当前的业务中,而看到的历史问题不在你的工作边界之中,只能看着历史债务越集越多,直到某一天,雪崩。
特别是后端,作为业务核心的技术部分,一个 24×7 要在线的,其稳定性,可用性都是非常重要的。
如何通过系统化的机制保障后续架构的稳定演进,并且不会随着组织结构的频繁变动而频繁变动?
要想抵抗组织结构对系统架构的影响,一种办法是适度隔离,比如采用内部开源的方式,让系统脱离具体业务组织而存在,代码由核心小组统一维护。这种虚拟组织不会随业务变动而变动,适用于底层框架、中间件等非业务模块。
但对于业务属性较高的模块,内部开源并不可行。因为其开发和维护需要对业务有深入理解,跨部门的认知成本太高。这时就需要换一个思路:利用康威定律,通过优化团队架构来引导系统架构,减少沟通和认知成本,实现理想的、高内聚低耦合的架构闭环。这就是逆康威定律的应用。
逆康威定律是 2015 年微服务兴起之际,ThoughtWorks 技术总监 James Lewis 提出的概念,即组织要根据他们想得到的软件架构来设计团队结构,而不是期望团队盲从一个被设计好的团队结构。。
其中的核心观点在于,将软件架构看作一个独立的概念,认为它可以被孤立设计,然后交由任何团队来实现,这从根本上就是错误的。软件架构和团队结构的差异在所有架构类型中比比皆是,无论是客户端-服务端、SOA 还是微服务架构。这也是为什么为了让团队聚焦,单体架构需要拆分的原因。
通过逆康威定律的应用,我们可以先设计出理想的软件架构,然后根据这个架构来调整和优化团队结构。这样做的好处是可以更好地匹配业务需求,提高系统的内聚性和可维护性,减少不必要的沟通和协调成本。
具体来说,我们可以采取以下措施:
康威定律揭示了组织结构与系统设计的同构关系,而逆康威定律则为我们指明了一条突破之路:从组织架构入手,持续优化团队分工,才能推动系统架构向理想方向演进。这需要我们在组织设计上投入更多思考,用系统思维来对待研发效能问题。
认知负载是指在特定时间内,工作记忆中的信息负荷。对于个人而言,认知负载就是大脑需要同时处理的信息量。当我们将视角拓展到团队层面时,认知负载就变成了团队在执行任务时所承担的信息处理总量。
一个团队的认知负载并不等于团队成员认知负载的简单加总。团队协作过程中产生的交流、同步、协调等活动,都会带来额外的认知负载。同时,团队成员之间知识和技能的差异,也会影响到认知负载在团队内部的分配。
团队的认知负载也是影响软件研发效能的重要因素。
当系统复杂度超出团队的认知极限时,就会导致生产力下降、质量恶化等问题。
控制认知负载的关键,在于团队内部的”通晓全局”程度,即每个成员对系统的整体理解。
那如何判断团队是否处于认知过载状态?
可以从任务执行、团队氛围、个人状态三个维度来观察。
从任务执行的角度看,如果团队在面对新需求时响应速度明显变慢,对变更的适应能力下降,出现更多交付物质量问题,需要更多的返工和修复,这就是认知过载的典型信号。团队投入了更多的时间和精力,但产出的绩效却在下降,说明认知资源已经难以支撑高质量高效率的工作。
从团队氛围的角度看,如果团队成员之间的沟通变得低效和困难,产生更多的误解和冲突,知识共享和协作的意愿下降,整个团队的创新能力和解决问题的能力下降,团队士气低落,抱怨和消极情绪在蔓延,这也提示团队正在经历认知过载。当团队的认知资源捉襟见肘时,成员往往会降低对他人和整体的关注,转而专注应对自己的工作压力。
从个人状态的角度看,如果团队成员普遍感到疲惫和倦怠,对工作失去热情和主动性,工作与生活难以平衡,出现失眠、健康问题等身心状况,这往往是认知过载的结果。当个人长期处于高认知负荷状态,既要应对本职工作,又要参与大量协调和沟通,还要不断学习新知识,就很容易产生持续的压力感,陷入职业倦怠。
团队认知过载不是孤立的问题,而是会从任务执行、团队氛围、个人状态等方面综合反映出来。作为团队管理者,需要保持敏锐的洞察力,及时捕捉这些危险信号,采取针对性的优化措施,从而保障团队的可持续发展。
为了降低认知负载,我们可以从组织设计和架构设计时都做一些考虑。
在组织设计时,可以考虑如下几点:
在架构设计时,可以考虑如下几点:
通过对认知负载的有效管理,我们可以显著提升团队的工作效率和整体协同能力。
认知负载,说到底是对人的真正尊重。而尊重,恰恰是最好的管理。
业务交付团队,是组织中最主要和基础的团队组织。
业务交付团队是围绕清晰目标和职责,匹配持续变化的业务价值交付任务,形成独立高效工作流的长期、稳定、跨职能团队。
一个业务交付团队通常对应一条单一、完整的价值交付流,可以是一个产品、服务、功能集合、用户故事或用户画像等。团队拥有端到端的能力,能够独立完成从概念到交付的全部工作,快速、安全地持续创造用户价值,而无需依赖其他团队。
业务交付团队要尽可能贴近最终用户,通过生产环境实时监控,获得快速反馈,并据此迅速响应变化和问题。团队规模适中,由高素质的跨职能成员组成,保持长期稳定性,而不是随项目起起落落。
组织内通常存在多种业务交付团队,各自负责不同的业务流,如特定用户、业务领域、地理区域、产品条线等。无论承接何种业务流,团队都应围绕明确的待办事项和优先级开展工作,确保工作流的清晰和聚焦。
一个高效能的业务交付团队应该是这样的:
业务交付团队是组织的一线力量和价值核心,其他辅助型团队如技术智囊团和基建平台等,都是为了补齐能力短板、降低认知负载,让业务交付团队得以更高效地运转和创新。这种以业务交付为中心的团队组织模式,是相对于传统的职能式、项目式组织的一种进化。
组建长期、稳定、高度自治的业务交付团队,打造清晰的端到端业务流,是实现快速、频繁、可靠价值交付,适应快速变化的关键所在,代表了现代软件开发组织的进化方向。
平台团队的目标是赋能业务交付团队,使其能够高度自治地交付工作。平台团队提供的内部服务,使业务交付团队无须开发底层服务,降低了认知负荷。这里的平台是指其作为公司内部的基础产品,向开发团队提供自服务的 API、工具、服务、知识和支持。借助平台,业务交付团队获得了自主性,可以更快地交付产品特性,减少开发过程中的各种协调、沟通。
业务交付团队可以方便地使用平台团队提供的自服务的网站门户和/或编程API(而非厚厚的使用手册)。「方便使用」是采纳平台的基本要求,并且平台团队必须将他们所提供的服务视为一种产品,无论这些服务是被内部还是外部用户所使用,要具有可信赖的、易用的、量身定做的特征。
平台团队可以提供不同级别的服务,但如果所有业务交付团队都要求高等级服务(如零停服务时间、自动扩缩容、自动修复),平台团队则难以支持。为避免人人都要求高等级服务,可以为这些内部基础设施和服务定价,向使用团队收费。
作为基础设施工程团队,平台团队需要聚焦于开发团队的工作流,以及应用和基础设施的改变如何影响用户。为了帮助开发团队用户更高效地使用平台,平台团队需要做到:
一个高效能的平台团队应该有以下行为和产出:
平台团队和传统的基础设施团队略有不同,突破了传统基础设施团队与业务团队之间的隔阂,通过提供自助式的平台服务,赋能业务团队快速构建和交付应用。与传统基础设施团队相比,平台团队更加贴近业务,团队成员除了技术能力外,还需要具备产品管理、用户体验设计等技能。
在软件开发过程中,有一些模块或逻辑涉及高深专业领域知识而显得特别复杂,开发和维护都需要相关领域的资深专家(人也特别贵),对于这样的专业系统,我们通常会单独构建团队,称为为「专业系统团队」。
专业系统团队的成员都是某个领域的能手,精通子系统涉及的核心技术。比如 AI 算法模型、视频编解码、特定数学模型、实时交易算法、财务报表系统、人脸识别引擎等,都是典型的复杂子系统,需要专业系统团队来专门负责。
组建专业系统团队的主要目的,是为了给使用这些核心子系统的业务团队减负。本来这些「绝世武功」需要专业系统团队的「武林高手」倾囊相授,现在业务团队只管安心用就行了,不必自己还得练上几年。这样不仅能让每个团队专注自己最擅长的事情,也能节省组织的时间和成本。
需要注意的是,专业系统团队和传统的「组件团队」有本质区别。后者的设立往往是为了让多个团队共用同一个组件,而专业系统团队纯粹是为了「解决疑难杂症」,和代码复用无关。
那么,一个高效能的专业系统团队应该是什么样的呢?
以上。