項目經理手記

上個項目算是告一段落，進展的非常不順利，但也算是一種經曆，從中領略到了很多東西。做項目，就是要從失敗中學習，對于導緻項目進展不利的因素進行分析，進而使自己在下一次的項目管理過程中不會再一次的犯相同的錯誤。俗話說的好，人不應該被同一塊石頭絆倒兩次。是以，失敗并不都是壞事，雖然對于項目沒有按時完成，項目經理承擔主要責任，也被上司叫去訓話，但是我覺得自己從中分析自己失敗的原因，并在下一次項目的改正，這就已經足夠了。

現在，又一個新的項目開始了，在對上個項目進行細緻的總結以後，我也一直在思考，同時也看了一些關于項目管理的書籍以及大家的回貼後，我對發現的一些問題進行了個人的總結，并找到了一些改進的方法，希望在下一個項目中得以實施并收到良好的結果。當然，項目管理并不是從書本上的知識就能學到并靈活掌握的，但把從書本中學到的一些好的方法應用到項目管理中，從一定程度上還是很實用的。

１．如何進行需求的分析與挖掘？

其實這個問題不應該成為一個問題，因為一個真正意義上的的項目經理是不需要去做需求分析的，而應該是讓專職的需求分析人員去做。我的了解，項目經理在工作過程中，與需求沾邊的工作應該是對于項目範圍的定義：确定哪些是在項目中要做的，哪些是不用去理會它的，清楚地定義項目的邊界。除此之外，其它的工作都應該交由專門的人員去進行專業的資訊采集與處理。但大家都知道，在實際的工作中，項目經理往往是既當爹來又當媽，一個人做Ｎ個人的活，尤其是當項目不大的時候，項目經理更是要一馬當先地什麼都做，幾手都要抓，同時，老闆對你的期望又是幾手都要硬。是以，從現實的角度考慮，這個問題還是要探讨一下的。

記得我剛從學校畢業到公司的時候，曾無知地告訴老闆說我對需求分析還是很有經驗的，老闆當時就笑着對我說，其實要想成為一個有經驗的需求分析人員，起碼要有十年的工作經曆。當時隻是覺得老闆嫌我剛出道罷了，但做了一些項目之後，我對于需求分析這件工作有了更深刻的認識，也清醒地了解到需求分析真不是一件容易做的事。

首先，是我們對領域知識的缺乏。客戶所在的領域并不都是我們所熟知的，這不像是在學校裡做課程設計，不是圖書館管理系統，就是學生管理系統，連蒙帶猜也能編出來。行業的多樣性必然會導緻需求領域知識的多樣性，面對這樣的困境，又怎麼能要求我們在與客戶短短的幾次交談中就擷取足夠的資訊來完成一個複雜的軟體産品呢。

其次，客戶對需求的了解與傳達不足。需求很明顯是由客戶傳遞給項目組的。客戶在解釋需求的時候，有時就會帶有很大的含混性，而且客戶對需求的說明不能做到完全的正确。如果是與外國人交流，那資訊的損失就會更大。在與外國客戶的交往中，英語國家的人可以用母語與你交談還算是慶幸了，遇到了母語不是英語的國家的客戶與你交談，那兩個人都要非母語進行交談，雙方都夠把心裡想的東西表達出７０％以上就算是非常成功的交流了。同樣，分析人員在對需求進行吸收的時候也會産生誤解，一些資訊也會被遺漏掉。靠這樣擷取的需求進行開發，結果是可想而知的了。

要解決上述的問題，似乎沒有什麼比經驗更好的辦法了。對于某一行業領域的熟悉，需要一定時間的積累，了解了一定的知識之後，就能更容易得與客戶進行有效的溝通，擷取項目中需要的資訊。需求對于項目的重要性不用多說，一個項目至始至終都是為了達到讓客戶滿意的目的，滿足客戶的需求，其實是一種對需求含混性降低的過程。為了達到這一目的，還有一些稱為方法的步驟可以讓我們減少對需求的誤解：

１．細晰地劃分項目幹系人（Stakeholder）：尤其是厘清什麼是客戶，什麼是使用者。在了解需求的時候，我們能從哪些人中擷取資訊。同時還要注意到，擷取的資訊是否得到負責人的确認。

