标签归档:研发效能

研发团队没有战斗力,怎么解?

研发团队没有战斗力,怎么解?

在现代企业中,研发团队的战斗力是企业竞争力的重要组成部分,尤其是在技术驱动型的公司。

一个高效、有战斗力的研发团队不仅能快速适应市场变化,还能通过技术创新为企业创造更多的价值。那么,如何才能打造一个有战斗力的研发团队?

我们先界定问题,拆解问题,然后再看怎么系统化的去解。

1 界定问题

我们需要明确什么是「有战斗力的研发团队」,并清楚当前团队与理想状态之间的差距。

用我和我们家闺女常说的,当有人和你说一些事情的时候,需要看一下他说的「是一个观点还是一个事实」。「研发团队没有战斗力」,这明显是一个观点。基于这个观点,接下来我们要做的,就是去拆解这个观点背后的事实,并找到支撑这个观点的具体原因。

那事实有哪些呢?

1.1 任务完成效率低

团队的任务完成效率可以通过数据来衡量。如果团队频繁出现项目延期、任务积压,或者在完成某些任务时总是比预期时间拖延很多,这通常会被认为是研发团队没有足够战斗力的重要表现之一。这里的事实包括:

  • 项目计划与实际进度的差距有多大?
  • 每个任务的平均完成时间是否过长?
  • 团队在解决问题时是否常常遇到瓶颈?

这些数据可以通过项目管理工具(如 Jira、Trello 等)来进行追踪和量化。一旦明确了当前的情况,我们就能更好地了解团队效率低下的具体原因。

1.2 沟通不畅

沟通问题是研发团队中非常常见的困扰之一。它可以通过以下事实来体现:

  • 团队成员之间是否常常因为沟通不足而产生误解?
  • 在跨部门协作中,是否有任务交接不清、信息传递不准确的情况?
  • 是否存在因为沟通问题导致的工作重复或返工?

通过团队内部的回顾会议、跨部门的反馈等方式,可以明确沟通问题的具体表现和影响。沟通不畅往往会拖慢整体效率,降低团队的战斗力。

1.3 团队士气低落

士气低落是另一个常见的观点化描述,但它背后有很多具体的事实可以支撑:

  • 团队成员是否主动承担任务,还是常常出现推诿现象?
  • 团队的离职率是否高于行业平均水平?
  • 团队成员是否经常表现出疲惫、倦怠,缺乏对工作的积极性?

如果团队中缺乏成就感、归属感,激励机制不到位,这些都会导致士气低落,进而影响团队的整体战斗力。通过员工满意度调查、绩效考核结果等数据,我们可以准确捕捉到士气低落的事实。

1.4 技术债务积累

「技术债务」经常会被忽视,但它实际上是研发团队战斗力不足的重要原因之一。以下事实可以帮助我们判断团队是否面临技术债务问题:

  • 系统是否频繁出现 BUG,导致大量时间用于修复问题而非开发新功能?
  • 是否有大量遗留的代码或架构问题,导致团队在进行新功能开发时效率低下?
  • 系统的可维护性和可扩展性是否在不断下降?

技术债务的积累不仅会拖慢整个团队的开发进度,还可能让团队陷入“救火”而非创新的状态,这无疑是战斗力下降的一个重要体现。

1.5 质量问题严重

质量问题也是影响研发团队战斗力的一个重要因素,并且算是一种非常关键的事实表现。质量问题不仅影响产品的稳定性和用户体验,还会对团队的效率、士气和创新能力造成负面影响。在「研发团队没有战斗力」这一观点下,质量问题可以归结为以下几个具体事实:

  • 有频繁的产品缺陷和返工,可以使用缺陷率、线上故障数、SLA 等指标来衡量
  • 项目交付质量不达标,如功能不完整,性能问题,用户反馈差等
  • 缺乏严格的代码审查和质量控制流程

1.6 工程化和系统化问题

「工程化和系统化问题」是影响研发团队战斗力的重要因素之一,尤其是在团队规模扩大、项目复杂性增加的情况下。工程化和系统化不足通常会导致团队的开发流程混乱、效率低下、交付质量不稳定、可扩展性差,甚至会影响团队的整体协作能力和长期发展。其主要体现在如下几个方面:

  • 缺乏标准化流程
  • 自动化程度不足,缺乏自动化测试,手动操作的事项较多,重复劳动多
  • 系统化不足,缺乏整体架构设计,模块耦合度高或者扩展性差

