你是项目经理，被客户问本项目可否在10周内完成?

如果你公司有收集以往类似项目数据，分布如下:

你便可以跟客户说:"从我们类似项目的历史经验，

以现在的人手配置，能在10 周内完成的机会小于15%。

估计要12周时间才可完成。

但很多公司没有收集以往的项目数据，项目经理对客户的时间要求只能说尽力完成，最终很可能导致项目组人员大量加班，质量也不好。

这个案例我们探索公司要量化管理，要具备什么要素。

高层支持

每次我做过程改进培训互动练习，与大家分享过程改进的最重要概念时，都会提是否得到高层的支持很重要。

60年前，丰田开始改革时，主推人大野耐一 也是有高层（丰田家族）支持，丰田才能成就今天的世界第一。

我们公司要走向量化管理持续改进，也需要有高层的支持、理解和推动，绝不可以是由下面的工程师从自己团队试验，希望由此扩大，再影响整个公司。

如果管理层缺乏改进的决心和持续地推动，便容易半途而废。

因为要任何人改变自己的做事风格是非常难的，没有高层的坚持，这些新的改进、变化很快会被反对的人推翻。

以下案例：一家发展不错的公司，从领导对数据的重视而引发整个公司往量化管理方向的持续改进。

刚给一家公司做完CMMI评估，这家公司发展得很快，3年前员工数量才不到一千，现在已经达到2000多；原本只有1个主打的产品，现在已经在3、4个主要产品全国推广；且服务客户方面做得相当不错。

我问研发的主管：过去有没有主要客户丢失?

答：说一个都没有丢。最近他们在一些新领域获得中标，对手都是大型上市公司。

这位研发总经理在我们评估结束后，与我说：CMMI这套量化管理的思路，其实与公司大老板的要求很配合。

我问：为什么？

答：大老板是数学专业出身， 对数字很有要求，为了满足他的信息要求，要准备各种数据。

其中一位女经理已经被大家开玩笑地称为“表姐”，因为她每天要做很多表格、表单。

大老板的要求很简单——不要求你立马有什么非常突破的提升，但是要让看到 （从数字上)业务、能力等、团队在不断提升。

这与我们在持续改进中常常提到的丰田故事相通。

丰田汽车对质量要求很高，最终目标是不希望有任何的缺陷和库存，这个几乎是一个无法完成的目标。但是每个事业部和团队会依据这个目标评估现在处在什么水平，制定未来3个月，6个月的目标。

这位研发部总经理说有一次大老板问他：你们团队现在的生产率是出于什么水平，跟行业如何比较？

因为他一直没考虑过这个问题，所以没答上。反思后觉得大老板的这个问题很有道理，作为一个部门主管应该随时可以回答。

我们做CMMI过程改进就是要提升团队和部门，依据实际关注的指标，收集数据，建立基线和标杆，如果一直有做这件事，上级问的这个问题就可以回应了。

研发总经理说，市场变化和业务增长都很快，公司架构上也做了很多重组，让每个事业部尽量更独立去服务好客户，得到好成绩，他说大老板另外一方面也很注重整个公司的质量标准，所以公司的QA部门很有资源和影响力，管理层可看成是QA，是公司重要的柱子，支撑整个事业部的发展。道理很简单，每个事业部都可以按照自己市场的需要，想尽办法拓展市场，降低成本，但是绝不可以不遵守公司的质量标准，万一出了问题，整个公司的品牌就会受到影响，这个会远远超过事业部的得失。

我说确实很多公司为了求快而不注重质量，例如最近的波音737，去年三星的Note，都是我们知道的典型例子。

注重新员工培训

从3年前第一次接触这家公司，我就发现他们在新员工入职培训的力度和精力上投入很大。每个新员工入职都要经过一个不少于5周的集体培训过程，禁止让新员工为了事业部的紧急需要立马就投入项目中。整个培训由企业的全职老师负责，但课堂培训便要5周，除了进行笔试外，还要小组做小项目，最后还会公布成绩。

其中一些项目经理就特别认同公司的这个做法，确实感觉到经历了正式入职培训的员工与没有经历的差异很大。

这个对培训的要求，形成了整个公司的文化——项目都会依据一个成熟的方法来做，不会只依赖每个人的喜好来做，比如为了保证交付产品的质量，质量部从一年半前就开始推动一个静态代码检验的要求，所有的代码都要把那些重要缺陷修复好，才可以做后面的测试。

