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

「软件正在吞噬世界」，著名风险投资公司 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-智能研发协作平台，体验智能研发协作，一起变大变强！