导读

2023年7月25日，网友“一丹”在某微信群里提了一个关于项目管理成熟度应用的问题:

“项目管理成熟度如何定义及分级？哪一级可以开展的工作事项如何组成？哪些指标体系参考？”

群主找我给她科普一下，于是，我花了2个小时，断断续续地和一丹聊了下项目管理成熟度模型，主要谈了下哈罗德.科兹纳的K-PMMM模型、项目管理成熟度模型OPM3，还有在软件开发企业应用比较广泛的CMMI以及成熟度等级评价和指标设定的一些问题。但是，因为是在微信群里聊的，我当时还有其他事情，因此聊得比较零碎、不够系统和全面。

另外，7月24日晚上，我在视频号听了一个老师分享了《软件质量体系CMM在企业落地的丽境与突围》，也有一些关于CMMI改进落地的想法，因此，有了今天这篇文章。

正文分为三个部分，分别是CMMI简介、CMMI应用存在的问题和原因分析、CMMI实施改进策略。本篇文章写作的思维导图如下

1 CMMI简介

1.1CMMI定义

CMMI模型，中文全称叫 (软件) 能力成熟度集成模型，其前身是SW-CMM（Software Capability Maturity Model）,SW-CMM是20世纪80年代美国卡内基梅隆大学软件工程研究所(SEI-CMU)开发的用于评价软件开发组织过程能力的模型。

CMMI模型和ISO 9001体系一样，都可以被看成质量管理体系 (框架) ，只不过CMMI更适用于软件开发领域。CMMI模型最新版本是V3.0，但是对企业认证来说，主要还是依据V2.0版本进行，而我本次分享的内容，还是按照软件开发我本人比较熟悉的V1.3版本来撰写，CMMI本身版本更迭及内容变化，不是本文的关注的重点，不做细表。

1.2CMMI核心内容

CMMI模型分为三个分支，适合于供方、乙方的模型有CMMI-DEV（主要针对开发类）、CMMI-SVC（主要是针对服务类组织）；适合需方、甲方的模型有CMMI-ACQ（主要是针对采购类组织）。

CMMI模型组件，按照严格要求，包含三个控制级别，分别是：1）必需的2）期望的3）参考的。其中第1点是必须要满足的，另外两点，视组织的具体情况而定。

CMMI-DEV包含了22个过程域( Process Area，简称PA),这个22个过程域，可以被分为项目管理类（7个）、过程管理类（5个）、工程类（5个）和支持类（5个）。

过程域是一类最佳实践的集合，不是过程的集合，过程一般是有顺序的，而集合是没有顺序，这一点，对于CMMI初学者来说特别重要，因为是无序的，这个在企业内部应用时，操作性比较弱，不好落地。

1.3CMMI等级划分

CMMI的等级，按照连续式表示法，可分为4个等级，从低到高依次为不完整级、已执行级、已管理级和已定义级；按照阶段式表示法，可分为5个等级，从低到高，分别是初始级、已管理级、已定义级、已量化管理级和持续优化级。

1.4CMMI评估方法

CMMI评估主要采用SACMPI方法，SCAMPI A类评估方法是普遍认可用于使用CMMI模型来实施ARCA类评估的方法。SCAMPI A类方法定义文档（(SCAMPI A Method Definition Document，MDD)定义了确保SCAMPIA类评估评定一致性的规则]。为了与其他组织进行基准比较，评估必须确保具有一致的评定。达成具体的成熟度级别，或满足某一过程域，对不同的已评估的组织必须具有相同的意义。

SCAMPI将整个评估分成三个阶段，依次为评估过程计划和准备、执行评估和报告结论。

2 CMMI应用存在的问题和原因分析

2.1普遍问题

