配置项从登记到归档，需要设计成一条有状态、有责任人、有记录的管理流水线。本文按“登记—版本记录—状态维护—归档”四个环节展开，先说明配置项范围与命名规则，再逐环节给出输入、动作、输出和完成标志，最后用完整示例和运行检查表验证流程是否真正执行。文中聚焦研发资产的受控管理，需求版本变更和交付制品管理分别由对应流程承接。
要点总览（TL;DR）
- 配置项流程按“登记—版本记录—状态维护—归档”四段设计，每段明确输入、动作、输出和完成标志，流程才能被检查。
- 登记前先定配置项分类与“项目代号-类型-序号”命名规则，需求版本变更和交付制品管理分别由对应流程承接。
- 版本记录用主次版本号加变更说明留痕，基线在评审通过或发布前冻结，清单逐项记录标识与版本号。
- 状态集合建议为草稿、受控、变更中、冻结、已归档，每次流转需审批并留记录，误登记走作废而非删除。
- 流程是否运行看记录能否支撑追溯：从登记表查到版本记录，从状态变更还原生命周期，从归档记录确认关闭依据。
先定配置项范围和命名规则
登记环节能否执行，取决于前置定义是否清晰。范围不清，登记表会变成“什么都往里装”的清单；命名不统一，后续版本记录和归档检索都会失效。建议先用一张分类清单明确“哪些资产纳入配置项管理”，再用命名规则保证每个配置项有唯一、可读、可检索的标识。
配置项分类清单
研发过程中需要受控的资产通常可分为以下几类。团队可在此基础上增删，但每一类都要写明纳入理由和责任人。
| 配置项类型 | 典型内容 | 纳入理由 | 责任人 |
|---|---|---|---|
| 需求文档 | 需求规格说明、用户故事集、验收标准 | 作为开发与测试的依据，需要版本可追溯 | 产品负责人 |
| 设计文档 | 架构设计、接口设计、数据库设计 | 变更影响面大，需要评审与留痕 | 开发负责人 |
| 代码 | 主干分支、发布分支的关键提交 | 交付物的直接来源，需要与版本对应 | 开发负责人 |
| 构建脚本 | 编译脚本、打包配置、流水线定义 | 影响构建结果的一致性 | 构建负责人 |
| 环境配置 | 测试环境、预发布环境的参数与配置 | 环境差异会导致问题难以复现 | 运维或环境负责人 |
边界需要同时写清：需求版本的具体变更控制归需求变更与版本管理流程，交付制品与构建产物的管理归研发交付物与制品管理流程。配置项管理关注的是“受控资产本身及其版本状态”，不替代这两条流程。边界写进分类清单，登记时才有判定依据。
命名规则与唯一标识
推荐采用“项目代号-配置项类型-序号”的结构，例如 PAY-DESIGN-003。规则要满足三点：全局唯一、类型可识别、序号不复用。配置项作废后序号保留，避免历史记录指向错误对象。命名规则表应包含项目代号对照、类型代码对照和序号分配方式，由配置管理员统一维护。
配置项登记表字段
登记表是后续所有记录的索引，字段不宜过多，但关键信息必须齐全：
- 唯一标识：按命名规则生成，登记时分配
- 配置项名称：简明描述资产内容
- 配置项类型：取自分类清单
- 责任人：对该配置项内容和变更负责的人
- 创建时间与首次纳入受控时间
- 当前状态：与状态集合一致
- 存放位置：文档库路径、代码仓库地址或配置中心位置
- 关联需求或工作项：便于追溯来源
登记环节：谁在什么时点把配置项录入
登记的触发时点是配置项首次产生或首次纳入受控范围。典型场景包括：设计文档完成初稿并准备评审、代码分支首次进入发布计划、环境配置首次用于联调。时点定在“首次需要被他人依赖”之前，避免资产已经在用却查不到记录。
登记操作步骤
- 开发负责人确认资产属于分类清单中的类型，按命名规则申请唯一标识。
- 开发负责人填写登记表必填字段，附上存放位置和关联需求。
- 配置管理员审核：核对标识是否重复、类型是否正确、存放位置是否可访问。
- 审核通过后，配置项状态置为“受控”，登记完成。
完成标志很明确：唯一标识已分配且审核通过。审核不通过时退回补充，不进入受控状态。登记表填写示例如下：
| 字段 | 示例值 |
|---|---|
| 唯一标识 | PAY-DESIGN-003 |
| 名称 | 支付网关接口设计说明 |
| 类型 | 设计文档 |
| 责任人 | 张工（后端开发负责人） |
| 存放位置 | 文档库/支付项目/设计 |
| 关联需求 | PAY-REQ-012 支付渠道接入 |
| 当前状态 | 受控 |
版本记录：变更如何留痕并形成基线
版本记录解决两个问题：每次变更改了什么、由谁确认；在哪个时点把一组版本固定为基线。记录方式建议采用“主版本号.次版本号”规则：内容结构调整或接口不兼容变更升主版本，文字修订和补充说明升次版本。每次变更必须附变更说明，写明变更原因、影响范围和审核人。
变更提交与记录动作
- 责任人修改配置项内容，在版本记录表中新增一行，填写新版本号、变更说明、变更日期。
- 评审人按配置项类型对应的评审要求确认变更，评审意见记入版本记录。
- 配置管理员核对版本号递增是否符合规则，确认后更新配置项的当前版本字段。
基线建立规则
基线是“在特定时点冻结的一组配置项版本”。常见建立时点包括：需求评审通过、设计评审通过、发布前冻结。基线内容清单要逐项列出配置项标识与对应版本号，并记录基线建立时间、审批人和基线说明。基线建立后，清单内配置项进入冻结状态，后续变更需走变更审批并生成新版本，不能直接覆盖基线版本。
| 版本记录字段 | 说明 |
|---|---|
| 配置项标识 | 关联登记表中的唯一标识 |
| 版本号 | 按主次版本规则递增 |
| 变更说明 | 变更原因、内容摘要、影响范围 |
| 变更日期 | 实际提交日期 |
| 审核人 | 评审通过的责任人 |
| 所属基线 | 若纳入基线，填写基线编号 |
版本记录与状态联动：产生新版本时状态进入“变更中”，评审通过后回到“受控”；纳入基线后状态置为“冻结”。状态变化本身也要记录，具体规则在下一节展开。
状态维护：配置项生命周期状态怎么流转
状态是配置项当前所处管理阶段的唯一表达，不能让责任人凭印象口头说明。建议状态集合为：草稿、受控、变更中、冻结、已归档。每个状态都要有进入条件、可执行动作和责任人。
| 当前状态 | 允许流转到 | 触发条件 | 审批人 | 记录要求 |
|---|---|---|---|---|
| 草稿 | 受控 | 登记审核通过 | 配置管理员 | 登记表审核记录 |
| 受控 | 变更中 | 提交变更申请并获准 | 开发负责人 | 变更申请单 |
| 变更中 | 受控 | 变更评审通过并生成新版本 | 评审人 | 版本记录与评审意见 |
| 受控 | 冻结 | 纳入基线 | 项目负责人 | 基线清单 |
| 冻结 | 变更中 | 基线变更审批通过 | 项目负责人 | 基线变更记录 |
| 受控或冻结 | 已归档 | 满足归档条件并通过完整性检查 | 配置管理员与项目负责人 | 归档记录 |
状态变更一律通过状态变更记录留痕，字段包括配置项标识、原状态、新状态、变更时间、操作人和审批依据。异常情况单独处理：误登记或重复登记的配置项走“作废”流程，状态标记为作废并注明原因，保留记录而不直接删除，避免历史引用断链。作废审批由配置管理员执行，涉及已纳入基线的配置项需项目负责人确认。
归档：什么条件下关闭配置项并保留证据
归档不是删除，而是把不再活跃的配置项转入只读保留状态。触发条件通常有三类：项目结束且无后续维护计划、配置项被新版本或新资产替代、配置项明确不再维护。满足任一条件即可发起归档，但必须通过完整性检查。
归档前完整性检查清单
- 登记表字段完整，唯一标识与存放位置可访问
- 版本记录覆盖全部受控变更，无缺失版本号
- 当前状态与最后一次状态变更记录一致
- 若曾纳入基线，基线清单中该配置项版本可查
- 关联需求或工作项链接有效
- 无未关闭的变更申请
归档记录与后续查阅
归档记录字段包括：配置项标识、归档原因、归档日期、完整性检查结论、审批人、保留期限和查阅方式。保留期限按项目合同或内部制度确定，没有统一口径时不强行规定年限，但要在记录中写明依据。归档后配置项转为只读，查阅权限保留给配置管理员、项目负责人和审计需要的人员，查阅动作本身可记入访问记录，便于追溯。
角色分工与各环节交付物
四个环节涉及四类角色。职责不清时最容易出现“登记有人做、状态没人改”的情况，因此需要一张责任矩阵把输入、动作、输出和完成标志对应到人。
| 环节 | 主要责任人 | 配合角色 | 输入 | 输出与完成标志 |
|---|---|---|---|---|
| 登记 | 开发负责人 | 配置管理员审核 | 资产内容、分类清单、命名规则 | 登记表，唯一标识分配且审核通过 |
| 版本记录 | 开发负责人 | 评审人、配置管理员 | 变更内容、变更申请 | 版本记录表，新版本号确认 |
| 状态维护 | 配置管理员 | 开发负责人、项目负责人 | 状态变更申请、审批依据 | 状态变更记录，状态与记录一致 |
| 归档 | 配置管理员 | 项目负责人审批 | 归档申请、完整性检查结果 | 归档记录，检查通过并转只读 |
职责冲突时的处理原则：配置管理员负责规则执行和记录完整性，不替开发负责人判断技术内容；评审人对变更质量负责，不承担登记审核；项目负责人对基线建立和归档审批负责。同一人兼任多个角色时，审批动作仍需留下独立记录，避免自己提交自己审批却无痕迹。
当团队把这条流程放到协作平台上执行时，登记表和版本记录可以作为工作项字段与文档模板承载，状态流转对应工作项状态，审批意见留在评审记录中。ONES 的方案覆盖需求、基线、版本、变更、测试与发布，并可将标准流程、评审节点和交付物模板沉淀为可复用资产，适合把上述规则从文档要求转成项目中的实际执行流程。配置项级别的登记字段和归档记录是否直接复用，需结合团队实际配置确认。
一个完整示例：从登记到归档走一遍
以“支付网关接口设计说明”为例，演示四个环节如何串起来。以下为演示情景，用于说明填写方式。
登记
后端开发负责人完成接口设计初稿，准备提交评审。他按规则申请标识 PAY-DESIGN-003，填写登记表：类型为设计文档，责任人为自己，存放位置为文档库支付项目设计目录，关联需求 PAY-REQ-012。配置管理员核对无重复标识、位置可访问，审核通过，状态置为受控。
版本记录与基线
评审会上，评审人提出补充超时重试策略。责任人修改文档，版本从 1.0 升为 1.1，变更说明写明“补充超时与重试策略，影响支付回调处理”，评审人确认通过。项目进入发布准备时，项目负责人将该文档 1.1 版本与其他设计文档、代码分支一并纳入发布基线，基线清单记录标识与版本号，文档状态转为冻结。
状态变化时间线
| 时间 | 动作 | 状态变化 | 记录 |
|---|---|---|---|
| 第1周 | 登记审核通过 | 草稿→受控 | 登记表 |
| 第2周 | 提交变更申请 | 受控→变更中 | 变更申请单 |
| 第2周 | 评审通过，版本 1.1 | 变更中→受控 | 版本记录与评审意见 |
| 第4周 | 纳入发布基线 | 受控→冻结 | 基线清单 |
| 第20周 | 项目结束，发起归档 | 冻结→已归档 | 归档记录 |
归档检查结果
项目结束后，配置管理员核对：登记字段完整、版本记录覆盖 1.0 和 1.1、基线清单可查、关联需求链接有效、无未关闭变更申请。检查全部通过，项目负责人审批归档，记录归档原因“项目结束”、保留期限依据合同条款、查阅方式为配置管理员审批后只读查阅。文档转为只读，流程闭环。
流程落地后的完成检查
流程写完不等于执行到位。建议按季度抽样检查，由配置管理员组织，项目负责人确认结果。检查项和判定标准如下：
| 检查项 | 检查方法 | 判定标准 |
|---|---|---|
| 登记完整率 | 抽取当期新增资产，核对是否在登记表中 | 抽样中未登记资产为零，必填字段无空缺 |
| 唯一标识重复 | 全量比对标识字段 | 无重复标识，作废标识未被复用 |
| 版本记录与基线一致性 | 抽取基线清单，核对配置项版本号与版本记录 | 基线内版本号均能在版本记录中找到对应行 |
| 状态变更审批覆盖 | 抽取状态变更记录，核对审批依据 | 每条变更均有审批人和依据，无口头变更 |
| 归档完整性 | 抽取已归档配置项，核对检查清单 | 检查项全部通过，归档记录字段齐全 |
检查结果形成记录，发现缺口时明确整改责任人和期限，下一轮复查。检查频率可按项目节奏调整，交付密集期缩短到月度抽样。流程是否真正运行，最终看的是记录能否支撑追溯：任意一个配置项，都能从登记表查到版本记录，从状态变更记录还原生命周期，从归档记录确认关闭依据。
常见问题
配置项登记由开发负责人提交、配置管理员审核，如果团队没有专职配置管理员怎么办？
可以由项目负责人或质量负责人兼任，但审核动作要独立留痕。兼任时建议在登记表上区分“提交人”和“审核人”两个字段，即使同一人操作也分别记录时间和依据。审核重点放在三件事：唯一标识是否重复、类型是否属于分类清单、存放位置是否可访问。团队规模较小时可降低审核频次，改为批量周审，但登记时点仍应保持在资产首次被他人依赖之前。
基线建立后，如果发现某个配置项版本有误，能不能直接改基线清单？
不建议直接修改已发布的基线清单。正确做法是发起基线变更：记录原基线版本、变更原因和影响范围，经项目负责人审批后生成新的基线版本，原基线保留可查。基线内配置项需要修改时，从冻结状态转入变更中，评审通过生成新版本，再决定是否纳入新基线。这样历史基线仍能还原当时的交付状态，审计和问题回溯时不会出现“基线被悄悄改过”的情况。
归档后的配置项还需要保留多久，保留期限怎么定？
保留期限取决于项目合同、行业监管要求和内部制度，没有统一年限。可行做法是在归档记录中写明期限依据，例如“按客户合同第X条保留至项目验收后三年”或“按公司档案制度保留五年”。没有明确依据时，至少保留到项目验收和质保期结束。归档后配置项转为只读，查阅权限保留给配置管理员、项目负责人和审计人员，查阅动作记入访问记录，便于后续追溯。
流程运行检查发现登记完整率不达标，应该先改流程还是先追责？
先定位缺口原因再决定动作。常见原因有三类：分类清单边界不清导致资产归属争议、登记时点定得太晚导致资产已在使用、登记表字段过多导致填写负担重。对应处理分别是补充分类示例、把触发时点前移到评审或联调之前、精简非必填字段。连续两轮检查仍不达标时，再把登记完整率纳入项目负责人的过程指标。检查记录中写明整改责任人和期限，下一轮复查同一抽样范围。
配置项管理和需求变更管理、制品管理之间怎么划清边界，避免重复登记？
按“管理对象”划分：配置项管理管受控资产本身及其版本状态，需求版本的具体变更控制归需求变更与版本管理，构建产物和交付制品归研发交付物与制品管理。落地时在分类清单里写明边界，并在登记表中用“关联需求或工作项”字段建立引用关系，而不是把需求变更单再登记一遍。跨流程的追溯通过标识关联实现：配置项标识指向需求编号，制品记录引用配置项版本号，各流程各自维护自己的记录。
