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

這樣說可能有點(diǎn)抽象，我們可以來拿一個(gè)例子進(jìn)行說明。

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

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

可是，到了階段驗(yàn)收的時(shí)候，用戶組織了一段時(shí)間的試用，對(duì)這個(gè)功能大家都覺得不滿意，因?yàn)槠胀ㄓ脩舾静粫?huì)編輯xml模板，覺得很麻煩，而且容易出現(xiàn)格式錯(cuò)誤。這時(shí)，用戶提出應(yīng)該提供一個(gè)編輯界面，讓用戶以所見即所得的方式來編輯模板，這也是很自然的。

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

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

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

對(duì)于需求分析中關(guān)鍵的因素，我自己的體會(huì)主要有如下三點(diǎn)：

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

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

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

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

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

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

二、充分和用戶溝通

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

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

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

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

三、具備深厚的技術(shù)背景和嚴(yán)謹(jǐn)?shù)乃季S

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

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

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

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

有人說，對(duì)方項(xiàng)目經(jīng)理簽字不就行了，為啥非要所有核心用戶簽字呢?因?yàn)轭I(lǐng)導(dǎo)們簽字都是很慎重的。如果不需要簽字，他拿著需求隨便翻兩下往抽屜里一扔，壓根不會(huì)仔細(xì)看。但是如果三天后需要他一次性提出修改意見，沒有修改意見就簽字認(rèn)可，這就不一樣了。他就會(huì)仔細(xì)看，認(rèn)真提出意見，因?yàn)楹苌儆腥藭?huì)在自己沒仔細(xì)看過的東西上簽字的，對(duì)不?這樣也是提前幫你檢查了定義不夠嚴(yán)謹(jǐn)、將來有可能產(chǎn)生爭(zhēng)議的內(nèi)容。所以通過這個(gè)過程，可以讓核心用戶對(duì)需求的理解和開發(fā)團(tuán)隊(duì)進(jìn)行一次同步，真正形成需求的一個(gè)基準(zhǔn)。

關(guān)于需求分析的體會(huì)，俺就說這么多吧。自己水平有限，嘮叨了這么半天，也不知道有多少有用的東西，還請(qǐng)讀者多多指正。最后其實(shí)俺還有一個(gè)想法，需求分析是項(xiàng)目經(jīng)理義不容辭的工作，如果需求很復(fù)雜需要一個(gè)團(tuán)隊(duì)，項(xiàng)目經(jīng)理也必須是這個(gè)團(tuán)隊(duì)的核心人員。關(guān)于項(xiàng)目管理俺也有一些體會(huì)，有時(shí)間再寫一點(diǎn)東西，博讀者一笑而已。各位看官，預(yù)知后事如何，且聽下回分解。