配置管理计划要能直接送评审，关键在章节顺序和表格字段：把评审信息、范围与受控对象放在前两章，让评审人先判断“这份计划管什么、谁来管”；再把标识规则、基线、变更、状态与审计逐项落到可填写的表格里，每张表设必填列和判定口径。下文给出一套可复制的目录骨架、六张空白表格、字段说明、必填最低线、填写示例与维护方法，覆盖研发资产受控组合；需求版本的具体变更流程、交付制品的发布归档不在本篇展开。
要点总览（TL;DR）
- 可直接评审的配置管理计划按九章组织：评审信息、范围与受控对象、角色职责、标识与版本规则、基线与变更控制、配置状态与审计、工具与数据、计划与风险、附录表格。
- 评审首屏放第1、2章，让评审人先确认文档身份与受控对象覆盖范围；第3至6章承载规则主体，每张表设必填列和判定口径。
- 评审通过的最低线是评审信息表、受控对象清单表、角色职责表、基线与变更控制表四张表的关键字段填齐且可互相引用；其余字段可按项目裁剪并留记录。
- 评审按“先范围、后规则、再计划”三轮进行，结论取通过、有条件通过、不通过三种，有条件通过须写明补齐项与复核日期。
- 计划生效后，受控对象类型增减、基线规则调整、审批角色变更或工具迁移时触发版本更新，更新走与首次评审相同的结论记录方式。
可直接评审的配置管理计划目录结构
评审人拿到一份配置管理计划，通常先问三个问题：这份计划覆盖哪些受控对象、谁对它们负责、规则是否可执行。目录按这三个问题排序，评审首屏就能看到答案，后面的章节再补细节。建议采用两级结构，一级章节固定为九章，二级按项目裁剪。
| 章节 | 一句话职责 | 回答的评审问题 |
|---|---|---|
| 1 评审信息 | 记录文档编号、版本、评审人、评审结论 | 这份计划是谁写的、谁审的、结论是什么 |
| 2 范围与受控对象 | 界定项目范围并列出全部受控对象 | 管什么、不管什么、对象清单是否完整 |
| 3 角色职责 | 定义配置管理员、变更审批人、审计人等角色 | 每项配置活动由谁执行、谁批准 |
| 4 标识与版本规则 | 规定对象命名、版本号规则与存放位置 | 对象如何唯一标识、版本如何递增 |
| 5 基线与变更控制 | 定义基线类型、建立时点、冻结范围与变更流程 | 基线何时建立、变更如何申请与审批 |
| 6 配置状态与审计 | 规定状态值集合、状态记录方式与审计频次 | 如何知道当前配置状态、如何验证一致性 |
| 7 工具与数据 | 说明承载工具、库结构、备份与权限 | 配置数据存在哪里、如何保障可用 |
| 8 计划与风险 | 列出配置管理里程碑、依赖与风险应对 | 何时完成何事、有哪些风险 |
| 9 附录表格 | 汇总空白表与填写说明 | 表格是否齐全、口径是否一致 |
第1、2章必须前置到评审首屏。第1章让评审人确认文档身份与结论记录位置，第2章让评审人直接核对受控对象是否覆盖项目实际产出。第3至6章是规则主体，评审重点在“规则是否可执行、是否有判定口径”。第7、8章按项目规模可简可详，第9章只做索引，不重复正文。
边界上，本计划只规定“哪些研发资产纳入受控、如何标识、何时形成基线、变更如何审批”。需求条目本身的版本演进流程归需求变更与版本管理；构建产物、安装包的发布与归档归研发交付物与制品管理。计划中可以用一句话声明接口关系，例如“需求版本变更经本计划第5章变更控制流程审批后，由需求管理流程执行”，避免两份文档互相覆盖。
可复制空白模板：正文骨架与关键表格
以下骨架可直接复制到文档工具中填写。方括号内为待填内容，表格保留表头即可使用。
文档头与评审信息表
配置管理计划 文档编号：[项目代号]-CMP-[序号] 文档版本：[Vx.y] 编制人／日期：[姓名]／[日期] 适用范围：[项目或产品名称、阶段]
| 评审轮次 | 评审日期 | 评审角色 | 评审人 | 评审结论 | 遗留问题编号 |
|---|---|---|---|---|---|
| 通过／有条件通过／不通过 |
受控对象清单表
| 序号 | 对象名称 | 对象类型 | 责任人 | 存放位置 | 当前状态 | 备注 |
|---|---|---|---|---|---|---|
角色职责表
| 角色 | 承担人 | 配置管理职责 | 审批权限 | 备份角色 |
|---|---|---|---|---|
基线与变更控制表
| 基线名称 | 基线类型 | 建立时点 | 冻结范围 | 变更申请编号 | 影响对象 | 审批角色 | 结论 |
|---|---|---|---|---|---|---|---|
配置状态与审计记录表
| 审计日期 | 审计范围 | 审计人 | 发现差异 | 处理措施 | 审计结论 |
|---|---|---|---|---|---|
计划与风险表
| 里程碑 | 计划完成时间 | 依赖条件 | 风险描述 | 风险等级 | 应对措施 | 责任人 |
|---|---|---|---|---|---|---|
字段说明：每个字段填什么、怎么判定
字段说明与模板表头一一对应，填写时以“评审人能否据此判断”为标准。下表按字段组给出含义、填写口径与常见错误。
| 字段 | 含义 | 填写口径 | 常见错误 |
|---|---|---|---|
| 对象名称 | 受控对象的唯一称呼 | 与项目实际文档或制品名称一致，可加项目前缀 | 同一对象在不同表中名称不一致 |
| 对象类型 | 对象所属类别 | 从计划约定的类型集合中选取，如需求文档、设计文档、源码、测试用例、构建脚本 | 临时新增类型未在计划中声明 |
| 责任人 | 对该对象内容负责的人 | 填具体姓名，不填部门 | 填团队名称导致无人可追 |
| 存放位置 | 对象受控存储的位置 | 填库路径或文档空间名称，精确到目录 | 只写“服务器”无法定位 |
| 当前状态 | 对象在配置管理中的状态 | 从状态值集合中选取，如草稿、评审中、已基线、变更中、已归档 | 自造状态词导致统计口径不一 |
| 版本号规则 | 版本递增的约定 | 写明主版本与次版本的递增条件，例如基线变更升主版本、编辑修订升次版本 | 只写“按需递增”无法判定 |
| 基线名称 | 基线的唯一标识 | 采用“项目-阶段-基线类型-序号”格式 | 同名基线重复出现 |
| 建立时点 | 基线形成的触发条件 | 写事件或日期，例如“需求评审通过后”“里程碑M2当日” | 写“适时建立”无法审计 |
| 冻结范围 | 基线内不可随意改动的对象集合 | 列出对象类型或清单编号区间 | 范围写成“全部文档”过宽 |
| 变更申请编号 | 变更请求的唯一编号 | 与变更管理流程编号一致 | 编号与流程系统对不上 |
| 影响对象 | 变更波及的受控对象 | 逐项列出对象名称，不写“相关文档” | 漏列下游测试用例 |
| 审批角色 | 对变更作出结论的角色 | 填角色名，与角色职责表一致 | 填个人姓名导致角色缺位时无人审批 |
| 结论 | 变更审批结果 | 批准、拒绝、退回补充三选一 | 写“同意再看看”无法归档 |
| 状态值集合 | 对象状态的全部合法取值 | 在计划中一次性列全，后续新增需走计划变更 | 各表状态词不统一 |
| 审计频次 | 配置审计的执行周期 | 写周期或触发点，如“每基线建立后”“每月一次” | 写“定期”无法考核 |
| 审计结论 | 审计的一致性判断 | 一致、存在差异待处理、不一致三选一，并关联差异处理记录 | 只写“已检查” |
| 里程碑 | 配置管理活动的关键节点 | 与项目计划节点对齐，写可验收的完成标志 | 写“完成配置管理”无验收标准 |
| 依赖条件 | 里程碑达成的前置条件 | 写具体输入，如“测试报告签署”“变更单全部关闭” | 写“视情况” |
| 风险等级 | 风险的影响程度 | 高、中、低三档，并在计划中写明分档标准 | 全部标为“中”失去区分度 |
| 应对措施 | 降低风险的具体动作 | 写动作、责任人与时间 | 写“加强管理” |
必填与选填：评审通过的最低字段集
评审通过的最低线是：评审信息表、受控对象清单表、角色职责表、基线与变更控制表四张表的关键字段全部填齐，且字段之间可互相引用。其余字段可按项目规模裁剪，但裁剪要在计划中留记录。
| 表格 | 必填字段 | 可选填字段 |
|---|---|---|
| 评审信息表 | 文档编号、文档版本、评审角色、评审结论 | 遗留问题编号、评审日期 |
| 受控对象清单表 | 对象名称、对象类型、责任人、存放位置、当前状态 | 备注 |
| 角色职责表 | 角色、承担人、配置管理职责、审批权限 | 备份角色 |
| 基线与变更控制表 | 基线名称、建立时点、冻结范围、审批角色、结论 | 变更申请编号、影响对象（小规模项目可合并到变更单） |
| 状态与审计记录表 | 状态值集合、审计频次、审计结论 | 审计范围、发现差异明细 |
| 计划与风险表 | 里程碑、计划完成时间、风险等级 | 依赖条件、应对措施、责任人 |
裁剪时需在计划第1章或附录写明“本项目不设独立配置审计角色，由质量角色兼任”，并说明替代安排。必填字段缺失时，评审结论不应给“通过”：缺受控对象清单或责任人，给“不通过”；缺变更审批角色或基线建立时点，可给“有条件通过”，限期补齐后复核。评审人按表逐项打勾，结论自然落到三种取值之一。
填写示例：一份填好的配置管理计划片段
以下为演示情景，项目为某研发团队的版本发布项目，用于说明写法，不代表真实项目数据。
受控对象清单片段
| 序号 | 对象名称 | 对象类型 | 责任人 | 存放位置 | 当前状态 |
|---|---|---|---|---|---|
| 1 | PRJ-需求规格说明书 | 需求文档 | 张明 | 文档库/PRJ/需求 | 已基线 |
| 2 | PRJ-接口设计说明 | 设计文档 | 李华 | 文档库/PRJ/设计 | 评审中 |
| 3 | PRJ-测试用例集 | 测试用例 | 王芳 | 测试库/PRJ/用例 | 草稿 |
三行分别对应字段说明中的对象名称、类型、责任人、存放位置、当前状态。状态值取自计划约定的集合，存放位置精确到目录，评审人可据此抽查对象是否真实存在。
基线与变更控制片段
| 基线名称 | 基线类型 | 建立时点 | 冻结范围 | 变更申请编号 | 影响对象 | 审批角色 | 结论 |
|---|---|---|---|---|---|---|---|
| PRJ-需求-功能基线-01 | 功能基线 | 需求评审通过后 | 需求文档第1至5章 | CR-021 | 需求规格说明书、测试用例集 | 变更控制委员会 | 批准 |
该行演示了“建立时点写触发事件、冻结范围写章节、影响对象逐项列出”的写法。变更申请编号与变更流程一致，审批角色与角色职责表对应，结论取三选一值。
状态与审计记录片段
| 审计日期 | 审计范围 | 审计人 | 发现差异 | 处理措施 | 审计结论 |
|---|---|---|---|---|---|
| 2025-03-10 | 功能基线-01全部对象 | 赵强 | 测试用例集版本落后于需求文档 | 更新用例并重新提交评审，3月14日前完成 | 存在差异待处理 |
审计结论使用约定取值，差异描述指向具体对象，处理措施带责任动作与时间，便于下次审计复核闭环。
评审组织与调整维护方法
评审按“先范围、后规则、再计划”的顺序进行，每轮控制在一次会议内完成，结论当场记录。
- 编制人提前两个工作日发出计划与空白表，标注本轮重点章节。
- 第一轮核对第1、2章：文档身份是否完整、受控对象是否覆盖项目产出。
- 第二轮核对第3至6章：角色是否落实到人、版本规则是否可判定、基线与变更流程是否闭环、状态与审计口径是否统一。
- 第三轮核对第7、8章与附录：工具承载、里程碑与风险是否可执行。
- 评审人按表逐项给出“通过／有条件通过／不通过”，有条件通过须写明补齐项与复核日期。
计划生效后，出现以下情况触发版本更新：受控对象类型增减、基线类型或建立时点调整、审批角色变更、工具或库结构迁移。更新走与首次评审相同的结论记录方式，文档版本按第4章规则递增，旧版本保留可查。
定期复核建议与基线节奏对齐，每次基线建立后复核一次受控对象清单与状态值集合；每季度检查一次角色承担人是否仍在岗。模板裁剪维护上，把本项目实际使用的表头和状态词固化为组织模板，新增字段先在单个项目试用，再纳入模板版本。
当计划需要多人协同填写、评审意见需要留痕、结论需要与工作项关联时，可以用 ONES 承载这套流程：ONES Wiki 的页面模板库可一键创建制式化文档模板，页面版本记录支持随时查看与回滚，权限可按角色配置读写范围；ONES ALM 方案围绕需求、基线、版本和变更建立统一管理对象，支撑变更影响分析与过程状态追踪，并可将评审节点、交付物模板沉淀为可复用资产。这样，配置管理计划的评审结论、遗留问题与后续变更能在同一套记录中衔接，减少文档与流程脱节。具体功能范围以实际部署与套餐为准。
常见问题
配置管理计划评审时，如果受控对象清单还没完全确定，可以先给“有条件通过”吗？
可以，但需要区分缺失程度。受控对象清单完全缺失或责任人未落实时，评审结论应为“不通过”；清单主体已列出、仅个别对象类型待补充时，可给“有条件通过”，并在评审信息表中写明补齐项、责任人和复核日期。复核时只核对补齐项，不重复全量评审。
小规模项目裁剪配置管理计划模板时，哪些表可以合并或省略？
小规模项目可合并变更申请编号与影响对象到变更单中，状态与审计记录表可只保留状态值集合、审计频次和审计结论三列。评审信息表、受控对象清单表、角色职责表、基线与变更控制表的关键字段仍需保留。裁剪决定要在计划第1章或附录中写明替代安排，例如“本项目不设独立配置审计角色，由质量角色兼任”。
配置管理计划生效后，哪些情况必须触发版本更新并重新评审？
受控对象类型增减、基线类型或建立时点调整、审批角色变更、工具或库结构迁移，这四类情况应触发版本更新。更新后的计划走与首次评审相同的结论记录方式，文档版本按计划中约定的版本号规则递增，旧版本保留可查。日常对象状态变化不需要重新评审计划，按状态记录表更新即可。
配置管理计划中的状态值集合和审计频次，评审人重点看什么？
评审人重点看两点：状态值是否一次性列全且各表用词统一，审计频次是否写成可考核的周期或触发点。状态值集合应覆盖草稿、评审中、已基线、变更中、已归档等全部合法取值，后续新增需走计划变更；审计频次写“每基线建立后”或“每月一次”，避免只写“定期”。
用文档工具承载配置管理计划时，评审意见和结论如何与计划版本对应？
评审意见和结论应记录在评审信息表中，与文档版本号绑定。每次评审产生一轮记录，包含评审轮次、评审日期、评审角色、评审人、评审结论和遗留问题编号。计划版本更新后，旧版本的评审记录保留可查，新版本重新记录评审结论。这样评审结论与计划版本一一对应，后续追溯时能定位到具体版本的评审意见。
