需求分析是層層遞進的關系：過濾原始需求、舍棄無用需求、最後整合分類，确定需求優先級。

各位産品經理，時間已經來到2020年，今年突如其來的黑天鵝的打得人類措手不及，任何事情都不确定，未來的環境唯一不變的就是變化。我想唯一可以做的就是不斷總結和積累，增加自己唯一握在手上可以确定的部分，在做産品經理的這兩年，經常面對需求分析，也經常翻看各大博主的需求分析策略。本文将結合實際工作的經驗，試圖總結出一套完整的2B需求分析思路和方法，希望給看到這篇文章的産品經理帶來一些啟發，在需求的不确定中獲得确定。

一、需求獲取

要分析需求，首要要弄清楚需求的來源，也就是你的需求從哪裡來？

1. 獲取方式

總的來說獲取需求的方式有兩種：

1. 主動獲取（1、市場環境整體調研；2、競品分析3、問卷調研）
2. 被動接受，對于被動接受的需求，往往是 用戶直接提出的需求，通過意見反饋渠道或主動聯系産品溝通。

原則：明确目的采取不同的獲取需求方式

在實際過程中采用哪種方式來獲取需求？往往跟我們本身想要達到什麼目的有關，時刻牢記一切從目的出發，當然獲取需求的方式不是3選1，也不是2選1，可以結合。

一般來說本身産品的叠代規劃往往采用競品調研分析、問卷調研的方式。産品的原始規劃往往采用市場環境調研、同類産品調研的方式在在每一項的具體方式中，根據自身的目的，調研的具體方式也不盡相同：拿問卷訪談來說，明确此次調研主要是為了産品優化的體驗項，那麼你設計的調研問卷更偏向于體驗的問題，對象也更多是實際操作者，如果此次調研的目的是為了整個産品的二次功能叠代，那麼調研問卷更傾向于産品功能的延展或改善上的問題（一個原則“問卷調研更多的是調研”，所以在設計問卷的問題更多的是開放和引發思考的問題）

2. 明确調研對象

原則：窮盡你的調研對象—針對主動調研的方式

B端産品的訪談對象不同于C端，B端涉及到的用戶角色代表不一樣，同一套産品一般不止一個角色使用，他們有可能往往包含着矛盾的需求，為了使需求更全面更合理，那麼根據調研的目的要盡可能的選擇包含相關所有的對象。

3. 明确需求

原則：多問為什麼

無論是被動獲取還是主動獲取，在面對所有的需求時，都需要問自己或者問你的對象“為什麼“，據說有一個産品經理思考問題的法則，就是無論任何事情，都連問6個為什麼，要多問為什麼？直到說清楚原因、講清楚邏輯，搞清楚環境、搞清楚原因的過程。

二、需求分析

當我們獲得了這些需求後，是不是馬上就開幹了？答案當然是否定的，從産品經理視角看用戶：用戶不是自然人，而是用戶背後的需求合集，這有兩層意思：1是産品經理的最終對象是需求，2是需求的承載是人，它們具有異質性（特點千差萬别）、情境性（用戶的行為和反應會受情境影響）、可塑性（用戶的偏好和認知會随着外界不同信息刺激發生變化和演化）、自利性（用戶追求個人總效用最大化）、有限理性（用戶雖追求理性，但能力是有限的），這就意味着，我們還要從已經獲得的原始需求裡抽象分析、梳理整合出真正需要滿足的需求，然後找到産品可以做的地方，這才構成了我們作為産品經理和産品設計者的核心價值。

那麼如何去做需求分析？需求的分析也是層層遞進的關系。

1. 需求過濾

面對原始需求，哪些才是我們需要去解決的，哪些不需要？ 而最終留下來的需求才是我們要去解決的需求。

需要解決的問題：需求要最終解決的是什麼樣的問題？需求是正确的嗎？需求是真實的嗎？需求可以解決嗎？需求值得解決嗎？這幾個問題層層遞進，弄清楚這幾個問題，基本上我們的需求就能決定其去留了。

需求最終解決什麼樣的問題？–需求定義

未經過訓練的人都不是抽象問題的專家，所以在提出他們的需求的時候，往往直接說出感受，或者給出解決方案。

如：小A對于聽歌軟件使用體驗感不好，提出了顔色不好看，這個地方字太小了，聽不到我想聽的歌，能不能把這個地方的顔色換成藍色呢？這往往是用戶直接表達的需求和使用體驗，這時候如果刻意做抽象，才能意識到用戶會在說布局不符合使用習慣；在用戶搜索要聽的歌時，連續翻了好幾頁都找不到，因此前幾頁的關鍵字匹配代表能否更快速的找到結果，所以産品要解決的是用戶關鍵字快速匹配的問題。

