項目管理之力挽狂瀾
有些項目總是很“難搞”，例如，對一些新領域的項目，因爲與客戶有關係，所以就接下來了，在項目啓動後，由於對項目的範圍沒有確定，導致項目的需求總是在變化，項目週期一再延期，用戶也不滿意，公司項目小組也很累，成本也很難控制！這樣的所謂“爛”項目到了中後期如何進行項目管理？
其實，這樣的項目是我們經常會遇到的一些項目，項目啓動的時候項目範圍不清，過程中業主和開發者關係緊張難以協調。或許做過IT政府大型項目的人對這些情況都不陌生。我不想談這樣的項目有如何的不好、如何的難以管理，
以及如何的沒有在開始的時候確定範圍等，我只想談談項目在此時此刻的生存環境下，如何管理和溝通，盡最大的努力來完成作爲項目組層次上的項目管理應該做的事情。（此爲親生經歷的一個項目，反思如下）：
1、鼓舞項目團隊的士氣。項目進行到這個層次，項目組成員的感受是最不穩定的。這個時候很多項目組成員對項目出現絕望的情緒，甚至影響到項目進一步工作開展中來。這個時候項目組管理者一定要注意緩解這種情緒的蔓延，要鼓舞士氣。
2、項目長期的範圍和目的不明確的情況下，要多和業主溝通，同時注意溝通的效率和頻次。如果可以和最高決策層溝通就直接溝通，當然溝通的時候需要準備的是完整的系統方案。對應的需求方案可以不拘泥於規定的格式，但是一定要利於理解。根據受衆的不同而調整需求方案。另外對項目需求管理要做一個動態控制的計劃。不能指望一次就可以做好整個系統，而是根據需求確定的程度來步步推進，動態控制需求及變更，過程中一定要將業主方的技術和業務負責人及項目關鍵干係人引入到你需求變更控制流程中來。
3、項目進行過程中或許已經出現了這樣那樣的問題，但是對於科學的管理依然要堅持。項目管理中有很多很好的工具和方法，不能因爲項目出現問題而擯棄。我看到很多項目經理都會有這樣的想法：只要我交出的東西ok，其中的過程你不用理會。這樣的想法是錯誤的。行業裏一句話講：上乘的項目管理是效果和過程都實現好，中乘的項目管理是效果好但過程馬虎，下乘的項目管理是效果不好過程ok，失敗的項目管理是過程效果都沒有。我想這個項目進行到這個程度，作爲項目組層次的管理者來說一定要認清形勢，在這個時候項目的結果很好已經不是我們最終可能或者追求的結果了。但是注重管理過程也許就要提到一個更加重視的程度。管理過程既可以反促進項目結果，又可以提高客戶對此項目的滿意度，減少不滿程度。
4、採取迭代型開發，合理分配資源來達到項目的最終結果。
總之，如果我們能盡最大的努力保證項目的完工，交一份中下乘項目管理答卷，無論從客戶還是企業的角度來說這樣的項目就算成功了。
感悟：項目生存於一個更大的環境中，例如項目的商務環境、項目規模、客戶成熟度、客戶關係、客戶滿意關鍵點等等；而它自己內部由人員、技術、風險、成本等個體組成。比如範圍，通常在政府IT項目中，範圍有兩個難點，一是範圍不確定，而是範圍變化頻繁。你要求自己都不清楚想要什麼內容的客戶提供清晰的功能描述，以此來規避在進度和成本上的風險，不現實。
——時光荏苒，一轉眼從2010年來到了2012年，這一年接手了一個非常難弄的項目（產品）。
背景爲該產品有一定的技術難度，且產品經理比較喜歡鑽牛角尖，我是中途接手該項目（原PM由於種種原因離開了）。
我進入的時候，根據觀察和調查，發現存在以下嚴重的問題：
§bug居高不下；
§團隊士氣非常低落；
§與客戶溝通成本奇高：每天都舉行bug review（按規定是每週一次），每次至少2小時
§在結案前新需求頻繁
我知道，考驗我的時候又到了。我只有一個念頭，把這個項目正常的release。這個時候，需要冷靜、要拿出毅力和韌性，並且給出對應的solution。
我的具體對策如下：
一、找原因
1、分析bug並分類，這樣找到產生的根本原因
§由於需求和設計不當引起的bug；
§大部分bug是由極少數幾個模塊產生
§修改舊bug引起的新bug
2、團隊士氣低落的原因
§工作毫無成就感
3、與客戶溝通成本高的原因
§我們未做好導致客戶不放心，他們就催着問。
4、需求變動的原因
§客戶想做一個什麼，以前我們的第一反饋就是不能做，關係矛盾激化；我們沒有去引導和理順。所以客戶索性就不管三七二十一，一股腦的提過來。
二、給出措施執行改進
1、設計合理化，舉例來講，我們以前的很多場景是無極限，其實這是設計遺漏，所以加了加了很多這方面的邊界條件。
2、重點模塊重點對待，code review時花絕大部分的精力在它們上面。
3、對反覆出現的bug在修改前檢查上一個版本是否存在。這是我陪他們加班時見到修改某一個bug引起了別的bug後，制定的針對措施。其實這種狀況，我只要想看到，每天都可以看到。
4、進行團隊建設，開展適當的關懷活動。這絕對不是一句空話，必須落到實處，喊喊口號現在騙不了任何人。
5、集中辦公，我的辦公室本來同開發、MD、QT他們不在一起，我特意每天花大半天同他們一起，這樣的好處是很多的。可以快速討論和解答問題；可以讓他們知道我在幹什麼，我關注什麼；有事加班時，我不走他們也會一起幹；…。
6、每日里程碑，事情一日一清。下班前讓大家花10分鐘show一下他們的成果，可以透明化、可視化，另外也可以起到鼓舞人心的作用。
7、我親自參與測試，並且經常在晚上11點或凌晨6點發出bug list給團隊，這樣一是自己對產品瞭然於胸；二是檢測出一些問題；三是感染大家。我一直強調，團隊的戰鬥力肯定不是喊口號能夠喊出來的，帶頭人的身體力行比別的什麼辦法都有用。
8、每日把當天的成果向客戶反饋，包括不好的結果。電話溝通或電子郵件，這樣ta就不會對我們不放心了，減少了很多溝通成本。
以上活動堅持兩週後，情況就慢慢好轉了。向着積極的方向發展了，爲後面的工作開展創造了好的條件。雖然累點，但至少心沒有以前累了，怕就怕心累。
老實講，在這樣的項目環境下，指望能夠達到優異是一種奢望，能夠全身而退即是勝利。
後話：正是通過這個項目（儘管這個項目的綜合得分不高），讓公司看到了我作爲資深人員所具有的能力，所以後面就將優質也很重要的項目交給我去處理。
正所謂，輕舟已過萬重山！