1.7 人才梯队问题

人才梯队是指团队中不同层级的人才储备和发展体系。如果团队中缺乏明确的人才梯队,意味着团队内部没有清晰的发展路径,成员的技能水平参差不齐,导致团队的整体战斗力不足。以下是一些具体的事实表现:

  • 缺乏明确的晋升机制:团队中没有明确的晋升机制和路径,导致优秀的员工看不到职业发展前景,逐渐失去动力。
  • 关键人员依赖严重:团队中的某些核心人员承担了过多的技术关键任务,一旦这些人离职或出问题,整个项目或团队都会陷入停滞。
  • 缺乏接班人:当团队中的高层或资深技术人员调岗或离职时,缺乏能够快速接替其工作的接班人,导致项目推进或技术维护出现断档。

这些现象说明团队在人才梯队建设上存在严重不足,导致团队的持续作战能力和抗风险能力较差。

1.8 人才密度问题

人才密度指的是团队中高水平技术人才的比例。如果团队的人才密度不足,即高水平人才较少,团队整体的战斗力自然会大打折扣。以下是一些具体的事实表现:

  • 技术水平不均衡:团队中技术能力强的人数较少,大多数成员的技术能力不足以支撑复杂的项目开发,导致高水平的成员承担了大部分工作,而低水平的成员拉低了整体效率。
  • 问题解决能力差:团队整体在面对复杂问题时,解决问题的能力不足,往往需要依赖外部资源或高层决策,无法自主高效地解决技术难题。
  • 技术创新动力不足:由于缺乏高水平人才的引领,团队内部的技术创新能力较弱,难以提出具有前瞻性的技术方案。

人才密度直接影响到团队的技术创新和问题解决能力,因此提升人才密度是打造高战斗力团队的关键。

2 分解问题

在明确了研发团队战斗力不足的主要表现后,我们需要进一步分解问题,以便逐步分析并找到解决方案。根据 MECE 的原则,可以将战斗力不足的问题分解为下列几个方面:

2.1 效率问题

效率是衡量研发团队战斗力的最直接指标之一。如果团队的任务完成效率低下,项目延期频繁,势必会影响整体战斗力。这一问题可以分为以下几个子问题:

  • 流程不清晰:团队的开发流程、测试流程、发布流程是否标准化?是否有明确的职责划分和操作步骤?
  • 工具使用不当:项目管理工具、代码管理工具、自动化工具是否充分使用?是否存在大量的手动操作和重复劳动?
  • 不合理的资源分配:团队成员的任务分配是否合理?是否存在某些成员工作过载,而其他成员任务量不足的情况?
  • 瓶颈无法突破:团队在某些技术领域或开发阶段是否经常遇到瓶颈,导致任务卡住?

2.2 沟通协作问题

沟通不畅往往是导致研发团队效率低下和战斗力不足的主要原因之一。沟通问题可以进一步分解为:

  • 跨部门沟通障碍:研发团队和其他部门(如产品、运营、市场等)之间的沟通是否频繁出现误解或信息不对称?
  • 内部沟通不畅:团队内部成员之间是否缺乏有效的沟通渠道?是否存在信息流动不畅或不透明的情况?
  • 技术与业务脱节:研发团队是否充分理解业务需求?技术方案是否能够及时响应业务的变化?

2.3 士气和激励问题

研发团队的士气低落通常是由激励机制不合理、工作压力过大或缺乏成就感引起的。这个问题可以进一步分解为:

  • 激励机制不健全:绩效考核、薪资、奖金等激励机制是否能够有效激励员工?团队中是否存在“吃大锅饭”的问题,导致优秀员工失去动力?
  • 成就感缺失:团队成员是否能感受到工作的意义?是否有足够的成就感和归属感?
  • 工作倦怠:团队成员是否长期处于高压、加班的状态,导致出现工作倦怠?

2.4 技术债务与质量问题

