度量体系中的笨人、懒人和坏人

 

在试图建立度量体系的过程中，你一定遇到过各种各样的人。

 

一种是“笨人”，他们经常理解错误，不知道该度量什么和如何度量，而且经常弄错数据。你不得不深入项目进行解释，甚至亲手帮他们进行度量。他们甚至以学不会度量为荣，反复多次请你去帮他度量。

 

一种是“懒人”，他们试图说服你他们的项目如何与别的项目不同，以致于他们应该被置于度量之外，他们制造托辞的工作量甚至超过制作数据的。

 

还有一种是“坏人”，他们试图制作虚假的数据，利用你对项目不能深入了解这一障碍，蒙混过关。听说一家企业的 “坏人”隐瞒了实际的缺陷数据，产品被顺利发布，但却遭到客户投诉。

 

反观他们的教育经历，并没有修过《厚黑学》、《懒惰学》之类的边缘学科（实事上多数人连应有的项目管理学科都没修好，甚至从未学过），所以看来他们是到企业工作之后才学笨、学懒、学坏的。

 

度量利益链

 

    当一次度量活动过后，我们发现EPG如愿以偿地拿到了评估必须的数据，老板也对项目进度质量成本有所了解。惟独项目组，花费了大量时间进行度量，却所得甚少。有人说不是啊，至少项目经理也知道了进度质量成本的数据啊。可是，知道或不知道这些数据，项目延期、低质量、超支这些情况能改变吗？

 

    比如规模估算，众多用处中最重要的一个是可以推测出到客观的工作量和工期。但是企业有没有尊重这个由客观数据推测出的工作量和工期呢？多半没有。再加上项目组未必掌握了平衡进度、质量和需求范围的技能，所以最终也放弃了这个客观的数据。笨人们坐下来用10分钟讨论到底用10万行还是20万行代码；懒人们讨论都没讨论直接写下15万行；懒人中的一部分后来变成坏人，因为他们把最终结果写回估算值，并告诉你他们估算地挺准（真实的例子是：当多数项目都在为延期加班时，他们有的却达到了世界级的规模估算精度：±2%）。

 

    多数企业在建立度量体系前就要写月报、周报甚至日报来报告项目状态，现在又要增加一个度量报告（“还好”，多数企业只在项目结束的时候才需要）。当度量费时费力，而度量的主要执行人却不能从中获益的时候，“笨人”、“懒人”和“坏人”就诞生了。

 

防卫心理

 

    有家企业的“坏人”是这样被催生的：他们决定提高质量，方法是用测试缺陷数量进行绩效考核，结果大家可以猜到：开发组和测试组共同隐瞒了实际缺陷率。欧洲企业的工会势力强大，创建度量体系的时候他们会过问是否影响到绩效考核，目的是保护员工自身利益。国内的工会工作繁忙，保护员工自身利益的任务落到员工自己身上。一般无关紧要的数据笨一点懒一点就过去了，但涉及切身利益的事，不做“坏人”是应付不过去的。

 

    “度量什么改善什么”，这是度量界的至理名言了。多数情况下，企业都有绩效考核的机制。而把这个考核机制建立在量化的客观基础上，似乎是非常顺理成章的事情。无论领导、项目经理还是EPG组，都希望绩效考核是客观的，剩下的问题是：为什么好心办了坏事？

 

    另一种企业则在另外一个极端上：度量数据领导基本不过问（请问缺陷分类计数数据和COO有何关系？）。度量报告的最终读者是质量保证经理和主任评估师。

 

反思

 

     当笔者回顾自己的开发和项目管理经历时发现，自己非常幸运地只在研发型企业工作过。所以尽管工作也很繁忙，但在每个项目结束之后，还是有一些喘息的机会反思一下以往项目失败的原因（全部是失败的，因为没有一个项目同时是按期、高质量、如预算完成的）。虽然现在重新反思那些项目时发现，当年的反思所得实在浅薄，但因为这些反思，每一个新产品、新项目，都有超出前一次之处。从这一点上归类，还不算是太笨太懒的。

 

    有时候会遇到一些很累的项目经理，他们在近10年间管理了不下20个项目，但如果问到后期的项目和前期的管理方法有何不同，实在少之又少。问及项目失败的原因，则发现主要是客户不成熟、新人太多、老板出身销售不懂开发，还有一些则涉及国家体制改革，总之都是人力不可为的。

 

    由于缺少有益的反思，这类项目一般都处于“可重复级”：用基本相同的管理方法，不断重复失败。

 

    不依赖度量也可以进行一些反思，但是针对反思制定行动计划的时候会遇到困难。比如缺陷，造成缺陷的原因多达100多种甚至更多，除非进行度量分析否则很难找到消灭它们的有效方法。在一次度量分析中笔者发现68%的缺陷来自5种缺陷，其中17%来自自己最引以为豪的“函数入口数据检查”。这个发现及相应的举措使2.0版的缺陷率下降了一半。

 

