许多研发管理者并不想提升研发效能,这才是最大的问题!

2021-09-30   出处: 软件质量报道  作/译者: Test Ninja  

        不是标题党,只是敢于说真话,说出许多人想说而不敢说的话。为何会有这样的结论,请听我慢慢道来。不过,文中说的现象,只是存在于某些公司中,不是每个公司都有的现象,也不要对号入座。

        ● 研发效能最近几年的确比较热,各个大厂先后成立工程效能团队或部门,开发了一些效能平台,推出白皮书或举办效能峰会等,例如:2014年百度公司成立工程效率部,2019年和平台测试部合并成立工程效能部

        ● 2015 年滴滴工程效能团队成立,构建项目管理、代码管理、持续交付、效果验证等多个平台。

        ● 2015年 腾讯一站式软件研发管理平台—CODING上线

        ● 2015年底,阿里巴巴全面启动集团中台战略

        ● 2016年12月 华为云DevCloud(一站式云端 DevOps 平台)发布

        ● 2017年发布《百度工程师手册》

        ● 2017年6月首届阿里研发效能峰会召开

        ● 2018年10月发布《百度工程能力白皮书》 

        ● 2019 年 5 月,百度推出百度效率云(前身是内部工具链),包含三大平台——iCafe, iCode, iPipe

        ● 2020年9月 首届QECon(全球软件质量与效能大会)在上海成功举办

        ● 2021年5月 相聚鹏城、论道质效:QECon大会深圳站圆满落幕

        即使“研发效能” 这么红火,但不少人对“研发效能”还是有误解,最近还看到一个采访,被采访的专家说 “研发效能是指单位时间产出量”,将“效能”和“效率” 搞混了。

研发效能

究竟什么是研发效能?

        其实,研发效能不等于研发效率。效率是指单位时间产出量,英文常用Efficiency,相当于生产力(Productivity),即效率 = 产出/所用的时间。而效能是指对业务有实际价值的效果、成效,更强调有效性、效益,英文常用Effectiveness,效能 = 有价值的产出/所用的时间,效能公式的分子是效率公式分子中有价值的一部分——有效的成果。

        简单地从软件研发来看,效能= 对客户有价值的需求 + 效率 ,在需求有效的情况下,效率越高,效能越高;效率/生产力不变,需求对客户的价值越高,开发效能就越高。

        如果考虑到商业环境变化比较快,还需要考虑研发是否有能力适应环境的变化能与时俱进,保持稳定的、有价值的交付,即我们经常所说的可持续性。另外,短时间的苦干也可以有高产出,但不能持续。我在上项目管理课程时,曾经问过同学:如果及时、按质按量、按预算完成项目交付,一定能说明项目获得成功吗?多数同学毫不犹豫说,项目成功了。等他们回答完了,我给他们讲了一个真实的例子:一个团队,为了及时、按质按量地完成项目,每周工作7天、每天工作12小时(比996还辛苦),连续干了3个月,终于完成项目目标,但项目结束后,大家都离职了,因为公司要控制成本在预算内、没有加班费,而且大家干的很辛苦。似乎项目 “成功” 了,团队却跨了,这能说是一个成功的项目吗?不能。所以也有人认为:效能 = 有效性 + 效率 + 可持续性,即简单地说,效能就是能长期可持续地、高效地开发出有价值的软件产品

