DevOps 与研发效能资深技术专家张乐：研发效能的升维思考与降维执行

在 4 月 20 日举行的《中国企业软件研发管理白皮书》发布会上，DevOps 与研发效能资深技术专家张乐老师做了一场名为《研发效能的升维思考和降维执行》的主题演讲，阐述了如何系统化思考研发效能的关键要素、互动结构及实施路径，并将其与落地执行有机结合起来。以下为张乐老师的演讲内容摘录。

首先我要支持一下《中国企业软件研发管理白皮书》，在我看来这是特别好的一个载体。因为我们之前看到很多与研发管理相关的内容都是从国外引入的，比如 DevOps 现状调查报告等。这次非常开心能够看到我们本土输出的研发管理的实践经验，为广大研发效能管理者和从业人员提供参考，这是一次有益的尝试。

回到正题，今天我分享的话题是「研发效能的升维思考和降维执行」，希望能给大家带来一些启发。

研发效能到底怎么提升？

当我们谈论研发效能时，所指代的内容、谈论的焦点可能并不完全相同。所以在讲研发效能怎么提升之前，我们首先要回答的是：大家谈论的研发效能到底是什么？我把这个问题抛给了最近很火的 ChatGPT，同时也在行业里调研了一些软件工程师。

大家的回答里罗列了很多有助于研发效能提升的要素，比如目标、流程、方法、技能、知识、工具，还有团队沟通等。这些内容为我们找到效能提升的突破口提供了一些线索，但相对局部和片面，并无法直接回答「组织研发效能如何提升」这个综合性的问题。

所以，我们今天讲研发效能的升维思考，首先是要清楚地知道总体目标是什么，与达到目标相关的要素有哪些，以及这些要素之间的关联关系是什么。只有这样，才能看到问题的本质，有效提升效能。

如下图所示，我从管理、工程和技术三个关键维度出发，对影响研发效能的关键要素进行了一些梳理：

第一个是管理维度，强调通过流程、文化和人来帮助组织提效。从效率层面看，首先要关注的一个点与需求相关。行业里有句话叫「GIGO（Garbage in garbage out）」，如果你的输入是低质量的，那么你的输出也是低质量的。这就要求我们在研发源头一定要避免开发不靠谱的需求，而实例化需求的实践能够帮助我们。

从质量层面看，测试/安全左移、质量门禁、各种应用变更管理等都可以对质量的提升产生促进作用。那这些要素怎么才能对工程师的体验产生很好的影响呢？一个行之有效的方法就是标准化和简化研发流程。比如说有没有一些在 Code Review 阶段就能发现的问题？有没有在自动扫描阶段就能发现的问题？通过流水线能否自动检出 Bug？而不是所有的变更都要走重量级的审批流程。

第二个是工程维度，也就是通过自动化、一致性的方式来执行研发活动。

从效率层面看，代码分支怎么管？是主干开发还是分支开发，还是 Git Flow？这些不同的分支模型，都会对研发效率产生很大影响。除此之外，还有自动化构建/测试、环境治理、部署发布等，也都会对团队的交付周期和交付效率产生影响。

在质量层面，代码评审、单元测试都是工程维度经常需要考虑的实践。跟大家分享一个数据，近期腾讯发布了《2022年腾讯研发大数据报告》，里面提到代码评审的参与率是 74.6%，代码评审的千行评论数为 15.3 个。也就是说参与代码评审的每 1000 行代码，就有 15 个评论。这说明代码评审这件事是在实实在在地做，而不是表面功夫。

那么从工程维度看，怎么优化我们研发工程师的开发体验呢？就是通过自动化流程，减少手工重复的工作，让大家聚焦在业务代码的开发上。

第三个是技术维度，侧重于应用和基础设施架构的设计和实现，以及新技术的应用。

比如云原生，还有现在非常火的 ChatGPT。很多同学已经开始尝试让 ChatGPT 帮助我们细化需求，生成概要设计，或者在局部做代码补全、代码重构，以及自动生成一些测试。可以说，智能化开发、智能化测试、智能化运维逐渐走进我们的视野了。

但问题是，这些要素不能单独存在，因此我们需要一个抓手，将这些要素体系化，才能真正落地到实际中。

研发效能的黄金三角模型

在 2021 年，我提出了「研发效能黄金三角」的框架，将效能实践、效能平台和效能度量统一起来。经过这两年的持续探索和实践沉淀，我把这个模型升级成了 2.0 版本，在框架里增加了更多细节描述，比如效能实践地图、效能平台的五个层次、效能度量的五项精进等，目的是让我们对于研发效能提升的理解具有全局性和系统性。

