本文主要内容:
1、研发效能度量的误区和反模式
2、怎么样系统性建设研发效能度量体系
3、研发效能度量的正确方向怎么引导
作者简介
张乐,腾讯技术工程事业群 DevOps与研发效能资深技术专家,多年一线互联网大厂工程效率领域工作经历(百度、京东等)历任埃森哲、惠普等全球五百强企业资深咨询顾问、技术专家长期工作在一线,专注于研发效能提升、敏捷与DevOps实践落地、万人研发规模 DevOps 平台设计、研发效能度量体系建设等方向;
本文来源:张乐老师的研发效能系列文章,本文全篇收录于QECon组委会发布的白皮书之《研发效能实践指南》
研发效能度量的误区和反模式
正所谓“成功大都相似,失败各有不同"。研发效能度量其实也不算是个新鲜的话题了,随着业界各大公司日益发展壮大,很多都已经拥有几百、几千甚至上万人的研发队伍,研发效能的基础数据都积累了很多。
但我们经常看到一些所谓的“反模式”在不断上演,虽然从公司角度花了很大的力气去做研发效能度量,但从其理念、出发点到具体实践、指标选择、推广运营上似乎都存在一些问题、限制和弊端,以至于获得的成效不大甚至是造成负面影响,最终连累公司整体业绩。
研发效能度量的常见反模式如下:
●使用简单的、易于获取的指标。正如比尔·盖茨曾经说:“用代码行数来衡量软件的生产力,就像用飞机的重量来衡量飞机的生产进度一样。”
●过度关注资源效率类指标。我们不要过度关注资源效率类指标,还需要考虑流动效率类指标。
●使用成熟度评级等基于活动的研发效能度量。狭隘的、以活动为导向的研发效能度量很可能失败。研发效能应该研发效能度量结果而不仅是过程,端到端价值流的局部优化对结果的改进效果很小,因为可能根本就没有解决效能瓶颈。
●把研发效能度量指标设置为KPI进行绩效考核。所有的研发效能度量都可以被操纵,而数字游戏式的研发效能度量会分散员工的注意力并耗费大量时间。把研发效能度量指标设置为KPI进行考核,只是激励员工针对研发效能度量指标本身进行优化,这通常比他们在研发效能度量之前所做的工作效率要更低。
●片面地使用局部过程性指标。如果你不能研发效能度量一个事物的所有方面,就无法管理或者发展它。研发效能的提升不仅是有“效率”这一个方面,还有很关键的另外一个部分是“有效性”。
●手工采集,人为加工和粉饰指标数据。一个研发效能度量系统的最基本的要求就是研发效能度量数据的公信力。只有在研发效能度量平台上自动采集、汇聚、计算出来的数据,才是可以被认可的,这些数据才可以被用来进行管理和技术决策。
●不顾成本,堆砌大量非关键指标。研发效能度量不是免费的,为了做到准确、有效的研发效能度量,各种成本加在一起是很高的。我们可以根据当前企业的上下文,在不同领域选取少量的北极星指标来指导我们改进的方向,从目标出发驱动改进,从宏观下钻、定位到微观问题后再引入更多的过程性指标进行辅助分析。
●货物崇拜,照搬业界对标的指标。要根据一个组织或团队的成熟度来选择指标,否则很可能适得其反,搞得工程师苦不堪言。
●舍本逐末,为了研发效能度量而研发效能度量。官僚主义的一个问题是,一旦制定了一项政策,遵循该政策就成了官僚主义的目标,而不管该政策所支持的组织目标是什么。研发效能度量是为目标服务的,如果一种研发效能度量真的很重要,那是因为它必须对决策和行为产生一些可以想象的影响。
●仅从管理角度出发,忽略了为工程师服务。我们不应该把员工当成一种”资源”,而是要作为”工程师”来看待。员工幸福感的下降不仅会影响代码编写过程的生产力,还会影响结果代码的质量。
希望大家能够在开启研发效能度量之旅之前,先辨别清楚方向,避免一开始就陷入到沼泽泥潭之中。
系统性建设研发效能度量体系
在企业研发效能度量体系建设的初始阶段,大家的关注点可能都聚焦在研发效能度量什么样的指标、如何采集和计算、如何展示报表等问题上,这只是在做一些单点能力的建设,但并没有形成体系。随着持续深入的推进,需要更加系统性地思考,对于研发效能度量体系也会有不同的理解。
图1:系统性建设研发效能度量体系
在上图,有以下几部分内容需要重点关注:
●研发效能度量的用户场景
研发效能度量指标是统计出来用来给人来看的,我们首先要找准用户和场景,没有目的性的堆砌指标没有任何价值。比如,高层管理者一般关注组织级的效能评估结果,包括整体的研发投入产出、战略的资源分配和达成情况、业务满意度、各事业部北极星指标的横向对比、研发效能月报等,
但可能不会关注特别细节的指标数据。团队级管理者不仅会关注团队交付效率、交付质量、交付能力等全方位的效能指标,并且希望研发效能度量平台具备问题自动化诊断和分析能力,能够结合趋势、下钻、关联分析等多种手段帮助识别效能瓶颈。工程师也会关注一些效能指标,用于对个人工作进行需求、任务、代码、缺陷等维度的统计和反馈。
●研发效能度量的指标体系
我们在之前的章节中讲到了很多研发效能度量指标,但只有指标的定义是不够的。我们还需要明确指标价值、指标说明、指标公式、指标采集方式、指标优先级、指标健康度等内容。研发效能度量的根本要求之一就是数据的准确性,那么研发效能度量指标的健康度就显得尤为重要了。另外,指标体系及其详细说明应当尽量公开透明,这样用户在得到指标研发效能度量结果的时候也可以更清晰理解其计算口径和与其他指标的逻辑关系。
●研发效能度量的模型设计
模型是对某个实际问题或客观事物、规律进行抽象后的一种形式化表达方式,一般包括目标、变量和关系。
图2:研发效能度量的模型设计
如上图所示,在研发效能度量领域,模型有很多种,比如研发组织的整体效能指数模型、需求价值流模型、工程师的代码贡献度效能模型、研发规范度模型、工具支持力模型等。研发效能度量的领域专家可以建立模型,并通过研发效能度量平台屏蔽其复杂性,提供给用户自助化分析使用。
●研发效能度量的产品建设
研发效能度量的过程实际上是要把数据转化为信息,然后将信息转化为知识,这样就可以让用户自主消费数据,进行分析和洞察。一个优秀的研发效能度量产品要做到自动化的数据采集,自动化的数据聚合,让用户可以自助化的查询和分析,甚至自定义报表,从而获得研发效能的有效洞察。
研发效能度量产品应该是可以被整个组织的团队和管理者访问到的,效能数据也应当被更加透明地使用,不宜设置过多的数据访问权限,人为地制造信息不对称。研发效能度量平台也应该被作为一个产品而不是项目来运作,包括研发效能度量什么、如何分析、如何对比实验都是需要持续演进的,而且作为一个产品我们要多听取用户的反馈,这与建设其他产品的过程都是一样的。
另外,研发效能度量产品一定要注重易用性,使用平台的用户往往不是这个方面的专家,应该避免使用复杂的公式定义和晦涩难懂的专业术语进行描述。
●研发效能度量的运作模式
成功的研发效能度量落地离不开组织的有力支撑,很多企业会采取虚拟的研发效能度量委员会来进行研发效能度量体系的设计和落地。在研发效能度量体系建设的初期,委员会的主要职责就是进行指标的定义和对齐,要考虑各种可能的场景和边界情况,让指标明确、有意义、无歧义。
随着研发效能度量体系的逐步落地发展,委员会成员也会迅速扩充,这些成员就成为了各个部门推进研发效能度量的种子选手。当然,在一线落地过程中免不了遇到各种问题,那么委员会就要进行整体规划的对齐和疑难问题的决策。
随着研发效能度量体系逐渐成熟,委员会可以把重心放到效能分析和效能提升的实践分享上来,形成研发效能度量指导手册、效能提升案例库和专项解决方案知识库,沉淀过程资产,让效能的研发效能度量、改进和提升成为日常工作的一部分。
把研发效能度量引导到正确的方向上来
研发效能度量组织效能是企业中最敏感的领域之一,经常受到政治和各种职能障碍的影响。此外,由于研发效能度量不可避免地涉及到对研发效能度量数据的解释,也会受到认知偏差、沟通问题和组织目标对齐的影响。所以如果研发效能度量没有被引导到正确的方向上或没有被正确地实现,会导致重大的风险,即研发效能度量的结果可能弊大于利。
我们要避免把研发效能度量武器化。根据古德哈特定律,当某个研发效能度量变成了目标,它便不再是一个好的研发效能度量。所有的研发效能度量都可以被操纵,而数字游戏式的研发效能度量会分散员工的注意力并耗费大量时间。把研发效能度量指标设置为KPI进行考核,只是激励员工针对研发效能度量指标本身进行优化,这通常比他们在研发效能度量之前所做的工作效率要更低。研发效能度量不是武器,而是指导我们进行效能改进的工具。
我们也会碰到另一种情况,就是纯从数字来看,研发效能度量指标有了大幅提升,比如交付效率和吞吐量都在提高,但业务部门却仍不满意,他们的反馈是:”好像并没有什么变化!”那么这个时候,我们应该相信谁呢,是数据还是业务部门的声音?正如杰夫·贝佐斯(Jeff Bezos)的名言所说:“我注意到的是,当传闻和数据不一致时,传闻通常是正确的”。很可能是你研发效能度量的方法有问题,或是数据已经失真,这就需要进一步的检视和反思了。
丰田的大野耐一曾经说过:”那些不懂数字的人是糟糕的,而最最糟糕的是那些只盯着数字看的人”。每个数字背后都有一个故事,而这个故事往往包含比数字本身所能传达的更重要的信息。现场观察(Gemba)是一个可以与研发效能度量结合使用的强大工具,管理者要到实际的研发交付过程中去,观察需求和价值的流转过程,看一下团队是如何满足客户需求的。正式的研发效能度量和非正式的观察是相辅相成的,可以对结果进行相互印证。
结语
在数字化时代,每一家公司都是信息技术公司,研发效能已经成为核心竞争力。通过正确的研发效能度量方法,坚持数据驱动和实验性的精神,可以让研发效能可量化、可分析、可提升。