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

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

   一開始就延期了，怎麼辦？最直接有效的方法，加資源，冒著二期可能延期的風險，抽調了一名中級程式設計師小C到廣州開發一期。結果week 2結束後（7月22日），一期的開發只完成了不到50％，這時候離釋出一期beta版本只剩下5個工作日的時間。當時的直覺：一期如果還在廣州開發就必然會完蛋的，當機立斷，決定廣州的開發截至到26日，同時26日開始廣州那邊抽調一名初級程式設計師並和原來抽調過去的小C在客戶現場開發一期，同時以外包的形式把一大部分的內容給WBB開發。這回把寶壓在了XXX上面，幸好，偶沒有看錯人，WBB沒有讓我們失望，經過一個星期的努力和週末的加班，一期beta版本在8月1日如期釋出，先在客戶的技術部門內部做了一次評審，並在8月4日給客戶的業務科室做了一次演示，謝天謝地，演示過程沒有出錯。真的已經很穩定不會出錯了嗎？當然不是，在3日晚上內部測試的時候就預先把那些功能可用，那些不能用，那些按鈕可以點，那些不能點搞得清清楚楚，以確保演示的“萬無一失”。

   演示Pass後，經過QA的測試，在8月15日釋出了一期的release版本1.0。當時還很樂觀的認為一期不會有什麼問題，但後來幾天發生的事情，讓我自己都覺得這個版本實在太爛了，出現了很多很多不該出現的缺陷。因為什麼？沒有程式碼複審，在上線前如果我花1-2個小時的時間，認真看看程式碼的話，起碼可以保證不會出現一些很嚴重的問題，也不會弄得客戶的電話變成熱線，一刻都沒有停過。比如，一個非常嚴重的缺陷，單位A和單位B同時做業務C，單位B的使用者後登陸，單位A儲存資料後，這些資料都變成B單位的資料。Why？客戶帶我們去客戶的客戶那裡看現象的時候，我也不相信，怎麼會有這樣的情況發生？重新看程式碼，發現了某些可疑的程式碼可能會導致這樣的問題，修改後重新發布。當時有一個很可疑的變數，我感覺是有問題的，但一時忽略，沒有細看，這是基於：開發人員不會犯這麼低階的錯誤的。結果到了第二天，還是有這樣的問題，這回用了不到一分鐘的時間就發現struts的action類中居然出現了靜態變數，這個變數用來儲存單位編號，也就意味著某個時刻只會有一個單位存在，其他單位做的資料全部都是這個單位的資料。我Kao，這個錯誤也太低階了，實在無話可說。

   另外還有其他一些小問題，頁面問題，操作不方便問題，那段時間客戶的電話沒有停過，而且往往是一個電話過後，客戶就在我身邊跟我說這個有問題，那個有問題，接著又匆匆跑回去接電話，然後又匆匆的跑過來跟我說這個那個，那1-2天真不是人過的日子，連喝水的時間都沒有，幸好，客戶關係做得還算可以，壓力都頂住了。然後，電話慢慢，慢慢的少了，一個星期後，每天只有零星幾個電話，多數是操作問題。

   總的來說，一期是硬上的，沒有經過QA的嚴格測試，沒有客戶的試執行，沒有SA的程式碼複審等等，質量可想而知了。不過我們都挺過去了：一切終須過去，只要奮起面對。

   相比較而言，二期的質量就好多了，畢竟是專案組的主力完成。二期的開發是跟一期同時進行，在客戶現場，這樣做的目的是把客戶的資源也納入到專案組中，客戶的資訊部門有一個既熟悉業務也熟悉技術的人配合我們。一個很不爽的地方，由於客戶地方不夠，我們只能跟客戶同一個辦公室，什麼事情都暴露在客戶的眼皮底下，cvs等等重要的資源也是跟客戶共享，這個非常的不好。當別人對你知根知底的時候，想跟別人討價還價就很難了。另外，不得不說一下的，財神爺又不是沒錢，卻在硬體方面小氣得很，Web Server用的還是1個CPU，1G記憶體的機器，而且資料庫還是Sybase 11.9.2這樣的古董。先不說這些廢話了，看看二期的管理把。