項目管理心得：一個項目經理的個人體會、經驗總結(2)

　　9.好了，做了很多前期工作，定義了一些游戲規則，現在是坐下來做計劃的時候了。這一節，任意找一本項目管理的書都會說得比我好，所以我就少寫一點，說一些自己的體會就是了。首先是找幾個關鍵組員，比如客戶業務專家、系統分析員等等，做一下項目模塊劃分工作。項目分成幾塊去做，每一塊完成什么，模塊之間的信息如何交換等等。需求定義的是做什么的問題，而這里說的是怎么做的問題。這里要強調一點：完成一個目標有很多種方式，你要選一種你最熟悉的，而不是看上去最完美的，這個思路會讓你的項目減少很多風險。有時候客戶會被某種新技術打動，堅持要你采用那種新技術，你就應該告訴他：你選我做這個項目，就應該容許我采用自己最喜歡的方式做事情，新技術之所以有誘惑力，就是因為吃虧的人還不多，我不希望你成為第一批受害者。采用一個計劃會讓你的工作更加明確，比如用微軟的Project軟件，你填寫完表格以后，就可以知道這個項目有多少件事情要做，每件事情需要什么資源，他們之間的前后關系如何，消耗的時間有多長，完成后有什么標志等。所有的結果最后用一個叫做干特圖的形式表現出來。你做完這個表以后會驚奇地發現，干特圖上項目的結束時間會遠遠落后于你的計劃結束時間(簽合同的人永遠不會先征求你的意見的)。當然，學過項目管理的人會大談什么WBS、優化路徑之類的東西，但是我的經驗是你再優化也不可能把這些東西安排到計劃的時間結束。如果你沒碰到這個問題，在我恭喜你挑了一個輕松活之前，請你再去確認你是否羅列了所有要做的事情和正確評估了他們所需要的時間。這時候，你就要考慮犧牲一些任務的時間(也意味著質量)了。按照什么標準犧牲?這個項目的戰略!我們在第三節提到過的戰略。我的經驗是如果你什么都趕進度，其結果可能就是十件事情你一件也沒做好，想想多么失敗啊。所以，把資源投到你熟悉和有把握的事情上，最后的結果是十件事情，你有三件做成了精品，三件完成，還有四件因為某些原因延誤，成績單是否靚麗了很多呢?戰略決定優先級，而正確排列事情的優先級是一個項目經理能力的主要體現。

　　好，現在項目已經完成了前期工作，了解了項目的目標、搞清楚了手上的資源，制定了項目的策略，然后編制了項目的整體計劃，項目進入實施階段。進入這個階段反而是項目經理比較空閑的時候，不像前期的時候項目經理要象記者一樣到處和不同的人接觸，搞清楚他們在說什么，努力猜測他們在想什么和他們的真正目的，那才是最累人的事情。當然，小項目的項目經理往往自己也是一個資源，要做很多事情，這時候反而比誰都苦。項目經理這段時間的主要工作是保持和客戶領導以及自己領導的溝通。和客戶領導溝通時特別要注意，除非你需要對方給你支持，那么你才需要講得具體一點，否則，告訴他一切正常就可以了，而且態度要積極一些，千萬不要說一些領導不懂的細節，比如：“王局長，最近項目進度還算正常，就是JVM經常發生一些內存泄漏的情況…”王局長：“(*&$@@”。和自己的領導匯報也要注意這個問題，除非他是一個技術高手，你需要他的技術經驗，否則一般就匯報進度是否正常以及有問題時你的對策和打算就可以了，有些需要他支持的地方，比如資源調用需要說詳細一點。和組員開會，除了一些項目進度跟蹤會議以外，還有很多討論會，需要大家用頭腦風暴方法給出解決問題。與會人員很多都是技術人員，他們的特點是注重細節、缺乏大局觀、有點消極悲觀、自尊心強(如果總結得不對，歡迎大家拍磚)，所以，你作為會議的主持人，只要負責提出問題和記錄下他們的觀點，千萬不要做評判者的角色。一個問題，有很多方面，從不同的角度看，現象是完全不同的，想想盲人摸象的故事吧。這些技術人員，他們往往精通一個方面，就自己的角度發表見解，除非一些很特別的情況，你都應該認為，他們提出的方案，從他們的角度來看是最合理的。你的長處是掌握事情的優先級，評估各個方面的輕重緩急，從而根據他們的意見得出一個合適的(而不是正確的)方案。所以，在會議上，你要充分尊重每一個人和他的意見，夸獎那些意見提得比較好的人，千萬不要把會議帶入無休止的爭論(你要讓大家知道事情不是非黑即白的，而是多元的，唉，我們的教育惹的禍…)。會后，你自己寫文檔，做決定。會議上大家的面子都被照顧了，自己實施起來的阻力就小，如果還有意見的，你就私下找他聊，如果還不能說服他，你就要讓他明白，因為你負責這個項目、你擔當風險，所以，這個優先級應該你來判斷。組織中的高層，并不見得水平會比一般的成員高，但是，他要承擔組織的風險，加之信息的不對稱性，所以，對事情的優先級的判斷肯定比下屬強。

　　在開發過程中，內部管理還要注意的一點是時刻強調以驗收為目的的思想，每個任務的最終可交付成果一定要是可以被檢查的，比如，【界面要求：美觀大方、簡潔明快】，這個要求我就不知道如何檢查。所以，給開發小組布置任務的時候就要考慮如何檢查結果，比如我見過一個計劃，里面有一個任務【開發人員熟悉EJB編程】，這個任務，除了讓這些人去參加一些專業認證考試，否則，結果很難被檢查。所以，時刻考慮如何檢查結果、如何向客戶交付是項目經理一直要注意的事情，我聽說有些老項目經理拿到項目是倒排計劃的，即首先看如何驗收和驗收標準，然后決定工作計劃。很多項目開始了很久，還不知道如何驗收，那么這個項目出問題的可能性就很大了。做項目就是為了驗收，我們的角色不是研究機構，我們的目的就是在付出那么多勞動后得到結果。

　　另外我插一句：我是極其不主張到客戶現場開發的。尤其是一大群技術人員直接和客戶交流，很容易引起沖突和矛盾(技術人員的本性決定的)。我的做法是項目經理和項目實施人員到現場，軟件開發人員還是在公司做項目。項目實施人員就是初級項目經理，他們了解自己的產品，懂得一些客戶的業務，關鍵是在于他們具有良好的溝通能力，俗稱“皮厚”。他們是客戶和研發人員的橋梁，其職業方向也是很機動靈活，以后可以有很多方向可以轉，比開發人員的路要寬得多。

　　接著，我們再談談最讓人頭痛的需求變更問題。變更通常分為兩種：一種是部分更改了原先的目標，即需求變更;另一種是沒改變目標，但是客戶不滿意目前的實現方式，大到流程的實現，小到界面的布局，都是屬于這類。碰到這種情況是難以避免的，主要是事先溝通的不夠充分和客戶隨著項目的進展，慢慢想清楚了問題，改變了以前的思路。這時候，如果需要改并且你的戰略是容許這種情況的，那么注意下面幾點：

原文轉自：http://www.kuqin.com/projectmanage/20090215/34989.html