技术债务和质量问题会严重影响团队的战斗力,因为它们导致团队需要花费大量时间在修复错误和维护上,而不是开发新功能或创新。技术债务和质量问题的细分包括:

  • 代码质量差:团队是否有严格的代码评审流程?代码是否有良好的可读性、可维护性?
  • 技术债务积累:系统中是否存在大量的历史遗留问题(如未重构的老旧代码、架构问题等),导致维护成本高、开发效率低?
  • 缺乏自动化测试:团队是否有足够的自动化测试覆盖?是否依赖大量的手工测试,增加了测试和发布的成本?

2.5 人才梯队建设不足

人才梯队建设不足意味着团队缺乏不同层次的人才储备,导致团队的整体战斗力和可持续发展能力受限。具体问题包括:

  • 晋升机制不明确:是否有清晰的晋升机制和职业发展通道?员工是否知道如何通过努力获得晋升或更多的成长机会?
  • 接班人缺失:是否有计划培养接班人,确保每个关键岗位都有后备力量?
  • 关键依赖严重:团队是否过度依赖某些核心人员,一旦这些人离职或请假,项目进展是否会受到严重影响?

2.6 人才密度不够

人才密度不够会导致团队在面对复杂技术问题时缺乏足够的解决能力,团队的技术创新能力也会因此受到影响。这个问题可以进一步分解为:

  • 招不到合适的人:招聘过程是否存在瓶颈,导致无法及时引入高水平的技术人才?
  • 人才培养不足:是否有系统的内部培训机制,帮助团队成员提升技术水平?
  • 技术水平参差不齐:团队成员的技术能力是否存在较大的差异,导致整体效率不高?

2.7 工程化和系统化不足

工程化和系统化不足会导致团队效率低下、交付质量不稳定,无法应对复杂的项目需求。具体问题包括:

  • 开发流程不标准:是否有统一的开发、测试、发布流程?是否存在大量的手动操作?
  • 自动化程度不够:系统的开发、测试、部署等环节是否充分利用了自动化工具?是否存在大量重复的手工劳动?
  • 架构设计不合理:系统的架构设计是否能够支持业务的扩展和未来的发展需求?是否存在模块耦合度过高、扩展性差等问题?

3 体系化的解决问题

解决研发团队没有战斗力的问题,是一个多维度、跨职能的系统性工程。它涉及到组织文化、组织结构、技术架构、流程设计、工程系统和度量考核等多个方面。每个维度的优化和提升都能够为研发团队带来战斗力的增强,但这些维度并非孤立存在,而是相互关联、彼此支撑的。

我们需要明确的是,研发团队战斗力的提升不仅仅是为了提高「速度」,更是为了提高「质量」和「价值」,即更高效地交付更优质的产品,满足业务需求,并为公司创造长期的价值。

3.1 组织文化和沟通机制构建

组织文化是企业的灵魂,它直接影响员工的行为和思维方式。一个以创新和协作为核心的组织文化能激发员工的创造力,鼓励他们尝试新方法和新技术,并在失败中学习和改进。文化的塑造对研发效能提升而言,是打下「地基」的工作。

如何构建?

  • 建立跨部门沟通机制:通过定期的跨部门会议或项目复盘,确保技术、产品、业务等不同职能部门之间的沟通顺畅。可以采用 OKR 或双向沟通机制,让各部门了解彼此的目标和进展,减少信息孤岛。

  • 鼓励知识共享:定期组织 技术分享会内部培训,以及设立 技术博客 或 Wiki,这样可以促进技术积累和知识在团队内的流动。还可以通过内部的 导师制,帮助新员工快速融入团队。

  • 认可和激励创新:设立相应的 奖项 或 肯定机制,对提出创新方案或成功实施新技术的员工进行公开表扬和奖励。比如可以设立 季度创新奖,以鼓励员工在日常工作中不断试验和改进。

  • 领导层的共识:研发负责人应确保与高层管理者达成一致,使研发效能提升工作得到高层支持。领导层的共识会帮助在资源分配、目标设定、团队管理等层面为研发效能的提升提供保障。

我们可以进行如下的一些具体的操作:

  • 定期组织 跨部门的需求讨论会 或 研发复盘会,确保各个部门的需求和反馈能够及时传递。
  • 设立 激励计划,对优秀的创新项目和技术方案进行奖励。
  • 通过 员工满意度调查 或 一对一访谈,了解员工对现有文化的看法,并持续改进。

3.2 调整组织结构

