專案（FBMS）總結－管理篇(1)

本文可以任意轉載或分發,但請註明作者和出處。

   面臨的困難很多，如何能夠在兩個月時間內完成這麼一個專案？我們還是一步一步的來看看把。

   專案組在專案啟動之日（2005年7月4日）成立，當時的專案組的組成有PM、QC、 TM和QA各1名，高階程式設計師（其中一名從公司其他部門借調過來，時間到8月底）2名，中級程式設計師3名，初級程式設計師2名，還有一個mm（需求人員/整合測試人員/文件編寫人員）。幸好，專案組中有多名團隊成員參與過第一個專案（國庫集中支付）的開發，積累了不少的經驗。

   專案採用跌代的開發方式，其中一期beta版本在7月底釋出（以提交給客戶做評審為標誌），release版本在8月15日釋出；二期beta版本在8月15日釋出（同樣，以提交給客戶做評審為標誌），release版本在9月5日釋出。從最後的結果來看，當時錯誤的估算了二期的beta釋出時間，直到8月22日（其實這個時間釋出beta版本客戶也應該是接受的）才釋出，延期一週。

   為了規避需求風險和技術風險，7月4日－7月8日，需求開發人員天天纏著客戶（mm就有這樣的好處了，換成個大男人天天纏人就不太好了）確認需求，同時組織技術評審，定好大體的開發和技術框架。

    由於不熟悉業務，只得採用駐客戶現場開發的方式，但有些團隊成員（1高階程式設計師，2中級程式設計師）有其他任務在身，不能在客戶現場開發。迫不得已，安排他們在廣州開發一期，專案組主力駐客戶現場開發二期，分為兩條開發主線並行開發。當時錯誤的估算了一期的工作量和高估了廣州開發人員的能力，在Week1結束後（7月15日）發現廣州開發小組只是做了幾個還沒有完善的jsp頁面，其他什麼都沒有，進度已經嚴重滯後。當時分析的原因有那麼幾點：

i.    廣州那邊的開發人員沒有參與第一個專案的開發，技術積累不夠，業務知識積累不夠。

ii.    由於需求是在客戶現場捕獲的，透過msn等交流工具存在很多的溝通問題。

iii.    開發人員的能力確實不夠，短時間要求他們的生產效率大幅提高不太現實。

iv.    迫於時間的壓力，沒有做技術框架的Demo和完善的架構文件以及技術說明，直接導致了程式碼的不規範和實現方式的不統一，直接影響了一期的開發效率和進度的滯後，因為一期的開發人員大多是新手，希望他們幾天時間瞭解struts、dao等等確實是勉為其難。