有關專案管理的一點實踐經驗！

引言：

在論壇上經常看到很多人有關專案管理的經驗，而且都是長篇大論，侃侃而談；總是看得我暈頭轉向，總感覺，都是停留在人的作用上，總是強調管理中的人為因素，幾乎很多條目都是帶有很強的人為色彩，看完後，總是覺得這些經驗很不錯，但是自己往往卻很難在自己的專案中具體實施。

想法：本人是乙個實踐主義者:)，自己在專案管理中，總是嘗試拋開人為因素的困擾，利用一些簡單通用的工具來協助專案管理，通過這些工具的運用，讓它們自動來推動專案管理的程序，減少人為因素的問題，形成一條無形的推動專案程序的生產鏈條。

核心鏈條：

源**管理工具 => bug追蹤工具 => 每日編譯工具

wincvs/cvsnt => bugzilla => bat和perl指令碼

下面是這些核心工具的運用經驗：

1. 必須建立源**的版本控制系統，就是cvs，基本的**提交原則：

1) 程式設計師盡量每天只在下班前提交一次;

2) 提交的**必須是在自己的機器上是正常執行的；

3) 每次提交都必須用簡短的話說明自己提交**的功能描述。

2. 建立錯誤追蹤系統，用bugzilla就很好，配置好郵件系統，使bugzilla成為測試人員與開發人員溝通的橋梁。

4. 測試人員的第二天，應該到公共區取得頭天的最新版本，並根據changelog進行新版本的測試。並將測試中發現的bug，通過bugzilla反饋給程式設計師。程式設計師可以根據自己的情況，或公司的規定來決定修改這些bug的時間。並將這些bug的修改情況，在**提交時，寫入**日誌。

5. 開發人員的第二天，應該到公共區檢視編譯日誌，看看自己的模組是否正常編譯，及時更正，看看自己的郵箱有沒有bug報告，及時修改。

6. 管理人員的第二天，在綜合專案需求與頭天版本進度的上，可以判斷產品的發展方向，如果有偏航或理解錯誤或有新需求時，可以根據當前情況及時調整。

這樣，通過 cvs => bugzilla => daily-build，就能將程式設計師與測試員，進行互動，各施其責。減少溝通與人為的麻煩。對於管理層，也能做到心中有數：因為每天都有新版本，隨時掌握產品的走向。。。等等。

另：有關專案管理中與客戶、與公司上層、成本、進度等等，這裡沒有具體談，但如果切實運用以上經驗，會在一定程度上簡化這些關係的複雜度，使得各個環節變得相對簡單。