警惕度量指标陷阱

本文首发于个人网站「BY林子」，转载请参考版权声明。

近日，某群有人发了领导制定的绩效考核指标：

对测试人员的工作成效进行考核，指标是发现的 Bug 的情况，甚至有参考指标细到每个小时要求发现多少 Bug，同时还考虑不同严重程度的 Bug 占的权重也不一样，并附有详细计算公式。当然，细节就不说了，大意是发现 Bug 越多绩效越好，且越严重得分越高。

这可真是一套经过严密设计的考核指标，相信这位指标制定者一定下了一番功夫！

指标固恋（metric fixation）

杰瑞·穆勒（Jerry Z. Muller）所著的《指标陷阱（The Tyranny of Metrics）》对痴迷于使用指标来度量绩效的现象提出“指标固恋”的概念：

1. 相信基于标准化数据的可比较绩效的数值型指标，替代依靠个人经验和天赋获得的判断力，不但可行，还是可取的；

2. 相信公开这些指标（透明），可确保机构履行其目的（问责制）；

3. 相信在这些组织内，激励人们的最佳方式是根据其测量绩效进行奖惩，奖励可以是货币性的（绩效薪酬），也可以是声誉上的（排名）。

很多的管理者都喜欢使用看似非常客观的标准化的数据来考察人员的绩效，但人不是流水线上的机器，软件开发过程是一系列的社会化活动，怎么可能通过简单的标准化数据来衡量呢？

度量什么，就一定能得到什么

上有政策，下有对策。当度量指标跟绩效挂钩，指标就会被操纵。

在《指标陷阱》一书中介绍了各行各业的指标操纵案例：

• 航空公司延长航班预定飞行时间，以提高正点率；

• 警方只逮捕低级毒贩来提高办案效率，而放任大毒贩逍遥法外；通过不登记报案来降低犯罪率，使得受害者得不到保护，而违法分子得不到法律制裁；

• 医生避免治疗疑难病例，以维持成功率，使得最需要医生的病人得不到医治；

• ……

同样，对于本文开头提到的测试人员绩效考核指标，各位专家同仁积极出谋划策，提出各种可以提高绩效或响应该指标的好建议：

• 指标制定者说啥就是啥，好好配合吧

• 跟研发搞好关系，多写点 Bug

• Bug 别一次性都提报, 控制好节奏

• 有些不那么严重的, 可以屯着, 等下个 Milestone 再报

• 能拆的 Bug 就拆开来报

• Fuzzing 和 Monkey Testing 走起，Bug 一堆一堆地出来

• 准备一块板砖，随时拿手里……

• 走人！

这件事情很有意思，这样下去测试人员的工作变得简单多了，至于产品质量是否有保障，相信大家也已心知肚明……

如果指标被操纵，看似度量结果很完美，但跟我们真正需要关注的内容可能已经偏离十万八千里。不恰当的度量指标，可能会带来扭曲的、欺骗性知识：可度量的，不一定值得度量；度量得到的东西跟我们真正需要的可能毫无关系；度量的成本可能高于收益；被度量的东西，可能分散我们需要真正在乎的事情上的精力。

让度量发挥它该有的价值

度量指标可能会被操作，导致结果没有意义；度量没用对地方，可能会带来负面结果。但是，度量还是有价值的，只不过，我们需要正确运用度量，让其发挥价值。

那么，该何时使用以及如何使用度量指标呢？《指标陷阱》中介绍了一个核对清单，我们在做度量方案的时候，值得对清单中的每一条都进行谨慎斟酌：最合适的做法是不是根本就不使用指标。

该核对清单包含 10 个问题，详情如下。

1. 你要度量的是什么类型的信息？

不同类型的被度量对象对度量结果可靠性的影响是不同的：

• 越接近无生命物质，度量的可能性越大，如自然科学和工程学等；

• 如果被度量对象受到度量过程影响，度量的可靠性就会降低；

• 被测对象越接近人类活动，度量过程越不可靠，因为人的自我意识会对度量过程做出反应。

而软件开发是一项复杂的人类社会活动，在定义软件质量相关指标的时候，就需要提防度量有效性被人为地扭曲。

2. 所测信息有多大的用处？

要始终提醒自己，有些可以被度量的活动，并不意味着它值得被度量。有可能越容易度量的东西，对它度量的意义反而越小。例如，前面提到的 Bug 数量很容易度量，但是把它作为测试人员的绩效指标，对于软件的高质量交付完全没有帮助。

3. 更多的指标有多大的用处？

度量指标可能在辨识异常情况方面会起作用，本来就很好的绩效可能很难通过指标来区分；指标越多成本也越高，甚至成本可能超过收益。因此，指标有用，但也不是越多越好。

4. 除了标准化的度量外，是否还有其他信息源？

对软件质量的度量，人们往往喜欢用工具平台收集到的数据，除此之外，是否还有一些实践过程以及客户满意度等信息的综合考虑？对测试人员的考核或许收集 360 度反馈更加有效？

5. 度量用于什么目的？

当度量跟绩效挂钩，用来衡量个人或团队工作做得好与坏，就很容易被各种“对策”糊弄；而度量仅是评估现状，用于牵引持续改进将会更有价值。

6. 获取指标数据的成本是多少？

获取信息都需要成本，如果成本太高，再有价值的指标可能也不划算。平衡成本和收益，是务必要考虑的因素。

7. 领导为什么对绩效指标提出要求？

对绩效评估的要求，有时候是源于对情况的不了解。比较常见的有对外包的开发或测试团队的绩效考核，可能是由于不了解供应商的具体情况而不放心。这种情况下是否可以通过更有效的协作和信息共享等方式来增加透明度，而不是简单地用指标衡量？

8. 绩效指标由谁设定，怎么设定？

如果问责制的绩效指标自上而下强加的，由远离一线工作的人设定的标准化公式，就很难发挥效果。前面提到的 bug 数量作为测试人员的绩效指标就属于该情况。如果能有一线人员参与指标的设定，效果可能会好很多。

9. 请记住：哪怕最好的度量，也受制于腐败或目标转移。

人总会想方设法最大化自身利益，绩效度量计划也就难免会存在缺陷。建议不要采用单一指标来度量，而是综合运用多个指标，让指标之间有一定的制约关系，从而缩小可操纵空间。同时，度量策略也需要定期回顾，持续演进，确保始终在为正确的目标服务。

10. 请记住：有时候承认可能存在的局限性，是智慧的开端。

不是所有的问题都能得到解决，仅依靠指标能解决的问题更少。有些重要情形，需要依赖经验或无法量化的技能来判断和阐释，这时如果想依赖度量指标来解决，可能就会误入歧途。

写在最后

简单说来，度量最关键的有以下三点：

1. 度量需要以目标驱动，真正为目标服务的度量才可能发挥价值。例如，目标是交付高质量的软件，应该是 Bug 数量越少越好，如果用发现更多的 Bug 数量来度量测试人员绩效更好，那就是本末倒置，显然得不到高的质量。

2. 度量需要综合多个指标，定性与定量相结合，过程指标和结果指标相结合。这块内容，于晓南的度量系列文章有非常详细的介绍。

3. 不要过度迷恋度量，小心落入指标陷阱。

推荐阅读

• 书籍《指标陷阱》

• 文集：质量度量
  

• 文章：《构建测试的体系化思维（基础篇）》

• 文章：《构建测试的体系化思维（进阶篇）》

• 文章：《构建测试的体系化思维（高级篇）》

本文首发于个人网站「BY林子」，转载请参考版权声明。