CMMI的模型架构
回帖数
0
阅读数
989
发表时间
2024-05-23 10:22:49
为什么CMMI落不了地?我想这个问题应该困扰着很多组织的管理者以及过程改进相关者,小到20人的企业,大到规模上万人的企业,在执行CMMI过程中可能有一些组织多多少少有过这样的疑问,也或多或少地都遇到过下面列举的这10个常见的坑。
在正式列举之前,我先简单介绍一下CMMI的发展历程。可能很多人对整个CMMI的发展历史不是很清楚,这里有必要让大家了解它的发展背景,有利于全视角的了解CMMI。
CMMI最早是由美国卡耐基梅隆大学软件工程研究所组织当时世界知名的软件过程改进和软件开发管理方面的专家历时多年开发出来的,并后续在全世界推广实施的一种软件能力成熟度评估模型,主要用于指导软件工程和系统工程的开发、集成过程和软件开发能力的评估。
发展到今天,过程中历经了不断的蜕变和升级。从早期的CMM到今天的CMMI2.0,隶属组织也由早期的SEI到今天的CMMI研究院,但是不变的是过程改进的初心。
现在CMMI已经发展成为性能改进的模型,它的实用性不断加强,适用于希望不断提升性能以及应对和解决业务挑战的组织。在过去的20多年发展中,它慢慢成为全球商业和政府范围内被论证的行之有效的最佳实践的集合,它可以快速提升和维持企业组织的绩效,从而提升组织发展过程中的盈利能力和竞争力。
但有句话叫:“理想很丰满,现实很骨感”。很多组织在组织内部实施CMMI的时候并不能达到既定的目标,就像很多事情在计划的时候是欣欣向荣的场景,而在真正执行的时候,会发现总会遇到各式各样的问题与困难,下面我总结了在实施CMMI过程中我们常见的10个坑,供大家参考.
那么如何可以做好呢?在获得组织发起人强有力支持的基础上,从EPG的角度来看,在做宣贯培训工作之前首先要解决大家的思想认识问题,这个在初期还是比较难的,毕竟改变大家固有的习惯是件非常困难的事。不仅要在主观上想办法解决,而且客观上也必须要有措施,并且能够从体系落地的组织架构、角色职责和义务、文化建立上多处入手,形成组织的共同认知并一起推动过程改进的落地。
改进过程中需要有全局视角,如何打破原有的平衡并快速建立起对组织更长远更有利的新的平衡是每个管理者和执行者需要深思熟虑的问题。
但是从CMMI研究院官方的实际执行数据来看,大多数企业的改进不是一蹴而就的,是需要经过时间的积累,少则2年,多则5年以上。
我们不能用快速投资的视角来看待过程改进,改进效果的提升也不是由单独一方来决定的,它受到很多其他因素的影响,需要这些影响因素共同改善。从大多数企业的改进曲线来看,有的企业在改进初期还有可能带来运行效率下降,甚至出现一些混乱的局面。
体系是持续改进的,应该以循序渐进为主,逐步建立适应当时的体系。另外,体系需要通过实践,不断迭代,发现改进机会,然后针对性改进,从而让体系符合实际的工作情况。
改进需要一个过渡期,需要人与人之间,流程与流程之间,人与流程之间的不断磨合。只有不断的坚持和反复优化,才能真正看到改进带来的效果,所以过程改进请大家保持耐心。
这里要提醒所有的企业,过程改进不是简单的复制和粘贴。另外体系也不是一刀切,一套流程走天下。组织可能需要根据不同项目类型不同的场景进行实例化裁剪确定细分流程。
CMMI并不是一套可以直接生搬硬套的标准。在这些实践域中,每一个实践都有着明确的目标,具体到每一个特定的企业,需要根据企业的商业目标、实际情况、行业标准等,来确定采取什么样的改进方法、流程和具体的行动来实现模型的要求。
从度量数据方面来举例说明。在大量的数据面前,如果没有工具支持而只能靠手工整理的情况下,会大大增加工作量,适当地使用工具就会大大的提高组织的项目管理效率。同时也有些公司大量使用工具(想用工具解决所有流程),但是在使用之前没有给项目组做充分的培训,导致最后项目都结束了,项目成员还在修改或者返工因为项目没有正确使用工具所产生的问题。这些都是没有正确利用工具执行过程改进的主要体现。
通常在CMMI实施中会涉及哪些工具?例如:项目管理工具,缺陷管理工具,配置管理工具,自动化测试工具,数据度量工具等等。
我们经常在企业里看到,因为使用了一些管理经验及技术实力上不足以担负其职责的人员,导致执行层面不理解或不清楚过程改进工作,其结果直接导致项目实施缓慢,或者在审核过程中暴露太多的问题。
所以,我们尽可能选择那些有经验、有能力的员工参与到实施过程中来,在企业里充分发挥他们的正面影响力和执行力。当然有的组织,直接以立项咨询项目的方式来推进改进,这不失为是个行之有效的方案,因为咨询公司往往有丰富的项目实施案例并且对模型有着专业的理解。
我们在做CMMI实施过程时一直强调,过程改进只有起点没有终点,我们不能因为通过评级后开始懈怠,评估通过只是阶段性的一个里程碑,漫漫改进道路上的一个节点,不会是改进的全部,否则结果一定是前面的努力和阶段性成果付之东流,重新回到了起点,这是我们最不愿意看到的。
同时商业目标的更新变化、新的产品需求、新的技术需求等不断更新,都会催生出新的过程改进需求,要确保流程始终能够符合当下的组织需求。
事实上,企业需要达到什么样的级别应该由企业的规模、发展阶段、人员能力,文化、客户和产品类型决定的。如果企业规模过小,却往高等级方向去仰望,最终结果一定是浪费了大量资源,无法获得设想的结果。我们不可叶公好龙,更不能天方夜谭,千里之行始于足下。
选择适合组织当下的模型和方法论,持续不断的改进,脚踏实地的执行。
从CMMI实施来看,QA是工作流程和质量的最后一道防线,我们不能把第三方监控的价值短浅地看成只是额外成本。对比后续的返工成本,从避免重大问题的发生,提升客户的满意度来说,节省的远远大于QA的投入成本。企业要把QA投入看成是高收益的投资项目,不能不重视QA,不理解它存在的意义,更不能忽视了它真正的价值。
我们甚至可以说QA是体系落地的关键,通过产品审计、过程审计等手段,确保流程落地,推广到各个项目中去。
同时QA是我们组织中最Pure(纯净)的角色,由于他们独立第三方的位置,往往能发现组织现有亟需改进的过程改进建议以及需求。
当我们的流程建立完成,后面重点就是要实时关注并衡量改进的效果,这让我们的所有的努力和方向会变得更有意义。然而实际上能够做到上述的组织很少,他们时常不知道自己改进方向在哪里?改进成功的效果如果定义?等等一系列问题。
这使我们组织需要有自己的专人(负责)变得尤为迫切,例如组建EPG小组,他们需要具备过程改进思路和组织协同能力,能够定期给组织体检,诊断,并能开出良药,定期组织体系应用结果和效果,对体系进行全面的评估,并识别改进机会。只有这样才能认清自己并可以衡量改进的效果,才能在过程改进这条路上真正做到游刃有余。
经常有人说,CMMI是一个复杂的,标准化的,程式化的软件研发过程,是相对比较重量级的(当然这是部分人错误的理解),而敏捷是轻量级的,快速响应的一种所谓高效的研发方式。二者看起来貌似水火不容,实则可以进行很好的融合。
CMMI的大部分实践与敏捷思想其实是相同的,在很多地方都有共识。例如:都是来自于历史成功组织的最佳实践集合,两者都要做Plan,都要做跟踪,都要做配置管理,都要做数据度量,都要做原因分析,都要做复盘等等。CMMI更多强调的是what to do ,而敏捷强调的是how to do,只是活动的抽象层次不同。
CMMI与敏捷并不冲突,在实施过程中可以进行很好的融合,融合制度和过程其实并不难,难的主要是让团队从上到下发生思想的转变,进而落在行动之上。 以上所列举的10个“坑”就是企业在CMMI落地过程中经常遇到和面临的一些问题,对照着这些问题希望能给正在或将要实施CMMI改进的企业,带来一些启发和思考,也希望这些问题在过程改进的道路上有则改之,无则加勉。
在正式列举之前,我先简单介绍一下CMMI的发展历程。可能很多人对整个CMMI的发展历史不是很清楚,这里有必要让大家了解它的发展背景,有利于全视角的了解CMMI。
CMMI最早是由美国卡耐基梅隆大学软件工程研究所组织当时世界知名的软件过程改进和软件开发管理方面的专家历时多年开发出来的,并后续在全世界推广实施的一种软件能力成熟度评估模型,主要用于指导软件工程和系统工程的开发、集成过程和软件开发能力的评估。
发展到今天,过程中历经了不断的蜕变和升级。从早期的CMM到今天的CMMI2.0,隶属组织也由早期的SEI到今天的CMMI研究院,但是不变的是过程改进的初心。
现在CMMI已经发展成为性能改进的模型,它的实用性不断加强,适用于希望不断提升性能以及应对和解决业务挑战的组织。在过去的20多年发展中,它慢慢成为全球商业和政府范围内被论证的行之有效的最佳实践的集合,它可以快速提升和维持企业组织的绩效,从而提升组织发展过程中的盈利能力和竞争力。
但有句话叫:“理想很丰满,现实很骨感”。很多组织在组织内部实施CMMI的时候并不能达到既定的目标,就像很多事情在计划的时候是欣欣向荣的场景,而在真正执行的时候,会发现总会遇到各式各样的问题与困难,下面我总结了在实施CMMI过程中我们常见的10个坑,供大家参考.
NO.01 组织上下思想认识不统一
推行CMMI不仅仅是管理层的事情,每个人都需要积极参与。假如,EPG在强有力地推进CMMI,而组织的其他成员却完全靠自觉自愿地来执行,甚至认为体系建设是外部顾问或者领导的职责,与普通员工没有关系,那么在这样的场景下整个过程改进工作执行起来就非常的吃力。一开始思想认识从上到下就没有捋顺,就没有统一,这时就很难推行,最后通常都不了了之。那么如何可以做好呢?在获得组织发起人强有力支持的基础上,从EPG的角度来看,在做宣贯培训工作之前首先要解决大家的思想认识问题,这个在初期还是比较难的,毕竟改变大家固有的习惯是件非常困难的事。不仅要在主观上想办法解决,而且客观上也必须要有措施,并且能够从体系落地的组织架构、角色职责和义务、文化建立上多处入手,形成组织的共同认知并一起推动过程改进的落地。
改进过程中需要有全局视角,如何打破原有的平衡并快速建立起对组织更长远更有利的新的平衡是每个管理者和执行者需要深思熟虑的问题。
NO.02 缺少耐心
在实施过程改进初期,很多企业对改进的效果都抱有很大的期望,希望能够快速给企业带来显著的提升,期望体系一次性建设到位,从而一次性投入大量时间和人力来研发体系,然后全力推广。但是从CMMI研究院官方的实际执行数据来看,大多数企业的改进不是一蹴而就的,是需要经过时间的积累,少则2年,多则5年以上。
我们不能用快速投资的视角来看待过程改进,改进效果的提升也不是由单独一方来决定的,它受到很多其他因素的影响,需要这些影响因素共同改善。从大多数企业的改进曲线来看,有的企业在改进初期还有可能带来运行效率下降,甚至出现一些混乱的局面。
体系是持续改进的,应该以循序渐进为主,逐步建立适应当时的体系。另外,体系需要通过实践,不断迭代,发现改进机会,然后针对性改进,从而让体系符合实际的工作情况。
改进需要一个过渡期,需要人与人之间,流程与流程之间,人与流程之间的不断磨合。只有不断的坚持和反复优化,才能真正看到改进带来的效果,所以过程改进请大家保持耐心。
NO.03 照搬照抄
很多企业在实施CMMI中,完全照搬其他组织的流程和经验。这里确实有部分咨询公司会直接给企业一套标准化的模板来进行过程改进,而并没有根据企业实际情况进行体系的落地化改进。这里要提醒所有的企业,过程改进不是简单的复制和粘贴。另外体系也不是一刀切,一套流程走天下。组织可能需要根据不同项目类型不同的场景进行实例化裁剪确定细分流程。
CMMI并不是一套可以直接生搬硬套的标准。在这些实践域中,每一个实践都有着明确的目标,具体到每一个特定的企业,需要根据企业的商业目标、实际情况、行业标准等,来确定采取什么样的改进方法、流程和具体的行动来实现模型的要求。
所有的流程都需要经过认真的探讨和科学的论证,绝不能照搬照抄,否则一套不适合组织的流程最终也会执行不下去或者没有达到原定的效果。
NO.04 改进缺少工具支持
工欲善其事必先利其器。企业在实施CMMI过程中离不开工具的支持,正确的使用工具会达到事半功倍的效果,虽然前期的工具采购会花费一些成本,但长远来看给我们节省的成本远远大于工具本身。从度量数据方面来举例说明。在大量的数据面前,如果没有工具支持而只能靠手工整理的情况下,会大大增加工作量,适当地使用工具就会大大的提高组织的项目管理效率。同时也有些公司大量使用工具(想用工具解决所有流程),但是在使用之前没有给项目组做充分的培训,导致最后项目都结束了,项目成员还在修改或者返工因为项目没有正确使用工具所产生的问题。这些都是没有正确利用工具执行过程改进的主要体现。
通常在CMMI实施中会涉及哪些工具?例如:项目管理工具,缺陷管理工具,配置管理工具,自动化测试工具,数据度量工具等等。
NO.05 缺少精兵强将
公司实施过程改进,除了公司高层的支持和参与之外,还需要有强有力的改进推动者和关键过程改进实施人员,例如:EPG组长, QA和配置管理人员等。我们经常在企业里看到,因为使用了一些管理经验及技术实力上不足以担负其职责的人员,导致执行层面不理解或不清楚过程改进工作,其结果直接导致项目实施缓慢,或者在审核过程中暴露太多的问题。
所以,我们尽可能选择那些有经验、有能力的员工参与到实施过程中来,在企业里充分发挥他们的正面影响力和执行力。当然有的组织,直接以立项咨询项目的方式来推进改进,这不失为是个行之有效的方案,因为咨询公司往往有丰富的项目实施案例并且对模型有着专业的理解。
NO.06 评估之后懈怠
这个问题也是我们在很多企业里面常见的问题,很多企业错误地把通过CMMI评估,拿到CMMI证书作为终极目标。我们在做CMMI实施过程时一直强调,过程改进只有起点没有终点,我们不能因为通过评级后开始懈怠,评估通过只是阶段性的一个里程碑,漫漫改进道路上的一个节点,不会是改进的全部,否则结果一定是前面的努力和阶段性成果付之东流,重新回到了起点,这是我们最不愿意看到的。
同时商业目标的更新变化、新的产品需求、新的技术需求等不断更新,都会催生出新的过程改进需求,要确保流程始终能够符合当下的组织需求。
NO.07 一味的追求高等级而忽视了自己的能力
很多人有这样错误的理解:高等级一定比低等级强,我为什么不做高等级。其实不然,每个企业的能力和现状都是不一样的,我们不能做超出能力之外的事情。事实上,企业需要达到什么样的级别应该由企业的规模、发展阶段、人员能力,文化、客户和产品类型决定的。如果企业规模过小,却往高等级方向去仰望,最终结果一定是浪费了大量资源,无法获得设想的结果。我们不可叶公好龙,更不能天方夜谭,千里之行始于足下。
选择适合组织当下的模型和方法论,持续不断的改进,脚踏实地的执行。
NO.08 低估QA的作用
很多企业不愿意在QA角色和这项工作上投入太多的成本,完全没有真正评估和认识到QA的真正价值。从CMMI实施来看,QA是工作流程和质量的最后一道防线,我们不能把第三方监控的价值短浅地看成只是额外成本。对比后续的返工成本,从避免重大问题的发生,提升客户的满意度来说,节省的远远大于QA的投入成本。企业要把QA投入看成是高收益的投资项目,不能不重视QA,不理解它存在的意义,更不能忽视了它真正的价值。
我们甚至可以说QA是体系落地的关键,通过产品审计、过程审计等手段,确保流程落地,推广到各个项目中去。
同时QA是我们组织中最Pure(纯净)的角色,由于他们独立第三方的位置,往往能发现组织现有亟需改进的过程改进建议以及需求。
NO.09 体系建设和推广效果无法衡量,也没有专人(小组)负责
很多企业初期在咨询公司的帮助下搭建了CMMI体系,这些历史积累和经验在改进前期确实发挥了很大作用,但任何事情从0到1的过程都是个痛苦和艰难的过程。当我们的流程建立完成,后面重点就是要实时关注并衡量改进的效果,这让我们的所有的努力和方向会变得更有意义。然而实际上能够做到上述的组织很少,他们时常不知道自己改进方向在哪里?改进成功的效果如果定义?等等一系列问题。
这使我们组织需要有自己的专人(负责)变得尤为迫切,例如组建EPG小组,他们需要具备过程改进思路和组织协同能力,能够定期给组织体检,诊断,并能开出良药,定期组织体系应用结果和效果,对体系进行全面的评估,并识别改进机会。只有这样才能认清自己并可以衡量改进的效果,才能在过程改进这条路上真正做到游刃有余。
NO.10 敏捷和CMMI你死我活
经常有人说,CMMI是一个复杂的,标准化的,程式化的软件研发过程,是相对比较重量级的(当然这是部分人错误的理解),而敏捷是轻量级的,快速响应的一种所谓高效的研发方式。二者看起来貌似水火不容,实则可以进行很好的融合。
CMMI的大部分实践与敏捷思想其实是相同的,在很多地方都有共识。例如:都是来自于历史成功组织的最佳实践集合,两者都要做Plan,都要做跟踪,都要做配置管理,都要做数据度量,都要做原因分析,都要做复盘等等。CMMI更多强调的是what to do ,而敏捷强调的是how to do,只是活动的抽象层次不同。
CMMI与敏捷并不冲突,在实施过程中可以进行很好的融合,融合制度和过程其实并不难,难的主要是让团队从上到下发生思想的转变,进而落在行动之上。 以上所列举的10个“坑”就是企业在CMMI落地过程中经常遇到和面临的一些问题,对照着这些问题希望能给正在或将要实施CMMI改进的企业,带来一些启发和思考,也希望这些问题在过程改进的道路上有则改之,无则加勉。
最后,我们认定这个公理:“过程改进的前提是产品质量在很大程度上取决于用于其开发、维护的过程质量。”这就需要我们的过程执行者忠于定义的过程,需要让他们看到过程及过程改进的好处,看到质量的提升,看到效率的提升,看到客户的认可,看到组织商业目标一步一步的实现。只有让组织管理者和参与者深信:严苛打磨的过程是项目成功的重要保障,在这个基础上,CMMI才能更好的落地。
——————————————
作者:赛希咨询
https://www.bilibili.com/read/cv15255733/
声明:本文系转载,文章版权属于原作者,如有疑问请联系删除。
2024-05-23 10:27:57 路婕 最后编辑
联系人
高丽亚/高级客户经理
电话(微信)
17667930330
QQ号码
3645260865
联系邮箱
gaoliya@chandao.com