总的来说，落地研发效能提升工作，并不是只关注效能实践、效能平台、效能度量这三件事就可以了，这还是一种静态思维。我希望我们去思考要素和要素之间的互动、关联关系，并让这些要素形成一个彼此强化、持续优化的增强回路。这个增强回路能够把研发效能里的优秀实践沉淀到工具平台上，通过一站式的平台来承载这些研发实践，帮助我们做规模化的扩展；而效能平台又会产生大量数据，支撑我们做效能的度量与分析，形成持续改进的闭环。

研发效能的实践地图

黄金三角看上去还是比较抽象，所以我在里面写了一些落地的条目：比如在效能实践里，我们需要关注产品导向的交付范式，关注敏捷精益协作、持续交付的工程实践、云原生的持续交付等。我将这些内容总结归纳成了「研发效能的降维执行——效能实践地图」，如下图所示：

里面的要点有很多，我着重讲一下产品导向的交付范式。如下图，我将产品导向与项目导向的交付模式从多个维度进行了对比：

首先，从思维模式来看。世界上很多举世瞩目的工程都有项目管理理论的支撑，比如甘特图，它是由亨利·劳伦斯·甘特在 1917 年所创，随后被用于修建当时世界上最大的混凝土结构——胡佛大坝。值得注意的是，甘特图在当时的使用场景是高确定性的基础设施工程，重复性工作多，不确定性工作较少。

在类似的场景下，用这种管理范式足够了。但是，我们不能指望两次工业革命之前的范式到今天的数字化时代依然奏效。现如今，大环境是快速的、迭代的，其显著特征是易变性、不确定性、模糊性、复杂性，那么研发范式也需要做相应的调整才行。所以现在的研发项目管理，除了项目导向外，也要考虑产品导向。

什么是产品导向的思维模式呢？就是要承认不确定性，用迭代的思路去解决不确定环境的问题，持续交付业务价值。

去年我翻译了一本书 Project to product，书名直译是《从项目到产品》，但最终我认为，《价值流动》这个书名更能体现书中要表达的内容，因为这本书强调我们要考虑价值在企业里跨越多个部门的流动，要从端到端的视角去看企业全局的价值交付过程，而不是某个组织、某个部门的局部过程。

为什么很多企业有技术债？一定程度上是项目模式导致的。一个项目是有终点的，到截止时间之后，没有人再愿意投入资源。那时工作会指派给一个人，让他在做新项目的同时再去维护老项目，这就导致大量没有人愿意维护的技术债务变得越来越多。但如果从产品导向来解决这个问题，会容易一些。

其次，从成功标准来看，项目导向是以成本中心的运营模式，以按时、按预算完成项目既定的交付内容来作为成功标准。但是产品导向，是把业务成功作为真正的成功标准，它更聚焦于增量的价值交付。

项目导向是把人安排在工作上，一个人在一年里可能换了七八个项目，但他很难在每一个项目里都有积累、跟团队磨合得很好，也很难产生很高的效能。而产品导向，就是要长期稳定的团队来负责长期稳定的产品，从而产生长期稳定的价值。另外，这两种模式在组织与团队、驱动模式和可见性等方面都有着完全不同的处理方式。

说到可见性，我们不得不提到「西瓜现象」——常被用于描述项目管理中未暴露的问题。西瓜表面是绿色的，里面的瓤是红色，就好像我们在项目管理过程中，向上汇报时认为进度一切正常，最后上线前才发现上不了。这是为什么？因为本质的问题没有被暴露。因此，产品导向就是要解决这个问题，把可见性暴露出来，通过迭代持续的优化，让过程变得更透明。

除了产品导向的交付范式外，持续交付也是我们在「效能实践地图」中要格外关注的。

云原生的持续交付实践

在云原生时代，我们不禁追问：云原生的持续交付跟普通的持续交付到底有何种区别？要考虑这个问题，我们先要搞清楚云原生到底有什么不同，我认为主要有三个点：

• 可以通过代码去管理基础设施（ IaC，Infrastructure as Code）；
• 微服务和容器化，能够帮助我们更简化、更解耦地开发和部署应用；
• 更完善的发布控制，比如各种灰度策略等。

那么，接下来的问题是，云原生的持续交付该怎么做？概括来说，云原生的持续交付就是在云原生的技术底座之上，用 CI/CD 串联上下游工具链和底层的工具平台，最后做到全流程的自动化。

效能平台的多视角设计