为何不想提升研发效能呢?

        记得多年前,在美国的一位从事软件开发的同学对我说,写代码不写出几个Bug,就容易被老板解雇,而且也不能清除所有的Bug,自己的价值也不容易得到体现。代码没问题,老板都不知道你,而线上出问题,你去救火(troubleshooting)救成功了,就是英雄,正像扁鹊,名气很大,而最有价值的老大(扁鹊的大哥)一点名气都没有。

        本来高质量带来高效率,但开发人员并不这么想,总想留点Bug在代码中,从而让公司挽留他。虽然上面那样的想法,不是每个程序员都有,但一定会有一部分程序员有类似的想法。

        更何况国内的加班文化进一步促进大家对效能的提升没那么在意,一个员工特别忙,就显得勤奋,常常被认为是一个好员工;如果员工不忙、轻松工作,往往被看成是偷懒,往往不会被看作是一个好员工,所以有人会在白天上班时间拖拖拉拉,然后去吃一个免费的晚餐,在科技园区逛一逛,再回到办公室加班,直到晚上9、10点下班,给领导一个良好的印象。

        幸运之处,软件总不是那么好度量,如果你按代码行来度量大家的工作量,会被骂死,因为这的确不科学。更何况度量专家常说,不能将度量的结果作为个人绩效的考核指标。所以,开发人员每天完成的工作也很难度量,唯一的硬性度量指标就是工作时间

        员工是那样,许多管理者更没有动力去提升研发效能。如果效能提升了,人员是不是要减少?团队规模缩小,自己的价值就很可能降低。因为团队规模越大越能体现管理者的价值,带的人越多,预算也就越多,越有操作的空间。所以,团队/部门的研发管理者,从来不会想减少自己的人,而是希望扩充自己的团队

        曾经想帮研发团队梳理并优化整个研发过程,提升效能,大力缩减研发成本,但和一些朋友沟通,大家都觉得阻力会很大,主要原因如上分析。

        我们也曾看到,有效能专家说,一套解决方案帮助团队提升到 “10倍的响应速度、10倍的过程质量、10倍的有效价值”,那是不是效能提升100-1000倍,原来几万人的队伍可以降到几十~几百人?有人说,人不能少,会做更多的事情。我看了他所在的大厂,产值的确增加了30%左右,已经很不错了,但没有增加十倍,更不用说100-1000倍。

        如果只做正确的事,哪有那么多正确的事可做?就像软件功能,刚开始的确有不少新功能要开发,所以刚开始加人是正常的,到了稳定的时候,管理者也不会主动要求减人,甚至还是喊 “人不够”,从来就没有感觉人够的时候,然后就开发一些没有价值的功能,改来改去,效率有(如交付的代码、特性),质量(指功能、性能、兼容性、安全性等)也不错,就是没有效能,没有价值

        所以,重复造轮子的事,在软件研发过程中常见的现象;有的团队可以采购一些工具或引入一些开源工具,但没有,而是自己开发;有些团队把简单的事情复杂化,有些团队不断尝试新的技术、不断迁移平台......就是从来不做正确的事,不能这么说应该说:有相当一部分时间不做正确的事。

        做对事情,似乎是由业务部门、产品经理来决定,其实不是,交付哪些功能或特性、技术选型、是否要迁移到不同的平台、是否采用新的技术、是否采用新的流程等等,还是在研发部门。业务部门,只是说要能解决哪些业务问题、用户有什么需求,而功能如何实现,那还是研发部门的事,业务部门也不懂,究竟需要多大的工作量业务部门就更说不清楚,因为研发部门自己都说不清楚。

如何提升研发效能呢?

        虽然有些人不想提升研发效能,还是会有不少人想提升研发效能,否则研发效能不会这么热。

        管理大师彼得·德鲁克曾在《有效的管理者》一书中指出:效率是‘以正确的方式做事’,而效能是‘做正确的事’。如果是这样,不断提升对用户/业务的认知,控制好需求质量,就可以提升效能。但今天我们给研发效能赋予更多的内涵,让软件研发效能既要做到‘做正确的事’,又要做到‘以正确的方式做事’,还要具有可持续性。

        如果每个人都想提升研发效能,其实也很容易,因为大家不笨、有智慧,心中常有“效率、有效性、持续性”这样的意识,不断反思,就能及时发现工作中这类问题,并能一起努力解决这些问题,持续提升效能。效能提升,也不能一口吃成胖子,一定是一个持续的过程。

        按照前面讨论的逻辑思维,要提升研发效能,必须和产品收入、人均产值等结果捆绑起来,类似游戏工作室、事业部那样的建制,产品营收(利润)的一定比例用于奖励研发人员、市场人员和业务人员,人均效益越高,奖励比重越高。业务驱动研发,市场驱动效能,让研发不再只是按预算来运行的一个独立部门,而是和市场收益直接绑定的一部分

        ● 在研发内部如何提升效能呢?提升研发效能的具体实践很多,可以列出一堆,例如技术选型、中台、低代码构建、Serverless、开发工具、脚手架、代码规范、代码仓库管理、代码托管、本地代码检查、代码提交规范、代码审查、接口文档平台、接口测试平台、即时协作和企业通讯、团队知识库、任务调度平台、配置中心、项目管理、CI/CD 流水线、容器管理平台、监控告警、日志平台、可视化数据管理、链路追踪等。但归纳起来,按照传统的观点,会从“人、流程和技术” 三个维度去提升研发效能,建立良好的组织文化,提升全员的素质和能力,持续优化流程,构建良好的研发基础设施......像百度还会加上数据,因为许多公司拥有编程大数据(如源代码数据、缺陷数据、日志数据等),的确可以帮忙分析问题、度量效能,以提升效能。但如果按照前面的效能定义,问题会相对简单,就是提升软件研发的效率、有效性和可持续性:效率提升:过去几十年一直在讨论中,积累了很多经验,从CMU SEI的PSP(如个人能力)、TSP(如团队协同)开始直到敏捷、精益和DevOps(如高度自动化的交付流水线、迭代速度、交付周期等),以及到今天将人工智能(AI)赋能软件研发、运维,都能致力于效率的提升;

        ● 有效性:即做对事情,甚至可以理解为需求质量、设计质量和代码质量,如确保需求是有效的,来自于真实的业务需求和用户需求,准确、有效的定义需求;选择正确而合适的架构和开发技术等;

        ● 可持续性:主要指可持续性交付与团队能力的可持续性发展,这也和软件的质量(特别是软件的内部质量,如可维护性)相关,例如系统架构强耦合、代码不规范、复杂度高,即软件研发的技术债快速上升,最终就很难做到可持续的快速交付。这其中也要求确保公司体制、流程的可持续的、稳步改进和系统平台的可持续的、稳定的演化,关注方法、技术和工具前后的连贯性或衔接性,并力求做到团队的持续建设和培养、组织文化的持续提升等。

        研发效能的提升离不开业务,而且是为了业务、服务于业务,也就是我们常说的“不忘初心”。效能提升的过程,也应该是企业成本下降、利润提升的过程,否则说明研发效能的提升一定是有问题的。研发效能的提升要有一个愿景:效能驱动效益,最大化企业的价值。

        具体如何做,后面会提供非常有价值的、大厂实践的详细资料,供大家下载学习,不是几千字能讲得清楚。

