速来报名!AICon北京站鸿蒙专场~ 了解详情
写点什么

有度量才有真管理 研发效能的度量体系建设实践 | GTLC 南京

陈东

  • 2022-07-25
  • 本文字数:4837 字

    阅读完需:约 16 分钟

有度量才有真管理 研发效能的度量体系建设实践 | GTLC 南京

2022 年 7 月 16 日,由 TGO 鲲鹏会主办的 GTLC 全球技术领导力峰会·南京站成功召开,吸引全球 200 余位 CTO、技术 VP、CEO 等科技领导者参与。会上,数禾科技 CTO、TGO 鲲鹏会(上海)学员陈东,为与会嘉宾带来《研发效能的度量体系建设实践》的主题分享。我们将演讲内容整理如下,以飨读者。


近两年,互联网行业的增速明显下降,无论公司规模大小都有一个共同的诉求,就是如何降低研发团队的成本并增加效能。


今天我会围绕《研发效能的度量体系建设实践》这一话题,将自己带领不同规模研发团队所积累、沉淀下来的思考和实践,从度量体系对于研发效能的意义、度量体系的建立原则、度量体系的架构设计与案例、度量体系的系统运营,共四方面为大家进行分享。

度量体系对于研发效能的意义


提高研发效能的方法非常多,比如引入先进工具、优化工作流程和调整组织结构等。不过无论用什么方法,最终都要回答一个问题:研发效能提升了吗?提升了多少?如果回答不出这个问题,前面许多的工作是无法证明它的价值。因此,研发效能的度量很重要。


管理大师彼得·德鲁克讲过,“没有度量就没有管理。”管理者的一项重要职责,就是思考如何做好度量,以及基于度量做决策。


然而度量并不好做,为什么?因为没有理解度量体系建设的本质——研发管理思维的数字化转型。很多研发团队的管理者主要凭借主观感觉来对团队成员进行度量,对研发团队的能力,缺乏量化、数字化的判断标准。大多研发团队都是在帮公司做各种业务的数字化转型,但其自身工作方式却是“拍脑袋”决策,从这个角度来讲,不做度量体系管理的研发团队,就是公司数字化转型的最后一块短板。


度量体系的建立原则


度量体系建设的目的是在帮助公司进行数字化转型的同时,实现研发团队的数字化转型;研发团队不能只知道埋头苦干,还要学会“抬头看天”——团队开工前定下度量体系的原则指引,以免团队之后的工作变形。


原则一,以客户价值为导向,不追求完美,但要能体现当前痛点。从客户和产品的角度思考,明确客户是谁,他们关注的痛点是什么,以及度量体系是否反映出客户当前的痛点。在开始实践时,不要追求建立完美的度量体系,因为所花费的人力成本很高;建立一个符合公司现状、满足业务痛点的度量体系更为可行。



原则二,以团队主要工作流程为线索,建立研发流程的度量。度量体系指标选取选取逻辑是以团队的主流程为线索,从主流程选指标来搭建研发效能的度量体系。除主流体系的之外的其他指标都不是重点指标。



原则三,度量体系需要有层次,不同的人关注不同的指标。整个度量体系指标需要有层次,不是简单的指标罗列,因为不同的人关注不同的指标,所以要对指标进行分层。



原则四,度量体系需要不断迭代。这与原则一相关,度量体系的指标要反映客户的痛点,若痛点解决了,这个指标就没有必要考核了。接下来,还需要去思考当前的痛点是什么,指标权重和考核方式是否要做修改,整个指标体系处于不断地迭代状态。


度量体系的架构设计与案例


有了上述四点原则做支撑,如何进行下一步实施呢?具体分三点:第一,度量体系的指标选取;第二,度量体系的分层架构;第三,度量指标的几个讨论案例。


度量指标的选取维度。比如,如何判断一个团队好不好呢?答案是“多快好省”,这四个字基本上可以覆盖大部分对研发团队研发效能的要求。进一步来看,“多”对应“产能”,“快”对应“响应力”,“好”对应“质量”,“省”对应“成本”,因此产能、响应力、质量、成本就是对研发团队进行度量的四个维度。



但是四个思维没有必要全做,可以排优先级的。根据第一个原则:要以客户的价值为导向。研发团队的客户是谁?是业务团队 。业务团队关心研发团队的“响应力”、“质量”和“产能”,对这三个维度再排优先级,则是质量第一,响应力第二,产能第三。


