配置管理计划要回答的是：哪些研发资产需要受控、由谁在什么时点以什么方式管理、基线何时建立以及变更如何闭环。本文按“定内容—识配置项—建库与基线—管变更与审计—分角色—做示例—查落地”的顺序，给出一份可直接填写和核对的编写指南。范围限定在研发资产的受控组合，需求版本本身归需求变更与版本管理，交付制品归研发交付物与制品管理。
要点总览（TL;DR）
- 配置管理计划先回答七个问题：受控范围、配置库、版本与基线、变更控制、配置审计、角色职责和记录表单，用最小内容清单搭骨架。
- 配置项按“会变更、需共享、需追溯”三条标准筛选，清单至少包含编号、名称、类型、责任人、存放位置、关联基线、版本和状态。
- 配置库分开发库、受控库、产品库三级，基线按功能基线、分配基线、产品基线选择建立时点，建立前逐项检查并归档基线记录。
- 变更走申请、评审、实施、验证四步，配置审计分功能与物理两类，审计问题登记整改并明确关闭期限。
- 落地验证看执行证据：清单是否更新、基线记录是否写到版本、变更单是否闭环、审计报告是否含问题项，计划随基线发布和季度节奏复审。
配置管理计划先定哪几件事
配置管理计划是一份可执行文档，作用是把研发过程中不断变化的资产纳入受控状态，让团队在任意时点都能说清“当前版本是什么、谁批准的、改了什么、依据哪份记录”。它不替代需求管理，也不替代制品发布，只处理研发资产的受控组合：哪些文档、代码、模型、脚本和配套记录需要被纳入统一管理。
一份能执行的计划，至少要回答七个问题。可以先用下面的最小内容清单搭骨架，再逐项补充字段和流程。
| 内容块 | 要回答的问题 | 最小产出 |
|---|---|---|
| 范围 | 哪些资产受控，哪些不受控，边界在哪里 | 配置项清单 |
| 配置库 | 资产放在哪一级库，进出库条件是什么 | 库结构说明 |
| 版本与基线 | 版本号怎么编，基线何时建立、何时发布 | 版本规则与基线记录 |
| 变更控制 | 谁可以提变更，谁审批，改完如何验证 | 变更申请单与审批路径 |
| 配置审计 | 多久查一次，查什么，问题怎么处置 | 审计检查表与审计报告 |
| 角色职责 | 谁负责执行、谁负责决策、谁负责记录 | 角色—职责—交付物对照表 |
| 记录表单 | 用什么表单留痕，记录保存在哪里 | 表单模板与归档位置 |
边界要在计划开头写清楚。需求条目的版本演进、需求变更的影响分析属于需求变更与版本管理的范畴；安装包、镜像、发布包的打包与制品库管理属于研发交付物与制品管理。配置管理计划关注的是这些资产在研发过程中的受控状态与基线组合，三者通过配置项编号和基线记录衔接，避免同一份资产在两套清单里各说各话。
配置项识别与命名：把受控范围落到清单
识别配置项的标准可以归纳为三条：会随项目推进发生变更、需要多方共享使用、出问题后需要追溯来源。满足其中两条以上的研发资产，通常就应纳入配置项清单。典型对象包括需求规格、设计文档、接口定义、源代码模块、构建脚本、测试用例、部署配置和项目级计划文档。
识别动作按以下顺序执行：先由项目经理和配置管理员圈定候选资产，再逐项判断是否满足选取标准，然后为入选资产分配编号和属性，最后由各资产责任人确认清单。完成标志是清单经过一次评审，且每个配置项都有明确责任人和存放位置。
| 字段 | 填写要求 | 示例 |
|---|---|---|
| 配置项编号 | 全局唯一，含类型前缀 | DOC-SRS-001 |
| 名称 | 与文档或模块标题一致 | 订单模块需求规格 |
| 类型 | 文档、代码、模型、脚本、配置 | 文档 |
| 责任人 | 对该项内容负责的角色 | 需求负责人 |
| 存放位置 | 库名加目录路径 | 受控库/需求/订单 |
| 关联基线 | 已纳入或计划纳入的基线编号 | BL-FUNC-01 |
| 当前版本 | 按版本规则填写 | V1.2 |
| 状态 | 草稿、受控、冻结、废止 | 受控 |
命名规则建议采用“类型前缀—业务域—序号”的结构，版本号采用“主版本.次版本”两段式：内容发生影响下游的调整时升主版本，文字修订或补充说明时升次版本。规则一旦确定就写入计划，新增配置项按规则分配编号，避免出现同一资产多个叫法。
配置项清单需要承载状态和责任人，放在工作项或文档系统中比散落在表格里更容易维持。ONES 当前方案覆盖需求、基线、版本、变更、测试与发布，围绕需求、基线、版本和变更建立统一管理对象，配置项清单可以与这些对象关联，减少清单与实际情况脱节。
配置库与基线：分级存放与建立时点
配置库按受控程度分为三级，每级有明确的准入和准出条件。开发库供个人和小团队日常修改，允许频繁变动；受控库存放通过评审、进入受控状态的配置项，修改需要走变更流程；产品库存放已发布或已交付的基线组合，只读保存，作为回溯依据。
| 库级别 | 用途 | 准入条件 | 准出条件 |
|---|---|---|---|
| 开发库 | 日常编写与调试 | 配置项已登记编号 | 通过评审并提交变更申请 |
| 受控库 | 受控版本存放与共享 | 评审通过、变更单批准 | 纳入基线并完成发布检查 |
| 产品库 | 基线归档与交付回溯 | 基线评审通过 | 仅按变更流程解冻 |
基线类型按项目阶段选择。功能基线通常在需求规格评审通过后建立，锁定系统对外功能范围；分配基线在设计与接口确定后建立，把功能分配到各模块和团队；产品基线在测试通过、准备交付时建立，锁定完整的受控组合。项目规模较小时可以合并功能基线与分配基线，但建立时点和检查项仍需保留。
基线建立前的检查项包括：纳入范围的配置项是否齐全、版本号是否连续可追溯、关联的评审记录是否归档、责任人是否确认、变更单是否全部关闭。检查通过后生成基线记录，写明基线编号、建立日期、包含的配置项及版本、审批人和发布范围。完成标志是基线记录归档，且团队成员能从记录中定位到每个配置项的对应版本。
变更控制与配置审计：让受控状态可验证
变更控制的目标是让每一次受控修改都有申请、有评审、有实施、有验证。流程按四步走：提出变更申请，评审影响范围，实施并更新版本，验证后决定是否重发布基线。
| 步骤 | 输入 | 动作 | 输出 |
|---|---|---|---|
| 申请 | 变更需求说明 | 填写变更单，注明涉及配置项与影响范围 | 变更申请单 |
| 评审 | 变更申请单 | 评审组评估技术影响、进度影响与关联基线 | 评审结论与审批意见 |
| 实施 | 批准的变更单 | 修改配置项，更新版本号，同步关联文档 | 新版本配置项 |
| 验证 | 新版本与变更单 | 测试或复核，确认变更生效且无遗漏 | 验证记录与关闭的变更单 |
变更单至少包含：变更编号、申请人、申请日期、涉及配置项及当前版本、变更内容、影响分析、审批人、实施人、验证结论、关闭日期。变更实施后，若涉及已发布基线，需要按规则重发布基线：影响对外功能的变更升主版本并建立新基线，内部修订升次版本并在基线记录中追加说明。
配置审计分两类。功能配置审计检查配置项是否实现了基线规定的功能，通常结合测试记录和评审结论核对；物理配置审计检查配置项的实际存在与记录是否一致，包括版本号、存放位置、清单完整性。审计频次可以按基线建立时、迭代结束时或每月固定一次执行，检查结果写入审计报告，发现的问题登记为整改项，明确责任人和关闭期限。
变更单、审计记录与配置项状态需要在同一套对象中流转，才能支撑追溯。ONES 以数字线程贯通需求、开发、测试、变更与发布，支撑影响分析、过程追溯和合规审计；在配置审计环节，审计结论可以关联到对应配置项和基线记录，便于后续复核。
角色分工与交付物：谁在什么时点交什么
配置管理涉及四类角色。配置管理员负责维护清单、库结构和基线记录，执行审计并汇总状态报告；项目经理负责批准配置管理计划、裁定范围争议、确认基线发布；开发与测试人员负责按规则提交配置项、发起变更并配合审计；变更评审组负责评估变更影响并给出审批结论。角色可以合并，但决策权限和记录责任要分开写清。
| 角色 | 主要职责 | 决策权限 | 关键交付物 |
|---|---|---|---|
| 配置管理员 | 维护清单与库结构，组织审计 | 配置项编号分配、库准入检查 | 配置项清单、基线记录、审计报告 |
| 项目经理 | 批准计划，协调资源 | 基线发布、范围变更裁定 | 批准的配置管理计划、基线发布记录 |
| 开发与测试 | 提交配置项，执行变更 | 无审批权，可发起变更 | 变更申请单、验证记录 |
| 变更评审组 | 评估变更影响 | 变更批准或驳回 | 评审结论 |
评审与交接时点固定在三个位置：配置项进入受控库前评审一次，基线建立前评审一次，迭代结束时审计一次。小团队可以把配置管理员与项目经理合并，把评审组缩减为技术负责人加测试负责人，但变更单的审批记录和审计报告仍需保留，否则受控状态无法验证。
状态报告按迭代或按月输出，内容包括新增配置项数量、变更单数量与关闭率、基线发布情况、审计问题及整改状态。ONES 效能管理支持对系统中产生的数据进行多维度分析，帮助团队进行效能的持续改进，状态报告中的变更关闭率、审计问题趋势可以基于系统数据整理。
示例：一个迭代项目的配置管理计划片段
以下为演示情景：一个六人团队开发订单管理模块，迭代周期两周，受控范围包括需求规格、接口文档、源代码模块、测试用例和部署配置。示例中的编号和日期为示意，实际使用时按团队规则替换。
配置项清单填写示例：
| 编号 | 名称 | 类型 | 责任人 | 存放位置 | 关联基线 | 版本 |
|---|---|---|---|---|---|---|
| DOC-SRS-001 | 订单模块需求规格 | 文档 | 需求负责人 | 受控库/需求/订单 | BL-FUNC-01 | V1.1 |
| DOC-API-003 | 订单接口定义 | 文档 | 架构负责人 | 受控库/设计/接口 | BL-ALLOC-01 | V1.0 |
| CODE-ORD-012 | 订单创建服务 | 代码 | 开发负责人 | 受控库/代码/order | BL-ALLOC-01 | V2.3 |
| TEST-ORD-007 | 订单创建用例集 | 测试 | 测试负责人 | 受控库/测试/order | BL-PROD-01 | V1.0 |
基线建立记录示例：基线编号 BL-ALLOC-01，类型为分配基线，建立日期为迭代第二周周三，包含 DOC-API-003 V1.0、CODE-ORD-012 V2.3 及关联设计文档，审批人为项目经理，发布范围为订单模块开发组。检查项全部通过后归档，并在记录中注明“后续修改需走变更流程”。
变更单示例：变更编号 CR-014，申请人为开发负责人，涉及 CODE-ORD-012 当前版本 V2.3，变更内容为订单创建接口增加幂等校验，影响分析为接口文档需同步修订、测试用例需补充两条，审批人为变更评审组，实施后版本升为 V2.4，验证结论为测试通过，变更单于次日关闭，并触发 BL-ALLOC-01 的基线重发布记录。
从示例中可以提炼三条填写规律：编号带类型前缀便于检索；基线记录必须写明包含的版本而非只写名称；变更单的影响分析要落到具体关联配置项，避免只写“影响较小”。
计划落地后的完成检查
判断配置管理计划是否真正执行，看内容完整性和执行证据两方面。内容完整性检查计划是否覆盖范围、库、版本与基线、变更、审计、角色和记录七块；执行证据检查这些内容是否留下了可核对的记录。
| 检查项 | 核验方式 | 通过标准 |
|---|---|---|
| 配置项清单完整 | 抽查三个配置项 | 编号、责任人、位置、版本齐全 |
| 基线记录可追溯 | 任选一条基线 | 能定位到每个配置项的具体版本 |
| 变更单闭环 | 抽查近一个月变更 | 均有审批、实施、验证和关闭记录 |
| 审计记录留存 | 查看最近一次审计报告 | 有问题清单和整改关闭情况 |
| 角色责任明确 | 对照角色表 | 每个交付物都有指定责任人 |
常见失效信号包括：配置项清单长期不更新、基线记录只写名称不写版本、变更单集中在迭代末补填、审计报告只有结论没有问题项。出现这些信号时，先缩小受控范围，把清单和变更流程跑通一个迭代，再逐步扩大，而不是一次性铺开全部资产。
计划复审周期建议与项目阶段绑定：每个基线发布后复核一次范围与基线策略，每个季度复核一次角色分工和审计频次。复审结论写入计划修订记录，确保配置管理计划随项目推进保持可用。
常见问题
配置管理计划和需求变更管理、制品发布管理的边界怎么划？
配置管理计划处理研发资产的受控组合，回答哪些文档、代码、模型、脚本和配套记录需要纳入统一管理，以及它们在什么状态下被谁修改。需求条目的版本演进和需求变更影响分析归需求变更与版本管理；安装包、镜像、发布包的打包与制品库管理归研发交付物与制品管理。
三者通过配置项编号和基线记录衔接：需求版本变化会触发相关配置项的变更单，制品发布则引用某条产品基线。计划开头写清这条边界，可以避免同一份资产在两套清单里重复登记、各说各话。
小团队人手有限，配置管理角色可以合并到什么程度？
角色可以合并，决策权限和记录责任要分开写清。常见做法是配置管理员与项目经理由一人承担，变更评审组缩减为技术负责人加测试负责人。
可以合并的是执行动作，需要保留的是审批记录和审计报告：变更单上仍要有明确的审批人签字或审批结论，审计报告仍要记录问题清单和整改关闭情况。如果连这两类记录也省掉，受控状态就无法验证，基线记录也就失去了回溯价值。
基线建立后，什么情况下需要重发布基线？
变更实施后是否重发布基线，取决于变更对已发布基线的影响程度。影响对外功能或接口约定的变更，通常升主版本并建立新基线；内部文字修订、补充说明类变更升次版本，在基线记录中追加说明即可。
判断依据是变更单里的影响分析，要落到具体关联配置项，而不是笼统写“影响较小”。重发布时同步更新基线记录中的配置项版本清单，并保留旧基线记录，供后续回溯和审计核对。
配置审计多久做一次比较合适，审计发现问题怎么处置？
审计频次可以绑定关键节点：基线建立时做一次、迭代结束时做一次，项目周期较长时再增加每月固定一次。功能配置审计结合测试记录和评审结论核对配置项是否实现基线规定的功能；物理配置审计核对版本号、存放位置和清单完整性是否与实际一致。
审计发现的问题登记为整改项，写明责任人和关闭期限，下一次审计时复核关闭情况。审计报告只写结论不列问题项，通常说明审计流于形式，需要调整检查内容或核验方式。
配置项清单长期不更新，计划还能算落地吗？
清单长期不更新是典型的失效信号，说明配置管理计划停留在文档层面。其他信号还包括基线记录只写名称不写版本、变更单集中在迭代末补填、审计报告没有问题项。
修正时先缩小受控范围，选一个迭代把清单、变更单和基线记录跑通，再逐步扩大资产范围。计划复审建议与项目阶段绑定：每次基线发布后复核范围与基线策略，每季度复核角色分工和审计频次，复审结论写入计划修订记录。
