度量指标的陷阱

研发效能指标的构建，在最近几年的博弈和发展中，笔者以为已经形成了基本的共识。但是最近在参与某个团队的度量指标选择时，又产生了很多疑问。本文纯粹从自己的理解上来讨论研发效能度量指标，欢迎指正。

01

先回答一个老问题：为什么需要做研发效能度量？理论上应该是为了提升效率，让团队往更好的方向去发展。

在效能度量指标体系中，应该包含结果指标和过程指标。结果指标建议少而精，用于整体方向的引导和驱动，这类指标由于涉及因素较多，博弈成本比较高；过程指标是更容易被博弈的，建议给团队自主权，让团队自己去决定是否使用，减少通晒和考核，而强调过程指标在发现问题、解决问题方面发挥的作用，也能减少追数据的现象发生。从结果指标开始，以终为始去牵引。

如果一个指标，不能很好地牵引团队去做质量改进，就没必要去度量。

02

在研发效能指标的选取过程中，首先应该要考虑到的就是从全局的视野来看瓶颈点在哪里。这样可以避免过度的局部优化，但对整体交付效率的提升没有过多的帮助。比如在测试领域，过度地强调自动化，以期提升测试效率，提升交付质量。但如果产研团队的最大瓶颈并不在测试，那自动化测试对全局的交付效率提升意义就不大。

如下图，通过对全局的价值流分析和不同维度的周期设定，可以快速识别出团队的瓶颈在哪里。优先确认周期最长的环节，下钻分析原因，制定改进方案。

如果研发效能指标的制定是各领域自行定义，会能很明显地感受到部门墙的存在。指标多数是约束上流而忽略自身。我们应当跳出自己所在的角色，从更高的视角去看待度量指标，让指标引导过程改进，而不是让自己更轻松。

03 来看看第一个例子：测试代码覆盖率指标。

测试代码覆盖率指标：代码覆盖率的主要目标是为了度量测试场景对代码的覆盖情况。这个指标好不好？个人理解，从测试的角度看，并不好。因为高覆盖率并不能说明测试得更充分（比如对异常的处理，如果代码没有考虑到，那么就会被遗漏。但是覆盖率可以达到很高，不捕获异常等于没有异常 =.=!!）.

同时，这个指标会让测试人的注意力，从需求和用户场景侧，转移到代码层。过度考虑代码的覆盖，而忽略了业务是否需要这样的场景，是否有真实的价值产生（度量什么，就会得到什么）。当下测试人员的价值已经从文档测试逐步向价值验证转变，需要更关注业务价值。

04 来看看第二个例子：生产缺陷逃逸率。

先看看这个指标的计算公式：生产缺陷逃逸率 = 生产缺陷数/（生产缺陷数+测试人员提交的缺陷数）。这个指标给团队的指引是什么呢？为了降低生产缺陷逃逸率（这个指标过高，肯定是要挨骂的），就在测试环节多提缺陷。缺陷一多，研发又不高兴了（他们也有缺陷指标）。所以，这个指标不但不能促进研发效能的改进，反而会让研发和测试更对立。

那么生产缺陷逃逸率要如何计算呢？常见的做法是：生产缺陷逃逸率 = 生产缺陷数/需求个数。要想降低生产缺陷，要么多为质量负责，减少分子。要么，多产出可交付的需求数，让交付周期变短。是不是双赢？至于需求的大小问题，一定会达到团队内平衡的，因为需求的最小粒度是有交付价值！

05

从结果指标开始，以终为始去牵引。过程指标的度量，问题的挖掘乃至改进，是为了达成大目标，而大目标是由结果指标来反映的。结果指标选定后，先让各研发团队了解现状，接着不同团队达成目标的路径可能是不一致的，那各团队再自选过程指标，去发现并解决问题。

在选取过程指标时，要避免过度强调单点指标，而是使用多维度的、相互制衡的指标矩阵。刻意追某个指标，其他指标就会出卖你。同时，要注意不同角色间的指标互斥问题，比如研发有代码缺陷密度指标，而测试有缺陷数量指标，这就容易让两个角度相互打架。

如果一个指标，不能很好地牵引团队去做质量改进，就没必要去度量！

最后： 下方这份完整的软件测试视频学习教程已经整理上传完成，朋友们如果需要可以自行免费领取【保证100%免费】

 这些资料，对于【软件测试】的朋友来说应该是最全面最完整的备战仓库，这个仓库也陪伴上万个测试工程师们走过最艰难的路程，希望也能帮助到你！