为什么质量是第一?可以反过来思考,如果质量不好,响应力越快,产能就越高,线上的 Bug 就越多。当 Bug 增多时,线上系统就会呈现崩溃的状态。这说明,没有质量保障的产能是无效的;而从另一个角度来看,若产品质量做得好,会间接促进响应力和产能的增长,因为工程师从线上紧急问题响应环节节省的时间,可以投入至原来规划的研发工作,更好保证了响应力和产能的提升。


但是只选质量这个维度是不够的,因为它太片面了,也不是客户唯一需要的。研发团队要将质量和响应力两个维度同时做起来并做得足够好,才能最小化的满足客户痛点。


如何具体设计指标。设计指标需要分层的思考,因为不同的人关心不同的指标。比如对外进行交付,业务团队关心的指标比较简单,我们列出了两个大类、四个指标。在响应力维度,关注需求的按时完成率和需求交付时长;在质量维度,关注故障的数量和故障时长。对外交付的研发项目指标不需要太复杂,掌握四个核心指标就可以。


真正复杂的是对内面向过程管理的指标设计,如何拆解上述四个指标、指标落地路径如何实现,才是研发效能度量体系建设最重要的环节。因为上述四个指标不是可以轻松达成的,并且四个指标中至少有存在两个明显问题。


问题一,在需求交付时长上存在度量是否精准的问题。需求从提出到上线之间经历的环节众多,有非常多的角色和岗位都在参与,甚至有来回拉锯的情况,因此如何定义需求的交付时长存在问题;此外,不同需求的颗粒度也是不同的,有的需求可能要花一个月交付,有的需求花一天就可以,因此需求的力度如何度量准确也存在问题。



问题二,在故障数量上存在指标稀疏和指标滞后的问题。根据经验,每一个研发部门,每季度的故障数一般是 0 到 1,表现差一点会到 2;如果一个部门的故障数量按季度统计的话,可能就是 0、1、0、1,这样的数据是没有统计意义的;还有,如果一个季度中的前 2 个月一直没出事故,但这时就能保证质量真的好吗?不一定。如果只是简单看“零事故”这个指标,而不做任何的管理动作,是存在隐患的。当事故真正发生时,再做任何的事情这个指标也已经改不回来了。滞后性的指标,没有办法进行日常的优化。因此,如果做不好内部的管理拆解,就很难向业务团队保障最终的响应力和质量的交付。


对内的度量体系指标的设计方面,可以先将需求、设计、开发、测试、发布、运维主流程拉出来,在主流程中看每个环节的响应力和质量,这是选取指标的核心的逻辑,像是考勤、满意度考评这些指标都不需在考察范围内。


研发流程支撑指标众多,也不一定都有效。首先,从需求角度来看。理想的度量区间,是从业务开始提需求到最终发布。但是现实往往只能度量和管理设计和开发这两个环节。前面的需求环节,因为有大量的与业务团队来回拉锯讨论的时间,所以只能观测不能考核。后面测试的环节需要在测试环境里去进行验收,只要没有验收通过,是不会往下发布的。所以,为了让整个的研发效能的流程和度量的区间变得更加合理,我们做了以下改变。


第一,提供了一个预发环境,将业务验收环节从测试环境中剥离。测试环境完全回归到研发团队里,把可控的度量空间延长,从设计、开发、测试延长到了预发部。对于头尾两部分,业务的验收和前面需求的沟通是作为观测指标进行观察,虽不考核研发团队但会进行分析,以及与业务团队沟通,使整体效能有更大的提升;第二,对于“需求颗粒度”不一致的问题。我们把需求拆解成不同的 Story,通过考核 Story 的交付时长,相对统一了考核口径,使得交付时长的统计数据也变得有意义。


接下来是工程师开发。工程师开发中有一个经典指标叫“缺陷密度”,公式为:加权的缺陷数 / 代码行数 = 工程师的缺陷密度,意思是代码写得越多,缺陷数可能会越多。但是如果按这个指标的设定,会存在有效的代码行数定义不清楚,以及工程师没有动力优化代码,对团队带来负面导向。