CMMI作为项目管理成熟度模型，已在全球范围内获得了广泛的推广与应用，中国很多企业也都通过高级别的认证，中国企业从2019年至2022年10月通过CMMI L3等级到CMMI L5等级认证的企业，由下表可以看出CMMI L3等级认证的企业最多，达到7493家企业,认证 CMMIL4等级的企业最少，达到53家。CMMI5级引入了量化、统计的方法，整体实施起来更加复杂，认证的项目也会增多，通过CMMI L5认证的企业都是行业内的佼佼者。在中国通过CMMI5级的企业逐年增多，从2019年的97家企业，2020年激增78.68%，达到455家。

但是，我们也发现，在中国很多企业拿认证的多，真正落地实践CMMI的少。导致CMMI体系与实践存在严重的两张皮现象，这是CMMI体系本身的问题，还是企业特殊情况导致的，需要我们做细致的分析。

2.2原因分析

CMMI是项目管理成熟度模型研究的起源，模型本身很成熟的，针对软件项目开发也很实用。我国引入CMMI后，政府积极出台了各种奖励政策，鼓励企业实行CMMI认证，但效果并不明显，初步分析，有5个方面的原因:

1) 模型本身比较复杂

使用了大量表达晦涩的独创性术语对模型进行描述，而且评价指标众多，便利性不足，评价投入成本过大，另外还需要经过认证评估师参与方可进行。

2) 传统文化障碍

CMMI模型产生于美国，基于“三权分立”的理念在组织中分别设立了行使“立法”、“监督”、“执法”的三个机构，这种安排的目的是为了强调项目管理过程需要依据规章制度，即依“法”办事。而我国企业，尤其是中小型企业，大部分还处于“人治”的状态，因此在落地CMMI时存在一定的文化障碍，需要深刻理解后才能实施下去。

3) 缺乏企业高层支持和承诺

如果未能获得高层领导的支持和承诺，CMMI在实施过程中很难取得成功。没有高层的推动力量，员工参与度和积极性可能会下降。例如，如果高层领导不理解CMMI的价值，并未将CMMI作为组织的战略目标之一，员工可能会对CMMI实施过程不感兴趣或产生抵触情绪。

4) 企业文化和习惯难以改变

CMMI要求企业在流程管理、项目管理、质量管理等方面进行优化改进。然而，许多企业已经形成了固定的工作习惯和组织文化。这些习惯和文化可能与CMMI的要求不一致，从而导致实施CMMI时遇到困难。例如，在某些企业中，项目管理人员习惯于按部就班地完成任务，而CMMI要求进行风险管理和持续改进。

5) 缺乏培训和培养机会

CMMI的实施需要具备相应的知识和技能。如果企业没有提供充足的培训和培养机会，员工将很难掌握CMMI所需的方法和工具。例如，CMMI要求进行统计过程控制，但如果员工没有接受过统计分析的培训，将很难满足CMMI的要求。

3 CMMI实施改进策略

为了解决CMMI体系认证和实际落地存在的两张皮问题，逐步提升企业的项目管理水平以及过程改进效果，可以考虑从更新认知、行动策略两方面进行系统级改进。

3.1更新认知

1）CMMI不是万能膏药

在管理学中，有个所谓的“木桶理论”，即一个木桶可存水的最大容量是由最短的那根木头决定的。在企业的开发能力中，过程，技术(含工具、方法)和人员都是主要的因子，都需要全面提高，只关注一个方面，而忽略了其他方面，很可能事倍功半。

在企业开始实施CMMI时，很容易犯的一个错误就是“唯管理论”或孤立地只抓过程改进，忽略了开发技术与人员的提高，实施了3到6个月后，发现企业的生产能力并没有得到明显的改善，这时反对的声音起来了，过程改进就难以继续进行了。

有的企业采用面向对象的开发方法进行软件开发，但是企业内并没有对面向对象技术真正了解的专家，即使采用了RUP过程，也仅仅是形似，而没有做到真正的面向对象方法，没有掌握面向对象方法的精髓，这种问题靠过程改进是无法解决的。

还有的企业开发人员积极性差、比较佛系，工作热情低，企业的激励机制没有起到良好的作用，这种问题也是依靠CMMI无法解决的。

2）过程改进是需要时间的

