ASK MO第76期 | 如何给研发产品测试UI定度量指标

图片来源网络，侵删

正文共：2075字  预计阅读：8分钟

很多传统企业的 IT 团队都会被领导要求量化指标，最常见的就是：每千行 BUG 率，每页文档的 BUG 数，每天的代码行数等等。这种过程指标收集起来费时又费力，但是领导乐此不疲地让大家度量，并要求提高度量指标。

那为什么领导会如此乐此不疲地度量这些指标呢？其根本原因是在于：不是每个团队都能比较好地度量业务指标。

比如卖手机的销售团队，他可以说我去年卖了1000万台，今年怎么样也能卖个1200万台，那今年的1200万台就是我的业务指标。对于运营团队来说，去年卖了1000万台，我烧掉了200万的运营费用，如果今年卖1200万台，我仍然只烧掉了200万的运营费用，销售额增加，运营成本减少，那么我为公司做出的贡献就是增加了公司的利润率，这就是我的价值。

这是典型的比较好衡量的团队。但是对于研发，产品，测试，UI 团队来说，度量指标的确不太好度量，这是为什么呢？

因为他们都是成本部门，对于成本部分的度量来说，公司多采用“多快好省”的方法来度量。

“多快”就是效率是不是变高了。

“好省”就是质量是不是提高了，问题是不是减少了，成本是不是降低了？

好省还比较好衡量，可以直接由财务方法得出来，就是是不是用更少的人员，用更低的费用，完成了一样的事情。

但效率就不是那么好衡量了。毕竟IT 团队不像是生产线上的工种，按件计费。软件开发本身就是智力的结晶。比如一个流水线的员工，今天拧了多少颗螺丝是可以很直观地看出来的，一天能拧500个是达标，600个是优秀，这样的结论很好得出。因为螺丝是标准品，大小一样，复杂程度也是一样。

软件生产就不一样了，每天写得不一样的功能，用着不同的代码，可能一个高手10行代码就可以写出一般人100行代码做的事情，而且算法而简单。

如果这样的话，是不是就没有办法去度量研发，产品，测试，UI 的价值了呢？

比如要度量一个IT 产品，我们可以通过三个大的纬度得出来：速度，质量和价值。

1、速度包括两个能力：需求响应能力和发布能力。

需求响应能力又包括业务需求前置周期，和用户故事交付周期，前者指的业务需求提出到被排入开发的时间。后者指的是用户故事从提出到完成交付的周期，这些周期是越短越好。发布能力包括集成测试周期和发布频率、还有解决发布问题的平均时间时长。集成测试周期指的是一次集成测试从搭建环境开始到被测试完成的所有时间，发布频率指的是多久进行一次发布，解决发布问题的平均时长指的是发布完成后，外网问题产生到修复的时间。这些时间是越短越好。

2、质量包括：内部质量和外部质量。

内部质量包括单位周期的遗留缺陷数和用户故事的缺陷数。前者指的是一段时间在内部的遗留缺陷个数，为什么会有这个指标呢，是因为软件不可能是毫无缺陷的，一般软件的小问题在发布中是可以容忍的。后者指的是缺陷是由某个用户故事引起的，我们只需要计算一次发布的时候，用户故事会产生多少个缺陷。外网质量就是一个系统的年平均故障率。这是系统稳定性指标，是指一年的故障时间除以系统总运行时长。

3、价值包括：需求吞吐量和交付有效性。

需求吞吐量体现在单位时间内交付的业务需求数，比如我两周发布一个版本，那两周我能交付多少业务需求呢？这里注意，需要把需求进一步细化，最好需求的粒度差不多。交付有效性性体现的业务的需求价值，这里可以设置直接价值和间接价值。直接价值包括收入，活跃，留存等数据，间接价值可以通过用户行为数据来度量，比如我们做交互优化，用户在高频使用的步骤或者时长的减少，用户对于软件使用的投诉减少等等。

但是，最后莫老师提醒，这些度量指标是要综合在一起看的，从单一的指标来衡量的话，很容易导致走偏，就是你想度量什么，团队能给你做出来什么，比如你要解决发布频率的问题，那么团队就一次发布只做一个功能就行了。这样原本的度量就变味了。

IT 团队度量，你学会了吗？你还想到有哪些度量项呢？欢迎留言讨论。