我隔三差五就会收到类似的问题我们公司要投标一个大客户对方在合同里明确写了要求CMMI三级可网上还有人在说先做CMMCMM和CMMI到底什么关系这两个名字实在太像了很多人在刚接触过程改进时会把CMM、CMMI混着用甚至有人以为CMMI只是CMM的缩写写法。实际上CMM和CMMI是两套有着直接血缘关系、但定位完全不同的模型。理解它们的关系不只是为了搞清楚几个名词更关系到你在团队里做过程改进时到底该借鉴哪套方法论、该以什么节奏推进。这篇文章我不打算端着教科书讲就从我这些年和这两个模型打交道的经验出发把它们的来龙去脉、等级结构、核心区别、选型建议以及落地时容易踩的坑一次讲清楚。适合正准备做过程改进的团队负责人、正在准备CMMI评估的工程师以及只是想真正搞明白这两个名词的人。1. 从CMM到CMMI的演进逻辑1.1 CMM出现之前软件管理面临什么问题上世纪八十年代末期软件工程领域最大的痛不是某个技术不会用而是结果太不稳定。同样一批人上一个项目干得漂亮下一个项目却拖了半年质量一塌糊涂。代码写得好不好往往取决于团队里有没有一两个“牛人”管理者很难解释清楚为什么换个人、换个项目整个团队就完全失控了当时有个很关键的观察被反复验证软件开发的成功与否很大程度上不取决于某个程序员个人的水平而取决于整个组织是不是有稳定的、可重复的开发和项目管理方式。一个组织如果没有任何沉淀所有成功都靠运气那它本质上就是不可靠的。这种思路催生了“过程能力”这个概念——你不仅要关注结果更要关注产生这个结果的流程是不是稳定的。1.2 五级成熟度框架的诞生基于这样的背景一家知名的软件工程研究所组织了一批软件工程专家系统调研了大量成功和失败的项目提出了一套软件过程成熟度框架这就是CMM的雏形。CMM全称Capability Maturity Model能力成熟度模型。它把人从“新手”到“成熟管理者”的成长路径——刚开始毫无章法、慢慢积累经验、形成规范、用数据驱动、持续优化——映射成软件组织的成熟度等级一共五级。这个映射方式非常巧妙它第一次把“好的软件管理长什么样”变成了一套可评估、可打分、可认证的框架。在CMM之前各家企业都说自己做项目管理很厉害但谁也说不清“厉害”到底具体指什么。CMM之后你可以对照五级标准说我处于二级因为需求管理、项目计划、配置管理这些基本实践都建立了。1.3 为什么需要“集成”CMM在软件领域取得成功之后系统工程、硬件工程、采购管理等领域也效仿推出了类似模型。单看每个模型都有道理但放在一个企业里就出问题了业务通常不是单一学科的做一套复杂的系统集成项目可能同时涉及软件、硬件、系统设计、采购分包。这个时候企业要应付好几套不同的模型术语不统一、评估成本高、改进方向还互相冲突。于是负责维护这套框架的组织开始启动整合工作把软件、系统、硬件、采购等多个学科的成熟度模型整合成一个统一框架这就是CMMI全称Capability Maturity Model Integration能力成熟度模型集成。注意这个“I”很多人以为是“Improvement”改进实际上是“Integration”集成。CMMI不是简单地在CMM上修修补补而是把多个模型彻底打散重组。CMMI第一个正式版本发布是在2000年前后后续经历了v1.1、v1.2、v1.3一直到v2.0。到今天CMMI依旧活跃在各类研发管理、招投标、外包准入场景里。理解了这个演进逻辑你就明白CMM并没有“死”它只是被吸收到了一个更庞大的框架里变成了CMMI的一部分基因。2. CMM的成熟度等级到底在衡量什么2.1 五级阶梯的核心特征要理清CMM和CMMI的关系必须先吃透CMM本身就有的五级阶梯。我把它用最直白的方式拆解一下等级名称核心特征典型表现1级初始级过程不可预测靠英雄人物救火项目进度全靠人盯经验无法复制延期是常态2级已管理级单个项目的管理基本建立经验可重复需求、计划、配置管理有章法同类项目能重复成功3级已定义级组织级标准过程成型项目按标准裁剪使用跨项目打法一致新人能按流程快速上手4级量化管理级用数据和统计方法管理过程通过量化指标预测工期和质量而不是事后补救5级优化级持续改进成为组织习惯组织主动找瓶颈、主动消除根因而不只是“不出事故”很多初学者容易把这五级背成顺口溜却不理解背后的逻辑。我给一个生活化类比一个做饭的厨房1级是什么都靠主厨换个人就乱2级是有了菜谱和流程照着做能出一样的菜3级是整个后厨建立了统一的操作规范和培训体系4级是后厨用出菜时间、客诉率这些数据来调整备菜流程5级是后厨每周都会主动复盘做实验改进口味。每一级都是在下一级基础上多了一层“体系化”。2.2 等级背后的关键过程域CMM不是空谈等级每个成熟度等级都对应一组“关键过程域”英文缩写KPA。以CMM v1.1为例二级到五级分布如下二级已管理级需求管理、软件项目计划、软件项目跟踪和监控、软件子合同管理、软件质量保证、软件配置管理共6个。三级已定义级组织过程焦点、组织过程定义、培训程序、集成软件管理、软件产品工程、组间协调、同行评审共7个。四级已管理级定量过程管理、软件质量管理共2个。五级优化级缺陷预防、技术变更管理、过程变更管理共3个。这里值得琢磨的是过程域的排序逻辑。为什么需求管理放在二级而不是三级因为二级关注的是单个项目能不能可控需求如果管不住后面的计划全是空中楼阁。为什么同行评审放在三级而不是塞进质量保证因为CMM认为质量是工程活动中“内建”出来的不是靠事后检查查出来的。这种排序本身就是在传递一种工程价值观。2.3 CMM的局限CMM的局限也很明显。首先它只面向软件工程做系统集成、硬件开发、IT服务的团队很难直接套用。其次CMM时代对文档的要求非常重很多企业为了过级不得不大量造文档导致“过程和现实两张皮”这也是后来被诟病最多的地方。还有一点CMM只有一个整体评级你想单独改进某个薄弱环节比如只把配置管理做扎实其他方面先不动在CMM的框架里很难操作因为过级必须按等级整体满足。这些局限恰好解释了为什么CMMI要在框架层面做两个根本性的变化一是覆盖面大扩二是引入连续式表示法。3. CMMI的框架设计与两种表示法3.1 阶段式表示法延续CMM的五级阶梯CMMI的“阶段式表示法”与CMM一脉相承仍然用1到5的成熟度等级来描述组织整体水平。你申请CMMI三级评估评估师按照三级要求的全部过程域和实践去核验通过了就给三级证书。这个逻辑和CMM几乎没有差别所以很多做过CMM老评估的老团队看到CMMI阶段式表示法时会觉得特别亲切。但CMMI的阶段式和CMM时代相比过程域做了重排和扩展。在常见的软件加系统工程配置下CMMI v1.3一共有22个过程域分成四类过程管理类组织过程重点、组织过程定义、组织培训、组织过程绩效、组织革新与部署。项目管理类项目计划、项目监控与控制、供应商协议管理、集成项目管理、风险管理、量化项目管理。工程类需求开发、需求管理、技术解决方案、产品集成、验证、确认。支持类配置管理、过程与产品质量保证、测量与分析、决策分析与解决方案、原因分析与解决方案。对比CMM的18个KPACMMI不只是数量多了还加入了风险管理、决策分析这类更贴近现代项目管理实践的领域。需求开发和需求管理被拆成两个过程域一个管“挖掘和定义”一个管“基线化和变更控制”细粒度明显提升。3.2 连续式表示法CMMI最重要的增量CMMI真正的突破是引入了连续式表示法。连续式不再要求你整体评一个等级而是针对每个过程域单独打分用“能力等级”0到5来衡量0级表示未完成5级表示最高水平。这里打个比方阶段式相当于“整年级排名”你被评为五年级就是所有核心科目都达到五年级要求连续式相当于“单科成绩单”语文可以是一年级数学可以是三年级英语可以是五年级互不拖累。阶段式适合需要给外部一个整体认定的场景比如投标时亮证书连续式则非常适合组织内部做针对性改进哪里痛补哪里。我自己见过一个很典型的例子。某团队做嵌入式开发整体项目管理还行但配置管理一直混乱版本经常合错发布前总要回滚。如果他们走阶段式路径为了拿到二级证书得把二级要求的所有过程域都补齐工程量太大。换了连续式之后他们只挑“配置管理”这一个过程域从1级往4级推三个月后版本管理问题明显改善。这种“单科突破”的路径在CMM时代是不存在的。3.3 从制度化到通用实践CMM和CMMI都极其强调“制度化”——好的做法不能只靠一两个人自觉必须变成组织的规定动作。CMM里用“共同特征”表达对过程的承诺、执行能力、执行活动、测量与分析、验证实现。CMMI沿用了这个思想但把它转化成更清晰的“通用目标”和“通用实践”体系。CMMI里的通用目标GG1到GG3分别要求过程域的目标被达成、实践被制度化、过程被定义为组织资产。GG4和GG5则要求用统计方法管理过程并持续优化。每一级通用实践前面都有“制度化”这个前缀它的意思是不是问“你做了没有”而是问“你如何保证持续地做”。这一层表达比CMM时代的共同特征更可操作、更便于评估员核验。4. CMM与CMMI的核心区别4.1 一张表看清差异很多人只想知道结论那我先把关键区别铺成一张表再逐条展开讲“为什么”。维度CMMCMMI全称Capability Maturity ModelCapability Maturity Model Integration首版时间1991年前后2000年前后覆盖面仅软件工程软件、系统、硬件、服务、采购等等级表示法只有阶段式五级阶段式连续式两种过程域数量18个关键过程域22个过程域v1.3常见配置评估方法老式SEI评估方法SCAMPI A/B/C三类评估结果成熟度等级1-5成熟度等级1-5或能力等级0-5制度化的表达共同特征通用目标通用实践敏捷适配度几乎没有v2.0明显增强4.2 从“单一学科”到“多学科集成”CMM全称里的“Capability Maturity Model”没有限定领域但你翻开CMM文件通篇都在讲软件。这个定位在早期很清晰后来却成了天花板。现代项目的形态越来越复杂一个产品往往软件、硬件、系统、采购、服务交织在一起。CMMI把这些学科的实践统一框架化让一个做软硬结合产品的公司可以用同一套评估标准贯穿整个研发链条。实际操作中还有一个很现实的差异CMM时代软件团队和系统工程团队往往各有一套流程、各做各的改进到了CMMI时代标准维护组织提供的框架天然要求你打破部门边界把跨学科流程统一起来。我见过不少老牌企业做完CMMI评估之后研发、测试、运维、项目管理第一次坐下来一起定义统一流程这种组织层面的副作用比证书本身更有价值。4.3 从“关键过程域”到“过程域”从“共同特征”到“通用实践”CMM把那些重要实践叫“关键过程域”CMMI直接叫“过程域”。这个细微改动背后有深意CMM时期一个组织只关注“关键”过程域就够了容易让企业忽略那些“不关键”的部分CMMI认为要保证整体能力所有过程域都应该被纳入管理视野只是推进节奏可以不同。制度化表达的变化更值得关注。CMM的共同特征是一种“检查清单”思维问你有没有承诺、有没有能力、有没有活动、有没有度量、有没有验证。CMMI的通用实践则是一种“进化阶梯”思维先做到基本实践再把实践沉淀为组织标准再用统计分析管理最后持续优化。前者是“一件事做到五面俱全”后者是“一个实践逐步升级”维度完全不同。4.4 评估方法和商业场景的差异最后说评估。CMM时代使用的老式SEI评估方法在商业化的今天已经彻底退出主流。CMMI时代统一使用SCAMPI方法分三类A类评估最正式需要评估师进场综合文档审查、人员访谈、项目现场观察三类证据通过后可以发放证书B类用于内部自评估不发证C类用于快速差距分析半天到一天就能出结论。这点对准备过级的企业非常重要。SCAMPI A类的证据三件套里访谈和现场观察恰恰是很多人最容易翻车的地方。你文档写得再漂亮评估师随机抽几个项目经理聊天发现实际执行和文档对不上问题就大了。这也是CMMI和CMM最大的现实差别之一CMM时代还有人能靠纸面文章蒙混过关CMMI的访谈环节逼着企业必须“纸上写的和实际做的”保持一致。5. 企业落地时的选择与常见误区5.1 什么场景该选CMMI先说结论今天在企业实操层面你基本不会再碰到“要不要做CMM认证”的选择题。CMM这个名称已经退出主流商业服务现在市场上能做的成熟度认证基本就是CMMI。需要做CMMI的场景集中在三类商业准入甲方招标文件明确写了CMMI等级要求没有证书连投标资格都没有。这在政务类项目、大型国企类项目、出口外包类项目里特别常见。内部管理升级团队规模上来了项目一多就乱靠救火队式管理撑不下去需要用成熟度阶梯把计划、需求、质量、配置等基础管理动作固化下来。组织能力资产化公司想减少因人而异的项目风险把散落在几个骨干脑子里的经验提炼成组织标准过程。5.2 关于“选几级”的现实建议很多老板一开口就要做CMMI五级好像级别越高越有面子。我做过的每一个真实评估项目都在提醒我从二级或三级起步才是绝大多数团队理性选择。二级解决的是“单项目能不能按计划走”的问题适合那些项目流程还靠人盯、文档和代码管理一团糟的团队。三级解决的是“不同项目能不能共用一套打法”的问题适合已经能稳定交付、但各项目各自为战的团队。四级和五级要求的量化管理和持续优化没有数据积累和工程文化支撑基本做不出来。如果组织基础薄弱硬跳级过五级实际结果是两个要么评估前疯狂赶材料评估后所有流程迅速还原要么为了满足量化要求造一堆没人看的度量报表。这两种结果都违背了过程改进的本意。5.3 四个特别常见的坑第一“CMMI过级等于写文档”。这种理解最危险。CMMI核验的是实践是否真实存在文档只是实践痕迹的一种载体不是目标本身。只重文档的企业很容易在访谈环节被评估师追问到漏洞百出。第二“用了敏捷就不能搞CMMI”。CMMI v2.0已经把敏捷和DevOps实践纳入框架两者不是对立关系。真正有效的路径是用敏捷的方式做迭代开发用CMMI的实践域保证敏捷过程被定义、被度量、被持续改进。把二者对立往往是既不懂敏捷也不懂CMMI。第三“咨询公司包过就等于万事大吉”。包装得再漂亮如果实际流程没有改变第二年监督评估时就会现出原形。我见过不止一家企业证书拿到手内部却一点变化都没有最后导致团队对CMMI彻底失去信任认为这只是一场表演。第四“有CMM基础升级CMMI很容易”。历史上有企业做过CMM成熟度评估后续要转CMMI仍然要重新做差距分析、重新定义过程域映射、重新准备证据。框架变了评估方法变了证明标准也变了不能说“升级”只能说“迁移”。6. 实操观察用好这套框架比拿证更重要6.1 一个让我印象深刻的对照有位工程师来找我说公司过完CMMI三级发版还是天天加班质量也没变好他怀疑CMMI是不是就是一个纯骗钱的证书。我说你先别急着下结论回答我三个问题你们过级之后有人真正维护过“组织标准过程”这个文档库吗你们每个迭代有没有人去分析度量数据你们项目的复盘结论有没有回流到流程定义里去如果三个全没有那你们过的三级就只是一个挂在墙上的证书。CMMI本身没有问题问题在于很多企业把“通过评估”当成终点而不是把“组织过程资产持续运转”当成起点。6.2 我建议你从这套框架里真正拿走的东西哪怕你所在的公司不打算做CMMI认证我也建议你理解这两套模型背后的工程管理思想。以下是我实操之后觉得最“值钱”的部分第一把组织经验显性化。CMMI里的组织过程定义、组织过程重点这几个过程域本质上是逼着公司把散落在个人脑子的经验抽出来沉淀成文档库和流程库。哪怕是十个人的小团队这件事做了人员流动风险就会明显降低。第二把过程改进从一个“项目”变成一种“机制”。最有效的做法是成立一个三到五人的过程改进小组每季度选一个真实痛点比如“发布总是回滚”“需求反复变更”用CMMI的通用实践思路来改善。一段时间只聚焦一件事比全面铺开有效得多。第三借用连续式思维做局部精进。不要等公司下定决心整体过级才去思考过程成熟度。挑当前最痛的一个过程域比如配置管理、需求开发、决策分析单独把它提升到高能力等级。三个月的局部改进往往比一年的花架子评估更让团队受益。6.3 如果正在准备评估给几句实在话如果你已经在准备CMMI评估我的建议是差距分析阶段一定要让内部骨干深度参与不要把全部工作打包给咨询公司。内部的人最清楚流程哪些地方是空的、哪些地方是写了但没人执行的。评估访谈前让不同角色的同事用自己的话复述流程不要背标准条款。另外送审项目不要专门挑“最优秀的三个项目”去展示。评估师经验丰富你挑得太完美反而容易增加访谈追问深度。选几个有代表性的真实项目有些不算完美、但过程和文档能对得上这样的证据链反而更可信。还有评估结束之后把评估师的发现和建议整理成行动清单每个季度回顾一次这才是这套框架对团队产生长期价值的开始。这些年我见过太多关于CMM和CMMI的争论有人把它们说得神乎其神有人不屑一顾。我的真实感受是这两个模型本质上都是“把好工程实践显性化”的工具CMM打下了骨架CMMI把它扩大并加固。证书有保质期但过程能力没有。你从这套框架里真正要学的不是怎么写文档、怎么凑证据而是怎么用一套系统的眼光审视自己团队的工程成熟度到底处在哪个位置。哪怕你所在的公司完全不碰CMMI认证把五级阶梯的思路拿回来对照自己的项目流程逐条问一句“我们现在处在哪一级”就已经值回票价。 
长河君 · 2026/10/21 8:58:26 · 阅读 1.2k CMM与CMMI的关系、区别及企业过程改进落地指南
我隔三差五就会收到类似的问题我们公司要投标一个大客户对方在合同里明确写了要求CMMI三级可网上还有人在说先做CMMCMM和CMMI到底什么关系这两个名字实在太像了很多人在刚接触过程改进时会把CMM、CMMI混着用甚至有人以为CMMI只是CMM的缩写写法。实际上CMM和CMMI是两套有着直接血缘关系、但定位完全不同的模型。理解它们的关系不只是为了搞清楚几个名词更关系到你在团队里做过程改进时到底该借鉴哪套方法论、该以什么节奏推进。这篇文章我不打算端着教科书讲就从我这些年和这两个模型打交道的经验出发把它们的来龙去脉、等级结构、核心区别、选型建议以及落地时容易踩的坑一次讲清楚。适合正准备做过程改进的团队负责人、正在准备CMMI评估的工程师以及只是想真正搞明白这两个名词的人。1. 从CMM到CMMI的演进逻辑1.1 CMM出现之前软件管理面临什么问题上世纪八十年代末期软件工程领域最大的痛不是某个技术不会用而是结果太不稳定。同样一批人上一个项目干得漂亮下一个项目却拖了半年质量一塌糊涂。代码写得好不好往往取决于团队里有没有一两个“牛人”管理者很难解释清楚为什么换个人、换个项目整个团队就完全失控了当时有个很关键的观察被反复验证软件开发的成功与否很大程度上不取决于某个程序员个人的水平而取决于整个组织是不是有稳定的、可重复的开发和项目管理方式。一个组织如果没有任何沉淀所有成功都靠运气那它本质上就是不可靠的。这种思路催生了“过程能力”这个概念——你不仅要关注结果更要关注产生这个结果的流程是不是稳定的。1.2 五级成熟度框架的诞生基于这样的背景一家知名的软件工程研究所组织了一批软件工程专家系统调研了大量成功和失败的项目提出了一套软件过程成熟度框架这就是CMM的雏形。CMM全称Capability Maturity Model能力成熟度模型。它把人从“新手”到“成熟管理者”的成长路径——刚开始毫无章法、慢慢积累经验、形成规范、用数据驱动、持续优化——映射成软件组织的成熟度等级一共五级。这个映射方式非常巧妙它第一次把“好的软件管理长什么样”变成了一套可评估、可打分、可认证的框架。在CMM之前各家企业都说自己做项目管理很厉害但谁也说不清“厉害”到底具体指什么。CMM之后你可以对照五级标准说我处于二级因为需求管理、项目计划、配置管理这些基本实践都建立了。1.3 为什么需要“集成”CMM在软件领域取得成功之后系统工程、硬件工程、采购管理等领域也效仿推出了类似模型。单看每个模型都有道理但放在一个企业里就出问题了业务通常不是单一学科的做一套复杂的系统集成项目可能同时涉及软件、硬件、系统设计、采购分包。这个时候企业要应付好几套不同的模型术语不统一、评估成本高、改进方向还互相冲突。于是负责维护这套框架的组织开始启动整合工作把软件、系统、硬件、采购等多个学科的成熟度模型整合成一个统一框架这就是CMMI全称Capability Maturity Model Integration能力成熟度模型集成。注意这个“I”很多人以为是“Improvement”改进实际上是“Integration”集成。CMMI不是简单地在CMM上修修补补而是把多个模型彻底打散重组。CMMI第一个正式版本发布是在2000年前后后续经历了v1.1、v1.2、v1.3一直到v2.0。到今天CMMI依旧活跃在各类研发管理、招投标、外包准入场景里。理解了这个演进逻辑你就明白CMM并没有“死”它只是被吸收到了一个更庞大的框架里变成了CMMI的一部分基因。2. CMM的成熟度等级到底在衡量什么2.1 五级阶梯的核心特征要理清CMM和CMMI的关系必须先吃透CMM本身就有的五级阶梯。我把它用最直白的方式拆解一下等级名称核心特征典型表现1级初始级过程不可预测靠英雄人物救火项目进度全靠人盯经验无法复制延期是常态2级已管理级单个项目的管理基本建立经验可重复需求、计划、配置管理有章法同类项目能重复成功3级已定义级组织级标准过程成型项目按标准裁剪使用跨项目打法一致新人能按流程快速上手4级量化管理级用数据和统计方法管理过程通过量化指标预测工期和质量而不是事后补救5级优化级持续改进成为组织习惯组织主动找瓶颈、主动消除根因而不只是“不出事故”很多初学者容易把这五级背成顺口溜却不理解背后的逻辑。我给一个生活化类比一个做饭的厨房1级是什么都靠主厨换个人就乱2级是有了菜谱和流程照着做能出一样的菜3级是整个后厨建立了统一的操作规范和培训体系4级是后厨用出菜时间、客诉率这些数据来调整备菜流程5级是后厨每周都会主动复盘做实验改进口味。每一级都是在下一级基础上多了一层“体系化”。2.2 等级背后的关键过程域CMM不是空谈等级每个成熟度等级都对应一组“关键过程域”英文缩写KPA。以CMM v1.1为例二级到五级分布如下二级已管理级需求管理、软件项目计划、软件项目跟踪和监控、软件子合同管理、软件质量保证、软件配置管理共6个。三级已定义级组织过程焦点、组织过程定义、培训程序、集成软件管理、软件产品工程、组间协调、同行评审共7个。四级已管理级定量过程管理、软件质量管理共2个。五级优化级缺陷预防、技术变更管理、过程变更管理共3个。这里值得琢磨的是过程域的排序逻辑。为什么需求管理放在二级而不是三级因为二级关注的是单个项目能不能可控需求如果管不住后面的计划全是空中楼阁。为什么同行评审放在三级而不是塞进质量保证因为CMM认为质量是工程活动中“内建”出来的不是靠事后检查查出来的。这种排序本身就是在传递一种工程价值观。2.3 CMM的局限CMM的局限也很明显。首先它只面向软件工程做系统集成、硬件开发、IT服务的团队很难直接套用。其次CMM时代对文档的要求非常重很多企业为了过级不得不大量造文档导致“过程和现实两张皮”这也是后来被诟病最多的地方。还有一点CMM只有一个整体评级你想单独改进某个薄弱环节比如只把配置管理做扎实其他方面先不动在CMM的框架里很难操作因为过级必须按等级整体满足。这些局限恰好解释了为什么CMMI要在框架层面做两个根本性的变化一是覆盖面大扩二是引入连续式表示法。3. CMMI的框架设计与两种表示法3.1 阶段式表示法延续CMM的五级阶梯CMMI的“阶段式表示法”与CMM一脉相承仍然用1到5的成熟度等级来描述组织整体水平。你申请CMMI三级评估评估师按照三级要求的全部过程域和实践去核验通过了就给三级证书。这个逻辑和CMM几乎没有差别所以很多做过CMM老评估的老团队看到CMMI阶段式表示法时会觉得特别亲切。但CMMI的阶段式和CMM时代相比过程域做了重排和扩展。在常见的软件加系统工程配置下CMMI v1.3一共有22个过程域分成四类过程管理类组织过程重点、组织过程定义、组织培训、组织过程绩效、组织革新与部署。项目管理类项目计划、项目监控与控制、供应商协议管理、集成项目管理、风险管理、量化项目管理。工程类需求开发、需求管理、技术解决方案、产品集成、验证、确认。支持类配置管理、过程与产品质量保证、测量与分析、决策分析与解决方案、原因分析与解决方案。对比CMM的18个KPACMMI不只是数量多了还加入了风险管理、决策分析这类更贴近现代项目管理实践的领域。需求开发和需求管理被拆成两个过程域一个管“挖掘和定义”一个管“基线化和变更控制”细粒度明显提升。3.2 连续式表示法CMMI最重要的增量CMMI真正的突破是引入了连续式表示法。连续式不再要求你整体评一个等级而是针对每个过程域单独打分用“能力等级”0到5来衡量0级表示未完成5级表示最高水平。这里打个比方阶段式相当于“整年级排名”你被评为五年级就是所有核心科目都达到五年级要求连续式相当于“单科成绩单”语文可以是一年级数学可以是三年级英语可以是五年级互不拖累。阶段式适合需要给外部一个整体认定的场景比如投标时亮证书连续式则非常适合组织内部做针对性改进哪里痛补哪里。我自己见过一个很典型的例子。某团队做嵌入式开发整体项目管理还行但配置管理一直混乱版本经常合错发布前总要回滚。如果他们走阶段式路径为了拿到二级证书得把二级要求的所有过程域都补齐工程量太大。换了连续式之后他们只挑“配置管理”这一个过程域从1级往4级推三个月后版本管理问题明显改善。这种“单科突破”的路径在CMM时代是不存在的。3.3 从制度化到通用实践CMM和CMMI都极其强调“制度化”——好的做法不能只靠一两个人自觉必须变成组织的规定动作。CMM里用“共同特征”表达对过程的承诺、执行能力、执行活动、测量与分析、验证实现。CMMI沿用了这个思想但把它转化成更清晰的“通用目标”和“通用实践”体系。CMMI里的通用目标GG1到GG3分别要求过程域的目标被达成、实践被制度化、过程被定义为组织资产。GG4和GG5则要求用统计方法管理过程并持续优化。每一级通用实践前面都有“制度化”这个前缀它的意思是不是问“你做了没有”而是问“你如何保证持续地做”。这一层表达比CMM时代的共同特征更可操作、更便于评估员核验。4. CMM与CMMI的核心区别4.1 一张表看清差异很多人只想知道结论那我先把关键区别铺成一张表再逐条展开讲“为什么”。维度CMMCMMI全称Capability Maturity ModelCapability Maturity Model Integration首版时间1991年前后2000年前后覆盖面仅软件工程软件、系统、硬件、服务、采购等等级表示法只有阶段式五级阶段式连续式两种过程域数量18个关键过程域22个过程域v1.3常见配置评估方法老式SEI评估方法SCAMPI A/B/C三类评估结果成熟度等级1-5成熟度等级1-5或能力等级0-5制度化的表达共同特征通用目标通用实践敏捷适配度几乎没有v2.0明显增强4.2 从“单一学科”到“多学科集成”CMM全称里的“Capability Maturity Model”没有限定领域但你翻开CMM文件通篇都在讲软件。这个定位在早期很清晰后来却成了天花板。现代项目的形态越来越复杂一个产品往往软件、硬件、系统、采购、服务交织在一起。CMMI把这些学科的实践统一框架化让一个做软硬结合产品的公司可以用同一套评估标准贯穿整个研发链条。实际操作中还有一个很现实的差异CMM时代软件团队和系统工程团队往往各有一套流程、各做各的改进到了CMMI时代标准维护组织提供的框架天然要求你打破部门边界把跨学科流程统一起来。我见过不少老牌企业做完CMMI评估之后研发、测试、运维、项目管理第一次坐下来一起定义统一流程这种组织层面的副作用比证书本身更有价值。4.3 从“关键过程域”到“过程域”从“共同特征”到“通用实践”CMM把那些重要实践叫“关键过程域”CMMI直接叫“过程域”。这个细微改动背后有深意CMM时期一个组织只关注“关键”过程域就够了容易让企业忽略那些“不关键”的部分CMMI认为要保证整体能力所有过程域都应该被纳入管理视野只是推进节奏可以不同。制度化表达的变化更值得关注。CMM的共同特征是一种“检查清单”思维问你有没有承诺、有没有能力、有没有活动、有没有度量、有没有验证。CMMI的通用实践则是一种“进化阶梯”思维先做到基本实践再把实践沉淀为组织标准再用统计分析管理最后持续优化。前者是“一件事做到五面俱全”后者是“一个实践逐步升级”维度完全不同。4.4 评估方法和商业场景的差异最后说评估。CMM时代使用的老式SEI评估方法在商业化的今天已经彻底退出主流。CMMI时代统一使用SCAMPI方法分三类A类评估最正式需要评估师进场综合文档审查、人员访谈、项目现场观察三类证据通过后可以发放证书B类用于内部自评估不发证C类用于快速差距分析半天到一天就能出结论。这点对准备过级的企业非常重要。SCAMPI A类的证据三件套里访谈和现场观察恰恰是很多人最容易翻车的地方。你文档写得再漂亮评估师随机抽几个项目经理聊天发现实际执行和文档对不上问题就大了。这也是CMMI和CMM最大的现实差别之一CMM时代还有人能靠纸面文章蒙混过关CMMI的访谈环节逼着企业必须“纸上写的和实际做的”保持一致。5. 企业落地时的选择与常见误区5.1 什么场景该选CMMI先说结论今天在企业实操层面你基本不会再碰到“要不要做CMM认证”的选择题。CMM这个名称已经退出主流商业服务现在市场上能做的成熟度认证基本就是CMMI。需要做CMMI的场景集中在三类商业准入甲方招标文件明确写了CMMI等级要求没有证书连投标资格都没有。这在政务类项目、大型国企类项目、出口外包类项目里特别常见。内部管理升级团队规模上来了项目一多就乱靠救火队式管理撑不下去需要用成熟度阶梯把计划、需求、质量、配置等基础管理动作固化下来。组织能力资产化公司想减少因人而异的项目风险把散落在几个骨干脑子里的经验提炼成组织标准过程。5.2 关于“选几级”的现实建议很多老板一开口就要做CMMI五级好像级别越高越有面子。我做过的每一个真实评估项目都在提醒我从二级或三级起步才是绝大多数团队理性选择。二级解决的是“单项目能不能按计划走”的问题适合那些项目流程还靠人盯、文档和代码管理一团糟的团队。三级解决的是“不同项目能不能共用一套打法”的问题适合已经能稳定交付、但各项目各自为战的团队。四级和五级要求的量化管理和持续优化没有数据积累和工程文化支撑基本做不出来。如果组织基础薄弱硬跳级过五级实际结果是两个要么评估前疯狂赶材料评估后所有流程迅速还原要么为了满足量化要求造一堆没人看的度量报表。这两种结果都违背了过程改进的本意。5.3 四个特别常见的坑第一“CMMI过级等于写文档”。这种理解最危险。CMMI核验的是实践是否真实存在文档只是实践痕迹的一种载体不是目标本身。只重文档的企业很容易在访谈环节被评估师追问到漏洞百出。第二“用了敏捷就不能搞CMMI”。CMMI v2.0已经把敏捷和DevOps实践纳入框架两者不是对立关系。真正有效的路径是用敏捷的方式做迭代开发用CMMI的实践域保证敏捷过程被定义、被度量、被持续改进。把二者对立往往是既不懂敏捷也不懂CMMI。第三“咨询公司包过就等于万事大吉”。包装得再漂亮如果实际流程没有改变第二年监督评估时就会现出原形。我见过不止一家企业证书拿到手内部却一点变化都没有最后导致团队对CMMI彻底失去信任认为这只是一场表演。第四“有CMM基础升级CMMI很容易”。历史上有企业做过CMM成熟度评估后续要转CMMI仍然要重新做差距分析、重新定义过程域映射、重新准备证据。框架变了评估方法变了证明标准也变了不能说“升级”只能说“迁移”。6. 实操观察用好这套框架比拿证更重要6.1 一个让我印象深刻的对照有位工程师来找我说公司过完CMMI三级发版还是天天加班质量也没变好他怀疑CMMI是不是就是一个纯骗钱的证书。我说你先别急着下结论回答我三个问题你们过级之后有人真正维护过“组织标准过程”这个文档库吗你们每个迭代有没有人去分析度量数据你们项目的复盘结论有没有回流到流程定义里去如果三个全没有那你们过的三级就只是一个挂在墙上的证书。CMMI本身没有问题问题在于很多企业把“通过评估”当成终点而不是把“组织过程资产持续运转”当成起点。6.2 我建议你从这套框架里真正拿走的东西哪怕你所在的公司不打算做CMMI认证我也建议你理解这两套模型背后的工程管理思想。以下是我实操之后觉得最“值钱”的部分第一把组织经验显性化。CMMI里的组织过程定义、组织过程重点这几个过程域本质上是逼着公司把散落在个人脑子的经验抽出来沉淀成文档库和流程库。哪怕是十个人的小团队这件事做了人员流动风险就会明显降低。第二把过程改进从一个“项目”变成一种“机制”。最有效的做法是成立一个三到五人的过程改进小组每季度选一个真实痛点比如“发布总是回滚”“需求反复变更”用CMMI的通用实践思路来改善。一段时间只聚焦一件事比全面铺开有效得多。第三借用连续式思维做局部精进。不要等公司下定决心整体过级才去思考过程成熟度。挑当前最痛的一个过程域比如配置管理、需求开发、决策分析单独把它提升到高能力等级。三个月的局部改进往往比一年的花架子评估更让团队受益。6.3 如果正在准备评估给几句实在话如果你已经在准备CMMI评估我的建议是差距分析阶段一定要让内部骨干深度参与不要把全部工作打包给咨询公司。内部的人最清楚流程哪些地方是空的、哪些地方是写了但没人执行的。评估访谈前让不同角色的同事用自己的话复述流程不要背标准条款。另外送审项目不要专门挑“最优秀的三个项目”去展示。评估师经验丰富你挑得太完美反而容易增加访谈追问深度。选几个有代表性的真实项目有些不算完美、但过程和文档能对得上这样的证据链反而更可信。还有评估结束之后把评估师的发现和建议整理成行动清单每个季度回顾一次这才是这套框架对团队产生长期价值的开始。这些年我见过太多关于CMM和CMMI的争论有人把它们说得神乎其神有人不屑一顾。我的真实感受是这两个模型本质上都是“把好工程实践显性化”的工具CMM打下了骨架CMMI把它扩大并加固。证书有保质期但过程能力没有。你从这套框架里真正要学的不是怎么写文档、怎么凑证据而是怎么用一套系统的眼光审视自己团队的工程成熟度到底处在哪个位置。哪怕你所在的公司完全不碰CMMI认证把五级阶梯的思路拿回来对照自己的项目流程逐条问一句“我们现在处在哪一级”就已经值回票价。