如何度量研发效能呢?

        软件研发效能度量也是争议比较大的一个问题,虽然度量会产生副作用,但是必须做,不度量,就不知自己在哪里,就无法改进。如果其它配套措施跟上,就能最大程度消除副作用。例如,每千行代码缺陷数常常被用于度量开发编写代码的质量,如果你纠结这单一的指标,它的确会有问题,如人们常常说的,一个能力弱的程序员将几千行就能实现的功能特性写成1-2万行代码,分母增大了,每千行代码缺陷数就下降了不少,不能反映真实情况。但是,加上代码评审、代码复杂度度量、单元测试、单元性能指标等其它配套的措施和度量,这样的问题就能发现。

        研发效能的度量一是要成体系,系统、全周期、科学合理的设置,并和研发活动、项目管理等结合起来,如需求评审、设计/技术方案评审、代码评审、过程评审、管理评审、等。度量也没那么复杂,更没那么可怕,先做起来,及时发现问题及时纠正;一面实施一面改进,持续改进度量自身,消除各种隐患和不合理的度量,就能让度量成为一种驱动效能提升的坚实力量

        说起研发效能度量,人们会常常提起阿里云效的五大度量指标,相对比较简单、清晰。在云效平台上,针对研发效能洞察上,侧重代码洞察、项目洞察

        (阿里云效的研发效能度量指标体系)

        如果从本文给的研发效能的定义(有效性 + 效率 + 可持续性),滴滴的研发效能度量指标体系更吻合一些,在特征指标中强调了“有效性、可持续性”,涉及8项指标,但是除了“代码复杂度、测试覆盖率、团队构成及人数(影响评判有些困难)” 这3项指标之外,其它指标具有一定的主观性,难以自动获取数据。一旦度量数据靠人工输入,问题就会比较大。

        像ThoughtWorks研发效能指标体系就回归到传统的两大度量指标:交付效率和交付质量,只是在具体度量指标设置上考虑了可持续性,如技术债天数、需求停留时间、研发停留时间等。


声明:本文为本站编辑转载,文章版权归原作者所有。文章内容为作者个人观点,本站只提供转载参考(依行业惯例严格标明出处和作译者),目的在于传递更多专业信息,普惠测试相关从业者,开源分享,推动行业交流和进步。 如涉及作品内容、版权和其它问题,请原作者及时与本站联系(QQ:1017718740),我们将第一时间进行处理。本站拥有对此声明的最终解释权!欢迎大家通过新浪微博(@测试窝)或微信公众号(测试窝)关注我们,与我们的编辑和其他窝友交流。
140°|1401 人阅读|0 条评论

登录 后发表评论