从 0 到 1 搭建研发质量管理体系：CMMI + 统计过程控制的落地全指南

Mon, 29 Jun 2026 16:00:00 +0800

为什么大多数团队的质量管理形同虚设

研发质量管理最常见的失败模式不是"没有流程"，而是流程沦为了检查清单。

团队在评审会上逐项打勾——需求文档有吗？有。测试用例写了吗？写了。代码审查做了吗？做了。所有勾都打完了，产品质量依然漏洞百出。这种"清单心态"（Checklist Mentality）的本质问题在于：

过程没有被度量，执行了不等于有效执行
质量目标没有量化，“高质量"只是一句口号
改进缺乏数据支撑，每次复盘都停留在"下次注意”
过程能力不可见，无法区分随机波动和系统性偏差

质量管理的核心不是"有没有做"，而是"做得怎么样"以及"能不能持续做得更好"。CMMI 框架和 SPC 统计过程控制，正是解决这两个问题的方法论基础。

顶层设计：质量方针与 QPPO 目标

搭建质量管理体系的第一步，不是写流程文件，而是明确质量方针和质量和过程绩效目标（QPPO）。

质量方针的三层结构

层级	内容	示例
战略层	组织级质量愿景	“以零缺陷为目标，持续提升客户满意度”
策略层	质量原则与承诺	“需求评审覆盖率 100%，缺陷前移”
执行层	可量化指标	“缺陷密度 ≤ 0.5 个/KLOC，交付准时率 ≥ 95%”

QPPO 目标的制定逻辑

QPPO（Quality and Process Performance Objectives）需要将业务目标分解为可度量的过程绩效目标：

1
2
3
4
5
6
7


业务目标：客户满意度 ≥ 90%
 ↓ 分解
质量目标：线上缺陷密度 ≤ 0.3 个/KLOC
 ↓ 分解
过程目标：需求评审缺陷检出率 ≥ 85%，代码审查覆盖率 100%
 ↓ 分解
基线指标：各阶段缺陷清除率、需求变更率、返工率

没有 QPPO 牵引的质量体系，就像没有靶心的射箭——动作再标准也毫无意义。

四层文件体系：让质量管理有据可依

质量管理体系的文件架构采用经典的四层金字塔结构：

层级	文件类型	内容定位	典型文档
第一层	质量手册	方针、范围、体系概览	《组织质量管理手册》
第二层	程序文件	跨部门流程与职责	《需求管理程序》《配置管理程序》
第三层	指引/规范	操作级作业指导	《代码审查指引》《测试用例编写规范》
第四层	质量记录	执行证据与数据	评审记录、缺陷日志、度量报告

四层文件的核心原则：上层指导下层，下层支撑上层。质量手册定义"为什么做"，程序文件定义"谁来做、做什么"，指引规范定义"怎么做"，质量记录证明"做到了"。

CMMI 过程四大类：体系的全景视图

CMMI 将研发过程划分为四大类别，覆盖了从需求到交付的全生命周期：

工程过程（Engineering）

直接产出产品价值的核心过程链：

需求开发与管理：需求获取、分析、确认、变更控制
技术设计与实现：架构设计、详细设计、编码
验证与确认：测试策划、执行、缺陷跟踪
产品集成与交付：集成构建、部署发布

管理过程（Project Management）

项目策划与监控：WBS 分解、进度跟踪、偏差管理
风险管理：风险识别、评估、缓解与应急
供应商管理：外包过程的质量保障

支持过程（Support）

配置管理：版本控制、基线管理、变更追溯
质量保证（QA）：过程审核、产品审核、不符合项跟踪
度量与分析：数据采集、基线建立、统计分析

过程管理（Process Management）

组织过程定义：建立标准过程集与过程资产库
组织培训：能力矩阵与培训计划
组织过程改进：基于度量数据的持续优化

PPQA 落地：过程与产品质量保证的 8 个元素

PPQA（Process and Product Quality Assurance）是 CMMI 中确保过程被正确执行的关键实践域。其落地可以拆解为 8 个可操作的元素：

序号	元素	核心活动	输出物
1	QA 计划	确定审核范围、频次、方法	《QA 计划》
2	过程审核	对照标准过程检查执行情况	《过程审核报告》
3	产品审核	检查工作产物是否符合规范	《产品审核报告》
4	里程碑审核	阶段关口验证准入准出条件	《里程碑评审记录》
5	跟踪不符合项	记录、分级、跟踪直至关闭	《NC 跟踪表》
6	参与技术评审	QA 列席评审会议，监控评审有效性	评审观察记录
7	收集分析数据	汇总度量数据，识别过程偏差	《质量度量报告》
8	管理 QA 工作	QA 团队自身的计划与绩效管理	QA 工作总结

