如何建成有效的前端效能度量体系
引言
现代管理学之父彼得·德鲁克说：“如果你不能度量它，你就无法改进它”。优秀的度量体系对目标会有很强的正向牵引作用，不恰当的度量体系往往会引发一场灾难。虽然好的度量标准能够帮助我们理解研发效能，确定改进方向，并衡量改进效果，但是如何构建度量的体系化框架、如何选取度量指标、如何进行度量分析以及如何进行落地运营，却是一个不小的挑战。
在剖析如何定义度量体系之前，有必要先澄清两个概念。所谓 “效能”，是指从质的层面求效，意味着 “做正确的事”，即 “做对”；衡量效能的依据有效率、质量、效益。所谓 “效率”，是指从量的层面求效，意味着 “正确地做事”，即 “做好”；望之以尽可能少的投入获得尽可能多的产出。追求效率要以追求效能为前提，不但要求正确地做事，首先要求做正确的事。
现实的困境
当处在数字化的时代变革中，研发效能已经越来越成为一家科技公司的核心竞争力，能够帮助提升效能的方法论和实践也一直在快速发展。比如十多年前产生的敏捷方法论，以及后面延伸出来的 DevOps，都已经被很多企业引入并进行了落地和实践。但现实中却存在一种奇怪的现象，就是当一个组织或团队在消耗了大量的时间和人力成本进行 “变革” 后，却无法有效回答一些看似非常基本的问题，比如：
团队研发效能到底怎么样？可否量化？
处在行业中什么水平？相比别的公司和团队是更好还是更差？
团队研发效能的瓶颈点在哪里？
经历了一系列 “变革” 实践之后，有没有实质性的提升？
可见，一个科学合理的效能度量体系，其目标应该是让效能可量化、可分析、可提升，通过数据驱动的方式更加理性地评估和改善效能。
但在实际操作过程中，软件研发效能的度量其实是相对困难的，原因有以下三个：
研发过程中进度更新不及时
涉及到产品、研发、测试、运维等不同职能，多个团队多种角色协作时，任务处理的进度很难被清晰地统计到，比如任务已完成或出现了延期但却没有及时地更新进度，以至于项目管理软件中很多任务的进度百分比可能只有参考意义，实际并不准确。
软件工作粒度的随意切分
有时管理者会制定一些 KPI 来度量团队绩效，但就像那句名言所说：你度量什么，就会得到什么。其实这句话只说了一半，另一半是：只是不一定是用你所期待的方式得到。所谓上有政策、下有对策，由于软件工作切分的随意性，也许把一个需求拆成多个小需求，一行代码拆成多行来写，某些 KPI 指标就被用非预期的方式完成了。
敏捷开发中工作是并行的
随着公司敏捷研发模式的持续推进，我们很难再像传统项目管理模式一样清晰界定软件研发的各个阶段，很多情况下不同需求所对应的开发/测试工作都是并行的，产品也是不断迭代、持续演进的，这也对准确度量造成了一定的困难。
另外，现代信息工作的通病就是经常容易被各种不断到来的干扰打断，比如一个同事问你一个问题、来自微信上的消息通知或者突然被拉进一个会议里。这种高度并行、频繁被打断的场景往往无法被度量出来，我们也许看到每个人都在很饱满地忙于各种任务，但其实这种工作流的中断对于效能的影响是非常巨大的。这就是所谓的 “忙忙碌碌一整天，好像啥也没做成”，相信很多人都有这种经历。
反模式
前事不忘后事之师，在讨论正确的度量之前，我们先看一些定义度量体系时的常见误区，即所谓的 “反模式”。
使用简单的、易于获取的指标
比如以单位时间内产出的代码行数，来衡量工程师的工作是否饱满、产出是否高效。代码行是一种简单的、易于获取的指标，但不会是一个好的度量指标，因为代码不一定越多越好。在这个度量的导向下，工程师可能倾向于提交大量重复、冗余的代码来 “凑指标”，让数据变得很好看，但这对企业没有任何价值。相反，代码也不是越少越好。因为在同样业务逻辑下，大量使用复杂语法和表达式来精简行数，最终的结果就是写出来的代码晦涩难懂。
过度关注资源效率类指标
比如以工作时长为度量手段时，在内卷和 “表演型” 加班的氛围里，这种工作时间的延长其实根本无法转化为实际有效的产能。我们经常看到的情况是，研发似乎忙得热火朝天，但是业务仍然抱怨做得太慢。即使大家真的都在忙，也会导致更多的衍生问题。比如资源利用率的饱和会导致上下游协作时的大量排队和等待，这种局部的过度优化会导致全局的效率劣化，对企业来讲得不偿失。另外，长期强调超高的资源利用率，有把员工当成 “资源” 而不是 “工程师” 的倾向，会令员工产生幸福感下降。不仅会影响代码编写过程的生产力，还会影响结果代码的质量。
片面地使用局部过程性单一指标
需求交付周期是常见的效能度量北极星指标，在行业实践中引用的比较多。但是，如果一个组织或团队仅仅认为交付快了、周期短了就代表效能提升了，其实这就是一种片面的追求了。研发效能的提升不仅是有 “效率” 这一个方面，还有很关键的另外一个部分是 “有效性”。我们所谓的效能提升，一定是要从业务目标出发的，构建的功能、质量是需要达到期望要求的，在此基础之上当然效率越高越好、成本越低越好，所以我们说的效能实际上综合考虑了关于产出和投入的多个要素。回到需求交付周期这个指标的例子，追求这个指标的优化当然很重要，但是需要在功能有效，吞吐量和质量稳定、安全合规的基础之上才有价值，片面地使用局部过程性指标对于研发效能提升的效果有限，而跳出来看到全局的研发体系和结构才是关键。
手工采集，人为加工和粉饰指标数据
效能度量过程中最基本的一个要求是度量数据的公信力。研发效能度量的过程实际上是要把数据转化为结论，最终由结论来影响决策。在研发效能度量的初始阶段，可能会存在各种各样的研发工具产生出来的原始效能数据，但缺少对其进行分析和加工成信息的自动化工具。在这个过程中，经常存在大量的人工干预行为。那么，在数据分析和加工过程中，就很容易有意或无意地引入一些数据集合的筛选或 “异常数据” 排除的行为。有时甚至是仅仅为了让数据变得好看、达标而做出一些看似合理但颇有欺骗性的报表来。只有通过平台自动采集、汇聚、计算出来的数据，才可以被用来进行管理和技术决策。我认为这才是一个研发效能度量产品的立足之本。
将度量指标作为 KPI 进行绩效考核
效能度量固然很重要，但当它演变成了与绩效考核挂钩的 KPI，那么久而久之，就会上演各种有创造性的、为提升指标而进行的不优雅的短视行为，度量走偏也就在所难免了。其实从理论上讲，所有的度量都可以被操纵，而数字游戏式的度量会分散员工的注意力并耗费大量时间。试图把度量作为绩效考核，不仅是一种成本浪费，而且往往适得其反。
那么，如果不把效能度量与绩效考核挂钩，那怎样才能使用度量提高研发效能呢？答案是：把度量作为一种目标管理方法、一种效能提升的参考工具，促进团队明确效能目标、分析效能问题，指导团队针对性优化，从而最终获得效能提升。比如，对线上缺陷的度量和分析，可以让团队了解产品的质量走向和问题的根因，有助于持续优化交付质量；对需求交付周期的度量和分析，可以让团队了解产品端到端交付效率和细化每个阶段的耗时占比，可以针对性的采取干预措施，让团队获得有效的提升。
仅从管理角度出发，忽略了为工程师服务
国内很多公司的研发效能度量都是主要从管理者的视角出发的，无论是工时、人员饱和度等衡量资源利用率的指标，还是需求交付周期、吞吐量等衡量流动效率的指标，本质上都是从管理维度看待研发效能这件事情。但是我们不应该把员工当成一种 “资源”，而是要作为 “工程师” 来看待。 员工幸福感的下降不仅会影响代码编写过程的生产力，还会影响结果代码的质量。他们对工作环境、工作模式、工作负载、研发基础设施、项目协作、团队发展、个人提升是否感到满意，是否有阻碍工程师发挥更大创造性和产生更大生产力的因素存在。工程师个人效能的有效提升是组织效能提升非常关键的组成部分。就像 Facebook 会把 “不要阻塞开发人员” 作为贯穿公司研发和管理实践中的核心原则之一，就是强调公司流程和实践也要从工程师视角来考虑问题。
行业案例
阿里巴巴的效能度量与 “2-1-1” 愿景
阿里巴巴围绕着团队的持续价值交付能力这一根本性问题，分别用：持续发布能力、需求响应周期、交付吞吐率、内建质量的能力以及交付质量五个指标进行了回答。
持续发布能力：
（1）发布频率，也就是团队平均多长时间发布一次需求。它约束了团队对外响应的最大可能性;
（2）发布前置时间，也就是从代码提交，到功能上线所需要花费的时间。如果时间开销很大，团队就不太可能去增加发版的频率。
需求响应周期：
（1）交付周期时间，也就是从用户提出需求并被确认，到需求上线所要经历的时长。它反映团队(包含业务、开发、运营等职能)对客户问题或业务机会的整体响应速度;
（2）开发周期时间，即从开发团队理解并确认需求，到需求可以上线所经历的时长，它反映研发的响应能力。
交付吞吐率：也就是单位时间内交付的需求的个数。
交付过程质量：
（1）开发过程中缺陷的创建和修复时间的分布，我们希望缺陷能够及时且持续的发现，并且在发现后尽快修复；
（2）缺陷库存，我们希望能在整个开发过程中控制缺陷库存量，让产品始终处于接近可发布状态，奠定持续交付的基础。
对外交付质量：
（1）单位时间（线上）问题数目；
（2）（线上）问题平均解决时长；
这五组指标概括起来，分别是流动效率、资源效率和质量三个方面。其中，持续发布能力和需求响应周期这两组指标反映价值的流动效率；吞吐率反映资源效率；交付过程质量和对外交付质量这两组指标共同反映质量水平。
什么是 211 呢? “2” 指的是交付周期 2 周——85%以上的需求可以在 2 周内交付；第一个 “1” 指的是开发周期 1 周——85%以上的需求可以在 1 周内开发完成；第二个 “1” 指的是发布前置时间 1 小时——提交代码后可以在 1 小时内完成发布。
阿里巴巴在指标的选取上，仍然秉承了优先使用面向结果的指标，其次才是面向过程的指标；更多使用全局性指标，而不是局部性指标这样的原则。另外，这里面的指标都是可被量化的定量指标，并没有出现主观的定性指标。
Facebook 的效能度量
Fackbook 从团队和个人这两个维度对度量指标进行分类，其中团队维度中又分为速度、质量和准确度三类。
速度：主要用来衡量团队研发产品的速率。比如，前置时间，从任务产生到交付的时长。
质量：如果质量有问题，产品的商业价值会被大打折扣。包括产品的性能、功能、可靠性、安全等方面。
准确度：关注产品是否跟计划吻合，跟用户需求吻合，能否提供较大的用户价值。一个例子是功能的采纳率，也就是有百分之多少的用户使用了某功能。提供用户价值是公司存在的根本，因此与之相关的指标是最最重要的。比如净推荐值 (Net Promoter Score，NPS)，是通过调研了解用户满意度，实用性很强。
个人效能：个人开发过程中的效率指标，比如开发环境生成速度、本地构建速度等。个人效能相关的度量，直接反映开发人员的开发效率和满意度，对团队产出影响很大。所以，作为管理者或内部效能团队，应该关注开发人员的高频活动，并自动化和优化这些步骤，让开发人员能专注开发。
Facebook 在指标选取上，注意到了度量要的全面性，指标之间可以相互制约。研发组织没法用单一指标来衡量，而需要用一组指标来互相制约以求得平衡。例如，单纯追求交付速度是危险的，必须用质量指标来平衡；同样，我们也不能在忽视工程师个人效能的情况下片面追求过程规范性的提升。
七大原则
通过对多个研发效能度量的行业案例进行分析，提炼出以下七大原则：
原则一：结果指标 > 过程指标
我们要以终为始，通过结果指标评估效能水平，通过过程指标指导改进。比如：需求交付周期是结果指标，敏捷活动成熟度是过程指标。
原则二：全局指标 > 局部指标
过度的局部优化可能会导致全局的劣化，只聚焦在易于度量的局部指标上，会以牺牲组织更好地提升全局目标为代价。
原则三：定量指标 > 定性指标
尽量使用量化指标客观评价，并通过系统自动采集，降低对团队的干扰。但也不排除部分综合评价的定性指标。
原则四：团队指标 > 个人指标
指标设定需要促进团队协作，共同努力达到组织目标。不能因相互冲突的指标而破坏团队配合，制造出更多的部门墙。
原则五：指导性，可牵引行动
指标设定为目标服务，指标的数值和趋势可以牵引团队改进。比如适当设定缺陷类指标可以促进质量内建能力的建设。
原则六：全面性，可相互制约
比如需求交付周期 vs 线上缺陷数量、需求吞吐量 vs 需求规模、研发周期 vs 技术债务，这些都是可以成对出现进行相互制衡的指标。
原则七：动态性，按阶段调整
随着团队能力的提升，指标也需要随之进行适当调整，从而促进团队的持续改进。
指标设计
根据研发效能度量的七大原则，结合行业案例及前端领域研发流程的特殊性和差异点，我们设计了以下三个维度九组指标，它们分别是：
需求响应能力
具体包含两个细分指标，分别是：
需求交付数：统计周期内交付的需求个数 / 统计周期，即单位时间交付的需求个数。需要注意的是，需求颗粒度要保持一定规则（如约定业务需求、产品需求的颗粒度上限），避免需求大小不统一导致的数据偏差；
需求交付周期：也就是从产品提出需求并被确认，到需求上线所要经历的时长。它反映整个团队（包含产品、视觉、开发、测试等职能）对客户问题或业务机会的整体响应速度，其中前端的有效编码时长与联调、测试时间显著影响了这一指标；
工程编码能力
有效编码时长：度量的是从研发开始编码到提测之前的时间段，包含自测及代码审查工作。和需求吞吐量一致，需要需求颗粒度要保持一定规则，避免需求大小不统一导致的数据偏差；
代码规范度：良好的代码规范和基础的静态检查能够避免很多低级问题，在这方面基于人工的代码审查 及代码质量工具扫描，可以建立起代码规范度的要求；细分下来，代码规范度可以由以下几个二级指标按照一定的权重构成：
千行代码缺陷率：统计周期内线下问题数 / 千行单位的代码行数；这个指标能够在一定程度上反映出提测代码的质量好坏；
持续交付能力
平均发布周期：团队平均多长时间发布一次需求。它约束了团队对外响应的最大可能性；
发布成功率：发布成功后，且没有导致服务回滚、降级或需要事后补救的比例；
线上故障密度：统计周期内线上严重级别的故障数 / 需求个数；
故障恢复时长：度量的是从发生故障到修复完成之间的时间段的平均值，即系统出现问题后恢复的速度；
好的度量体系应该回答一个根本性的问题，并为此讲述完整的故事。为回答团队持续价值交付能力如何这一问题， 上面九组指标，横向来看，分别从需求响应能力、工程编码能力和持续交付能力三个方面描述了一个完整的过程；纵向来看，所有的指标都分布在研发流程的各个阶段中，即需求、开发、测试、发布及运营过程中。
以下是一个完整交付周期的全景图：
全景图
在全景图中，除了前面定义的九组指标外，还出现了一些常用指标，但并没有被选取到前端效能度量指标体系中。这些额外的指标虽然也有一定的参考意义，但其要么不符合我们的七大原则，要么其贡献方并非只有前端一方。
体系框架
研发效能的度量是一个完整的体系框架，包括度量指标的设计、数据的自动化采集、度量模型的构建分析、度量产品建设以及数据运营等多个方面。同时，度量与效能提升的实践应该形成一个闭环：从特定的研发效能痛点出发，抽象出具有参考意义的北极星指标，并构建自动化数据采集的能力，获得客观数据，通过分析数据模型，挖掘问题本质，找到提升效能的有效途径。这样层层推进，持续循环，获取自我反馈，才能让度量做到首尾呼应与可持续发展。
形成能力上的闭环
产品化地运营与建设
建立数据自动化采集的能力
借助于各类研发平台工具进行数据自动抓取，包含但不限于开发 Chrome 或 IDE 插件进行代码扫描、利用 Gitlab Hooks 钩子或 研发平台能力升级进行代码审查精细化采集，借助 Team 需求缺陷管理平台进需求缺陷类指标统计等等。最后将各个渠道度量指标数据分层处理、汇聚存储。在存储介质上，小型团队通过 MQ、API 等方式把数据采集起来之后，使用 MySql（存放明细数据和汇总数据）、Redis（存放缓存数据）、ES（数据聚合和检索分析）三件套基本就够用了；而大规模企业由于数据量庞大、汇聚和分析逻辑复杂，建议使用整套大数据分析解决方案，比如流行的流批一体的大数据分析架构。
构建体检式的度量分析模型
模型是对某个实际问题或客观事物、规律进行抽象后的一种形式化表达方式，一般包括目标、变量和关系。在研发效能度量领域，模型有很多种，比如组织效能模型、产品/团队效能模型、工程师效能模型等。效能度量的领域专家可以建立模型，并通过度量平台屏蔽其复杂性，提供给用户自助化分析使用。
一个典型的应用场景是效能度量的体检模式，即度量平台根据领域专家总结出来的效能指标和既定模型，对产品线某个时间段的研发过程进行分析体检并推送体检报告，相关干系人都可以定期收到报告。在报告中标识了的正常/异常的研发效能指标项，并带有初步分析结果和问题改进的建议。然后，如果想对其中的某个指标进行详细分析，则可以切换到问题诊断模式，这样可以基于模型对相关的指标及报表组合进行专项分析，包括各种趋势、下钻和关联分析等，帮助排查具体问题。在积累了足够的历史数据后，也可以通过模型进行风险预警，当发现某些指标有异常波动或相不好的方向发展的趋势后，及时给出风险提示。
产品化演进效能度量平台
研发效能度量的过程实际上是要把数据转化为信息，然后将信息转化为知识，这样就可以让用户自主消费数据，进行分析和洞察。一个优秀的研发效能度量产品要做到自动化的数据采集，自动化的数据聚合，让用户可以自助化的查询和分析，甚至自定义报表，从而获得研发效能的有效洞察。度量产品应该是可以被整个组织的团队和管理者访问到的，效能数据也应当被更加透明地使用，不宜设置过多的数据访问权限，人为地制造信息不对称。
度量平台也应该被作为一个产品而不是项目来运作，包括度量什么、如何分析、如何对比实验都是需要持续演进的，而且作为一个产品我们要多听取用户的反馈，这与建设其他产品的过程都是一样的。另外，度量产品一定要注重易用性，使用平台的用户往往不是这个方面的专家，应该避免使用复杂的公式定义和晦涩难懂的专业术语进行描述。
有效地运营效能数据体系
有了度量指标、有了度量模型、有了度量产品，但一定要注意的是：要避免不正当使用度量而产生的负面效果，避免将度量指标 KPI 化而导致 “造数据" 的短视行为。根据古德哈特定律，度量不是武器，而是学习和持续改进的工具。正所谓 “上有政策，下有对策”，“度量什么就会得到什么”，为了避免度量带来的各种副作用，我们首要的度量对象应该是工作本身，而不是工作者。另外，效能改进的运作模式也很重要，只是把数据报表放在那里效能不会自己变好，需要有团队或专人负责推动改进事宜。
参考文献
（注：本文大量来源于互联网经验实践）
勤思考，勇实践，空杯看世界 2019.05.04 加入
快手前端，聚集于架构与生产力提升
评论