业界还有一个更成熟的理论,即不考量代码行数,转而考量“功能点数”,公式为:加权的缺陷数 / 功能点数 = 工程师的缺陷密度。但是这个考量方式需要人工预估功能点数,若没有专业的人员去做功能预估,是会耗团队工作量,在实际操作中不一定对所有的公司都适合。


因此我们最终采用的是第三个方案,我们用“工作量”来代替,公式为:加权的缺陷数 / 工作量 = 工程师的缺陷密度,工作量指工程师登记的工作时长。其优点在于它相对比较简单,工程师可以自主提交工作时长。当然也可能存在填写时长过长的问题,不过这一弊端有制衡的因素,如果把工作量填得很大,那响应和交付时长就会变长,从而影响产能,这一制衡因素可以避免做假和偏移的情况出现。



下一个环节是测试。测试有一个经典指标,叫缺陷逃逸率。公式为:缺陷逃逸率 = 生产缺陷数 / (测试缺陷数 + 生产缺陷数)),但是这个公式会把刚才提到的预发环境和放 10-20% 的流量的灰度环境跳过了,只能看到生产环境的缺陷。而前两个环节,发现问题概率是最大的。


因此我们重新定义了一个发布缺陷数的概念:发布缺陷数 = 验收缺陷数 + 灰度缺陷数 + 生产缺陷数,只有把所有客户感知到的环节记录下来作为分母,才能更好的反映我们的客户价值。因此缺陷逃逸率公式变成,缺陷逃逸率 = 发布缺陷数 /(测试缺陷数 + 发布缺陷数)。



最后,故障数量的改进。对于内部团队而言,考核的是事件处理,而不是事故本身。团队每周都会接到告警、业务反馈的线上问题,这些告警和线上问题不一定是事故,但的确是反映了当前系统的问题。对于每周都会发生的事情,我们会进行相关的响应力和质量进行考核,每周也都会对上一周的事件进行复盘,把对事故的管理转变成对事件的管理。



总结一下,度量指标需要客观反映现状,避免主观打分;度量指标尽可能在前后环节、响应力和质量之间有制衡;度量指标需要尽可能覆盖全流程,避免只关注拒不缓解;度量指标需要可频繁观测,指导日常工作。


再次强调一下度量的重要性。提升研发效能方法非常多,比如培养团队的研发能力、流程优化等,这些事情都可以做,但是很漫长。最简单、快速、有效的方法,就是把度量指标定义和调整好。只要大家能看得到正确的度量指标,团队自然有动力和方向去优化自己的研发效能。

度量体系的系统运营


上述所讲都是度量体系如何建立,它只是一个模型,真正运行还需要系统支持,所以要做系统化、做自动化、做可视化。


我们打造的这套系统,拥有底层的基础系统层、中间的逻辑层以及最上面的展示层,通过这套系统,可以更便捷地使用和管理数据。



这套系统能够实现一定程度的自动化数据采集、数据分析以及自动化运营。如果没有做好数据自动化采集,整个体系是建立不起来的。必须基于底层研发工具,自动抓取工程师在这个上面工作的时间和状态,实现自动化采集数据。对于自动化运营的思路是,当指标发生偏离的时,主动去告警和推送。


在整个体系的日常运营管理上。要明确责任主体,即谁为研发效能指标负责。我们定义的主体是研发部门,让部门承担这个指标,不考核个人。如果考核个人,个人就有可能对这些指标动手脚,因为所有的数据都是由工程师在工作中产生的,如果知道这个指标会直接考核到他的绩效,就会基于数据本身做优化,而不是基于事件优化,所以我们不考核个人。


另外,日常运营中要周期性跟进。每周把数据贴出来让大家看,然后进行考评,自然而然整个团队就会投入更多关注,会做得越来越好。


最后,指标是要迭代的,只有不停的更新迭代,才能不断的进步。如果不去迭代、更新这些指标,最后很可能是每个季度的考核都是一百分,失去了度量地意义。所以,度量指标一定要调整,并聚焦在做得不好的地方。



最后我想用一句话来结束今天的演讲:度量是为了改进。要以客户价值为导向,体现当前痛点,才能找到正确的前进方向。感谢大家的聆听!

关于 TGO 鲲鹏会


TGO 鲲鹏会是极客邦旗下科技领导者聚集和交流的组织,学员由 CTO、架构师、技术 VP、具有技术背景的 CEO 等组成,目前已经在北京、上海、深圳、广州、杭州、成都、硅谷、南京、台北、厦门、武汉、苏州等 12 个城市定期举办学习活动。