再舉個例子：小B提出每次做采購單都必須要有商品的編碼，太麻煩了，沒有編碼就要去找數據中心的人維護，能不能不要這個編碼？直接填說明？從表面上來看小B是想要解決商品編碼的問題，而實際上呢？經過詢問你會發現要解決小B的問題其實是維護流程繁瑣或編碼缺失的問題。而不是商品有沒有編碼的問題。

大多數人的需求和“要解決的問題”都是需要抽象和梳理的，所以我們要将用戶提出的需求，進行抽象。

另一個經典的例子就是：用戶說我需要一匹馬，經過分析抽象才知道用戶需求的不是一匹馬，而是一個能快速到達目的地的工具。

2. 需求舍棄

在明确定義需求需要解決的問題了，接下來我們要思考的是需求是真實的嗎？需求是正确的嗎？也就是說有沒有“價值風險”需不需要去解決。我們可以試着從以下幾個方向去思考：

（1）需求是否存在矛盾？

A要解決的問題和其相關的角色需求或現狀是否有沖突：這很重要，尤其是對于B端的需求來說，我們前面提到産品經理面對的需求往往是個人賦予在當前角色和環境下提出來的，人提出的需求都是利己的。比如：以剛剛小A提出這個按鈕放在這裡太不方便了。那麼我們抽象出來是要解決的小A的問題是布局問題，在經過分析小A是個左撇子，所以他這樣提，那麼他的需求就和普通的一般人的需求是矛盾的，此時就應該平衡價值，是否應該舍棄掉這樣的需求。往往B端的産品需求會存在，角色于相關覺得之間的矛盾，與上級需求的矛盾，與整體公司管理需求的矛盾，與商業訴求的矛盾針對矛盾的需求，要理清矛盾關系，分清價值，大膽舍棄。

（2）需求是否隻是解決了當時問題？

就是「産品做出來了，某些顧客也會用了，但後來都不繼續用，因為沒有滿足需求」的狀況，此類需求是否需要我們花力氣花成本去滿足？還是是否可以需要用戶麻煩一點。分清需求的長期價值，大膽舍棄。

（3）是否帶來了真實的價值？

有些需求可能是我們創造出來的需求，來源于我們自身認識的不足，比如我們認為用戶一條條删除會很麻煩，想做一個批量删除的功能改善一下，但實際上用戶批量删除更容易導緻錯誤删除，而删除的情況并不多，所以此類需求就是我們人為創造的需求。充分認識需求是否真實帶來了價值，大膽舍棄創造出來的不能帶來真實價值的需求。

（4）從需求的成本和價值檢視需求

此時需要考慮兩個問題：

1. 當前是真實的需求也能帶來價值且長期帶來價值，但手邊并沒有解決問題的技術，或技術尚未成熟，就是「我們知道要做什麼産品，但是做不出來」的狀況，此類需求也隻能暫時舍棄
2. 投入的成本是否大大超過帶來的價值：需求不是無邊界的，滿足超過一定邊界，邊際收益會驟降。絕大多數情況下，超過這個滿意的邊界，用戶的滿意度不會一點兒都不變，但變化程度會非常小。因此我們要關注這個邊界并且定義這個邊界。

3. 需求整理

（1）需求聚合

對于2B的需求往往都是以業務為導向的，着手去解決分散的需求，往往容易陷入點狀裡面，此時需要以業務為導向指引将零散的需求串聯起來，形成一個完整，内容清晰的框架，以免落入拼命應付解決問題的境地。

找出哪些需求是哪些業務，并将其劃分不同的闆塊，例如有些是采購申請的需求，有些事采購單的需求，他們又都屬于采購需求。其中需求1，2都歸屬哪條業務線上。

（2）需求分類

問題不分大小，不分場景，隻要是需要解決的問題，都是需求，而需求扽分類有助于我們分清需求的優先級，一般我會将需求分為：功能性需求、體驗性需求、二級分類是新增還是優化；他們的重要關系一般是：功能新增>功能優化>體驗優化

（3）需求優先級

在需求分類分級的基礎上，我們可以在定義其優先級，這裡就可以運用“痛點”、“癢點”或者馬斯洛模型等作為參考了，它們可以協助我們定義問題的大小即嚴重程度。對于2B需求來說，往往急需解決的痛點需求是少了這個功能業務無法開展，或者開展的十分困難。

結語

需求分析作為産品經理工作中核心的也是最重要的一環，其需要警示和思考的内容遠不止于此，如何運用并不斷改進是重中之重。

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

題圖來自Unsplash，基于CC0協議

,

更多精彩资讯请关注tft每日頭條，我们将持续为您更新最新资讯!

查看全部