配置项识别要解决的是：研发过程中哪些资产需要受控、由谁负责、用什么标识和版本管理、归入哪条基线。本文给出一套可直接执行的判定问题、四步操作流程、角色分工、示例清单和完成检查项，帮助团队把散落在需求、设计、代码、测试和环境中的资产整理成可评审、可维护的配置项清单。
要点总览（TL;DR）
- 配置项识别先用四个判定问题筛选资产：是否被多方引用、变更是否影响交付或验证、是否需要回溯历史版本、是否需经评审后发布；任一为“是”即具备纳入理由。
- 判定结果分三档：纳入配置项、暂不纳入但登记观察、明确排除，排除项也要留下理由，减少后续重复讨论。
- 操作按四步推进：盘点候选资产、逐项判定并记录理由、补齐标识与负责人等字段、评审后登记入库并明确变更入口。
- 配置管理员组织盘点与评审，项目经理确认范围与排除项，开发与测试负责人盘点各自资产，评审组给出通过或退回结论。
- 识别完成后用范围覆盖、理由齐全、字段完整、标识唯一、评审通过、已登记入库六项检查确认，并在新增资产或基线节点变化时重新识别。
配置项识别先回答哪几个判定问题
对单个资产做判定时，不需要先讨论工具和流程，先回答四个问题即可。四个问题中任意一个回答“是”，该资产就具备纳入配置管理的基本理由；全部回答“否”时，再结合项目约束决定登记观察还是排除。
| 判定问题 | 回答“是”的含义 | 回答“否”的处理 |
|---|---|---|
| 是否被多方引用？ | 多个角色或下游活动依赖该资产，改动会波及他人 | 记录引用方，确认是否仅为个人临时使用 |
| 变更是否影响交付或验证？ | 改动会改变交付内容、验收结论或测试结果 | 评估影响是否局限在个人工作范围 |
| 是否需要回溯历史版本？ | 需要知道某个时间点的内容，或需要对比前后差异 | 确认是否可用一次性记录替代 |
| 是否需经评审后发布？ | 资产在发布或交付前要经过评审、批准或冻结 | 确认是否存在其他受控环节覆盖 |
判定结果分三档处理，避免“要么全管、要么不管”的粗放做法：
- 纳入配置项：至少一个判定问题为“是”，且资产在项目周期内会持续演进。入选项需要补齐标识、负责人、存放位置、版本规则和基线归属。
- 暂不纳入但登记观察：当前判定问题均为“否”，但资产可能随项目推进变得重要，例如早期草稿、临时验证脚本。登记名称、持有人和观察理由，设定复核时点。
- 明确排除：确认属于个人临时文件、可再生成的中间产物或与交付无关的辅助材料。排除也要留下理由，便于后续复核时不必重复讨论。
需要区分相邻管理范围的边界。需求条目的版本号规则、变更审批流程属于需求变更与版本管理；交付包的打包、发布和制品库存储属于研发交付物与制品管理。配置项识别关注的是“哪些资产进入受控集合”，以及每个配置项的标识、负责人和基线归属，不展开上述两类流程的具体规则。
从资产盘点走到配置项清单的操作步骤
识别工作按四步推进，每一步都有明确输入、动作、输出和完成标志，避免盘点完却没有结论，或清单建了却无人维护。
| 步骤 | 输入 | 动作 | 输出 | 完成标志 |
|---|---|---|---|---|
| 第一步：盘点候选资产 | 项目计划、研发阶段划分、现有文档目录与代码仓库结构 | 按阶段列出候选资产，标注所属阶段、当前持有人和存放位置 | 候选资产盘点表 | 各阶段均有候选条目，参与角色确认盘点范围无遗漏 |
| 第二步：逐项判定 | 候选资产盘点表、判定问题表 | 对每个候选资产回答四个判定问题，记录判定理由和三档结论 | 判定记录 | 每个候选资产都有结论和理由，无空白项 |
| 第三步：补齐配置项字段 | 判定记录中的入选项 | 为每个入选项填写标识、负责人、存放位置、版本规则、基线归属 | 配置项清单初稿 | 入选项字段完整，标识在项目内唯一 |
| 第四步：评审入库 | 配置项清单初稿、判定记录 | 组织评审确认清单，通过后登记到配置库，明确变更入口 | 评审结论、配置库登记记录 | 评审通过并有结论记录，清单已登记，变更入口已通知相关角色 |
配置项清单建议包含以下字段，字段设计以“能定位、能追责、能回溯”为目标：
- 配置项标识：项目内唯一编号或命名规则，避免同名冲突。
- 配置项名称与类型：需求文档、设计文档、源代码、构建脚本、测试用例、环境参数等。
- 负责人：对该配置项内容和变更负责的角色。
- 存放位置：文档库路径、代码仓库地址或工具中的登记位置。
- 版本规则：版本号如何递增、何时冻结，与需求版本管理的规则保持衔接但不重复定义。
- 基线归属：属于哪条基线，例如迭代基线、发布基线。
- 判定理由：简要记录为何纳入，便于后续复核。
- 状态：已入库、观察中、已排除。
在工具承载层面，配置项清单的登记、版本记录和基线归属需要在研发管理平台中保持关联。ONES 围绕需求、基线、版本和变更建立统一管理对象，可支撑配置项与需求、测试、发布之间的追溯关系；清单本身仍应按上述字段设计，工具承担的是登记、关联和状态追踪。
角色分工与各环节交付物
识别工作涉及多个角色，职责不清时最容易出现“盘点有人做、判定无人认、清单无人维护”的情况。下表按环节明确职责和交付物归属。
| 角色 | 主要职责 | 交付物 |
|---|---|---|
| 配置管理员 | 制定判定问题表和清单字段模板，组织盘点与评审，维护配置库登记记录，触发定期复核 | 判定问题表、清单模板、配置库登记记录、复核记录 |
| 项目经理 | 确认盘点范围和阶段划分，协调各角色参与，对排除项做最终确认 | 盘点范围确认、排除项确认意见 |
| 开发负责人 | 盘点代码、构建脚本、接口设计等技术资产，填写技术类配置项的字段 | 技术资产候选条目、技术类配置项字段 |
| 测试负责人 | 盘点测试用例、测试数据、测试环境参数等资产，确认验证相关配置项 | 测试资产候选条目、测试类配置项字段 |
| 评审组 | 评审清单完整性、判定理由和字段规范性，给出通过或退回结论 | 评审结论 |
职责交接时需要做确认动作，而不是口头传递。开发负责人把技术资产候选条目交给配置管理员时，应同时确认存放位置可访问、负责人已指定；配置管理员把清单初稿提交评审前，应确认每个入选项都有判定理由；评审通过后，配置管理员登记入库并将变更入口通知到各负责人，负责人确认已知晓自己名下配置项的变更提交方式。这些确认动作可以记录在清单状态或评审记录中，作为后续追溯依据。
一个研发项目的配置项识别示例
以下为演示情景，不对应真实客户项目。某迭代包含需求说明、接口设计、源代码、构建脚本、测试用例和环境参数六类资产，团队按四步流程完成识别。
| 候选资产 | 判定要点 | 结论 | 理由 |
|---|---|---|---|
| 迭代需求说明 | 被开发、测试多方引用；变更影响验收；需回溯历史版本；需评审后发布 | 纳入配置项 | 四个判定问题均为“是”，归入迭代基线 |
| 接口设计文档 | 被前后端共同引用；变更影响联调与测试；需回溯；需评审 | 纳入配置项 | 跨角色依赖强，归入迭代基线 |
| 源代码 | 被构建和测试引用；变更直接影响交付；需回溯；合并前需评审 | 纳入配置项 | 按代码仓库管理，归入发布基线 |
| 构建脚本 | 影响构建结果和交付物；变更需回溯；修改需评审 | 纳入配置项 | 与源代码同仓管理，归入发布基线 |
| 测试用例 | 被测试执行和验收引用；变更影响验证结论；需回溯 | 纳入配置项 | 归入迭代基线，与需求条目建立追溯关系 |
| 环境参数 | 影响部署和验证结果；需回溯配置差异 | 纳入配置项 | 敏感值单独保管，参数模板纳入配置库 |
| 个人调试脚本 | 仅个人使用；不影响交付；无需回溯；无需评审 | 明确排除 | 临时辅助材料，记录排除理由 |
| 会议纪要草稿 | 当前无多方引用；不进入交付 | 暂不纳入但登记观察 | 若形成决策记录并被引用，下次复核时重新判定 |
最终清单片段示例如下：
| 标识 | 名称 | 类型 | 负责人 | 存放位置 | 版本规则 | 基线归属 | 状态 |
|---|---|---|---|---|---|---|---|
| CI-REQ-001 | 迭代需求说明 | 需求文档 | 产品负责人 | 文档库/迭代目录 | 评审通过后递增 | 迭代基线 | 已入库 |
| CI-DES-001 | 接口设计文档 | 设计文档 | 开发负责人 | 文档库/设计目录 | 评审通过后递增 | 迭代基线 | 已入库 |
| CI-CODE-001 | 源代码 | 代码 | 开发负责人 | 代码仓库/主分支 | 按合并记录追踪 | 发布基线 | 已入库 |
| CI-BLD-001 | 构建脚本 | 构建资产 | 开发负责人 | 代码仓库/构建目录 | 随代码合并追踪 | 发布基线 | 已入库 |
| CI-TEST-001 | 测试用例 | 测试资产 | 测试负责人 | 测试管理目录 | 评审通过后递增 | 迭代基线 | 已入库 |
| CI-ENV-001 | 环境参数模板 | 环境配置 | 配置管理员 | 配置库/环境目录 | 变更需登记 | 发布基线 | 已入库 |
示例中排除项和观察项同样保留在判定记录中，评审时可以快速说明“为什么这个资产没有进清单”，减少后续反复讨论。
识别完成后的检查项与维护机制
识别是否做到位，可以用一组可核验的检查项确认，而不是凭感觉判断“差不多齐了”。
- 范围覆盖：各研发阶段的候选资产均已盘点，无阶段空缺。
- 判定理由齐全：每个候选资产都有结论和理由，排除项和观察项也有记录。
- 字段完整：入选项的标识、负责人、存放位置、版本规则、基线归属均已填写。
- 标识唯一：项目内无重复标识，命名规则已通知相关角色。
- 评审通过：评审结论已记录，退回项已整改并重新确认。
- 已登记入库：清单已登记到配置库，变更入口已通知各配置项负责人。
清单需要随项目演进维护。以下情况应触发重新识别：新增需求或设计文档进入受控范围；代码仓库新增模块或构建方式调整；测试资产新增类型；环境参数发生结构性变化；项目进入新的基线节点。触发后由配置管理员组织相关角色补充判定，更新清单并记录变更原因。
定期复核建议按迭代节奏或基线节点执行，由配置管理员发起，开发负责人和测试负责人确认各自名下配置项的状态，项目经理确认观察项是否需要转为纳入或排除。复核结果记录在清单状态和复核记录中，形成“识别—评审—入库—复核”的闭环。ONES 覆盖需求、基线、版本、变更、测试与发布的管理对象，可在同一体系中承载配置项与基线、变更之间的关联，便于复核时查看配置项当前归属和变更记录。
常见问题
项目刚开始、资产还不稳定时，要不要先做配置项识别？
建议先做一轮轻量识别，不必等资产稳定。此时可以把判定问题均为“否”的资产放入“暂不纳入但登记观察”，记录名称、持有人和观察理由，并设定复核时点。这样既不会过早把草稿类资产纳入受控范围，也不会在项目推进后遗漏已经变得重要的资产。等进入迭代或基线节点时，再对观察项重新判定。
配置项清单建好之后，由谁负责日常维护？
日常维护通常由配置管理员牵头，各配置项负责人配合。配置管理员负责清单结构、登记记录和复核组织；开发负责人、测试负责人分别确认自己名下配置项的状态和字段是否仍然准确；项目经理对观察项转为纳入或排除做确认。维护动作应记录在清单状态或复核记录中，避免只靠口头同步。
配置项识别和需求版本管理、交付制品管理怎么衔接？
三者关注的对象不同。配置项识别回答“哪些资产进入受控集合”，以及每个配置项的标识、负责人和基线归属；需求条目的版本号规则和变更审批流程属于需求变更与版本管理；交付包的打包、发布和制品库存储属于研发交付物与制品管理。衔接点在于基线归属和追溯关系：配置项清单中的需求类、交付相关条目，应与对应的需求版本和交付制品建立关联，便于回溯时找到同一批受控内容。
小团队人手有限，能不能简化识别流程？
可以简化形式，但判定问题和判定理由建议保留。小团队可以把盘点与判定合并为一次会议完成，评审由项目经理和配置管理员共同确认，字段模板只保留标识、负责人、存放位置、版本规则、基线归属和状态。简化的是参与人数和文档层级，不是跳过“为什么纳入”的记录，否则后续复核时容易重新争论同一批资产。
配置项清单在研发管理工具中登记后，还需要单独维护文档版本吗？
工具登记解决的是清单与需求、基线、变更之间的关联和状态追踪，文档本身的版本仍按团队约定的版本规则管理。ONES 围绕需求、基线、版本和变更建立统一管理对象，可支撑配置项与需求、测试、发布之间的追溯关系；清单字段和版本规则仍需团队自行定义并保持一致，避免工具记录与文档实际版本脱节。
