软件研发效能度量的成功要素

本文主要内容:1、研发效能度量的误区和反模式2、怎么样系统性建设研发效能度量体系3、研发效能度量的正确方向怎么引导

软件研发效能度量的成功要素

本文正文内容共计3721字,建议阅读时间:7-8分钟。


本文主要内容:

1、研发效能度量的误区和反模式

2、怎么样系统性建设研发效能度量体系

3、研发效能度量的正确方向怎么引导

作者简介

张乐,腾讯技术工程事业群 DevOps与研发效能资深技术专家,多年一线互联网大厂工程效率领域工作经历(百度、京东等)历任埃森哲、惠普等全球五百强企业资深咨询顾问、技术专家长期工作在一线,专注于研发效能提升、敏捷与DevOps实践落地、万人研发规模 DevOps 平台设计、研发效能度量体系建设等方向;


本文来源张乐老师的研发效能系列文章,本文全篇收录于QECon组委会发布的白皮书之《研发效能实践指南



01. 研发效能度量的误区和反模式

正所谓“成功大都相似,失败各有不同"。研发效能度量其实也不算是个新鲜的话题了,随着业界各大公司日益发展壮大,很多都已经拥有几百、几千甚至上万人的研发队伍,研发效能的基础数据都积累了很多。

但我们经常看到一些所谓的“反模式”在不断上演,虽然从公司角度花了很大的力气去做研发效能度量,但从其理念、出发点到具体实践、指标选择、推广运营上似乎都存在一些问题、限制和弊端,以至于获得的成效不大甚至是造成负面影响,最终连累公司整体业绩。

研发效能度量的常见反模式如下:

使用简单的、易于获取的指标。正如比尔·盖茨曾经说:“用代码行数来衡量软件的生产力,就像用飞机的重量来衡量飞机的生产进度一样。”

过度关注资源效率类指标。我们不要过度关注资源效率类指标,还需要考虑流动效率类指标。

使用成熟度评级等基于活动的研发效能度量。狭隘的、以活动为导向的研发效能度量很可能失败。研发效能应该研发效能度量结果而不仅是过程,端到端价值流的局部优化对结果的改进效果很小,因为可能根本就没有解决效能瓶颈。

把研发效能度量指标设置为KPI进行绩效考核。所有的研发效能度量都可以被操纵,而数字游戏式的研发效能度量会分散员工的注意力并耗费大量时间。把研发效能度量指标设置为KPI进行考核,只是激励员工针对研发效能度量指标本身进行优化,这通常比他们在研发效能度量之前所做的工作效率要更低。

片面地使用局部过程性指标。如果你不能研发效能度量一个事物的所有方面,就无法管理或者发展它。研发效能的提升不仅是有“效率”这一个方面,还有很关键的另外一个部分是“有效性”。

手工采集,人为加工和粉饰指标数据。一个研发效能度量系统的最基本的要求就是研发效能度量数据的公信力。只有在研发效能度量平台上自动采集、汇聚、计算出来的数据,才是可以被认可的,这些数据才可以被用来进行管理和技术决策。

不顾成本,堆砌大量非关键指标。研发效能度量不是免费的,为了做到准确、有效的研发效能度量,各种成本加在一起是很高的。我们可以根据当前企业的上下文,在不同领域选取少量的北极星指标来指导我们改进的方向,从目标出发驱动改进,从宏观下钻、定位到微观问题后再引入更多的过程性指标进行辅助分析。

货物崇拜,照搬业界对标的指标。要根据一个组织或团队的成熟度来选择指标,否则很可能适得其反,搞得工程师苦不堪言。

舍本逐末,为了研发效能度量而研发效能度量。官僚主义的一个问题是,一旦制定了一项政策,遵循该政策就成了官僚主义的目标,而不管该政策所支持的组织目标是什么。研发效能度量是为目标服务的,如果一种研发效能度量真的很重要,那是因为它必须对决策和行为产生一些可以想象的影响。

