首先，最重要的一個問題就是，為什么要做需求分析，或者說需求分析的意義是什么?每個人對這個問題可能都會有不同的體會。我的看法是，需求分析的意義在于準確無歧義地表達項目需要交付的產品，并且獲得需求方的認可，從而為整個項目建立一個基準。指望需求不變化是幾乎不可能的，不管是開發(fā)者還是需求方都有可能隨著項目的進展提出變更的需求，所以需求分析(及變更管理)的目標不是定義一個不會再改變的需求，而是從開發(fā)開始到項目結束，雙方對于需求(包括變更后的)的認知都是一致的。

這樣說可能有點抽象，我們可以來拿一個例子進行說明。

比如項目初期形成的需求分析中有這樣一段描述：“應用系統(tǒng)能夠根據(jù)預先定義的個性化模板，定期自動對每條用戶的數(shù)據(jù)生成對應的pdf報告文件，并發(fā)送到在用戶信息中預先設定好的電子郵箱中?！?/p>

針對這條需求，開發(fā)人員找到了一個自動生成pdf文件的插件，這個插件會讀取一個xml模板，然后根據(jù)傳入的數(shù)據(jù)生成pdf文件。一段時間后，功能做好了，用戶的項目經理看了生成的pdf覺得不錯，項目進展順利。

可是，到了階段驗收的時候，用戶組織了一段時間的試用，對這個功能大家都覺得不滿意，因為普通用戶根本不會編輯xml模板，覺得很麻煩，而且容易出現(xiàn)格式錯誤。這時，用戶提出應該提供一個編輯界面，讓用戶以所見即所得的方式來編輯模板，這也是很自然的。

問題就來了：開發(fā)人員認為這是對需求的變更，需求里沒有提到要做這么個界面嘛!這樣會導致項目的進度、預算都需要調整，也許有人還會要求用戶增加開發(fā)費用。而用戶會認為這是開發(fā)的工作沒做好，怎么能做個功能出來讓用戶自己編輯xml呢?一百個用戶里也難找出一個用戶知道xml是啥東西，更別說編輯它了。所以雙方就會在這個問題上糾纏不清。而這只是整個項目中很小的一塊需求，一葉而知秋，其他部分的問題也肯定少不了。

這里面到底是用戶不講理，還是開發(fā)人員偷懶?其實都不是，我覺得問題出在需求定義得不嚴謹。如果開發(fā)人員在需求分析過程中和用戶交流過模板的格式問題，用戶會在第一時間明確模板編輯的需求，這樣寫出來的需求可能會是這樣的：“應用系統(tǒng)能夠提供pdf模板編輯功能，讓用戶以所見即所得的方式自行定義個性化模板，根據(jù)該模板定期自動對每條用戶的數(shù)據(jù)生成對應的pdf報告文件，并發(fā)送到在用戶信息中預先設定好的電子郵箱中。”這樣的需求就更嚴謹，事后出現(xiàn)爭議的問題就減少了。當然，你還可以在里面找出一些不夠嚴謹?shù)牡胤?，比如“定期”是什么概念，固定一周一次還是一月一次，還是用戶可以自定義，或者是提供幾個標準選項讓用戶自選?所有這些不明確的定義，都是需求分析過程中要重視的。除非你對于它的不確定性及其可能帶來的最壞結果有充分的把握，否則忽略它就會在未來給項目帶來麻煩。

小結一下我的想法：在項目中，用戶的字典里是單證、收入、報表、審核等，而開發(fā)人員的字典里則是鍵值、索引、按鈕、事件這些，而需求分析就像是一位翻譯，把用戶的語言和開發(fā)人員的語言融合到一起，讓雙方準確理解對方的意思，從而在開始開發(fā)工作之前讓雙方都真正明白對方的思路。

對于需求分析中關鍵的因素，我自己的體會主要有如下三點：

一、深刻理解業(yè)務

需求分析人員需要對用戶的業(yè)務有非常深刻的理解。所謂非常深刻的理解，就是說你能和用戶的管理層就他們的業(yè)務問題談笑風生。如果做金融產品不懂風險管控，做論壇不懂SEO，做人事系統(tǒng)不懂組織行為，如何能對業(yè)務有深刻的理解呢?

