标签归档:组织架构

关于研发效能在组织层面的一些思考和总结

组织结构决定了信息流动、资源分配和决策过程的效率。在研发效能的提升中,扁平化的管理层级、跨功能的团队配置以及灵活的人员动态管理,都能够促进创新和加速决策过程。

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

康威定律和逆康威定律

在 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 算法模型、视频编解码、特定数学模型、实时交易算法、财务报表系统、人脸识别引擎等,都是典型的复杂子系统,需要专业系统团队来专门负责。

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

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

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

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

一些观点

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

以上。