仅从管理角度出发,忽略了为工程师服务。我们不应该把员工当成一种”资源”,而是要作为”工程师”来看待。员工幸福感的下降不仅会影响代码编写过程的生产力,还会影响结果代码的质量。

希望大家能够在开启研发效能度量之旅之前,先辨别清楚方向,避免一开始就陷入到沼泽泥潭之中。

02. 系统性建设研发效能度量体系

在企业研发效能度量体系建设的初始阶段,大家的关注点可能都聚焦在研发效能度量什么样的指标、如何采集和计算、如何展示报表等问题上,这只是在做一些单点能力的建设,但并没有形成体系。随着持续深入的推进,需要更加系统性地思考,对于研发效能度量体系也会有不同的理解。


图1:系统性建设研发效能度量体系

在上图,有以下几部分内容需要重点关注:        

●研发效能度量的用户场景

研发效能度量指标是统计出来用来给人来看的,我们首先要找准用户和场景,没有目的性的堆砌指标没有任何价值。比如,高层管理者一般关注组织级的效能评估结果,包括整体的研发投入产出、战略的资源分配和达成情况、业务满意度、各事业部北极星指标的横向对比、研发效能月报等,

但可能不会关注特别细节的指标数据。团队级管理者不仅会关注团队交付效率、交付质量、交付能力等全方位的效能指标,并且希望研发效能度量平台具备问题自动化诊断和分析能力,能够结合趋势、下钻、关联分析等多种手段帮助识别效能瓶颈。工程师也会关注一些效能指标,用于对个人工作进行需求、任务、代码、缺陷等维度的统计和反馈。

●研发效能度量的指标体系

我们在之前的章节中讲到了很多研发效能度量指标,但只有指标的定义是不够的。我们还需要明确指标价值、指标说明、指标公式、指标采集方式、指标优先级、指标健康度等内容。研发效能度量的根本要求之一就是数据的准确性,那么研发效能度量指标的健康度就显得尤为重要了。另外,指标体系及其详细说明应当尽量公开透明,这样用户在得到指标研发效能度量结果的时候也可以更清晰理解其计算口径和与其他指标的逻辑关系。

●研发效能度量的模型设计

模型是对某个实际问题或客观事物、规律进行抽象后的一种形式化表达方式,一般包括目标、变量和关系。


图2:研发效能度量的模型设计

如上图所示,在研发效能度量领域,模型有很多种,比如研发组织的整体效能指数模型、需求价值流模型、工程师的代码贡献度效能模型、研发规范度模型、工具支持力模型等。研发效能度量的领域专家可以建立模型,并通过研发效能度量平台屏蔽其复杂性,提供给用户自助化分析使用。

●研发效能度量的产品建设

研发效能度量的过程实际上是要把数据转化为信息,然后将信息转化为知识,这样就可以让用户自主消费数据,进行分析和洞察。一个优秀的研发效能度量产品要做到自动化的数据采集,自动化的数据聚合,让用户可以自助化的查询和分析,甚至自定义报表,从而获得研发效能的有效洞察。

研发效能度量产品应该是可以被整个组织的团队和管理者访问到的,效能数据也应当被更加透明地使用,不宜设置过多的数据访问权限,人为地制造信息不对称。研发效能度量平台也应该被作为一个产品而不是项目来运作,包括研发效能度量什么、如何分析、如何对比实验都是需要持续演进的,而且作为一个产品我们要多听取用户的反馈,这与建设其他产品的过程都是一样的。

另外,研发效能度量产品一定要注重易用性,使用平台的用户往往不是这个方面的专家,应该避免使用复杂的公式定义和晦涩难懂的专业术语进行描述。

●研发效能度量的运作模式

