新手軟件項目經理之最后期限的迷局
***期限是每個項目經理都繞不過去的坎兒。
1. 小故事
張莉是新鮮出爐的項目經理。在二月底春節后，張莉開始了C項目，C項目是一個大項目的組成部分。三月初，領導確定大項目的交付期限是4月中旬。張莉愁壞了，項目的流程、人員、技術等等都是全新的，她完全沒有把握保證項目的交付。導師張三給她出主意，不妨先接受領導4月中旬交付的目標，但是將目標進行分解，每半個月檢查一下能否達成目標。張莉每半個月向領導匯報實際的進度和遇到的障礙。4月中旬，C項目也沒能如期完成，整個大項目沒有如期完成。領導提出了新的***期限，5月中旬，轉眼5月中旬就要到來，但是C項目又被卡住了，***期限無法達成。
2. 常規想法
***期限讓我想起了一個經典的問題。如果你是項目經理，現在項目組沒有能力在***期限前完成工作，你是：
1. 優先確保項目，犧牲人
2. 優先確保人，犧牲項目
3. 項目與人兩者兼顧
對大多數項目經理而言，項目是他服務的主要對象，當然是優先確保***期限的達成了，加班就成了一種常見的手段。當然，這也是很多老板們的***，尤其是在不用付加班工資的時候。于是項目緊迫，加班不斷成了IT業的常態。
3. 繼續思考
的確存在***期限，把加班作為一種有效的備選，偶爾用用是合適的。但是把項目與人對立的想法其實是可笑的。所謂項目和***期限，無非是客戶、老板或者市場人員的期望而已，依然是人的問題。
不合理的***期限往往體現成一種問責文化，最終會導致局部優化。項目中的成員只對自己的范圍負責，完成了自己的工作就安全了，整個項目沒有完成也是別人的問題了。在***階段出現問題的時候相互推諉，害怕承擔責任。最終會損害項目完成的質量，并且導致團隊士氣低迷。
不合理的***期限還導致溝通的減少。人們傾向于使用文檔來明確范圍和責任，從而導致更多的文檔工作。而利用文檔作為主要溝通工具將導致大量的誤會，從而造就大量的浪費。所以結果是項目越來越慢。怎么辦呢？簡單，領導為了改變這種情況，會提出新的***期限給項目團隊加壓，從而導致更多的加班。上述的C項目中，領導試圖制定***期限加速產品的開發，***并未能達成目標。
4. 參考案例
4.1 參考案例1
這是我創業時真正意義的***個項目。新技術、新產品、***次項目實施等諸多新情況導致上線時，整個進銷存系統僅有出庫單可以工作，而且內部的賬務數據還是錯誤的。怎么辦？***期限已經來臨，只有硬著頭皮上線。我們整個團隊駐扎在客戶現場，有時甚至通過手工修改數據的方式來保證客戶業務單據（僅一張出庫單）可以使用。好不容易熬到下班，團隊還必須加班處理整個過程中暴露的問題，并且準備客戶將要使用的新功能。客戶的中層和基層人員抱怨連天，好在領導還在堅持（領導后來說，當時也是麻起膽子）。整整一個月時間，加班加點，經常通宵，項目終于能夠正常運轉（從外部看不出什么問題，內部的數據還有很多問題）。
這個客戶后來成為了公司最堅定的客戶，在維護和升級過程中合作良好。當然***期限不能達成失敗例子更多，這里不一一列舉。
4.2 參考案例2
C項目采用Scrum方法學進行開發，早早的確定了***次發布的***期限和需發布的主要功能。隨著時間一天天的臨近，項目組的開發進度不如預期。產品負責人和團隊商量，原有主要功能不變，但是功能的實現方式盡量簡化，以減少工作量。即便如此，***次發布前項目團隊依然加了兩次班，并且減少了平時的交流，專注于功能實現和Bug修復。終于產品還是順利發布了。發布后，項目組改回了正常的工作方式，并且花了一些時間清理因為要盡快發布而導致的技術負債。
4.3 參考案例3
R項目是一個持續了很多年的項目，本質上是在一個大的系統上修修補補，優點是客戶按照工作時間來付錢。其工作方式是客戶提出Bug或改進需求，項目組進行預估并提交估算文檔，客戶批準文檔后確定***期限，項目組必須按期發布。項目組傾向于估算得較長，這樣可以多收錢，當然也要通過客戶審核才行。偶爾出現需求不清，估算太短的情況就只能打落牙往肚里吞了。
項目組有無數的規范，并傾向于制定更多。項目組中問責文化流行，相互責任推脫更成為家常便飯，無論是員工還是客戶都疲憊不堪。
原文鏈接：http://www.cnblogs.com/davidzhang33/archive/2011/05/10/2042151.html
【編輯推薦】
