配置管理：文档配置库不是历史的垃圾堆

现在“配置管理”基本已经充分的普及了，差不多我遇到的每一个项目组建立了自己的“配置库”，配置库一般也都包括两部分：代码配置库，以及文档配置库。但遗憾的是，我常常发现大家对于代码配置库的利用还是比较有效的（可能使拜IDE中集成的配置管理所赐吧），而文档配置库基本上就是“历史的垃圾堆”。
本文主要说说文档配置库存在的问题以及改善方法----注意，这里不讨论代码配置库。文档配置管理最容易的犯得错误就是不知道“项目的配置需求”，因而出现下列“重形式，轻内容”的情况。

重要的文档都没有进入配置库（判断文档是否重要的标准是：是否经常阅读这些文档；是否经常被其他文档引用）

比如：一个项目的背景资料，这个项目是为了落实什么“想法”。这个“想法”对于任何进入项目的人来说都是极好的“入门教材”----它浅显易懂；项目实施过程中，又是极好的“紧盯项目目标的工具”----它是当之无愧的项目目标（参见：）；对于“大国企的项目”，可以根据这个“想法”仔细的去琢磨其“表面的项目目标下的”深层的“政治目的”。

比如：需求分析，概要设计的中间产品，如“思路”的演进；大家关于某一个问题的讨论的过程以及结论；常常在我的项目中最重要的文档是：

一个针对需求的思维导图（用mindmanager画的项目整体需求的树状图，满足需求管理中的“层次”和“粒度”的需要。参见需求相关：需求管理如何管；需求相关：Use Case用例的“抓手”）；

一个用于解释系统整体架构的PPT。系统架构的目的很大程度上是要在项目组内部推广（PPT非常利于推广时候的演讲），因此采取项目组成员人人都能理解且一目了然的方式当然最为有效。

一个顶层“用例图”：用于把握项目的整体需求方向（参见：需求相关：实战用例--“电信OSS资源管理系统”）。

比如：关于一些开发工具、数据库、应用服务器的安装、配置以及使用的技巧。这些类似于“学习笔记”的东西，这可以避免大家一遍一遍反复的上网查询。甚至能有效的营造出一个“学习型团队”的氛围，而促进团队凝聚力。

比如：“新人入门”。我曾经做过一个项目，人员流动非常厉害（主要是公司总是借人给我用，过不到2、3个月就抽走，又换新人来----危害不在这里说了）我为了应付反复对“新人”说重复的话，在我们的文档配置库中专门建立一个“新人入门”，包括“项目目标的简单说明”、“项目需求的简单说明”、“项目配置库的使用”、“开发环境建立的步骤”等等。

文档配置库成为历史的垃圾堆。

进入配置库的都是些“格式一流”，“内容三流”的文档，如：。

需求规格说明书：由于需求规格说明书太大，导致产品人员疏于更新（更新成本太高）；研发人员懒得去读（太长了，而且那种可以理解的文字水平，是在没有兴趣读写去。文档工程师显然没有《昆虫记》作者法布尔对事物的描述水平）。（参见：需求相关：需求管理如何管）需求规格说明书的价值主要体现在：1、大家都离职了，下一波冲上来的工程师用来对项目“扫扫盲”；2、研发、测试人员“扯皮”用，用来指责需求工程师----“你看，你的需求说明就是这么写的，因此这个责任不关我的事”。

概要设计文档：为了通过评审，概要设计文档“抽象”的外行看了“看不懂”，内行看了“全是放之四海皆准的东西”。反正后期的研发工作和这个概要设计没什么直接关系。更为奇怪的是：概要设计多半处于“架构师”之手，而架构师在做完“架构设计”就会被公司抽调到其他更为重要的地方去了(参见：技术相关：我们需要什么样的架构师？)，这个概要设计文档入库的意义可能就在于此吧。

以及测试用例、编码规范这些等等

进入配置库的都是一些经过“评审”且板上钉钉的文档：配置管理有一个很重要的目的就是“管理变更”，有变化才需要管理，也才有管理的难度和复杂度。项目中，不经常需要修改的文档，也正是不重要的文档。