成功的研发效能度量落地离不开组织的有力支撑,很多企业会采取虚拟的研发效能度量委员会来进行研发效能度量体系的设计和落地。在研发效能度量体系建设的初期,委员会的主要职责就是进行指标的定义和对齐,要考虑各种可能的场景和边界情况,让指标明确、有意义、无歧义。

随着研发效能度量体系的逐步落地发展,委员会成员也会迅速扩充,这些成员就成为了各个部门推进研发效能度量的种子选手。当然,在一线落地过程中免不了遇到各种问题,那么委员会就要进行整体规划的对齐和疑难问题的决策。

随着研发效能度量体系逐渐成熟,委员会可以把重心放到效能分析和效能提升的实践分享上来,形成研发效能度量指导手册、效能提升案例库和专项解决方案知识库,沉淀过程资产,让效能的研发效能度量、改进和提升成为日常工作的一部分。

03. 把研发效能度量引导到正确的方向上来

研发效能度量组织效能是企业中最敏感的领域之一,经常受到政治和各种职能障碍的影响。此外,由于研发效能度量不可避免地涉及到对研发效能度量数据的解释,也会受到认知偏差、沟通问题和组织目标对齐的影响。所以如果研发效能度量没有被引导到正确的方向上或没有被正确地实现,会导致重大的风险,即研发效能度量的结果可能弊大于利。

我们要避免把研发效能度量武器化。根据古德哈特定律,当某个研发效能度量变成了目标,它便不再是一个好的研发效能度量。所有的研发效能度量都可以被操纵,而数字游戏式的研发效能度量会分散员工的注意力并耗费大量时间。把研发效能度量指标设置为KPI进行考核,只是激励员工针对研发效能度量指标本身进行优化,这通常比他们在研发效能度量之前所做的工作效率要更低。研发效能度量不是武器,而是指导我们进行效能改进的工具。

我们也会碰到另一种情况,就是纯从数字来看,研发效能度量指标有了大幅提升,比如交付效率和吞吐量都在提高,但业务部门却仍不满意,他们的反馈是:”好像并没有什么变化!”那么这个时候,我们应该相信谁呢,是数据还是业务部门的声音?正如杰夫·贝佐斯(Jeff Bezos)的名言所说:“我注意到的是,当传闻和数据不一致时,传闻通常是正确的”。很可能是你研发效能度量的方法有问题,或是数据已经失真,这就需要进一步的检视和反思了。

丰田的大野耐一曾经说过:”那些不懂数字的人是糟糕的,而最最糟糕的是那些只盯着数字看的人”。每个数字背后都有一个故事,而这个故事往往包含比数字本身所能传达的更重要的信息。现场观察(Gemba)是一个可以与研发效能度量结合使用的强大工具,管理者要到实际的研发交付过程中去,观察需求和价值的流转过程,看一下团队是如何满足客户需求的。正式的研发效能度量和非正式的观察是相辅相成的,可以对结果进行相互印证。

04. 结语

在数字化时代,每一家公司都是信息技术公司,研发效能已经成为核心竞争力。通过正确的研发效能度量方法,坚持数据驱动和实验性的精神,可以让研发效能可量化、可分析、可提升。


——结束——

如果您想了解更多关于研发效能的内容,可查看思码逸网站获取;

思码逸Merico研发效能数据平台,致力于帮助研发团队解决研发效率、研发质量和人才发展三大痛点,提升研发效率与软件工程质量;

如果您想要与思码逸团队交流,欢迎在思码逸网站留下联系方式,我们将在24小时内回复。或拨打电话400-863-7426:


与先进研发团队并肩

“软件工程在工业生产中越来越重要。一方面,软件供应链快速演进,软件研发越来越复杂;另一方面,市场的快速变化对研发能力提出各种新的要求。而思码逸作为客观的研发效能平台,立足于对软件开发给出创新性的解释,并尝试将研发效能指标标准化。这对由管理者视角、业务视角、人员视角等更多维度更加全面地看待开发过程有很大帮助。”

Mars Sun

腾讯CODE平台产品负责人

