谈到研发效能,我们有着自己的独到见解。我们看到的现象是:只要努力搞,没有折腾不垮的团队。 虽然有很多大厂研发效能做的还不错,成为了大家膜拜的对象,但是我们也看到很多“内卷”现象的发生。经历了很多故事,我们更能谈谈自己的理解和感悟。

研发效能是目前互联网企业和传统软件企业都高度关注的领域,互联网大厂希望通过“研发效能”实现持续的研发能力提升以应对日趋复杂的产品开发;腰部厂商则希望通过“研发效能”实现弯道超车,充分发挥后来者居上的优势;更多中小企业看到国内互联网大厂不约而同地在这个领域重点投入,纷纷也是摩拳擦掌准备在效能领域发力。

一夜之间,似乎只有推进了研发效能,才能提升研发团队的效率,才能让自己在和友商的比拼中不至于输在起跑线上。

那么现在企业的研发效能实践到底为企业带来了多大的优势,又帮企业解决了哪些问题呢?那些推行研发效能的企业现在的状态怎么样?研效问题到底解决了吗?

别急,这些问题其实大多都还没有解决,而且有些问题可能还变得更糟糕了。毕竟研发效能的实施没有捷径,需要摸着石头过河,肯定不会能像电影里面演得那样注定会有皆大欢喜的结局。经历了风雨,不一定能看见彩虹,更有可能会得重感冒。研发效能问题今天解决不了,不要着急,因为明天同样也解决不了。 所以就让我们“放心大胆”地看看研发效能到底是如何搞垮一个团队的。

要看懂研发效能如何搞垮一个团队,我们首先需要对研发效能有一个全局的认识,需要先从正向的角度来理解研发效能。

到底什么是研发效能

和敏捷的概念类似,到底什么是研发效能很难精确定义。其实很多复杂概念也不是定义出来的,而是逐步演化出来的,是先有现象再找到合适的表述。其实,效率和效能也从来都不是软件工程的专有名词,纵观人类发展史,就是生产力和生产效率不断提升的发展篇章,到了数字化时代,软件研发效能的重要性被凸显了出来。如果要用一句话来总结研发效能的话,我们会用“更高效、更高质量、更可靠、可持续地交付更优的业务价值”来总结。

图 1:研发效能的“第一性原理”

解释一下其中几个关键概念:

• 更高效:价值的流动过程必须高效顺畅,阻力越小越好。

• 更高质量:如果质量不行,流动越快,死的也会越快。

• 更可靠:安全性和合规性要保障好。

• 可持续:输出不能时断时续,小步快跑才是正道,不要憋大招。

• 更优的业务价值:这是从需求层面来说的,你的交付物是不是真正解决了用户的本质问题。比如:“女生减肥不是本质问题,女生爱美才是”。可以体会一下。

在这个概念的引导下,我们引出持续开发,持续集成,持续测试,持续交付和持续运维的理念,它们是研发效能落地的必要实践。与此同时,我们还需要从流动速度,长期质量,客户价值以及数据驱动四个维度来对研发效能进行有效的度量。

为什么大厂都开始搞研发效能

阿里的云效、腾讯云的 CODING、百度的工程效能白皮书都是国内研发效能领域的标杆,可是你有没有想过,为什么最近几年各大行业龙头企业都纷纷开始在研发效能领域发力,而且步调如此一致,我们认为背后的原因有以下这么三点:

图 2:组织层面的“谷仓困局”

很多企业存在大量重复造轮子

就像“中台“概念一样,现在很多大企业的产品线非常广,其中存在大量重复的轮子,如果我们关注业务上的重复轮子,那么就是业务中台;如果我们关注数据建设上的重复轮子,那么就是数据中台;如果我们关注研发效能建设上的重复轮子,那就是研效平台,其实研效平台在某种程度上也可以称之为”研发效能中台“,其目标是实现企业级跨产品跨项目的研发能力复用,避免原来每条产品线都在做研发效能所必须的”0 到 1“,没人有精力去关注更有价值的”1 到 n“。现代化的研效平台会统一来打造组织级别通用研发能力的最佳实践平台。

