上一篇分享提到,管理层的支持很重要,V2.0专门增加了治理 (GOV) 与 实施基础 (II) 这两个PA,因若要过程改进成功,公司必须有管理层的支持与系统支撑。
这道理大家都懂,但我看国内真正做到的公司很少,为什么?
刚刚中秋节当天,与一香港公司几位高管做CMMI项目启动前交流。会议后,我更了解过程改进的成功要素。
大家可从以下分享可了解,推进过程改善预先必须考虑哪些问题:
目录
-
1为改进交流打好基础
-
2从公司的改进目标开始
-
3投资与回报
-
4利用系统收集数据.挖掘改进机会
-
5对CMMI的误解
-
6项目管理系统
-
7如何获得CMMI预算
-
8总结
-
9后记
-
10一资深顾问对这文章的反馈
为改进交流打好基础
他们与会共有5人,包括IT主管(他曾在IBM工作过很久,是非常有经验的人士);下面还有管研发、管项目管理(PMO),不同领域的负责人,他们行业经验都在20年以上。
简单介绍后,我便打开一张幻灯片(如下图)
我问:你们知道图上的T和G分别是哪家公司?
研发主管很快回答:T公司是丰田,G是通用。
从这里我很开心了解到,这帮高管确实很有经验,都很熟悉“丰田故事”,持续改进思路。
我接下来跟他们说:丰田大野内一和改善(Kaizen)
改良 vs 改善
|
我说:你们都很清楚,从5、60年代到今天,丰田很成功地利用PDCA不断完善的管理模式,提升到世界第一。在CMMI刚出现时,美国很多软件开发项目,延误、超支或失败,所以CMMI的核心思路是在软件开发中不断改善。
我问:你们觉得这个思路可以用在贵公司的改进吗?
他们都很认同。
有了认同这个管理思路的基础,我们继续讨论如何实实在在做好CMMI改进。
从公司的改进目标开始
大家有了改进的概念,我就问IT主管:你们有什么改进目标?今年或者明年有什么公司的提升目标?
他说:希望可以更好控制项目的延迟与成本。
我说:好,我们现在是什么水平?
他没概念。
我说:首先你们需要有度量来收集一些客观数据,针对现在团队的生产率——软件开发很多主管都希望知道,但却不清楚。因为软件开发和其他生产工业不同,产出物是看不到的,比如你看到200人的开发团队好像每天都埋头努力工作,但(如公司没有项目管理系统)是无法知道他们真实效率如何。
主管说:这也是我常常问下面主管的问题,但一直没有获得答案。
我说:这些都是应该依据一些客观数据,不仅仅是依靠项目经理来汇报。 ‘度量系统’就是能帮助你了解不同团队之间的效率如何?生产率如何?
投资与回报
IT总监说:好,请问有没有什么资料说做了CMMI后,回报多少?或者有什么数据证明所获得的好处?
我说:以前在SEI的时候是有的,就是以下这图,比如从抽样的项目,回报(ROI)平均大概是4:1
我在国内极少遇到以上问题。 |
其中一位经理补充说:我以前老公司的CMMI经验是:人员/资源投入不少,内部人员的投入远远大于给顾问的费用。
我说:你们要预算好内部和外部成本,如果没有预留充分资源,很难做好。但在做预算时要注意,很多我们做改进的工作量,其实不应算在CMMI预算里,因为平常工作也要改进,应是工作的一部分。但若是为了做CMMI需要参加的额外培训,准备文档证据的时间等便应算在预算里。
他们都赞同。
利用系统收集数据.挖掘改进机会
接下来我跟他们分享一个故事。
我以前分享过的一个关于瀑布开发的问题,如我所料,他们大部分的缺陷是在验收和测试阶段才发现,前面的单元测试和评审的发现很少,或者早期做相关测试但没记录。
研发经理说:我们有个大型的政府部门项目,在UAT期间,验收测试发现的缺陷数超过2000个。 我就问他,是否可以把一些前期的评审和单元测试做好,以减少后面的缺陷呢?
研发经理回应说:理论是可以,但是这个项目不一定有效,因为这个项目时间很长,中间客户方的经理换了4、5位,每个人的需求基本都推翻前一位项目负责人的需求。
我想了想,回应说:我们工程说要有度量数据统计,如果以前统计过不同项目的延误跟缺陷,那么就可以建立公司的基线,知道哪些客户他的项目成本、人员比其他公司高,下次接他的项目的时候,就可以预留一些空间,才能有信心保证项目不亏损。
IT总监说:我们做乙方有个好处,跟做IT内部不同,内部是不可以选择客户来提供服务。但是做乙方的话,如果确实从历史数据看到客户的工作量很高,导致项目不赚钱,下次再有投标,就可以预留更好地预算空间,甚至不参加投标,避免亏损。
对CMMI的误解
很多第一次接触CMMI的经理都会误解,以为CMMI有一套标准过程,只需要照着去做,就可以达到CMMI的成熟度。 这位很有经验的总监虽然曾是IBM的员工,但也有这个误解。
我说:CMMI为了满足不同企业,会依据不同的客户需要和团队的特性,有不同的过程,为了使CMMI可以在不同环境使用——从严谨的军方项目到快速的敏捷项目,所以CMMI模型必须是一个比较高的框架,才可以有这个灵活度,使得无论严谨还是快速,都可以用上。
开始的时候,这总监觉得很诧异:为什么没有一套已经建议好的做法。
我接着说:其实每个开发团队,无论他用什么模式,自己肯定都有一套常用过程——虽然不一定是写出来的。所以我们第一件事不是把一些外面的过程强加给他们用,而是要理解他们现在的过程,及如何匹配CMMI的最佳实践,利用其中的差异,找出改进点。整个过程也需要团队的参与。 例如下面的三角图——一个成功的改进必须有模型、培训、咨询和工具的相互配合,才能成功。
单靠培训和工具配合,可不可以?
评估的作用就类似于小孩学钢琴——如果没有每年的考级目标,就很难主动天天练琴。
这个企业比较注重项目管理的一些改进跟监控,所以后面我们就讨论到,不同的项目管理工具也要配合到过程改进来用才会有效。
项目管理系统
我说:根据你们希望完善项目延误、控制项目成本的目标,最好可以借CMMI项目引进项目管理系统。
其中一位经理说:是的,我的老公司也是使用一套项目管理系统,要求每个团队定期填工时表,这样管理层就可以和财务可以及时知道实际的项目情况。
我说:对的,因为我曾帮你们老公司做了10多年的CMMI过程改进,清楚他们那套系统可以体现很多CMMI项目管理和监控的最佳实践。
如何获得CMMI预算
IT总监问:应如何做好整个CMMI过程改进的预算,更好说服董事会,获取批准。
我说:我没有这方面的金科玉律,但可先回顾之前项目因为缺陷而返工的损失是多少?比如刚才你说的有些大型项目UAT 缺陷有超过2000个,你可以估算这些缺陷带来的不必要的工作量、返工量是多少?成本是多少?然后就可以以这些成本的1/10、1/5作为CMMI的预算。
同样除了返工缺陷,也可以估计以往因为项目的超时延误导致的额外项目成本,虽然CMMI改进不可能完全消除,也可以作为CMMI预算的参考。
总结
有些管理层不了解过程改进的原理,以为是一套最佳实践过程。 以为只需套用一些顾问给的模板便会有效。
有些不相信过程改进改善能帮公司提升, 不希望改变以往的管理模式。
有些更可能是只把CMMI过程改进视为一个认证,希望以最小的投入,只要能通过评估便可。 没有对内部人员投入的成本预算与相关自动化系统的预算。
以上都是很多公司未能真正从CMMI过程改进获益的主因,也是为什么国内很少过程改进成功的原因。
公司要做好 治理(GOV),不仅仅单靠高层口头的支持,如没有资源投入,改进便只是梦想。
后记
刚刚在中秋放假前,我为另外一家公司专门做测绘业务的公司,准备CMMI评估。因为软件开发只占公司业务的一小部分,很多软件开发的实施都没做好,例如配置管理、评审、单元测试等。
第一次到客户现场,我都要求先与发起人(总经理)会面。 这位总经理行业经验也很丰富,精通测绘业务,对我说他们行业从以前的手工为主到现在越来越依赖软件。
我对发起人说:很感谢你抽空过来,CMMI过程改进都是从公司的商业目标出发,所以想先了解你对现在公司的软件开发有什么要求?觉得有什么不足?
他说:在我们项目中很多是需要软件集成硬件,软件只占一部分,从我看来我们软件没有什么问题。
我再问:有没有一些你希望做的更好的地方,或者现在有什么不足需要改进?
他想了想,回应:确实没有,都挺好。
从这个简单的对话,我就了解,我后面要他们下面做什么改进都不会有效果,因为高层根本不了解过程改进,也没有这个意愿。
这让我回想到几个月前,有个总监说过,他下面有一些管软件团队的经理本身不是软件开发出身,所以不知道软件开发对测试质量的重要性,所以分配到测试的人员很少。
所以管理者的想法以及认同很重要。
一资深顾问对这文章的反馈
以下是我对当前国内大多数软件公司实施相关内容的看法;
国内软件公司大致可按成熟度分为A B C三类:
A类--有大量项目实施积累,有基本的项目管理方法; 对体系的接受度比较高,容易对照模型的指导找差距,也可以根据已积累的实施数据、经验快速进行改进,对于改善的目标较为明确,改善方案的推进较为顺利。一般这类公司高层的配合度也较高,有了较多项目的实施积累,高层对于项目管理、质量、痛点的解决这些目标都比较清晰,目标分解、实施皆较为易行,项目成本测算较为精细。 B类--有一些项目实施积累,项目管理方法还在摸索中; 有较多项目实施上的痛点,但是在项目管理和实施方法上迫切需要有人指导,对于度量、改进的推广略有难度,需要先培训,梳理缺漏过程,建立基础的体系标准(基础项目实施要求),然后再逐步提升、优化。这类公司的高层迫切希望提升客户的满意度,提高项目实施过程的规范性,减少售后支持的压力,项目成本测算较为粗放。 C类--项目实施积累较少,暂无项目管理方法(以快速完成项目获取利润为目标)。 公司处于上升期,亟需赚取利润维持企业运转,故公司高层大多关注于工期的缩短、成本的降低和客户关系的维持,在体系的建设和过程管理的改善上没有太多的目标要求,较多为为了获取更多的合同而进行体系认证。体系过程改进的推广较为困难。 |
三类公司共同点:
公司需要如实反映当前项目的实施现状,提出项目实施的痛点,便于咨询人员协助进行过程实施分析,共同提炼出过程改进的目标,商讨过程改进方案,然后进行PDCA实施。
在实施过程中,我们必须了解不同层次的干系人对过程改进的关注焦点及期待,例如:
-
公司高层的关注重点:
-
是否能够实时了解各产品实施成本、实施平均周期及质量现状
-
是否可以降低成本(产品售前成本、项目实施成本、售后维护成本、管理成本、其他成本--如房租、福利等)
-
是否可以提高产品质量,进而使客户满意
-
是否有利于关键项目团队及内部人员的稳定
-
是否可以增强竞争优势,从而促使商业目标的实现
-
-
项目经理的关注重点:
-
是否可以加快项目进度,进度可控
-
是否有助于提升产品质量
-
是否有助于降低人员的流动性
-
是否有助于提升项目实施效率、降低实施风险
-
是否有助于项目成本的降低
-
是否有助于提升个人技能及在团队中的威信力
-
-
团队成员的关注重点:
-
是否有助于提升工作效率,减少加班
-
是否有助于提升产品质量
-
是否有助于提升个人的管理、工具使用、技术应用等能力
-
因必须获得各层次干系人的支持,过程改进才有机会成功。而基于客观数据的沟通起关键作用。