２．需求分析會議：與客戶的會議當然必不可少。從中盡可能多的找出不清楚的地方，及時的提出，如果客戶允許可以進行錄音，不過這一招估計很難做到，大部分時候客戶可不想留下自己的話柄。與項目組成員的開會是為了在組内加深對需求的了解，集思廣義，再用點頭腦分暴之類的東東，可以發現更多的求知問題。

３．在初始的需求得到後，要對其進行細緻的分析，劃分功能塊及其屬性和限制條件。

更多的知識，可以參考溫伯格的《探索需求——設計前的品質》。

２．如何進行有效的溝通

溝通的話題一直沒什麼争議，在項目中沒有溝通簡直就是死路一條。我上次做的那個項目就是在溝通上出了問題，使得項目延誤。在我發了貼之後，很多朋友也回複指出存在的溝通問題。其實在項目進行中，項目經理要把大部分的時間放在溝通交流上。作用主要包括提出項目的方向（做決策、授權工作、指導各項工作、協商、報告），參加會議，整個項目的管理，公共關系，記錄管理（會議記錄、報告、規格說明、合同檔案）等。溝通的關系主要存在于三個方面：與項目組内部、上司、客戶。

項目組内部的溝通是開發出有品質保障的軟體的基礎。沒有溝通，大家個個閉門造車肯定是不行的。上次的文章中我也提到了這個問題，項目成員間的溝通方式有Email，會議，電話，面對面交談等。Email這種溝通方式友善快捷，如同QQ聊天，不需緊張，對于不善當面交流人們來說是一個福音，但是這種方式還是少用為妙。做為人與人之間的溝通，僅用文字是遠遠不夠的，當然，對于技術上的東西可以，但對于了解性的或者感性的東西，文字的表達能力還是欠缺的。會議這種形式也是問題多多：有效的會議組織可以使得各種決策成為會議的結果，達到開會的目的；無效的會議人們就是在那邊聊天叙舊，很多問題都得不到最終的确認結果。是以說會議也是一把雙刃劍，如何有效的組織會議也是一門講究。事先安排好會議日程是必須的，而且在會前要對會議有充分的準備，進而在會議中得出結論。電話交流相對好一些，但若是項目經理與組員的交流過多的通過電話，資訊的傳達就像上級向下級傳達指令一樣，組員會覺得項目經理架子太大，這樣會給組員一個很不好的印象。是以，面對面的交流也是必不可少的一樣形式，而且項目經理要多花時間在與組員的直接交流上來，積極的把握項目的進度，及時的得到組員的回報資訊以便做出調整。而且直接交流也在項目組内創造一個寬松的環境。

這裡需要提出一點的是，我本人也屢次遇到這種情況。當項目經理傳達任務給組員時，一定要注意自己的用語，務必達到清晰準确，以免造成别人完成任務以後，你才發現這并不是你當初想要的結果。最好在傳達後，讓組員确認他是否已經精确地了解了你的要求，這樣的資訊傳遞才是有效的。

與上司的交流是個有趣的話題。在我的上個項目中，更多的情況下是上司主動來找我問項目的進展情況，我當時沒有意識到要主動的去向上司彙報項目的進展情況。結果在項目出現了問題之後再去找上司，這樣就是等于把責任往上司那邊推，好危險的：）是以，作為項目經理，要及時得與上司交流，把項目目前的進展情況傳遞給上司，正式的彙報比如每周的報告是遠遠不夠的，建議多一些日常的非正式交談。在交談中，在上司的一些問詢中很可能發現一些自己未預見到的問題，如果上司覺得有必要，要及時的做出調整，增加資源等。這樣的話，對項目，對項目經理本人，對上司自身，都是有百益而無一害的。

客戶的交流很重要，上個項目中的與客戶交流不暢導緻了很多問題。很多網友也在回複提到這個因素。項目經理有這個責任與客戶進行交流，詢問一些不清晰的需求，及時報告項目進展等。但要注意到，不能一有問題就打電話給客戶，這樣客戶會非常反感。要利用有限次的機會，獲得更多的必須的資訊，這樣才是有效的交流。比中可以讓組員最大程度的發現未知的問題，搜集到一定量再一次性的去詢問客戶。這樣不但不會影響客戶，也要提高項目組提出問題的能力。在這裡，有一點問題需要說明，介于各公司組織結構與人員安排等多方面的因素，項目經理有時未必能直接與客戶取得聯系，必須通過上司，這種情況下，就回到了上面所說的與上司交流問題，項目經理也要給上司一些壓力，促使上司安排與客戶的聯系的機會。

