配置管理计划要先把受控范围定清楚，再确定配置项识别与命名规则、基线与变更控制方式、库与权限、角色分工和记录要求，最后落到可执行的阶段安排与检查项。计划的核心产物是一份可评审的文档加一张配置项清单。本文按范围界定、规则设计、角色分工、示例片段和完成检查的顺序展开，适用于研发项目从零制定或修订配置管理计划的场景。
要点总览（TL;DR）
- 配置管理计划的最小可用版本包含五块内容：受控范围、配置项识别口径、基线与变更规则、库与权限安排、角色与记录要求，缺一块执行时就会退化成口头约定。
- 制定过程按六步推进：识别受控资产、确定命名与版本规则、设计库结构与权限、定义变更与偏离流程、安排审计与状态记录、计划评审与发布，每步都要有可核对的输出。
- 角色分工的关键是每个动作都有明确责任人：配置管理员维护清单与库，项目经理审批基线与重大变更，开发与测试按规则提交并验证，评审者把关计划与审计。
- 配置项清单、基线记录和变更单要写成可填写的格式，示例片段给出了字段与填写方式，实际项目按自身规模和规范调整。
- 计划发布前用八项清单逐项核对，核对通过后进入执行，并在每个里程碑回看变更关闭、基线一致性和审计整改情况。
一份可用的配置管理计划先定哪几件事
配置管理计划的最小可用版本由五块内容构成：受控范围、配置项识别口径、基线与变更规则、库与权限安排、角色与记录要求。这五块缺任何一块，计划都会在执行时退化成口头约定。判断一份计划是否够用，可以看它能否回答“哪些资产受控、谁在什么时候冻结什么、改动走什么路径、记录存在哪里”这四个问题。
受控范围与配置项识别口径。先划定项目中被纳入配置管理的资产边界，通常包括需求文档、设计文档、源代码、测试用例、构建脚本、环境配置和对外交付物。范围要写到可核对的程度，例如“本项目所有进入集成测试的源代码分支与需求基线文档”，而不是“项目相关文档”。范围之外的内容明确列出，避免后续争议。
基线与变更控制的基本规则。基线是配置项在某一时点被正式评审并冻结的状态。计划中要写明设置哪几类基线（如需求基线、设计基线、发布基线）、每类基线的冻结时点和审批人、基线建立后变更的申请入口与审批层级。偏离处理也要有规则：紧急修复、临时绕过审批的情形如何记录和补审。
库结构、权限与备份要求。配置库按项目、配置项类别或阶段划分目录结构，明确读写权限的授予对象。备份频率、保留周期和恢复验证方式要写成可执行的条目，例如“每日增量备份，保留30天，每季度做一次恢复演练”。
角色、记录与阶段安排。计划要落到人：谁担任配置管理员、谁审批基线、谁提交变更。记录要求包括配置项清单、基线记录、变更单和状态报告的格式与存放位置。阶段安排把上述动作挂到项目里程碑上，说明每个阶段开始和结束时配置管理要完成什么。
制定步骤：从范围界定到计划评审
制定过程按六个步骤推进，每步都有明确输入、动作、输出和完成标志。步骤之间可以并行准备，但评审前必须全部闭合。下表给出操作框架，随后对关键步骤做补充说明。
| 步骤 | 输入 | 动作 | 输出 | 完成标志 |
|---|---|---|---|---|
| 1. 识别受控资产并划分类别 | 项目计划、交付物清单、现有文档与代码仓库 | 盘点全部研发资产，按文档、代码、测试资产、环境配置、交付物分类，标注是否受控 | 受控资产清单与配置项类别表 | 每类资产有明确的受控与否结论，无遗漏项 |
| 2. 确定命名、版本与基线规则 | 配置项类别表、组织现有规范 | 为每类配置项定义命名格式、版本号规则、基线类型与冻结时点 | 命名与版本规则、基线定义表 | 任取一个配置项能按规则写出唯一标识和版本号 |
| 3. 设计配置库结构与访问权限 | 命名规则、团队角色名单 | 规划库目录结构，定义各角色的读写权限，确定备份策略 | 库结构说明、权限矩阵、备份方案 | 每个角色能查到自己的权限范围，备份条目可执行 |
| 4. 定义变更与偏离处理流程 | 基线定义表、现有审批流程 | 设计变更申请、影响分析、审批、实施、验证、关闭的路径，规定紧急偏离的记录与补审方式 | 变更流程图或步骤说明、变更单模板 | 一次典型变更能按流程走完全程并留下记录 |
| 5. 安排审计、状态记录与报告 | 变更流程、基线定义 | 确定配置审计的类型（功能审计、物理审计）、频次、执行人和记录格式，定义状态报告的内容与周期 | 审计计划、状态报告模板 | 审计项可逐条核对，报告有固定字段和提交时间 |
| 6. 计划评审与发布 | 前五步全部输出 | 组织项目经理、开发、测试、质量人员评审计划的完整性与可执行性，修订后发布 | 评审通过的配置管理计划文档 | 评审意见闭环，计划版本号与生效日期确定 |
第2步的命名与版本规则要兼顾唯一性和可读性。常见做法是“类别缩写-项目代号-序号-版本号”，版本号区分草稿、评审中、已基线三种状态。基线规则要写明冻结时点，例如需求基线在需求评审通过后冻结，发布基线在回归测试通过后冻结。规则写得越具体，执行时的解释空间越小。
第4步的变更流程要区分常规变更和紧急偏离。常规变更走申请、影响分析、审批、实施、验证、关闭的完整路径；紧急偏离允许先实施后补审，但必须在变更单中记录原因、实施人和补审时限。偏离记录是后续审计的重点对象，计划中要明确由谁跟踪补审闭环。
第5步的审计安排要与项目节奏匹配。迭代型项目可以在每个迭代结束做一次轻量物理审计，检查配置项与清单是否一致；里程碑节点做功能审计，确认基线内容满足约定要求。状态报告按周或按迭代输出，内容包括基线状态、变更数量和未关闭变更单。
角色分工与各阶段交付物
配置管理的角色不在多，在于每个动作都有明确责任人。小团队可以一人兼多角，但职责边界仍要在计划中写清，避免审批人和执行人混同。下表给出常见角色、职责与交付物的对应关系。
| 角色 | 主要职责 | 交付物 |
|---|---|---|
| 配置管理员 | 维护配置项清单与配置库，执行基线冻结与解冻，登记变更单，组织配置审计，输出状态报告 | 配置项清单、基线记录、变更登记台账、配置状态报告、审计记录 |
| 项目经理 | 批准配置管理计划，审批基线建立与重大变更，协调资源，对范围变更做决策 | 计划审批记录、基线审批记录、重大变更审批意见 |
| 开发人员 | 按命名与版本规则提交配置项，发起变更申请，提供影响分析输入，配合审计核对 | 变更申请单、影响分析说明、代码与文档提交记录 |
| 测试人员 | 维护测试资产配置项，验证变更实施结果，参与功能审计 | 测试用例版本记录、变更验证结论、审计核对结果 |
| 评审者（质量或架构角色） | 评审配置管理计划的完整性，参与基线评审，抽查审计记录 | 计划评审意见、基线评审结论、审计抽查报告 |
交付物与阶段挂钩：计划阶段产出配置管理计划文档和配置项清单初稿；基线建立阶段产出基线记录和评审结论；执行阶段持续产出变更单和状态报告；里程碑或项目收尾阶段产出审计记录和配置管理总结。计划中要为每类交付物指定模板位置和保存路径，让记录可查、可追溯。
当配置项、基线和变更记录需要在协作平台中承载时，可以把配置项清单作为受控对象管理，把基线冻结与变更审批挂到对应的工作项状态上，让变更单与需求、测试用例保持关联。ONES ALM 研发管理方案围绕需求、基线、版本和变更建立统一管理对象，支撑需求变更影响分析、过程状态追踪和交付结果回溯；其数字线程贯通需求、开发、测试、变更与发布，可用于影响分析和过程追溯。计划中的角色与审批规则仍需在工具中按项目实际配置，具体设置方式以开通模块和项目配置为准。
示例：一个迭代型项目的配置管理计划片段
以下片段为演示情景，用于说明填写方式，实际项目需按自身规模和规范调整。
配置项清单示例。清单至少包含类别、唯一标识、名称、责任人、当前版本和状态六个字段。
| 类别 | 唯一标识 | 名称 | 责任人 | 版本 | 状态 |
|---|---|---|---|---|---|
| 需求文档 | REQ-PAY-001-V1.2 | 支付模块需求规格 | 产品负责人 | V1.2 | 已基线 |
| 设计文档 | DES-PAY-003-V0.9 | 支付对账设计说明 | 架构师 | V0.9 | 评审中 |
| 源代码 | SRC-PAY-SVC-V2.1.0 | 支付服务代码库 | 开发负责人 | V2.1.0 | 开发中 |
| 测试用例 | TC-PAY-014-V1.0 | 对账异常用例集 | 测试负责人 | V1.0 | 已基线 |
| 环境配置 | ENV-UAT-002-V1.0 | UAT环境配置说明 | 运维负责人 | V1.0 | 已基线 |
基线设置与冻结时点示例。该项目设置三类基线：需求基线在需求评审通过当日冻结，冻结后需求文档版本锁定，变更须走变更单；设计基线在设计评审通过后冻结；发布基线在回归测试通过、发布清单确认后冻结。每次冻结由配置管理员登记基线记录，写明基线名称、包含的配置项及版本、冻结时间、审批人。
一次变更从申请到关闭的记录示例。变更单字段包括变更编号、关联配置项、变更原因、影响分析、申请人、审批人、实施人、验证结论、关闭时间。演示记录如下：变更编号 CR-PAY-027，关联配置项 REQ-PAY-001-V1.2，原因是支付超时阈值需要从30秒调整为20秒；影响分析列出受影响的接口文档、测试用例 TC-PAY-014 和联调计划；申请人产品负责人，审批人项目经理，实施人开发负责人；验证结论为回归测试通过，测试负责人签字；关闭时间为变更实施后第三个工作日。变更关闭后，配置管理员更新配置项清单版本并归档变更单。
完成检查：计划可执行性的核对项
计划发布前逐项核对以下清单，任何一项无法给出肯定答案，都说明该部分还需要补充。核对结果建议作为评审记录的附件留存。
| 核对项 | 通过标准 |
|---|---|
| 受控范围是否完整可核对 | 受控资产清单覆盖全部研发交付物类别，每类有受控与否的明确结论，范围外内容已列明 |
| 配置项清单是否可用 | 每个配置项有唯一标识、责任人、版本和状态字段，任取一项能按命名规则复现标识 |
| 基线规则是否明确到可操作 | 每类基线有冻结时点、审批人和包含范围，冻结后的锁定方式已说明 |
| 变更规则是否闭环 | 常规变更与紧急偏离都有路径，变更单字段完整，补审时限和跟踪人已指定 |
| 角色与权限是否落实到人 | 每个角色有姓名对应，权限矩阵覆盖读写与审批，兼岗情况已注明 |
| 记录与审计是否可验证 | 交付物有模板和保存位置，审计频次、执行人和记录格式已确定，状态报告有固定周期 |
| 阶段安排是否挂到里程碑 | 每个项目阶段开始和结束时的配置管理动作已列出，与项目计划时间一致 |
| 计划本身是否经过评审 | 评审意见已闭环，计划版本号、生效日期和修订记录完整 |
核对通过后，计划进入执行。执行期间建议在每个里程碑回看一次清单，重点检查变更单是否全部关闭、基线记录是否与实际版本一致、审计发现的问题是否已整改。配置管理计划本身也需要版本管理：范围、角色或流程发生实质变化时，按变更流程修订并重新评审，保留旧版本备查。
常见问题
小团队人手有限，配置管理员可以由开发或测试兼任吗？
可以兼任，但要在计划中写清职责边界，避免审批人与执行人混同。常见做法是配置管理员由开发或测试骨干兼任，负责维护配置项清单、登记变更单和组织审计；基线审批和重大变更决策仍由项目经理承担。兼岗情况在角色表中注明，审计时重点核对变更单的申请人与审批人是否为同一人。
迭代型项目和瀑布型项目的配置管理计划主要差别在哪里？
差别主要在基线设置和审计节奏。迭代型项目通常按迭代设置轻量基线，每个迭代结束做一次物理审计，检查配置项与清单是否一致；瀑布型项目按阶段设置需求、设计、发布等基线，在里程碑节点做功能审计。变更流程的完整路径两者一致，迭代型项目需要额外说明迭代内紧急偏离的记录与补审时限。
配置管理计划制定后，什么情况下需要修订并重新评审？
受控范围、基线类型、变更审批层级、角色分工或配置库结构发生实质变化时，应按变更流程修订计划并重新评审，保留旧版本备查。日常执行中的小调整，例如新增一个配置项类别下的具体条目，可以在配置项清单中更新并记录，不必触发计划整体修订。判断标准是变化是否影响他人按计划执行。
配置项清单和变更单在协作平台中怎么承载比较合理？
常见方式是把配置项清单作为受控对象管理，把基线冻结与变更审批挂到对应工作项的状态上，让变更单与需求、测试用例保持关联，便于影响分析和过程追溯。ONES ALM 研发管理方案围绕需求、基线、版本和变更建立统一管理对象，支撑需求变更影响分析、过程状态追踪和交付结果回溯。具体字段和审批规则需按项目实际在工具中配置，以开通模块和项目配置为准。
计划核对清单全部通过，是否就说明配置管理已经做到位？
核对清单通过只说明计划本身具备可执行性，执行效果还要看运行数据。建议在每个里程碑回看变更单是否全部关闭、基线记录与实际版本是否一致、审计发现的问题是否整改。连续几个周期出现变更单积压或基线漂移，说明计划中的规则或角色安排需要调整，而不只是执行不到位。