组织结构决定了信息的流动、资源的分配以及决策的效率。一个灵活的、扁平化的组织结构能够促进创新,加速决策过程,同时减少层级间的沟通障碍。通过合理的组织结构设计,可以让团队在面对复杂问题时具备更强的反应能力。

组织结构的调整需要根据实际的团队情况以及业务情况来做优化,是职能型,还是项目型,还是矩阵型等等,可以有如下的一些参考思路:

  • 小型化、自治化的团队:采用 跨职能团队 的形式,促进团队成员之间的紧密合作。每个团队都拥有相对独立的决策权,能够快速响应业务需求。采用 Spotify 模式 或 Scrum 团队 的形式,打破职能部门壁垒,形成更快速决策和执行的团队。

  • 灵活的项目管理机制:引入 动态人员管理 和 内部创业机制,让团队能够根据项目的需求灵活调整人员和资源配置。通过设立 内部孵化器,让员工能够在公司内部尝试新的项目和解决方案。

  • 减少管理层级:通过扁平化管理,减少中间层级的沟通障碍,形成更直接的反馈机制。管理者应该更多地起到 协调者 和 支持者 的作用,而不是微观管理。

在实际操作过程中,我们可以:

  • 设立多个 跨职能团队,每个团队独立负责某个产品或项目的端到端交付。
  • 引入 OKR 管理机制,确保各个团队的目标与公司整体战略保持一致,并且团队间可以灵活协作。
  • 定期进行 组织结构评估,根据业务需求和人员成长情况灵活调整团队架构。

3.3 评估并调整技术架构

技术架构的合理性直接影响团队的研发效率。如果架构设计不合理,团队的开发成本会持续增加,迭代速度会变慢,系统的稳定性和可扩展性也会下降。通过合理的架构设计,可以让团队更高效地应对变化和扩展需求。

以下为一些评估和调整的思路或原则:

  • 模块化、低耦合的架构设计:在架构设计中,遵循 高内聚、低耦合 的原则,确保系统模块之间的依赖性降到最低,便于独立开发和部署。采用 微服务架构 或 服务化架构,将系统拆分为相对独立的服务,确保每个模块可以独立扩展和维护。这虽然是老生常谈,但是很少有组织做得很好。且这里需要根据实际的业务需要和当前架构形态来决策。

  • 云原生架构:通过云原生架构,使用 DockerKubernetes 等容器化和编排技术,实现系统的一致性和可移植性,支持快速部署和环境隔离。

  • 灵活的技术栈:根据业务需求选择合适的技术栈,而不是盲目追求技术潮流。技术选择要与团队的技术能力和业务发展阶段相匹配。

  • DevOps 和 CI/CD 实践:通过持续集成和持续交付(CI/CD)来加速产品发布,减少人工操作的错误,提升发布频率和质量。

具体操作过程中,我们可以:

  • 进行 架构评审,定期对系统的技术架构进行审查,确保架构能够支持当前和未来的业务发展。
  • 引入 DevOps 实践,通过自动化工具(如 Jenkins、GitLab CI 等)实现持续集成和交付。
  • 采用 微服务架构 进行系统划分,确保各个服务可以独立开发、测试和部署。

3.4 优化研发流程

研发流程设计是确保研发活动高效进行的关键。良好的流程设计可以减少非必要的工作,清晰定义各个阶段的输入、输出和质量标准。同时,优秀的流程设计能帮助团队在每个环节上减少浪费,提升整体效率。

以下为常用的一些优化思路:

  • 引入敏捷开发方法:采用 Scrum 或 Kanban 等敏捷开发方法,确保团队能够快速响应需求变化,并通过短周期迭代逐步交付产品。不能为了敏捷而敏捷,根据当前团队情况来实施。

  • 精益开发思想:通过 精益思想(Lean),消除流程中的浪费,减少不增值的工作。例如,减少不必要的会议、文档、审批流程,提升团队专注于高价值任务的时间。

  • 自动化流程:通过引入自动化工具,简化开发、测试和发布流程,减少手工操作和人为错误。比如自动化代码检查、自动化测试、自动化部署等。

  • 数据驱动的流程优化:通过 数据分析工具(如 Jira、SonarQube 等)监控流程中的瓶颈点和低效环节,并持续优化流程。

