定義有麻煩的項目
首先，我們來定義一下什么叫有麻煩的項目，它們一般具有以下特征：
1、項目表面上已經進入后期，但是沒有人能說出項目結束時間。
2、產品漏洞百出。
3、管理層已經無法控制進度，制定的進度計劃沒有半點準確性。
4、開發人員日夜加班，效率低下。
5、項目小組的
士氣極度低落，失去了工作的激情。
像這樣有麻煩的項目在行業內普遍存在，如果不采取一些措施來修復的話，項目注定會失敗，什么是失敗？失敗項目的成本、工期遠遠超過估算，甚至項目被取消。作為項目經理，項目的負責人，我們有什么方法可以把這些有麻煩的項目拉向正軌呢？本人前一段時間親身經歷過一個像這樣的有麻煩的項目，讀過《快速軟件開發》一書后，其中的“項目修復”一節使我受益非淺，成功的把項目拉向了正軌，本文在參考《快速軟件開發》一書的基礎上介紹一些實用的項目修復方案。
修復項目
修復項目有三個最基本指導思想：
1、篩選需求，縮減項目規模。
2、注重短期的過程改善。
3、面對現實，放棄原計劃，著手制定新的計劃。
對于一個有麻煩
項目，很多人都還把注意力放在如何趕上原計劃上，這樣的項目，最重要的是怎么完成，完成！不要再幻想出現什么轉機，項目已經有了麻煩，和原計劃已經有了出入，所以，我們應該面對現實，把當前的事情做好。
如果你想改變項目的現狀的話，動作一定要大一點，小打小鬧的改變不足以改變現狀，小打小鬧在公司高層眼里意味著什么？意味著你并沒有什么辦法來修復項目。
下面詳細說明修復項目的措施：
第一步要做的
1、分析自已的處境
評估一下項目的最后期限到底有多重要，或許項目本身就不存在硬性的完成期限，這樣的話，你就不必擔心項目修復是否成功了。還有，有這個時候，公司上層或者是客戶為了避免項目嚴重延期，會和你商討一些功能上的取舍。
2、客觀分析
為了在現有的基礎上成功，項目組需要做什么？公司上層需要做什么？客戶需要做什么？過去的都已經過去了，關鍵要著眼于現在。
3、自已要做好項目修復的準備
如果你的項目處于修復狀態下，而且落后的不是一點半點。那么你要意識到你的項目已經支離破碎了，必須有一些大的舉動來挽救，讓所有人都知道要對項目采取一些措施來修復。
4、爭取多方意見
詢問一下你的開發組、你的其它同事、你的領導等所有了解項目的人，有什么方法可以使項目走向正軌。
5、面對現實
有麻煩的項目組需要一個客觀的、現實的項目經理。項目修復剛開始，你不要再向任何人承諾項目的完成日期，不要再陷入：“迫于壓力的承諾－>更大的進度壓力->更多的錯誤->更加偏離計劃”這樣的死循環。你應該用幾天的時間去認真分析一下項目，再給出一個客觀、準確的計劃。
影響項目成本、進度的四大因素：人員、過程、產品（功能集）、技術。在項目后期，在技術這一因素上已經沒有多大的改進余地。我們在此討論針對其它三個因素的改進措施。
人員
人員是影響項目進度最重要的因素，我們應該在這個因素上下最大的功夫。
1、采取一切措施來恢復開發人員的士氣
兵戰者，求勝于勢，恢復開發人員士氣對于項目修復的成敗起著決定性的作用。恢復開發人員士氣的最佳方式是做一件很明顯的事情讓他們知道公司已經把他們放在了首位，比如說，完成任務可以提前回家，在不影響進度的前提下允許他們請假等等，當開發人員意識到自已受到了重視，項目組士氣自然會得到提升，提升士氣的方法很多，可以根據實際情況來選擇恢復士氣的方法，其實有時候領導的一句話就足以恢復整個項目組的士氣。
2、消除重大的人員問題
如果你覺得項目有一位有問題（不合作，難以溝通等）的員工，那么就請勇敢的面對這個現實。即使他現在起著關鍵性的作用，也要毫不猶豫的撤掉他，這些的員工對項目組士氣的影響要大于他在技術上的貢獻。
3、增加新成員要謹慎
雖然有一句話叫作：“向一個已經延誤工期的項目上增加新成員無異于火上澆油”。但是如果能把項目組的任務分解到新成員并不影響原有開發人員的話，就不存在“澆油”的問題。不過你要考慮到新成員很可能用8小時的時間去完成原有開發人員用1小時所能完成的任務，這樣的情況出現后，你是否能維持與管理層的關系，因為管理層極可能不會容忍一個人用8小時的時間去完成1小時的工作。如果你無法妥善處理這樣的后果的話，那么就不要增加新的人員。
4、充分利用開發人員的時間
在項目修復模式下，你要盡可能的充分利用現在開發人員的時間，因為他們已經對這個項目非常熟悉。打算增加新開員的成本，還不如用在提高現有開發人員的效率上。
5、觀察開發人員的節奏
千萬不要讓開發人員陷入“進度壓力—更多的缺陷－更多的工作量－更大的進度壓力”這樣的循環里面，給他們足夠的時間，讓他們能考慮一下質量問題，這樣的話進度就自然而然的加快。
過程
雖然是人員是影響項目進度的最為重要的因素，但是如果想成功修復項目的話，用心整理一下過程也是必需的。
1、修復支離破碎的過程
項目一遇到麻煩，大家通常都知道是開發過程哪一個環節出現了問題，其實，出問題的環節一定是忽略了軟件開發最基本的東西。
如果缺陷管理困難，就搭建一個缺陷管理系統；如果開發人員得不到及時的任務分配，那么就放更多的精力于各開發人員的任務完成狀態上，可能你做更多的工作以保證任務的及時分配；如果開發人員的代碼質量總是難以保證，那么就加入代碼審核過程。
2、創建詳細的小型里程碑
在項目修復模式下，一定要建立一個項目跟蹤機制，以便于實時了解項目的狀態。
小型里程碑可以讓你每天都能看到項目進度是否在按著計劃進行。小型里程碑有三個特點：1)小型性2)二元性3)徹底性。小型性指每個里程碑必須在一兩天之內可以完成；二元性是指里程碑要么就完成，要么就沒有完成，不存在“差不多完成”、“完成了90%”之類的情況；徹底性是指當你完成了最后一個里程碑時，項目也就完成了，不存在你所建立的進度表之外任務，如果還有其它任務，那么就把它加進來。
創建一些沒有太大意義的小型里程碑有助于提高項目組的士氣，人都是這樣，快速完成一個任務心里總會感到愉快，即使這個任務不是那么重要。
在項目初期是不適使創建小型里程碑的，因為那個時候你對所要做的工作了解的詳細程序還不夠。但是項目修復模式下，每個人都清楚的知道項目還剩下些什么。
3、依據里程碑的完成來安排進度
為每一個里程碑設立完成日期。不要再打加班的主意，完成日期必須是在沒有考慮加班的情況下設立的。每一天任務的完成保證了，才有每一個月的保證，最后也會保證項目的成功。
4、細致的跟蹤項目進展情況
創建了小型里程碑，但如果不跟蹤實際進度的話，就沒有一點兒實際意義。每天都要檢查里程碑的完成情況，一定要確保標記為“已完成”的里程碑是百分百完成了，如果把“99%完成”的里程碑標記為已完成，就會打亂你的計劃，你所能對項目控制的程度也會越來越弱。
絕對不能讓開發人員在小型里程碑進度上偏離正軌，如果誤了里程碑，并不加以改正，項目很容易偏離正軌。晚了1天的任務有可能會晚2天，晚2天就會晚3天，接下來項目實際進度就和計劃完成脫節了。如果一個開發人員在里程碑上落后了，就讓他當天加一下班，以趕上進度。如果是計劃制定的有問題，那就要及時的修正它。
5、記錄延誤里程碑的原因
如果一個里程碑延誤了，一定要延誤原因記下來，這樣可以幫你發現潛在的問題。
6、短期后修正
每1、2周都要對計劃的里程碑進行修正，如果完成開發人員用5天的時間完成了3天的任務，而且沒有可以改進方法的話，那么就把剩下的工作量乘以5/3，千萬不要幻想著你能在以后的時間里把以前落下的任務補回來。
7、在得出有意義的進度前不要固守著某一個
在計劃/進度表沒有達到非常準確的情況下，不要急著把它交給領導過目，一個良好的進度/計劃肯定是在從制定到跟蹤，從跟蹤到修正，再跟蹤、再修正這樣的循環中得出的。
8、勤快的進行風險管理
產品（功能集）
產品的功能沒有管理好，那么項目修復就是不可能的
1、穩定需求
在項目修復模式下，首先穩定需求是最為重要的任務，如果在這個時候需求還是頻繁化的話，那么你就不用考慮其它修復手段了，花時間去穩定它。很多項目都是在后期還不確定究竟要完成哪些功能，這樣的項目注定是要失敗的。
2、修正功能集
毫不猶豫的把那些優先級較低的功能、特性剔除掉，一定要根據優先級來完成任務。
3、去除沒有用的垃圾
如果一個模塊質量極其低下，改了又改，bug還是不斷涌現，那么就從把這個模塊的代碼去除掉，重新設計它，不要讓一堆無法控制的缺陷把項目拖死。
4、持續降低缺陷數目
功能、特性可以權衡，質量是不可以權衡的，項目管理三角形：成本、進度、功能。三角形里并沒有質量這一角，不要為了追趕進度而在質量上做手腳。
參考書目：
《快速軟件開發－有效控制與完成進度計劃》?? 電子工業出版社