在开始实施CMMI体系时，很多软件企业，尤其是不少中小企业，其管理层往往会对CMMI体系过程改进的期望值太高，希望在短时间内就达到显著效果，但系统级的管理改善需要时间的，在改善的初期，企业的运行效率还可能会出现下降，甚至可能会出现一些比改进前更混乱的情况，只有度过了这段时间，才会看到改进的效果。所以在改善的初期，企业的高层管理者要有这个思想准备，要有耐心。

3）活学活用，以我为主

在推行CMMI体系时，所遇到的阻力,有很大程度上是由于照搬CMMI的条文，不切合项目组的实际情况，没有具体情况具体分析。

实际上，一线的管理人员、开发人员最了解实际。谁了解实际，谁就有发言权。所以在制定质量规范时，尤其是在制定大家都要执行的操作规程、模板时，一定要得到执行者，尤其是基层员工的认同，否则就容易成为执行和沟通的障碍。

凭借公司的行政制度硬性推行CMMI等质量体系，表面上看，似乎大家也照规范要求做了，但是很多时候可能只是表面文章，这对改善没有实际的帮助，导致过程改进工作受阻。

4）我们要渐进式的改良

以革命的方式来实施CMMI体系，期望通过一场运动战来解决过程能力的问题，一种可能是管理层不懂CMMI体系，不懂得管理的改进是要遵循循序渐进的，还有另一种可能是明知故犯，期望在短期内通过CMMI评估，单纯追求市场上的轰动效应，或者获得相关部门的补贴。

有的企业，虽然在短时间内通过了CMMI评估，但是由于没有实效，得不到大家的认同，因此，难以将这种“水平”持续下去。

过程改进，就像女生减肥，是可以通过吃减肥药在短时间内减轻体重，但如果不是从根本上改善饮食、生活和运动的习惯,那么体重还是会在短时间内反弹，另外，减肥药的副作用可能会给你的身体健康带来更大的威胁。

5）CMMI与创新不矛盾

软件企业必须形成创新的文化，这是由这个行业的本身属性决定的，管理与创新是软件企业发展的两个轮子，管理能够确保企业平稳地发展，而创新能够实现企业的跳跃式发展，只抓管理不抓创新，可能导致企业的发展速度太慢，最终形成“快鱼吃慢鱼”的现象，只抓创新不抓管理，则可能导致创新无法转化为生产力。

软件企业里有些管理人员，也包括一些开发人员，会认为严格的管理会束缚他们的创新，认为CMMI提倡的是一种按部就班的文化，什么活动都要做计划、按规章流程来做，对企业的创新文化会起负面作用。

但是，实际上，技术创新必须通过管理才能有效地转化为生产力，转化为企业的实际效益达到效益最大化，这是最根本的。说句实在话，中国企业不缺技术（除了少量的卡脖子外），缺的是如何将技术高效转换为生产力的能力。

当然，管理的改进优化到一定程度会遭遇“天花板”，此时就必须借助技术的创新或管理的创新去实现突破，这是另外一个值得思考的问题，暂且不表。

6）建立宽容的组织文化

CMMI是软件工程经验与教训的总结。在实施CMMI的过程中，肯定会走不少弯路，甚至犯错误，因此许多人会议论，一直会反映到高层管理者那里。

这时不要犹豫，要敢于尝试，不能因为有困难就打退堂鼓，想学会游泳，但是不下水，或者呛着一两口水就不学了，那是永远学不会游泳的。

对于软件企业的高层管理者来说，尤其要注意这一点，要在组织内建立起良好的氛围，不因为在过程中的一些实践失败，就对项目经理、EPG等人员有偏见，要以积极的心态面对改进。

7）过程改进要全员参与

推行CMMI，不仅仅是管理人员的事情,每个人都要积极参与。要改变企业原来的一些不好的做法：PMO和EPG在使劲地推进CMMI的工作，而不是大家自觉自愿地来实施CMMI。

从 PMO和EPG的角度来看，要做好CMMI培训的工作，首先是要解决大家的思想认识问题，这还是比较难的，因为有些人的思想是比较顽固的。