实际操作过程中可以通过以下的方式来做一些落地的操作:

  • 定期进行 流程审查会议,分析当前流程中的低效环节和瓶颈,提出改进方案。
  • 采用 需求交付周期 和 需求吞吐量 等指标,衡量每个迭代的效率,并根据数据优化流程。
  • 使用 自动化工具 完成代码检查、测试和部署,减少人工干预。

3.5 优化工程系统

工程系统是研发效能提升的基础设施。包括代码管理、构建、测试、部署等一系列工程实践。通过系统化的工具和方法,可以减少重复性工作,提升研发的效率和稳定性。

工程系统如何优化?

  • 统一的开发环境:建立统一的开发环境和工具链,确保团队成员在同一套标准下工作,降低环境差异带来的问题。采用 Docker 等容器化技术,确保本地开发环境与生产环境的一致性。

  • 自动化测试平台:通过自动化测试平台(如 Selenium、JUnit、TestNG 等),实现单元测试、集成测试、回归测试的自动化,提高产品质量,减少人工测试的负担。

  • 版本控制系统:采用 Git 等版本控制系统,建立合理的分支管理策略(如 GitFlow),确保代码的安全性和可追溯性。

  • 监控和日志分析系统:引入 监控工具(如 Prometheus、Grafana)和 日志分析工具(如 ELK Stack),确保系统的运行状况可视化,尽早发现问题并采取措施。

在实际操作过程中我们可以:

  • 建立统一的 Docker 镜像仓库,确保开发和生产使用相同的基础环境。
  • 使用 持续集成工具(如 Jenkins)进行代码的自动化构建和测试。
  • 设立 监控和报警机制,确保系统的健康状况能够被实时监控。

3.6 构建度量考核

度量考核是研发效能提升的反馈机制。它为团队提供了衡量成果和改进的依据,帮助团队识别问题、跟踪进度,并调整优化策略。没有量化的度量,研发效能的提升就缺乏方向和依据。

同时,度量可以让战斗力这个概念可视化出来,更明确什么是有战斗力,什么是没有战斗力。

我们可以用如下的方式落地:

  • 建立科学的度量体系:用一套符合团队实际情况的指标体系来衡量效能,覆盖项目进度、产品质量、团队效率等方面。常见的度量指标包括 需求交付周期缺陷率代码覆盖率部署频率 等。

  • 定期审视数据:定期对这些指标进行审查,分析趋势和异常,找出影响效能的主要原因,并制定改进措施。

  • 将度量结果与激励机制挂钩:通过绩效考核,确保团队成员的贡献能够被量化和认可,并通过奖励机制激励团队不断提升效能。

实际操作:

  • 建立 研发效能仪表盘,实时监控团队的效能指标。
  • 每月定期召开 效能回顾会议,根据数据分析报告,制定下一步的改进计划。
  • 将 研发效能指标 纳入团队的 OKR 或绩效考核体系,确保团队成员的目标与效能提升保持一致。

4 小结

提升研发团队的战斗力是一个体系化、系统化的工程,涉及到组织文化、组织结构、技术架构、流程设计、工程系统和度量考核等多个层面。通过在这些维度上进行持续优化,可以显著增强研发团队的战斗力,提升产品交付的速度、质量和创新能力。

如果要真正的解决研发团队没有战斗力的问题,在上面界定问题、分析问题和解决问题的基础上,还需要有如下的一些操作和逻辑:

  • 建立目标和成功判断
  • 制定详细的解决方案
  • 设定里程碑
  • 制定详细的工作计划
  • 风险判断和未来改进

只有完整落地详细的工作计划,完成里程碑,一步一个脚印,才能真正的打造出有战斗力的研发团队。

每个企业的实际情况不同,因此在执行时需要根据具体场景进行灵活调整。最终目标是帮助研发团队在高速变化的市场环境中,更高效、更稳定地交付高质量的产品,创造更大的商业价值。

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

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

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

康威定律和逆康威定律

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

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

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

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

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

一些观点

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

以上。

从定义到落地:如何系统构建研发效能优化机制

在带团队过程中,经常会听到「搞一个机制」,[某某某机制]的场景,这种一般是出现了问题或故障之类的时候,或者为了某个特定的目标。又或者一天老板说,你搞一下研发效能优化的机制。

那,机制到底是什么,包括什么内容,构建机制有什么价值,如何构建机制,如何保持机制的有效性和合理性?想以今天的文章大概回答一下这些问题。

1 机制的定义

