近期的培训中，遇到这样的一个问题：

我认为这是个普遍问题，非常值得深入讨论，于是便有了这篇文章。

不管我们讨论的是质量度量还是改进，亦或是提升研发效能，期望的目标都是牵引团队迈向更好的方向。所谓更好的方向，有可能是更明确的产品规划，更高的质量，更快的交付，也有可能是更顺畅的上线体验，更理想的工作氛围，这些都可以是我们追求的“更好的”范畴。团队整体变得更好了，团队中的每个人都会因此受益。

这个问题促使我们思考如何在引入一些实践的同时，不增加额外的物质成本或情绪成本，因此我认为这是个很好的问题。

回到问题本身，“增加指标如何能不加重研发的负担？” 这个问题映射的可能是对现状的不满，由于增加了度量指标，研发需要为此付出不少的额外成本，但并未获得任何价值收益。不妨采用以下的问题来抽丝剥茧，分析产生问题的原因。

1. 指标的选取是否合理？

选错了指标，从一开始便是错的，做得越多，错的也就越多。我能理解管理者对于绩效数据的硬性需求，但管理者做出的任何决策对团队的牵引作用是显著的，因此在决定做什么、不做什么时更应考虑对团队长久的影响。

2. 实施是否需要较大成本？

当前条件下不具备实施条件，没有平台工具支持。有时候看到优秀实践案例，可能包含很全的指标体系和精准的数据统计分析，这需要大量的成本支撑。可能这个案例已经具备了基础的平台能力和统一的工具链支撑，背后可能是一整个团队在运维效能度量平台。而在大多数条件下，我们并没有充足的资源，因此在引入度量指标时需要考虑当下可复用的方式和未来需要引入的额外成本。

3. 指标的用法不对

用法不对通常有几种情况：一是指标的静态值被用于横向比较，加速团队割裂和部门墙的产生；二是盲目追求数值，而忽略数值背后的价值是否仍然成立或者已然发生了变化；三是使用静态的眼光看问题，觉得指标无效。

第三种情况比较抽象，举个例子，当我们度量技术债务时，发现虽然在版本1修复了大量的技术债，但版本2时技术债的点数并未因此减少，反而更多了。如果我们静态来看，这样的数据是不合理的。当我们动态来看，从版本1到版本2，存量技术债的点数会受哪些因素的影响呢？可能是版本2新引入了更多的技术债，或者随着时间的推移代码自然的更加腐化，亦或是新人不熟代码规范和技术架构，额外引入更多技术债……动态来看越修越多反而是合理现象了。

因此当我们分析指标值时，遇到合理或不合理的数据，都不用忙着承认它或否定它，进一步地分析都是必要的，找到数据背后的影响因素可能比数据本身更加重要。

4. 指标的价值不明确

在某些情况下，引入一个度量指标，更多的是为了度量而度量，想引入指标的人、实施的人、收集和消费数据的人，都不很清楚引入指标的意义。如果为了度量而度量，那么势必不会获得与成本相匹配的收益，最终就会流于形式，或维持一派虚假的繁荣，久而久之便无疾而终了。

5. 价值和用法未达成共识

还有些情况下，可能指标的价值、用法、资源等都不是问题，但团队并未共识，甚至实施者并不知道。初心赤诚，但却不为人知，最终也是不会获得良好效果的。在牵引团队时，良好的初始并不必然走向善终的结局，也有可能由于人心向背而误入歧途。

小结

我们讨论了引入度量指标可能会有的误区，思考引入的指标是什么，找到该指标适合团队的实施方式，共识其为团队带来的价值。整个过程应给团队带来正向的牵引。而好的管理者需要审慎的举措，促使大家彼此释放善意，带领团队走向我们想看到的未来。