３．如何進行時間管理

從項目經理的角度來看，時間管理應該分兩個方面，一方面是項目經理對項目的時間資源管理，另一方面是自身工作時間的安排管理。時間資源對于項目來說是十分寶貴的，雖然人月隻是神話，但是每一天，這個神話都在不停的被人期待着，尤其是老闆們（可能他們也知道這隻是個神話）。

完美的時間配置設定是每個人每天八小時都被安排的滿滿的。這顯然是不可能的。項目的開發有點像程序的并發，有時要有等待。這時項目經理要及時的調整組員的工作安排，一種辦法是把任務已經的組員安排到被瓶頸阻塞的任務上來，幫助别的組員一起進行解決問題（又見神話），另一種是看下階段的工作是不是可以劃分出一些在這個階段就完成。讓組員空閑着就說明項目經理的安排沒有做好。上個項目中，有一段時間組員都說沒有事情可以做，當時沒有很好的做出調整，才導緻後面的時間資源緊張。

對于自身的時間管理，項目經理要把握的一點就是永遠都要把重要的事情放在第一位。每天早上到公司就要安排自已一天的工作，并按優先級排一個序，接下來就要做優先級第一的事情。從長遠看，要按照重要與緊急的安排劃分，相信大家在很多地方也都看到過。

重要又緊急的事情是目前要執行的，讓人忙得不可開交。

不重要又緊急的事情就是浪費時間。

重要但不緊急的事情才是項目經理能把握先機的關鍵。之是以出現很多的緊急的事情，把項目經理整天忙得團團轉，很多情況下就是因為事先沒有把握好這些重要但不緊急的事情，如果能夠事先做準備，後面的安排就是按步就班，很少出現忙不過來的情況了。

不重要又不緊急的事情，就随它去吧。

特别的，對于一些項目經理要寫的文檔，最好規範出一些模闆。一般公司都會有相應的文檔模闆，但那遠遠不夠，每次項目都要寫一些類似的資訊，是以最好自己整理一份模闆。以後每次做新的項目，隻要輸入一些新項目的資訊即可，這樣大大地減輕項目經理日常的工作，把花在文檔上的時間降到最小，何樂而不為呢。

４．如何進行開發方法的讨論

關于開發方法的讨論一直是個熱門的話題。不論是學者還是實踐家都在不斷地尋找一種好的方法，從經典的瀑布模型到現在流行的靈活開發，都給軟體開發帶來了一次次的進步。雖然方法如此之多，但老實說，雖然瀑布模型很難應對目前快速變化的軟體需求，但大部分情況下，軟體開發還是按照它來進行開發的，最多有一些疊代的變化。至少我在參與了不少項目後發現基本上都是按照它來進行的。

瀑布模型明确指出了軟體開發過程所要經曆的每一步流程，每個階段都是以上一個階段的完成而開始的。同時，在每個階段的結束時，要有一個裡程碑的檢查，來決定是否可以進入下一個階段。這種方式比較适合需求基本穩定或者大型的項目。疊代的開發模式階段與瀑布模型一緻，不同的是當一個階段的工作出現問題時允許回溯到上一個階段進行改進，這種方法其實更加實用。因為，在現實中，很少有項目在編碼與需求或設計文檔要求的完全一樣。現在熱論中的靈活開發好像在國内實施的并不是很多，這種方法講究的是輕量級的入手與實施，簡單靈活的設計以備随時應對需求的變化。國外似乎應用的更多，我覺得可能這種方法看似簡單，但對開發人員的要求極高，光是靈活的設計以及對面向對象思想的深入了解，我們又有多少人都夠勝任呢？

我個人覺得方法的使用還是要與項目的特征相結合。比如說我的上個項目是個Web的項目，那就應該用快速原型開發的方法：在接到客戶需求後，第一時間内就是進行UI的設計，把所有頁面全都按已知需求做出來，以及頁面間的連結做出來，然後拿給客戶看，這種方法對需求的定位比較準備，能夠在早期就與客戶進行有效的溝通，啟發客戶提供進一步詳細的需求描述，對後期的開發有着極大的幫助。再比如我現在正在做的一個類似MIS的系統，所有的需求都已明确，客戶提供了詳盡的需求資料，而且是在先前系統上做的一個增加功能的版本。這種情況下，我們就應該選擇走标準的流程。