从比较泛的概念来看,机制是指为了实现某种目标或功能,而建立起来的一整套运作方式、管理方法和规则体系。它是由一系列相互关联、相互作用的要素和环节构成的,通过这些要素和环节的有机结合和协调运转,来保证整个系统高效、有序、可持续地运行,从而实现预期的目标或功能。

提取关键词:实现目标或功能,一整套体系,可大可小。

从管理上来看,机制通常包含以下几层含义:

  1. 体制层面:是由一系列制度、规则、流程等构成的框架,用以规范和指导组织的运作。
  2. 运作层面:是在既定的体制框架下,通过各要素之间的互动、协调和反馈,推动组织高效运转的动态过程。
  3. 方法层面:是为实现特定管理目标,在体制和运作的基础上,采取的一系列具体的管理方法、工具和技巧。
  4. 保障层面:是为维持机制的正常运行,提供必要的资源、环境和监督等支持条件。

机制强调系统性、规范性和持续性

建立科学完善的机制,有利于在组织内形成清晰的责权利关系,规范有序的工作流程,可预期的行为模式,从而提高组织效率,实现组织目标。同时,机制也强调动态优化,需要在实践中不断评估改进,以适应内外部环境的变化。

2 机制的价值

机制的价值在机制的定义中做了说明,其价值就是为了实现某种目标或功能,其价值大小和机制本身强相关联。

以项目研发管理机制来看,其定义是指在项目的研发过程中,为了提高研发效率、控制研发成本和确保项目质量,所制定的一系列管理规范和方法。其价值在于提高研发效率、控制研发成本和确保项目质量,更细一点,价值在机制的落地文档中有明确说明。

3 如何构建机制

构建一个完整的机制是一项系统工程,从大来说需要全面考虑组织的战略目标、业务规模和特点、资源条件等因素,从小来说需要考虑具体的问题,目标,条件限制等等。

一个大的管理机制的构建大概会是如下的步骤,小的机制也可按此逻辑,但过程中的相关人员等都可缩小范围:

  1. 确定问题、目标或需求:在构建管理机制的过程中,明确问题和目标是首要步骤。这一步骤要求明确机制建设的主要目的和目标,如提高工作效率、增强员工激励、防范潜在风险等。这些目标应与组织的整体战略紧密相连,确保机制的设计能够支持组织的长远发展。接下来的需求分析阶段则涉及到对组织内外部需求的全面分析,这包括理解员工的期望、管理层的要求、合作伙伴的互动方式以及环境的变化。这一阶段的目的是确保新机制能够解决实际问题并满足不同利益相关者的需求。

  2. 设计机制框架:在制定原则环节,需要依据组织的文化和战略目标来设定机制设计的基本原则和标准,确保机制既符合组织的核心价值观,又能实现预定的战略目标。选择机制类型阶段则涉及选择合适的机制类型来应对特定的需求,例如激励机制用于提高员工动力,约束机制用于规范行为,协调机制用于优化部门间合作。草案设计则是将这些原则和类型综合起来,形成一个初步的机制设计草案,这一草案将详细描述机制的具体内容和操作方式。

  3. 征求反馈与优化:在内部沟通阶段,将草案在组织内部进行广泛讨论,这通常涉及不同层级的员工和管理者,以确保机制的设计能得到广泛的支持和理解。通过收集反馈,机构可以利用会议、问卷等方式广泛收集员工、管理层甚至是客户的反馈意见。这些反馈将在修改优化阶段被用来调整和优化机制的设计,以确保其最终的实用性和有效性。

  4. 制定实施计划:在这一阶段,组织需要制定详细步骤,包括机制实施的时间表、具体步骤和责任人。这有助于确保实施过程的有序进行。同时,准备资源环节要确保所有必要的资源都已到位,例如技术支持和培训材料等。此外,风险管理则要求预见并计划应对可能的挑战和风险,确保机制能够顺利实施。

  5. 执行与监控:这一阶段的关键在于正式实施,按照既定计划开始执行机制,并进行必要的员工培训和指导。监控执行阶段要持续跟踪机制的实施效果,监控包括员工接受程度和机制的运行状态。在此基础上,数据收集对操作数据和反馈信息的收集是必不可少的,这些数据将用于后续的评估和调整。

  6. 评估与持续改进效果评估是通过定期的机制效果评估来检查是否达到了预定的目标。这一阶段的重点是根据评估结果对机制进行必要的调整,以实现持续改进。组织应该建立一种机制,使得每一次评估都能成为未来改进的基础,确保机制始终能够适应组织发展的需求和外部环境的变化。通过这种循环反馈的方式,组织可以持续优化管理机制,从而持续提升组织的整体表现和效率。