企业的过程改进首先要解决的就是思想认识问题，然后才是实施方法得问题。不仅要建立整体的思想认识，还要有切实可行的改进措施。

光说不练是不行的,光练不说也是要否定的。任何变革都会涉及企业内部权力的再分配，不要忽视企业政治，这是客观存在的,所以一定要预防那些光说不练者。

3.2行动策略

我在上面提出要更新认知，在行动上，对于实施CMMI也得有具体的策略和改进方向，下面分享8个策略：

1）循序渐进，由易到难

CMMI的一个核心思想是分级改进，宜采用渐进的方式，而不是突变的方式进行过程改进。比如对于2级的每个过程域，你可以先启动一部分活动，支持部分目标，待制度化了，再实施另外一部分活动，直至支持全部目标。

在实施CMMI 的过程中，企业一定要根据实际情况量力而行，千万不要把期望值定得太高，要一步一步来，先定出最基本的改进方案，把握分级的思想后再逐步提高。

2）先敏捷，再规范

先敏捷再规范，这个策略源于实践，其本意是先做到再写到，先短期利益再长远利益，先实效再完备。因为一步到位，直接采用规范的方法，阻力比较大，效果难以持久，很可能事倍功半。

敏捷方法以其短期内可以见效、对已有的开发过程调整幅度小等特点易被开发人员接受,所以可以先敏捷再规范,将敏捷作为通向规范的一个阶段。

过程改进要从普通的管理人员、开发人员做起，他们是CMMI体系的执行者，所以要满足首先他们的需求，让他们看到好处。否则，他们可以是体系建设的支持力量，也能是阻碍、破坏力量。

如果一家企业的项目规模大都是在10人以下，那么开发团队完全可以从敏捷方法开始着手进行过程改进。但是，因为软件开发存在非规模经济的现象，随团队规模的增加，很多敏捷方法可能很快就失去效果，这时还是要回到重量级的传统管理方法上来。

3）从下游开始，向上回溯

过程改进，优先从软件项目生命周期的下游开始,再逐步到上游。

一般情况下，信息系统的维护阶段是用户方与开发方交流沟通最多，也是最直接的一个阶段，软件开发承包方在这个阶段的错误很容易被用户发现，用户对开发承包方的管理、服务和开发水平的体会最直接、最深刻。

对于软件开发承包方来说，应该首先改进与客户直接交互的流程，确保高质量的产品能得到有效的部署与维护。在维护阶段发现的问题，应组织原因分析，详细分析这些问题的产生根源，以提供客观的证据证明在生命周期上游存在的问题，便于从生命周期的上游开始改进。

采用此策略，有助于解决客户反应最强烈的问题，易于发现瓶颈问题进行改进，能够在短期内取得良好的改进效果，制定的改进措施，也易于被软件开发人员所接受，是一种典型的由表及里的改进路线。

4）因材施教，各个击破

在一个企业内可能有多个开发项目组或者开发部门，不同的组与部门有不同的管理水平,在我们推行CMMI时，不要一刀切，不要希望每个队伍同时达到CMMI 2级或更高的级别,要区别对待。

比如产品研发部门，会经常进行大大小小各种各样的升级，产品的版本比较多，他们对版本管理认识得很深刻，在工作中已积累了一套行之有效的版本管理方法，对于这样的部门可以实施配置管理PA的要求,进一步提高管理水平，而对于其他做系统集成的部门这方面的工作可能就差一些，没有很好的版本管理的基础。

因此，如果一刀切要求大家都在3个月内都达到CMMI2级的要求，这个目标对系统集成的部门就定得太高了，所以，在进行改进时，我们应针对不同的项目组、不同的部门定出不同的改进计划。

5）教育与培训并重

教育主要是改变思想认识，培训主要是传授具体的方法，二者互补，可以使员工能够知其然，知其所以然，能够在主观上认可,客观上执行。

教育与培训可以有各种方式,配合起来使用。比如可以采用观摩学习、请外面的专家来讲、自我反省和培训等方式进行。

