【AICon】探索RAG 技术在实际应用中遇到的挑战及应对策略!AICon精华内容已上线73%>>> 了解详情
写点什么

有度量才有真管理 研发效能的度量体系建设实践 | 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:393530

评论

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

端云一体开发,助力鸿蒙应用开发效率全面提升

最新动态

高管对上新老板的 Twitter

HoneyMoose

面试处处碰壁?不慌,Java核心面试文档.PDF助你披荆斩棘

钟奕礼

Java java面试 java编程 程序员‘

即时通讯赛道开打信创牌,WorkPlus为何独树一帜?

WorkPlus

东莞理工学院-网安学院举办第二届“火焰杯”软件测试高校就业选拔赛颁奖典礼

测试人

软件测试 自动化测试 测试发开 测试比赛

单体分层应用架构剖析

京东科技开发者

架构 模块 应用架构 服务层 业务层

EMQ宣布推出LF Edge eKuiper全新Logo标识

EMQ映云科技

物联网 IoT emq 11月月更 eKuiper

PGL图学习之项目实践(UniMP算法实现论文节点分类、新冠疫苗项目实战,助力疫情)[系列九]

汀丶人工智能

图神经网络 图学习 11月月更 论文节点分类任务 新冠疫苗任务

“鸿蒙开发套件”焕新升级 端到端赋能助力开发运维事半功倍

最新动态

A/B测试有哪些常见应用场景?——火山引擎DataTester科普

字节跳动数据平台

大数据 AB testing实战

华为开发者联盟学堂上线超1800门课程,为开发者提供一站式赋能

最新动态

集群部署看过来,低代码@AWS智能集群的架构与搭建方案

葡萄城技术团队

负载均衡 部署 集群 亚马逊

目前看过最全的一线大厂面试题(题+详解),你所不知道的都在这

钟奕礼

Java java程序员 java面试 java编程

太全了!神仙级SpringCloud Alibaba笔记,从入门到实战,全方位讲解微服务技术栈!

程序知音

Java 微服务 Spring Cloud 后端技术

Nacos 中的配置文件如何实现加密传输

江南一点雨

nacos SpringCloud

《鸿蒙生态应用开发白皮书》正式发布,携手更多开发者迈入鸿蒙世界

最新动态

四项发明专利布局国际市场 申威睿思层级化数据库操作加速系统和方法获肯定

科技热闻

Spring6正式发布!重磅更新,是否可以拯救Java

宋小生

【实用工具】解决PCB设计难题,痛击风险漏洞!

华秋PCB

工具 PCB PCB设计

阿里资深架构师谈Java进阶攻略:7大技能+12份进阶笔记+面试150题

钟奕礼

Java 程序员 java面试 java编程

即时通讯技术文集(第7期):长连接网关、P2P等 [共10篇]

JackJiang

网络编程 IM 即时通讯IM

金九银十已过,总结了阿里面试官常问九大项面试题!

钟奕礼

Java java面试 java编程 程序员‘

东莞理工学院-网安学院举办第二届“火焰杯”软件测试高校就业选拔赛颁奖典礼

测吧(北京)科技有限公司

软件测试

【Java经典面试800题】面试必备,查漏补缺;多线程+spring+JVM调优+分布式+redis+算法

程序知音

Java java面试 java架构 后端技术 Java面试八股文

观察者模式在spring中的应用

京东科技开发者

Java spring 编程 观察者模式

JVM 核心知识体系

钟奕礼

Java java面试 java编程 程序员‘

DHorse系列文章之操作手册

tiandizhiguai

微服务 云原生 k8s管理 微服务治理 Serverless Kubernetes

瓴羊DAAS体系结构,助力乔丹体育高质量增长

瓴羊企业智能服务

一次MTU问题导致的RDS访问故障

京东科技开发者

数据库 Linux MTU RDS vpn

咱也不知道这份牛P哄哄的【Nginx实战】资料是不是你们想要的

钟奕礼

Java 程序员 java面试 java编程

《鸿蒙生态应用开发白皮书》正式发布,携手更多开发者迈入鸿蒙世界

最新动态

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