从 CMMI 到敏捷：大型制造企业研发过程管理体系是怎么建起来的

Thu, 18 Jun 2026 22:40:00 +0800

为什么研发过程管理值得认真对待

很多人一提"过程管理"就皱眉，觉得是流程官僚化的代名词。但在大型制造企业的研发场景里，过程管理不是可选项——它是底线。

某汽车制造企业的动力总成研发团队，三百多人分布在四个城市，同时推进六个在研项目。2019 年之前，项目管理全靠项目经理的个人经验和 Excel 表格，结果是一年之内三个项目延期超过六个月，其中一个因为设计评审遗漏导致模具报废，直接损失过千万。

问题不在于工程师能力不行，而在于过程不可见、不可控、不可复制。一个人离职，带走的不只是经验，还有整套隐性流程。新人接手，等于从零开始踩坑。

这就是过程管理要解决的核心问题：让研发活动从"依赖个人"变成"依赖体系"。

CMMI 成熟度模型：五个等级到底在说什么

CMMI（Capability Maturity Model Integration）不是什么新鲜事物，但它对过程能力的分级思路至今仍然实用。很多人只听说过"过 CMMI 3 级"这种说法，但不清楚每个等级到底意味着什么。

等级	名称	核心特征	企业表现
1	初始级	过程不可预测，缺乏控制	项目成败取决于个别英雄人物
2	已管理级	项目级有基本管理，可重复已做过的事	有项目计划和跟踪，但跨项目不一致
3	已定义级	组织级标准过程已建立，项目可裁剪使用	有统一的过程资产库，新项目能快速启动
4	量化管理级	用统计方法管理过程性能	能预测项目结果，偏差可量化控制
5	优化级	持续改进已嵌入组织文化	主动识别改进机会，过程能力持续提升

某大型集团的软件研发中心在 2018 年通过了 CMMI 5 级评估。但说实话，评估通过和实际落地之间还隔着一条鸿沟。证书挂在墙上，工程师该怎么做还是怎么做。这是很多企业的通病：重评估、轻落地。

CMMI 的真正价值不在于那张证书，而在于它提供了一套思考框架——你的过程在哪个层级，差距在哪里，改进路径是什么。

QDS/EMDP：面向研发的过程管理框架

CMMI 是通用模型，落到制造业研发场景需要更具体的实施框架。QDS（Quality Development System）和 EMDP（Engineering Management Development Process）是两种在汽车行业用得比较多的变体。

QDS 的核心逻辑是把研发过程拆成若干阶段（概念、设计、验证、量产准备），每个阶段有明确的交付物、评审节点和质量门控。它和 APQP（先期产品质量策划）高度对齐，适合硬件主导的研发。

EMDP 更侧重工程活动管理，关注的是需求追踪、设计决策记录、变更控制这些工程实践层面。它和 CMMI 的工程过程域（REQM、RD、TS、PI、VER、VAL）直接对应。

某汽车制造企业在实际落地时，把两者做了融合：

用 QDS 的阶段门控作为项目管理骨架
用 EMDP 的工程实践填充每个阶段的具体活动
用 CMMI 的过程域作为检查清单，确保没有遗漏

这种"三层嵌套"的结构好处是：项目经理看 QDS 阶段，工程师看 EMDP 活动，过程改进组看 CMMI 过程域。三个视角，同一套体系。

敏捷和 CMMI：不是替代，是互补

这是被讨论烂了的话题，但很多企业仍然没搞清楚。

CMMI 解决的是"过程有没有"的问题，敏捷解决的是"过程快不快"的问题。两者不在同一个维度上竞争。

某大型集团的嵌入式软件团队在 2020 年引入 Scrum，结果搞得一团糟。原因很简单：他们把 CMMI 要求的需求追踪、设计评审、配置管理全部扔掉了，觉得"敏捷就是不要流程"。六个月后，代码质量断崖式下跌，客户投诉增加 40%。

后来他们调整了策略：

保留 CMMI 的组织级过程资产（模板、检查单、经验库）
在开发阶段用 Scrum 迭代，两周一个 Sprint
需求追踪用工具自动化，不再手动维护追踪矩阵
设计评审从"阶段门控"改为"持续评审"，每个 Sprint 结束做一次轻量级评审
配置管理用 Git 工作流强制执行，分支策略即过程规则

