今天遇到一個關于配置管理的真實案例，整理一下，跟大家分享一下。
背景：某軟件公司，職能部門明確，項目管理部門、產品部、售前部、研發(fā)部、測試部、配置管理部（3人）、QA。當前大產品線12條，當前處于運行狀態(tài)的項目50 ，由配置管理部牽頭各部門一起梳理當前配置管理問題，主要問題有：
1、開發(fā)庫混亂，產品與項目交叉，權限不明、責任人不清晰；
2、受控庫更新不及時（開發(fā)庫混亂，配置管理人員已無法跟蹤）；
3、產品庫更新不及時（負責人不明確，產品未入產品庫直接發(fā)送給客戶）；
4、未建立配置庫，所有文件直接存
放在服務器<開發(fā)庫>、<受控庫>、<產品庫>三個文件夾下，由各自負責人隨意建立子文件夾。
會議討論了兩個多小時，最終形成了一個定稿，如下：
1、繼續(xù)采用文件夾形式，不上配置工具，已完結項目不再跟蹤，只跟蹤進行中項目和新增項目；
2、開發(fā)庫產品和項目分開，分別建立產品和項目兩個頂級文件夾，產品由產品經理負則，項目由項目經理負則，配置管理員監(jiān)控；值此試運行一個月；
3、受控庫和產品庫暫不更改，沿用原來模式。
這個結果顯然是不好的，但是公司太過于龐大，項目文件總體體量太過巨大，一一梳理太耗人力和時間成本，只能暫時這樣處理。但這無異于飲鴆止渴，時間不會太久就會又變的十分臃腫、無法管理。
不同的公司可能采用的配置管理方式不同，我見過配置管理由專門的配置管理員負責的、由項目經理兼則的、由職能經理兼則的…任何方式都不能說錯，畢竟每家公司的體制不同、規(guī)模不同、客戶群體不同因而對配置管理的要求也就不同。
但不論怎樣，都需要有一個明晰的配置管理方法和制度，才能為項目管理、產品管理、公司運營提供助力。在這里分享一下我常用的配置管理模式，僅供大家參考。
我對配置管理一直奉行一句話，“三庫一專員，傳完喊一喊”。
三庫：
開發(fā)庫–項目過程中的所有文件、代碼、大小版本、測試結果等；配置管理員只負責監(jiān)督，不負責入庫工作；代碼、過程記錄由開發(fā)人員自行上傳；測試結果、測試報告/測試清單由測試人員上傳；
受控庫–經過評審的所有文件、里程碑基線/大小版本基線與對應的測試報告；只有配置管理員（和項目經理）有權限入庫和出庫，其他人只讀；
產品庫–項目交付所需的產品、過程文檔；項目過程中需提交給客戶的小版本產品及對應過程文檔；只有項目經理、產品經理、配置管理有權限入庫和出庫。
喊一喊：
不論是誰，上傳了什么版本，只要你做了改動并對別人會產生影響，都要以郵件的形式發(fā)給受影響的人，必須抄送項目經理和配置管理員！
根據不同的情況其實可以裁剪，之前駐場開發(fā)某項目時，在客戶本地服務器建立配置管理（SVN），再建立受控庫、產品庫，明顯不合適，就將受控庫和產品庫裁減掉，以SVN基線的形式，原本需要入受控庫的，打小基線；需要通過正式渠道交付給客戶的，打大基線。當時按照合同規(guī)定的是每完成一個里程碑就要交付一版供客戶進行場景測試?？梢院唵慰聪庐敃r的文件夾樣式（只能靠大腦回憶復現了）：
配置管理對于項目還是很重要的，尤其是涉及人員較多、跨職能部門、跨組織的項目，項目配置管理尤為重要，一個不慎，全面崩盤！
項目經理要做好配置管理還是要制定詳細的配置管理計劃，指定專門的配置管理員，我的方法不一定適合你，但是大的框架是差不多的可以借鑒的。
配置管理最根本的作用是協(xié)同工作，權限的分配不是最主要的，你上傳了新的版本，一定要廣而告之，配置管理不會說話，不會主動溝通，你不說，即使你再嚴格按照配置管理流程來走也是徒然。配置管理在項目管理中占得比重越來越高，給大家推薦一本書，寫的很不錯，可以看一看，指導性、規(guī)范性很強，對項目管理、配置管理幫助很大。謝謝。
版權聲明：本文內容由互聯(lián)網用戶自發(fā)貢獻，該文觀點僅代表作者本人。本站僅提供信息存儲空間服務，不擁有所有權，不承擔相關法律責任。如發(fā)現本站有涉嫌抄襲侵權/違法違規(guī)的內容， 請發(fā)送郵件至 舉報，一經查實，本站將立刻刪除。