不符合项的分级处理

严重 NC：过程完全未执行（如跳过代码审查直接合入主干）→ 限期整改 + 管理层通报
一般 NC：过程执行不到位（如评审记录缺失关键信息）→ 限期整改 + 项目组内部关闭

SPC 控制图：用统计方法守住过程稳定

统计过程控制（SPC）的核心思想是：区分过程中的随机波动和异常波动。当过程数据超出控制限，说明存在系统性原因需要干预。

缺陷清除率模型

基于项目阶段的缺陷清除率（Defect Removal Efficiency, DRE）模型：

1
2
3
4
5
6
7


各阶段缺陷清除率 = 本阶段发现缺陷数 / (本阶段发现缺陷数 + 逃逸到后续阶段的缺陷数)

示例：
需求阶段：发现 20 个缺陷，逃逸 5 个 → DRE = 20/(20+5) = 80%
设计阶段：发现 35 个缺陷，逃逸 8 个 → DRE = 35/(35+8) = 81%
编码阶段：发现 60 个缺陷，逃逸 12 个 → DRE = 60/(60+12) = 83%
测试阶段：发现 45 个缺陷，逃逸 3 个 → DRE = 45/(45+3) = 94%

通过对多个项目的 DRE 数据建立控制图，可以识别哪些项目的某个阶段存在异常偏低的情况。

需求变更 p 控制图

需求变更是研发过程中最常见的不稳定因素。使用 p 图（比例控制图）监控每个迭代的需求变更率：

1
2
3


CL = 历史平均变更率（中心线）
UCL = CL + 3√(CL(1-CL)/n) （上控制限）
LCL = CL - 3√(CL(1-CL)/n) （下控制限）

参数	含义	示例值
CL	过程中心（历史均值）	变更率均值 12%
UCL	上控制限	18.5%
LCL	下控制限	5.5%
n	样本量（需求条目数）	当前迭代 45 条

判异规则：当某迭代变更率超过 UCL，触发根因分析——是客户需求本身不稳定，还是需求理解存在偏差？

SPC 的价值不在于"画出控制图"，而在于建立过程稳定的预期。当控制图持续收窄，说明过程能力在提升；当控制图出现趋势性偏移，说明过程正在退化。

PDCA：持续改进的闭环引擎

质量管理体系的生命力取决于改进循环是否能够闭环运转：

Plan（策划）：基于度量数据和审核发现，制定改进计划。明确改进目标、责任人、时间节点。
Do（执行）：实施改进措施。可能包括流程优化、工具引入、培训赋能。
Check（检查）：通过控制图和度量指标验证改进效果。对比改进前后的过程能力。
Act（固化）：将有效的改进纳入标准过程，更新过程资产库，推广到全组织。

1
2
3
4
5
6


 ┌─── Plan ◄──── Act ───┐
 │ 制定改进计划 固化推广 │
 ▼ │
 Do Check
 执行改进措施 验证改进效果
 └──────────────────────┘

每一轮 PDCA 循环都应当产生可量化的过程能力提升。如果循环结束后控制限没有收窄，说明改进措施没有真正生效。

CMMI 成熟度进阶路径

级别	名称	核心特征	关键实践	典型度量能力
Level 1	初始级	过程混乱，依赖个人能力	无系统性过程	无
Level 2	已管理级	项目级过程可控，可重复成功	项目策划、需求管理、配置管理、QA	项目级进度与成本偏差
Level 3	已定义级	组织级标准过程，项目可裁剪	组织过程定义、培训、集成管理	过程遵从度、评审有效性
Level 4	量化管理级	统计过程控制，量化目标管理	SPC 控制图、过程基线、预测模型	过程能力指数 Cp/Cpk
Level 5	优化级	持续改进制度化，主动创新	因果分析、过程创新、组织级优化	改进 ROI、过程性能预测

从 Level 2 到 Level 3 的跨越，核心在于从项目级过程上升到组织级过程资产。从 Level 3 到 Level 4 的跨越，核心在于从定性管理上升到统计量化管理。每一次跨越都不是"写更多文档"，而是"建立更强的过程能力和度量体系"。

质量管理的终极目标不是通过某个认证，而是让过程能力持续可预测、可持续改进。CMMI 提供了框架，SPC 提供了工具，PDCA 提供了引擎——三者结合，才能构建真正有效的研发质量管理体系。

质量管理 on 文艺技术笔记