“看清组织研发过程、合理有效地进行研发效能度量是牵引组织研发效能提升的关键。思码逸实现了深入代码语义的AST分析能力,引入代码当量将常规的基于代码行的相关研发效能度量方式提升到了一个新的高度,并通过代码层面的分析提供了研发人员的技术栈相关的标签数据,为组织研发选型提供有力的数据支撑,在行业内有很强的借鉴意义!”

杨永强

原滴滴出行代码团队技术负责人

“相信很多产品技术团队把研发效能提升列为重要的目标。然而,到底什么是好的研发效能,却很少有人能够表达清楚,而代码度量指标种类繁多且相对浅层。如何有效对程序员的工作合理量化测量,思码逸团队围绕每次代码提交对应的抽象语法树的变化进行有效评估,去除了代码中的一些干扰和噪音,为我们提供了新的思路和相对准确的一种测量基础。”

唐洪山

原京东科技研发效能部

“思码逸研发效能平台的专业性令人兴奋,非常适合中国快速发展的互联网软件企业使用。很好的帮助我们解决了团队和项目快速增加过程中遇到的研发效能度量、研发质量规范和人才组织发展的问题。后期的咨询和落地解决方案针对性强,问题分析和解决专业、高效。”

应阔浩

自如基础架构部总监

“在越来越多的企业把数字化转型作为核心战略落地主要抓手的大背景下,思码逸作为基于源代码并扩展至项目管理领域的研发效能平台分析工具,能够为企业数字化转型提供明显助力。和讯网在和思码逸合作共创的2年时间里,2020年主要集中于降本增效领域(提升下限),当年技术部的年度绩效位列全公司第一;2021年主要集中于价值达成领域(提升上限),当年技术部被公司评为年度优秀团队。”

杨扬

和讯网CTO

“开发人员状态有起伏是很正常的。采用思码逸的研发效能度量工具,我们不仅能及时发现表现优秀的开发者并给予激励,也能快速发现工作有待改善的开发者,给他们提供精准的指导与帮助,推动整个团队共同进步。”

朱文雷

长亭科技CTO

“思码逸在代码度量层面给出了创新性的解释,给技术管理者带来全新的研发效能度量提升思路和指标抓手工具,看清团队研发效能的短板,知道该往什么地方提升和改进。结合历史数据、行业数据的比对,让管理者、开发者可以看到努力的成果,并且用数据说话,研发团队日益精进。”

周彦斌

云货优选 研发部门负责人

“研发成果的度量可以说是一个世界性难题,开发者的工作之间内容不同、起点不同、用户不同、代码质量不同,既难以简单量化,也难以横向比较。思码逸作出了一个非常有意义的尝试,它一方面找到了有效的研发效能度量方法,另一方面打通了企业边界来开展数据比较,为研发数字化变革提供了一个非常有意义的新角度。”

谢超平

索贝数码副总裁/总工程师

在数字化的浪潮里,研发效能的高低是企业的核心竞争力。我们面对的产品研发都是脑力工作者,研发效能的度量也变的更复杂和有挑战性。思码逸的深度分析系统,用代码当量来更科学的评估开发的工作量,有效避免人为对代码量的干扰。通过MARI模型产出分析报告,帮助我们在公司内研发效能的推进和落地提供新的思路和方法。

谢超平

王蕾 贝壳工程效率负责人

长期以来,我们一直努力在复杂的市场环境中保持和不断提升研发效率及质量。思码逸为我们提供了重要的量化工具,较传统量化方式更客观和实用。目前思码逸的量化结果已经成为我们评价和提高研发效能的重要组成部分。

谢超平

妙盈科技联合创始人&CTO 刘涛

我们的客户

打开研发管理黑盒,数据驱动研发效能
立即试用
立即预约
在线客服
扫码添加咨询微信
售前电话
在线客服
免费试用
扫码添加咨询微信
长按二维码下载

取消