终极指南:如何在中大规模企业成功落地研发效能度量?❓❓

小青爱吃草2021-10-25  248

作者 | 张乐

编辑 | 蔡芳芳

在之前的文章中,我们分别讨论了效能度量的难点和误区、业界案例和关键原则、度量实践框架、度量指标体系设计、度量常用分析方法,但在中大规模企业中成功落地效能度量还有很多因素需要考虑,本篇文章我就结合近期落地经验,来介绍一下落地过程中具体的实施建议。

1

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

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

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

✅️度量的用户场景

度量指标是统计出来用来给人来看的,我们首先要找准用户和场景,没有目的性的堆砌指标没有任何价值。

比如,高层管理者一般关注组织级的效能评估结果,包括整体的研发投入产出、战略的资源分配和达成情况、业务满意度、各事业部北极星指标的横向对比、研发效能月报等,但可能不会关注特别细节的指标数据。团队级管理者不仅会关注团队交付效率、交付质量、交付能力等全方位的效能指标,并且希望度量平台具备问题自动化诊断和分析能力,能够结合趋势、下钻、关联分析等多种手段帮助识别效能瓶颈。工程师也会关注一些效能指标,用于对个人工作进行需求、任务、代码、缺陷等维度的统计和反馈。

✅️度量的指标体系

我们在之前的章节中讲到了很多度量指标,但只有指标的定义是不够的。我们还需要明确指标价值、指标说明、指标公式、指标采集方式、指标优先级、指标健康度等内容。✅️度量的根本要求之一就是数据的准确性,那么度量指标的健康度就显得尤为重要了。我们曾经发现在推广度量体系时,某部门的需求交付周期小于 0.1 天的占比为 8.6%(290/3374)⭐,经排查,这些需求通常为研发完成后补录,这些数据的存在会影响交付周期度量结果的准确性,需要格外引起重视。另外,指标体系及其详细说明应当尽量公开透明,这样用户在得到指标度量结果的时候也可以更清晰理解其计算口径和与其他指标的逻辑关系。

✅️度量的模型设计

模型是对某个实际问题或客观事物、规律进行抽象后的一种形式化表达方式,一般包括目标、变量和关系。在研发效能度量领域,模型有很多种,比如组织效能模型、产品 / 团队效能模型、工程师效能模型等。效能度量的领域专家可以建立模型,并通过度量平台屏蔽其复杂性,提供给用户自助化分析使用。

一个典型的应用场景是效能度量的体检模式,即度量平台根据领域专家总结出来的效能指标和既定模型,对产品线某个时间段的研发过程进行分析体检并推送体检报告,相关干系人都可以定期收到报告。在报告中标识了的正常 / 异常的研发效能指标项,并带有初步分析结果和问题改进的建议。然后,如果想对其中的某个指标进行详细分析,则可以切换到问题诊断模式,这样可以基于模型对相关的指标及报表组合进行专项分析,包括各种趋势、下钻和关联分析等,帮助排查具体问题。在积累了足够的历史数据后,也可以通过模型进行风险预警,当发现某些指标有异常波动或相不好的方向发展的趋势后,及时给出风险提示。

✅️度量的产品建设

研发效能度量的过程实际上是要把数据转化为信息,然后将信息转化为知识,这样就可以让用户自主消费数据,进行分析和洞察。一个优秀的研发效能度量产品要做到自动化的数据采集,自动化的数据聚合,让用户可以自助化的查询和分析,甚至自定义报表,从而获得研发效能的有效洞察。度量产品应该是可以被整个组织的团队和管理者访问到的,效能数据也应当被更加透明地使用,不宜设置过多的数据访问权限,人为地制造信息不对称。

度量平台也应该被作为一个产品而不是项目来运作,包括度量什么、如何分析、如何对比实验都是需要持续演进的,而且作为一个产品我们要多听取用户的反馈,这与建设其他产品的过程都是一样的。另外,度量产品一定要注重易用性,使用平台的用户往往不是这个方面的专家,应该避免使用复杂的公式定义和晦涩难懂的专业术语进行描述。例如下图就是度量平台对交付周期类指标的一种可视化的展示视图,用户可以在页面上进行点选操作,关于指标范围、说明都动态展示,让用户可以一目了然进行快速理解。

✅️度量的运作模式

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

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

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

2

通过自动化降低度量带来的额外成本

研发效能的度量不是免费的,为了做到准确、有效的度量,各种成本加在一起是很高的。度量的准确性依赖流程的规范性,需要明确研发流程、制定相应规范,并确保相关的活动都在系统中进行及时、完整的记录。为了能在减少研发过程中各个角色时间和精力投入的基础上提升效能度量的准确性,可以通过统一工程效能平台固化研发流程与活动,并通过自动化的手段减少工程师繁琐的额外手工操作(如在多个系统进行状态更新同步等)⭐。

在研发过程中,我们要同时关注管理侧的需求价值流和工程侧的研发工作流。管理侧的价值流以需求特性为核心,贯穿就绪、设计、开发、测试、发布等阶段。工程侧的研发工作流以代码提交为线索,会执行分支创建、代码提交、编译、扫描、测试、代码合并、部署、发布的等一系列活动。我们可以通过效能工具平台的建设,让这两条流之间实现联动,自动完成状态的流转和信息的同步。

下图就是一个自动化状态流转和信息同步的案例,部门选用了特性分支开发的分支模型,当特性分支拉出并关联需求的时候,或者代码提交 Commit 信息关联了需求 ID 后再进行 Push 的时候,就会触发对应需求的状态更新,从”就绪”更新为”开发中”。当代码 Merge Request 合并到 remote/dev 分支时,会触发对应需求的状态更新为”测试中”。当代码合并到 remote/master 分支时,会触发对应需求的状态更新为”发布中”。直到最终发布完成后,需求的状态自动更新为”已完成”。这种自动化的状态流转让系统中记录的研发过程元数据更为准确,也在较低成本的情况下给度量提供了有效的研发基础数据。

3

避免度量的平均值陷阱

平均值陷阱,是指由于参与平均值计算的数据样本存在较大差异,平均值难以真实反映所有样本状态的情况。比如某个需求的交付周期是 1 天,第二个需求是 2 天,另外一个需求是 96 天,那么这三个需求交付周期的平均值就是 33 天,这明显无法反馈出真实的情况。

转载请注明原文地址: http://www.youzishihuo.cn/tech/717512
00