研发数字化的四个层次和效能度量的五项精进

我们很荣幸邀请到腾讯技术工程事业群的资深 DevOps 与研发效能技术专家张乐老师参与 DevData Talks 直播活动。活动中张乐老师做了《研发数字化的四个层次和效能度量的五项精进》主题分享。

研发数字化的四个层次和效能度量的五项精进

本文共计3200字,建议阅读时间:10~11分钟。

阅读本文你将收获:

1、研发效能度量的不同关注点

2、研发数字化的四个层次

3、《软件研发效能度量规范》的先进性体现在哪些方面

前言:我们很荣幸邀请到腾讯技术工程事业群的资深 DevOps 与研发效能技术专家张乐老师参与 DevData Talks 直播活动。活动中张乐老师做了《研发数字化的四个层次和效能度量的五项精进》主题分享。

以下是干货内容整理:

01 研发效能度量的不同关注点

近两年研发效能度量的话题特别火,但同时也出现一个关键问题:看似大家都在讨论研发效能,实际上不同身份可能讨论的是研发效能不同层次,对效能有着不同的诉求。

从中高层管理者的视角,可能主要希望站在全局视角下清晰定义研发效能,有一个简洁、易理解、数字化的方法来反映效能整体情况,说明全局性的问题和可提升方向。面对这类管理者,研发效能的作用是把复杂问题抽象化,也许是精炼成几个指数,来辅助整体决策。

这么宏观的视角,对于基层管理者来说可能就太虚了。基层管理者期待的是研发过程全盘数字化,能够看到细致的、覆盖各维度的效能数据,能够从宏观到微观逐层下钻,基于数据排查出根本问题,并能将数据作为抓手,指导改进行动。

一线工程师也需要研发效能数据吗?数据一方面可以成为工程师的镜子,用趣味性的方式提供客观量化参照;另一方面,在绩效评审的场景下,效能数据也能为开发者的优秀工作提供佐证。

理想情况是,同一套效能数据能够根据不同角色的不同需求,用不同展现逻辑来提供个性化价值。因此,大家在讨论研发效能度量前,需要先明确效能的服务对象是谁?需求是什么?在这一点上需要先取得共识。

02研发数字化的四个层次

如何理解数字化?数字化是从物理世界中,开采出数据,粗炼出信息,精炼出知识,聚合出智慧,最终提高生产率,因此可以把数字化拆解为四个层次。

第一层的数据是对物理世界的原始刻画,在软件研发的场景下,可能是代码提交日志、需求流转记录、代码本身等。并非所有数据都是有价值的。

经过识别筛选去芜存菁,留下的是第二层的信息。需求前置交付时间、代码提交习惯、代码重复度等度量指标,都落在这一层。

多种信息聚合加工之后,辅以分析判断,就成为第三层知识。比如交付需求的数量和时长、研发团队的负载、需求交付周期中等待的时间比例,多个指标聚合为交付价值流的分析,反映研发团队是否正在顺畅、高质量地交付价值,这对于就是很有价值的知识。

在多个知识积累的基础上,结合专业领域的专家经验,推荐解决方案,这是第四层的智慧,也是数字化希望最终达到的目标。

研发效能度量也应按照这四个层次,不停留在数据本身,而是逐层向上聚合提炼,加工成可落地的改进方案。

03研发效能度量的五项精进

去年写的《加班多、Bug少就是好程序员?别再被忽悠了》一文中,提出了“效能度量五项精进”这个实践框架。这里不再一一阐述,只做简单概括:

1. 自动化采集效能数据,减少人工投入,提高数据置信度

2. 建立度量指标体系,涵盖用于整体评估的结果指标和用于细节分析改进的过程指标、反映研发过程全过程的全局指标和反映单点情况的局部指标、用于事前干预的先导性指标和用于事后复盘的滞后性指标等多种类型,让各有侧重的不同指标协同发挥作用

3. 度量分析模型,对客观事物的规律进行抽象归纳,发现不同变量之间的关系,达到客观分析改进的目的

4. 度量产品建设,将复杂逻辑内化,对外展现简单清晰的效能数据,让用户可以自行消费数据,是研发效能规模化推进的基础

5.把度量引导到正确的轨道上,用数据驱动持续学习与改进,带着实验思维用一线真实故事核实结论

接下来我们会举些例子,深入讲讲指标体系、分析模型与数据驱动三方面。

研发效能度量指标体系

需求交付周期是相当常见的北极星指标。这一指标的价值在于它是端到端的全局性、结果性指标,反映了业务+产研团队对客户问题或业务机会的响应速度。要改善这一指标,需要整个组织各职能部门的协调一致,紧密协作,作为整体去交付价值。然而,对于这样重要的指标,我们也未必完全清晰其定义和使用方法。这些模糊的部分会导致指标失真乃至失效。

首先,需求前置时间中的『需求』是什么?如果不对颗粒度做一定限制,花了三个月时间的业务需求和花了一小时的页面配置需求,必然是没有可比性的。我们将需求定义为『最小业务需求』,其特征是以业务为出发点,可上线运行,且完成了用户体验闭环。这些限定条件会让指标更加具象,也更加可用。

