这一周，都在密集的参与公司CMMI资质评审。什么是CMMI？我发现这是一个很模糊，似懂非懂的概念，很多时候，都没法向他人解释清楚。仔细想想，这大概说明了3个问题：第一，自己没有真正理解这个概念；第二，自己的语言表述不到位；第三，听众没有行业背景，听不明白。

大家想想，我们的生活和工作，都是由各种小事组成的，职场人士能力的强弱，往往就是在细节处理上的区别，积小成多，最终形成差距。比如，文档发出去之前，对标题和错别字多检查一次；每天工作前，花五分钟列一下当天的工作计划；当别人找你办事时，不会回复“我有很多其他项目的事，我很忙”等。

类似的细节很多，除此之外，我觉得有一个最基本并且核心的能力——把一件事、一个概念解释清楚，并且别人能听懂。

我们对很多司空见惯事物的解释，往往显得特别无力的。比如，你们公司的主要业务是什么？你自己是怎么样的一个人？如何快速掌握这套系统？你会如何教会一个小孩子用筷子？或者还有前一阵，我们同事面临的一个问题，你会如何向一个小学生解释早恋？什么是比特币、区块链、智慧城市等等。

看似简单，这种技能实则需要不断的打磨和练习。今天我想试一下能不能把CMMI这个概念解释清楚。

下文概念解释逻辑：

一、什么情况下，我们需要CMMI？

二、CMMI的概念核心是什么？

三、CMMI体系结构是怎样的？

一、什么情况下，我们需要CMMI？

如果你是一个码农，你的公司有软件开发业务，在完成一个软件产品或实施项目时，常常会出现以下的状况：

1、开发人员不懂客户业务，一个高大上的规划，落地后的软件，只是机械的满足了基本功能，毫无易用性和科学性可言。

2、项目只有简单的里程碑计划，细节处理粗糙，需求不断扩大，工期一再延后。

3、项目需求、设计等由一人跟踪，然后再口述给其他人，最后验收前疯狂补文档，应付验收。一段时间后，这些人离职了，新来的同事看着文档，牛头不对马嘴，完全不知所云。

4、做完了N个类似的项目了，面对一个新项目，大部分工作还得重新开始，无法复用，对公司来讲，资产和经验都没得到积累。

5、项目过程中的问题，没有有效跟踪，还没有解决，就不了了之了。

6、项目过程中的风险，没有有效识别。风险发生后，局面无法控制，后期因为要验收，又草草处理。

以上这些现象其实是实际软件开发过程中常见的，最后产出的产品质量可想而知。别急，这个时候，CMMI就特别适合你。

二、CMMI的概念核心是什么？

CMMI，由美国人在1994年提出，过去二十几年在世界范围内被广泛应用，其科学性和应用效果得到验证。

CMMI，即软件成熟度模型。

换句话说，就是给你公司一个软件开发管理可执行的框架，这个框架具有自动性和可扩展性。实行CMMI体系的过程就是改进的过程。最终的目的，就是在保证工期和预算的前提下，输出高质量的软件。

只要按照这个框架执行，我们开发工作每一个环节都有规程和文档为依据，我们的需求、设计、测试各个环节都有评审，变更将得到有效管理，项目成果和经验能得到积累和应用……

大家熟知的信息系统项目管理师和PMP，是两个对个人层面的认证，而CMMI是对企业层面的认证。

三、CMMI体系结构是怎样的？

5个等级。CMMI模型把企业的软件能力成熟度划分为5个等级——第1到第5级。数字越大，成熟度越高。5个等级分别是：初始级、已管理级、已定义级、已定量管理级、优化级。一般企业评估是第3级或第5级。

22个过程域。每一个成熟度等级对应一定数量的过程域。所谓过程域（PA），就是做好软件管理的某一个方面，如项目计划（PP）、风险管理（RSKM）、需求开发（RD）等等。CMMI一共包括22个过程域，涵盖了过程管理、项目管理、工程管理、支持管理四个方面。

特殊目标和通用目标。每一个过程域下面有具体的特定目标和通用目标。如项目计划（PP），其特定目标如下：

SG1 完成参数估计；

SG2 拟订项目计划；

SG3 获取对计划的承诺。

特殊实践和通用实践。每一个目标下面有具体实践方法，即特定目标下面有特殊实践，通用目标下面有通用实践。所谓实践，即具体可执行和量化的行动措施。比如项目计划（PP）的特定目标SG1（完成参数估计），就包括4个特定实践：

SP1.1 估计项目的范围

SP1.2 建立项目属性的估计

SP1.3 定义项目生命周期

SP1.4 确定工作量和成本的估计

这样，就形成了自上而下的CMMI体系，自下而上的可评估方法。

CMMI的评估，就是自下而上，通过对具体项目提供的文档证据和访谈，来了解开发工作是否采取了实践措施，进而确定每个过程域的特定目标和通用目标是否实现，从而确定这个过程域是否满足，最终能确定评审企业是否达到CMMI等级。

好了，讲完了，你听懂了吗？