大家很关注工具，但如果只是把多个工具集成在一起，那只是做了第一步，更高阶的方式是贴合具体研发场景实现多视角的设计。

要做好工具平台的建设，就要从三个视角出发，分别是产品视角、项目/空间视角、应用视角。这三层是一个相互嵌套的关系，越往外层越是产品和业务导向的；越靠内层越是工程和技术导向的。参见下图：

先看最容易理解的项目视角/空间视角。我们现在进入到任何一个 DevOps 平台，都会要进入到一个项目/空间中。负责某个产品或某个部分工作的团队在这里工作，他们分解需求、写代码、做测试，完成部署发布。这里的关键点是，各个领域的工具怎么才能有机整合在一起，高效支撑工程师的工作。这就需要跨领域互联互通的能力，让开发、测试、运维之间的研发活动能够衔接得更丝滑。

不过，只有空间或者项目视角是不够的。在一个大的项目里，可能有 1000 个人，500 个服务，几万条流水线。这种信息爆炸会让团队成员不容易聚焦在自己关注的工作上。

如果以应用为中心来组织 DevOps 流程，就可以让工程师聚焦在自己负责的应用上，管控整体流程。这跟云原生的大思路是一致的，在云原生之前，开发看的是代码，运维看的是机器。但是在云原生时代，开发和运维看的都是应用。

那么怎么从应用视角去提升效率呢？既然云原生时代以应用为中心，那我们可以采取应用模板的方法。

比如企业里有 300 个应用，那么可以通过同一个应用模板把 300 个应用创建出来。这样做的第一个好处，就是通过应用模板去沉淀云原生时代的最佳实践和规范，一键化地创建应用，实现研发管理规范性的提升。第二个好处就是效率的提升，极大简化开发过程和运维过程。

不过还存在一个问题：业务人员更关心业务需求什么时候被受理、有没有被开发、能否上线，并不关注细节代码。所以有什么样的办法能把这些工作也管理起来呢？思路就是在产品视角里完成：从产品角度透视需求流转及相关研发活动，确保产品全生命周期得到良好的管理。

这三个视角相互解耦，不同角色可以专注于各自的职责和目标，高效完成自己的工作。它们又相互连接，构成一个有机整体。不同视角中的底层数据是同一份，研发信息也能够互联互通。通过这个有机的整体：

• 在应用视角，我们以应用为中心，实现云原生的持续交付，对工程师日常工作，尤其是工程类的工作流程进行优化。
• 在项目/空间视角，我们以需求（特性）的流动为主线，拉通了交付团队内各角色的高效敏捷协作，也实现了跨应用的研发协同。
• 在产品视角，我们以产品生命周期管理为目标，实现了复杂业务或产品的跨空间协作。

最终，通过一站式研发效能平台的多场景、多视角设计，可以支撑研发全链路的高效、高质量、可持续的交付。

总的来说，在项目或者空间视角里，我们看到的是每一个产品需求、每个研发团队的研发过程；在业务视角里，我们看到的是云原生的持续交付；在产品视角里管理业务需求，我们能够看到业务需求的流动。三者既分离又相互整合，从而形成一个生态共同体，帮助我们持续优化研发过程，这就是多视角的研发效能平台建设。

效能度量的五项精进

最后我们谈一下度量。我之前整理过一个模型，叫「研发效能度量的五项精进」。

1. 度量基础设施建设：包括价值流网络、工件网络、工具网络；
2. 度量指标体系：要让结果指标牵引整体，让过程指标赋能一线；
3. 洞察分析模型：包括分析思路、模型建立、分析方法和分析场景；
4. 度量产品建设：从数据、信息，到知识、智慧，要让转化过程自动化；
5. 数据驱动的实验思维：目的是让研发效能可量化、可分析、可提升。

尤其要注意的是，对单一维度过度解读是很危险的事情，所以我们需要通过指标组合，比如「北极星指标+群星指标+围栏指标」，来得到一个比较完整的流量指标体系，从而牵引着效能的提升。

总结和展望

对于研发效能的提升，首先是要升维思考，我强调研发效能不是解决局部的效率问题，也不是单点的工具或资源问题，而要从全局化、系统化的角度去寻求解决方案。同时，我们还要降维执行，要下钻到一线去解决具体的问题，并结合新技术与时俱进。

最近，我们已经看到大模型的技术在行业里面的探索应用，相信未来我们有机会从各个维度去重塑研发生产力，让研发过程获得十倍甚至更高的效能提升。

就让我们一起拥抱创新，持续探索，共同构建未来。