其次,这个指标应该怎么看?如果简单取平均完事,不理解统计背后的逻辑,可能又会掉入陷阱 —— 研究显示,需求前置时间这一指标并不呈正态分布,而是呈韦伯分布,因此85分位数这样的指标更能反映出真实、普遍的交付效率。另外,指标的趋势比绝对值更有参考价值。

再次,指标看过了,该怎么改善?找老板要求加人可能是加快交付的一个路径,但关键是要加在刀刃上。基于数据的下钻分析,找到交付周期中的瓶颈,进行针对性改善。

最后,如何保障指标是有效的?这就要求持续监控指标的健康度,通过规范乃至自动化流程,保障指标能够反映研发的真实情况。

以上围绕一个单点指标讲了这么多,主要想陈述的是,搭建效能度量体系的确实不能人云亦云,需要研发团队投入时间和精力去钻研和思考指标背后的逻辑,避免度量成为实际无人使用的面子工程。

研发效能度量分析模型

我从2019年开始搭建需求价值流的模型,研究过程中逐渐发现,研发效能的每个细分领域都值得深入分析,并针对性地抽象为模型来解决特定问题。这个过程包含了定位关键问题和关键变量、找出变量间的逻辑关系、引导这些变量不断改善。建立这套完整的体系是效能度量更加深入的必经之路。

这里用需求价值流模型来举例。在上图中可以看到价值流的五个关键要素:需求交付周期、需求吞吐量(单位时间交付需求个数)、流分布(交付需求的类型分布情况)、流负载(同一时间的在制品数量)、流效率(有效工作时间占总时间的比例)。基于这五个要素,我们能够相对完整地展现需求价值流动的情况,并从中找到瓶颈,针对性地制定干预措施。

在使用模型过程中,则涉及到不同分析方法。例如宏观到微观逐层下钻分析:针对需求交付周期这个指标,可以先在时间维度上看趋势,判断是否需要干预;接下来可以按照阶段下钻,看看哪个环节耗时最长;进一步还可以按照组织层级继续下钻,从部门、团队、个人到单个需求粒度,逐步拆解找到问题。

例如关联性分析:尽管研发流程受到复杂的多因素影响,依然可以从历史数据中找到变化趋势的关联性,摸索实验,找到可用的抓手。举个例子,流负载可以作为交付周期的先导性指标,那么在实践中,我们会使用Aging Report这样的工具,分析在制品在哪个环节卡住,卡了多长时间,与过去三十天这一环节的平均停留时间的基线对比是否超过正常范围,这样基于关联性的实践能帮助我们提前感知问题,尽早解决瓶颈。

需求交付周期与相关性指标的因果回路图(理论)和相关性热力图(实际数据验证+针对性挖掘)

数据驱动的研发效能改进

之前写过一篇《研发效能度量的难点与反模式拆解》,这里简单展开阐述几点:

尽管硅谷的一些效能度量方法并不适合被直接套用到国内,但我很认同谷歌的GSM(目标/信号/指标)框架。首先,做研发效能度量,最重要不是指标,而是度量的目标。如果目标不明确,不理解为何做度量,度量定然是没有价值的;第二,度量后如果无法对结果做任何事情,那么度量也是不值得做的。效能度量需要以可感知的改善为终点,再去设计抵达终点的路径,牵引指标设计。

另外,毕竟研发团队中都是知识工作者,效能度量也不能仅仅服务于老板。我们需要多关注工程师的感受,了解工程师对工作环境、工作模式、工作负载、研发基础设施、项目协作、团队发展、个人提升等是否感到满意,是否有阻碍工程师发挥更大创造性和产生更大生产力的因素存在。

需要再次强调的一点是,尽管效能度量与数字紧密相关,但关在小黑屋里仅盯着数字是很糟糕的。建议大家多到研发现场去,把数字与现场观察进行比对。

04研发效能度量的行业发展方向

最后分享我对研发效能度量行业发展方向的几点认知。

首先,行业对于效能度量的认知是越来越落地的,也在踩坑和反思的过程中逐渐摆脱了一些反模式,相信大家会逐渐走到效能度量的正轨上来。

其次,指标只是度量的第一步,度量工具也会逐渐向智能诊断分析的方向走。

最后,从使用方法上,大家也会从堆砌指标向效能提升闭环靠近,反思数据+进行实验,找到在具体场景下行之有效的方法,将改进落实到实处。下图来自阿里云效能产品负责人张燎原老师。

如果您想了解更多关于本次演讲的内容,可以联系思码逸团队获取演讲视频和演讲PPT;

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

如果您想要与思码逸团队交流,欢迎在网站留下联系方式,我们将在24小时内回复。

与先进研发团队并肩

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

Mars Sun

腾讯CODE平台产品负责人

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

杨永强

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

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

唐洪山

原京东科技研发效能部

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

应阔浩

自如基础架构部总监

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

杨扬

和讯网CTO

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

朱文雷

长亭科技CTO

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

周彦斌

云货优选 研发部门负责人

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

谢超平

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

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

谢超平

王蕾 贝壳工程效率负责人

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

谢超平

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

我们的客户

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

取消