toC 产品已经趋向饱和

从商业视角来看,现在 toC 产品已经趋向饱和,过去大量闲置时间等待被 APP 填满的红利时代已经一去不复返了,以前业务发展极快,那么用烧钱的方式(粗放式研发,人海战术)换取更快的市场占有率达到赢家通吃是最佳选择,那个时代关心的是软件产品输出,研发的效率都可以用钱填上。而现在 toC 已经逐渐走向红海,同时研发的规模也比以往任何时候都要大,是时候要勒紧裤腰带过日子了,当开源(开源节流中的开源)遇到瓶颈了,节流就应该发挥作用。这个节流就是研发效能的提升,同样的资源,同样的时间来获得更多的产出。

部分企业存在“谷仓困局”

从组织架构层面看,很多企业都存在“谷仓困局”(图 2),研发各个环节内部可能已经做了优化,但是跨环节的协作可能就会有大量的流转与沟通成本,从而影响全局效率。基于流程优化,打破各个环节看不见的墙,去除不必要的等待,提升价值流动速度正是研发效能在流程优化层面试图解决的一大类问题。

研发效能真的能够提高吗

既然如此重要,那接下来的问题是研发效能是否真的能提高?

很不幸,我们的观点比较悲观。我们认为研发效能的绝对值随着以下因素的增长必然会变得越来越差,就像我(声明一下,这里没有张乐老师)的头发一样,随着时间的推移必然会越来越少一样。

• 软件架构本身的复杂度提升(微服务,服务网格等)

• 软件规模的不断增长(集群规模,数据规模等)

• 研发团队人员规模不断扩大引发沟通协作难度增长

所以,我们能做的不是提升研发效能的绝对值,而是尽可能减缓研发效能恶化的程度,使其下降的不至于太快,努力保持现状就是成功。

图 3:研发效能的鸿沟

减缓研发效能恶化我们能干啥

看清了本质后,关于如何减缓研发效能的恶化,我们能做点什么呢?

可以说研发效能的涉猎面是很广的,软件研发的每个阶段都有研发效能需要关注的问题,腾讯提出的“研发效能双流模型”可以说很好的诠释了这一概念。双流模型从软件研发的各个阶段提出了研发效能提升的各种工程实践,并且倡导需求价值流和研发工程流的自动联动。

图 4 研发效能的双流模型

这里我们列举一些实践给大家抛砖引玉一下,下期的文章我会更系统地来说明其中的最佳实践。

• 可以通过 All-in-one 的开发环境降低每位开发人员开发环境准备的时间成本,同时又能保证开发环境的一致性。更高级的玩法是使用云端集成开发环境 IDE,实现只要有浏览器就能改代码,这一领域国内典型的代表就是腾讯云 CODING 旗下的 Cloud Studio 以及 Github 目前处于 beta 测试阶段的 CodeSpaces。

• 可以借助基于 AI 的代码提示插件,大幅度提升 IDE 中代码的开发效率。输入一段相同的代码,不借助 AI 代码提示插件,需要敲击键盘 200 次,启用插件可能只需要 50 次键盘敲击,这样可以更容易让开发工程师进入“心流“状态,实现”人码合一“。

• 代码的静态检查没有必要等到代码递交后由 CI 中的 Sonar 流程来发起,那个时候发现问题再修复为时已晚,完全可以通过 Sonar Lint 插件结合 IDE 实时发起本地的代码检查,有问题直接在 IDE 中提示,直接修复,这样开发工程师会更愿意修复问题,因为成本更低,也不会引起修复后的再次发版。

• 单元测试比较耗费时间,可以借助 EvoSuite 之类的工具降低单元测试的开发工作量。

• 对于规模较大的项目,每次修改后编译时间比较长。可以采用增量编译,甚至是分布式编译(Distcc 和 CCache)提升效率,对于 Maven 项目还可以通过缓存 pom 依赖树进一步降低编译时间。

