度量信息需求
很多人错误地认为：度量项的多寡取决于CMMI的级别，比如4级就应该比2级多很多。其实不然，度量项的多少取决于我们有多少问题是向数据要答案的。先来看看我们有几类问题，或者说度量信息需求。下面有一个简单的结构：
项目外部问题
客户满意度问题
企业运营问题
项目内部问题
计划问题(前期)
监控问题(中、后期)
反思问题(结束后)
多数企业高层愿意把项目当作一个黑盒，也就是不愿意询问内部的事，但对外部影响还是非常关心的。比如高层会关心下面前2个问题，而不关心后2个问题：(一个不完整的例子)
客户对这个项目的质量满意吗?(客户满意度)
这个项目赚钱吗?(企业运营)
项目的不同缺陷各有多少(缺陷分类计数)?
项目成员每天在干什么(活动分类统计)?
很可惜，多数项目从来不度量前两个问题，所以高层不能从度量中得到这两个问题的答案，也就不会深入参与度量利益链条。
而项目经理，他们被迫地参与了度量过程，也提供了后两个问题的数值，但却不知道为什么要问这两个问题。另外缺少高层的过问，这两个数值最后如石沉大海，只有若干月后听说在CMMI评估中被列为强项。
所以很多企业的度量体系运行在一种不健康的状态：Sponsor不关心，主要执行人也不关心。注意他们只是对度量不关心而已，没有人会对上述结构中的5类问题不关心。高层和项目经理经常开会讨论这些问题，虽然很难达成一致认识。
保护“坏人”
上面提到的在度量中无法得到利益与在度量中失去利益相比，还算好的。后者将催生“坏人”。
好的度量结构和定义使企业团结如一人，共同对外。关键只有一点：面向客户满意度进行度量。
与其定义内部的缺陷数据，不如定义外部的，比如：在交付后半年内，每千行代码的缺陷率(甚至非常主观的：投诉次数)。客户是不可控制的因素，永远不会“变坏”来造假数据。而且他们是项目的支付者，如果一个项目的质量好到让客户满意，也就足够了。
当遇到质量差的项目时，互相推诿是没用的，无论责任是测试组测试不充分，还是开发组的产品质量天生太差，结果都是相同的：大家绩效考核得分都低。所以大家惟有一起坐下来分析一下：到底为什么质量差?虽然要达到畅所欲言的地步可能还差点，但是大家已经倾向于发现和报告真相，以改善绩效。
另一个问题：只面向客户满意度度量吗?其他的度量项是为什么提出来的?
帮助“笨人”“懒人”
质量差的原因很多，比如：
测试不充分(覆盖不足、工作量不足、测试重点不对……)
产品本身很差(编码缺陷很多、设计缺陷很多、需求缺陷很多……)
工期太紧，没时间测试、做设计、做需求……
新人太多，又没人指导
靠拍脑袋可以定位一些问题原因，但这些推论过程很可能不为人所接受，更可能被人驳倒。虽然大家都在一条船上受苦，但站出来承认让船搁浅的人是自己，无疑还是很难的一件事。如果大家都是“笨人”“懒人”，只能坐等而无所做为。
这时候你需要一些数据来做判断和决策。太多的问题，太多的数据，中间的对应关系可能是相当复杂的。忙乱中的项目组很可能根本没有喘息的机会来研究，是EPG大展身手的时候了。
还好现在已经有相当多的书籍、专题与此相关，很多咨询机构也提供度量体系建设的服务。相信“笨人”“懒人”们听说你是来帮助他们提高绩效的，应该不会无动于衷。所以我们不是一个人在战斗。
文章来源于领测软件测试网 https://www.ltesting.net/