度量信息需求

 

     很多人错误地认为：度量项的多寡取决于CMMI的级别，比如4级就应该比2级多很多。其实不然，度量项的多少取决于我们有多少问题是向数据要答案的。先来看看我们有几类问题，或者说度量信息需求。下面有一个简单的结构：

 

        项目外部问题

 

        客户满意度问题

 

        企业运营问题

 

       项目内部问题

 

       计划问题（前期）

 

         监控问题（中、后期）

 

         反思问题（结束后）

 

多数企业高层愿意把项目当作一个黑盒，也就是不愿意询问内部的事，但对外部影响还是非常关心的。比如高层会关心下面前2个问题，而不关心后2个问题：（一个不完整的例子）

 

         客户对这个项目的质量满意吗？（客户满意度）

 

         这个项目赚钱吗？（企业运营）

 

         项目的不同缺陷各有多少（缺陷分类计数）？

 

         项目成员每天在干什么（活动分类统计）？

 

很可惜，多数项目从来不度量前两个问题，所以高层不能从度量中得到这两个问题的答案，也就不会深入参与度量利益链条。

 

而项目经理，他们被迫地参与了度量过程，也提供了后两个问题的数值，但却不知道为什么要问这两个问题。另外缺少高层的过问，这两个数值最后如石沉大海，只有若干月后听说在CMMI评估中被列为强项。

 

所以很多企业的度量体系运行在一种不健康的状态：Sponsor不关心，主要执行人也不关心。注意他们只是对度量不关心而已，没有人会对上述结构中的5类问题不关心。高层和项目经理经常开会讨论这些问题，虽然很难达成一致认识。

 

保护“坏人”

 

    上面提到的在度量中无法得到利益与在度量中失去利益相比，还算好的。后者将催生“坏人”。

 

    好的度量结构和定义使企业团结如一人，共同对外。关键只有一点：面向客户满意度进行度量。

 

    与其定义内部的缺陷数据，不如定义外部的，比如：在交付后半年内，每千行代码的缺陷率（甚至非常主观的：投诉次数）。客户是不可控制的因素，永远不会“变坏”来造假数据。而且他们是项目的支付者，如果一个项目的质量好到让客户满意，也就足够了。

 

     当遇到质量差的项目时，互相推诿是没用的，无论责任是测试组测试不充分，还是开发组的产品质量天生太差，结果都是相同的：大家绩效考核得分都低。所以大家惟有一起坐下来分析一下：到底为什么质量差？虽然要达到畅所欲言的地步可能还差点，但是大家已经倾向于发现和报告真相，以改善绩效。

 

     另一个问题：只面向客户满意度度量吗？其他的度量项是为什么提出来的？

 

帮助“笨人”“懒人”

 

       质量差的原因很多，比如：

 

         测试不充分（覆盖不足、工作量不足、测试重点不对……）

 

         产品本身很差（编码缺陷很多、设计缺陷很多、需求缺陷很多……）

 

         工期太紧，没时间测试、做设计、做需求……

 

         新人太多，又没人指导

 

靠拍脑袋可以定位一些问题原因，但这些推论过程很可能不为人所接受，更可能被人驳倒。虽然大家都在一条船上受苦，但站出来承认让船搁浅的人是自己，无疑还是很难的一件事。如果大家都是“笨人”“懒人”，只能坐等而无所做为。

 

这时候你需要一些数据来做判断和决策。太多的问题，太多的数据，中间的对应关系可能是相当复杂的。忙乱中的项目组很可能根本没有喘息的机会来研究，是EPG大展身手的时候了。

 

还好现在已经有相当多的书籍、专题与此相关，很多咨询机构也提供度量体系建设的服务。相信“笨人”“懒人”们听说你是来帮助他们提高绩效的，应该不会无动于衷。所以我们不是一个人在战斗。

 

这中间要讲求一些方式方法，比如度量报告和日报、周报、月报的目的相同：提供信息。因此可以考虑合并。如果原来写N多文字的报告现在能用一张图来表示（如MS Project截图、EV图、Scrum中的Burn down图），而且这张图的生成速度只需要几分钟，“懒人”的惰性会变成一种动力。

 

DNV的一些欧洲客户是几乎从来不写文字报告的，他们定期维护一个由众多图表组成的多页面Excel文件，需要报告的时候，直接拷贝给上级。所有数据、历史都在上面清晰地记录在上面，不同的角色可以只关注自己的页面，超出阈值的数据被自动打上红框……不需要分析因为数据自己在说话，可谓大勤若懒。

 

小结

 

项目外部数据的合理定义，使“坏人”不能再隐藏坏消息，而是诚实地坐下来开始考虑对策。

 

项目内部数据的合理定义，使“笨人”学会了如何提升绩效，而“懒人”则发现了最快的工作方法，在更短的时间里做了更多的事情，使我们后悔曾把他们叫做懒人。