最後期限是每個項目經理都繞不過去的坎兒。
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或改進需求，項目組進行預估並提交估算文檔，客戶批准文檔後確定最後期限，項目組必須按期發佈。項目組傾向於估算得較長，這樣可以多收錢，當然也要通過客戶審覈才行。偶爾出現需求不清，估算太短的情況就只能打落牙往肚裏吞了。
項目組有無數的規範，並傾向於制定更多。項目組中問責文化流行，相互責任推脫更成爲家常便飯，無論是員工還是客戶都疲憊不堪。