有人看到這里要說了，用戶給我講明白需要做什么功能就行了，我對他的行業(yè)了解那么深有什么必要呢?我想說的是，做需求分析也是分很多層次的，層次越高，需要對業(yè)務的理解越深。

我再舉一個例子吧。某個項目要開發(fā)一套企業(yè)管理系統(tǒng)，客戶是一個企業(yè)集團，下屬很多分公司，都在做多條產品線業(yè)務，集團對分公司的業(yè)務管理一盤散沙的問題很頭疼。之前的做法是每個分公司每個月底將每條產品線的業(yè)務報表傳真到集團，然后集團進行業(yè)務統(tǒng)計?，F(xiàn)在客戶提出的需求是，在每個分公司都部署一套和集團一樣的業(yè)務管理系統(tǒng)，并在集團的平臺中做一個數(shù)據(jù)上報模塊，讓各個分公司都可以從自己系統(tǒng)中導出電子版數(shù)據(jù)并上傳給集團，從而提高接收和統(tǒng)計的效率。

“還可以”的需求分析能夠把這個需求準確描述，嚴謹定義，讓開發(fā)人員開發(fā)出用戶滿意的功能?！氨容^好”的需求分析則可以更進一步，和用戶探討是否可以做成一套大集中的系統(tǒng)，分公司無須上報就可以讓集團隨時看到各個分公司的業(yè)務狀況，從而杜絕虛報瞞報數(shù)據(jù)的問題。“更好的”需求分析也許可以和用戶探討通過信息系統(tǒng)的支持實現(xiàn)矩陣化的業(yè)務管理，在不改變組織結構(因為組織結構問題已經超出需求分析的范疇，甚至超過了項目范圍了)的情況下，提高集團對各條業(yè)務線的宏觀管理能力，從而更好地落實集團對于各條產品線的戰(zhàn)略。

也許有人還有“更更好的”業(yè)務分析，但你可以看到，越深入業(yè)務的分析結果對于用戶的價值越大，用戶對整個開發(fā)團隊的認可程度也會更高。這對于項目的成功是非常重要的。如果客戶很感謝你提出了讓他能加強業(yè)務管控能力的方案，他還會和你糾纏菜單的顏色夠不夠好看么?

二、充分和用戶溝通

首先要搞清楚你有哪些用戶，他們之間的關系是怎樣的。有句老話叫眾口難調，用戶之間的觀點也會有沖突。比如高管希望采集的數(shù)據(jù)越多越好，現(xiàn)在用不上將來可能弄個數(shù)據(jù)挖掘工具就突然有奇效了也說不定;負責采集數(shù)據(jù)的一線用戶當然希望數(shù)據(jù)越少越好，只要自己夠用就行了。有些業(yè)務部門不希望自己的業(yè)務數(shù)據(jù)被太多人知道，有些項目甚至會讓一些部門失去權力，一些領導丟掉職位。所以在一個項目里，需求討論會上往往會有各種各樣的聲音。聲音后面是立場，立場后面是利益。缺乏經驗的需求分析人員很容易迷失在這些聲音里，最后做出來的需求成了四不像，而這正是某些用戶希望看到的結果。

這時候怎么辦呢?老碼農俺有一個祖?zhèn)髅胤剑赫矣脩糇畲蟮念I導討論項目的整體思路，然后按大領導的意見把用戶需求篩選一遍，凡是和大領導思路明顯沖突的一律扔到一邊，把符合大領導思路的那些需求充分細化。啥叫大領導?不是什么IT部經理、信息處處長、客戶項目經理之類的，而是能拍板決定和這個項目相關的業(yè)務問題的人，比如做人事系統(tǒng)，大領導至少是人力總監(jiān)，做財務系統(tǒng)至少是財務總監(jiān)，當然能再往上讓一把手積極參與進來就更好了。和大領導討論的過程，既是了解大領導思路的過程，也是篩選需求的過程，更重要的是，獲取大領導支持的過程。有了大領導的支持，再開會的時候，底下吵吵嚷嚷，你也能氣定神閑，胸有成竹。

有人可能又要嘀咕了：大領導你想見就見，你以為自己是誰啊?這就又聯(lián)系到我剛才談的第一個問題，對業(yè)務理解的深度。項目啟動的時候，大領導一般例行是要接見一下項目組的，你也會給大領導留下一個印象。如果你張口閉口就是數(shù)據(jù)庫、表單、Java框架什么的，大領導和你沒有交集，自然懶得見你，要是你能聊到們最大的競爭對手在這個項目相關的業(yè)務領域有哪些優(yōu)勢劣勢，國外的業(yè)務管控經驗等等，你也許能經常成為大領導的座上賓。所以說，對業(yè)務理解的深度是項目成功非常關鍵的。

