如何避免做了也白做的困境，来看看度量的起手式

你度量什么，你就能得到什么？

如果我关注产品交付质量的话，那是不是直接度量线上缺陷不就可以了？

真的是这样。

你度量开发人员每天的代码量，就会得到越来越多的......（垃圾）代码。那如果要度量线上缺陷，会不会得到更多的线上缺陷？

首先是不会的，线上缺陷是一个负向指标，此类指标的度量通常会得到越来越少的.....线上缺陷。这也是做此类指标的初心，通过这个指标来牵引团队来持续改进。

不过现实中呢？通常“正常”的团队都首先会去关注线上缺陷的定义，哪些缺陷可以不纳入线上缺陷范畴，其次通过在研发过程中彼此心照不宣地去报告各种bug以做大分母，又或者是用需求、代码行增量等指标来做分母以实现所谓的合理性。

因为背后的数学公式很简单，

假设有99个缺陷和1个线上缺陷，那么缺陷逃逸率就是1%。而好巧不巧如果又发现了一个线上缺陷，那团队为了维持之前的逃逸率目标，就得额外再找99个缺陷来填到分母上。那是不是去和运维探讨一下这个新的是不是线上缺陷更为简单直接 ？

那么我们做度量是为了什么？其实是高质量的交付，而不是线上缺陷本身。

线上缺陷是一个结果指标。结果指标只告诉你结果。That‘s it。

业界有位同行曾经发圈感慨，“当团队在忙得焦头烂额的时候，'你'除了给团队开不符合项，还能做些什么？”团队需要的不是你告诉他们有几个线上缺陷，团队需要的是，有一套行之有效的软件工程方法论，用于指导研发交付过程，以提高取得最终的好的结果的可能性。

高质量交付的这个结果，都是一个个研发过程的细节所构成的。

在阅读了何勉老师等组织编写的《BizDevOps白皮书》之后，笔者发现关于度量的部分，各位专家老师们也提出了类似的问题，并给出了如下的方案模型。

DORA或者通常的度量方案主要会关注交付效能指标，并部分涉及业务结果指标。

“这个上面的三类指标中，越靠右边的是越外部的，接近想要的结果；越靠左边的是越内部的，指向需要改进的行动。”但是右边的指标无法直接知道团队改进。

因此，作为对于团队的来说，高质量交付是通过团队和个人的行为以及能力所达成的。而团队和个人的行为，例如：工程习惯、协作方式、需求并行度、代码评审质量等；也包括技术和工程能力，如：代码质量、架构耦合、测试覆盖率、发布成功率等。这些指标与最终业务目标之间不存在必然性，应为中间存在转化，但是就如前述而言，其中的有些行为和能力会影响交付效能，进而最终可能会影响业务结果。

高质量交付的过程逻辑

因此，作为初始投资度量，希望得到收益的团队，笔者的建议是应该优先关注最左侧的行为和能力指标。通过度量过程是否在遵循最佳实践去保障好的结果。

也就是说，瀑布、敏捷、精益、DevOps这一路走来，软件工程其实一直存在许多朴素的所谓最佳实践。而度量首先要做的，也就是去看团队是否在遵循这些最佳实践，以及遵循的程度。

拍拍脑袋随便想想，就会有如下的一些点

根据上述描述，一些努力一下还比较好实现的度量指标如下，