• 前端开发可以借助 JRebel 和 Nodemon 之类的工具使前端开发预览的体验更流畅,实现前端代码的“所见即所得”,避免重复的编译、打包、部署和重启步骤,以此提高开发过程的流畅度。

• 选择适合项目的代码分支策略对提升效率也大有帮助。

• 构建高度自动化的 CI 和 CD 流水线将大幅提升价值的流转速率。

• 选择合适的发布策略也会对效能和风险之间的平衡起到积极的作用。比如架构相对简单,但是集群规模庞大,优选金丝雀,如果架构比较复杂,但是集群规模不是太大,可能蓝绿发布更占优势。

• 引入 DevSecOps 与 DevPerfOps 实践,使安全和性能不再局限在测试领域,而是形成体系化的全局工程能力,让安全测试成为安全工程,性能测试成为性能工程。

• ...

研发效能的“罗生门”

好了,理解了研发效能的正面观点后,我们再回来看看研发效能在实际落地过程中又是一番什么样的景象。

可以说理想很丰满,但是现实很骨感,下面就我一起看看国内研发效能的各种乱象。

迷信单点局部能力,忽略全局优化和拉通的重要性

研发效能的单点能力其实都不缺,各个领域都有很多不错的垂直能力工具,但是把各个单点能力横向集成与拉通,能够从一站式全流程的维度设计和规划的研发效能成熟平台还是凤毛麟角。现在国内很多在研效领域有投入的公司很多其实还在建设,甚至是重复建设单点能力的研效工具,这个思路在初期可行,但是单点改进的效果会随着时间收益递减,企业往往缺少从更高视角对研发效能进行整体规划的能力。很多时候局部优化并不能带来全局优化,有时候还会是全局恶化。

具有普适性的通用研发效能工具其实没有专属工具来的好用

既然打造了研发工具,那就需要到业务部门进行推广,让这些研效工具能够被业务部门使用起来。其实,很多比较大的业务团队在 CI/CD、测试与运维领域都有自己的人力投入,也开发和维护了不少能够切实满足当下业务的研发工具体系。此时要把新打造的研效工具来替换业务部门原来的工具,肯定会遇到很强的阻力。除非新的工具能够比老工具好 10 倍,用户才可能有意愿替换,但实际情况是新打造的工具为了考虑普适性很有可能还没有原来的工具好,再加上工具替换的学习成本,所以除非是管理层强压,否则推广成功的概率微乎其微。即使是管理层强压,实际的执行也会大打折扣,接入但不实际使用的情况不在少数。

用“伪”工程实践和“面子工程”来滥竽充数

如果你去比较国内外研发效能工程实践的差距,你会发现国内公司和硅谷公司的差距还是相当明显的。但是当你逐项(比如单元测试,静态代码扫描,编译加速等)比较双方开展的具体工程实践时,你会惊讶地发现从实践条目的数量来说,国内公司的一点都不亚于硅谷公司,在某些领域甚至有过之而不及。那为什么这个差距还会如此明显呢?我们认为这其中最关键的点在于,国内的很多工程实践是为了做而做,为的是“政治上的正确”,而不是从本质上认可这一工程实践的实际价值。这里比较典型的例子就是代码评审和单元测试。虽然很多国内互联网大厂都在推进代码评审和单元测试的落地,但是在实际过程中往往都走偏了。代码评审变成了一个流程,而实际的评审质量和效果无人问津,评审人的评审也不算工作量,也不担任何责任,这样的代码评审能有什么效果,结果可想而知。单元测试也沦为一种口号,都说要贯彻单测,但是在计划排期的时候压根没有给单测留任何的时间和人力资源,可想而知这样的单测是否能成功开展。所以,国内公司缺的不是工程实践的多少,而是工程实践执行的深度。不要用“伪”工程实践和“面子工程”来滥竽充数。

忽略研发效能工具体系的长尾效应

