在试图建立度量体系的过程中，你一定遇到过各种各样的人。
一种是“笨人”，他们经常理解错误，不知道该度量什么和如何度量，而且经常弄错数据。你不得不深入项目进行解释，甚至亲手帮他们进行度量。他们甚至以学不会度量为荣，反复多次请你去帮他度量。
一种是“懒人”，他们试图说服你他们的项目如何与别的项目不同，以致于他们应该被置于度量之外，他们制造托辞的工作量甚至超过制作数据的。
还有一种是“坏人”，他们试图制作虚假的数据，利用你对项目不能深入了解这一障碍，蒙混过关。听说一家企业的 “坏人”隐瞒了实际的缺陷数据，产品被顺利发布，但却遭到客户投诉。
反观他们的教育经历，并没有修过《厚黑学》、《懒惰学》之类的边缘学科(实事上多数人连应有的项目管理学科都没修好，甚至从未学过)，所以看来他们是到企业工作之后才学笨、学懒、学坏的。
度量利益链
当一次度量活动过后，我们发现EPG如愿以偿地拿到了评估必须的数据，老板也对项目进度质量成本有所了解。惟独项目组，花费了大量时间进行度量，却所得甚少。有人说不是啊，至少项目经理也知道了进度质量成本的数据啊。可是，知道或不知道这些数据，项目延期、低质量、超支这些情况能改变吗?
比如规模估算，众多用处中最重要的一个是可以推测出到客观的工作量和工期。但是企业有没有尊重这个由客观数据推测出的工作量和工期呢?多半没有。再加上项目组未必掌握了平衡进度、质量和需求范围的技能，所以最终也放弃了这个客观的数据。笨人们坐下来用10分钟讨论到底用10万行还是20万行代码;懒人们讨论都没讨论直接写下15万行;懒人中的一部分后来变成坏人，因为他们把最终结果写回估算值，并告诉你他们估算地挺准(真实的例子是：当多数项目都在为延期加班时，他们有的却达到了世界级的规模估算精度：±2%)。
多数企业在建立度量体系前就要写月报、周报甚至日报来报告项目状态，现在又要增加一个度量报告(“还好”，多数企业只在项目结束的时候才需要)。当度量费时费力，而度量的主要执行人却不能从中获益的时候，“笨人”、“懒人”和“坏人”就诞生了。
防卫心理
有家企业的“坏人”是这样被催生的：他们决定提高质量，方法是用测试缺陷数量进行绩效考核，结果大家可以猜到：开发组和测试组共同隐瞒了实际缺陷率。欧洲企业的工会势力强大，创建度量体系的时候他们会过问是否影响到绩效考核，目的是保护员工自身利益。国内的工会工作繁忙，保护员工自身利益的任务落到员工自己身上。一般无关紧要的数据笨一点懒一点就过去了，但涉及切身利益的事，不做“坏人”是应付不过去的。
“度量什么改善什么”，这是度量界的至理名言了。多数情况下，企业都有绩效考核的机制。而把这个考核机制建立在量化的客观基础上，似乎是非常顺理成章的事情。无论领导、项目经理还是EPG组，都希望绩效考核是客观的，剩下的问题是：为什么好心办了坏事?
另一种企业则在另外一个极端上：度量数据领导基本不过问(请问缺陷分类计数数据和COO有何关系?)。度量报告的最终读者是质量保证经理和主任评估师。
反思
当笔者回顾自己的开发和项目管理经历时发现，自己非常幸运地只在研发型企业工作过。所以尽管工作也很繁忙，但在每个项目结束之后，还是有一些喘息的机会反思一下以往项目失败的原因(全部是失败的，因为没有一个项目同时是按期、高质量、如预算完成的)。虽然现在重新反思那些项目时发现，当年的反思所得实在浅薄，但因为这些反思，每一个新产品、新项目，都有超出前一次之处。从这一点上归类，还不算是太笨太懒的。
有时候会遇到一些很累的项目经理，他们在近10年间管理了不下20个项目，但如果问到后期的项目和前期的管理方法有何不同，实在少之又少。问及项目失败的原因，则发现主要是客户不成熟、新人太多、老板出身销售不懂开发，还有一些则涉及国家体制改革，总之都是人力不可为的。
由于缺少有益的反思，这类项目一般都处于“可重复级”：用基本相同的管理方法，不断重复失败。
不依赖度量也可以进行一些反思，但是针对反思制定行动计划的时候会遇到困难。比如缺陷，造成缺陷的原因多达100多种甚至更多，除非进行度量分析否则很难找到消灭它们的有效方法。在一次度量分析中笔者发现68%的缺陷来自5种缺陷，其中17%来自自己最引以为豪的“函数入口数据检查”。这个发现及相应的举措使2.0版的缺陷率下降了一半。
文章来源于领测软件测试网 https://www.ltesting.net/