效果是：过程合规率从之前的 62% 提升到 89%，同时迭代交付周期从原来的平均 8 周缩短到 3 周。

关键洞察：敏捷实践可以成为 CMMI 过程域的落地手段。Sprint Review 对应验证（VER），Sprint Retrospective 对应组织级过程聚焦（OPF），Product Backlog 对应需求管理（REQM）。不是两套体系并行，而是一套体系的两种表达。

从零建设：四个阶段怎么走

如果你的组织目前处于"过程管理基本为零"的状态，以下是经过验证的建设路径：

第一阶段：现状评估（1-2 个月）

别急着建流程。先搞清楚现在到底是怎么干活的。

做法：选 2-3 个已完成的项目，做回溯式访谈。问三个问题：

哪些活动是实际做了的（即使没有文档）？
哪些环节出了问题？根因是什么？
如果重来一次，你最想改变什么？

产出：现状过程地图 + 痛点清单 + 改进优先级。

第二阶段：体系设计（2-3 个月）

基于评估结果，设计目标过程体系。注意：不要照搬 CMMI 的全部过程域，选对你最痛的 5-8 个先建。

某汽车制造企业第一轮选了：需求管理、项目策划、配置管理、质量保证、同行评审。就这五个，够用半年。

第三阶段：试点运行（3-4 个月）

选一个中等规模的新项目作为试点。不要选最大的项目（风险太高），也不要选最小的（没有代表性）。

试点期间重点收集两类数据：

过程执行数据（活动是否按计划执行，偏差多大）
团队反馈数据（哪些流程有用，哪些是负担）

第四阶段：推广优化（持续）

试点验证后，逐步推广到其他项目。同时建立过程改进机制——每个项目结束后做复盘，识别改进项，更新过程资产库。

这个阶段的关键是建立过程改进的闭环，而不是让体系设计变成一次性工程。

真正有用的度量指标

过程管理最怕的是"度量了一堆数据但没人看"。以下是三个真正值得跟踪的指标：

1. 周期时间（Cycle Time）

从需求确认到交付可用的端到端时间。这是最直接的效率指标。如果引入敏捷后周期时间没有缩短，说明你的敏捷只是换了个名字的瀑布。

2. 缺陷密度（Defect Density）

每千行代码或每个功能点的缺陷数。按阶段统计（编码、测试、发布后）可以看到缺陷是在哪个环节被注入的。某大型集团通过跟踪这个指标，发现 70% 的发布后缺陷可以追溯到需求阶段的模糊描述。

3. 过程遵从度（Process Adherence）

实际执行的活动占计划活动的比例。这个指标不是用来考核个人的，而是用来评估过程设计的合理性。如果遵从度长期低于 70%，大概率是过程设计脱离实际，需要简化。

不要跟踪超过 5 个核心指标。多了就是噪音。

常见的反模式

反模式	表现	后果	正确做法
为评估而建体系	所有文档都是评估前三个月突击补的	评估通过后体系立即瘫痪	以解决实际问题为驱动，评估只是副产品
过程警察	QA 人员只负责找不符合项，开不合格报告	团队把 QA 当敌人，隐藏问题	QA 转型为过程教练，帮助团队改进
一刀切	所有项目用同一套过程，不允许裁剪	小项目被流程压垮，大项目流程不够用	建立裁剪指南，按项目类型和规模差异化
工具先行	先买 ALM 平台，再想怎么用	工具限制了过程，而不是过程驱动工具	先确定过程，再选支撑工具
只做加法	不断加新流程，从不删减旧流程	流程越来越重，执行率越来越低	定期做流程瘦身，删掉不产生价值的活动
度量虚荣	跟踪代码行数、加班时长、文档页数	团队优化数字而不是优化结果	跟踪业务结果相关的指标（周期、质量、成本）

写在最后

过程管理的终极目标不是让每个人都按同一套流程机械执行，而是让好的实践可复制，让犯过的错不重犯。

好的过程体系像好的代码架构——它应该是松耦合的（各过程域可以独立演进），高内聚的（相关活动组织在一起），并且支持持续重构（定期优化）。

如果你正在从零建设研发过程管理体系，记住一条：先让它能用，再让它好用，最后让它自动化。不要试图一步到位，那只会让所有人都不满意。

CMMI 给你思考框架，敏捷给你执行节奏，两者结合才是大型制造企业研发过程管理的完整答案。

过程改进 on 文艺技术笔记