配置管理人员和项目组割裂。

大多数项目组的配置管理员一般都是由精通“配置管理软件”的人员来担当的。当这个角色不了解这个项目真正有价值的文档是什么后，就出现了很多项目组出现的问题：项目组为了避免“配置管理上的麻烦”而把最不经常变换的东西提交给“配置管理员”；而配置管理员也就稀里糊涂的把这些东西当成“宝贝”置入配置管理库。

建设“文档配置库”的目的是消极的，而不是建设性的。

大家都有一个很奇怪的想法，就是把文档纳入配置库，是为了避免事后的“扯皮”，以及确定“谁该对某件事情的失败而负责任”。而忽视了配置管理最根本的：为什么需要对“变更进行”管控。

配置库的“过度管理”导致整个配置库的失效。

说的配置管理，似乎大家都非常重视“变更”的管理，很多公司专门成立了SCCB（软件变更配置委员会）。一次变更要经过：1、变更请求；2、SCCB审核；3、配置管理员开放权限并备案；4、发生变更。流程看起来很美，问题是：

首先，SCCB很多时候是由领导组成的，本身既不了解项目，也没有时间去了解项目中哪些文档需要变更、可以变更。这时谁的嘴巴大，领导就听谁的了。

流程的复杂性导致那些真正重要的文档----需要经常变更的文档，不敢进入配置库。每变更一次都要走一遍流程，谁受得了？

针对项目组的配置管理培训则“重工具，轻内容”

其实很多项目组也都重视对于配置管理的培训，但培训中所强调的是VSS，CVS，CleanCase等工具的使用与维护，而对于什么内容该入库，什么内容有价值却没有一个衡量标准。

而针对上诉问题的改善的更本性方法就是：改变“重形式，轻内容”为“重内容，轻形式”。

关于称职的配置管理人员：配置管理工作的角色有两部分构成：

能够判断项目中文档重要性的人，主要“抓内容”----一般来说就是“项目经理”。

能够保证配置库的有序的人，主要“抓形式”。督促项目组成员养成良好“配置管理习惯”的人员。

在选择配置管理人员的时候，不必看其是否做过配置管理工作。我常常的方法是，考察这个人对于MP3的收集水平（只要有“收集”的爱好就可以）。大量MP3的收集整理和配置管理有异曲同工之妙，对于mp3目录的组织；文件的更新都能反映一个所谓“配置管理人员”的内在素质。

由于其常常需要和“人”打交道，需要其沟通能力，以及耐心，远比其所谓的对于配置管理工具的熟练使用要重要的多（很多时候，项目组中的那个文档工程师的小MM，就是一个不错的选择）。

“抓内容”和“抓形式”角色的分开，既能够解放项目经理对于琐碎小事的分心，也有利于项目经理整体把握项目真正有价值的“内容”。

关于对于有价值内容的判断：（我的经验）

经常“想去变更”的文档就是最有价值的文档：比方说“各种列表”，如需求跟踪列表，Bug跟踪列表等。

经常“需要去看”的文档就是最有价值的文档：比如“用例图”；系统架构图

那种涉及复杂逻辑的文档：这些文档常常容易搞混淆，而且过段时间就忘记了：比如客户的“业务处理流程”等等

常常在项目组中提及的文档：项目组在开会、或者讨论时候常常提及的东西，比如涉及到项目背景，技术背景相关的那些文档，甚至包括软件的的配置、安装、维护技巧等。

关于配置“管理”本身：

流程要简单：配置管理的核心目的是为了把大家纳入到配置管理过程中来，因此简单的流程是大家“心甘情愿接受配置管理的”的良方；而通过“高压”、“处分”“罚款”等方法都只能适得其反。着这里想想“三个代表”也是有益的（参见：过程相关：实行CMM要以“三个代表”为指导思想）。

工具要易用：对于配置管理工具的选择，完全没有必要追求“高”“新”“尖”。项目组成员大家都用过的工具，大家都愿意接受的工具就是最好的工具。记住“内容比形式更重要”。