軟件項目延期的應對策略

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