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

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

   首先，最重要的先把範圍定好，跟客戶確認在2005年9月5日上線包括的內容，這方面經驗不足，其實有很多可以在9月底上線的內容都提到9月5號，但客戶一口咬定非得在9月5日上線，現在想想，實在不知道客戶方出於一種什麼考慮。其次，定好範圍後，拆分模組根據團隊成員的特點分配工作，比如新加進來的開發人員就分配一些不需要熟悉業務的工作，參與過上個專案開發的就分配一些熟悉業務的任務等等。其實加快任務的執行最有效的方法就是拆分為並行的多個任務，而且這些任務相互之間的關聯越少越好，這個跟Oracle並行執行的原理是一樣的。

二期開發一週（7月16日）後，發現專案組的前臺開發效率很低，專案比預期延期了20%。效率為何低下，當時分析的原因有：

i.    專案組成立沒多久，團隊之間的磨合不夠，基本同一班開發人馬，加入的人員又是新人，要想在短時間內，提高開發效率是比較困難的

ii.    開發人員的能力不夠

iii.    對於現場開發的開發環境，不利於團隊建設和人員溝通，由於和客戶混在同一個工作場所，人員計程車氣會受到影響、交流的機會大大減少

   當時在進度報告中對這些情況作了詳細的說明，要求增加1名熟練的前臺開發人員開發新的業務模組以及熟悉Sybase的後臺開發人員2名開發查詢統計部分〔如果目前資源不足以完成任務的情況，PM就應該跟高層要求資源了，不然PM沒有跟高層說明情況而導致專案延期的話，老闆會很生氣，後果會很嚴重，責任會很大〕。報告是發過去了，不過高層那邊好像穩如泰山，不見一點動靜。當時感覺是部門沒有資源可用了，專案已經存在延期的風險，起碼beta版本的釋出會受到很大影響。幸好，在第二週，新加入的高階程式設計師小W的開發效率提高了很多，這是一個很利好的訊息。在第二週結束後，小W開始了新業務模組的開發，但查詢統計還是沒有人開始做，需求開發、程式碼開發等等，還是原樣。

   這樣的開發一直到了7月底，這時候由於一期要上線，中間抽調了不少資源在一期上，在8月初的第一個星期，感覺特別的亂，一期開發和二期開發扯在一起，那段時間基本上沒有計劃的，內容實在是太多，人員安排不過來〔不要跟我說加人，這時候加人只會更亂〕。幸好，也只是一週的時間，慢慢的，從混沌又恢復到正常，這是在一期上線後，也就是在8月8後。

   這時候，又加入一名新人小Y，據稱熟悉Sql server，熟悉儲存過程，加入專案組開發查詢統計。不過一天過後我就覺得，如果單靠這個人的話，查詢統計兩個月都做不完，技術不太熟練之餘，業務上的理解有不少問題。負責開發需求的人在跟我提意見，說小Y應該這樣開發，不應該那樣開發，偶只是聽，沒有做其他實質性的工作，因為我知道單憑他是不可能完成任務的，反正都要延期，不如先集中精力把其他有望如期交付的任務上面。這種情況也如實往部門高層反映，並抄送了一份給大Boss。不知道是客戶給boss施加了壓力還是什麼其他原因，大boss派了一個玩了八、九年的sybase人CF過來，當然效率不是小Y可比擬的。客戶曾經說過，查詢統計不能在9個工作日內完成，但CF做到了，而且是在週末沒有加班的情況下做到的。