只要在软件研发、项目管理和质量改进这个圈子里待过一段时间一定绕不开两个名字CMM和CMMI。无论是内部做研发过程诊断还是对外应付客户审核、供应商评级这两组字母都会频繁出现。很多人把CMMI简单说成“CMM的升级版”这个说法不算错但远远不够。我今天想从实践者的角度把CMM和CMMI的关系彻底讲清楚CMM是怎么诞生的CMMI为什么要接替它两者在等级框架、评估方式、适用范围上有哪些本质差别以及落到自己公司或项目里真正该关注的又是什么。这篇文章既适合刚入行的项目经理、质量工程师也适合正在准备模型评估、或者在搭建研发管理体系的团队。1. CMM的来龙去脉模型是怎么诞生的1.1 软件危机与过程改进的需求上世纪八十年代软件行业最大的痛点是项目失控。大量项目延期、超预算甚至直接失败有经验的从业者回忆那个时代基本靠个人英雄主义某个优秀工程师在项目就顺人一走项目就崩。背后的根本原因是软件开发没有可控过程的保障大家写代码靠灵感交付靠口号出了问题就靠通宵救火。CMM正是在这种背景下出现的全称是能力成熟度模型。它的核心思路说得直白一点评价一个组织能不能稳定交付软件不要只看它某一次项目的表现要看它是否具备一套可重复、可管理、可改进的过程体系。打个比方如果一个人每次都能煮出好菜可能是天赋但一家厨房如果有标准菜谱、食材管理流程和卫生规范那就是体系能力。CMM评价的是整家厨房的运作能力而不是某一个厨师今天的手感。这个思路在当年非常超前因为它把“看不见的软件开发过程”变成了“可以评估的等级”让采购方有机会在合同签署之前就判断承包商的开发能力。与此同时它也倒逼企业开始重视文档化、配置管理、同行评审这些基本功。很多老工程师都承认CMM时代虽然行政味很重但它确实让“过程”这个词第一次真正进入软件行业的管理话语体系。1.2 五个成熟度等级和关键过程域CMM模型最大的贡献是提出了一套五级成熟度框架等级名称核心特征1级初始级过程无序成功依赖个人能力进度预算经常失控2级可重复级建立基本项目管理过程能够重复过去的成功经验3级已定义级组织层面有标准过程项目在标准基础上做裁剪4级已管理级用统计手段量化管理过程和产品质量能够预测趋势5级优化级主动识别过程缺陷并持续改进组织具备自我进化能力每个等级由若干关键过程域KPAKey Process Area支撑。一个组织想要达到某个等级必须满足该等级以及以下所有等级的全部KPA。比如要达到3级2级的六个KPA也必须全部满足。这里有个细节值得留意CMM的KPA是有“资源密度的”。2级偏重项目管理基本功像需求管理、项目计划、项目跟踪、软件质量保证、软件配置管理3级开始进入组织级能力比如组织过程定义、培训程序、同行评审4级上升到量化管理5级则是缺陷预防和过程变更管理。这种从项目级到组织级再到优化级的递进逻辑后来被CMMI完整继承下来也是整个模型最精华的部分。1.3 CMM当时解决了什么问题如果用一句话概括CMM的历史价值就是“让过程说人话、让等级可比较”。在CMM出现之前甲方评估乙方能力基本靠面试和印象今天这套在软件工程领域已经司空见惯的做法很大程度上是CMM起的头。实践结果也证明了过程成熟度的价值。大量研究数据表明在类似的项目类型和团队规模下过程成熟度更高的组织缺陷密度、进度偏差、返工成本等核心指标都显著更优。很多当年通过CMM评估的团队发现即使不是为了拿证按照KPA要求把需求管理、配置管理、同行评审这些基础动作做扎实项目质量确实会有立竿见影的提升。不过CMM也不是没有毛病。它太重、太慢对中小团队极其不友好它的KPA之间相对割裂企业容易陷入“为了满足检查项而做文档”的形式主义它只关注纯软件项目在那个系统和硬件深度集成的年代已经开始显得不够用了。2. CMMI的出现为什么要做一次大整合2.1 多套CMM并存的问题CMM成功后各个专业领域开始竞相模仿出现了针对软件工程、系统工程、采购、集成产品开发等不同领域的多套CMM模型。模型一多问题就来了。首先是术语冲突。同一件事软件CMM叫“软件质量保证”系统工程CMM又有一套自己的叫法一个企业同时做软件和系统集成内部培训、体系文件、评估方案都得各写各的体系维护成本非常高。其次当时很多产品的形态已经不再是“纯软件”而是硬件、软件、结构、服务交织在一起的复杂系统。这时候还分着评“软件成熟度”和“系统工程成熟度”对企业来说既不真实也不公平。我记得当时有些规模较大的研发组织光是应付各类模型评估的文档工作就占用了大量资源一线项目经理怨声载道。行业迫切需要一套统一的模型能用同一种语言描述整个产品研发过程。这就是CMMI诞生的直接推动力。CMMI的全称是能力成熟度模型集成“集成”两个字点明它不是一个从零开始的新发明而是把多套CMM打散后重新焊成的一个整体框架。2.2 CMMI的两套表示法阶段式和连续式CMMI在设计上做了一件很聪明的事一套模型同时提供两种表示法组织可以根据自身需要选择使用方式。第一种是阶段式表示法延续CMM的传统思路整体评定成熟度等级Maturity LevelML从1级到5级适合对外展示、招投标、供应商评估这种需要“一个整数等级”的场景。第二种是连续式表示法不再追求一个整体等级而是针对每一个过程域单独评定能力等级Capability LevelCL从0级到3级。组织可以根据自身短板只选择需要改进的过程域单独提升。比如说你的项目管理已经做到位了但配置管理明显拖后腿那就可以只针对配置管理这个过程域做改进和评估不需要把整套体系推翻重来。这两套表示法不是二选一的矛盾关系而是对同一套过程域的不同“投影”。阶段式看重整体成熟度连续式看重局部能力。很多刚接触CMMI的人容易搞混认为阶段式和连续式是两个不同模型其实它们是同一个模型上观察维度的不同。用生活中的例子类比一个是给整栋楼评星级另一个是给楼里每套房间单独打分房子是那一套只是评价视角不同。2.3 过程域、通用实践与模型视图CMMI把CMM里的KPA改叫过程域Process AreaPA内部结构也做了升级。每个过程域下有特定目标Specific GoalSG和通用目标Generic GoalGG。特定目标对应这个过程域独有的能力比如需求管理过程域要求建立需求基线、维护需求双向追溯通用目标则是所有过程域共同要满足的管理要求比如定义过程、提供资源、监督执行等。这个“通用实践”的设计是CMMI相对CMM最重要的升级之一。CMM的KPA之间相对独立改进时必须一个一个去补CMMI则强调通用实践贯穿所有过程域只要组织建立了统一的管理体系各过程域的能力会同步提升改进效率远高于CMM时代。CMMI还按应用场景拆分成多个模型视图最常见的是开发视图CMMI-DEV、服务视图CMMI-SVC和采购视图CMMI-ACQ。软件开发团队默认都走开发视图它的过程域数量在1.3版本里是22个划分为过程管理、项目管理、工程、支持四大类涵盖需求开发、技术解决方案、产品集成、验证、确认、配置管理、测量与分析、风险管理、组织绩效管理等。2018年还发布了2.0版本弱化了传统的“认证等级”味道更强调业务绩效和能力域评分但核心逻辑没有变。对绝大多数人来说先把1.3版本的核心框架吃透再谈2.0不会走错路。3. CMM与CMMI的核心差异一张表看懂3.1 直接摆差异六张对比很多人经常问CMM和CMMI到底差在哪。我用一张表格把最核心的区分点列出来先说结论再展开解释对比维度CMMCMMI定位面向纯软件项目的过程能力评估面向多学科集成产品与服务的过程改进框架等级表示只有阶段式整体成熟度等级1-5阶段式成熟度1-5同时支持连续式能力等级0-3实施单元关键过程域KPA约18个过程域PA开发视图22个适用范围软件开发过程软件、硬件、系统集成、服务、采购术语体系各领域模型各自为政统一的术语与实践描述评估定级满足本级及以下所有KPA阶段式满足对应PA集连续式按PA单独评分配套评估方法早期方法偏检查和文档更强调证据链、访谈与实证验证这张表里藏着两个最容易被忽略的重点一个是CMMI把“连续式”引入了成熟度建模另一个是CMMI从骨子里就是为多学科集成设计的。这两个点放到实际管理场景里影响非常深远。3.2 定级逻辑的差异升级不是走过场CMM时代一个组织要从3级升到4级必须保证2级、3级、4级的所有KPA全部满足任何一个KPA不达标都可能导致整体降级。这种“全有或全无”的评定方式虽然严格但也带来一个问题组织为了通过评估不得不平均用力把精力分散到所有KPA上而不是优先解决自己真正要命的短板。CMMI的定级逻辑本质上还是“目标达成评价”但内部检查维度变得更细。每个过程域不是一整个黑匣子而是由多个目标和实践组成的结构化体系评审组要看的是目标是否达成、实践是否有证据、过程是否真正落地。一个团队光有制度模板是不够的必须在项目实证里找到对应记录。很多第一次参加CMMI评估的团队就是栽在这上面文件写得漂漂亮亮一查项目实际执行全对不上。连续式表示对处于改进过程中的团队价值更大。已经做到成熟度3级的企业完全可以通过连续式对某个薄弱过程域做定向提升不需要为了一个短板把整体等级推倒重来。我见过一个场景系统集成业务比较重的一家公司项目管理整体不错但风险管理一直靠裸奔他们就用连续式方式只针对风险管理过程域做了一次深度改进和评估用很低的成本补齐了最致命的短板。3.3 KPA和PA差距背后的改进理念变化CMM的关键过程域数量有版本差异但大逻辑是一致的每个等级挂着一批KPA等级越高KPA越偏向统计、量化和组织级优化。它天然带着“流程完备度评估”的气息只要实践动作齐全即可至于这些动作是否真的改进了业务结果反而关注得比较少。CMMI的过程域则引入了“目标导向”的评估思路并且分成了特定的四大类。工程类过程域被单独放大包括需求开发、技术解决方案、产品集成、验证、确认这六个过程域直接对应研发全链条很多企业把功夫全花在项目管理和支持类过程域上工程类PA反而成了评估掉分最严重的地方。说白了CMMI比CMM更进一步它不但问你有没有流程还问你做出来的产品靠不靠谱、需求有没有闭环、集成有没有验证过。4. 从CMM到CMMI演进中的关键逻辑4.1 CMMI不是CMM的第6级这是我被问得最多的问题CMMI是不是CMM的更高版本会不会有第六个等级答案是否定的。CMMI不是简单的版本升级而是模型架构上的重构它把软件工程、系统工程、集成产品开发、采购等领域的多个CMM合并成一套统一框架。成熟度等级依然是最高5级并没有出现第6级的概念。两者的关系更像“前身和继承者”而不是“低级和高级”。CMMI继承了CMM最核心的成熟度思想和等级递进逻辑但它重新定义了过程域、通用实践、模型视图。老工程师如果只懂CMM直接上手CMMI通常不会太难受反过来专门学CMMI的新人回头翻CMM资料也不用推倒重来只是多了解一层历史包袱。4.2 术语断档和旧资料映射CMM时代留下的历史资料里面大量使用KPA、关键实践这些词汇。CMMI时代则统一叫过程域、特定实践、通用实践。真正做体系切换的企业最头疼的不是理解新模型而是把旧文档体系映射到新模型上。比如CMM里的“软件质量保证”概念在CMMI里叫“过程和产品质量保证”过程域编号和位置都变了CMM里的“同行评审”在CMMI里归入“验证”过程域的特定实践之一。这个映射表老团队一定要提前做好。我自己的经验是如果公司已经有一批CMM时代的老员工不要急着把旧术语全部弃用。体系文件里保留一段“新旧术语对照表”对老员工心智过渡帮助很大。毕竟过程改进的核心是减少阻力不是为了术语争面子。4.3 CMMI为什么更适合系统化时代CMM诞生时软件还只是大系统中比较小的一块。CMMI出现时软件已经嵌入了几乎每一个产品传统硬件和软件边界变得模糊一个产品团队往往要同时管理机械结构、嵌入式软件、应用软件和数据服务。这种情况下再用CMM这种“只评软件”的老模型显然是刻舟求剑。CMMI用一套模型讲清楚了跨学科过程管理过程域设置天然覆盖需求、设计、实现、集成、验证、确认、交付、支持整个价值链。对团队来说做一个产品、管一套流程、接受一次评估比维持多套并行的体系文件要轻松得多。这也是为什么CMMI能在大规模企业里快速替代CMM因为它适配了现代研发管理的基本形态。5. 落地过程中的常见困惑和实操建议5.1 最常见的三个误解越早纠正越好第一个误解是“CMMI就是CMM加了一些内容”。实际上CMMI不是做加法而是做乘法。它虽然沿用了成熟度等级框架但在过程域定义、目标设定、通用实践、评估方法上彻底重构用CMM的旧经验来套CMMI很容易在评审时翻车。第二个误解是“过了高等级流程就永远完美了”。CMMI等级评定是对当时状态的认可不是永久牌照评估结果有有效期隔几年需要复评。更现实的问题是很多团队在拿到等级证书之后组织架构变动、骨干流失、项目节奏加快过程体系迅速回退下一轮复评前才突击补文档。这样做的成本和风险都极高。第三个误解是“连续式表示比阶段式简单更好过级”。从流程上看连续式确实不用满足全部过程域可以聚焦改进范围但这不意味着证据要求降低。恰恰相反只选择一个PA做评估评审组的注意力会全部集中到这一个过程域上证据链稍有断裂就会被发现。连续式更适合真正有改进需求的成熟团队而不是想走捷径拿证的团队。5.2 准备评估前必须搞清楚的几件事如果团队真实地准备做一次CMMI评估我的建议顺序是先选视图再定目的最后选表示法。视图选择上绝大多数纯软件研发团队选开发视图CMMI-DEV做运维服务的选服务视图CMMI-SVC。很多团队同时有研发和运维觉得选两个视图更有面子实际操作中发现两类过程域的覆盖范围和工作量都会增加第一次评估不建议这么搞。定目的最关键。如果目标是为招投标拿证那么建议找项目管理基础最扎实的一个核心项目做试点集中力量打造标杆再逐步推广。如果目标真是内部过程改进建议不要一开始就上完整评估先按连续式思路挑出最影响交付的两三个过程域例如测量与分析、配置管理、需求管理做一轮差距分析和试点改进看到效果再扩大范围。体系文件一定要克制。我见过不少团队为了“完整性”把流程文件写成了几百页的大部头结果没人看、没人用。好的体系文件是核心过程定义控制在二十到三十页外加一页纸的裁剪指南告诉项目组什么场景必须怎么做、什么场景可以灵活调整。宁可薄不要厚。5.3 我踩过的一些坑写在这里供参考第一过程文件不能由质量部门代写。以前有一家团队为了快速过级把全套文件集中由几个人代写结果现场评审的时候项目成员连自己项目的“裁剪说明”都说不清楚。过程文件应该是项目组自己按模板写质量部门只做辅导和审核这样评审访谈才能对答如流因为事情是他们自己做的。第二同行评审的记录要认真对待。CMMI评审里工程类过程域的访谈评审员最喜欢追问的就是评审记录评审会名单、缺陷记录、返工闭环。很多时候体系文件做得再漂亮评审记录里一没有缺陷清单二没有后续措施直接暴露“纸面符合”问题。第三内部预审非常值得做。正式评估前找一个没有参与过文件编写的同事按模型检查单把项目档案翻一遍。这个做法每次都能挖出一堆“文件写了但没执行”“记录缺失”“责任人不清”的问题成本很低价值极高。第四度量指标不要堆砌。不少团队为了凸显“量化管理”硬凑了几十个质量指标结果管理层根本不用。有效的度量指标应该围绕成本、进度、缺陷建立。先想清楚每个指标给谁看、看完做什么决策再决定要不要统计。最后再说一点个人体会CMM与CMMI的关系我想用一个比喻来收尾CMM是一台老式机械钟表结构精密但只能整体上发条CMMI是一套模块化智能仪表系统可以做整体校准也可以针对单个模块单独调优。CMM给了我那一代从业者最基本的过程意识而CMMI提供了一个更灵活、更贴近现代研发形态的改进框架。我这些年做评估和过程改进最大的转变是不再把“拿几级”当成目标而是用CMMI的连续式思路每个季度挑出最影响交付的两三个过程域对照模型做差距分析改完看指标再定下一轮优先级。这样虽然很难一口气晃出一个漂亮的“5级证书”但团队的交付稳定性、客户满意度、返工率都在实实在在地变好。如果你现在正准备启动过程改进我建议你也先把“为了过级”这个念头放下去做一次诚实的差距分析你会重新认识这套模型的价值。 
长河君 · 2026/10/21 8:58:26 · 阅读 1.2k CMM与CMMI核心差异与过程改进实践全解析
只要在软件研发、项目管理和质量改进这个圈子里待过一段时间一定绕不开两个名字CMM和CMMI。无论是内部做研发过程诊断还是对外应付客户审核、供应商评级这两组字母都会频繁出现。很多人把CMMI简单说成“CMM的升级版”这个说法不算错但远远不够。我今天想从实践者的角度把CMM和CMMI的关系彻底讲清楚CMM是怎么诞生的CMMI为什么要接替它两者在等级框架、评估方式、适用范围上有哪些本质差别以及落到自己公司或项目里真正该关注的又是什么。这篇文章既适合刚入行的项目经理、质量工程师也适合正在准备模型评估、或者在搭建研发管理体系的团队。1. CMM的来龙去脉模型是怎么诞生的1.1 软件危机与过程改进的需求上世纪八十年代软件行业最大的痛点是项目失控。大量项目延期、超预算甚至直接失败有经验的从业者回忆那个时代基本靠个人英雄主义某个优秀工程师在项目就顺人一走项目就崩。背后的根本原因是软件开发没有可控过程的保障大家写代码靠灵感交付靠口号出了问题就靠通宵救火。CMM正是在这种背景下出现的全称是能力成熟度模型。它的核心思路说得直白一点评价一个组织能不能稳定交付软件不要只看它某一次项目的表现要看它是否具备一套可重复、可管理、可改进的过程体系。打个比方如果一个人每次都能煮出好菜可能是天赋但一家厨房如果有标准菜谱、食材管理流程和卫生规范那就是体系能力。CMM评价的是整家厨房的运作能力而不是某一个厨师今天的手感。这个思路在当年非常超前因为它把“看不见的软件开发过程”变成了“可以评估的等级”让采购方有机会在合同签署之前就判断承包商的开发能力。与此同时它也倒逼企业开始重视文档化、配置管理、同行评审这些基本功。很多老工程师都承认CMM时代虽然行政味很重但它确实让“过程”这个词第一次真正进入软件行业的管理话语体系。1.2 五个成熟度等级和关键过程域CMM模型最大的贡献是提出了一套五级成熟度框架等级名称核心特征1级初始级过程无序成功依赖个人能力进度预算经常失控2级可重复级建立基本项目管理过程能够重复过去的成功经验3级已定义级组织层面有标准过程项目在标准基础上做裁剪4级已管理级用统计手段量化管理过程和产品质量能够预测趋势5级优化级主动识别过程缺陷并持续改进组织具备自我进化能力每个等级由若干关键过程域KPAKey Process Area支撑。一个组织想要达到某个等级必须满足该等级以及以下所有等级的全部KPA。比如要达到3级2级的六个KPA也必须全部满足。这里有个细节值得留意CMM的KPA是有“资源密度的”。2级偏重项目管理基本功像需求管理、项目计划、项目跟踪、软件质量保证、软件配置管理3级开始进入组织级能力比如组织过程定义、培训程序、同行评审4级上升到量化管理5级则是缺陷预防和过程变更管理。这种从项目级到组织级再到优化级的递进逻辑后来被CMMI完整继承下来也是整个模型最精华的部分。1.3 CMM当时解决了什么问题如果用一句话概括CMM的历史价值就是“让过程说人话、让等级可比较”。在CMM出现之前甲方评估乙方能力基本靠面试和印象今天这套在软件工程领域已经司空见惯的做法很大程度上是CMM起的头。实践结果也证明了过程成熟度的价值。大量研究数据表明在类似的项目类型和团队规模下过程成熟度更高的组织缺陷密度、进度偏差、返工成本等核心指标都显著更优。很多当年通过CMM评估的团队发现即使不是为了拿证按照KPA要求把需求管理、配置管理、同行评审这些基础动作做扎实项目质量确实会有立竿见影的提升。不过CMM也不是没有毛病。它太重、太慢对中小团队极其不友好它的KPA之间相对割裂企业容易陷入“为了满足检查项而做文档”的形式主义它只关注纯软件项目在那个系统和硬件深度集成的年代已经开始显得不够用了。2. CMMI的出现为什么要做一次大整合2.1 多套CMM并存的问题CMM成功后各个专业领域开始竞相模仿出现了针对软件工程、系统工程、采购、集成产品开发等不同领域的多套CMM模型。模型一多问题就来了。首先是术语冲突。同一件事软件CMM叫“软件质量保证”系统工程CMM又有一套自己的叫法一个企业同时做软件和系统集成内部培训、体系文件、评估方案都得各写各的体系维护成本非常高。其次当时很多产品的形态已经不再是“纯软件”而是硬件、软件、结构、服务交织在一起的复杂系统。这时候还分着评“软件成熟度”和“系统工程成熟度”对企业来说既不真实也不公平。我记得当时有些规模较大的研发组织光是应付各类模型评估的文档工作就占用了大量资源一线项目经理怨声载道。行业迫切需要一套统一的模型能用同一种语言描述整个产品研发过程。这就是CMMI诞生的直接推动力。CMMI的全称是能力成熟度模型集成“集成”两个字点明它不是一个从零开始的新发明而是把多套CMM打散后重新焊成的一个整体框架。2.2 CMMI的两套表示法阶段式和连续式CMMI在设计上做了一件很聪明的事一套模型同时提供两种表示法组织可以根据自身需要选择使用方式。第一种是阶段式表示法延续CMM的传统思路整体评定成熟度等级Maturity LevelML从1级到5级适合对外展示、招投标、供应商评估这种需要“一个整数等级”的场景。第二种是连续式表示法不再追求一个整体等级而是针对每一个过程域单独评定能力等级Capability LevelCL从0级到3级。组织可以根据自身短板只选择需要改进的过程域单独提升。比如说你的项目管理已经做到位了但配置管理明显拖后腿那就可以只针对配置管理这个过程域做改进和评估不需要把整套体系推翻重来。这两套表示法不是二选一的矛盾关系而是对同一套过程域的不同“投影”。阶段式看重整体成熟度连续式看重局部能力。很多刚接触CMMI的人容易搞混认为阶段式和连续式是两个不同模型其实它们是同一个模型上观察维度的不同。用生活中的例子类比一个是给整栋楼评星级另一个是给楼里每套房间单独打分房子是那一套只是评价视角不同。2.3 过程域、通用实践与模型视图CMMI把CMM里的KPA改叫过程域Process AreaPA内部结构也做了升级。每个过程域下有特定目标Specific GoalSG和通用目标Generic GoalGG。特定目标对应这个过程域独有的能力比如需求管理过程域要求建立需求基线、维护需求双向追溯通用目标则是所有过程域共同要满足的管理要求比如定义过程、提供资源、监督执行等。这个“通用实践”的设计是CMMI相对CMM最重要的升级之一。CMM的KPA之间相对独立改进时必须一个一个去补CMMI则强调通用实践贯穿所有过程域只要组织建立了统一的管理体系各过程域的能力会同步提升改进效率远高于CMM时代。CMMI还按应用场景拆分成多个模型视图最常见的是开发视图CMMI-DEV、服务视图CMMI-SVC和采购视图CMMI-ACQ。软件开发团队默认都走开发视图它的过程域数量在1.3版本里是22个划分为过程管理、项目管理、工程、支持四大类涵盖需求开发、技术解决方案、产品集成、验证、确认、配置管理、测量与分析、风险管理、组织绩效管理等。2018年还发布了2.0版本弱化了传统的“认证等级”味道更强调业务绩效和能力域评分但核心逻辑没有变。对绝大多数人来说先把1.3版本的核心框架吃透再谈2.0不会走错路。3. CMM与CMMI的核心差异一张表看懂3.1 直接摆差异六张对比很多人经常问CMM和CMMI到底差在哪。我用一张表格把最核心的区分点列出来先说结论再展开解释对比维度CMMCMMI定位面向纯软件项目的过程能力评估面向多学科集成产品与服务的过程改进框架等级表示只有阶段式整体成熟度等级1-5阶段式成熟度1-5同时支持连续式能力等级0-3实施单元关键过程域KPA约18个过程域PA开发视图22个适用范围软件开发过程软件、硬件、系统集成、服务、采购术语体系各领域模型各自为政统一的术语与实践描述评估定级满足本级及以下所有KPA阶段式满足对应PA集连续式按PA单独评分配套评估方法早期方法偏检查和文档更强调证据链、访谈与实证验证这张表里藏着两个最容易被忽略的重点一个是CMMI把“连续式”引入了成熟度建模另一个是CMMI从骨子里就是为多学科集成设计的。这两个点放到实际管理场景里影响非常深远。3.2 定级逻辑的差异升级不是走过场CMM时代一个组织要从3级升到4级必须保证2级、3级、4级的所有KPA全部满足任何一个KPA不达标都可能导致整体降级。这种“全有或全无”的评定方式虽然严格但也带来一个问题组织为了通过评估不得不平均用力把精力分散到所有KPA上而不是优先解决自己真正要命的短板。CMMI的定级逻辑本质上还是“目标达成评价”但内部检查维度变得更细。每个过程域不是一整个黑匣子而是由多个目标和实践组成的结构化体系评审组要看的是目标是否达成、实践是否有证据、过程是否真正落地。一个团队光有制度模板是不够的必须在项目实证里找到对应记录。很多第一次参加CMMI评估的团队就是栽在这上面文件写得漂漂亮亮一查项目实际执行全对不上。连续式表示对处于改进过程中的团队价值更大。已经做到成熟度3级的企业完全可以通过连续式对某个薄弱过程域做定向提升不需要为了一个短板把整体等级推倒重来。我见过一个场景系统集成业务比较重的一家公司项目管理整体不错但风险管理一直靠裸奔他们就用连续式方式只针对风险管理过程域做了一次深度改进和评估用很低的成本补齐了最致命的短板。3.3 KPA和PA差距背后的改进理念变化CMM的关键过程域数量有版本差异但大逻辑是一致的每个等级挂着一批KPA等级越高KPA越偏向统计、量化和组织级优化。它天然带着“流程完备度评估”的气息只要实践动作齐全即可至于这些动作是否真的改进了业务结果反而关注得比较少。CMMI的过程域则引入了“目标导向”的评估思路并且分成了特定的四大类。工程类过程域被单独放大包括需求开发、技术解决方案、产品集成、验证、确认这六个过程域直接对应研发全链条很多企业把功夫全花在项目管理和支持类过程域上工程类PA反而成了评估掉分最严重的地方。说白了CMMI比CMM更进一步它不但问你有没有流程还问你做出来的产品靠不靠谱、需求有没有闭环、集成有没有验证过。4. 从CMM到CMMI演进中的关键逻辑4.1 CMMI不是CMM的第6级这是我被问得最多的问题CMMI是不是CMM的更高版本会不会有第六个等级答案是否定的。CMMI不是简单的版本升级而是模型架构上的重构它把软件工程、系统工程、集成产品开发、采购等领域的多个CMM合并成一套统一框架。成熟度等级依然是最高5级并没有出现第6级的概念。两者的关系更像“前身和继承者”而不是“低级和高级”。CMMI继承了CMM最核心的成熟度思想和等级递进逻辑但它重新定义了过程域、通用实践、模型视图。老工程师如果只懂CMM直接上手CMMI通常不会太难受反过来专门学CMMI的新人回头翻CMM资料也不用推倒重来只是多了解一层历史包袱。4.2 术语断档和旧资料映射CMM时代留下的历史资料里面大量使用KPA、关键实践这些词汇。CMMI时代则统一叫过程域、特定实践、通用实践。真正做体系切换的企业最头疼的不是理解新模型而是把旧文档体系映射到新模型上。比如CMM里的“软件质量保证”概念在CMMI里叫“过程和产品质量保证”过程域编号和位置都变了CMM里的“同行评审”在CMMI里归入“验证”过程域的特定实践之一。这个映射表老团队一定要提前做好。我自己的经验是如果公司已经有一批CMM时代的老员工不要急着把旧术语全部弃用。体系文件里保留一段“新旧术语对照表”对老员工心智过渡帮助很大。毕竟过程改进的核心是减少阻力不是为了术语争面子。4.3 CMMI为什么更适合系统化时代CMM诞生时软件还只是大系统中比较小的一块。CMMI出现时软件已经嵌入了几乎每一个产品传统硬件和软件边界变得模糊一个产品团队往往要同时管理机械结构、嵌入式软件、应用软件和数据服务。这种情况下再用CMM这种“只评软件”的老模型显然是刻舟求剑。CMMI用一套模型讲清楚了跨学科过程管理过程域设置天然覆盖需求、设计、实现、集成、验证、确认、交付、支持整个价值链。对团队来说做一个产品、管一套流程、接受一次评估比维持多套并行的体系文件要轻松得多。这也是为什么CMMI能在大规模企业里快速替代CMM因为它适配了现代研发管理的基本形态。5. 落地过程中的常见困惑和实操建议5.1 最常见的三个误解越早纠正越好第一个误解是“CMMI就是CMM加了一些内容”。实际上CMMI不是做加法而是做乘法。它虽然沿用了成熟度等级框架但在过程域定义、目标设定、通用实践、评估方法上彻底重构用CMM的旧经验来套CMMI很容易在评审时翻车。第二个误解是“过了高等级流程就永远完美了”。CMMI等级评定是对当时状态的认可不是永久牌照评估结果有有效期隔几年需要复评。更现实的问题是很多团队在拿到等级证书之后组织架构变动、骨干流失、项目节奏加快过程体系迅速回退下一轮复评前才突击补文档。这样做的成本和风险都极高。第三个误解是“连续式表示比阶段式简单更好过级”。从流程上看连续式确实不用满足全部过程域可以聚焦改进范围但这不意味着证据要求降低。恰恰相反只选择一个PA做评估评审组的注意力会全部集中到这一个过程域上证据链稍有断裂就会被发现。连续式更适合真正有改进需求的成熟团队而不是想走捷径拿证的团队。5.2 准备评估前必须搞清楚的几件事如果团队真实地准备做一次CMMI评估我的建议顺序是先选视图再定目的最后选表示法。视图选择上绝大多数纯软件研发团队选开发视图CMMI-DEV做运维服务的选服务视图CMMI-SVC。很多团队同时有研发和运维觉得选两个视图更有面子实际操作中发现两类过程域的覆盖范围和工作量都会增加第一次评估不建议这么搞。定目的最关键。如果目标是为招投标拿证那么建议找项目管理基础最扎实的一个核心项目做试点集中力量打造标杆再逐步推广。如果目标真是内部过程改进建议不要一开始就上完整评估先按连续式思路挑出最影响交付的两三个过程域例如测量与分析、配置管理、需求管理做一轮差距分析和试点改进看到效果再扩大范围。体系文件一定要克制。我见过不少团队为了“完整性”把流程文件写成了几百页的大部头结果没人看、没人用。好的体系文件是核心过程定义控制在二十到三十页外加一页纸的裁剪指南告诉项目组什么场景必须怎么做、什么场景可以灵活调整。宁可薄不要厚。5.3 我踩过的一些坑写在这里供参考第一过程文件不能由质量部门代写。以前有一家团队为了快速过级把全套文件集中由几个人代写结果现场评审的时候项目成员连自己项目的“裁剪说明”都说不清楚。过程文件应该是项目组自己按模板写质量部门只做辅导和审核这样评审访谈才能对答如流因为事情是他们自己做的。第二同行评审的记录要认真对待。CMMI评审里工程类过程域的访谈评审员最喜欢追问的就是评审记录评审会名单、缺陷记录、返工闭环。很多时候体系文件做得再漂亮评审记录里一没有缺陷清单二没有后续措施直接暴露“纸面符合”问题。第三内部预审非常值得做。正式评估前找一个没有参与过文件编写的同事按模型检查单把项目档案翻一遍。这个做法每次都能挖出一堆“文件写了但没执行”“记录缺失”“责任人不清”的问题成本很低价值极高。第四度量指标不要堆砌。不少团队为了凸显“量化管理”硬凑了几十个质量指标结果管理层根本不用。有效的度量指标应该围绕成本、进度、缺陷建立。先想清楚每个指标给谁看、看完做什么决策再决定要不要统计。最后再说一点个人体会CMM与CMMI的关系我想用一个比喻来收尾CMM是一台老式机械钟表结构精密但只能整体上发条CMMI是一套模块化智能仪表系统可以做整体校准也可以针对单个模块单独调优。CMM给了我那一代从业者最基本的过程意识而CMMI提供了一个更灵活、更贴近现代研发形态的改进框架。我这些年做评估和过程改进最大的转变是不再把“拿几级”当成目标而是用CMMI的连续式思路每个季度挑出最影响交付的两三个过程域对照模型做差距分析改完看指标再定下一轮优先级。这样虽然很难一口气晃出一个漂亮的“5级证书”但团队的交付稳定性、客户满意度、返工率都在实实在在地变好。如果你现在正准备启动过程改进我建议你也先把“为了过级”这个念头放下去做一次诚实的差距分析你会重新认识这套模型的价值。