|
1对模型研究不够深入 模型是多年软件工程经验的总结,里面的每一句话,每个例子都不是随便写上去的,都有其内在的含义在里面,需要仔细琢磨,仔细体会。作为EPG的成员,在遇到问题时,首先要做的事情是要去读模型,在模型中查找答案。市面上所有翻译的中文资料都不准确,所以要去读模型原文,以免以讹传讹。在读不懂的地方应该去读SW-CMM与SE-CMM,从那里获取类似的描述,如果还读不懂,可以去网络上搜索资料,与朋友交流。 当然,不能唯模型论,模型不会解决所有的问题,模型也只是描述了做什么,怎么做在模型里并没有详细描述,要解决怎么做的问题需要和有实践经验的专家进行沟通。只有真正理解了模型才能不唯模型论,才能根据实际进行裁剪。
2 不善于与项目组沟通 规范的管理是着眼于未来的,可以降低犯错的概率,其效益可能在当前并不明显,规范的管理会改变开发人员的工作习惯,在他们的眼中可能认为规范是一种累赘,因此对规范的抵制是一种很自然的反应。 EPG是公司研发管理大法的制订组织者,是体系推广者,项目组是体系的执行者,而EPG不是项目组的领导,在和项目组打交道时,不能以居高临下的姿态和项目组沟通,否则很容易引起项目组的反感,给体系的推广设置人为的障碍。 项目组里最有影响力的是项目经理,项目经理就是EPG的重点沟通对象。
3 不善于利用企业高层管理人员 过程改进也是一把手工程,尤其是在基础薄弱的组织中。如果缺少了企业高层的支持,体系的推广是寸步难行的。 EPG不是项目组的直接领导,不可以直接对项目下命令,因此在推广的过程要善于利用企业的领导,经常和领导沟通,和领导一起加深对研发管理的认识,从领导那里获得反馈,并借助领导的影响力促进体系在项目中的推广。 与领导的沟通是有技巧的,要根据领导的风格区别对待。有的领导喜欢直来直去,有的领导喜欢迂回曲折,有的领导喜欢独断专行,有的领导则比较民主。要将你的思想转换为领导的思想,就要采取一定的技巧,对症下药。
4 不善于利用一切改进机会 为了推广体系,需要充分抓住一切在组织内教育员工、教育领导的机会。最典型的有4个机会: (1)质量事故。一旦发生了质量事故就要刨根问底,追根溯源,以充分引起大家对质量的重视。 (2)成功案例。如果有个项目做的很成功,同样也要抓住机会,仔细深入地分析项目成功的原因,利用典型的成功案例教育大家。 (3)外部咨询。中国有句俗话:“外来的和尚会念经”,当有外部的咨询师或者评估师到企业时,也要充分利用这个机会,对员工和领导进行教育。 (4)内部调研。在企业里进行对管理现状的调查,是一种自底向上反应大家对组织规范管理需求的有效手段。管理永远是需要改进的,改进的动力来自于商务需要,也来自于群众的呼声,群众的呼声可以转换为商务需要。
5 EPG本身作业不规范 EPG要以身作则,自己也要按规范办事,不能表现的很随意。比如: EPG自己生产的文档不符合公司定义的各种的规范; EPG自己的文档没有纳入配置管理; 体系文件的变更不遵守公司的变更流程; EPG的工作缺乏计划性 对EPG的工作没有执行PPQA等等。 已身不正,何以正人?
6 违背了循序渐进的思想 “以人为本,以过程为核心,以度量为基础,循序渐进”是当前各种管理模型的核心思想。管理的改进是文化的变革,要改良而非革命,不能拔苗助长,要冷水煮青蛙。一些软件开发中的基本实践看似简单,在企业里推行时却会困难重重,比如:需求文档化、设计文档化、计划文档化、同行评审、专职的测试等等。往往迫于商业目标的压力,在过程改进时,EPG会定义不切实际的改进目标,试图短期内见效,这样就要求项目组一次改进的地方太多,而这么做,很可能事与愿违,导致项目组比较抵触,即使短期内能够通过评估,一旦拿到证书,反弹也会比较大。
7 忽略了裁剪指南 裁剪指南比体系本身更重要。僵化的体系是不可能真正在组织里推行下去的,要保持体系的灵活与敏捷,就必须定义详细的、实际的裁剪指南,并在实践中逐步完善。EPG的成员往往试图包罗万象,将体系定义的相当完备,在过程定义、模板定义上花费了大量的时间,而忽略了裁剪指南是体系的更重要的部分。这样导致在实际推广中,体系可以裁剪的选择余地很少,针对具体的项目组,往往会让项目组多做一些无法产生价值的活动,这样项目组就会产生一些抵触情绪。
8 忽略了持续培训 在过程改进的初期会做CMMI的 introduction培训、过程域培训、管理技术的专题培训,在体系定义完成后,会做体系的培训。那些培训要么是集中在一段时间完成了,培训的密度比较高,效果并不好,要么间隔的时间比较长,培训后面时忘记了前面的内容。因此,需要在体系的推进过程中再将已经做过的培训的要点换个角度进行强化,使一些观念、一些做法深深的刻在每个人的脑子里,这样才能成为习惯,才能让执行者能够知其然,知其所以然,持之以恒地坚持下去。
9 缺乏足够的软件工程经验 这一条实际上是在选择EPG成员时犯的错误。以CMMI模型的博大精深,要想充分理解其内涵,理解其精神,没有足够的软件工程背景是比较困难的。而很多企业的EPG成员恰恰就缺乏足够的软件工程经验,有经验的员工都去生产一线做项目经理、做部门经理,去直接创造商业价值了,间接创造商业价值或者会带来长期效益的管理活动便让一些缺少经验的人来做了,这实际上一种“脑体倒挂”。缺少经验的人需要到一线去工作,去锻炼,去提高,那些有经验的员工则需要充分贡献出其经验,充分发挥他们在企业里的正面影响力,而不是成为过程改进的阻力,这才是他们的价值的体现。
10、过分依赖咨询公司 EPG成员在建立公司内部过程体系的初期,往往会过分依赖外部咨询公司,要求咨询公司提供已成型的过程体系文档。每个组织都有其自身的特点,产品方向可能不同、组织结构可能不同、企业文化可能不同、人员结构可能不同、外部的商务环境也可能不同,因此企业的作业流程、文档格式等都可能不同。如果机械的照搬,那么势必会造成EPG建立的标准过程并不适合本组织,从而使过程改进见效缓慢,甚至夭折。
原文发表于软件工程专家网
|
一共有 6 条评论
------ 用怀疑的眼光看待理论与实践,你会学到更多。
2. 不善于与项目组沟通
3 不善于利用企业高层管理人员
------ 干系人管理不好,项目管理中,利用一切可以利用的资源,你做到这些,基本就是未来的企业高管。
4 .不善于利用一切改进机会
5 .EPG本身作业不规范
---------这个没做好,就是自己给自己挖坑
6. 违背了循序渐进的思想
---------严格遵守CMMI的IDEAL,对于遇到的问题,严格follow PDCA.
7. 忽略了裁剪指南
8. 忽略了持续培训
9. 缺乏足够的软件工程经验
10. 过分依赖咨询公司
----------依赖于外部的文档模版产生的内容,只是给ATM看的,过后,100%的保证,CMMI将以失败而告终。
以上内容出现这么多的问题,可以看出,在Run CMMI这个项目的管理者,出现了项目管理上的问题。
http://cmmionline.net/forums/thread/843.aspx
1 你那么做很好,会做的比较扎实。
2 只要有效果,能提高,实践的颗粒度大小没关系。我建议的原则:
(1)大家有比较强烈的意识到了这是个问题,优先级比较高;
(2)在组织目前的情况下,力所能及,是目前能够改进的;
(3)改进后的效果能够在短期内看到。
举很简单的例子:
开会迟到的现象很普遍,你可以定义一个奖惩措施改进之;
开会时投影仪或者白板没有准备好,你可以定义一个会议的流程改进之;
大家都不写设计文档,你可以定义一个设计的模板让大家遵守,或者将设计与编码的人员分离等等;
给客户交付的产品BUG太多,到现场后迟迟无法正式上线,你可以实施CMMI的大部分PA了,哈哈!
这些改进颗粒度的大小都没关系吧,只要符合上边的原则就OK吧。
请各个小部门总结经验,对Top 1的问题进行改进,改进实践自己订,但同时定出检验的标准,这个标准让过程改进组审核,不同过的重新订检验标准,一直达到可以客观的检验为止。
可是我不知道过程改进的实践应该是多大的粒度?
能否提供帮助?枚举改进的实践?