实际也证明实施了严格的静态代码检测后，降低了交付后的缺陷率。

量化管理之旅

这位研发中心总经理在吃饭时问我：接下来您建议我们如何继续做好量化管理？

我答：我在最后的评估报告中也提到，可以针对缺陷的数据做分析、提升。从现有缺陷分析后面遗漏的缺陷来自什么阶段和原因，针对性避免。要制定不同阶段技术评审的评审方法，包括最严谨的同行评审或简单的走查。项目团队应依据质量情况、实际需求，制定一个详细的质量计划或技术评审计划，对某个阶段、某个模块，如何有效进行评审，也要定一个找出缺陷的目标。

这总经理立马说:我赞同评审的重要性，我们做评审不是走形式，如果一个需求没有评审过，很多问题会遗漏到后面。所以你这个建议很好。

我说：质量的重点是要确保质量不是靠后面测试来防止，因为被测试人员找到已经是事后，最有效是自己做事的人在当时的阶段立马就找出缺陷并解决，防止后面返工。

这个道理大家都懂，但是有些管理者觉得这种评审太耗费人力物力，不如先做，后面有问题再修改，对于这种想法的公司或管理者，我就问他，你算算以往的项目有多少问题是到最后客户用的时候才暴露出来？

如果你算一下就会发现，公司用于这种返工的成本绝对不会少。

我有个采矿的客户在听了我说了的这个道理后，就说确实自己公司就是这样。因为开发对象都是大学中的研究人员，他主要是先把软件做出来，没有太多精力花在评审或测试，导致后面用于出差、维护的成本确实不少，很多项目如果算起来就变成了亏本。

公司的总经理说：现在很多汇报人对质量的注重性不够。例如今天下面的人汇报了一个数据表，可能他都没自己详细查过，我一眼就看出错误，但是他还坚持说没有问题，没有错。 所以这就是由于缺少评审，导致很多潜在的缺陷会遗漏到自己上司或客户那边，造成影响。

研发中心总经理在我们发布的时候跟所有的同事说，我很赞同刚才老师分享的概念，我们公司要做量化管理，不需要每个项目经理或成员都是统计学博士，详细的分析可以让一些技术人员帮你做，但是项目经理要懂得如何利用数据更有效管理好项目，这才发挥到真正量化管理的意义，这个也是我们管理层很希望看到的。

最后我依据这个分享了谷歌的故事.

不听'河马'指挥

2000年时，谷歌重大的决定都需要有充分的数据、理据支撑，对于那些高层、希望依赖自己的权利来推动一些他的做法、思路，在谷歌称之为河马Hippo(Highest Paid Person's Opinion)。

有一次一个部门的SVP希望推一个互动，需要研发资源，但是研发的负责人不同意，这个SVP也觉得自己地位高，但是也不能硬推，所以尝试在会议说，我们做个试验，你把一半的资源投入进来，另外的一般仍按你原来的做。但是研发经理觉得SVP想法本身没有依据，也不信会成功，还是拒绝。所以说明在谷歌不是你权威高，你的话就有用。正是如此的文化，谷歌才出了这么多创新的公司。

在谷歌开会都会用2个投影仪，一个是平常交流用，一个是投相关数据，从这个可以看到，这个他们多么注重实际的数据。

所以我说，既然大老板这么注重数据，大家有这个环境真正推动公司级的量化管理。

吃晚饭时，跟一个参加的项目经理聊天。

她很满足地说：我现在的项目就用上你教我的东西：

（依据事实）讲故事

因为我们在评估过程中，要求他们把曾经的项目，按CMMI一条条写出来。这个过程让他们能很清晰回顾自己过去的项目如何对应CMMI的最佳实践。

WBS（任务分解）管理

她刚接手，发现这新项目的估算不太合理，于是用学过的任务分解，把具体所做的任务一一列出来——需要什么人？需要具备什么能力？就发现本来的计划不合理。以前没有这种系统的想法，只会按客户的想法硬着头皮来做，经常加班，效果也很不好。

所以他最后开心地说: 正如丰田的七个习惯之一"以忙碌为耻"，应尽量不加班才是算是把项目做好。

我们都笑了。

从这个案例我们知道，当一个项目经理能真正把CMMI最佳实践用起来，对项目、公司都会有极大的帮助。