對於軟體開發團隊而言，軟體開發的全過程是：做什麼 -> 怎麼做 -> 做 -> 成果檢驗 -> 交付部署；其中，“做什麼”對應的是需求分析過程，“怎麼做”對應於軟體架構設計過程，“做”對應於開發過程，“成果檢驗”對應於測試，部署由運維團隊執行後，如果達到使用者的要求，則軟體上線後進入軟體的執行生命週期。

而在實際的軟體專案開發中，“做什麼”，“怎麼做”和“做”是緊密結合在一起的，“做”，“成果檢驗”和“交付部署”通常也會是一個持續交付過程，“成果檢驗”的內容會受到“做什麼”的影響，開展“做什麼”階段的時候，也要考慮到如何部署和交付。所以軟體開發的全過程，都是緊密結合在一起的，如果刻意劃分為獨立的幾個階段，忽視其作為一個整理的綜合影響，每個環節的實施過程必然會遇到因上一階段考慮不周全帶來的問題，從而影響整體開發效率。

今天，我們首先來談一下軟體專案中，需求究竟該怎麼分析？

正確的需求分析決定了我們產品的方向，需求分析搞錯了，做再多都是浪費。只有方向對了你才能走出迷途，方向錯了，你只能迷失！基於此，我們的需求分析可分為兩個階段，第一個階段是收集需求，第二個階段是處理需求。

收集需求

需求的來源有很多，需求的處理方式也不盡相同。有效的收集需求，將收集到的需求去偽存真，是產品設計環節中最重要的一環，如同大廈的地基，地基不堅實，大樓是蓋不起來的。而且我們在收集到需求時，要第一時間與使用者交流溝通，儘量走到使用者中去了解他們的想法，深入瞭解目標使用者在真實環境下的感受，儘可能地挖掘使用者的原始需求，充分了解使用者真實場景，才能真正更好地服務使用者，打造出他所想要的產品。

1、還原場景

如果只是單獨看使用者提出的需求，你很難分析到使用者的真實需求，就像有些英語單詞一樣，你必須放到那個語境下面去了解，才能找到使用者背後真實目的。

我們可以從以下場景進行分析：

基於什麼環境：地鐵/辦公室/室內/公共場合/走路/夜晚/戶外…深入情景周圍的細節中去。

基於什麼使用者：具備什麼特徵，比如身份、收入、區域…

基於什麼行為：行為或操作流程，比如購物流程、操作習慣、行為認知…

場景分析也就是需要考慮具體什麼環境（時間、地點、情境）什麼型別使用者的什麼動機，想達到什麼目標，以及人與人的關係。如實地分析記錄下來，如果偏差或缺乏資訊，之後的分析就會有所偏差。

2、多問幾個為什麼

使用者需求的傳遞過程中總是存在著無法完全理解吸收的問題，導致所收集的需求不一定就是使用者的真實需求，這時你需要做的是找到需求的提出人，多問幾個為什麼。這個需求提出人可能是使用者，也可能是運營，也可能是技術，你多問幾個為什麼的時候，也就能發覺使用者背後的需求。

3、資料分析

資料是客觀反映產品的重要指數，也是收集需求的重要來源，前期收集的資料需要是可靠、客觀的，而且資料是零散的，在進行資料分析前一定要有明確的中心，劃定一個界限，收集同一個框架內的數，同時單獨的資料是死的，有對比的資料才有意義。為了避免主觀意識的影響，同一份資料可參考其他人員的分析結果。

4、多和別人溝通/頭腦風暴

一個人的力量是有限的，當我們吃不準的這個使用者需求的時候，可以把這個需求拿出來和使用者討論一下，進行頭腦風暴一下，人多力量大麼，當我們吃不準一個需求的時候，大家都認為的那個結果就是需求分析的結果。

處理需求

處理需求的階段，也是產品經理將需求進行篩選，梳理業務流程，設計產品架構的階段。

1.需求篩選、分類

儘管我們保持嚴謹的態度收集大量的需求，其中還是有很多需求是“偽需求”，甚至是不合理的，我們第一步就需要將這些需求進行“清洗”，擇優去重、去偽存真。

2.設定優先順序

一般來說，從需求型別來看，基本型需求>期望型需求>興奮型需求；

從需求來源來看，戰略性需求（使用者提出）>功能性需求（核心功能）>業務性需求（拉活、存留）>體驗性需求（提升使用者體驗）。需求優先順序判斷最常用的是用四象限法則去評定優先順序，另外可以使用RICE評定方法，KANO模型等。

3.競品分析

由於在這個階段，產品經理不僅要定義目標使用者、產品使用場景，還要確定核心功能，產品流程等等，因此通過競品（如果有）來輔助處理需求是一種很有效的方法。

通過相似競品的使用者定位、功能反推競品的需求，與自己的需求進行對比；將自己的需求代入競品中，看流程是否符合邏輯；與競品進行對比，分析需求的異同。

4.需求評審

在這個階段之前，作為產品經理對於產品應該有了一個完整的模型，但僅僅是理論上的模型，確保UI、UE、前端開發、後臺開發、測試參與，從產品開發流程的各個角度對需求進行拆解、分析。需求評審可以看作是產品開發的初始化或者預開發。

需求分析是基於使用者溝通、背景認知、人性理解，層層還原一個需求本源的過程。我們對一個需求的還原程度越高越準，越有機會在後續產品設計給出合理的方案。