在我前面寫的一篇博文《如何寫出讓自己滿意的程式碼》中，有讀者在評論中提到了使用者需求不確定導致在總體設計階段總是無的放矢的問題。需求分析當然是非常重要的，甚至在某些情況下比總體設計還更重要。那麼，如何理解需求分析呢？
Google一下關鍵字“需求分析”，網上已經有很多相關的文章了，有不少已經寫得像教科書一樣全面準確，還提供了一些最佳實踐的分類方法。我這篇就從個人經驗方面談一點自己的體會好了。
首先，最重要的一個問題就是，為什麼要做需求分析，或者說需求分析的意義是什麼？每個人對這個問題可能都會有不同的體會。我的看法是，需求分析的意義在於準確無歧義地表達專案需要交付的產品，並且獲得需求方的認可，從而為整個專案建立一個基準。指望需求不變化是幾乎不可能的，不管是開發者還是需求方都有可能隨著專案的進展提出變更的需求，所以需求分析（及變更管理）的目標不是定義一個不會再改變的需求，而是從開發開始到專案結束，雙方對於需求（包括變更後的）的認知都是一致的。
這樣說可能有點抽象，我們可以來拿一個例子進行說明。
比如專案初期形成的需求分析中有這樣一段描述：“應用系統能夠根據預先定義的個性化模板，定期自動對每條使用者的資料生成對應的pdf報告檔案，併傳送到在使用者資訊中預先設定好的電子郵箱中。”
針對這條需求，開發人員找到了一個自動生成pdf檔案的外掛，這個外掛會讀取一個xml模板，然後根據傳入的資料生成pdf檔案。一段時間後，功能做好了，使用者的專案經理看了生成的pdf覺得不錯，專案進展順利。
可是，到了階段驗收的時候，使用者組織了一段時間的試用，對這個功能大家都覺得不滿意，因為普通使用者根本不會編輯xml模板，覺得很麻煩，而且容易出現格式錯誤。這時，使用者提出應該提供一個編輯介面，讓使用者以所見即所得的方式來編輯模板，這也是很自然的。
問題就來了：開發人員認為這是對需求的變更，需求裡沒有提到要做這麼個介面嘛！這樣會導致專案的進度、預算都需要調整，也許有人還會要求使用者增加開發費用。而使用者會認為這是開發的工作沒做好，怎麼能做個功能出來讓使用者自己編輯xml呢？一百個使用者裡也難找出一個使用者知道xml是啥東西，更別說編輯它了。所以雙方就會在這個問題上糾纏不清。而這只是整個專案中很小的一塊需求，一葉而知秋，其他部分的問題也肯定少不了。
這裡面到底是使用者不講理，還是開發人員偷懶？其實都不是，我覺得問題出在需求定義得不嚴謹。如果開發人員在需求分析過程中和使用者交流過模板的格式問題，使用者會在第一時間明確模板編輯的需求，這樣寫出來的需求可能會是這樣的：“應用系統能夠提供pdf模板編輯功能，讓使用者以所見即所得的方式自行定義個性化模板，根據該模板定期自動對每條使用者的資料生成對應的pdf報告檔案，併傳送到在使用者資訊中預先設定好的電子郵箱中。”這樣的需求就更嚴謹，事後出現爭議的問題就減少了。當然，你還可以在裡面找出一些不夠嚴謹的地方，比如“定期”是什麼概念，固定一週一次還是一月一次，還是使用者可以自定義，或者是提供幾個標準選項讓使用者自選？所有這些不明確的定義，都是需求分析過程中要重視的。除非你對於它的不確定性及其可能帶來的最壞結果有充分的把握，否則忽略它就會在未來給專案帶來麻煩。
小結一下我的想法：在專案中，使用者的字典裡是單證、收入、報表、稽核等，而開發人員的字典裡則是鍵值、索引、按鈕、事件這些，而需求分析就像是一位翻譯，把使用者的語言和開發人員的語言融合到一起，讓雙方準確理解對方的意思，從而在開始開發工作之前讓雙方都真正明白對方的思路。
對於需求分析中關鍵的因素，我自己的體會主要有如下三點：
一、深刻理解業務
需求分析人員需要對使用者的業務有非常深刻的理解。所謂非常深刻的理解，就是說你能和使用者的管理層就他們的業務問題談笑風生。如果做金融產品不懂風險管控，做論壇不懂SEO，做人事系統不懂組織行為，如何能對業務有深刻的理解呢？
有人看到這裡要說了，使用者給我講明白需要做什麼功能就行了，我對他的行業瞭解那麼深有什麼必要呢？我想說的是，做需求分析也是分很多層次的，層次越高，需要對業務的理解越深。
我再舉一個例子吧。某個專案要開發一套企業管理系統，客戶是一個企業集團，下屬很多分公司，都在做多條產品線業務，集團對分公司的業務管理一盤散沙的問題很頭疼。之前的做法是每個分公司每個月底將每條產品線的業務報表傳真到集團，然後集團進行業務統計。現在客戶提出的需求是，在每個分公司都部署一套和集團一樣的業務管理系統，並在集團的平臺中做一個資料上報模組，讓各個分公司都可以從自己系統中匯出電子版資料並上傳給集團，從而提高接收和統計的效率。
“還可以”的需求分析能夠把這個需求準確描述，嚴謹定義，讓開發人員開發出使用者滿意的功能。“比較好”的需求分析則可以更進一步，和使用者探討是否可以做成一套大集中的系統，分公司無須上報就可以讓集團隨時看到各個分公司的業務狀況，從而杜絕虛報瞞報資料的問題。“更好的”需求分析也許可以和使用者探討通過資訊系統的支援實現矩陣化的業務管理，在不改變組織結構（因為組織結構問題已經超出需求分析的範疇，甚至超過了專案範圍了）的情況下，提高集團對各條業務線的巨集觀管理能力，從而更好地落實集團對於各條產品線的戰略。
也許有人還有“更更好的”業務分析，但你可以看到，越深入業務的分析結果對於使用者的價值越大，使用者對整個開發團隊的認可程度也會更高。這對於專案的成功是非常重要的。如果客戶很感謝你提出了讓他能加強業務管控能力的方案，他還會和你糾纏選單的顏色夠不夠好看麼？
二、充分和使用者溝通
首先要搞清楚你有哪些使用者，他們之間的關係是怎樣的。有句老話叫眾口難調，使用者之間的觀點也會有衝突。比如高管希望採集的資料越多越好，現在用不上將來可能弄個資料探勘工具就突然有奇效了也說不定；負責採集資料的一線使用者當然希望資料越少越好，只要自己夠用就行了。有些業務部門不希望自己的業務資料被太多人知道，有些專案甚至會讓一些部門失去權力，一些領導丟掉職位。所以在一個專案裡，需求討論會上往往會有各種各樣的聲音。聲音後面是立場，立場後面是利益。缺乏經驗的需求分析人員很容易迷失在這些聲音裡，最後做出來的需求成了四不像，而這正是某些使用者希望看到的結果。
這時候怎麼辦呢？老碼農俺有一個祖傳祕方：找使用者最大的領導討論專案的整體思路，然後按大領導的意見把使用者需求篩選一遍，凡是和大領導思路明顯衝突的一律扔到一邊，把符合大領導思路的那些需求充分細化。啥叫大領導？不是什麼IT部經理、資訊處處長、客戶專案經理之類的，而是能拍板決定和這個專案相關的業務問題的人，比如做人事系統，大領導至少是人力總監，做財務系統至少是財務總監，當然能再往上讓一把手積極參與進來就更好了。和大領導討論的過程，既是瞭解大領導思路的過程，也是篩選需求的過程，更重要的是，獲取大領導支援的過程。有了大領導的支援，再開會的時候，底下吵吵嚷嚷，你也能氣定神閒，胸有成竹。
有人可能又要嘀咕了：大領導你想見就見，你以為自己是誰啊？這就又聯絡到我剛才談的第一個問題，對業務理解的深度。專案啟動的時候，大領導一般例行是要接見一下專案組的，你也會給大領導留下一個印象。如果你張口閉口就是資料庫、表單、Java框架什麼的，大領導和你沒有交集，自然懶得見你，要是你能聊到們最大的競爭對手在這個專案相關的業務領域有哪些優勢劣勢，國外的業務管控經驗等等，你也許能經常成為大領導的座上賓。所以說，對業務理解的深度是專案成功非常關鍵的。
和使用者的溝通有多種形式，比如需求討論會、高層訪談、使用者討論什麼的。我覺得應該先做很多的一線使用者討論，問很多問題，把所有的業務環節都徹底摸清，順便收集一些表單和資料作為需求分析的依據。然後再去做高層訪談，瞭解整體思路、戰略、目標一類的巨集觀問題。需求討論會一般在後期開，主要是針對某些爭議比較大或者定義不清晰的問題，集思廣益，實際上就是一種頭腦風暴方法。在這些討論中，需求分析人員都不應該只是做一個記錄者，而應該多提問題和建議，用自己的思路去啟發使用者，大膽設想小心求證。但也要注意尊重使用者的意見，不能覺得使用者不懂技術所以我隨便聽聽就行了，怎麼實現是技術的事情，和使用者沒多少關係，這樣往往在後期會出問題。
三、具備深厚的技術背景和嚴謹的思維
需求分析是業務和技術之間的橋樑，需求文件是一種對使用者的承諾。在寫需求文件的時候，就需要需求分析人員有相當的技術背景，瞭解每個需求對應的實現途徑、難度、和大致工作量，並且能夠把它以一種業務和技術人員都能無歧義理解的嚴謹表達方式進行描述。當然，這是建立在前面與使用者（包括技術人員）充分溝通的基礎之上的。
有的需求分析人員技術背景不是很強，是不是就做不好需求分析了呢？我覺得倒也未必，這時候就需要團隊的力量了。如果有一個技術很強的開發人員作為後盾，能夠和你搭檔一起去討論需求，併為你提供技術方面的意見，讓你能充分發揮自己對業務的理解和溝通的能力，也會是不錯的組合。
寫文件就考驗需求人員的文字功底了，有時候一句話、一個字都需要反覆推敲，一不小心就有可能給自己挖坑，有點做律師的感覺是不是？要讓業務和技術都看明白的確不容易，這裡俺建議多畫圖，一張圖有時候能抵幾千字。什麼流程圖啊、資料流圖啊、組織結構圖啊、使用者介面示意圖啊什麼的，能畫圖的地方就多畫圖，圖加上文字，讀者的理解就不容易跑偏。
最後，需求文件寫完了，記得列印出來，核心使用者一人給一本，告知幾天內可以提出一次修改意見，只修改一次就會形成初始需求的定稿，以後再改要走變更控制流程。再印幾本存檔的，最後多一頁簽字確認頁，讓所有收到需求文件的使用者最後都要簽字確認，最後再給使用者方的專案經理簽字。有簽字確認的存檔就可以作為將來需求變更的依據了。
有人說，對方專案經理簽字不就行了，為啥非要所有核心使用者簽字呢？因為領導們簽字都是很慎重的。如果不需要簽字，他拿著需求隨便翻兩下往抽屜裡一扔，壓根不會仔細看。但是如果三天後需要他一次性提出修改意見，沒有修改意見就簽字認可，這就不一樣了。他就會仔細看，認真提出意見，因為很少有人會在自己沒仔細看過的東西上簽字的，對不？這樣也是提前幫你檢查了定義不夠嚴謹、將來有可能產生爭議的內容。所以通過這個過程，可以讓核心使用者對需求的理解和開發團隊進行一次同步，真正形成需求的一個基準。
關於需求分析的體會，俺就說這麼多吧。自己水平有限，嘮叨了這麼半天，也不知道有多少有用的東西，還請讀者多多指正。最後其實俺還有一個想法，需求分析是專案經理義不容辭的工作，如果需求很複雜需要一個團隊，專案經理也必須是這個團隊的核心人員。關於專案管理俺也有一些體會，有時間再寫一點東西，博讀者一笑而已。各位看官，預知後事如何，且聽下回分解。
打賞支援我寫出更多好文章，謝謝！
打賞作者
打賞支援我寫出更多好文章，謝謝！
任選一種支付方式