和用戶的溝通有多種形式，比如需求討論會、高層訪談、用戶討論什么的。我覺得應該先做很多的一線用戶討論，問很多問題，把所有的業(yè)務環(huán)節(jié)都徹底摸清，順便收集一些表單和數(shù)據(jù)作為需求分析的依據(jù)。然后再去做高層訪談，了解整體思路、戰(zhàn)略、目標一類的宏觀問題。需求討論會一般在后期開，主要是針對某些爭議比較大或者定義不清晰的問題，集思廣益，實際上就是一種頭腦風暴方法。在這些討論中，需求分析人員都不應該只是做一個記錄者，而應該多提問題和建議，用自己的思路去啟發(fā)用戶，大膽設想小心求證。但也要注意尊重用戶的意見，不能覺得用戶不懂技術所以我隨便聽聽就行了，怎么實現(xiàn)是技術的事情，和用戶沒多少關系，這樣往往在后期會出問題。

三、具備深厚的技術背景和嚴謹?shù)乃季S

需求分析是業(yè)務和技術之間的橋梁，需求文檔是一種對用戶的承諾。在寫需求文檔的時候，就需要需求分析人員有相當?shù)募夹g背景，了解每個需求對應的實現(xiàn)途徑、難度、和大致工作量，并且能夠把它以一種業(yè)務和技術人員都能無歧義理解的嚴謹表達方式進行描述。當然，這是建立在前面與用戶(包括技術人員)充分溝通的基礎之上的。

有的需求分析人員技術背景不是很強，是不是就做不好需求分析了呢?我覺得倒也未必，這時候就需要團隊的力量了。如果有一個技術很強的開發(fā)人員作為后盾，能夠和你搭檔一起去討論需求，并為你提供技術方面的意見，讓你能充分發(fā)揮自己對業(yè)務的理解和溝通的能力，也會是不錯的組合。

寫文檔就考驗需求人員的文字功底了，有時候一句話、一個字都需要反復推敲，一不小心就有可能給自己挖坑，有點做律師的感覺是不是?要讓業(yè)務和技術都看明白的確不容易，這里俺建議多畫圖，一張圖有時候能抵幾千字。什么流程圖啊、數(shù)據(jù)流圖啊、組織結構圖啊、用戶界面示意圖啊什么的，能畫圖的地方就多畫圖，圖加上文字，讀者的理解就不容易跑偏。

最后，需求文檔寫完了，記得打印出來，核心用戶一人給一本，告知幾天內可以提出一次修改意見，只修改一次就會形成初始需求的定稿，以后再改要走變更控制流程。再印幾本存檔的，最后多一頁簽字確認頁，讓所有收到需求文檔的用戶最后都要簽字確認，最后再給用戶方的項目經理簽字。有簽字確認的存檔就可以作為將來需求變更的依據(jù)了。

有人說，對方項目經理簽字不就行了，為啥非要所有核心用戶簽字呢?因為領導們簽字都是很慎重的。如果不需要簽字，他拿著需求隨便翻兩下往抽屜里一扔，壓根不會仔細看。但是如果三天后需要他一次性提出修改意見，沒有修改意見就簽字認可，這就不一樣了。他就會仔細看，認真提出意見，因為很少有人會在自己沒仔細看過的東西上簽字的，對不?這樣也是提前幫你檢查了定義不夠嚴謹、將來有可能產生爭議的內容。所以通過這個過程，可以讓核心用戶對需求的理解和開發(fā)團隊進行一次同步，真正形成需求的一個基準。

關于需求分析的體會，俺就說這么多吧。自己水平有限，嘮叨了這么半天，也不知道有多少有用的東西，還請讀者多多指正。最后其實俺還有一個想法，需求分析是項目經理義不容辭的工作，如果需求很復雜需要一個團隊，項目經理也必須是這個團隊的核心人員。關于項目管理俺也有一些體會，有時間再寫一點東西，博讀者一笑而已。各位看官，預知后事如何，且聽下回分解。