再回到研效工具建设的话题上,很多时候管理团队希望能够打造一套一站式普遍适用的研发效能平台,希望公司内大部分业务都能顺利接入,这和想法的确非常好,但是不可否认的,研效平台和工具往往具有非标准的长尾效应,我们很难打造一套统一的研效解决方案来应对所有的业务研发需求,各种业务研发流程的特殊性是不容忽视的。退一万步说,即使我们通过高度可配置化的流程引擎实现了统一研效解决方案,那么这样的系统会因为过于灵活,使用路径过多而易用性变得很差。这两者的矛盾是很难调和的。

盲目跟风

再来看看一些中小型研发团队,他们看到国内大厂在研效领域不约而同的重兵投入,所以也会跟风。他们往往试图通过引进大厂工具和大厂人才来作为研效的突破口,但实际的效果可能差强人意。大厂的研效工具体系固然有其先进性,但是是否能够适配你的研发规模和流程是有待商榷的,同样的药给大象吃可以治病,而给你吃可能直接丧命。很多时候研效工具应该被视为起点,而不是终点,就像你买了一辆跑车,你依旧不能成为赛车手。

迷信外部专家

引入大厂专家其实也是类似的逻辑,我常常会被问及这样的问题:“你之前主导的研效提升项目都获得了成功,如果请你过来,多久能搞定”?这其实是一个无解的问题。一定程度上,投入大,周期就会短,但是,实施周期不会因为投入无限大而无限变短。我可以帮你避开很多曾经踩过的坑,尽量少走弯路,犯过的错误不再次犯,但是,适合自己的路子还是要靠自己走出来,拔苗助长只会损害长期利益。

研效度量的罪与罚

最后再来看看度量。研发效能的度量一直以来都是很敏感的话题。科学管理时代我们奉行“没有度量就没有改进”,但是数字时代这一命题是否依然成立需要我们的反思。现实事物复杂而多面,度量正是为描述和对比这些具象事实而采取的抽象和量化措施,从某种意义上来说,度量的结果一定是片面的,反映部分事实。但没有银弹,也没有完美的效能度量。数据本身不会骗人,但数据的呈现和解读却有很大的空间值得探索。那些不懂数据的人是糟糕的,而最最糟糕的人是那些只看数字的人。当把度量变成一个指标游戏的时候,永远不要低估人们在追求指标方面“创造性”,总之我们不应该纯粹面向指标去开展工作,而应该看到指标背后更大的目标,或者是制定这些指标背后的真正动机。

总体来看,对于研发效能,我认为最重要的不是技术升级,而应该是思维升级,我们身处数字化的变革之中,需要转换的是自己的思维方式,我们需要将科学管理时代的思维彻底转为字节经济时代的思维。

研发效能的“冷思考”

最后,回到工程师层面,研发效能的提升对我们而言又意味着什么?

工具效率的提升并没有减少我们的工作时长

新工具新平台在帮助我们提升效率的同时,也不断增加着我们学习的成本。用前端开发来举例子,以全家桶为基础的前端工程化大幅度提高了前端开发的效率,但与此同时前端开发工程师的学习成本却在成倍增加,“又更新了,实在学不动了”一定程度反映了前端同开发的悲哀和无奈。

技术的升级正在不断模糊工作和生活的边界

早年时候的工作沟通除了面聊以外主要靠邮件,非工作时段老板给你发邮件你有各种正当理由不用及时回复,可是现在及时通讯工具 IM(那个消息已读提示,你懂的)再结合各种 ChatOps 实践,已经让工程师已经无法区分什么是工作什么是生活了,这难道是我们想要的吗?

随着在研发效能领域的不断投入,会有越来越多的研效工具诞生,所有这些工具都使人与工作之间的链接更加紧密,人越来越像工具,而工具越来越像人。我们之所以创造工具是想减轻我们自己的工作,但现实却很可能发展成,我们最终沦为被亲手创造的工具奴役。我们致力于的研发效能,究竟会成就我们,还是毁了我们?值得我们深入思考。

对于研发效能,实施的思路不对,方法不对会搞垮一个团队,我们需要的是体系化的方法论和相应的工程实践。请期待我们的下篇文章对此作出解读,让我们拭目以待!