luo weifeng 2011-5-21
時間過得真快，距上次做專案都快半年了，也是時候總結一下經驗教訓了。
首先，介紹下大背景。哈爾濱工業大學（威海）不算是很出名的學校，即使在我們自己看來都有點名不正言不順的意思，雖然是校區，但還沒有被普遍的承認和認識。但是學校還是很爭氣的，雖然扯淡的三方共建基本等於無經費**，但學校還是把自己放在了所謂好大學的位置。課程安排還是比較緊的，尤其是軟院，課程安排那個緊的也難以想象。沒5月1，沒10月1，好像從來不曾有假期這個說法。
上面基本扯談，下面進入正題。進入大三的第一學期（也就上個學期）很榮幸的轉戰到xx實驗室，而xx實驗室和yy公司有合作，所以做起了yy公司的乙個專案，這也是整個故事的開始。 專案很大，但在我們這群毛孩子面前就好像是天上掉下的機遇。專案被劃分為四個小組，三個前端，乙個後台，而我，有幸參與後台並作為組長。 正如你所意料的那樣，三個前端很成功，他們做的的確很棒。而我們後台，你可以想象ibm360當年的尷尬境地。不像失敗，也絲毫沒有成功的說法。接下來我做個個人的檢討，也是目前為止我們公認的專案失敗的一些原因，只為後來者做出一些借鑑，也為自己的那個半年畫上乙個句號。
失敗因素一：
介面標準的頻繁更改，或者說沒有標準。這個問題可以說是專案進展中最最突出的問題，一類是我們的客戶端-伺服器通訊協議。我們客戶端伺服器通訊協議在短短乙個月內出現了11個版本。而且很多都不相容前面版本。指定協議的時候只顧及了協議本身的優化，即使乙個欄位對業務沒有任何影響，也被接下來的協議立刻替代。造成的後果可想而知，四個團隊在不停的更改**以適應新的標準，造成了大量人月的浪費。後台內部也是一樣，資料庫設計從無到有，從第乙個版本到後期很多版本，一直在變動，自始至終沒有一套可以拍板的標準，而這方面，我個人對我的團隊以及專案表示深深歉意。
經驗一：時刻保證有乙個被大家共識和遵守的乙個標準（介面），在不危及專案成敗的情況下，所有對標準的更改被維護在乙個單獨的標準（介面）開發樹上。所有專案部分均按照這個既定的標準來執行，這個標準必須被大家所承認。所有開發過程中關於標準的異議和突發奇想在不影響專案正常進展的情況下都被載入到開發版標準（介面）樹上。
失敗因素二：人月安排。人月是個古老的問題，也是最考驗team leader的乙個東西，而我就在這裡翻了跟頭。對於人月的安排我同樣對專案組表示愧疚。後台小組四個人開發，我們算是有明確的分工。在開發前期，我過多的投入到了客戶端-伺服器通訊介面的討論中，以至於半個月後我們後台還像沒有開始一樣，資料庫的設計又走了標準頻繁變更的這個老路子。還有個更致命的地方就是：我作為小組的team leader竟然都我所依賴的組員的能力並不是很了解，有的時候竟然錯誤的估計了他們的生產能力。這個問題就好像：能否根據博爾特9秒58的100公尺記錄推測人類可以在100個9秒58裡拿下萬公尺記錄。還有乙個問題就是，正確估量可用時間，因為前面背景裡邊說了，大三的孩子都是很忙的。
經驗二：
team leader應該能夠很清楚的了解各個組員的能力，專案複雜度，做好恰當的人月安排。專案結束後我嘗試過去使用像project等管理軟體，然而真實的問題並不像project軟體那樣來的簡單。大二在zz實驗室的時候那個project圖夠標準正規了，可是真正做下來的時候，發現實際問題有時候竟然比這個複雜好幾倍甚至幾十倍。比如說，你考慮沒考慮過哪天一位或幾位同志感冒了，女同志孕產，誰女朋友過來了等等這些問題。 而這個正考驗team leader的東西，沒有經驗可供借鑑，而這方面我做的很失敗，在此向我的組員表示歉意。
失敗因素三：
嚴重缺少交流。口乃心之門戶，乙個成功的專案是需要很多交流的，而我們的專案中卻吧交流錯誤的夢想著用「詳盡的文件」來代替。誠然，這是可以替代的，然而，風險是很大的，因為你無法保證文件本身的可用性和權威性。而且，交流可以發現專案早期的路線錯誤，比如說，我在專案總結的時候才跟乙個哥們交流了下，他就很清楚的告訴我，標準（介面）問題對專案的困擾，要是我能在一開始就這樣交流就可能避免這樣低階的問題了。
經驗三：
永遠要想著跟團隊打成一片，要融入他們。team leader不能高傲的活著，交流的第一步便是成員關係，你沒有成員關係誰跟你用心交流，剩下的事就一切扯淡。
失敗因素四：
追求完美，過早的優化。我借用一句csdn上某人的話「將神的恩賜發揮到極致」。本來這句話是很有善意的，但是把它放在軟體工程中卻是致命的。因為追求完美，所以過早的去優化，無**檔或程式，過早的優化都是災難性的。
經驗四：
時刻準備開發第二個版本，在不影響專案成敗的情況下堅決不提前優化或增加功能。把所有對專案次要的東西都不要一次性往工程裡邊加，越微小的東西到最後越是災難性的，這個也就是所謂的軟體專案範圍控制。就那這個工程來說，直到完成這個工程，我們這邊做的東西確實他媽的正規，文件齊全，工程等都很規範，但是deadline的時候我們還不能執行起來。而bb團隊跟我們並行開發，他們的**確實很糟糕，文件很少，功能不如我們多，但是他們能跑起來了，可能一定意義上能執行了，我們這邊的開發像個臃腫的大胖子，往前走一步都很困難，以至於後邊的很多組員乾脆都不來實驗室了。
失敗因素五：team leader對組員的過分干預。這個可能大部分是我的原因，因為很多**我會去review，而且本身又是個極其追求完美的人。比如說，根據設計狀態嗎應該是通過邏輯操作來檢驗的，可是有大哥就直接列舉了，而我很不鎮定的要求按照我的思路做。現在想來真的很幼稚，可以這麼比喻：你覺得乙個專案的成敗重要還是實現的方法重要？
失敗因素六：
太過注重文件本身。要知道的一點是，why 文件？ 為什麼要做文件，這個是很關鍵的，整個專案開發過程中我們有接近10m的手寫文件。我們錯誤的把文件至上話了，而忽視了交流。文件是規範，他一方面是部分交流的替代，另一方面是留與後人的參見。我們把簡單的問題文件了老多老多，其實這些簡單的問題本可以在開發過程中很輕易的搞定。我們把自己的工程搞的跟ibm360一樣，企圖用文件來減少交流，而那些所謂的軟體工程權威在很多情況下都是不適用的。
經驗五：敏捷開發。首先宣告，敏捷開發不是沒有文件。還有，我不是敏捷開發方面的專家，有時間我會專程的學習這個東西。 我們都知道，軟體行業在近半個世紀才突然降臨世間，而這以前，汽車工程，電子工程等領域關於工程的理論已經趨於完善，還有一點，最初搞軟體的那幫牛人也大都出自這些領域。造成的結果是，人們開始用已有的工程控制理論來走軟體工程。他們被清晰的劃分成部分，階段，像我們所熟悉的需求分析，設計，編碼等。然而，「沒有銀彈」似乎在告訴我們，這條路不通。儘管「沒有銀彈」的本意不是這樣的，隨著軟體行業的發展，人們越來越認識到軟體工程有別於傳統工程控制的地方，於是敏捷就誕生了。在此我不再細說下去，因為我本人對這個還沒有細緻的研究，可它讓我看到希望。
一口氣寫了這麼多東西。一來，在此，我向我的團隊深深道歉。二來為一些像我一樣的人提供借鑑，同時，留此紀念，以慰那些年華。
2011-5-21 10:44
祭奠即將逝去的青春
是夜，4年後重登人人網，看到了張張熟悉的面孔。看到了很多同學和朋 友，此刻他們在washington chicago california dublin london south africa paris norway bombay 從他們的篇篇文章，張張的 看出，每個人都在為著自己的理想和信念奮鬥...
祭奠自己逝去的青春
祭奠自己逝去的青春 部落格裡，每個人都會總結自己這一年來的得與失，收穫與教訓，小漠也有自己的心事，也有自己的不捨與追求，2015年有歡樂也有憂愁。大四接近尾聲的時候，小漠找了乙份工作，是一家小型國有企業，工作氛圍挺好的，公司裡的同事待我也挺好。在公司裡實習了將近兩個月後小漠由於各種原因，向公司提交了...
記一次失敗的專案經歷
最近因為疫情原因一直在家，已經有快半年沒有更新部落格了，最近返回公司上班之後，去年做的專案已經完結，雖然已成功交付使用者使用，但是在我看來這仍然是失敗專案，在這裡我想回顧這些經歷，算是給後面的自己乙個警醒吧 我一直認為這是乙個失敗的專案，原因有如下幾點 專案為能如期交付，原定計畫是在2月份交付並發行...