借助各種手段，創(chuàng)造良好的溝通環(huán)境
在一般人的眼里，技術人員都普遍比較孤傲，不好管理。主管不僅僅要掌握良好的溝通技巧，還要擅于感情交流，幫助解決項目組成員工作上和生活上的實際困難，使他們集中精力干好本職工作。良好的上下級和同級關系創(chuàng)造了融洽的工作氣氛，尤其是有了這個良好的氣氛以后，每個人不但清楚的知道自己工作的進展，還能夠了解其他人和整個項目的進展，沒有人甘心落后，項目成功的可能性大大增加。
創(chuàng)造這種溝通環(huán)境有很多辦法。首先在技術層面上可以建立一個項目組內部的信息收集發(fā)布平臺，使得項目干系人都能隨時掌握自己關注的項目情況，這個平臺利用好以后，還能夠使大家共享很多技術信息，大大降低重復勞動造成的浪費。簡單的溝通環(huán)境可以采用E_Mail系統(tǒng)，復雜一點的可以采用比較專業(yè)的工具，例如PVCS、微軟PROJECT2000、IBM/Lotus QuickPlace等，這些的工具結合起來，不但提供簡單的信息收集發(fā)布功能，還能幫助項目組成員更好的協(xié)作。
其它的交流方式可以采用會議、頭腦風暴等手段。這些會議可以是不定期的，也可以是定期的項目例會，通常項目例會是非常必要的，頻率根據(jù)項目的不同而不同，一般一個星期左右為宜，這些溝通活動氣氛要相對輕松，但是效率非常重要。
總而言之，建設好項目團隊，保證項目成員的活力和士氣而能夠充分發(fā)揮每一個人的主管能動性是貫穿整個項目的復雜的管理活動，尤其是比較大一點的項目涉及人員比較多，人員之間的關系通常也比較復雜，這項工作更顯得重要了。
三、案例分析
問題
在以前的項目中，筆者曾經遇到過這樣的事情：項目已經完成過半，項目的期限馬上要到了，但是我在日�？冃徍耍ǹ冃徍耸欠磻椖拷M效率的非常客觀直接的一種方式）中發(fā)現(xiàn)整個項目組制訂的計劃的執(zhí)行越來越拖拉，原來一個星期內做好的事情，現(xiàn)在兩個星期了還沒有完成，這樣下去，隨時有項目失敗的危險。
原因
發(fā)現(xiàn)這件事情的時候，我感覺到這是一件非常嚴重的事情必須很快處理，否則后果不堪設想，在請教了一些有經驗的項目主管甚至人力資源主管以后，發(fā)現(xiàn)這種情況表面上是由以下兩個原因造成的。
1．項目很可能要延期。當時項目組為了避免移交的時候產生太多風險，在項目正式移交前一個月給用戶提交了一個beta版本，結果出乎意料：用戶覺得我們其中兩個比較大的模塊與用戶想象的大相徑庭，不滿意。這意味著項目組要多花至少半個月時間來重新做，項目延期幾乎是必然的。
2．個別人怠工。因為項目要延期，個別人在項目組里面擔心自己的利益受損，在項目的比較關鍵的時刻怠工，以此作為籌碼想讓項目組滿足他自己的一些私人利益，為了達到目的，曾經還與其它的相關成員進行了協(xié)商，這樣很多項目組的成員也與他一道來對抗。
現(xiàn)在想起來，當時虧得對項目的進展每兩天檢查一次，發(fā)現(xiàn)問題比較早，否則要是這個問題再晚發(fā)現(xiàn)一個星期，恐怕好多項目組成員已經離開了，項目肯定會失敗。其實這個問題的本質原因有兩個：第一，項目組的每一個人都擔心項目失敗，這樣肯定會很大程度上影響個人利益，而并不是對項目組的其他人有看法。項目發(fā)生變動以后，項目主管并沒有及時的把承包商和用戶的真實用意與所有項目組成員及時溝通，導致大家紛紛猜測，并且很可能被一些別有用心的人利用了這種情緒。第二：這里面也的確有個別別有用心的人為因素，這個問題一定的及早處理，否則它會攪得整個項目組不得安寧。
解決方案
問題根源找到以后，首先得解決溝通的問題。這包括用戶、承包商總體負責人、項目組成員之間的溝通，項目主管盡快找到終用戶，把用戶的更改要求和我們的理解與用戶進行了更加細致的溝通確認，讓用戶認識到我們非常在意他們的意愿，但是按照原來的方案更改的話，項目至少要延期半個月，其實這個風險對用戶方的影響也很大，終項目組與用戶達成了折中的方案：項目組在第一次移交的時候，只是更改那些工作量不是非常大的但是不解決無法讓用戶方領到滿意的問題，而對于其它的問題，都放在第一次移交一直到維護期結束這段時間來完成。其實，當時用戶并沒有想得非常多，只是想盡量盡早的把所有的工作提前做完，也并沒有認真考慮到很多工作需要耗費大量的時間和精力而導致整個項目拖延而影響到他們自己，而這些工作大部分并不是那么要緊。經過第一次溝通以后，項目組成員對于項目的問題和期限有了更加清晰的認識，已經能夠感覺到其實用戶并非是故意難為項目組，項目即使延期，對項目整體的影響并不大。緊接著，項目主管找到了承包商的直接負責人，把項目需求變更可能導致延期的問題和原因進行了匯報，隨即在項目例會中，承包商的直接負責人對項目組的整體成績給予了肯定，對項目組的人員給予了口頭表彰，對個別的非常懈怠的員工也提出了一定的批評。終于，項目組內部的種種猜疑都基本上結束了，用戶方和承包方對于項目的問題都有了比較清楚的認識，項目組的成員也都明白：項目雖然有困難，但是還是會成功結束的，每一個人的利益其實并不受什么影響。
溝通的問題解決以后，還是有個別渙散軍心的人繼續(xù)做一些對項目不利的事情。但是這個人在項目組中又比較重要，如果輕易的在項目組中去除，很多比較關鍵的工作沒有人負責了。為了避免這個人籠絡更多的人，后掌握更多的要害來要挾項目組而造成更壞的結果，當時在項目組中專門制定了“代碼同行評審”的制度，每天抽出一點時間對于項目中比較共性的設計、代碼進行相互評審，這也是一個相互學習的過程，對于表現(xiàn)比較好的個人記入績效，予以表彰。這不但讓每個人都有更多機會了解學習他人，也給每個人提供了更加好的展示自己的舞臺，大大激發(fā)了大家學習進取的積極性。這樣不但更好的保證設計與編碼的一致性以及好的設計、代碼的復用性，而且大大降低了個別人的變動對整個項目組的影響。然后項目組決定把渙散軍心的人的地位抬高到系統(tǒng)設計師的地位，而把具體的工作不斷的拆分給那些比較好學的其它人員手中。果然，當項目后期這個人離開的時候，項目組中的其它兩個人已經可以接手他的工作了。
看來在項目管理中重視文檔以及公共知識的管理，并且能有很好的溝通環(huán)境，可以大大降低項目進程中的人為風險，并且，有了更加客觀的績效標準以后，能夠塑造出更合理的環(huán)境，更好的保證成員的積極性。