TGO 鲲鹏会采用了“学员共建”的组织形式,希望通过“共建、自治”的方式维护各城市的健康发展,为学员提供必要的服务,帮助学员个人更好地学习和成长,助力学员企业之间更好地合作与交流。加入 TGO 鲲鹏会,全方位提升自身价值,成为卓越科技领导者!



2022-07-25 10:394887

评论

发布
暂无评论
发现更多内容

云小课|MRS基础原理之ClickHouse组件介绍

华为云开发者联盟

mapreduce 开源 Clickhouse EI企业智能 列式数据库

图解:为什么非公平锁的性能更高?

Java 程序员 面试 后端 计算机

AI 场景的存储优化之路(二)

焱融科技

人工智能 云计算 AI 高性能 分布式存储

引领异构时代,英特尔发布重大架构创新

科技新消息

MySQL 系列教程之(九)MySQL 必修:事务

若尘

MySQL 数据库 8月日更

全链路压测实践

超凡生

多种云资源管理用什么软件好?你知道吗?

行云管家

云计算 云服务 云资源

阿里P8耗时一个月肝出这份26W字Java面试手册,在Github标星30K+

Java~~~

Java spring 架构 面试 JVM

神策分析 iOS SDK 代码埋点解析

神策技术社区

程序员 数据采集 埋点

Docker

彭阿三

gopher成长之路(三):出差小记

非晓为骁

个人成长 蜕变

GitHub再现神作,阿里大牛面试30家大厂,整合出这份Java面试手册

Java~~~

Java 架构 面试 JVM 架构师

JVM调优(一)

彭阿三

币安智能链智能合约DAPP开发|智能合约DAPP源码搭建

量化系统19942438797

dapp 币安智能链

阿里大牛耗时三年整理出来的4588页Java面试诛仙手册,已全面开源

Java~~~

Java 架构 面试 JVM 架构师

ToB迎来上市潮,谁是下一个IPO黑马?

ToB行业头条

IPO

深度解读鸿蒙轻内核CPU占用率

华为云开发者联盟

鸿蒙 cpu 任务 CPUP LiteO

上线半天下载量破100W!美团内部微服务进阶笔记,超详细

Java 架构 面试 微服务 美团

Github高分爆赞,一天遭狂转 10w+ 次!20万字的Java面试手册来了

Java~~~

Java 架构 面试 JVM 架构师

全靠这份阿里大佬的“Java进阶面试手册”收获蚂蚁offer

Java~~~

Java 架构 面试 算法 JVM

Flutter 与 Swift - 在创建 iOS 应用程序时应该押注什么技术?

iOSer

flutter swift ios开发

安装ApiPost-接口工具 发送HTTP请求

CodeNongXiaoW

大前端 测试 后端 接口测试 接口管理工具

谷歌高级架构师十年心血终成Kubernetes微服务实战文档

公众号_愿天堂没有BUG

Java 编程 程序员 架构 面试

人类高质量 Java 学习路线【一条龙版】

程序员鱼皮

Java 数据库 后端 求职 编程学习

币安智能链智能合约DAPP开发

Geek_23f0c3

智能合约 DAPP智能合约交易系统开发 DAPP系统开发 币安智能链

结合scipy.linalg在Python中使用线性系统

华为云开发者联盟

Python 矩阵 Numpy 线性系统 向量

【ShardingSphere技术专题】「ShardingJDBC」SpringBoot之整合ShardingJDBC实现分库分表(JavaConfig方式)

洛神灬殇

ShardingJDBC ShardingSphere ShardingSphere-Proxy 8月日更

imtoken钱包搭建,区块链去中心化钱包搭建

学完阿里P8推荐的实时流计算系统设计与实现PDF,终入淘宝

公众号_愿天堂没有BUG

Java 编程 程序员 架构 面试

终于读完谷歌高级架构师分享的Kubernetes源码剖析文档

公众号_愿天堂没有BUG

Java 编程 程序员 架构 面试

聊聊 Kafka: 在 Linux 环境上搭建 Kafka

编程susu

Java IT 计算机 编程开发 技术宅

有度量才有真管理 研发效能的度量体系建设实践 | GTLC 南京_技术管理_InfoQ精选文章