这是鼎叔的第一百一十三篇原创文章。行业大牛和刚毕业的小白，都可以进来聊聊。
欢迎关注本专栏和微信公众号《敏捷测试转型》，星标收藏，大量原创思考文章陆续推出。本人新书《无测试组织 - 测试团队的敏捷转型》已出版（机械工业出版社），文末有链接。
我们继续聊聊，为什么看着挺好的度量指标，在实际考核工程师绩效时，常常起了负面效果？
相关前文：聊聊传统质量观 VS 敏捷质量观
从本能上，工程师会遵循经济学的规律。没有任何一个单一简单的指标经得起各种推敲，聪明的工程师一定有办法把他变成 “虚荣指标”——看着很好看，但是没有起到促进效益的作用。尤其当我们把度量指标和绩效挂钩时，它很容易被人扭曲成让人误导的解释，以便获得更多的利益。
下面是鼎叔经历过的因质量度量引发负面效果的几个例子。
一、考核测试工程师的缺陷定级准确性
某大型公司，会严格考核工程师提交缺陷的级别准确性，背景是不同的缺陷级别的处理优先级不同，有限的开发人力只能在发布日之前保证处理一部分高级别缺陷。因此 QA 会对执行测试的初级工程师进行定级标准培训，并对其结果加以考核。如何判断定级是否准确呢？以开发在修复缺陷时判断为主。
这个场景存在的问题：
虽然定级有指导模型，但是不同权重因素的交织（影响用户范围、频率、营销里程碑，重复发生情况、领导关注，品牌和安全等等），使得总有部分缺陷的严重程度是无法达成共识的，从测试的意愿（希望缺陷被修复）会采纳更高的定级规则。而从疲于修复缺陷的开发角度，利用各种不可能被事先约定的理由来降低缺陷级别就成了更佳选择，尤其是有些缺陷不容易重现，开发就更有动力阻止缺陷的升级。
此外，如果定级被认为不准，会影响绩效，那么测试人员在看到一个疑似缺陷或难以复现的缺陷，他会不会选择不提交数据库呢？当然是可能的，因为很难有确凿证据证明这是个明白无误的缺陷。更有甚者，开发会单方面解释这是 “用户的误解”，产品就是这么设计的，解释一下就好了。定级准确率度量就会进一步阻止测试人员据理力争和澄清到底的意愿。
二、度量各模块导致的事故数量和级别，并进行处罚
如果我们把一年来所有的线上事故进行盘点，按照引入故障的根因模块进行排序，会发现越是关键的中枢模块，排序越靠前。也就是说，如果按照事故引入数量和级别来处罚，那么越是公司的核心架构师，被处罚得越狠。
《人月神话》这本书提到，一个软件复杂度是由它的核心概念所构建的，它很难通过系列自动化手段大幅缩短开发周期。同样的道理，一个复杂系统软件，容易出问题的地方，往往是概念复杂度更高的模块，它和员工敬不敬业，认不认真没有必然关系。
因为组织结构决定软件风险，核心的中枢模块，往往会挑选最厉害的工程师来设计和维护，长此以往，只有他最精通这个超复杂模块的内部和关联模块的交互逻辑，也只有他能快速解决问题（当然这种状态对组织来说并不健康）。对于复杂业务逻辑链条和大量模块调用的产品，出故障概率最高的也是这里。因此，以故障数量和级别来处罚这个资深员工，显然是不合理的。
三、测试用例的自动化率
这也是技术部门最常见的考核指标，度量所有用例中实现了自动化的比率，确认考核结果的方式就是看自动化平台的指标呈现。
作为初期的自动化建设牵引，这个指标是有一定正向价值的，但是随着团队越来越成熟，这个指标的价值就不一定正向了。
本公众号一直在强调，自动化不是灵丹妙药，不是越多越好，而是看自动化的目的是什么，执行和维护的成本有多高。
现有的用例中，如果很多是面向用户验收的场景，可能随着产品变更而变化很大，是不是都要做成自动化并长期维护（矫正）呢？另外，越涉及完整交互链条和视觉验证的业务，自动化成本越贵。何况很多老用例的设计都已经过时了，价值很低但是数量庞大，纳入自动化目标的话得不偿失。
另一方面，工程师有多种方法对自动化平台的指标进行突击，比如强行 hardcode 通过，或者快考核时再录制修改脚本，这些自动化并不能在研发过程中起到持续保障作用。
四、通过用例发现的缺陷数量（或用例缺陷密度）
从强化用例设计的有效性来说，这个指标表面上有积极作用的。但是关注用例的缺陷密度，有可能阻止测试人员动态地探索需求的边界，通过用例数量限制了思路发挥，得不偿失。
有些公司使用这个指标，更多的是为了节省测试人力，希望降低用例数量后，能以更少的人力发现数量尽量多的缺陷，但是这个指标的想法是一厢情愿，因为用例和缺陷之间没有等比例的关联度。从逻辑而言，历史重灾区（破旧功能模块）遗留的缺陷更多，但这个指标是否导致测试人员聚集于此，而忽视了 “非高危模块” 的风险呢？
同理，度量开发人员的 “代码量”，以及 “代码缺陷密度”，也有类似的负面效应，对代码量进行 “注水” 太容易了。开发的人均交付价值大小建议用交付的故事价值点数除以投入周期来决定。
综上所述，依赖度量指标考核工程师绩效经常很不靠谱，指标仅作为某个客观事实，供管理者参考。
那什么样的数据更适合用来作为绩效参考呢？基于敏捷理念，我觉得这些反馈更有价值：特性交付的整体效果，质量评价，特性团队的评价，直属经理与之共事的评价，专业能力建设等等。绩效管理要考虑的内容很多，本篇就不太多展开了。
进一步聊聊- 度量的误区
我们即使有机会为真正拥抱敏捷的研发团队进行质量度量，而且被度量的人员也没有作弊行为，那设计出来的度量指标就一定满足预期效果么？显然不是的，度量指标设计并不容易，经常会踩入一系列误区。
误区一，认为度量没有成本。
实际上，度量是有成本的，而且成本可能相当高。包括：
设计度量指标和评审指标的成本。别忘了，度量涉及项目越广，参与评审互动的人就越多，成本也就越高。
准确人工填写或者自动化实现采集指标的成本。
被度量的团队规模可能很大，相关的培训宣导、检查、分析、汇报的成本可能会很高。
正因为被卷入的人很多，涉及到各团队的职责考察，如果度量指标容易误解，还会带来一系列的解释和争论成本。
误区二，度量是 QA 部门的事，其他角色配合提供数据就好。
基于敏捷原则，质量度量不是专属 QA 的职责，而是项目全员的职责。
曾经有测试团队希望招聘一个专职的初级 QA，接手大量缺陷的具体分析，输出改进计划，这样测试人员就可以专心做测试任务了。本质上，这是违背质量内建要义的。产生该缺陷的开发人员以及发现该缺陷的测试同学，是最应该从缺陷剖析中受益的，感受也最深，而不是接受外部新手的事后分析观点。其他度量指标场景也是类似道理。
项目成员如果坚持认为度量动作和自己无关，必然导致质量改进的措施难以落地。
误区三，度量通常会关联处罚。
上篇聊聊传统质量观 VS 敏捷质量观也提到，度量应该就事论事，提醒当事人深入分析，有则改之，不应该直接得出对人的批评结论。如果一说度量就联想到处罚，会带来大家消极对待度量，并掩饰不良数据的后果。
误区四，既要传统的质量度量体系，也要实施敏捷度量。
传统的严格管控型度量体系，会产生越来越多的考核指标，但是很多指标并不能鼓励敏捷提效。有些团队因为被传统度量考核的负担压制久了，失去了挖掘新的减负 “指示器” 的勇气。
既然我们决定轻装上阵，那应当暂时放下习以为常的指标，重新思考哪些指标是真正能促进产品尽早的、小批量的交付给用户的。度量不是工作的目标，而是指引工作如何改进的指南。
推广敏捷度量方案的关注点
即使指标体系本身没有什么问题，在行业中已经有成熟应用，我们在新团队实践中仍然要多加小心，以免踩坑，比如下面这些在鹅厂踩过的坑：
一，Leader 要自己主导度量分析和改进，要清楚知道指标不佳的原因，要思考长效管理改进的办法。
不要仅仅把指标问题透传给下属，纵容下属简单粗暴地 “卷考核指标”，这是不可持续的虚假繁荣，可能会让希望单纯埋头工作的人才流失。
二，每个业务研发部门都有自己的业务特性和团队特性，不要急着把一大批指标和改进要求推到所有研发部门，而是针对差异点和现状进行分析，选择合理的过渡适应方案。
比如，金融业务和电商业务有不少差异，重服务端团队和重客户端团队又有不少差异，有的团队有繁重的 UAT 签字流程，有的团队可以自主发布版本。一切从团队的实际苦恼出发。
三，不要增加一线员工的手工填写度量信息的认知负担，这需要大量的细节思考。每个关联指标，是完全的系统无感知获取，还是依赖人工填写字段的二次处理；如果是后者，填写的选项该怎么设计？这就需要金字塔拆分的技巧了。
鼎叔的经验是：每个人工选择的下拉字段，选择值不要超过十个，最好是 3-6 个，这些选择项既覆盖完整（不遗漏主要类型），又正交（不会重叠）。
如果一级字段填写，得到的分类还是太粗，可以设计为二级填写。
有一些选项值可能太长尾 - 即种类零碎且实际占比很低，那我们可能要用 “其他” 来归类，或暂时放弃它们，我们可以从过往统计数据中看到哪些选项属于长尾。
太多长尾值，对于公司的度量分析体系设计没有明显的好处，一线团队可以将来自行分析。
四，给一线 leader 及团队做度量指标讲解，说说度量指标背后的思考，字段的定义和作用解读，填写时的应注意事项。
更重要的是，探讨质效指标如何助力业务研发团队的年度目标达成？这里埋藏着公共效能团队和业务团队的共建机会。
五，指标展示的透明度，对高层汇报时公正完整，辩证主义视角，不要报喜不报忧，面向团队自主改进而非绩效排名。