本從將從需求分析內容、需求分析過程2個方面來分享2B項目的需求分析相關內容。

一、需求分析的內容

需求分析基本包括以下幾個關鍵詞：調研（獲?。?、分析、整理（編寫）、管理，當然了這4個關鍵詞肯定和需求有關的，比如調研是指需求調研。另外，根據不同公司崗位工作的安排，可能有的需求分析崗還有軟件產品設計等相關性工作，但不在本篇文章討論范圍內。

• 調研（獲?。汉涂蛻糁苯踊蜷g接溝通，對客戶方的業務需求做深入了解。
• 分析：該過程中發生在調研過程中調研后，對需求的收集不僅僅是“獲取”，更重要的是通過分析去挖掘需求。
• 整理：是對所有需求進行梳理，歸類及詳細描述，便于其他人能通過你的整理產出物快速準確了解需求。
• 管理：需求是動態的，需求變更是做項目性需求的常態，要學會適應。對于處于變化中的需求要學會需求管理。

了解了需求分析的內容，可以試著思考需求分析的目的是什么？答案一般包含于以下幾方面：搜需求、挖需求、糾需求、砍需求等，個人認為需求分析要用一個詞來歸納的話，那就是價值最大化：讓軟件或產品能夠為客戶提供最大價值。可能有人不太贊成我說的這句話，由于做項目會考慮到各方利益。但不管怎樣，應該保持這樣的初心。

二、需求分析過程

下面將圍繞需求分析的內容對需求分析過程進行闡述。

2.1 調研

調研的方法有很多種，比如訪談法、會議法、體驗法、觀察法等，但具體到某個項目就各有千秋了。訪談法和會議法是比較常用的方法，畢竟比較直接有效。在調研過程中，有以下注意事項和大家分享：

（1）找對人

做項目性需求時，一般都有專門的業務對接人或者叫關鍵用戶。做需求調研時，一定要讓關鍵用戶在場參與。既然客戶方指定某個人為對接人，肯定有是原因的。說明他是能夠代表客戶方利益，并且對客戶方的需求也是有獨到見解的。其他參與人的想法或思路，我們不是完全否定，而是要條條記錄、層層分析，最后要和關鍵用戶討論是否要納入建設范圍。

現實中有一些比較缺乏經驗的小伙伴在做需求分析時，可能太為客戶著想，覺得應該接受客戶方所有人的需求。結果把自己折騰得求生不能求死不得，更可怕的是關鍵用戶不認可這些需求，一切都涼涼了。

（2）多溝通、多確認

平常大家可能有這樣類似的經歷，說話的人覺得自己說的很清楚了，聽者也覺得自己明白說話者的意思了，其實雙方還是沒理解到一塊。比如一句話客戶說“我們部門工作內容有點多，平常很忙”，客戶可能的意思是說他們部門是公司的關鍵核心部門，而聽者可能理解為需要給他們部門減減壓。

現實中可能還有些業務專家可能覺得自己在同行業很久了，用戶說的他都懂。在和客戶溝通時，侃侃而談，有點“喧賓奪主”的趕腳，這是很危險的。同樣的一個問題，在不同客戶那可能訴求是不一樣的，所以要有耐心，讓客戶多說話，不要盲目自信。

關于需求確認，個人覺得比較有效的方式是把你理解的意思重復一遍講給客戶聽；或者把你理解的意思用具體的業務場景描述出來，比如把你和客戶都當成實際需求中的用戶，然后把需求描述一遍，讓客戶確認是否理解正確。

在調研時，不要一直局限于項目范圍，因為這樣會限制你的思路，也不能全面的去了解客戶需求。所以可以暫時不考慮項目的范圍，讓客戶盡情地表達他們的想法，把需求甄別放在下一步。

2.2 分析與挖掘

需求分析不是簡單的需求搬運工，而是要處理正確的需求。

更準確的說，客戶或用戶提出的一般都不是需求，而是問題。他們希望我們需要對問題進行提煉，轉化為軟件需求（解決方案），然后轉交給開發人員。從問題到解決方案就是一個思路、分析的過程。

比如客戶提出“我們所有的工作都要用軟件管理起來”一句話，這是一個10星級的很抽象的問題，作為需求分析人員需求對問題做深入的了解并轉化，才能成為軟件需求。

另外，有時候客戶的想法也是腦門一拍的事兒，所以我們要通過分析去識別出錯誤的需求或偽需求，這里不再舉例，回頭有機會會補上。

需求分析的過程也是把控范圍的一個過程，比如本次是給客戶做一個OA管理系統，客戶突然提到說他們的辦公用品臺賬管理太亂了，這個問題很明顯就不屬于OA的建設范圍。

技術是一步一步發展的，客戶提出的所有需求并不是技術上都能實現，所有不能實現的需求也要靠分析去識別出來。

以上是對需求分析的概述（轉化需求、甄別偽需求、控制需求等）。

需求收集、分析是本能，能夠引導客戶，挖掘需求才是高手。

滿足用戶提出來的需求不是目的，建立客戶在行業領域的標準化管理體系才是目的。這也就決定了用戶提出的需求不一定都要實現，沒有提出的需求也不一定不實現。讓用戶提需求只是實現這個目標的手段之一。

2.3 需求管理之文檔管理

從一開始的初步調研到最后的上線，需求管理是貫穿整個需求分析的過程中的。

日常對需求的管理，對文檔的依賴性還是挺多的，所以一定要重視文檔。有人覺得寫文檔太浪費時間了，可是從長遠來看寫文檔確實是為了提供效率。如有新人進入團隊，他想了解團隊之前的工作，如果有文檔的話他可以直接從文檔中就能了解大概；如果沒有文檔，那他只能點點滴滴都去問其他人了，中間的苦衷就不言而喻了。

需求管理涉及到不少過程及方法，本篇文章暫時只分享用文檔在需求管理中的應用。

（1）版本管理

由于各種原因，如調研不完善、規劃不全面、業務有變化等，需求池也是不斷變化的，那么如何對這些變化進行管理呢？

下面就說到文檔版本的管理，因為需求的記錄還是要用文檔的。當需求變化或更新時，需要及時更新文檔，重要的事情說三遍：及時更新文檔、及時更新文檔、及時更新文檔。

對于規范的需求文檔一般都會有文檔的“更新記錄”這樣的類似的章節，每次對版本做詳細說明，如本次修改了什么內容、修改人等：

提示：需求文檔要保留歷史版本，而不是只留最新版本。比如從版本v1.1向v1.11過渡時，應保留V1.1的文件，復制一份V1.1的文件并在它上面修改后作為V1.11。

（2）完成度及優先級管理

在軟件開發過程中可以用以下格式的文檔對需求進行管理：

由于篇幅有限，暫時對需求的分享先到這里了，以后有機會再對以上某個細分領域繼續分享……

畢竟個人能力有限，歡迎大家批評指正。

本文由 @喝茶嘮嗑 原創發布于人人都是產品經理，未經許可，禁止轉載。

題圖來自 Unsplah，基于CC0協議。