过程改进，不能仅仅定义为开发部门的工作，需要整个企业所有人员的参与和重视，因此需要教育与培训的对象比较多,不要有有遗漏,需要面向高层管理人员、开发管理人员、开发人员、市场人员和客户，制定有针对性的赋能计划。

6）充分利用管理工具

管理工具可以作为思想、方法的载体，它可以将管理可视化、客观化，降低劳动强度，解决手工无法解决的问题，易于为开发人员、管理人员所接受。充分利用管理工具来推行过程改进是一个很好的策略。

对工具的选择与购买需要把握好“够用即可”的原则。软件开发管理工具一般比较昂贵,如果一次性投资购买了比较昂贵的软件，可能软件的80%的功能用不上，待企业的管理提高到工具软件可以支持的较高的管理水平时，已经是2年以后的事情了，而2年以后的版本也需要升级更新。

所以，没有必要为用不到的80%的功能提前投资，而且现在各种各样的开源工具比较多，功能也可以满足需求，又便于进行客户化，因此，充分利用开源工具是一个不错的选择。

比如2019年，我在过程改进时引入了禅道管理系统，开始引入的时候是有些难度，毕竟是对工作方法产生了改变，一旦熟练了,就习惯了。

7）做好经验教训总结

每个开发人员、每个项目组、每个角色认认真真地总结自己的经验教训，并吸取这些经验教训，从长期来看，可有效地提高组织整体项目管理能力。

如果再加上参考某个模型，效果可能会更好。而现实中，很多企业把过多的精力盯在了外部的参考模型比如ISO9001质量体系、项目管理知识体系指南上，而忽略了自身经验教训的价值，没有充分发挥自身的价值。

8）善用外脑—咨询专家

目前，很多软件公司，为达到在较短的时间内通过CMMI的评估的目的，签订咨询合同，寻求咨询公司的帮助,我认为这也是一个可行的方式。但同时也需要注意，不要过分依赖咨询公司，尤其不值得提倡的是,有些公司直接从咨询公司处得到标准、规程，囫囵吞枣，直接照搬照抄，真正是为了评估而评估。

企业的标准规范必须与企业的实际情况紧密结合，这些标准规范在CMMI中被称之为企业财富，只有符合企业实际情况的标准规范才是最有价值的。

虽然咨询公司可以帮助企业通过评估，但企业的过程改进还是要以内部为主。软件的过程改进实际上是企业文化的转变，而企业文化的转变归根结底是人的观念、思想、认识、做事方式的转变，是个人能力的提高，这种提高是通过组织中的PMO或EPG、项目经理、技术人员、管理人员整体素质的提高得以实现的，这种实现的途径是通过学习、实践获得的。

因此,软件企业要真正注重实效的改进，就要尽可能多地与咨询公司进行交流，不仅要知其然，还要知其所以然，要有打破沙锅问到底的决心和毅力，才能真正促进企业过程的改进，同时也能丰富咨询公司的工程实践经验,获得双赢的效果。

4 总结和期望

本文首先介绍了CMMI的基本概念、主要等级和评价方法，然后介绍了CMMI在中国企业的认证概括以及存在的两张皮问题，然后从更新认知和行动策策略两个维度提出了一些改进建议，其中更新认知包括7个要点，行动策略上有8个要点。

本文对项目管理从业者包括PMO和PM，以及过程改进EPG人员和QA、以及关心组织能力提升和质量改进的中高层高管理者、以及对学习CMMI的朋友们有一定的启发意义。

请加入【项目经理问答图】知识星球
可免费获取更多精品项目管理资料

精品资料下载：涉及软件产品管理、项目管理、敏捷管理、质量管理、过程改进、软考、PMP、ChatGPT应用等资料，含公众号之前发布过的，即将发布的以及更多的优质资料。

或者，点击“张永彬敏捷管理”微信公众号《CMMI在软件企业应用存在的问题、原因分析和改进策略》查看全文

更多精品内容，请关注“张永彬敏捷管理”微信公众号