配置项识别要回答的是“哪些研发资产需要纳入受控管理”。判断依据通常来自四类输入：受控范围约定、产品分解与交付结构、变更与影响分析需求、合规与审计要求。把这些依据写成可套用的识别准则，再逐项判定、分配标识和责任人，才能形成一份可维护的配置项清单。
要点总览（TL;DR）
- 配置项识别的依据来自四类输入：受控范围约定、产品分解与交付结构、变更与影响分析需求、合规与审计要求。
- 把依据写成含纳入条件、排除条件和边界示例的识别准则，再按“梳理候选资产→套用准则→判定纳入→分配标识与责任人→登记清单并纳入基线”推进。
- 配置管理员维护准则与清单，项目经理确认受控范围与基线，开发测试负责人提供资产结构，质量或审计角色确认证据留存范围。
- 识别结果用覆盖完整性、标识唯一性、责任明确、边界口径一致、基线归属清晰五项检查确认，并在基线建立、版本发布、范围变更等节点复核。
- 需求版本按需求变更与版本管理处理，交付制品按研发交付物与制品管理处理，识别环节只需在清单中注明边界资产的处理口径。
配置项识别的判定依据与核心步骤
配置项识别是一项判定工作，依据充分与否直接决定清单质量。四类输入分别回答不同问题：受控范围约定回答“这个项目或产品线要管到什么边界”；产品分解与交付结构回答“资产之间是什么组成关系，哪些层级需要独立受控”；变更与影响分析需求回答“哪些资产一旦改动，需要独立追踪版本、评估影响范围”；合规与审计要求回答“哪些记录和证据必须留存、可追溯”。四类依据同时成立时，资产才具备纳入配置项的充分理由。
识别准则应写成可判定的条文，包含纳入条件、排除条件和边界示例三部分。纳入条件描述资产满足哪些特征时进入清单，例如“独立交付给客户或下游团队的制品”“被多个模块引用且版本需要区分的接口定义”“审计要求留痕的评审记录”。排除条件说明哪些资产不单独设配置项，例如“可由构建过程自动生成且无独立变更历史的中间文件”。边界示例则针对容易争议的资产给出明确口径，例如需求文档按需求版本管理，配置项清单只登记其受控状态与基线归属，具体变更流程另行处理。
操作步骤按以下顺序推进，每一步都有明确的输入、动作、输出和完成标志：
| 步骤 | 输入 | 动作 | 输出 | 完成标志 |
|---|---|---|---|---|
| 梳理候选资产 | 产品分解结构、交付物清单、现有文档与代码目录 | 按产品结构逐层列出可能受控的资产，标注类型与来源 | 候选资产清单 | 候选清单覆盖产品结构各层级，无整层遗漏 |
| 套用识别准则 | 候选资产清单、已发布的识别准则 | 逐项对照纳入与排除条件，记录判定理由 | 带判定结论与理由的资产表 | 每项资产均有明确结论和依据条目 |
| 判定纳入 | 判定结论表、边界示例 | 对争议项按边界示例裁定，必要时提交评审 | 纳入项与排除项两组结果 | 争议项全部有裁定记录 |
| 分配标识与责任人 | 纳入项清单、命名与标识规则 | 为每个配置项分配唯一标识，指定责任人 | 带标识和责任人的配置项条目 | 标识无重复，责任人到岗确认 |
| 登记清单并纳入基线 | 配置项条目、基线划分方案 | 登记配置项清单，标注基线归属与受控状态 | 配置项清单初版 | 清单通过评审并发布，基线归属明确 |
准则的写法要避免两类问题：条件过宽导致清单膨胀、维护成本失控；条件过窄导致关键资产游离在受控范围之外。组织规模较小、合规压力较低时，可以只对交付制品和关键接口设配置项；处于强监管或高安全要求场景时，评审记录、测试证据等过程资产也需要独立受控。识别准则应随项目类型区分适用，不宜用一套口径覆盖所有项目。
识别过程中的角色分工与交付物
配置项识别涉及多类角色，职责边界清晰才能保证依据来源可靠、判定结果可追溯。配置管理员负责维护识别准则和配置项清单，组织判定评审，保证标识规则统一；项目经理提供项目受控范围约定，确认基线划分与交付节点；开发与测试负责人提供产品分解结构和交付物信息，对技术资产的组成关系负责；质量或审计角色提供合规与审计要求，确认证据留存范围。各角色在识别环节的输入与输出如下：
| 角色 | 主要输入 | 主要输出 | 交付物归属 |
|---|---|---|---|
| 配置管理员 | 识别准则、候选资产清单、评审意见 | 判定结论、配置项清单、标识分配记录 | 配置项清单与识别准则的维护责任 |
| 项目经理 | 项目范围说明、交付计划、基线划分方案 | 受控范围约定、基线归属确认 | 范围约定文档的审批责任 |
| 开发负责人 | 产品分解结构、接口定义、代码与文档目录 | 候选技术资产清单、组成关系说明 | 技术资产信息的准确性责任 |
| 测试负责人 | 测试用例结构、测试证据清单 | 测试类候选资产与受控建议 | 测试资产信息的准确性责任 |
| 质量或审计角色 | 合规要求、审计检查项、行业标准条款 | 必须留存的记录与证据范围 | 合规要求的解释与确认责任 |
审批记录应随配置项清单一起归档，记录谁提出、谁判定、谁批准以及依据哪条准则。清单更新责任归配置管理员，但纳入或移出配置项的判定需要对应角色确认：技术资产由开发或测试负责人确认，合规相关资产由质量或审计角色确认。识别准则的修订同样需要评审，修订后应说明对已有清单的影响范围。
示例：一个研发模块的配置项识别过程
以一个包含接口服务与前端页面的研发模块为例，候选资产包括：接口定义文档、服务端代码仓库、前端代码仓库、数据库表结构脚本、模块需求文档、接口测试用例、构建生成的部署包、模块设计评审记录。逐项套用准则后，判定结果如下：
| 候选资产 | 判定 | 理由 | 标识 | 类型 | 责任人 | 基线归属 |
|---|---|---|---|---|---|---|
| 接口定义文档 | 纳入 | 被多个模块引用，版本变化影响下游联调 | CI-API-001 | 接口文档 | 接口负责人 | 模块设计基线 |
| 服务端代码仓库 | 纳入 | 独立交付且需追踪版本与变更 | CI-SRV-001 | 代码 | 服务端负责人 | 发布基线 |
| 前端代码仓库 | 纳入 | 独立交付且需追踪版本与变更 | CI-WEB-001 | 代码 | 前端负责人 | 发布基线 |
| 数据库表结构脚本 | 纳入 | 变更影响数据兼容性，需独立追踪 | CI-DB-001 | 脚本 | 数据负责人 | 发布基线 |
| 模块需求文档 | 边界处理 | 按需求版本管理，清单登记其受控状态与基线归属 | CI-REQ-001 | 需求文档 | 产品负责人 | 需求基线 |
| 接口测试用例 | 纳入 | 审计要求留存测试证据，需与接口版本对应 | CI-TC-001 | 测试用例 | 测试负责人 | 测试基线 |
| 构建生成的部署包 | 排除 | 由构建过程生成，版本可由源码与构建记录追溯 | — | — | — | — |
| 模块设计评审记录 | 纳入 | 合规要求留存评审证据 | CI-REV-001 | 评审记录 | 质量负责人 | 模块设计基线 |
这个示例体现了两类边界资产的处理口径。需求文档本身按需求版本管理，配置项清单只登记其受控状态与基线归属，具体变更流程由需求变更与版本管理承接；部署包由构建过程生成，通过源码版本和构建记录追溯，不单独设配置项，其构建、发布与归档由研发交付物与制品管理承接。识别环节只需在清单中注明边界资产的处理方式，保证后续环节能按同一口径衔接。
识别结果的完成检查与维护
配置项清单初版形成后，需要逐项核对以下检查项，确认识别结果完整可用：
| 检查项 | 核对内容 | 通过标准 |
|---|---|---|
| 覆盖完整性 | 产品分解结构各层级、各交付物类型是否均有判定记录 | 无整层或整类资产遗漏，排除项也有理由 |
| 标识唯一性 | 配置项标识是否重复、是否符合命名规则 | 全清单标识唯一，规则一致 |
| 责任明确 | 每个配置项是否指定责任人并确认 | 无责任人空缺项 |
| 边界资产处理一致 | 需求文档、部署包等边界资产的处理口径是否统一 | 同类资产判定结论一致，有书面口径 |
| 基线归属清晰 | 纳入项是否标注基线归属与受控状态 | 每项均有基线归属，未纳入项有记录 |
未纳入配置项的资产不应简单丢弃，而应在候选资产表中保留判定结论和理由，便于后续复查。清单评审建议设置在基线建立、版本发布和阶段评审等节点；出现产品结构重大调整、合规要求变化、项目范围变更时，应触发清单复核。发现识别偏差时，先定位是准则条文不清还是执行遗漏：准则问题走修订评审，执行问题补充判定记录并更新清单，同时检查同类资产是否存在相同偏差。
配置项清单的登记、标识维护与基线归属需要在日常协作中持续承载。ONES ALM 研发管理方案围绕需求、基线、版本和变更建立统一管理对象，可将配置项清单与需求、测试、发布等对象关联，沿关联关系分析变更影响并保留过程追踪记录，适合作为清单维护的承载方式之一。具体字段配置与模块组合需按实际部署确认。
常见问题
项目刚开始、产品结构还没稳定时，配置项识别应该做到什么程度？
产品结构尚未稳定时，可以先按已知的交付物和关键接口建立初版清单，把判定理由写清楚，并标注“待结构稳定后复核”。识别准则中的纳入条件可以按资产类型描述，避免绑定具体模块名称，这样结构变化时只需调整清单条目，不必重写准则。初版清单不必追求一次覆盖全部资产，但排除项也要留下记录，便于后续复查时判断是遗漏还是有意排除。
同一个资产既涉及需求版本又涉及配置项清单，会不会重复管理？
两者管理的是不同维度。需求文档的版本演进、变更申请与审批由需求变更与版本管理承接；配置项清单登记的是该文档作为受控资产的标识、责任人和基线归属。实际操作中，清单条目可以引用需求版本号，但不需要在清单里重复记录每次变更内容。识别环节要做的是明确这条边界口径并写进准则，避免两个环节各自判断、结论不一致。
配置项清单建立后，什么情况下需要重新识别？
常见触发条件包括：产品分解结构发生重大调整、项目范围或交付节点变更、合规与审计要求更新、基线重新划分。日常的小版本迭代通常只需更新已有条目的状态和基线归属，不必整体重做识别。建议把复核时点与基线建立、版本发布、阶段评审等节点绑定，并在准则修订后检查已有清单是否受影响的条目需要调整。
发现清单漏掉了关键资产，应该怎么纠正？
先判断偏差来源：如果是准则条文没有覆盖这类资产，走准则修订评审，修订后按新条文补充判定并检查同类资产是否存在相同遗漏；如果是执行时漏判，补充判定记录、分配标识和责任人后更新清单，同时回溯同一批次的候选资产表。纠正完成后，把该案例补充为边界示例，减少后续重复出现同类偏差。
配置项清单在研发管理工具中维护时，需要关注哪些衔接点？
重点看三处衔接：清单条目能否与需求、测试、发布等对象建立关联，便于分析变更影响；标识与责任人字段能否统一维护，避免多处口径不一致；基线归属能否随版本发布同步更新。ONES ALM 研发管理方案围绕需求、基线、版本和变更建立统一管理对象，可作为清单维护的承载方式之一，具体字段配置与模块组合需按实际部署确认。
