你是项目经理,被客户问本项目可否在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最佳实践用起来,对项目、公司都会有极大的帮助。