在 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 个利用创立进去。这样做的第一个益处，就是通过利用模板去积淀云原生时代的最佳实际和标准，一键化地创立利用，实现研发治理规范性的晋升。第二个益处就是效率的晋升，极大简化开发过程和运维过程。
不过还存在一个问题：业务人员更关怀业务需要什么时候被受理、有没有被开发、是否上线，并不关注细节代码。所以有什么样的方法能把这些工作也治理起来呢？思路就是在产品视角里实现：从产品角度透视需要流转及相干研发流动，确保产品全生命周期失去良好的治理。
这三个视角互相解耦，不同角色能够专一于各自的职责和指标，高效实现本人的工作。它们又相互连接，形成一个有机整体。不同视角中的底层数据是同一份，研发信息也可能互联互通。通过这个有机的整体：
- 在利用视角，咱们以利用为核心，实现云原生的继续交付，对工程师日常工作，尤其是工程类的工作流程进行优化。
- 在我的项目 / 空间视角，咱们以需要（个性）的流动为主线，拉通了交付团队内各角色的高效麻利合作，也实现了跨利用的研发协同。
- 在产品视角，咱们以产品生命周期治理为指标，实现了简单业务或产品的跨空间合作。
最终，通过一站式研发效力平台的多场景、多视角设计，能够撑持研发全链路的高效、高质量、可继续的交付。
总的来说，在我的项目或者空间视角里，咱们看到的是每一个产品需要、每个研发团队的研发过程；在业务视角里，咱们看到的是云原生的继续交付；在产品视角里治理业务需要，咱们可能看到业务需要的流动。三者既拆散又互相整合，从而造成一个生态共同体，帮忙咱们继续优化研发过程，这就是多视角的研发效力平台建设。
效力度量的五项精进
最初咱们谈一下度量。我之前整顿过一个模型，叫「研发效力度量的五项精进」。
- 度量基础设施建设：包含价值流网络、工件网络、工具网络；
- 度量指标体系：要让后果指标牵引整体，让过程指标赋能一线；
- 洞察分析模型：包含剖析思路、模型建设、分析方法和剖析场景；
- 度量产品建设：从数据、信息，到常识、智慧，要让转化过程自动化；
- 数据驱动的试验思维：目标是让研发效力可量化、可剖析、可晋升。
尤其要留神的是，对繁多维度适度解读是很危险的事件，所以咱们须要通过指标组合，比方「北极星指标 + 群星指标 + 围栏指标」，来失去一个比拟残缺的流量指标体系，从而牵引着效力的晋升。
总结和瞻望
对于研发效力的晋升，首先是要升维思考，我强调研发效力不是解决部分的效率问题，也不是单点的工具或资源问题，而要从全局化、系统化的角度去寻求解决方案。同时，咱们还要降维执行，要下钻到一线去解决具体的问题，并联合新技术与时俱进。
最近，咱们曾经看到大模型的技术在行业外面的摸索利用，置信将来咱们有机会从各个维度去重塑研发生产力，让研发过程取得十倍甚至更高的效力晋升。
就让咱们一起拥抱翻新，继续摸索，独特构建将来。