軟件項目延期的應對策略
發布時間：2016/11/23 10:03:00
項目組在試運行即將結束的階段，用戶對兩個比較大的模塊提出改進意見，這就意味著項目組要多花至少半個月時間來重新做，面臨正式運行的期限，項目延期幾乎是必然的。項目已經完成過半，項目的期限馬上就要到了，但是PM在日常績效審核(績效審核是反應項目組效率的非常客觀直接的一種方式)中發現整個項目組制訂的計劃的執行越來越拖拉，原來一個星期內做好的事情，現在兩個星期了還沒有完成，這樣下去，隨時有項目失敗的危險。
因為項目要延期，個別人在項目組里面擔心自己的利益受損，在項目的比較關鍵的時刻怠工，以此作為籌碼想讓項目組滿足他自己的一些私人利益，為了達到目的，曾經還與其它的相關成員進行了協商，這樣很多項目組的成員也與他一道來對抗。根據上述內容進行了深刻的分析：分析一：項目組的每一個人都擔心項目失敗，這樣肯定會很大程度上影響個人利益，而并不是對項目組的其他人有看法。項目發生變動以后，項目主管并沒有及時的把部門和用戶的真實用意與所有項目組成員及時溝通，導致大家紛紛猜測，并且很可能被一些別有用心的人利用了這種情緒。分析二：這里面也的確有個別別有用心的人為因素，這個問題一定的及早處理，否則它會攪得整個項目組不得安寧。
經過分析，找到問題根源，首先得解決溝通的問題。這包括與用戶、部門領導、項目組成員之間的溝通。
1)PM(PM培訓)與最終用戶溝通：把用戶的更改要求和我們的理解與用戶進行了更加細致的溝通確認，讓用戶認識到我們非常在意他們的意愿，但是按照原來的方案更改的話，項目正式運行時間至少要延期半個月，其實這個風險對用戶方的影響也很大，最終項目組與用戶達成了折中的方案：項目組在正式運行的時候，只是更改那些工作量不是非常大的但是不解決無法讓用戶方領導滿意的問題，而對于其它的問題，都放在正式運行之后一直到驗收這段時間來完成。其實，當時用戶并沒有想得非常多，只是想盡量盡早的把所有的工作提前做完，也并沒有認真考慮到很多工作需要耗費大量的時間和精力而導致整個項目拖延而影響到他們自己，而這些工作大部分并不是那么要緊。經過第一次溝通以后，項目組成員對于項目的問題和期限有了更加清晰的認識，已經能夠感覺到其實用戶并非是故意難為項目組，項目即使延期，對項目整體的影響并不大。
2)PM與部門領導溝通：把項目需求變更可能導致延期的問題和原因進行了匯報，隨即在項目例會中，部門領導對項目組的整體成績給予了肯定，對項目組的優秀人員給予了口頭表彰，對個別的非常懈怠的員工也提出了一定的批評。終于，項目組內部的種種猜疑都基本上結束了，用戶方和部門內部對于項目的問題都有了比較清楚的認識，項目組的成員也都明白：項目雖然有困難，但是還是會成功結束的，每一個人的利益其實并不受什么影響。
3)PM與項目組內部溝通：溝通的問題解決以后，還是有個別渙散軍心的人繼續做一些對項目不利的事情。但是這個人在項目組中又比較重要，如果輕易的在項目組中去除，很多比較關鍵的工作就沒有人負責了。為了避免這個人籠絡更多的人，最后掌握更多的要害來要挾項目組而造成更壞的結果，當時在項目組中專門制定了“代碼同行評審”的制度，每天抽出一點時間對于項目中比較共性的設計、代碼進行相互評審，這也是一個相互學習的過程，對于表現比較好的個人記入績效，予以表彰。
當項目后期這個人離開的時候，項目組中的其它兩個人已經可以接手他的工作了。這不但讓每個人都有更多機會了解學習他人，也給每個人提供了更加好的展示自己的舞臺，大大激發了大家學習進取的積極性。這樣不但更好的保證設計與編碼的一致性以及好的設計、代碼的復用性，而且大大降低了個別人的變動對整個項目組的影響。然后項目組決定把渙散軍心的人的地位抬高到系統設計師的地位，而把具體的工作不斷的拆分給那些比較好學的其它人員手中。(項目管理者聯盟)
更多內容詳細咨詢：http://mfeineon.cn/