● 預(yù)先行其事，必先利其器。用軟件武裝團(tuán)隊提高生產(chǎn)效率，例如：版本控制，錯誤跟蹤，信息發(fā)布，自動發(fā)布，CASE工具，調(diào)試工具，測試工具，文檔管理，代碼生成工具等等。

　　● 分析項目類型，在管理和構(gòu)建之間找尋平衡。商業(yè)系統(tǒng)、使命攸關(guān)的系統(tǒng)、性命攸關(guān)的系統(tǒng)在整個項目階段具備不同的控制粒度。需要根據(jù)項目的具體類型來確定管理的嚴(yán)謹(jǐn)程度，避免“過度控制”或“控制不足”。

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

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

　　在構(gòu)建期間處理需求變更

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

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

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

　　4、使用能適應(yīng)變更的開發(fā)方法：迭代與增量。

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

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

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

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

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

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

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

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

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

　　● 總結(jié)經(jīng)驗教訓(xùn)。必須對階段進(jìn)行經(jīng)驗教訓(xùn)總結(jié)，沒有什么比這些收獲更有價值。這樣文檔是組織的資產(chǎn)，是以后類似項目的參考和依據(jù)，并在持續(xù)優(yōu)化方面發(fā)揮更為重要的作用。

　　● 不要讓會議和文檔拖了團(tuán)隊的后腿！爱(dāng)船快要沉的時候，我們需要的是一個發(fā)號施令的，而不是開會！避浖椖康暮诵膯栴}是降低復(fù)雜度，越是復(fù)雜的項目越需要溝通，但別讓開會拖了我們的后腿。沒有必要的會盡量少開或不開，要常開會，開小會，每次會議幾個相關(guān)干系人碰頭溝通下可以了，沒有必要擴(kuò)大為全員參與。冗長的討論應(yīng)該適時的終止，畢竟會議室上只能做出決策，而解決問題還得在會下。所以我認(rèn)為應(yīng)該精簡那些冗長的會議，別然開會成為我們的工作。此外，要時刻謹(jǐn)記客戶終需要的是可以良好運行的軟件產(chǎn)品而不是華麗的文檔。所以，文檔要恰到好處，寫的再漂亮的文檔沒有完備的系統(tǒng)也不過是廢紙一堆，別丟了西瓜撿芝麻，可以正常工作的軟件才是我們的工作重心。

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

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