总的来说,就是明确目标和需求、设定原则和方案,征求意见,试点运行,完善优化,全面实施,评估改进。

以下以构建研发效能优化机制为例来看下如何落地。

4 构建研发效能优化机制

4.1 确定问题、目标或需求

在构建研发效能优化机制时,首先需要明确当前研发效能存在的主要问题,例如:

  1. 研发交付质量不高,缺陷率居高不下
  2. 研发进度频繁延误,影响产品上市时间
  3. 研发资源利用率低,存在大量低效无谓的工作
  4. 缺乏客观的研发效能度量指标和手段
  5. 团队士气低落,人员流失率高

在问题分析的基础上,结合公司的战略目标,确定研发效能优化的目标,比如:

  1. 提高产品质量,将严重缺陷率降低30%
  2. 缩短产品研发周期,平均交付时间缩短20%
  3. 提高人均产出,研发资源利用率提升15%
  4. 建立完善的研发效能度量体系,实现全流程数字化管理
  5. 提升团队凝聚力和工作热情,人员流失率降低10%

同时,需要充分理解各利益相关方的需求和期望:

  1. 高层管理者关注公司整体研发效率和产品竞争力
  2. 业务部门关注产品能否快速满足客户需求
  3. 研发人员关注个人成长和技术挑战
  4. 客户关注产品质量和使用体验
  5. 竞争对手关注公司的技术实力和创新能力

只有在全面了解问题,明确目标,洞察需求的基础上,才能设计出切实有效的优化机制。

4.2 设计机制框架

根据 4.1 中确定的目标和需求,设计研发效能优化机制的总体框架。机制应该围绕以下几个方面展开:

  1. 度量体系:建立科学合理的研发效能评估指标,包括质量指标(如缺陷率,测试通过率),速度指标(如需求交付周期,缺陷修复时间),效率指标(如需求吞吐量,代码复用率),以及满意度指标(如客户满意度,员工敬业度)等。

  2. 组织结构:调整组织架构,成立专门的效能优化小组。明确各级研发主管在效能管理中的职责,将效能目标纳入绩效考核。建立高管领导下的跨部门协调机制。

  3. 流程优化:对现有的研发流程进行梳理和优化,包括需求管理,设计评审,代码开发,测试验证,发布部署等各个环节。引入成熟的敏捷开发、精益开发等方法。

  4. 工具支撑:引进或自研效能管理工具,实现需求、任务、缺陷、代码等的全流程跟踪管理和数据分析。提供自动化测试、持续集成等工程化手段。

  5. 文化建设:倡导以结果和价值为导向的工程师文化,鼓励创新和持续改进。加强技术培训和经验分享,帮助员工提升能力。营造开放透明、相互信任的团队氛围。

以上五个方面构成了研发效能优化机制的主要框架,后续需要进一步细化每个方面的具体内容,形成一套科学、系统、可操作的方案。

4.3 征求反馈与优化

在设计出研发效能优化机制的初步框架后,需要广泛征求相关利益方的意见和反馈,包括:

  1. 研发人员: 作为机制实施的主体,研发人员的意见至关重要。通过问卷调查、座谈会等方式,了解他们对指标体系的看法,对流程优化的建议,以及可能遇到的困难和挑战。

  2. 研发管理层: 与研发管理层沟通机制设计的思路和细节,获取他们基于管理实践的反馈和改进建议,确保机制在管理层得到足够重视和支持。

  3. 相关部门: 与产品、测试、运维等部门沟通,了解机制实施对其工作的影响,以及他们对机制的期望和建议。

  4. 外部专家: 寻求外部专家如管理咨询、敏捷教练等的专业意见,借鉴其他企业的优秀实践经验。

在广泛收集反馈的基础上,对机制方案进行系统的优化和改进,使其更加切合组织的实际情况。优化的内容可能包括但不限于:

  1. 调整指标体系,选择更加关键和可度量的指标
  2. 简化优化流程,去除不必要的环节,提高灵活性
  3. 完善配套的激励和考核措施,调动研发人员的积极性
  4. 加强机制实施的过程管理和风险防范

