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