需求分析對產品發展有多重要就不多說了，直接開門見山吧！
一、需求來源
平時工作中需求來源有很多：用戶反饋、同事建議、老闆命令、自己頭腦風暴、競品分析、數據分析、技術需求、運營需求、商業需求、跨部門合作等等；對於四面八方而來的需求，不要慌，也不要立即答應做還是不做，先記錄到自己的需求池裡面，接下來認真分析！
二、需求的提煉
核心：拆分需求
一般我會將進行兩步拆分，下面將進行詳細介紹：
1. 拆分四個維度：用戶、場景、用戶現在的問題、用戶現在的解決方法
用戶維度
可以從兩個方面來看待：
- 誰提的這個需求
- 這個需求的用戶是誰
第一點還是蠻重要的，如果是老闆提的需求，自然是需要重視的；如果是用戶提的需求，就分析他是不是主流用戶，用戶價值咋樣？從提需求人這個方面可以對需求有個基本認識。
再來看第二點，這是我們需要著重分析的：
- 這個需求誰會用？
- 是不是我們的目標用戶？
- 這種用戶佔我們用戶的比例是多少？
- 用戶屬性咋樣？
能夠回答這些問題需求分析就差不多成功一半了！
回答一下第四點用戶屬性的問題，用戶屬性不同產品有著不同的定義，不過主要還是看用戶的價值，比如花的錢多不多、活不活躍、是不是大V等等。
場景維度
場景是我做產品以來一直覺得很重要的一個要素，因為同一個需求在不同的場景下用戶所需要的是完全不同的。
比如場景是一個單身男性週末宅在家，快到中午了，肚子有點餓了，為了填飽肚子，他這個時候會怎麼做呢？
點外賣可能就是他目前所想的，這時候他需要的就是美團或者餓了麼這種外賣APP！
再比如這個單身男性正在追一個女孩，有一天一起逛街，肚子餓了，你猜這個時候他們會怎麼解決他們肚子餓這個需求呢？
所以關鍵點來了，分析場景維度的時候就需要看：
- 這個場景是怎樣的？
- 場景是否高頻；
- 是否和我們產品目前提供的場景契合。
針對第一點，場景越真實，需求也就越真實。
針對第二點，場景的高頻一定程度上決定了這個需求是否高頻，自然也就決定了你的產品數據表現。
第三點需要特別說明一下：有可能這場景和目前產品提供的場景是不契合的，這個時候不要盲目做決定，需要分析這個場景是不是之前考慮漏掉了，而實際又是用戶使用產品時存在的（因為不同場景是可以被同一產品/功能滿足）；另外一種可能就是用戶使用的場景和自己產品目前的場景的確是不一致的，經過分析後覺得有必要提供這個場景就可以做，要麼就果斷捨棄或者再進一步觀察、或者完全就新立項一個項目（如果確實有這個必要的話）。
用戶現在的問題
顧名思義就是在當前場景下，用戶現在遇到的問題是什麼？這個需要多聽用戶反饋、多看用戶的操作，如果不能接觸用戶的話，就儘量模擬用戶的場景，自己去體驗、使用，從而找到現在的問題。
用戶現在的解決方法
這個也好理解，就是用戶為了滿足自己的這個需求，他目前是怎樣做的？梳理出用戶目前的解決方法，包括但不限於用戶的操作流程、所用到的功能、產品、 輸入的內容。
通過第一步就可以排除一些低頻需求和偽需求了，接著再來講講需求拆分的第二步。
2. 拆分兩個維度：任務、目標
任務維度
- 用戶完成這個需求需要做什麼
- 我們解決這個需求我們需要做什麼
第一點就是用戶完成這個需求需要在我們的產品裡面做什麼，大概就是用戶的一個基本操作路徑，這個時候需要注意任務的多樣性。
多樣性就是指滿足這個需求可能有很多種方式方法，至少應該想出兩種，並知曉其優劣。
這時候可以和第一步的用戶現在的解決方案做對比，看是否比現在的好、體驗是否得到了優化、是否解決了用戶現在的問題。
再來看第二點，意思就是我們為了滿足這個需求，需要做一個什麼功能/頁面給用戶。
這個時候需要注意的是任務的複雜度（可以簡單理解為開發難度、需要的資源、成本，如果技術難度太大或者我們根本沒這個資源，那就基本不可能實現，畢竟巧婦難為無米之炊。或者成本太高而回報不足，我們也不可能做太賠本的買賣。
目標維度
人們做事都是需要回報的，商業公司肯定最需要回報，所以這個目標也可以分為兩個方面：
- 用戶的目標
- 我們的目標
第一點很好理解，就是用戶為什麼要做這件事，做了他能得到什麼好處，這是用戶使用該產品/功能的驅動力來源。所以這一點我們需要了解清楚，比如用戶需要上傳照片這個功能，他的目標可能是希望記錄自己生活的點滴，驅動力越強，產品/功能被使用的頻率也就越高。
第二點我們的目標，就是我們為什麼要做這個，做了對我們有什麼好處。PRD的第一部分寫的就是需求背景與目的；開需求評審會的時候，也是先講為什麼要做這個需求。這個是重中之重，一定要想明白，最好有量化的標準！一家公司如果一直在做沒有目標、沒有意義的事，結果可想而知！
三、需求的轉化
上面的分析只是產品經理分析需求的一個基本過程，最終還是需要將零散的、口水化的、片面的描述轉化為產品需求即形成Feature List(需求列表)。需求列表主要內容就是描述具體功能、優先級以及量化標準。
確定需求優先級的方法，有利用KANO模型，需求重要-緊急四象限，看用戶的付費意願什麼的。其實個人覺得經過上面需求的提煉，其實優先級的高低、需求的真偽也就大概出來了。
最後說一下這個量化標準，這也是一個很重要的點：意思就是每個需求/功能點都需要給它設定一個上線後的考核標準，上線後相關數據指標要與這個標準對比。比如這次需求是優化下單的關鍵路徑，那麼考核標準就可以是下單成功率提升5%，這個考核標準是根據你的需求目的以及現有的數據所定下來的，而不是憑空想象的。
個人覺得一個需求至少滿足三點才算合格的需求：
- 可實現
- 可描述
- 可量化
如果一個需求不能實現，那還叫什麼需求呢？
如果一個需求作為產品經理自己都沒搞明白、弄清楚，怎麼讓別人認同自己呢？
如果一個需求不可量化或者說不去量化，那怎麼知道這次需求做得對不對？好不好呢？怎麼根據結果去倒推過程呢？
四、結語
需求分析是作為產品經理最重要的能力之一，希望大家能夠準確把握需求，辨別需求真偽，做出正確的抉擇。因為一將無能，累死三軍啊！
題圖來自Unsplash，基於CC0協議
閱讀更多 人人都是產品經理 的文章
