别把6-1当填空题：配置项识别才是配置管理的真正起跑线
6-1配置项识别是整个配置管理流程的第一步，它的核心任务是确定“哪些东西需要被管起来”，并给它们定好名字、编号和基线规则，直接从源头杜绝项目后期“版本对不上、改错文件、追溯无门”的混乱局面。很多团队把配置管理做成了纯工具题，以为上了Git、SVN就万事大吉，结果分支满天飞、基线形同虚设，问题恰恰出在最前置的6-1环节压根没把“管什么”想清楚。
6-1配置项识别怎么做：从“管什么”到“怎么管”
在CMMI配置管理流程中，6-1对应的是配置项识别这一核心实践，这也是业内专家指出最容易流于形式的环节，很多团队写了一份配置管理计划，把“需求文档、设计文档、源代码、测试用例”这些大词往模板里一填就算交差,真正执行起来却发现根本没有可操作性。
配置项识别的本质是回答三个问题：管什么？管到多细？怎么命名？
配置项的粒度怎么定才算到位
配置项的粒度是6-1配置项识别中最关键的决策点，粒度过粗，一份几十页的文档被当作一个配置项，变更时无法定位具体范围；粒度过细，把每一行代码都当配置项管理,你的配置管理员会被变更记录淹没。
行业共识是遵循“可独立变更、可独立验证、可独立交付”三个标准来判断，一个需求规格说明书可以拆成多个配置项，用户登录模块需求说明”“支付模块需求说明”；但如果是一个只有两页的接口说明文档,整体作为一个配置项就够了。
实际操作中的参考粒度划分：
- 过程管理类：项目计划、配置管理计划、质量保证计划、评审记录
- 工程文档类：需求规格说明书、概要设计说明书、详细设计说明书、用户手册
- 技术资产类：源代码、数据库脚本、配置文件、编译脚本、部署脚本
- 交付物类：可执行程序、安装包、版本发布说明、验收报告
配置项编号规则要能一眼看懂归属
编号不是随便起个名字就完事，好的配置项编号规则能让团队从编号本身直接判断出这个配置项属于哪个子系统、是什么类型、处于什么版本，推荐采用“项目代号-子系统代号-类型代码-序号”的四段式结构。
某电商项目代号为EC,订单子系统代号为ORD：
EC-ORD-DES-001
表示订单子系统的第1份设计文档
EC-ORD-SRC-023表示订单子系统的第23个源代码配置项EC-ORD-CFG-005表示订单子系统的第5个配置文件
这样一来，在变更管理、配置状态报告和配置审计中，只要看到编号就能快速分类统计，不需要打开内容重新辨认，这个动作虽小，但在“配置管理流程包含哪些步骤”的完整链条中属于最基础的一环，前面不做扎实,后面的审计和追溯全是空谈。
配置项基线怎么设置才算合理
基线的本质是配置项在某个时间点的“快照”，作为后续开发和变更的基准，设置基线的时间点与项目阶段直接相关，而不是随手打标签,实操中建议在以下节点设置基线：
- 需求评审通过后：设置“需求基线”，所有后续设计必须基于此版本需求
- 详细设计完成并通过评审后：设置“设计基线”，编码以此为准
- 集成测试通过后：设置“产品基线”，代表软件达到可交付质量
- 重要变更完成后：设置新的“版本基线”，替代旧基线
一个常见的认知误区是把所有配置项都纳入同一套基线规则，比如源代码需要频繁更新，基线间距短；而需求文档的相对稳定，基线间距应该拉长,分组设置基线节奏更贴合实际项目节奏。
配置管理流程包含哪些步骤：6-1不是终点而是起点
配置管理流程包含哪些步骤这个问题，很多项目经理能背出“配置项识别、配置控制、配置状态记录、配置审计”这四步，但执行效果天差地别，差距就在于有没有把6-1配置项识别当成一个真正的工作任务来做。
配置项识别阶段要产出的三样东西
按CMMI的要求，6-1配置项识别阶段需要形成三个核心产出物,这三个产出物直接影响后续配置控制的有效性：
配置项清单：完整列出所有已识别出来的配置项，包含编号、名称、责任人、存储位置、当前版本，这份清单要动态维护,每新增一个配置项就登记入册。
基线计划：明确每个基线的触发条件、包含哪些配置项、审批人是谁，需求基线在需求评审通过后由项目经理批准建立”。
命名规范和目录结构约定：项目级统一定义配置项的存放路径规则，比如文档统一放/docs/，源代码按模块分目录,配置文件单独存放避免与代码混淆。
6-1和配置控制之间的衔接关系
配置项识别划定“管什么”，配置控制管“怎么改”，没有清晰的配置项边界，变更控制就无从下手不知道变动影响到了哪些配置项,审批流再多也只是摆设。
实际场景中，一个程序员修改了配置文件里的数据库连接参数，这个动作属于配置项变更，如果这个配置文件在6-1阶段就已经被纳入受控管理，修改前必须走变更申请，修改后要更新版本并提交配置状态报告，如果没有6-1的识别，这个文件可能只是程序员电脑里的一个本地文件，连入库都没有,出了事故找不到责任方。
所以在落地配置管理时，建议把6-1的产出物纳入项目启动会议的重要议程，项目经理应该亲自带队过一遍配置项清单，而不是让配置管理员自己埋头拉清单，他们不认,后面执行也难。
绕开6-1配置落地最常见的三个坑
第一个坑：配置项清单和实际开发脱节
相当一部分团队的配置项清单是应付CMMI评估准备的，评估一过就没人维护，代码库新增了模块、新增了自动化部署脚本，配置项清单上根本没有，开发过程中靠口头传“最新版本在某某目录下”,这跟没有配置管理没什么区别。
对策：把配置项清单纳入代码评审流程，凡是新增了独立模块、脚本、配置文件，必须同步更新配置项清单,否则不予合入主干。
第二个坑：把“入库”等同于“管理”
有些团队把所有文档和代码提交到Git就算完成配置管理了，但配置管理的核心动作是状态记录和变更控制你要知道某个配置项当前处于哪个状态（草稿、评审中、已基线化、已发布）,每一次变更记录都能追溯。
第三个坑：版本命名各搞一套
不同开发人员提交代码时版本号随意写，文档版本五花八门（有人用V1.0，有人用final，还有人用“最终版2”），6-1配置项识别阶段就应该定死版本命名规则，推荐在仓库仓库中统一使用语义化版本号规则主版本号.次版本号.修订号，文档同样遵循这套规则,这样在配置状态报告和配置审计中能审计中能一眼看出版本演进路径。
配置管理工具选型：不用纠结“最好”而是“匹配”
这里不得不用一个更长尾的角度去看：配置管理工具选型，工具选型虽然是后续动作，但选型的前提恰恰是6-1阶段对配置项类型的完整梳理，如果你的配置项主要是代码，Git是默认选择；如果包含大量二进制交付物和大文件，需要考虑Git LFS或专门的文件管理工具；如果有严格的合规审计需求,带完整审计日志的工具更合适。
工具选型前先做一遍6-1识别，看你的配置项清单覆盖哪些类型,再对照工具能力矩阵做匹配。
配置状态记录和配置审计是6-1的验收标准
配置管理流程包含哪些步骤的完整闭环里，配置状态记录和配置审计是验证6-1做得好不好的手段。
配置状态记录至少要有这些信息：
- 配置项的当前版本
- 配置项的状态（草稿/已评审/已基线/已发布）
- 历次变更的时间、原因、批准人
- 配置项之间的依赖关系
配置审计则要回答以下几个问题：
- 配置项的基线与变更请求是否一致？
- 配置项清单里的内容和库里的实际内容是否吻合？
- 交付物是否从已基线化的配置项构建而来？
配置项基线怎么设置和审计怎么配合：审计时随机抽检基线中包含的配置项版本是否和配置状态报告一致，如果发现版本对不上，说明配置控制环节出了问题，这时候回过去查6-1阶段的识别结果是否遗漏了某些文件。
关于6-1配置项识别的常见问题
配置项识别是一次性的事还是贯穿整个项目周期？
配置项识别不是一次性的活动，项目启动时做的第一轮识别是框架级的，把主要交付物和大类定下来；随着项目推进，新增了部署脚本、自动化测试工具、第三方依赖清单，这些都要持续补充进配置项清单，建议每个月组织一次配置项清单走查，确认没有遗漏，一套配置管理流程包含哪些步骤在落地时之所以变形,配置项清单维护不及时是首要原因。
第三方库和开源组件要不要纳入配置项管理？
要纳入，并且要记录版本号和来源，近年来的供应链安全事件让业界对第三方依赖的追溯需求明显上升，在6-1配置项识别中，把第三方库单独列为一类配置项，字段中增加“许可证类型”和“来源地址”，当前端或后端框架升级时,这组配置项的变更评估才能有依据。
配置项识别做到什么程度算“够”？
判断标准很简单：配置审计的时候，随机抽一个交付物的某个版本，你能否在半小时内找到对应的配置项记录、变更历史、基线信息？能，说明6-1做到位了；不能，说明识别的粒度或记录方式需要调整，配置项识别是配置管理的基石，这块石头打得浅,后面建的高楼迟早要塌。