編輯導語：做産品離不開對需求的分析整理，當我們面對海量的需求該如何面對，如何處理，如何提煉出真需求來作為做産品的核心鍊。這篇文章從需求分析的定義出發，用四步法來教大家搞定需求分析關鍵節點。一起來看看吧。

這個需求做還是不做？這是産品經理日常需要做的選擇。

每天都有需求從不同的地方來，甚至都無法知道什麼時候會來，但是你知道需求一定會來。

那怎麼判斷需求是不是值得做？這就要做需求分析了，可見需求分析也是一門基本功。

我們今天就聊一聊需求分析，希望對大家有所啟發。

一、什麼是需求分析

需求分析也稱為軟件需求分析、系統需求分析或需求分析工程等，是開發人員經過深入細緻的調研和分析，準确理解用戶和項目的功能、性能、可靠性等具體要求，将用戶非形式的需求表述轉化為完整的需求定義，從而确定系統必須做什麼的過程(百度百科）。

關于需求分析的說明最重要的就是前文的最後一段“将用戶非形式的需求表述轉化為完整的需求定義，從而确定系統必須做什麼的過程。”

這段話說明了幾個情況：

• 一是需求通常來源于用戶；
• 二是用戶在表達需求的時候是根據自己的習慣表述的，是不完整甚至是隐含的，需要産品經理進行深入分析和定義；
• 三是在用戶表達了需求以後，從系統層面需要給出具體的方案，幫助用戶解決需求問題。

當然需求雖然是來源于用戶，但有可能不是直接來源于用戶，可能是經過業務部門轉述過來的，也可能是數據分析得來的。

實際上日常産品經理在正式開始做需求方案之前都會做需求分析，所以算是一個常規技能。

接下來我們具體講一下需求分析的三個步驟，隻有完成全部三個步驟才算一次需求分析完整的結束了。

二、需求真實性的判斷

第一步先做需求真實性的判斷，如果是一個不真實的需求其實就沒有必要做後續的分析。

一個需求是否真實通常可以通過回答以下四個問題來判斷：

1. 用戶是誰？
2. 需求場景是怎麼樣的？
3. 用戶遇到的問題是什麼？
4. 用戶想要解決的實際需求是什麼？

以上四個問題對應了用戶、場景、挑戰和目的，能夠回答以上四個問題是判斷需求真實性的前提，即如果無法表述前面的問題就可以判定這不是一個真實需求。

我們舉個例子做一些說明：

知乎上有個問題是這樣的，淘寶下訂單後為什麼不可以更改送貨地址？

我們按照前面的問題框架回答一下：

• 用戶是誰？淘寶上購買商品的用戶。
• 需求場景是怎麼樣的？送貨地址填錯了或者選錯了。
• 用戶遇到的問題是什麼？淘寶無法修改送貨地址。
• 用戶想要解決的實際需求是什麼？讓購買的商品送到正确的地址。

非常清晰，所以對于地址填錯了的淘寶用戶來說需要修改送貨地址是一個真實的需求。

我們再舉一個例子：

手工耿曾經做過一個物品，用處是在地震發生時能夠保證這個碗不被打翻，能夠繼續吃泡面。

我們還是按照前面的問題框架回答一下：

• 用戶是誰？肚子餓了，想吃泡面的人。
• 需求場景是怎麼樣的？在地震發生時正在吃泡面。
• 用戶遇到的問題是什麼？地震發生了需要躲避危險。
• 用戶想要解決的實際需求是什麼？保證自己的生命安全。

大家注意到沒有，在地震中用戶的最優先的需求是保證自己的安全，如果是地震發生，大地還在晃動，誰還有心思吃泡面。

所以用戶和場景都對，吃泡面這個需求雖然存在但是不是第一需求，第一需求是安全，那麼所謂的解決方案當然不對。

注意：我在這裡說的是需求的真實性，而不是判斷需求的真僞，我看了一下市面上很多寫用戶需求分析的文章，都在說僞需求的問題，他們中的絕大部分都把需求的理解不對或者需求的價值也歸在僞需求裡面，我認為這是非常不對的。

有名的一個例子是大家想要一匹更快的馬的需求，福特把他解讀為需要更快的速度就做出了福特汽車。

注意這個例子，福特變更了解讀的角度，更接近需求的本質，所以福特勝利了，但是這并不能說想要一匹更快的馬是一個僞需求，想要一匹更快的馬也是一個真實的需求，如果把這個時間拉到工業革命以前，當時的技術水平根本無法造出汽車，那你說這是不是一個真需求？

所以不要把不同的問題混為一談，都把它們歸類成僞需求，這是非常荒謬的做法。

三、需求價值的評定

需求真實性判斷完成之後就需要去判斷需求的價值。需求價值的大小由以下幾個維度來确定：

• 用戶廣度：該需求的受衆面有多大？
• 使用頻率：該需求的使用頻率是以日/周/月為周期？
• 剛需程度：該需求對用戶有多強烈需要？
• 生态影響：對平台其他參與方的影響。
• 産品時機：該需求是否符合産品的規劃，當下的環境？

我們還是以前面那個淘寶的例子來說明——淘寶下訂單後為什麼不可以更改送貨地址？

1. 用戶廣度

該需求的受衆面有多大？

具體數據我肯定不知道，但是應該還是蠻多人遇到過這個問題，假設為10%吧。

2. 使用頻率

該需求的使用頻率是以日/周/月為周期？

頻率肯定很低，大概上百次裡面才會有那麼一兩次，從頻率上來說大概一年也就一兩次，這是從一般用戶的角度來說，購買頻次越高這個功能的使用頻率也可能更大。

3. 剛需程度

該需求對用戶有多強烈需要？

用戶遇到這個問題的話當然是希望能夠修改地址，但是沒有這個功能好像負面也不是很大，可以客服聯系商家修改，或者去送達的地方取一下貨，對于大部分用戶來說地址不是住的地方就是公司，有的時候換住址或者公司可能出錯，但是去取一下也還行。

4. 生态影響

該需求對平台各方産生的影響是怎麼樣的？

對于購買用戶來說其實不會因為這個問題就離開，畢竟和平台帶來的便利性比較，這麼一兩次挫折不算什麼。

對于商家來說，如果允許修改就會是個非常大的麻煩。

我們來具體分析一下：

如果允許用戶修改會發生什麼情況呢？

可能有兩種情況，一種是商家發貨了，一種是商家沒發貨。

發貨了就不說了，修改也沒用，因為貨都在路上了，不可能更改地址，快遞公司也沒有這樣的流程。

如果沒發貨那麼可能會出現兩種情況，一種是商家還沒有備貨，一種是已經備貨提交快遞單給快遞公司了。

如果沒有備貨還好說，如果已經提交了快遞單那就很麻煩了，修改數據是簡單的，問題就是你需要把這個訂單對應的貨品找出來然後把快遞單換一下，這個找的過程是很耗費商家時間的，因為有可能商家一天發幾千件貨，花時間更換地址就會導緻發貨效率降低，如果要保持效率就需要話更多的人工成本，這對商家來說肯定是不希望的，因為錢賺少了。

如果允許修改則商家每天都要處理這個事情，不友好程度就很高了，商家不會馬上走但是可能會把重心遷移到其他平台，這樣整個淘寶生态就慢慢變差了，這個肯定是淘寶難以承受的。

所以從生态的角度來說這個就是負向價值非常大的一個用戶需求。

商業價值：該需求對于業績的價值是怎麼樣的？

基本沒有商業價值，因為改了之後并不會增加業績。

産品時機：該需求是否符合産品的規劃，當下的環境？這個倒是沒所謂。

所以綜合起來看這個需求的價值對于淘寶就是負面的，淘寶肯定不會做這個功能。

我在舉例說明的時候用的都是定性的說明，如果想要做成定量的分析，那麼可以給每一項做一個打分表，譬如1-10分，然後給每一項賦予不同的權重值，譬如都是20%，這個根據需要調整就是了，最後統計綜合得分，根據綜合得分判斷需求價值。

判斷需求價值是為了決定做不做的問題，如果需求價值不大甚至需求價值為負那就不用列入計劃了。

四、需求優先級的評定

按照我們的經驗來說，需求不可能隻有一個，它們廣泛的來自于領導、用戶、業務部門和産品部門自身，所以有十幾個或者幾十個需求是很正常的，這個時候就涉及到對需求優先級的判定問題，公司的資源總是有限的，所以不可能所有需求都在第一時間投入資源，優先級的判定就是解決資源如何投入的問題。

1. 需求的優先級如何判定呢

對于優先級的判定主要是基于前面的需求價值和需求成本-指的是實現這個需求需要投入的資源，這就是一個衡量性價比的過程。

一般類似會把需求價值和需求成本分成低、中、高三等，交叉之後分為優先級最高、優先級次高、優先級一般和不做四個部分。如下圖：

優先級最高一般劃為P0和P1，優先級次高劃為P2和P3，優先級一般就劃為P4。

特别說一下，有些公司把優先級劃的特别細，分成好多等級，其實沒必要。太細了浪費時間分。

五、需求池管理

需求池的管理是最後一步，也是最重要的一步，把從各方收集來的需求、經過前面的分析之後篩選出來的需求彙集到一起，記錄在冊方便管理需求和後續的版本規劃，也方便追溯産品方向的疊代。

需求池的基礎信息主要包含：編号、模塊、功能點、需求描述、場景描述、需求類型、優先級、提出人、提出時間、當前狀态、備注。

編号：需求的唯一标識，編号的規則可以自行定義，最簡單的就是日期 自增數，作用是作為每條需求的唯一編号和快速查詢需求。

模塊：根據産品模塊去劃分，作用是将需求統一歸類到某個模塊下，在進行版本規劃時，可以優先從某個模塊中篩選，同時便于根據模塊查詢。

功能點：簡單描述需求的功能，也就是要做什麼，這樣我們快速查看某個需求時，能一眼看明白這個需求是要新增或修改哪個功能。

需求描述：需要描述清楚需求的完整性、一緻性，需要精準的描述。如果産品經理在後續想不清楚這個需求到底要做什麼，可以通過需求詳細描述來回想或了解。

場景描述：了解用戶在什麼場景下産生的需求，在給開發轉述為什麼要增加這個需求時，可以清晰的說明是因為哪些原因，更能說服開發願意做這個需求。

優先級：從P0-P4，優先級依次下降，優先級可以幫助産品經理在做版本規劃時判斷應該先做哪些需求。

開發量：需求的開發工作量，可以通過這個信息規劃開發每個版本的工作内容，也方便我們了解每個需求的開發難度。

提出人：原需求的提出人，便于日後有疑問可追溯。

提出時間：需求的提出時間，方便我們了解是什麼時間提出的需求，同時可以利用提出時間來規劃需求的緊急程度。

産品對接人：具體是誰來負責對接和後續的産品設計，這個的話一開始沒有可以空着。

狀态：這個指的是需求的生命周期，待處理、設計中、開發中、已發布、暫緩（标注原因）；主要作用是可以對需求的流轉狀态進行跟蹤，可以了解需求在不同階段的狀态，發現問題及時調整。

備注：一些額外信息的記錄。

需求類型主要包含：

• 新增功能：目前平台沒有實現的功能；
• 功能疊代：對目前平台已實現的功能進行優化；
• 用戶體驗：例如頁面按鈕擺放的問題，發送消息時發送按鈕放在右側，可以按照用戶的使用習慣設計；
• UI優化：如整體産品色調的調整等，這個需要根據平台調性去處理。

六、最後

需求分析其實不複雜，但是想要把握的準其實還是需要一些功力的，大家在做具體的需求方案之前不妨想一想這個需求是不是值得做。

公司資源有限，你的時間也有限，總要投入到那些能夠産生更大價值的需求裡面去。

而選擇無疑是這個時代最重要的能力，那麼在選擇之前的分析就無疑是基石，多練練這個技能，或許不止對工作有幫助。

如果你選擇做産品經理，那麼祝你好運。

本文由 @代号道長 原創發布于人人都是産品經理。未經許可，禁止轉載

題圖來自 pexels，基于 CC0 協議

,