6 大原则!助你构建高绩效的研发强军 | Liga译文

原创
05/17 11:16
阅读数 2K

「软件正在吞噬世界」,著名风险投资公司 Andreessen Horowitz 联合创始人兼 GP 马克·安德森如是说道。随着数字设备的普及和新技术对生活的改变,软件已成为所有企业不可或缺的因素。哪怕是房地产或医疗行业从业者也必须使用一些系统或应用程序。因此,有效且高效地开发软件是所有企业生存和成功的关键。

然而,尽管出现了许多理念和项目管理框架,例如敏捷(Agile)、Scrum、极限编程(XP)、看板(KanBan)和团队拓扑(Team Topologies)等,但只有少数企业知道如何高效地开发软件。我遇到过许多错误模式,最终导致进度延迟、软件质量恶化和客户满意度下降。为了避免无效管理并达成更优秀的表现,你应该了解软件项目/产品管理的最佳实践、理念及原则。

其中影响范围最大的实践之一是搭建团队结构的方式。许多研究(如康威定律)证明,如果用错误的方式搭建团队结构,团队绩效将受到极大的制约。在本文中,我将根据自己的经验和深入研究,解释能够在组织中构建有效结构的几项原则。

1. 系统设计先行

搭建高绩效研发团队的第一条原则,是在设计团队结构之前,先设计你想要的系统。美国计算机科学家和计算机程序员 Melvin Edward Conway 于 1967 年提出康威定律(Conway's Law),该定律描述了组织的结构和沟通方式将制约其生产的系统设计。如果一个组织组建了设计团队、业务团队、前端团队和后端团队,那么系统的输出也将是业务文档、设计组件、前端组件和后端组件,这需要大量的团队沟通才能完成最终的整合并交付给用户。康威定律下的团队结构是最普遍的反模式之一,直到今天仍有许多组织在使用。

(康威定律示例)

下面这种团队结构无需频繁交流,也能让团队独立地为用户提供价值(尽管无法做到完全独立)。它也被称为流对齐团队、功能团队或跨职能团队。

2. 考虑认知负荷

Matthew Skelton 和 Manuel Pais 于 2019 年出版的《高效能团队模式:支持软件快速交付的组织架构》描述了软件研发组织中的四种基本团队:流对齐团队(Stream-aligned team)使能团队(Enabling team)复杂子系统团队(Complicated subsystem team) ,以及平台团队(Platform team) 。这四种基本团队的背后是一个重要的心理学理论:认知负荷——指工作记忆资源的使用量

上一条原则所解释的团队结构在《高效能团队模式》中被称为流对齐团队。流对齐团队是跨职能的,也是独立为用户提供价值的主力军。然而,流对齐团队太忙了,以致于无法赶上新玩意儿,比如新的技术、管理方法或领导力,也无法处理基础设施。如果把过多的责任压在流对齐团队身上,他们就无法处理任务,团队表现也会变差。 因此,为了减轻他们的认知负担,其余三个团队(使能团队、复杂子系统团队和平台团队)都要前来支援

(团队拓扑)

  • 使能团队帮助流对齐团队学习向用户交付更高价值所需的新事物,诸如技术、架构、UI/UX、管理方法等。使能团队可能由内部/外部导师、教练或顾问组成,他们可以在流对齐团队中教授和实施新事物。
  • 复杂子系统团队负责需要特殊技能或可与正常交付隔离的特定组件,例如机器学习模型、特殊图形/动画或认证 API。复杂子系统团队所处理的组件将通过讨论确定,因为它们与流对齐团队之间没有明确界限。
  • 平台团队负责构建和提供一个平台,以让流对齐团队可以在该平台顺利地部署和发布,向用户交付价值。 在团队拓扑的背景下,平台是一个包括文档、指南、DevOps 和基础设施的综合概念,旨在帮助流对齐团队顺利部署。

3. 保持团队精干

原则之三是让团队保持「小而精」。 许多研究和知名企业都表明,「小而精」有比「大而全」更高的效率、更好的业绩——这是因为小团队的沟通更加有效,团队中的每个人都能随时了解情况,并提高参与度。亚马逊自创立之初就实行「两个披萨」原则(即组建团队和参加会议的人数不超过 9 人)并取得了真正的成功。

《敏捷革命》的作者 Jeff Southerland 在「Scrum 指南」中也解释说:“Scrum 团队小到可以保持灵活性,大到能够在一个迭代内完成重要工作,通常是 10 人或者更少。总的来说,我们发现较小的团队沟通更顺畅,工作效率更高。”

4. 仆人式领导力

Daniel H. Pink 在《驱动力》一书中提出了「驱动力 3.0」。他认为自工业时代以来,人类的行为动机已然发生了变化,他还审视了驱动力的三大要素:自主、专精和目的——它们可以持续激励我们。

  • 自主(Autonomy) :人类想要决定如何做。
  • 专精(Mastery) :人类想要成长。
  • 目的(Purpose) :人类寻求意义。

由 Robert K. Greenleaf 提出的「仆人式领导理论」正是驱动力 3.0 的体现。这是领导哲学的一种,其主要实践是为团队服务,使团队成员在工作中保持高度的参与度、积极性和可持续增长。在传统的领导方式中,领导者(老板)以命令和控制的方式命令团队成员(下属)做什么以及如何做。传统的领导风格无法激励个人,也无法提高他们的参与度和工作表现。

仆人式领导者会设定一个目标和愿景(目的),将实现目标和愿景的方法下放给个人(自主),并提供学习新东西的机会(专精)

5. 持续改进

截至 2024 年 1 月,丰田是全球最大的汽车公司,其实践和理念一直影响着所有商业行业,如七大浪费、5S(Seiri 整理、Seiton 整顿、Seiso 清扫、Seiketsu 清洁、Shitsuke 素养)和 3M(Muri 超负荷、Muda 浪费、Mura 不均匀)。其中,最著名的理念是 Kaizen(改善)即持续改进业务流程。无论业务类型或情况如何(即使公司拥有行业最高的市场份额),都 100% 有改进的空间。 没有完美的企业,因此必须不断成长。

从长远发展来看,持续改进会产生复利效应。该术语最初来自金融学中的「复利」,意为利息长期呈指数级增长并产生被动收入。同样,如果团队和业务持续改进,他们的业务流程也将大幅改善,销售收入会成倍增加;其弊端在于大多数人由于短期看不到显著效果,会停止持续改进,但长期来看,持续改进所带来的效益是巨大的,因此需要坚持不懈和耐心。

Scrum 是最流行的敏捷框架,起源于丰田,也是持续改进的实践。在 Scrum 中,持续改进发生在「迭代回顾 Sprint Retrospective」中,Scrum 团队讨论他们在未来的工作中可以做得更好的地方。这是 Scrum 解决团队表现问题并成为应用最广泛的敏捷框架的最大原因之一。

6. 稳定性

搭建高绩效研发团队的最后一项原则是稳定性,即团队结构/成员和工作流程应保持稳定。不稳定会使团队混乱,影响工作效率和表现。

首先是团队结构和成员的稳定,这意味着他们不应频繁变动或调动。 比如,如果组织经常在不同团队之间调动开发人员,那么开发者被分配到新团队时就需要重新熟悉工作方式、代码库和文档,从而降低工作效率。

其次是工作流程流转的稳定性。如果工作流程不规范、不统一,团队成员就会对如何工作感到困惑,产出质量也会不一致。 丰田将标准化定义为业务最关键的实践之一,因为大野耐一强调工作应该顺畅地进行,没有阻碍和浪费。作为丰田生产方式(TPS)的成果,用于将工作流程和任务状态可视化的看板(Kanban)应运而生。

总结

在软件研发组织中,构建有效的团队结构对提高团队效率和工作表现至关重要。本文总结了构建高绩效研发团队的六项原则,它们分别是:

原则一: 系统设计应该比团队构建更早完成。

原则二: 充分考虑认知负荷并组建支持团队(使能团队、复杂子系统团队和平台团队),以协助核心团队(流对齐团队)工作。

原则三: 让团队保持在小而美的规模。团队规模越大,沟通也会变得更加复杂,进而降低工作效率。

原则四: 实践仆人式领导,围绕驱动力 3.0 帮助团队提高参与度和工作表现。

原则五: 无论如何都要坚持持续改进。哪怕在行业遥遥领先,也一定有进步空间。

原则六: 维护团队结构和工作流程的稳定性。这对于避免混乱和追赶成本,提高团队绩效非常重要。

(原文作者为 Eiki,内容经 LigaAI 翻译整理)


了解更多技术干货、研发管理实践等分享,请关注 LigaAI。

欢迎试用 LigaAI-智能研发协作平台,体验智能研发协作,一起变大变强!

展开阅读全文
加载中
点击引领话题📣 发布并加入讨论🔥
打赏
0 评论
1 收藏
0
分享
返回顶部
顶部