乙個專案中需求調研的充分與否是專案日後成敗的關鍵要素之一，這一點我想沒有哪位專案經理不認同吧？不過咱說的需求調研可不只是拿張紙記記客戶說什麼就完了，調研顧名思義就是調查和研究客戶的想法，我感覺應從以下幾個步驟入手：
1、客戶想要什麼？
2、要這幹什麼？
3、為什麼這麼想？
4、會不會有別的想法？
這裡也說乙個最最最最基本的，只談專案別談錢，我們可以說，價錢嘛需要我們回去詳細的分析過您的需求後再給您提供乙個整體的解決方案，您放心價錢一 定合理，不會超出您的預算（真超了再說）。因為現在談錢就等著挨砍吧，先砍你價錢，再砍你時間，最後加點功能，要點回扣，左一刀右一刀，砍到專案**身亡 還拖你尾款。這裡的客戶經理和專案經理們要小心呀。
通過以上四步我們的目標是：搞清客戶的要求，找出要求的邏輯，客戶想要的結果，同時排除開發的風險，挖掘與控制潛在的要求。下面咱們來一一討論。
第一步 客戶想要什麼
這步最簡單了，拿出咱們的筆記本。什麼？作為專案經理你還沒有？太失敗了，去找老闆申請乙個，不給ibm、dell的，至少也要個軟皮的能寫字的筆 記本吧，（本人就用的乙個３２開軟皮筆記本），乙個好記事本可以讓客戶感到你對此專案的重視，記在固定的記事本中也方便我們日後查詢以往的記錄，這點很重 要的。閒話少說，拿本開始記，讓客戶開始說，他第一遍說的時候我們要注意幾點，多記，少說話，如果你非要說話那就說：好、行、啊，再不過癮就說ok，為什 麼呢？因為客戶在說的時候，他多半同時在想自己要什麼什麼東西，不要打斷他的思路，尊重對方表達權同時可讓他把所有想法系統化的說出來，咱們多記，哪感覺 有問題也先標註，一會兒再說，這是其一。其二呢，他說你也說，越說越多，一會兒下班了，最後發現，今天的結果就是下次定個時間再繼續說。現在咱是調查階 段，還沒到研究呢，至少咱還不知道人家的整體想法呢。所以多記，少說。
ok,他說完了，現在到咱了，首先一條一條的複述，在複述的同時我們就可以發表建議了，看好了，是建議，不是意見，所以態度要把握好，我們是來幫他 們作事的，是要把客戶的需求合理化，簡單化，說白了就是程式別太複雜，風險能排全排除掉，別搞個邏輯又複雜又不實用的東西出來。在這個過程中就進入了第二 步。
第二步 客戶要這幹什麼
聽完所有的需要，咱們應該可以分析出客戶所要東西的重點了，圍繞重點開始研究，複述客戶的需求，不要認為他說的，你聽的就明白了，作事千萬別說： 「我以為」，以為就問清楚，所以咱再複述的同時以自己的理解解釋一遍，這時客戶開始聽你說，他就開始明白自己剛才說的哪對哪不對了，不對的會加以補充，繼 續記下來，然後再複述解釋。別怕麻煩，現在多說幾遍大家都還是客氣，比以後大家對需求有爭執強。而且這是先禮後兵，今天我可和你解釋清楚了，日後籤了字你 別說不是這麼回事。當在需求中遇到比較複雜或怪異的問題時我們啟用第三步。
第三步 他為什麼這麼想
客戶大多不是it專家，當然也有自以為是的，這些人要給他們留面子，有面子他們日後也會給你面子。既然不是it專家對有的問題可能在程式實現方面就 想的比較簡單了，還有他們大多是行業專家，對自己所作的行業至少對本公司的行業流程比較清楚，所有我們就需要搞清楚他們的行業流程或說業務邏輯，看看他們 到底想讓我們用程式為他們實現什麼功能，他們要幹什麼？比如說，產品出貨量要有個分析功能，表面一聽，好傢伙，你要幹什麼？細一問原來就是想知道每天出多 少貨，按類彙總一下就ok了，客戶在談需求時，有的人習慣把功能說的比較大，好聽，氣派，有面子，最常聽的「來，咱作個erp」，「這塊我要分析統計」， 「那塊我要綜合查詢」什麼什麼系統，什麼什麼平台，實際真如其所說的功能並非如此之大，所以這就要我們分析了，不過這也好，你說的大，那就是你認可大，大 就有大的價錢，呵呵！所以客戶說大不是壞事。另外不少關鍵問題通過了解其具體想要幹什麼就很容易的化解掉了。
現在他說完了，你也說完了。時間富裕就再複述複述，閒聊閒聊，沒事了就收拾走人了，走時別忘了和人家定個交付解決方案的時間，他不和你定說明他不重視至少不著急，你不和他定說明你不認真。所以定個時間，大家再談。
不說說還有第四步呢嗎？是，這步回公司慢慢想去，因為這步比較複雜。
第四步 他會不會有別的想法
需求收集完了，回來咱們就得好好想想了，他要什麼？要這幹什麼？為什麼這麼想？再來一遍，累呀》_< ，最後咱們來想想他會不會還有別的想法，為什麼說這塊複雜呢？有人說了，得挖掘潛在的需求，想到客戶想不到的事。是，沒錯。但這並不是關鍵。關鍵在於有的 想法能挖，有的不能挖，玩過掃雷吧，這塊我就喜歡稱之為掃雷。因為有的需求對專案有利，有的對專案無利，甚至會毀了我們的專案。比如他們就想作個人員資訊 記錄，你非給分析**事系統管理。這一分析有幾種可能，客戶接受了，就按原來的預算辦吧，完，賠了！要不客戶說是呀，我怎麼沒考慮到，我再想想，得，專案 沒信兒了！所以發掘潛需求得在一定的範圍內，這需求有一定的專案經驗支援，不然挖雷上就全盤皆輸了。還有實現比較複雜的功能，自然不要挖，至少不在本期開 發挖，等客戶提，他們提了再想辦法讓他們作二期。
另外掃雷還和公司的專案策略有關，看是不是想通過某個需求牽住客戶成為長期客戶，不是想通過什麼功能引發他們的二期開發，這就需求與老闆溝通了，所以此步比較複雜，多玩玩掃雷有好處，呵呵
好了，四部全完了，總結一下：在作調研時要把注意力集中在客戶為什麼這麼想？而不是想幹什麼？因為他想的，不一定是對的，需要我們分析他最終想要的 而且是最簡潔的解決方式，當然這樣一分析，我們就可以把自身的一些風險一併給排除出去了。所有搞清客戶為什麼這麼想很重要。同時挖掘潛需求時要在一定的範 圍內，客戶開發專案是有預算的，不會因為功能的增加而追加，當然有的撈錢專案除外。
所有分析完成，要形成詳盡的文件，我感覺最好先出個功能說明，再來個介面設計。
功能說明：比如合同管理模組實現增、刪、改、查功能，增與改分別涉及哪些字段，欄位的邏輯關係，刪除是否支援批操作，查詢可按什麼字段查詢。最後說 明與其它模組間是否有邏輯關係。總之你能寫多詳細就多詳細（當然也與專案的規模有關，不過有固定的文件規範寫起來其實也沒有多難），這個東西籤了字蓋了 章，咱們就有了一定的主動權，好使不好使至少咱們有，總比沒有強吧，沒有就百分之百沒理了。
介面說明：把頁面出個草圖，用word、vs、dw，什麼都成，就是資訊的擺放，把字段放到頁面上，這個介面主要說明點什麼按鈕，出什麼東西，哪個頁面擁有哪些功能。最後一樣簽字蓋章，為什麼又簽字又蓋章，小心客戶方的負責人專案期間離職貝，免的客戶來個全盤不認帳。
有這兩分文件開發就穩當多了，不過專案沒有不變的，古人云，專案中永遠不變的就是變化。
專案管理有感之需求調研
乙個專案中需求調研的充分與否是專案日後成敗的關鍵要素之一，這一點我想沒有哪位專案經理不認同吧？不過咱說的需求調研可不只是拿張紙記記客戶說什麼就完了，調研顧名思義就是調查和研究客戶的想法，我感覺應從以下幾個步驟入手 客戶想要什麼？要這幹什麼？為什麼這麼想？會不會有別的想法？這裡也說乙個最最最最基本的，...
專案管理之需求管理
需求的變化問題 在軟體開發過程中如果只有一條真理的話，那一定是 需求的變化是永恆的，需求不可能是完備的。軟體開發的過程實際上是同變化做鬥爭的過程，需求的變更不一定是壞事，也有可能是好事，是商業機會，對市場敏感的人可以從需求的變化中發現市場機會。需求變化的原因很多，如 一開始沒有識別全，需要增加需求 ...
深入理解專案管理之需求
隨著對專案管理理解的深入，自己對專案管理的兩點有了深刻理解 需求開發與管理 專案組織結構。一 需求開發與管理 寬 泛地講，需求 於使用者的一些 需要 這些 需要 被分析 確認後形成完整的文件，該文件詳細地說明了產品 必須或應當 做什麼。所以如果只有一些零碎 的對話 資料或郵件，你就以為自己已經掌握了...