反馈和优化是一个循环迭代的过程,可能需要经过多轮才能最终确定一个相对成熟和可执行的机制方案。

4.4 制定实施计划

在机制方案优化成型后,需要制定详细的实施计划,包括:

  1. 实施步骤: 将机制的实施分解为若干个步骤和阶段(如先试点再推广),明确每个步骤的目标、内容和时间节点。
  2. 责任分工: 明确各个步骤的责任人和参与人,划分具体的工作任务。
  3. 资源准备: 确定实施机制所需的人力、财力、工具等资源,提前进行准备和调配。
  4. 宣传培训: 制定机制实施的宣传方案,让所有相关人员知悉机制的内容和要求。针对关键岗位人员开展必要的培训。
  5. 应急预案: 梳理机制实施可能遇到的风险和问题,制定相应的应对措施和处理流程。

一个详细的实施计划能够指导机制的落地执行,确保按既定的方向和步骤稳步推进,降低实施过程中的混乱和风险。

4.5 执行与监控

按照实施计划,正式启动研发效能优化机制,主要做好以下几点:

  1. 各部门和团队根据流程规范开展具体工作,形成常态化机制。
  2. 严格执行指标度量,定期收集和分析相关数据。
  3. 通过会议、邮件、看板等形式,持续跟踪和传递机制运行的关键信息。
  4. 收集研发人员和相关部门在执行过程中的反馈,及时协调和处理遇到的问题。
  5. 对机制执行过程进行抽查和巡检,对重点环节进行督导,确保执行到位。

4.6 评估与持续改进

  1. 建立评估机制: 制定机制实施成效的评估办法,明确评估指标、周期、方式和责任人。评估指标应该聚焦机制的预期目标,如研发交付及时率,缺陷率,需求响应时间等。
  2. 定期开展评估: 按计划定期开展评估,全面审视机制执行的情况和效果。可采用定量与定性分析相结合的方式,深入剖析机制运行中的问题和不足。
  3. 评估结果应用: 将评估结果形成正式的报告或总结,作为后续优化和完善的重要输入。针对暴露出的问题,及时制定整改方案,落实到责任人。
  4. 持续优化改进: 研发效能优化是一个长期的、动态的过程。要以开放的心态接纳各方的反馈,根据实际效果和环境变化,对机制进行持续的改进和调整。可借鉴业界的最佳实践,定期进行对标学习。
  5. 形成优化闭环: 将优化措施落实到位,形成闭环管理。将成功的经验固化到机制中,并在组织内推广。长期坚持,追求卓越,构建起一套行之有效、持续进化的研发效能优化长效机制。

只有通过持之以恒的评估优化及持续改进,研发效能优化机制才能真正发挥作用,帮助组织不断提升研发效率和质量,增强市场竞争力。同时,这也是一个不断学习和改进的过程,需要组织上下的共同努力和长期坚持。

5 小结

构建机制是一项系统工程,需要从全局出发,综合考虑组织的战略目标、现实问题、资源条件等因素。总体而言,构建过程可分为六个主要步骤:确定问题和目标、设计机制框架、征求反馈与优化、制定实施计划、执行与监控、评估与持续改进。每个步骤都环环相扣,缺一不可。

以研发效能优化机制为例。

在其设计过程中,需要从度量体系、组织结构、流程优化、工具支撑、文化建设、外部合作等多个维度入手,形成一套科学、系统、可操作的方案。方案的制定需要广泛听取各方意见,不断迭代优化,以确保其能够真正解决问题,满足各利益相关方的需求。在实施过程中,更需要全员参与,上下协同,在执行中不断监控,及时发现和解决问题。

研发效能优化不是一蹴而就的,而是一个持续改进的过程。只有建立常态化的评估优化机制,持之以恒地推进,才能让研发效能不断提升,让追求高质高效的理念深植于研发文化之中。这需要组织上下的共同努力和长期坚持。通过构建研发效能优化机制,组织能够不断提升产品质量,加快创新速度,提高资源利用率,增强市场竞争力,实现可持续发展。

在整个过程中,需要研发团队的负责人坚持系统思维、问题导向和以人为本。