艾偉也談項目管理，技術上司的疑難：如何掌控其他成員的開發

　　如何将項目的開發掌控好是技術上司（Team Leader）必須做好的。何為掌控項目的開發，即開發的進度和品質在計劃内，不在期限快到時慌手慌腳，也不需交期到時天天加班，更不能删減測試時間。總而言之，就是開發工作有節奏，按部就班到達預期目标。

　　理想總是好的，可現實總是殘酷的。你有過每個周六都加班，每晚都加班的經曆沒？你有項目完不成，接二連三申請延期釋出的經曆沒？你有過遇見過你委以重任，但他卻誤了你事的同僚沒？如果你工作了一段時間，又恰好又有帶過小隊伍的經曆。我想你應該也遇到過這些問題中的一個或幾個吧。

　　我當然也遇到過，一回是将一個很重要的功能元件重寫的任務分派給一個新的團隊成員，給予了我能給的最多資源，并将其他任何任務，可能的幹擾源我都給擋了。但結果呢，開始我還滿懷希望，因為他非常自信，也不斷的給我好消息，比計劃更快更好。但時間過去一半也就是約兩個月後，痛苦開始來了，他建立了一個新的分支，因為接口變了，無法和其他元件內建建構，而這一切我之前竟然不知道。但離版本釋出已經隻有2個月時間了。這還包括測試。而該子產品功能上都還隻完成一半的樣子，而且完全抛棄了原有做法。更慘痛的是兩個星期後他離職了，面對不能內建，功能不全的半成品真是欲哭無淚。最後版本釋出時，此過程中代碼僅作參考，而使用舊代碼修改版本，預期的一些功能沒有，預期的效率提升沒有，還加班一段時間。這也是我的軟體開發曆程中最大的遺憾。

　　事後，我總結了該次技術事故的教訓，但沒有及時發貼。現在做一下簡單的總結，如何避免此類事故的發生。

　　一、認識問題

　　在将較大的子產品配置設定之前，必須確定子產品主人明确了需求，了解了問題。很多程式員有一拿到問題立馬動手的沖動，此時你至少應保證他看到了所有的問題。此步絕對不能省略，你不能假設他自己會去找需求，他能找到需求。你也應該将你對需求的認識，你從全局上的觀點傳遞給他。

　　二、搭架子

　　在甩手出去的工作，尤其是較重要的子產品給一個不了解的人的時候。必要的子產品架構設計是不能少的，這個時候你可以了解他的思路；讨論中提升設計的品質；更重要的是可以從整體的角度評判設計是否合理，是否可以和其它子產品較好的工作。同時還可以減少子產品開發人員的困惑，減少獨自摸索的時間。

　　三、分解工作

　　在架構設計的基礎上，将工作分解開來，獨立出來一段一段做。分解時最好和開發人員讨論，他在細節上可能會比你更清楚。

　　a. 工作項的大小。從經曆來看每個工作項1-2周比較妥當，時間太長不利于管理時間，也較難準确預估。太短又太細，而且有些事情又沒那麼容易做完做好，此外還可能涉及其他方面的修改。很多人習慣做完任務就不管了，也沒有足夠的時間測試，調整。

　　b. 工作項的獨立性。必須保證每個工作項的獨立性，可以單獨開發，單獨內建。每一到兩周将代碼內建編譯并做簡單的內建測試（保證主體不受影響，新增功能有效）。

　　四、及時跟蹤設計，時間，代碼

　　先說設計上的跟蹤，在新成員剛參與時。可以要求必要的設計文檔，如類圖，核心部分的序列圖。再就設計與程式員讨論我們現有的設計樣式，使設計與已有設計有一定的相似性。并可借此機會培養新成員的設計水準和設計方法。此讨論可以多讨論一些OO，設計模式什麼的。不一定要用，但要有用的準備和用于不用的判斷。

　　時間上的跟蹤，主要是每周的周會，周會上可以依照總的時間安排和工作進度一起簡要讨論，讓大家心中有底。此外還有每周的工作安排和回顧，新成員可以要求寫細點，每周要有兩到三個檢查點，及時跟蹤。出現問題可以及時發現。

　　代碼上的跟蹤，主要是要求在最新代碼上開發，保證有互動的元件可以正确編譯。此外新成員要在開始一段時間對代碼進行Review，保證編碼符合規範。模式和已有代碼一緻。

　　另外就已有元件的修改，可以要求逐漸改進，使用橋接或其他方式逐個替換進新的子產品。

　　很晚了，先就想到這了，歡迎大家提出好的想法。到時我再抽時間補充完整。