研发成熟度模型是一类用等级描述组织研发过程能力如何逐级演进的框架，CMMI是其中影响最广的一套具体模型体系，而CMMI评估是依据CMMI模型对组织过程能力做正式判定的活动。三者构成“框架类别—具体模型—模型应用”的关系。本文围绕定义、边界与配合方式展开，帮助读者在过程改进中分清模型、评估与改进各自承担的任务。
要点总览（TL;DR）
- 研发成熟度模型是一类用等级描述过程能力演进的框架类别，CMMI是其中影响最广的具体模型，CMMI评估则是依据CMMI对组织实际做法取证判定的活动，三者构成“框架类别—具体模型—模型应用”的关系。
- CMMI同时提供阶段式与连续式两种表达：阶段式看组织整体成熟度等级，连续式看单个过程域的能力等级，组织可按改进范围选择参照方式。
- 评估产出等级结论与改进项，结论具有时点性，反映评估期间、评估范围内的过程实践，不能直接等同于组织长期能力。
- 成熟度评估是手段，过程改进是目的；度量数据驱动的小范围效能实验范围更小、节奏更快，属于研发效能诊断与持续改进，两者可配合使用。
- 常见误解是把CMMI等同于成熟度模型全部、把评估等级当作能力完整证明、把评估当作一次性认证，结果是资源集中投向评估准备而日常过程执行被忽视。
研发成熟度模型是什么：分级思路与核心假设
研发成熟度模型的核心做法，是把组织研发过程能力从低到高划分为若干等级，用等级位置描述组织在过程管理上的当前状态和演进方向。它提供的是分级思路，而非某一条具体流程的写法。一个完整的成熟度模型通常包含三部分：等级划分，说明每一级应达到的整体状态；过程域或实践集合，说明支撑该等级需要覆盖的管理与工程活动；达成条件，说明判定是否达到某等级所依据的证据要求。
这类模型建立在几个基本假设之上。第一，过程可以被定义和描述，组织能够把实际做法写成可沟通、可执行的流程。第二，过程可以被重复，同一类工作在相似条件下能够稳定产出相近结果，而非依赖个别人的经验。第三，能力提升具有阶段特征，组织需要先夯实基础管理，再逐步进入量化管理和持续优化，跨越阶段往往难以稳固。第四，改进是持续活动，等级是某一时点的状态描述，组织仍需在日常运行中维持和提升。
理解这些假设有助于正确使用成熟度模型：它描述的是组织过程能力的演进路径，提供的是参照系。组织可以借助它识别当前短板、规划改进顺序，但模型本身不替代具体的流程设计，也不直接给出项目层面的操作方法。
CMMI在成熟度模型谱系中的位置
CMMI是一套具体的过程改进模型，属于成熟度模型这一框架类别中的一员。它把过程能力改进拆解为可参照的过程域和实践要求，并给出阶段式与连续式两种表达方式：阶段式以组织整体成熟度等级为视角，连续式以单个过程域的能力等级为视角。两种表达服务于不同的改进目的，组织可依据自身改进范围选择参照方式。
从从属关系看，通用成熟度模型回答“用等级描述过程能力演进”这一方法论问题，CMMI则回答“研发相关过程应覆盖哪些活动、达到什么状态”这一具体内容问题。CMMI关注组织过程能力，覆盖与研发相关的多个过程域，包括需求、计划、监控、质量、配置管理等方向。组织使用CMMI时，通常先对照过程域识别差距，再规划改进动作。
需要区分的是，CMMI是模型，不是评估结论，也不是认证证书。模型提供要求与参照，组织对照模型开展改进，评估则是在改进到一定程度后对实际做法进行取证和判定。把CMMI直接理解为“一张证书”或“一次评审”，会模糊模型与评估的界限。
CMMI评估做什么：判定活动与模型的关系
CMMI评估是依据CMMI模型对组织过程实践进行取证与判定的活动。评估关注组织实际在做的事情：查阅过程文档、访谈相关人员、抽查项目记录，将收集到的证据与模型要求逐项比对，形成对过程能力状态的判断。评估的产出包括等级结论和改进项，前者说明组织在评估范围内达到的状态，后者指出与模型要求之间的差距，为后续改进提供输入。
评估是周期性活动，结论具有时点性。一次评估反映的是评估期间组织所展现的过程实践，随着项目更替、人员变动和业务变化，过程执行情况会发生变化。因此，评估等级描述的是特定时点、特定范围内的状态，不能直接等同于组织的长期能力，也不能替代日常的过程管理。组织若希望维持等级状态，需要在评估之后持续按过程要求运行并定期自检。
模型与评估的关系可以概括为：模型提供判定依据，评估提供落地证据。没有模型，评估缺少统一口径；没有评估，模型要求难以验证组织是否真正执行。两者配合，才能让过程改进形成“对照要求—实施改进—取证判定—继续改进”的循环。
三者的区别与联系：一张对照表看清
把研发成熟度模型、CMMI模型和CMMI评估放在同一口径下对照，可以更清楚地看到它们各自的位置和衔接方式。
| 对照维度 | 研发成熟度模型 | CMMI模型 | CMMI评估 |
|---|---|---|---|
| 层次定位 | 框架类别，提供分级方法论 | 具体模型，属于成熟度模型谱系 | 模型应用活动，依据模型开展判定 |
| 关注对象 | 过程能力如何分级演进 | 研发相关过程域及实践要求 | 组织实际过程实践与证据 |
| 典型产出 | 等级思路、过程域框架、达成条件 | 过程域要求、阶段式与连续式表达 | 等级结论、改进项、评估报告 |
| 使用方式 | 作为改进参照系，规划演进路径 | 对照识别差距，设计改进动作 | 周期性取证判定，验证改进结果 |
三者的联系体现在一条链路上：成熟度模型给出分级思路，CMMI把这套思路落实为可参照的过程域与等级要求，评估则依据CMMI对组织实际做法取证并给出结论。评估结论反过来又成为下一轮改进的起点。需要避免的是把评估等级等同于模型全部内容：等级只反映评估范围内达到的状态，模型中的过程域要求、实践细节和改进方法，远多于一个等级数字所承载的信息。
相邻概念区别：成熟度评估、过程改进与效能实验
成熟度评估与过程改进是手段与目的的关系。评估用于判断组织当前过程能力状态、识别差距，改进则是针对差距调整流程、工具和协作方式，使过程更稳定、更可预测。评估本身不产生能力提升，改进也不必然需要正式评估；组织可以先做内部自评，再决定是否引入正式评估。把评估当成改进的终点，容易导致评估结束后改进动力下降。
与度量数据驱动的小范围效能实验相比，两者在范围和节奏上不同。效能实验通常围绕某个具体环节设定假设，用度量数据观察改动前后的变化，快速验证后决定推广或放弃，属于研发效能诊断与持续改进的范畴。成熟度评估覆盖范围更广、周期更长、判定口径更统一，适合回答组织整体过程能力处于什么位置。两者可以配合：效能实验解决局部问题，成熟度评估校准整体方向。
成熟度评估与认证、审计也有区别。认证侧重对组织是否符合某项标准要求给出证明，审计侧重检查合规性与风险，成熟度评估侧重过程能力的等级判定与改进项识别。三者的目的、依据和产出不同，组织在规划相关工作时应分别明确目标，避免用同一套材料应付不同活动而削弱各自价值。
具体例子与常见误解
以一个中型研发组织为例。团队先对照CMMI过程域做内部自评，发现需求变更缺少统一记录、项目计划与实际进度脱节。随后团队在需求、计划、评审环节补充流程和记录要求，运行两个季度后，用积累的过程数据检查执行情况，再决定是否申请正式评估。正式评估给出等级结论和若干改进项，团队据此进入下一轮改进。这个过程中，自评、改进、评估依次衔接，评估是链条中的验证环节，改进贯穿始终。
常见误解之一是把CMMI等同于成熟度模型的全部。CMMI是成熟度模型谱系中影响最广的一套，但成熟度模型作为框架类别，还包含其他模型和分级思路。误解之二，是把评估等级当作组织能力的完整证明。等级反映评估范围内的过程状态，项目类型、团队规模和业务复杂度不同，能力表现也会有差异。误解之三，是把评估当作一次性认证，认为拿到等级后可以长期沿用。评估结论有时点性，过程执行需要持续维持。
这些误解带来的实际影响是：改进资源被集中投向评估准备，日常过程执行被忽视；等级被用于对外宣传，内部却缺少维持机制；评估结束后流程回退，下一轮评估又要重新补材料。正确的理解方式是，把模型当作改进参照，把评估当作阶段性验证，把日常过程运行和数据记录当作长期基础。
在过程改进落地环节，组织需要把流程要求、项目记录、评审结论和改进项统一管理起来，让评估取证有据可查。ONES 效能管理提供效能管理实践体系，支持对系统中产生的数据进行多维度分析，帮助团队进行效能的持续改进；其效能度量实践体系覆盖交付效率、交付质量、资源效率、完成情况四个维度，并提供“CMMI 研发过程改进度量”场景化卡片模板。该模板在官方资料中仅列出名称，具体指标口径与适用等级需结合组织实际情况确认。对于希望把改进动作、过程记录和度量结果放在同一平台管理的团队，这类能力可以作为过程改进的承载方式之一。
常见问题
组织规模不大、项目类型单一，是否也需要做正式CMMI评估？
不一定。正式评估的价值在于用统一口径对过程能力做阶段性判定，适合需要对外证明过程能力、或内部需要明确整体改进基线的组织。规模较小、项目类型单一的组织，可以先对照CMMI过程域做内部自评，识别需求、计划、评审等环节的明显差距，先完成一轮改进。等改进动作稳定运行、过程记录积累到一定程度，再判断是否引入正式评估。评估是验证手段，改进才是目的，跳过改进直接准备评估，容易变成补材料。
评估结论有时点性，那评估之后如何维持过程执行不回落？
关键在于把评估期间形成的做法变成日常运行的一部分，而不是评估结束就放松。可执行的做法包括：把过程要求写入项目模板和评审检查项，让执行有固定载体；保留过程数据的日常记录，定期自检关键过程域的执行情况；把评估给出的改进项纳入后续改进计划并跟踪关闭。组织还可以安排内部自评作为周期性检查，在两次正式评估之间发现执行偏差。维持机制比评估本身更影响长期能力。
CMMI的阶段式与连续式两种表达，实际使用时怎么选？
看改进范围和汇报对象。如果组织希望以整体成熟度等级为视角推进改进、对外沟通组织级过程能力，阶段式更直观；如果改进集中在某几个过程域，例如需求管理或项目监控，希望逐个过程域提升能力等级，连续式更贴合。两种表达依据的是同一套模型内容，只是组织方式不同，组织也可以在不同阶段切换视角，先按连续式补齐薄弱过程域，再按阶段式看整体状态。
成熟度评估和度量数据驱动的效能实验，应该先做哪个？
两者解决的问题不同，可以并行，也可以按需求排序。效能实验围绕具体环节设定假设，用度量数据快速验证改动效果，适合已有明确局部问题、希望快速试错的团队；成熟度评估覆盖范围更广、周期更长，适合回答组织整体过程能力处于什么位置、改进顺序如何安排。常见做法是先用评估或自评校准整体方向，再用效能实验在局部环节验证具体改法，实验结果反过来支撑整体改进计划。
ONES 的效能管理能力能否直接支撑CMMI评估准备？
需要区分能力边界。ONES 效能管理提供效能管理实践体系，支持对系统中产生的数据做多维度分析，覆盖交付效率、交付质量、资源效率、完成情况四个维度，并提供“CMMI 研发过程改进度量”场景化卡片模板。该模板在官方资料中仅列出名称，具体指标口径与适用等级需结合组织实际情况确认。评估所需的证据采集、过程域映射等准备工作，建议在选型时向厂商核实，不宜直接假定平台能力覆盖评估全流程。
把评估等级写进对外宣传材料，需要注意什么？
等级结论有时点性和范围限定，宣传时应说明评估覆盖的组织范围、项目类型和时间，避免让读者理解为组织全部业务、全部时期的能力证明。同时要区分模型与评估：CMMI是模型体系，等级是依据模型评估得出的结论，两者不宜混用表述。若组织在评估后过程执行出现回落，对外表述与实际状态脱节，反而影响可信度。稳妥的做法是把等级作为阶段性改进成果呈现，并说明后续维持与改进安排。
