今天遇到一个关于配置管理的真实案例，整理一下，跟大家分享一下。
背景：某软件公司，职能部门明确，项目管理部门、产品部、售前部、研发部、测试部、配置管理部（3人）、QA。当前大产品线12条，当前处于运行状态的项目50 ，由配置管理部牵头各部门一起梳理当前配置管理问题，主要问题有：
1、开发库混乱，产品与项目交叉，权限不明、责任人不清晰；
2、受控库更新不及时（开发库混乱，配置管理人员已无法跟踪）；
3、产品库更新不及时（负责人不明确，产品未入产品库直接发送给客户）；
4、未建立配置库，所有文件直接存
放在服务器<开发库>、<受控库>、<产品库>三个文件夹下，由各自负责人随意建立子文件夹。
会议讨论了两个多小时，最终形成了一个定稿，如下：
1、继续采用文件夹形式，不上配置工具，已完结项目不再跟踪，只跟踪进行中项目和新增项目；
2、开发库产品和项目分开，分别建立产品和项目两个顶级文件夹，产品由产品经理负则，项目由项目经理负则，配置管理员监控；值此试运行一个月；
3、受控库和产品库暂不更改，沿用原来模式。
这个结果显然是不好的，但是公司太过于庞大，项目文件总体体量太过巨大，一一梳理太耗人力和时间成本，只能暂时这样处理。但这无异于饮鸩止渴，时间不会太久就会又变的十分臃肿、无法管理。
不同的公司可能采用的配置管理方式不同，我见过配置管理由专门的配置管理员负责的、由项目经理兼则的、由职能经理兼则的…任何方式都不能说错，毕竟每家公司的体制不同、规模不同、客户群体不同因而对配置管理的要求也就不同。
但不论怎样，都需要有一个明晰的配置管理方法和制度，才能为项目管理、产品管理、公司运营提供助力。在这里分享一下我常用的配置管理模式，仅供大家参考。
我对配置管理一直奉行一句话，“三库一专员，传完喊一喊”。
三库：
开发库–项目过程中的所有文件、代码、大小版本、测试结果等；配置管理员只负责监督，不负责入库工作；代码、过程记录由开发人员自行上传；测试结果、测试报告/测试清单由测试人员上传；
受控库–经过评审的所有文件、里程碑基线/大小版本基线与对应的测试报告；只有配置管理员（和项目经理）有权限入库和出库，其他人只读；
产品库–项目交付所需的产品、过程文档；项目过程中需提交给客户的小版本产品及对应过程文档；只有项目经理、产品经理、配置管理有权限入库和出库。
喊一喊：
不论是谁，上传了什么版本，只要你做了改动并对别人会产生影响，都要以邮件的形式发给受影响的人，必须抄送项目经理和配置管理员！
根据不同的情况其实可以裁剪，之前驻场开发某项目时，在客户本地服务器建立配置管理（SVN），再建立受控库、产品库，明显不合适，就将受控库和产品库裁减掉，以SVN基线的形式，原本需要入受控库的，打小基线；需要通过正式渠道交付给客户的，打大基线。当时按照合同规定的是每完成一个里程碑就要交付一版供客户进行场景测试。可以简单看下当时的文件夹样式（只能靠大脑回忆复现了）：
配置管理对于项目还是很重要的，尤其是涉及人员较多、跨职能部门、跨组织的项目，项目配置管理尤为重要，一个不慎，全面崩盘！
项目经理要做好配置管理还是要制定详细的配置管理计划，指定专门的配置管理员，我的方法不一定适合你，但是大的框架是差不多的可以借鉴的。
配置管理最根本的作用是协同工作，权限的分配不是最主要的，你上传了新的版本，一定要广而告之，配置管理不会说话，不会主动沟通，你不说，即使你再严格按照配置管理流程来走也是徒然。配置管理在项目管理中占得比重越来越高，给大家推荐一本书，写的很不错，可以看一看，指导性、规范性很强，对项目管理、配置管理帮助很大。谢谢。
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌抄袭侵权/违法违规的内容， 请发送邮件至 举报，一经查实，本站将立刻删除。
