● 預先行其事，必先利其器。用軟件武裝團隊提高生產效率，例如：版本控制，錯誤跟蹤，信息發布，自動發布，CASE工具，調試工具，測試工具，文檔管理，代碼生成工具等等。

　　● 分析項目類型，在管理和構建之間找尋平衡。商業系統、使命攸關的系統、性命攸關的系統在整個項目階段具備不同的控制粒度。需要根據項目的具體類型來確定管理的嚴謹程度，避免“過度控制”或“控制不足”。

　　● 需求必須被凍結。需求必須被凍結，如果需求不能凍結，那么誰來了都沒有用。再強的團隊也無法完成一個無盡的任務。

　　● 變更必須走流程。正確應對變更，變更并不可怕，可怕的是失控的變更。以下建議希望對讀者有所幫助：

　　在構建期間處理需求變更

　　1、核對需求，評估質量：如果需求不夠好，停下來，把它做好再開始。

　　2、確保每一個人都知道需求變更的代價：讓客戶知道需求辦更并不像在Excel上進行幾個修改那樣容易，“進度”和“成本”是你有力的武器。

　　3、建立一套變更控制程序：固定的變更控制程序讓你知道在什么時候處理變更，讓客戶知道你會處理他們的提議。

　　4、使用能適應變更的開發方法：迭代與增量。

　　5、放棄這個項目：如果以上提議沒有一條奏效，需求變更極其頻繁，那么，評估你的項目，考慮放棄它吧，繼續下去你只會越陷越深。

　　6、注意項目的商業案例：性價比，沒必要滿足超出項目成本的需求。

　　● 關于加班。做IT的加班是很正常的，但加班要加的有意義，而且不應該長期加班。必須針對關鍵路徑上的工作進行趕工，而不是做些無法加快整體進度的工作。而且，應當安排調休，而不是支付加班費。其主要原因也是我不贊成加班的原因??疲勞更容易引人缺陷。加班無疑會使人疲勞，每個人都想盡快結束手上的工作后回家休息。在長期疲憊的情況下，人員的工作效率會下降，士氣會低落，非正常離職率增加，重要的是疲憊的團隊很難保證軟件的質量，缺陷在不知不覺中引人，在后期無疑會為此付出代價。項目的總成本和周期，都會隨著引人缺陷的數量的增加而倍增，而且發現的越晚越嚴重。

　　● 做好版本控制和配置管理。版本控制和配置管理是必須有的，即便是再小的項目也不能忽視，必須加以重視，一旦版本混亂，多多少少會對構活動造成影響。所以，平時不要偷懶，管理好每個基線。

　　● 授權的好處。授權好處多多，包括：一，減少管理者工作量；二，對人員有意識地進行鍛煉，培養儲備人才；三，提高人員對項目的參與度，從而提高士氣。

　　● 樂觀管理與悲觀管理。樂觀與悲觀完全取決于人的性格，一般來講多數傾向于樂觀，應該清楚這兩種性格在項目中的優勢與劣勢。我本人傾向于悲觀，可能是性格使然，但悲觀的管理至少不會誤事。樂觀管理的優勢在于，很容易營造氣氛，擅長給客戶或領導描繪一個美好的未來。這種作風，前期很舒服，但后期可能要吃苦了。樂觀管理容易出現的問題是對風險的預計不足，不能預留充足的緩沖時間，沒有準備足夠的預防措施。其表現是，在進行進度計劃時，總是認為的問題可以解決，已經修復的BUG將不會再次出現，用戶需求是后一次變更，等等諸如此類的樂觀想法會使管理者蒙蔽雙眼，而沒有做足風險應對，其結果是不管怎么加班是趕不上進度，因為進度計劃被設計為順利的情形，而不是現實場景。悲觀管理的好處是，為潛在風險做足了準備。但悲觀管理有一個非常大的缺陷，是“過度控制”，可以比喻為“疑心病”（小心的都有些病態了）。其表現是為：按照之前的措施，發現遺漏了一個問題，那么悲觀管理者會在之前措施基礎上增加新的保障措施，然后又發現遺漏了一個問題，之后會繼續追加保障措施。乍看之下沒啥問題，因為是在不斷地進行過程改進，但問題出在保障措施的增長速度過于驚人，稱其為“疑心病”一點也不為過，悲觀管理者容易在很小的地方施加過多的控制，造成人日的浪費，而忽略掉本應該關注的更為重要的問題。不管那種性格的管理，清楚自己的弱點總是好的。

　　● 有效的溝通，不要踢皮球。軟件項目因為其本身的復雜度和涉眾眾多，所以更加需要溝通。溝通問題是所有大型項目都共用的問題，在大多數團隊中往往也不認為溝通是個問題。但我還是想請讀者認真對待溝通，比如郵件。郵件可以回復的慢，但請回復郵件。當我在一個連發出的郵件都沒人回復的團隊中工作時，除了無法解決問題，讓我感受到的只有無奈以及冷漠。

　　● 客戶是我們的朋友。把你的客戶當成朋友，客戶是我們做重要的資源之一。在每個客戶背后往往隱藏著更多潛在的客戶。我們必須清楚，客戶作為非專業人士，其可能并不理解我們的工作，在項目執行階段產生摩擦是難免的。但是，這些都不能成為我們遷怒客戶或故意在工作中放水的借口。即便是為了項目能成功收尾，我們也必須維護好與客戶的關系。

　　● 不要超前設計，不要項目鍍金。超前設計和項目鍍金都是不可取的，因為他是在浪費資源。滿足需求以外的東西，不會對你的項目有任何好處，但是卻可能引人缺陷。

　　● 總結經驗教訓。必須對階段進行經驗教訓總結，沒有什么比這些收獲更有價值。這樣文檔是組織的資產，是以后類似項目的參考和依據，并在持續優化方面發揮更為重要的作用。

　　● 不要讓會議和文檔拖了團隊的后腿。“當船快要沉的時候，我們需要的是一個發號施令的，而不是開會。”軟件項目的核心問題是降低復雜度，越是復雜的項目越需要溝通，但別讓開會拖了我們的后腿。沒有必要的會盡量少開或不開，要常開會，開小會，每次會議幾個相關干系人碰頭溝通下可以了，沒有必要擴大為全員參與。冗長的討論應該適時的終止，畢竟會議室上只能做出決策，而解決問題還得在會下。所以我認為應該精簡那些冗長的會議，別然開會成為我們的工作。此外，要時刻謹記客戶終需要的是可以良好運行的軟件產品而不是華麗的文檔。所以，文檔要恰到好處，寫的再漂亮的文檔沒有完備的系統也不過是廢紙一堆，別丟了西瓜撿芝麻，可以正常工作的軟件才是我們的工作重心。

　　● 核對表的你的好助手。像飛機工程師在檢查飛機時使用核對表一樣，軟件項目也可以大量使用核對表。核對表可以幫助檢驗文檔的質量，降低缺陷數量，以及改進項目管理。好的核對表，是你工作中的好助手。

　　● 小范圍的受控好過大范圍的失控。要注意控制的粒度，事無巨細。根據項目規模，人員構成，要采用不同的控制粒度。評估可控范圍，并不是控制越廣越好，控制不了是失控。 對無暇顧及的地方授權別人管理是個可行的做法。 即便是小范圍是受控，也好過大范圍的失控。一個失控的項目，誰也不知道其會走向何方。