DevOps 与研发效能专家张乐：研发效能的升维思索与降维执行
在 4 月 20 日举行的《中国企业软件研发管理白皮书》发布会上，DevOps 与研发效能资深技能专家张乐老师做了一场名为《研发效能的升维思索和降维执行》的主题演讲，阐述了怎样体系化思索研发效能的关键要素、互动结构及实施路径，并将其与落地执行有机结合起来。以下为张乐老师的演讲内容摘录。起首我要支持一下《中国企业软件研发管理白皮书》，在我看来这是特别好的一个载体。因为我们之前看到许多与研发管理相关的内容都是从国外引入的，比如 DevOps 现状观察报告等。这次非常开心能够看到我们本土输出的研发管理的实践履历，为广大研发效能管理者和从业人员提供参考，这是一次有益的实验。
回到正题，今天我分享的话题是「研发效能的升维思索和降维执行」，希望能给大家带来一些开导。
1、研发效能到底怎么提拔？
当我们谈论研发效能时，所指代的内容、谈论的焦点可能并不完全相同。所以在讲研发效能怎么提拔之前，我们起重要回答的是：大家谈论的研发效能到底是什么？我把这个题目抛给了最近很火的 ChatGPT，同时也在行业里调研了一些软件工程师。
大家的回答里罗列了许多有助于研发效能提拔的要素，比如目标、流程、方法、技能、知识、工具，另有团队沟通等。这些内容为我们找到效能提拔的突破口提供了一些线索，但相对局部和片面，并无法直接回答「构造研发效能怎样提拔」这个综合性的题目。
所以，我们今天讲研发效能的升维思索，起首是要清晰地知道总体目标是什么，与达到目标相关的要素有哪些，以及这些要素之间的关联关系是什么。只有如许，才能看到题目的本质，有用提拔效能。
如下图所示，我从管理、工程和技能三个关键维度出发，对影响研发效能的关键要素进行了一些梳理：
https://i-blog.csdnimg.cn/blog_migrate/94150d5992d33cbde39fa2d799a4c853.png
第一个是管理维度，强调通过流程、文化和人来帮助构造提效。从效率层面看，起重要关注的一个点与需求相关。行业里有句话叫「GIGO（Garbage in garbage out）」，假如你的输入是低质量的，那么你的输出也是低质量的。这就要求我们在研发源头肯定要制止开发不靠谱的需求，而实例化需求的实践能够帮助我们。
从质量层面看，测试/安全左移、质量门禁、各种应用变更管理等都可以对质量的提拔产生促进作用。那这些要素怎么才能对工程师的体验产生很好的影响呢？一个行之有用的方法就是标准化和简化研发流程。比如说有没有一些在 Code Review 阶段就能发现的题目？有没有在自动扫描阶段就能发现的题目？通过流水线可否自动检出 Bug？而不是所有的变更都要走重量级的审批流程。
第二个是工程维度，也就是通过自动化、一致性的方式来执行研发运动。
从效率层面看，代码分支怎么管？是主干开发还是分支开发，还是 Git Flow？这些差别的分支模型，都会对研发效率产生很大影响。除此之外，另有自动化构建/测试、环境治理、部署发布等，也都会对团队的交付周期和交付效率产生影响。
在质量层面，代码评审、单元测试都是工程维度经常需要考虑的实践。跟大家分享一个数据，近期腾讯发布了《2022年腾讯研发大数据报告》，内里提到代码评审的参与率是 74.6%，代码评审的千行评论数为 15.3 个。也就是说参与代码评审的每 1000 行代码，就有 15 个评论。这阐明代码评审这件事是在实着实在地做，而不是外貌功夫。
那么从工程维度看，怎么优化我们研发工程师的开发体验呢？就是通过自动化流程，减少手工重复的工作，让大家聚焦在业务代码的开发上。
第三个是技能维度，偏重于应用和底子设施架构的设计和实现，以及新技能的应用。
比如云原生，另有如今非常火的 ChatGPT。许多同学已经开始实验让 ChatGPT 帮助我们细化需求，天生概要设计，大概在局部做代码补全、代码重构，以及自动天生一些测试。可以说，智能化开发、智能化测试、智能化运维逐渐走进我们的视野了。
但题目是，这些要素不能单独存在，因此我们需要一个抓手，将这些要素体系化，才能真正落地到实际中。
02 研发效能的黄金三角模型
在 2021 年，我提出了「研发效能黄金三角」的框架，将效能实践、效能平台和效能度量同一起来。经过这两年的持续探索和实践沉淀，我把这个模型升级成了 2.0 版本，在框架里增加了更多细节描述，比如效能实践地图、效能平台的五个层次、效能度量的五项精进等，目的是让我们对于研发效能提拔的理解具有全局性和体系性。
https://i-blog.csdnimg.cn/blog_migrate/5c1a5e481312fd9f4f0107e27f25a9a2.png
总的来说，落地研发效能提拔工作，并不是只关注效能实践、效能平台、效能度量这三件事就可以了，这还是一种静态思维。我希望我们去思索要素和要素之间的互动、关联关系，并让这些要素形成一个彼此强化、持续优化的增强回路。这个增强回路能够把研发效能里的良好实践沉淀到工具平台上，通过一站式的平台来承载这些研发实践，帮助我们做规模化的扩展；而效能平台又会产生大量数据，支持我们做效能的度量与分析，形成持续改进的闭环。
03 研发效能的实践地图
黄金三角看上去还是比较抽象，所以我在内里写了一些落地的条目：比如在效能实践里，我们需要关注产物导向的交付范式，关注灵敏精益协作、持续交付的工程实践、云原生的持续交付等。我将这些内容总结归纳成了「研发效能的降维执行——效能实践地图」，如下图所示：
https://i-blog.csdnimg.cn/blog_migrate/472daf96d08b8494cf86afebefb39ade.png
内里的要点有许多，我偏重讲一下产物导向的交付范式。如下图，我将产物导向与项目导向的交付模式从多个维度进行了对比：
https://i-blog.csdnimg.cn/blog_migrate/c8f08342b80d477e8d6928dbbd304ce8.png
起首，从思维模式来看。天下上许多举世瞩目的工程都有项目管理理论的支持，比如甘特图，它是由亨利·劳伦斯·甘特在 1917 年所创，随后被用于修建当时天下上最大的混凝土结构——胡佛大坝。值得注意的是，甘特图在当时的使用场景是高确定性的底子设施工程，重复性工作多，不确定性工作较少。
在类似的场景下，用这种管理范式足够了。但是，我们不能指望两次工业革命之前的范式到今天的数字化时代依然见效。现如今，大环境是快速的、迭代的，其显著特性是易变性、不确定性、模糊性、复杂性，那么研发范式也需要做相应的调整才行。所以如今的研发项目管理，除了项目导向外，也要考虑产物导向。
什么是产物导向的思维模式呢？就是要认可不确定性，用迭代的思路去解决不确定环境的题目，持续交付业务代价。
客岁我翻译了一本书 Project to product，书名直译是《从项目到产物》，但最终我以为，《代价流动》这个书名更能表现书中要表达的内容，因为这本书强调我们要考虑代价在企业里跨越多个部分的流动，要从端到端的视角去看企业全局的代价交付过程，而不是某个构造、某个部分的局部过程。
为什么许多企业有技能债？肯定程度上是项目模式导致的。一个项目是有终点的，到截止时间之后，没有人再乐意投入资源。那时工作会指派给一个人，让他在做新项目的同时再去维护老项目，这就导致大量没有人乐意维护的技能债务变得越来越多。但假如从产物导向来解决这个题目，会容易一些。
其次，从乐成标准来看，项目导向是以成本中央的运营模式，以按时、按预算完成项目既定的交付内容来作为乐成标准。但是产物导向，是把业务乐成作为真正的乐成标准，它更聚焦于增量的代价交付。
项目导向是把人安排在工作上，一个人在一年里可能换了七八个项目，但他很难在每一个项目里都有积聚、跟团队磨合得很好，也很难产生很高的效能。而产物导向，就是要长期稳定的团队来负责长期稳定的产物，从而产生长期稳定的代价。别的，这两种模式在构造与团队、驱动模式和可见性等方面都有着完全差别的处理方式。
说到可见性，我们不得不提到「西瓜现象」——常被用于描述项目管理中未袒露的题目。西瓜外貌是绿色的，内里的瓤是赤色，就好像我们在项目管理过程中，向上汇报时以为进度一切正常，最后上线前才发现上不了。这是为什么？因为本质的题目没有被袒露。因此，产物导向就是要解决这个题目，把可见性袒露出来，通过迭代持续的优化，让过程变得更透明。
除了产物导向的交付范式外，持续交付也是我们在「效能实践地图」中要格外关注的。
04 云原生的持续交付实践
在云原生时代，我们不禁追问：云原生的持续交付跟平凡的持续交付到底有何种区别？要考虑这个题目，我们先要搞清晰云原生到底有什么差别，我以为重要有三个点：
[*]可以通过代码去管理底子设施（ IaC，Infrastructure as Code）；
[*]微服务和容器化，能够帮助我们更简化、更解耦地开发和部署应用；
[*]更完善的发布控制，比如各种灰度策略等。
那么，接下来的题目是，云原生的持续交付该怎么做？概括来说，云原生的持续交付就是在云原生的技能底座之上，用 CI/CD 串联上下游工具链和底层的工具平台，最后做到全流程的自动化。
https://i-blog.csdnimg.cn/blog_migrate/ad2589f1ffe802e8d9ca2b80917bdf9e.png
05 效能平台的多视角设计
大家很关注工具，但假如只是把多个工具集成在一起，那只是做了第一步，更高阶的方式是贴合具体研发场景实现多视角的设计。
要做好工具平台的建设，就要从三个视角出发，分别是产物视角、项目/空间视角、应用视角。这三层是一个相互嵌套的关系，越往外层越是产物和业务导向的；越靠内层越是工程和技能导向的。拜见下图：
https://i-blog.csdnimg.cn/blog_migrate/2e23c724fe2622e7f263d2e91a5976a5.png
先看最容易理解的项目视角/空间视角。我们如今进入到任何一个 DevOps 平台，都会要进入到一个项目/空间中。负责某个产物或某个部分工作的团队在这里工作，他们分解需求、写代码、做测试，完成部署发布。这里的关键点是，各个范畴的工具怎么才能有机整合在一起，高效支持工程师的工作。这就需要跨范畴互联互通的本事，让开发、测试、运维之间的研发运动能够衔接得更丝滑。
不过，只有空间大概项目视角是不够的。在一个大的项目里，可能有 1000 个人，500 个服务，几万条流水线。这种信息爆炸会让团队成员不容易聚焦在自己关注的工作上。
假如以应用为中央来构造 DevOps 流程，就可以让工程师聚焦在自己负责的应用上，管控团体流程。这跟云原生的大思路是一致的，在云原生之前，开发看的是代码，运维看的是呆板。但是在云原生时代，开发和运维看的都是应用。
那么怎么从应用视角去提拔效率呢？既然云原生时代以应用为中央，那我们可以采取应用模板的方法。
比如企业里有 300 个应用，那么可以通过同一个应用模板把 300 个应用创建出来。如许做的第一个好处，就是通过应用模板去沉淀云原生时代的最佳实践和规范，一键化地创建应用，实现研发管理规范性的提拔。第二个好处就是效率的提拔，极大简化开发过程和运维过程。
不过还存在一个题目：业务人员更关心业务需求什么时间被受理、有没有被开发、可否上线，并不关注细节代码。所以有什么样的办法能把这些工作也管理起来呢？思路就是在产物视角里完成：从产物角度透视需求流转及相关研发运动，确保产物全生命周期得到精良的管理。
这三个视角相互解耦，差别角色可以专注于各自的职责和目标，高效完成自己的工作。它们又相互连接，构成一个有机团体。差别视角中的底层数据是同一份，研发信息也能够互联互通。通过这个有机的团体：
[*]在应用视角，我们以应用为中央，实现云原生的持续交付，对工程师一样寻常工作，尤其是工程类的工作流程进行优化。
[*]在项目/空间视角，我们以需求（特性）的流动为主线，拉通了交付团队内各角色的高效灵敏协作，也实现了跨应用的研发协同。
[*]在产物视角，我们以产物生命周期管理为目标，实现了复杂业务或产物的跨空间协作。
最终，通过一站式研发效能平台的多场景、多视角设计，可以支持研发全链路的高效、高质量、可持续的交付。
总的来说，在项目大概空间视角里，我们看到的是每一个产物需求、每个研发团队的研发过程；在业务视角里，我们看到的是云原生的持续交付；在产物视角里管理业务需求，我们能够看到业务需求的流动。三者既分离又相互整合，从而形成一个生态共同体，帮助我们持续优化研发过程，这就是多视角的研发效能平台建设。
06 效能度量的五项精进
最后我们谈一下度量。我之前整理过一个模型，叫「研发效能度量的五项精进」。
[*]度量底子设施建设：包罗代价流网络、工件网络、工具网络；
[*]度量指标体系：要让结果指标牵引团体，让过程指标赋能一线；
[*]洞察分析模型：包罗分析思路、模型建立、分析方法和分析场景；
[*]度量产物建设：从数据、信息，到知识、智慧，要让转化过程自动化；
[*]数据驱动的实验思维：目的是让研发效能可量化、可分析、可提拔。
尤其要注意的是，对单一维度过度解读是很伤害的事情，所以我们需要通过指标组合，比如「北极星指标+群星指标+围栏指标」，来得到一个比较完备的流量指标体系，从而牵引着效能的提拔。
07 总结和展望
对于研发效能的提拔，起首是要升维思索，我强调研发效能不是解决局部的效率题目，也不是单点的工具或资源题目，而要从全局化、体系化的角度去寻求解决方案。同时，我们还要降维执行，要下钻到一线去解决具体的题目，并结合新技能与时俱进。
最近，我们已经看到大模型的技能在行业内里的探索应用，相信将来我们有时机从各个维度去重塑研发生产力，让研发过程获得十倍甚至更高的效能提拔。
就让我们一起拥抱创新，持续探索，共同构建将来。
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。
页:
[1]