这几年做过程改进咨询和评估我明显感觉到一件事CMMI 模型本身越来越不像一套“文档规范”而更像一套“组织运行逻辑”。尤其是到了 CMMI 3.0大家讨论最多的不是某个实践域怎么写文档而是治理、基础设施、组织级培训这三个域到底怎么落地、怎么联动、怎么在评估时拿出让人信服的证据。不少团队按 2.0 的老经验去应对 3.0结果发现自己卡在“证据不对路”的尴尬局面上。这篇文章我就围绕 CMMI 3.0 里这三个关键实践域把自己做过项目、走过弯路、反复调整后的理解完整写出来。不绕弯子直接说每个域到底要求什么、为什么这么改、实际操作时怎么做才能既过评估又真正提升组织能力。不管你是正准备做 CMMI 3.0 评估还是只想借模型梳理公司内部管理这篇文章都能给你一些可以直接用的思路。1. 为什么 CMMI 3.0 把这三件事单独拎出来说很多第一次接触 CMMI 3.0 的人会问治理、基础设施、组织级培训这三个词听上去都很大好像跟“开发流程”没什么直接关系。但真正理解模型逻辑以后你会发现这三个域恰恰是组织能力能不能持续运转的地基。1.1 版本演进的主线从“做事”到“让组织能持续做事”CMMI 从 2.0 进化到 3.0主线逻辑其实非常清晰过去模型的重点在于“有没有把一件事情做好”比如需求管理、项目计划、配置管理、质量保证。但到了 3.0模型更关注“组织有没有一套机制去持续地把事情做好”。换句话说评估的重心从项目层面的执行细节上升到了组织层面的“系统能力”。这个变化直接体现在实践域的合并和重新命名上。2.0 时代“治理”和“基础设施”虽然已经存在但更多是被当作管理支撑类实践来看待很多人把它们理解成“写制度”“买服务器”这种表层动作。而 3.0 把这两个域提升到了与工程类实践域并驾齐驱的位置同时把“组织培训”这类人才发展相关的内容也重新赋予了“能力建设”的内涵。1.2 治理、基础设施、培训——三个域的真实定位我自己的理解是治理管的是“什么能做、什么不能做、做了怎么被验证”基础设施管的是“用什么工具、在什么平台、靠什么资源去做”培训管的是“谁来做、会不会做、做到什么标准”。这三个问题不解决项目层面的流程再完善换个人、换个环境、换个时间结果立刻就变形。所以 CMMI 3.0 在设计评估视图和评估方法时特别强调了对这三类组织级能力的证据审查。评估时不再只看某个项目有没有按流程走而是要看组织有没有把规则、平台、人才三件事真正连起来。这也是为什么很多企业 2.0 评估能过3.0 却暴露出大量“系统性缺失”的根本原因。2. 治理实践域从“结果导向”到“规则导向”的转变治理域在 CMMI 3.0 里是一个核心且容易产生误解的实践域。先说一个我在项目现场经常看到的场景很多公司的治理文档写得非常漂亮定义了一大堆政策、流程、角色职责但评估师一问“这个政策最近一次评审是什么时候”“谁对政策偏差负责”“偏离流程时怎么申请豁免”整个会议室就安静了。治理域要解决的恰恰就是这些“管理上的管理”问题。2.1 治理维度的标准要求到底在考什么CMMI 3.0 治理实践域Governance关注的不是具体某项工作怎么干而是组织如何建立统一的方向、原则和约束条件并确保实际运作不偏离这些约束。它的核心信息项和使用视图通常围绕高层管理意图、管理指令、偏差处理机制来展开。具体来说治理域通常涉及下面的实践主题定义组织的战略方向与业务目标并将这些目标转化为可执行的治理原则建立决策权限矩阵明确什么人可以决定什么事情建立政策、标准与流程体系的发布、评审、变更和废止机制对项目和组织运行中的重大偏差进行监控、分析和升级处理确保管理层定期评审组织的绩效趋势而不是只看单点结果。我常给团队打一个比方治理不是写一堆“制度大全”而是给组织装一个“方向盘加刹车系统”。方向盘保证大家都在朝同一个方向走刹车保证发现跑偏时有人能踩得下来。没有这套机制流程做得再细也只是纸面繁荣。2.2 落地治理域从组织结构到决策机制的实操清单真正落地治理域我建议按下面这个顺序推进每一条都有明确的产出物。第一件事是把业务目标和过程改进目标对齐。这个动作看着虚实际非常重要。我见过一家做嵌入式软件的公司管理层说“今年要减少现场故障率”但过程改进小组做的却是“把文档模板统一”。治理域要求你把“减少现场故障率”这样一个业务指标翻译成过程改进的具体工作项比如加强代码评审、改进缺陷分析机制、建立现场问题回溯流程。翻译不出来说明治理和业务是脱节的。第二件事是建立清晰的决策权限矩阵。不需要很复杂但要解决实际问题。比如项目计划里的里程碑调整需要谁批准流程裁剪需要谁批准注入新工具链需要谁拍板这些决策不能都压到一把手头上也不能全放给一线自己说了算。我常用的做法是画一张 RACI 图明确每个关键决策的 Responsible、Approve、Consult、Inform贴在项目办公室和内部系统首页上效果比一本制度手册强得多。第三件事是设置“稳定的治理节奏”。治理不是出了问题才开会而是定期评审。我建议至少每个季度做一次组织级评审内容涵盖过程绩效、偏差分析、资源配置、风险趋势。评估时你要能拿出连续几个季度的评审记录而不是临时补几张会议纪要。这个节奏本身就是体系在运转的证据。第四件事是建立偏差处理与豁免通道。团队在实际执行时一定会遇到“标准流程不适用于当前场景”的情况。治理域不要求你死板地遵守流程而是要求你有明确的偏差申请、评审、批准、跟踪过程。我在一次评估前辅导中帮客户补的正是这条通道定义了偏差单模板、审批时限和回归检查点。这一条很容易被忽略但评估师特别爱看。2.3 治理域评估中常见的三个雷区第一个雷区是“政策与流程不联动”。有些公司的政策是一个体系各项目组的实际运作流程是另一个体系两者之间没有映射关系。评估师问“这个项目为什么没按组织流程走”得到的回答往往是“我们有自己的特殊情况”。治理域要求的是你可以裁剪组织流程但必须在批准的偏差或裁剪记录里体现而不是默认不遵守。第二个雷区是“高层评审停留在听取汇报”。评审会议必须有实质性的绩效数据分析和决策输出。如果每次高层评审都只是项目经理念 PPT、高层点头那这个实践基本就是不合格的。好的做法是提前把绩效数据包发给参会者会上直接讨论异常点和决策事项。第三个雷区是“治理文档成了部门的独角戏”。有些公司把治理责任挂在质量部或者流程改进部业务部门完全是被动配合。治理域强调的其实是“业务管理层直接参与”。如果你们公司的高层只是审批签字、从不参与规则评审那这件事还没落地。3. 基础设施实践域被误读最多的一个域基础设施域Infrastructure在 CMMI 3.0 里是典型的“看起来简单、做起来容易偏”的实践域。我经常问学员一句话“你们公司的基础设施包含哪些东西”有人说服务器有人说开发环境有人说办公系统。这些都不全对因为基础设施域在模型里的定义比大多数人理解的要宽很多。3.1 V2.0 时代的基础设施是“环境”3.0 里是“平台”如果你经历过 2.0可能还记得基础设施实践域主要关注的是工作产品交付所需要的工作环境、工具系统和相关资源。当时的常见做法是开一份“环境清单”服务器清单、软件工具清单、许可证清单然后就算应付过去了。但 CMMI 3.0 对基础设施域的关注点明显深化了。它不再满足于“有环境可用”而是要求组织具备“面向复用、持续演进、与治理联动”的基础设施管理能力。换句话说3.0 会关注你的工具链是否统一、环境配置是否可追溯、基础设施的变更是否有审批、团队使用基础设施的问题是否被系统收集和解决。我理解这个变化的背景是行业本身已经变了。现在的研发几乎离不开持续集成、持续交付、容器、自动化测试和部署平台这些东西构成了组织真正意义上的“生产力底座”。CMMI 3.0 把基础设施域做厚本质上是承认了工具平台在现代软件研发中的战略地位。3.2 工作环境、工具链、复用资产三层落地要点要把基础设施域做扎实我习惯于拆成三层来落地。第一层是物理与基础环境。包括办公网络、开发服务器、测试设备、代码托管服务器、文档协作系统等。这一层的核心要求是稳定性和可用性。你要能回答环境出现故障时有没有应急预案资源不足时有没有申请和扩容通道员工入职后能不能在一天内拿到开发所需的环境权限这些问题直接决定了研发效能的天花板。第二层是工具链与平台。这是 3.0 评估里最受关注的部分。组织级工具链的完整性和统一性比某个团队用什么工具更重要。评估时会看的典型证据包括组织是否定义了统一的代码仓库分支策略、是否建设了持续集成流水线模板、是否提供统一的日志和监控平台、是否有集中的依赖管理仓库。这些基础设施目标不是为了标准化而标准化而是为了减少项目之间的重复工作、提升关键过程的可控性。第三层是可复用资产库。这是很多团队最容易忽略的。模型要求组织建立并维护一套可复用的工作产品、组件、模块或者服务资产。我在实践里的做法是推动建立组织级“内部组件市场”公共库、基础服务、前端组件、部署脚本、安全扫描配置等都按模块化和文档化标准入库。这样做带来的直接好处是评估时你可以展示一个持续增长、有使用记录、有维护机制的资产库而不是空口说“我们有很多积累”。3.3 打通基础设施与治理审计日志和配置基线基础设施域落地时有一个很关键的实操细节基础设施的变更必须可追溯使用情况必须可审计。我举一个典型场景某个团队为了赶进度绕过组织级监控平台直接把应用部署到一台谁都不知道的服务器上。如果这事没人管基础设施治理就形同虚设。我们当时的做法是建立一套基础设施配置基线和管理台账。每台环境服务器、每个工具平台都有负责人、使用范围、配置说明和变更记录。基础环境的变更走统一的变更申请流程重大变更要更新配置基线文档。平台巡检记录、资源监控日志、工具权限审批记录都归档保留。CMMI 3.0 评估时需要这些证据从实际管理的角度讲这也能避免“环境黑暗角落”带来的质量风险。基础设施域还有一个我特别强调的点不要把基础设施当成一次性投资。模型会看组织是否定期评审基础设施的适用性、性能、安全性是否根据项目反馈调整工具策略。你需要一个类似“基础设施改进待办列表”的东西把研发团队提出的工具痛点、环境瓶颈、自动化缺口纳入管理并展示它们如何被解决。4. 组织级培训实践域把“培训记录”做成“能力地图”组织级培训这个域在 CMMI 3.0 里的名字在 2.0 时期叫“组织培训”或“培训组织”很多公司把它等同于“每年组织几场技术培训、保留签到表”这么简单。但模型真正要求的是从培训需求分析到培训效果评估的完整体系。而且 3.0 特别强调了“组织核心能力”这个概念——培训不是福利而是组织实现业务目标的关键投资。4.1 培训域实践要求的本质从需求到效果的全链路CMMI 3.0 中组织级培训实践域关注的几个关键主题包括识别组织战略目标所需的关键技能、评估组织当前的能力差距、设计和交付有针对性的培训方案、评估培训在岗位工作中的实际效果。这是一条完整链路任何一个环节缺失都会在评估时被追问。我经常用一句话概括这个域的本质培训不是供给侧驱动的而是需求侧驱动的。有些公司每年年初由各部门报培训计划部门为了完成任务就随便报几个公开课人力资源部门汇总一下就算完事。这种模式下培训记录再完整也说明不了组织能力建设水平。模型要看到的是你根据战略目标识别出了哪些关键能力用什么方法评估现状制定了什么培训计划来缩小差距最后验证了什么效果。4.2 胜任力模型、课程体系、效果评估的三步法我在实践中总结出了三步落地法非常适合大多数做研发的企业参考。第一步是建立岗位胜任力模型。你不需要搞得特别学术但至少要画出核心研发岗位的必知必会清单。比如对一个软件工程师岗位胜任力可能包括编程语言、代码评审方法、单元测试、安全编码意识、性能调优等。每个能力项分入门、熟练、精通三级定义清楚每一级的行为特征。这份清单的价值在于让培训需求变得可分析、可度量而不是拍脑袋。第二步是梳理培训课程与能力项的映射关系。每门内部或外部课程要能回答“它提升了哪个岗位的哪个能力项”。同时为每个关键能力项指定至少一个可选的培训或替代证明方式比如入职训练营、在线学习路径、师徒制带教、在岗实践考核。这个映射关系搭建好以后培训计划的制定就容易了先看差距再定课程不搞无差别全员培训。第三步是效果评估这是最难也最容易被忽略的。CMMI 3.0 对效果评估不是只看“培训后考试多少分”而是关注受训者在实际工作中是否应用了新技能以及应用后是否产生了正向结果。我推荐一个轻量方案培训结束后一个月做一次实践追踪通过项目经理反馈、代码评审记录、质量数据变化来判断培训是否有效。举个例子如果培训主题是“团队使用自动化测试”那效果评估就可以看培训后一个月内各项目自动化测试覆盖率有没有上升。4.3 与人力资源体系对接时的关键取舍这里我必须提醒一句CMMI 里的组织级培训跟人力资源部门做的年度培训台账经常是两套逻辑。人力资源部门关注培训时长、参训人数、培训完成率而 CMMI 实践域关注的是能力差距分析、培训对业务目标的支撑、培训效果的正向证据。实际做的时候我的建议是不要强行把两套体系合并成一张表而是建立对应关系。人事系统里仍然保留培训记录但过程改进小组要额外维护一份“能力建设档案”里面记录每个关键岗位的能力评级、发展计划、培训项目和实践效果。评估时拿这套档案出来比拿厚厚的签到表有说服力得多。组织级培训还涉及一个容易被小团队忽略的点新员工入职培训。很多公司把新员工培训理解为“发电脑、讲制度、认识人”但模型更希望看到新员工能快速获得标准化的工作方法训练。比如代码规范、配置管理流程、安全开发要求、测试策略这些都应该在新员工上岗前完成统一培训并且留有记录。项目团队评估时评估师经常会随机问新员工“你入职时接受了哪些培训”“相关流程怎么获取”答不上来就是证据缺口。5. 三个域的联动一种“组织能力三角形”的落地路径前面把三个实践域分开讲清楚了但实际评估和实际管理里最见功力的其实是它们的联动关系。在做 CMMI 3.0 咨询时我一直跟客户强调不要孤立地建设治理、基础设施和培训要把它们看成一组互相咬合的齿轮。5.1 治理提供规则基础设施提供舞台培训提供演员我习惯用一个“组织能力三角形”来解释这种联动关系。治理是三角形的顶角它决定方向。治理部门要定义哪些技术和流程标准是组织级的底线比如“代码必须经过同行评审”“配置项变更必须走申请审批”。这些规则一旦确定基础设施就要提供对应的支撑能力。比如治理要求代码评审基础设施就要提供代码评审工具和自动提醒治理要求环境配置可追溯基础设施就要提供配置管理机制和审计日志能力。培训则承担了“让团队能按规则做事”的重任。每一项新的治理要求或新的基础设施上线都要配套相应的培训和宣贯。没有培训规则只能挂在墙上没有基础设施规则执行全靠个人自觉没有治理基础设施和培训就会偏离组织目标。这个三角形任何一边短了另外两边都会出问题。5.2 推进顺序建议先治理再基础设施再培训如果你们公司是第一次系统性建设这三个域我建议按“治理 → 基础设施 → 培训”的顺序推进。这样做有一个很实际的理由先定规则你才知道要建什么平台、培训什么技能。举一个我经历过的真实案例。某软件开发公司在 3.0 评估前八个月启动改进初期团队一上来就买了一套新项目管理工具又组织了两场敏捷培训结果三个月后大家发现项目管理制度还是老一套工具与旧流程对不上培训学的东西在项目里根本不让用。后来我们调整策略先把治理层的流程、角色、决策机制重新梳理再根据流程需要裁剪和配置工具最后围绕新工具、新流程做针对性培训才慢慢走上正轨。这个例子我反复讲因为它太典型了。工具和培训不是独立的改进项它们是治理规则的“使能器”。没有治理规则在前工具和培训都是浮动的。5.3 三个域联动时的证据准备思路CMMI 3.0 评估时证据的呈现方式也要符合这种联动逻辑。单独拿出一堆治理文档、一堆工具截图、一堆培训记录效果远不如讲一个“联动故事”。我建议在评估前准备一套“组织能力演示包”大概包含下面几样东西一张组织级架构图把治理结构、基础设施平台、培训体系画在一页纸上一份年度关键改进清单标明每项改进来自哪个治理决策、用了什么基础设施支撑、配套了什么培训包若干个“规则-平台-能力”的对应示例比如“治理要求自动化测试 → 基础设施提供了统一测试流水线模板 → 培训体系开设了自动化测试实训营”并各附一两个样例证据。这套演示材料的意义在于帮助评估师快速建立全局认知。我在评估现场的经验是当你能主动把三个域的关联讲清楚评估师对单个实践域的追问会顺畅很多这种“引导式交流”对通过评估很有帮助也不完全是为了评估——它同样能帮助你确认公司内部这些模块到底有没有真正串起来。6. 实操中的常见坑与排查实录最后这部分我集中写一些在 CMMI 3.0 落地和评估准备过程中反复踩到的问题。这些内容来自真实项目经验常规培训材料里很少提到。6.1 治理文档与执行两张皮这是最常见的坑几乎每个准备 3.0 评估的公司都会遇到。治理文档写得完美但一线执行时根本不看。排查方法很简单随机抽两个项目对照治理流程走一遍看项目实际执行和文档规定的差异点在哪里。我的经验是不需要苛求完全一致但要能解释差异。如果差异是因为项目特殊情况应该有裁剪记录如果差异是因为文档本身不合理那就该更新文档。治理域最怕的是“从头到尾没人提过差异”这通常说明流程已经流于形式。曾经有一个项目组全员都不知道组织级流程文档存在哪里这比流程不合理更严重。6.2 基础设施忽略“组织级复用”很多团队在梳理基础设施时只写了每个项目各自使用了什么工具完全看不出组织级复用。但 3.0 基础实施域极为看重“组织是否持续改进可供多个项目使用的工作环境”。排查方式很简单查看项目的持续集成流水线脚本是不是每个项目都从零开始写公共模块是不是复制粘贴到各个仓库部署标准是否因项目而异。如果答案是肯定的说明组织级基础设施还停留在“环境拼凑”阶段。我的建议是从一个高频场景入手比如建立统一的持续集成流水线模板先固化再迭代等跑顺以后逐步覆盖更多项目类型。6.3 培训评估流于形式培训效果的评估是所有环节里最容易被做假的。我见过太多公司培训结束发一张问卷、考一次试然后就把培训记录归档。CMMI 3.0 的评估师很聪明他们通常会追问“这门课培训后团队工作方式有什么改变能拿出工作产物上的变化吗”我建议在培训计划阶段就想好评估指标。比如“安全编码培训”效果指标可以定义为“培训后三个月内项目组静态扫描高危问题数下降比例”。“代码评审培训”效果指标可以是“评审会议平均时长下降”“评审发现的缺陷数增加”。把培训效果跟数据指标绑起来不仅对评估有利对培训组织者也有利——你能真正看出哪门课值得保留、哪门课是浪费钱。6.4 工具选型与自动化检查工具选型也是常见坑。有些公司在准备 3.0 前突然上了好几套大型工具但组织根本消化不了。我见过一家公司同时买了项目管理系统、测试管理平台、需求管理工具、缺陷管理工具四个系统的数据根本不同步一线员工每天要在不同系统里重复录入信息。这种基础设施建设反而是负资产。我的实操经验是工具选型从“治理要什么”出发不要从“工具厂商有什么”出发。先明确哪些环节需要工具固化哪些环节用轻量方式就行。优先采用团队已经在用且普遍接受度高的工具哪怕它不够“大牌”也比推一套陌生的重平台强。另外一定要有“自动化证据收集”的思想。CMMI 3.0 评估要看的很多证据比如流程执行记录、变更审批历史、培训完成记录都能从系统里自动导出这比花费大量人力补纸质记录要可靠得多。6.5 时间线和评估前的最后冲刺最后提醒一句“治理、基础设施、培训”三个域不适合临阵突击。它们都是组织级能力的建设需要时间沉淀证据。如果评估时间已经确定我建议至少留出四到六个月的持续运行期这样你才能积累连续多个季度的评审记录、多个项目的平台复用记录、多期培训的效果追踪数据。没有运行周期的证据在 3.0 评估里几乎是无效的。我个人在这些年的实践里体会最深的一点是CMMI 3.0 真正考验的不是某个人角色有多懂模型而是整个组织有没有把“规则、平台、人”三者拧成一股绳。很多团队总觉得评估难难在平时这三条线各干各的。如果你今天读完这篇文章只记住一件事我希望是治理定原则基础设施给手段培训建能力然后把证据链留清楚。做到这一步3.0 评估不会成为负担反而会成为一个检验组织管理成色的照妖镜。 
长河君 · 2026/10/16 14:56:08 · 阅读 1.2k CMMI 3.0核心三域落地：治理、基础设施与组织级培训
这几年做过程改进咨询和评估我明显感觉到一件事CMMI 模型本身越来越不像一套“文档规范”而更像一套“组织运行逻辑”。尤其是到了 CMMI 3.0大家讨论最多的不是某个实践域怎么写文档而是治理、基础设施、组织级培训这三个域到底怎么落地、怎么联动、怎么在评估时拿出让人信服的证据。不少团队按 2.0 的老经验去应对 3.0结果发现自己卡在“证据不对路”的尴尬局面上。这篇文章我就围绕 CMMI 3.0 里这三个关键实践域把自己做过项目、走过弯路、反复调整后的理解完整写出来。不绕弯子直接说每个域到底要求什么、为什么这么改、实际操作时怎么做才能既过评估又真正提升组织能力。不管你是正准备做 CMMI 3.0 评估还是只想借模型梳理公司内部管理这篇文章都能给你一些可以直接用的思路。1. 为什么 CMMI 3.0 把这三件事单独拎出来说很多第一次接触 CMMI 3.0 的人会问治理、基础设施、组织级培训这三个词听上去都很大好像跟“开发流程”没什么直接关系。但真正理解模型逻辑以后你会发现这三个域恰恰是组织能力能不能持续运转的地基。1.1 版本演进的主线从“做事”到“让组织能持续做事”CMMI 从 2.0 进化到 3.0主线逻辑其实非常清晰过去模型的重点在于“有没有把一件事情做好”比如需求管理、项目计划、配置管理、质量保证。但到了 3.0模型更关注“组织有没有一套机制去持续地把事情做好”。换句话说评估的重心从项目层面的执行细节上升到了组织层面的“系统能力”。这个变化直接体现在实践域的合并和重新命名上。2.0 时代“治理”和“基础设施”虽然已经存在但更多是被当作管理支撑类实践来看待很多人把它们理解成“写制度”“买服务器”这种表层动作。而 3.0 把这两个域提升到了与工程类实践域并驾齐驱的位置同时把“组织培训”这类人才发展相关的内容也重新赋予了“能力建设”的内涵。1.2 治理、基础设施、培训——三个域的真实定位我自己的理解是治理管的是“什么能做、什么不能做、做了怎么被验证”基础设施管的是“用什么工具、在什么平台、靠什么资源去做”培训管的是“谁来做、会不会做、做到什么标准”。这三个问题不解决项目层面的流程再完善换个人、换个环境、换个时间结果立刻就变形。所以 CMMI 3.0 在设计评估视图和评估方法时特别强调了对这三类组织级能力的证据审查。评估时不再只看某个项目有没有按流程走而是要看组织有没有把规则、平台、人才三件事真正连起来。这也是为什么很多企业 2.0 评估能过3.0 却暴露出大量“系统性缺失”的根本原因。2. 治理实践域从“结果导向”到“规则导向”的转变治理域在 CMMI 3.0 里是一个核心且容易产生误解的实践域。先说一个我在项目现场经常看到的场景很多公司的治理文档写得非常漂亮定义了一大堆政策、流程、角色职责但评估师一问“这个政策最近一次评审是什么时候”“谁对政策偏差负责”“偏离流程时怎么申请豁免”整个会议室就安静了。治理域要解决的恰恰就是这些“管理上的管理”问题。2.1 治理维度的标准要求到底在考什么CMMI 3.0 治理实践域Governance关注的不是具体某项工作怎么干而是组织如何建立统一的方向、原则和约束条件并确保实际运作不偏离这些约束。它的核心信息项和使用视图通常围绕高层管理意图、管理指令、偏差处理机制来展开。具体来说治理域通常涉及下面的实践主题定义组织的战略方向与业务目标并将这些目标转化为可执行的治理原则建立决策权限矩阵明确什么人可以决定什么事情建立政策、标准与流程体系的发布、评审、变更和废止机制对项目和组织运行中的重大偏差进行监控、分析和升级处理确保管理层定期评审组织的绩效趋势而不是只看单点结果。我常给团队打一个比方治理不是写一堆“制度大全”而是给组织装一个“方向盘加刹车系统”。方向盘保证大家都在朝同一个方向走刹车保证发现跑偏时有人能踩得下来。没有这套机制流程做得再细也只是纸面繁荣。2.2 落地治理域从组织结构到决策机制的实操清单真正落地治理域我建议按下面这个顺序推进每一条都有明确的产出物。第一件事是把业务目标和过程改进目标对齐。这个动作看着虚实际非常重要。我见过一家做嵌入式软件的公司管理层说“今年要减少现场故障率”但过程改进小组做的却是“把文档模板统一”。治理域要求你把“减少现场故障率”这样一个业务指标翻译成过程改进的具体工作项比如加强代码评审、改进缺陷分析机制、建立现场问题回溯流程。翻译不出来说明治理和业务是脱节的。第二件事是建立清晰的决策权限矩阵。不需要很复杂但要解决实际问题。比如项目计划里的里程碑调整需要谁批准流程裁剪需要谁批准注入新工具链需要谁拍板这些决策不能都压到一把手头上也不能全放给一线自己说了算。我常用的做法是画一张 RACI 图明确每个关键决策的 Responsible、Approve、Consult、Inform贴在项目办公室和内部系统首页上效果比一本制度手册强得多。第三件事是设置“稳定的治理节奏”。治理不是出了问题才开会而是定期评审。我建议至少每个季度做一次组织级评审内容涵盖过程绩效、偏差分析、资源配置、风险趋势。评估时你要能拿出连续几个季度的评审记录而不是临时补几张会议纪要。这个节奏本身就是体系在运转的证据。第四件事是建立偏差处理与豁免通道。团队在实际执行时一定会遇到“标准流程不适用于当前场景”的情况。治理域不要求你死板地遵守流程而是要求你有明确的偏差申请、评审、批准、跟踪过程。我在一次评估前辅导中帮客户补的正是这条通道定义了偏差单模板、审批时限和回归检查点。这一条很容易被忽略但评估师特别爱看。2.3 治理域评估中常见的三个雷区第一个雷区是“政策与流程不联动”。有些公司的政策是一个体系各项目组的实际运作流程是另一个体系两者之间没有映射关系。评估师问“这个项目为什么没按组织流程走”得到的回答往往是“我们有自己的特殊情况”。治理域要求的是你可以裁剪组织流程但必须在批准的偏差或裁剪记录里体现而不是默认不遵守。第二个雷区是“高层评审停留在听取汇报”。评审会议必须有实质性的绩效数据分析和决策输出。如果每次高层评审都只是项目经理念 PPT、高层点头那这个实践基本就是不合格的。好的做法是提前把绩效数据包发给参会者会上直接讨论异常点和决策事项。第三个雷区是“治理文档成了部门的独角戏”。有些公司把治理责任挂在质量部或者流程改进部业务部门完全是被动配合。治理域强调的其实是“业务管理层直接参与”。如果你们公司的高层只是审批签字、从不参与规则评审那这件事还没落地。3. 基础设施实践域被误读最多的一个域基础设施域Infrastructure在 CMMI 3.0 里是典型的“看起来简单、做起来容易偏”的实践域。我经常问学员一句话“你们公司的基础设施包含哪些东西”有人说服务器有人说开发环境有人说办公系统。这些都不全对因为基础设施域在模型里的定义比大多数人理解的要宽很多。3.1 V2.0 时代的基础设施是“环境”3.0 里是“平台”如果你经历过 2.0可能还记得基础设施实践域主要关注的是工作产品交付所需要的工作环境、工具系统和相关资源。当时的常见做法是开一份“环境清单”服务器清单、软件工具清单、许可证清单然后就算应付过去了。但 CMMI 3.0 对基础设施域的关注点明显深化了。它不再满足于“有环境可用”而是要求组织具备“面向复用、持续演进、与治理联动”的基础设施管理能力。换句话说3.0 会关注你的工具链是否统一、环境配置是否可追溯、基础设施的变更是否有审批、团队使用基础设施的问题是否被系统收集和解决。我理解这个变化的背景是行业本身已经变了。现在的研发几乎离不开持续集成、持续交付、容器、自动化测试和部署平台这些东西构成了组织真正意义上的“生产力底座”。CMMI 3.0 把基础设施域做厚本质上是承认了工具平台在现代软件研发中的战略地位。3.2 工作环境、工具链、复用资产三层落地要点要把基础设施域做扎实我习惯于拆成三层来落地。第一层是物理与基础环境。包括办公网络、开发服务器、测试设备、代码托管服务器、文档协作系统等。这一层的核心要求是稳定性和可用性。你要能回答环境出现故障时有没有应急预案资源不足时有没有申请和扩容通道员工入职后能不能在一天内拿到开发所需的环境权限这些问题直接决定了研发效能的天花板。第二层是工具链与平台。这是 3.0 评估里最受关注的部分。组织级工具链的完整性和统一性比某个团队用什么工具更重要。评估时会看的典型证据包括组织是否定义了统一的代码仓库分支策略、是否建设了持续集成流水线模板、是否提供统一的日志和监控平台、是否有集中的依赖管理仓库。这些基础设施目标不是为了标准化而标准化而是为了减少项目之间的重复工作、提升关键过程的可控性。第三层是可复用资产库。这是很多团队最容易忽略的。模型要求组织建立并维护一套可复用的工作产品、组件、模块或者服务资产。我在实践里的做法是推动建立组织级“内部组件市场”公共库、基础服务、前端组件、部署脚本、安全扫描配置等都按模块化和文档化标准入库。这样做带来的直接好处是评估时你可以展示一个持续增长、有使用记录、有维护机制的资产库而不是空口说“我们有很多积累”。3.3 打通基础设施与治理审计日志和配置基线基础设施域落地时有一个很关键的实操细节基础设施的变更必须可追溯使用情况必须可审计。我举一个典型场景某个团队为了赶进度绕过组织级监控平台直接把应用部署到一台谁都不知道的服务器上。如果这事没人管基础设施治理就形同虚设。我们当时的做法是建立一套基础设施配置基线和管理台账。每台环境服务器、每个工具平台都有负责人、使用范围、配置说明和变更记录。基础环境的变更走统一的变更申请流程重大变更要更新配置基线文档。平台巡检记录、资源监控日志、工具权限审批记录都归档保留。CMMI 3.0 评估时需要这些证据从实际管理的角度讲这也能避免“环境黑暗角落”带来的质量风险。基础设施域还有一个我特别强调的点不要把基础设施当成一次性投资。模型会看组织是否定期评审基础设施的适用性、性能、安全性是否根据项目反馈调整工具策略。你需要一个类似“基础设施改进待办列表”的东西把研发团队提出的工具痛点、环境瓶颈、自动化缺口纳入管理并展示它们如何被解决。4. 组织级培训实践域把“培训记录”做成“能力地图”组织级培训这个域在 CMMI 3.0 里的名字在 2.0 时期叫“组织培训”或“培训组织”很多公司把它等同于“每年组织几场技术培训、保留签到表”这么简单。但模型真正要求的是从培训需求分析到培训效果评估的完整体系。而且 3.0 特别强调了“组织核心能力”这个概念——培训不是福利而是组织实现业务目标的关键投资。4.1 培训域实践要求的本质从需求到效果的全链路CMMI 3.0 中组织级培训实践域关注的几个关键主题包括识别组织战略目标所需的关键技能、评估组织当前的能力差距、设计和交付有针对性的培训方案、评估培训在岗位工作中的实际效果。这是一条完整链路任何一个环节缺失都会在评估时被追问。我经常用一句话概括这个域的本质培训不是供给侧驱动的而是需求侧驱动的。有些公司每年年初由各部门报培训计划部门为了完成任务就随便报几个公开课人力资源部门汇总一下就算完事。这种模式下培训记录再完整也说明不了组织能力建设水平。模型要看到的是你根据战略目标识别出了哪些关键能力用什么方法评估现状制定了什么培训计划来缩小差距最后验证了什么效果。4.2 胜任力模型、课程体系、效果评估的三步法我在实践中总结出了三步落地法非常适合大多数做研发的企业参考。第一步是建立岗位胜任力模型。你不需要搞得特别学术但至少要画出核心研发岗位的必知必会清单。比如对一个软件工程师岗位胜任力可能包括编程语言、代码评审方法、单元测试、安全编码意识、性能调优等。每个能力项分入门、熟练、精通三级定义清楚每一级的行为特征。这份清单的价值在于让培训需求变得可分析、可度量而不是拍脑袋。第二步是梳理培训课程与能力项的映射关系。每门内部或外部课程要能回答“它提升了哪个岗位的哪个能力项”。同时为每个关键能力项指定至少一个可选的培训或替代证明方式比如入职训练营、在线学习路径、师徒制带教、在岗实践考核。这个映射关系搭建好以后培训计划的制定就容易了先看差距再定课程不搞无差别全员培训。第三步是效果评估这是最难也最容易被忽略的。CMMI 3.0 对效果评估不是只看“培训后考试多少分”而是关注受训者在实际工作中是否应用了新技能以及应用后是否产生了正向结果。我推荐一个轻量方案培训结束后一个月做一次实践追踪通过项目经理反馈、代码评审记录、质量数据变化来判断培训是否有效。举个例子如果培训主题是“团队使用自动化测试”那效果评估就可以看培训后一个月内各项目自动化测试覆盖率有没有上升。4.3 与人力资源体系对接时的关键取舍这里我必须提醒一句CMMI 里的组织级培训跟人力资源部门做的年度培训台账经常是两套逻辑。人力资源部门关注培训时长、参训人数、培训完成率而 CMMI 实践域关注的是能力差距分析、培训对业务目标的支撑、培训效果的正向证据。实际做的时候我的建议是不要强行把两套体系合并成一张表而是建立对应关系。人事系统里仍然保留培训记录但过程改进小组要额外维护一份“能力建设档案”里面记录每个关键岗位的能力评级、发展计划、培训项目和实践效果。评估时拿这套档案出来比拿厚厚的签到表有说服力得多。组织级培训还涉及一个容易被小团队忽略的点新员工入职培训。很多公司把新员工培训理解为“发电脑、讲制度、认识人”但模型更希望看到新员工能快速获得标准化的工作方法训练。比如代码规范、配置管理流程、安全开发要求、测试策略这些都应该在新员工上岗前完成统一培训并且留有记录。项目团队评估时评估师经常会随机问新员工“你入职时接受了哪些培训”“相关流程怎么获取”答不上来就是证据缺口。5. 三个域的联动一种“组织能力三角形”的落地路径前面把三个实践域分开讲清楚了但实际评估和实际管理里最见功力的其实是它们的联动关系。在做 CMMI 3.0 咨询时我一直跟客户强调不要孤立地建设治理、基础设施和培训要把它们看成一组互相咬合的齿轮。5.1 治理提供规则基础设施提供舞台培训提供演员我习惯用一个“组织能力三角形”来解释这种联动关系。治理是三角形的顶角它决定方向。治理部门要定义哪些技术和流程标准是组织级的底线比如“代码必须经过同行评审”“配置项变更必须走申请审批”。这些规则一旦确定基础设施就要提供对应的支撑能力。比如治理要求代码评审基础设施就要提供代码评审工具和自动提醒治理要求环境配置可追溯基础设施就要提供配置管理机制和审计日志能力。培训则承担了“让团队能按规则做事”的重任。每一项新的治理要求或新的基础设施上线都要配套相应的培训和宣贯。没有培训规则只能挂在墙上没有基础设施规则执行全靠个人自觉没有治理基础设施和培训就会偏离组织目标。这个三角形任何一边短了另外两边都会出问题。5.2 推进顺序建议先治理再基础设施再培训如果你们公司是第一次系统性建设这三个域我建议按“治理 → 基础设施 → 培训”的顺序推进。这样做有一个很实际的理由先定规则你才知道要建什么平台、培训什么技能。举一个我经历过的真实案例。某软件开发公司在 3.0 评估前八个月启动改进初期团队一上来就买了一套新项目管理工具又组织了两场敏捷培训结果三个月后大家发现项目管理制度还是老一套工具与旧流程对不上培训学的东西在项目里根本不让用。后来我们调整策略先把治理层的流程、角色、决策机制重新梳理再根据流程需要裁剪和配置工具最后围绕新工具、新流程做针对性培训才慢慢走上正轨。这个例子我反复讲因为它太典型了。工具和培训不是独立的改进项它们是治理规则的“使能器”。没有治理规则在前工具和培训都是浮动的。5.3 三个域联动时的证据准备思路CMMI 3.0 评估时证据的呈现方式也要符合这种联动逻辑。单独拿出一堆治理文档、一堆工具截图、一堆培训记录效果远不如讲一个“联动故事”。我建议在评估前准备一套“组织能力演示包”大概包含下面几样东西一张组织级架构图把治理结构、基础设施平台、培训体系画在一页纸上一份年度关键改进清单标明每项改进来自哪个治理决策、用了什么基础设施支撑、配套了什么培训包若干个“规则-平台-能力”的对应示例比如“治理要求自动化测试 → 基础设施提供了统一测试流水线模板 → 培训体系开设了自动化测试实训营”并各附一两个样例证据。这套演示材料的意义在于帮助评估师快速建立全局认知。我在评估现场的经验是当你能主动把三个域的关联讲清楚评估师对单个实践域的追问会顺畅很多这种“引导式交流”对通过评估很有帮助也不完全是为了评估——它同样能帮助你确认公司内部这些模块到底有没有真正串起来。6. 实操中的常见坑与排查实录最后这部分我集中写一些在 CMMI 3.0 落地和评估准备过程中反复踩到的问题。这些内容来自真实项目经验常规培训材料里很少提到。6.1 治理文档与执行两张皮这是最常见的坑几乎每个准备 3.0 评估的公司都会遇到。治理文档写得完美但一线执行时根本不看。排查方法很简单随机抽两个项目对照治理流程走一遍看项目实际执行和文档规定的差异点在哪里。我的经验是不需要苛求完全一致但要能解释差异。如果差异是因为项目特殊情况应该有裁剪记录如果差异是因为文档本身不合理那就该更新文档。治理域最怕的是“从头到尾没人提过差异”这通常说明流程已经流于形式。曾经有一个项目组全员都不知道组织级流程文档存在哪里这比流程不合理更严重。6.2 基础设施忽略“组织级复用”很多团队在梳理基础设施时只写了每个项目各自使用了什么工具完全看不出组织级复用。但 3.0 基础实施域极为看重“组织是否持续改进可供多个项目使用的工作环境”。排查方式很简单查看项目的持续集成流水线脚本是不是每个项目都从零开始写公共模块是不是复制粘贴到各个仓库部署标准是否因项目而异。如果答案是肯定的说明组织级基础设施还停留在“环境拼凑”阶段。我的建议是从一个高频场景入手比如建立统一的持续集成流水线模板先固化再迭代等跑顺以后逐步覆盖更多项目类型。6.3 培训评估流于形式培训效果的评估是所有环节里最容易被做假的。我见过太多公司培训结束发一张问卷、考一次试然后就把培训记录归档。CMMI 3.0 的评估师很聪明他们通常会追问“这门课培训后团队工作方式有什么改变能拿出工作产物上的变化吗”我建议在培训计划阶段就想好评估指标。比如“安全编码培训”效果指标可以定义为“培训后三个月内项目组静态扫描高危问题数下降比例”。“代码评审培训”效果指标可以是“评审会议平均时长下降”“评审发现的缺陷数增加”。把培训效果跟数据指标绑起来不仅对评估有利对培训组织者也有利——你能真正看出哪门课值得保留、哪门课是浪费钱。6.4 工具选型与自动化检查工具选型也是常见坑。有些公司在准备 3.0 前突然上了好几套大型工具但组织根本消化不了。我见过一家公司同时买了项目管理系统、测试管理平台、需求管理工具、缺陷管理工具四个系统的数据根本不同步一线员工每天要在不同系统里重复录入信息。这种基础设施建设反而是负资产。我的实操经验是工具选型从“治理要什么”出发不要从“工具厂商有什么”出发。先明确哪些环节需要工具固化哪些环节用轻量方式就行。优先采用团队已经在用且普遍接受度高的工具哪怕它不够“大牌”也比推一套陌生的重平台强。另外一定要有“自动化证据收集”的思想。CMMI 3.0 评估要看的很多证据比如流程执行记录、变更审批历史、培训完成记录都能从系统里自动导出这比花费大量人力补纸质记录要可靠得多。6.5 时间线和评估前的最后冲刺最后提醒一句“治理、基础设施、培训”三个域不适合临阵突击。它们都是组织级能力的建设需要时间沉淀证据。如果评估时间已经确定我建议至少留出四到六个月的持续运行期这样你才能积累连续多个季度的评审记录、多个项目的平台复用记录、多期培训的效果追踪数据。没有运行周期的证据在 3.0 评估里几乎是无效的。我个人在这些年的实践里体会最深的一点是CMMI 3.0 真正考验的不是某个人角色有多懂模型而是整个组织有没有把“规则、平台、人”三者拧成一股绳。很多团队总觉得评估难难在平时这三条线各干各的。如果你今天读完这篇文章只记住一件事我希望是治理定原则基础设施给手段培训建能力然后把证据链留清楚。做到这一步3.0 评估不会成为负担反而会成为一个检验组织管理成色的照妖镜。