對於產品經理來說，大多數的日常都是圍繞需求展開的——溝通需求、實現需求等。那麼對於需求這一內容，如果做好正確理解，相信會對後續實現提供很大幫助。
接著上一篇《需求方法論（1）：需求的理解、來源、挖掘與記錄》
我認為得先理解需求是什麼？然後需求會從哪些地方來？如果自己挖掘需求該怎麼做？需求來了之後該怎麼記錄？記錄以後該怎麼進行分析？分析之後該怎麼進行驗證？驗證之後怎麼進行排序？
所以我的需求方法論由七個部分組成：需求的理解、需求的來源、需求的挖掘、需求的記錄、需求的分析、需求的驗證、需求的優先級排序。
這篇文章是關於需求的分析、驗證與排序。
一、需求的分析
需求分析的目的在於這個需求做不做，所以得分析這個需求的合理性。
1. 角色分析：這是誰提的需求？
領導、運營團隊、還是用戶？不同人站的立場不同，他們提出需求的目的也就不同。前面也提到過，每個人說出的話語都是受到自己認知所左右的主觀意識的表達，所以不能光看他們說的話，還得去想為什麼他們會說出這些話？是否受到自己所在立場的影響？
如果是用戶提的，那這個用戶是否是目標用戶？是重度使用的用戶還是一般用戶？如果連提出者是什麼身份都沒搞清楚的話有可能會大大影響後面的判斷。
舉例：比如通過訂單數量可以初步判斷該用戶是否是重度用戶；通過訂單均價可以判斷該用戶大概的收入層級，等等。
2. 目的分析：提出者是出於什麼樣的目的而提出？
前面提到過，時代雖然變了，但是需求沒變，變的只有需求的解決方案。所以得「透過顯像看本質」，挖掘提出者最本質的需求。
所以需求又可以分為：表面需求、本質需求、產品需求。表面需求就是他人提出的需求，本質需求就是提出者的目的，產品需求就是我們能給出的解決方案。
如果是用戶提出的需求，一般用戶喜歡直接給出解決方案，會直接指出他覺得應該怎麼做。那麼，他提的是不是偽需求？是否只能滿足一小部分人，而會損害大部分人的體驗？他提出的就是最好的解決方案嗎？如果不解決用戶會有多痛苦？
如果是領導提出的需求，他是出於戰略、商業上的考量？他提出的就是最佳選擇嗎？前面提到過，公司需求和用戶需求可能是存在矛盾點的，所以需要平衡這些矛盾點。
舉例：比如領導想要在某一板塊加上另一頁面的引導廣告彈窗，那這個彈窗是否會影響到用戶的操作體驗？可能領導的目的在於為那個板塊增加流量，那引導點是否加在其他地方會更好。
3. 定位分析：這個需求和當前產品的定位有沒有衝突？
如果有，衝突有多大？做了這個功能後會顯得格格不入嗎？會不會影響用戶對產品的看法？有沒有辦法縮小這個衝突？
4. 廣度、頻率分析：這和需求的接受程度怎麼樣？
最多能覆蓋多少目標用戶？會不會影響其他用戶的使用體驗？並不是要精確的覆蓋人數，但是需要預想一下大概的比例。
預計有多少用戶會經常使用？多少用戶使用頻率一般？而這個經常使用和頻率一般又需要怎樣來定義？
可以先預想一下，大概有多少用戶，他們每天、一周、一月使用這個功能的頻率。
5. 投入產出比分析：投入與產出合理嗎？
能創造多少金錢價值？能新增多少用戶量？能促活多少用戶？是否有長期收益？有沒有辦法能預測出大概的數據指標，並對照這個數據指標可以來看實現的效果。
大概需要投入多少金錢？人力？時間？這裡的投入是一個大概的估計，可能並不準確，因為沒有具體的方案，只能篩選一些明顯投入過大，明顯不合理的需求。
6. 數據分析：有沒有相應的數據來支撐？
如果有相應的數據能支持分析那最好，就是錦上添花，畢竟數據比人為主觀判斷更客觀一些。如果沒有，這一條也可以略過
7. 可行性分析：公司現有能提供的資源、團隊的技術水平能支持實現嗎？
為什麼這一條我放在了最後而不是價值分析前面？可能這個需求一看，現有條件就實現不了，就不用進行後面的價值分析了啊。
所以我寫的是現有條件，如果現有條件不支持，而需求確實有好處，那就後續跟進。
二、需求的驗證
為什麼要驗證需求？
需求來了之後很多時候我們都是靠感覺來判斷，可能會出現對這個需求理解不到位的情況，造成一些誤判。這時就需要提出一個初步的解決方案，提出的過程中會更詳細地拆解需求，然後再進行驗證與反推，甚至可能會對之前需求分析出來的結果進行一些矯正，比如現在沒法實現，那這時可能就得降低優先級。
當然，如果是一些小需求就沒必要進行這一步了。
1. 提出基本的解決方案：可以從正反兩個方向的思路來進行思考
肯定：正面解決用戶的需求，設計一套初步的解決方案，可以用流程圖展示出來。否定：讓用戶放棄這個想法，比如找一些替代方案，哪怕效果沒那麼好，後續再改善。需要注意的是，設計解決方案的時候各種場景、各種流程都要想清楚：正常主線流程、各種分支流程、各種可選流程、各種異常流程。只有把各種流程想清楚了，才能對需求做出相對準確的判斷。
舉例：下圖是我之前寫的一篇文章《從0到1構建電商平臺之訂單系統（2）：支付訂單》」裡的一個流程圖，畫的就是在客戶端的支付訂單這個頁面裡的一系列後端判斷。我就以這個流程圖來舉例。（圖有一些地方不一樣，在那篇文章中有說明）
A. 主線流程：
首先在提交訂單頁面成功提交訂單後，訂單生成，並進入支付頁面，此時就會鎖定庫存；然後支付訂單時會判斷該商品的商品狀態是否正常、sku信息是否更改；都沒問題時就會由用戶輸入支付密碼，支付成功就會生成一個待發貨訂單，然後訂單發貨之後就會扣除庫存。
這就是一個用戶使用，基本、正常的主線流程。
B. 分支流程：
比如圖中的，當訂單中有商品處於下架狀態時、sku信息更改了時就會自動取消訂單，並給與提示；當未成功支付時就會生成待付款訂單，過了N分鐘之後還不能支付成功，就自動取消訂單並釋放庫存。
這些就是主線流程上可能存在的分支流程。
C. 可選流程：
可選流程的意思就是質疑自己，當前做出的主線流程是否是最好的，有沒有更好的解決方案？
比如鎖定庫存，我設計的是提交訂單即鎖庫存，那是否能支付成功才鎖庫存呢？
比如用戶提交訂單之後，訂單處於待付款時，我設計的是商家能下架商品，那不能下架呢？
每個方案都有利有弊，得綜合考量之後再看選擇哪個方案，甚至可以靈活配置；比如添加商品時就可以選擇該商品是提交訂單還是支付成功時鎖庫存。
D. 異常流程：
異常流程就是查看每一步是否會存在哪些風險。這個風險不是指流程上的風險，如果是流程上的風險就可以放到支線流程裡；比如支付訂單時商家下架了該商品。
而是指外在的一些風險，比如一定數量的用戶在同一時間提交訂單時，峰值是否會造成伺服器崩潰的情況？如果對接了第三方庫存管理系統，會不會出現在鎖定、扣除商品庫存不及時，造成用戶超拍的情況？
2. 場景驗證與反推：通過場景來驗證這個需求與解決方案
什麼叫場景驗證，說白了就是講一段故事，有人物事件地點動作等元素，通過這段故事來驗證這個解決方案有沒有問題：具體的流程上有問題？整個解決方案有問題？還是倒推需求有問題？在產品設計時有什麼需要注意的地方？
和前面的需求的挖掘一樣，場景驗證需要先設置角色、場景，設定好了之後代入進解決方案裡；可以以多種角色匹配不同的場景來代入，可能會發現不一樣的問題。
舉例：我這次就舉一個以前做的名為「免費送禮」的功能。初步的解決方案是，後臺人員挑選一部分商品到「免費送禮」這個區域，用戶在這個區域中有看中的商品時，就可以分享給朋友，朋友可以點開連結並參與，不管這個朋友是否是註冊過，當參與的人數足夠之後，就可以隨機抽獎了。
時間：這個功能對季節、一天內什麼時候分享沒有特定要求，所以可以略過；
地點：用戶分享對所處位置也沒有限制，也可以略過。
（前面提到過，時間地點這兩個因素對電商來說影響不大，經常可以忽略，但是對像美團、共享單車這樣的產品影響就相當大）
角色：希望是平臺上的全體用戶參加，越多越好；所以對商品的挑選就有要求，得大眾化。
我是一個較少使用電商平臺的用戶，當我進入「免費送禮」這個版塊時，我的第一反應可能是帶有疑慮的，會不會是騙人的？（所以在頁面首屏的banner上是否應該將規則簡短的說清楚，並且利用從眾心理，在頁面上加上當前已有多少人成功領取商品。）
門檻是否會很高，需要很多人才能完成？（所以制定參與人數規則時是否能降低參加門檻，比如50元的商品，只需要5個人參加；或者出於成本的控制，挑選價格不太高的商品。）
我發現我感興趣的商品很少甚至沒有怎麼辦？（所以初步方案中的由後臺人員挑選的商品才能進行分享這一規則，是否能改為商城內所有商品或除一部分特殊商品以外的商品都能分享？發現沒有，如果要解決這個問題，就要從頭改很多流程和功能的邏輯。）
我是否可以找一堆朋友天天來薅羊毛？（如果新老用戶都可以參與，為了防止被薅只有在參與的次數上做限制；那讓老用戶參與的目的在哪呢，是促活嗎？我們公司是一個創業公司，錢得花在鋼刃上， 是否就限制成只有新用戶才能參與呢。）
完整的分析還有很多，這裡我就不一一列舉了。
總結，上面通過場景驗證可以發現，是不是騙人的這個是產品頁面設計中要注意的問題；門檻是否會很高這個是制定具體規則需要注意的問題；感興趣的商品少這個就是整個解決方案可能存在問題；防止薅羊毛這個是具體的流程上有問題。
所以通過具體的場景驗證可以反推出一些可能存在的問題和需要注意的事項，只有提前把這些問題推演出來。如果一開始就沒發現這些問題，後面的需求排序，產品設計等步驟可能會存在較大的誤差，甚至是在做無用功。
因為你不能排除，把產品設計做好之後再來，場景推演的時候發現該需求是個偽需求，導致浪費時間做原型的情況，或者在設計原型時不斷發現之前本該發現的漏洞，原型不斷地推倒重來；也不能排除因為之前考慮不夠周全漏掉很多情況，可能該排二級卻排成了一級。
三、需求的排序
需求一窩蜂來了一堆之後，該怎麼排序呢？如果僅憑感覺，可能會存在一定的誤差。我認為可以通過緊急重要四象限法則來進行參考。
（網圖，侵刪）
那緊急和重要又是怎麼來判斷的呢？我的方法是通過以下幾個維度來參考：
緊急程度：
任務：是否是公司指派的緊急任務，比如領導明確要求多久之前需要完成。類型：上面我在需求記錄板塊提到我將需求類型分為運營類需求、bug類需求、創意類需求、優化類需求；比如bug類就比較緊急，創意類需求就比較相對不那麼緊急。重要程度：
定位：與企業的戰略定位，與產品的定位之間的相關程度。價值：價值就是前面提到的廣度、頻率、投入、產出等維度。以上就是我所總結的關於需求分析的方法論了，下面我舉一個從頭到尾完整分析的例子。
八、舉例
這是前年做過的一個功能，現在已下線了。
當時公司給了我一個需求，有一個外部團隊將要在我們商城內上線「醫療服務」的功能，也就是有一些醫院將作為商家在商城發布商品。商品主要是類似美團的團購券，用戶購買後可以去相應的醫院享受服務後核銷。而外部團隊會給出我一套具體方案，由我評審後進行開發。
首先可以對上線「醫療服務」功能這個需求進行分析，比如上線這個功能能覆蓋多少用戶？得到多少回報？和產品定位相不相符合？
但因為是公司確定要做的需求，所以就將這個外部團隊提供的這一整套方案看作是一個需求來進行分析。（所以需求的樣式是多種多樣的）
1. 需求分析
A. 角色、目的分析：
這個外部團隊是方案的提供方，目的在於通過這麼一個功能能為他們合作的線下醫院引流。而公司領導願意對接的原因在於，能豐富我們平臺的商品，同時希望創造一定的價值。
B. 定位分析：
首先，我們是公益農副產品的商城，和醫療服務肯定是不搭邊的；那麼有沒有辦法能縮小定位上的差距呢？我和團隊負責人聊了之後發現，他們是可以上線一些價格便宜的醫療服務，比如「1元的全面口腔檢查」。其實這樣性價比高的商品是可以進行一定包裝的，可以和公益進行掛鈎（但包裝要把握尺度，不然就是在欺騙用戶）。
C. 廣度、頻率分析：
像這樣的功的廣度頻率主要得看上線的商品。如果是像「1元的全面口腔檢查」這樣的商品，是能和我平臺的用戶群體高度重合的。因為並不是像感冒藥這樣，生病感冒的時候才有需求去購買。但受到醫院的地域限制，所以預計購買用戶的佔比可能就比較低；
而頻率肯定就相當低了。
D. 回報分析：
能創造多少金錢價值？當時我們根據商品的價值和預計有多少用戶購買（總用戶人數*預計的比例），然後根據返傭比例，做了一個大致的估計；
能新增多少用戶註冊量？這個就確實不好估計了，因為這個需求就不是為了我們平臺引流。
長期收益不光看這個功能帶來的收益，如果和這個團隊合作得可以，以後可能會有一些資源互換，更多的商業價值。
E. 投入分析：
這些線下醫院的對接是外部團隊進行，這部分投入就不需要我們負擔，我們只需投入人力進行開發；如果按照他們提供的方案，我們大概需要三周的開發時間。投入產出比預期的比值是合理的，投入小風險小
F. 數據分析：
我們平臺沒有相關數據；但是可以從美團這樣的平臺上通過此類商品的購買量來做一個預估。
G. 可行性分析：
他們提出的方案僅僅是業務層的功能，還得考慮用戶購買之後，商家核銷券這一支持層的功能，這些是客戶端上的；還得考慮管理後臺、商家後臺裡缺失的功能。
所以我們是否能找一些替代方案來解決呢？
2. 提出初步的解決方案
如果正向解決他們的需求，就是對他們的方案直接開發，平臺上缺失的功能也直接開發；但我們並不知道用戶對這個需求的接受程度。那我們是否可以用一些替代方案，先快速上到商城，有了數據之後再來考慮後續的迭代呢？
所以我的想法是逆向解決，也就是先將他們的一整套方案先進行切割成小的且獨立的板塊，利用現有平臺上能提供的功能對這些小版塊分別滿足；滿足不了的再進行技術評估，如果時間成本小那就開發，時間成本大就先暫時擱置。
當然，也得和需求的提供方，也就是那個外部團隊進行溝通、協調。
3. 將解決方案代入場景進行驗證與反推需求
完整的場景驗證應該是，角色代入到我的解決方案裡，然後進行模擬
從用戶進入商城，有哪些入口可以看到這些商品？看到時可能有哪些不同的想法？然後購買，一件甚至多件（贈送親戚朋友），購買之後可能多久去核銷？商家怎麼核銷？核銷之後評價，等等都是需要進行驗證的。
4. 對需求進行優先級排序
因為這個需求是公司明確表示需要馬上實施的，所以我將他們的方案進行切割，並且我進行一些修改後，分解了一堆小需求，然後討論，分別進行優先級排序。
以上就是我的需求方法論的全部內容了，如果有不足之處，還請大佬指出一起討論。
本文由 @橘鑽 原創發布於人人都是產品經理，未經作者許可，禁止轉載。
題圖來自Unsplash，基於CC0協議。