软件质量度量实施中,最大的困难在哪里：软件质量度量的思考

各位大神，请教你们一个问题，领导认可统计的逻辑，但是想知道我们第一阶段应该达到哪个水平才能判断是好还是坏（容错率是多少）。应该怎么进行合理的拆解比较好（重点是领导自己也给不出一个划分的方向）

上下限，平均值。以均值为基础，逐步提升目标就好啊。不是规定上下限么，做一个过程能力分析看看分布在哪里？

有历史数据，我去除了最高值和最低值，然后求了一个平均值值。但是上下限应该如何定比较好？

这是近日群里一位朋友提出的问题。她们应该是公司质量同学，领导让她确定一个容错率的水平值。容错率，顾名思义，就是大家在软件开发过程中，会出现一些错误，只是每个人出错的概率不同而已。但如果每个错误都对员工进行处罚和批评也不合理，从持续改进角度，需要确定一个质量水平。也就是说，在容错率范围内的，可以认为是系统性波动导致的，不是员工个体差异原因导致的，这是管理系统的原因，就暂时不予追究员工个人，但是超出范围了，认为属于异常波动引起的，这时就需要对相关问题进行追溯分析、可能还会对相关人员进行追责。

上门有同学提到，通过计算过程能力方式，这个思路本身没什么错，也符合戴明的质量控制理论。但我们知道，过程能力，计算也需要知道上下限。

其实这里我认为有2种思路：

1、从统计过程控制角度--物理思维

大家如果看过 我之前文章，谈到 戴明 红蓝实验，这个实验很真实和简明的证明了，很多问题是由系统因素或者说共同原因导致，比如：

为帮助员工消除工作中的障碍；

管理不当；

未指出员工绩效差距在哪里，并给出改善建议；

等等。

在此共同原因作用下，员工即使努力工作也难免会出现错误。所以，我们可以让容错率达到管制状态，然后根据管制图的原理，确定上下限。处于管制状态下的数据，可以认为系统正常波动不用过度干预，如果超出，再进行分析和改善。

管制图原理

工序处于稳定状态下，其计量值的分布大致符合正态分布。由正态分布的性质可知：质量数据出现在平均值的正负三个标准偏差之外的概率仅为0.27%。这是一个很小的概率，根据概率论 “视小概率事件为实际上不可能” 的原理，可以认为：出现在3sigma区间外的事件是异常波动，它的发生是由于异常原因使其总体的分布偏离了正常位置。

2、从组织绩效管理角度

通过统计过程控制，有理论支撑、有数据支持当然很好，但有几个难点要做到

a、要消除系统异常原因，使系统仅仅受共同原因影响。所以，需要对现有的容错率进行分析，然后改善，让数据处于随机波动状态。但在软件行业，往往遇到问题可能是，业务变化和环境变化较快，想获得稳定系统，还是比较困难的事。

b、如何判断达到管制状态了呢？因为数据样本本身受限性，可能当前30个数据受管制，后面又超了。这时呢，可能需要从另一个实际维度来判定。

宋老师通常的判断方法是：

统计所有错误，进行分类（从不同维度，阶段、错误责任职能、主客观原因），如果从各个维度看每类错误的占比都差不多，处于比较离散状态的时候，基本可以判断系统是处于随机波动状态了。

但即使如此，估计领导可能还是不会满意。为什么？

从组织绩效管理角度，确定这个质量水平目的，肯定是希望鞭策做的差员工，奖励做的不好的员工。从而，激活组织的工作责任，提升工作质量。

如果管制状态，几乎所有员工出错率都在管制线内怎么办？

或者，超差的员工都是个别现象，起不到组织激励的目的怎么办？

所以，如果从这个角度看，统计过程方式可能就不太适用了。

所以，我给出建议是，按80%，原则。

对知识工作者，特别是软件研发人员，还是以激励为主。所以，我们应该讲80%人，都认为他们是符合岗位绩效要求的。然后，剩余 5%是较差的需要督促改进，15%，较好的要升职加薪予以鼓励。

这样即达到了，激励的目的，同时又可以督促各部门主管持续改善。关键，操作简单。

我相信这位同学应该可以很好的和领导协商出合适的上下限范围了。

我们回顾度量的目的：

1. 刻画（理解、发现问题、改进的目标）
2. 评估（期望与实际相比较）
3. 预测（由已知要素推算、估计其它要素）
4. 改进（识别问题、查找问题的根源）

度量远远不是定几个指标这么简单，度量模型设计应该考虑相关干系人的应用场景。

我们在设计度量方式以及使用度量数据给领导做判定和决策时，必须要理解如何应用这些数据，或者通过这些数据，领导需要用来做什么决策。

如果领导是希望，对公司整体的容错率水平，能可见、可预测，那么用统计过程方法就挺好；

如果领导目的是从组织绩效管理角度，那么可能用统计过程方法，就不是太适用的方式。

度量也是一个包含，人、流程、组织、工具的过程。