項目類型的不同，決定的開發方法選擇結果的不同。項目經理應該熟悉各種開發方法，才可以在對項目分析之後決定用什麼樣的開發方法來應對它。

５．如何面對技術細節

技術細節的問題我相信是困擾着項目經理的一個頭疼的問題。理論上說，項目經理的職責就是進行管理，對于技術是沒有什麼苛刻的要求，頂多是了解即可。但實際上，在我們所處的環境中，項目經理一般技術出身，有着一股對于技術狂熱的酷愛，仿佛不進行技術的學習就是沒有意義的工作。針對這人問題，我想談談自己對于這個問題的看法：

1.項目經理不能沒有技術背景

很難想像一個對技術毫不了解的人來做項目經理，對項目來說是個多麼大的悲哀。組員肯定會經常把氣撒在項目經理身上，“一個什麼都不懂的人怎麼能夠帶領我們這幫聰明的程式員？”，這樣一來，氣士低沉，項目何來的曙光呢？當然，大部分的情況下，項目經理還都是技術出身的，從程式員的崗位上提升上來，即所謂的編而優則管。一個具有技術經驗的項目經理，無論是在計劃安排，還是在做決策的時候，都會因其具有豐富的經驗而更加有效的執行。同時，在對需求的了解上也會更加深刻，可以更準确的把握項目的進展方向。

2.項目經理不能陷入技術細節

擁有技術對項目經理來說是必備的，過多的專注技術就是項目經理的大忌了。項目經理應把工作的主要任務放在管理上，即計劃安排，資源調配，進度控制，交流等等，把這些工作都做到位，需要大量的時間與精力的。而如果項目經理專注于技術而不能自拔，那就勢必影響到他應做的工作。而且，過分專注技術的人往往有個特點就是愛追求完美，我個人有時也是這樣。覺得事情總會一個完美的解決方案，就在其中深入的研究，這種精神對于科研的學者來說是一件好事，但是對于在企業中的人員來說，就另當别論了。尤其是項目經理，在管理一個項目時，不要去追求完美。典型的問題就是關于軟體産品的三要素的關系，即時間、成本、品質，如果項目經理想要對這三方面都追求完美，那麼這個項目基本上就不用做了。是以，在開始一個項目時就要衡量到底這三個因素要重點放在哪兩點上，另一點可以做一些舍棄。不要因為沒有找到一個完美的辦法而灰心喪氣，這個世界本來就不是完美的。

3.項目經理應該把握技術的發展方向

不專注技術，不代表不去理會技術，特别是目前這個技術日新月異的時代，項目經理應該主動地比别人更快的去接收新資訊。對于技術的發展，作為一個項目經理是應當很好的把握的。做Web的項目就應該了解現在Web 2.0的方向，在微軟平台上做産品，就應該了解.Net 2.0, 3.0的新特性。這時并不要求項目經理要去學習具體的知識點，隻是說要求項目經理每天能夠利用少許的時間從網際網路上擷取最新的資訊，更新自己的知識結構，對項目的技術方向有個明确的認識，才能更從容地應對未來的技術變化。

4.項目經理應與職能經理一起為促進團隊的技術提高而努力

當項目接近尾聲的時候，項目經理需要準備一個總結的報告，對項目進行一番評述。而組員的工作基本就已經結束，其實這時需要做的工作非常重要，就是對軟體開發過程中的一些技術點進行總結，比如生成能夠重用的控件、某一問題的通用解決辦法等。這些工作，對于技術人員來說是一種積累，同時，對于公司來說也是一筆潛在的收益。是以，項目經理應該安排技術人員進行這方面的工作，多數情況下，職能經理可能考慮到現實的情況，會安排他們直接進入下一個項目。但項目經理應該與職能經理進行很好的交流，争取到一部分的時間來進行上述的工作。所謂磨刀不費砍柴工，大量的知識積累，可以更高地提高開發人員的工作效率與開發的産品的品質，到頭來，還是解除了項目經理的一大頭疼問題。

總結

啰嗦了那麼多東西，隻是想談談自己對項目管理中遇到問題的想法。其實上面的每一點都可以展開成一本書的容量，隻是自己還沒有那個能力去分析的那麼徹底。畢竟自己也是一個剛剛步入項目經理隊伍的新手，更多的時候，還是需要去從項目中學習經驗，總結成敗。也希望自己能夠及時将自己的經驗總結拿出來與大家分享與交流，從大家的意見中，吸取更多的精華。