對于產品經理來說,，大多數(shù)的日常都是圍繞需求展開的——溝通需求,、實現(xiàn)需求等。那么對于需求這一內容,，如果做好正確理解,，相信會對后續(xù)實現(xiàn)提供很大幫助。

接著上一篇《需求方法論（1）：需求的理解,、來源、挖掘與記錄》

我認為得先理解需求是什么,？然后需求會從哪些地方來,？如果自己挖掘需求該怎么做,？需求來了之后該怎么記錄？記錄以后該怎么進行分析,？分析之后該怎么進行驗證,？驗證之后怎么進行排序？

所以我的需求方法論由七個部分組成：需求的理解,、需求的來源,、需求的挖掘、需求的記錄,、需求的分析,、需求的驗證、需求的優(yōu)先級排序,。

這篇文章是關于需求的分析,、驗證與排序,。

一、需求的分析

需求分析的目的在于這個需求做不做,，所以得分析這個需求的合理性,。

領導,、運營團隊,、還是用戶？不同人站的立場不同,，他們提出需求的目的也就不同,。前面也提到過，每個人說出的話語都是受到自己認知所左右的主觀意識的表達,，所以不能光看他們說的話,，還得去想為什么他們會說出這些話？是否受到自己所在立場的影響,？

如果是用戶提的,，那這個用戶是否是目標用戶？是重度使用的用戶還是一般用戶,？如果連提出者是什么身份都沒搞清楚的話有可能會大大影響后面的判斷,。

舉例：比如通過訂單數(shù)量可以初步判斷該用戶是否是重度用戶；通過訂單均價可以判斷該用戶大概的收入層級,，等等,。

前面提到過,，時代雖然變了,，但是需求沒變,，變的只有需求的解決方案。所以得“透過顯像看本質”,，挖掘提出者最本質的需求,。

所以需求又可以分為：表面需求、本質需求,、產品需求,。表面需求就是他人提出的需求，本質需求就是提出者的目的,，產品需求就是我們能給出的解決方案,。

如果是用戶提出的需求，一般用戶喜歡直接給出解決方案,，會直接指出他覺得應該怎么做,。那么，他提的是不是偽需求,？是否只能滿足一小部分人,，而會損害大部分人的體驗？他提出的就是最好的解決方案嗎,？如果不解決用戶會有多痛苦,？

如果是領導提出的需求，他是出于戰(zhàn)略,、商業(yè)上的考量,？他提出的就是最佳選擇嗎？前面提到過,，公司需求和用戶需求可能是存在矛盾點的,，所以需要平衡這些矛盾點。

舉例：比如領導想要在某一板塊加上另一頁面的引導廣告彈窗,，那這個彈窗是否會影響到用戶的操作體驗,？可能領導的目的在于為那個板塊增加流量，那引導點是否加在其他地方會更好,。

如果有，沖突有多大,？做了這個功能后會顯得格格不入嗎,？會不會影響用戶對產品的看法？有沒有辦法縮小這個沖突,？

最多能覆蓋多少目標用戶？會不會影響其他用戶的使用體驗,？并不是要精確的覆蓋人數(shù),，但是需要預想一下大概的比例。

預計有多少用戶會經常使用,？多少用戶使用頻率一般,？而這個經常使用和頻率一般又需要怎樣來定義？

可以先預想一下,，大概有多少用戶,，他們每天、一周,、一月使用這個功能的頻率,。

能創(chuàng)造多少金錢價值,？能新增多少用戶量,？能促活多少用戶？是否有長期收益,？有沒有辦法能預測出大概的數(shù)據(jù)指標,，并對照這個數(shù)據(jù)指標可以來看實現(xiàn)的效果。

大概需要投入多少金錢,？人力？時間,？這里的投入是一個大概的估計,，可能并不準確，因為沒有具體的方案,，只能篩選一些明顯投入過大,，明顯不合理的需求。

如果有相應的數(shù)據(jù)能支持分析那最好,，就是錦上添花，畢竟數(shù)據(jù)比人為主觀判斷更客觀一些,。如果沒有,，這一條也可以略過

為什么這一條我放在了最后而不是價值分析前面,？可能這個需求一看，現(xiàn)有條件就實現(xiàn)不了,，就不用進行后面的價值分析了啊,。

所以我寫的是現(xiàn)有條件，如果現(xiàn)有條件不支持，而需求確實有好處,，那就后續(xù)跟進,。

二、需求的驗證

為什么要驗證需求,？

需求來了之后很多時候我們都是靠感覺來判斷,，可能會出現(xiàn)對這個需求理解不到位的情況，造成一些誤判,。這時就需要提出一個初步的解決方案,，提出的過程中會更詳細地拆解需求，然后再進行驗證與反推,，甚至可能會對之前需求分析出來的結果進行一些矯正,，比如現(xiàn)在沒法實現(xiàn)，那這時可能就得降低優(yōu)先級,。

當然,，如果是一些小需求就沒必要進行這一步了。

1. 肯定：正面解決用戶的需求,，設計一套初步的解決方案,，可以用流程圖展示出來。

2. 否定：讓用戶放棄這個想法,，比如找一些替代方案,，哪怕效果沒那么好，后續(xù)再改善,。

需要注意的是,，設計解決方案的時候各種場景、各種流程都要想清楚：正常主線流程,、各種分支流程,、各種可選流程、各種異常流程,。只有把各種流程想清楚了,，才能對需求做出相對準確的判斷。

舉例：下圖是我之前寫的一篇文章《從0到1構建電商平臺之訂單系統(tǒng)（2）：支付訂單》”里的一個流程圖,，畫的就是在客戶端的支付訂單這個頁面里的一系列后端判斷,。我就以這個流程圖來舉例。（圖有一些地方不一樣,，在那篇文章中有說明）

A. 主線流程：

首先在提交訂單頁面成功提交訂單后，訂單生成,，并進入支付頁面,，此時就會鎖定庫存；然后支付訂單時會判斷該商品的商品狀態(tài)是否正常、sku信息是否更改,；都沒問題時就會由用戶輸入支付密碼,，支付成功就會生成一個待發(fā)貨訂單，然后訂單發(fā)貨之后就會扣除庫存,。

這就是一個用戶使用,，基本、正常的主線流程,。

B. 分支流程：

比如圖中的,，當訂單中有商品處于下架狀態(tài)時、sku信息更改了時就會自動取消訂單,，并給與提示,；當未成功支付時就會生成待付款訂單，過了N分鐘之后還不能支付成功,，就自動取消訂單并釋放庫存,。

這些就是主線流程上可能存在的分支流程。

C. 可選流程：

可選流程的意思就是質疑自己,，當前做出的主線流程是否是最好的,，有沒有更好的解決方案？

比如鎖定庫存,，我設計的是提交訂單即鎖庫存,，那是否能支付成功才鎖庫存呢？

比如用戶提交訂單之后,，訂單處于待付款時,，我設計的是商家能下架商品，那不能下架呢,？

每個方案都有利有弊，得綜合考量之后再看選擇哪個方案,，甚至可以靈活配置,；比如添加商品時就可以選擇該商品是提交訂單還是支付成功時鎖庫存。

D. 異常流程：

異常流程就是查看每一步是否會存在哪些風險,。這個風險不是指流程上的風險,，如果是流程上的風險就可以放到支線流程里；比如支付訂單時商家下架了該商品,。

而是指外在的一些風險,，比如一定數(shù)量的用戶在同一時間提交訂單時，峰值是否會造成服務器崩潰的情況,？如果對接了第三方庫存管理系統(tǒng),，會不會出現(xiàn)在鎖定、扣除商品庫存不及時，造成用戶超拍的情況,？

什么叫場景驗證,，說白了就是講一段故事，有人物事件地點動作等元素,，通過這段故事來驗證這個解決方案有沒有問題：具體的流程上有問題,？整個解決方案有問題？還是倒推需求有問題,？在產品設計時有什么需要注意的地方,？

和前面的需求的挖掘一樣，場景驗證需要先設置角色,、場景,，設定好了之后代入進解決方案里；可以以多種角色匹配不同的場景來代入,，可能會發(fā)現(xiàn)不一樣的問題,。

舉例：我這次就舉一個以前做的名為“免費送禮”的功能。初步的解決方案是,，后臺人員挑選一部分商品到“免費送禮”這個區(qū)域,，用戶在這個區(qū)域中有看中的商品時，就可以分享給朋友,，朋友可以點開鏈接并參與,，不管這個朋友是否是注冊過，當參與的人數(shù)足夠之后,，就可以隨機抽獎了,。

時間：這個功能對季節(jié)、一天內什么時候分享沒有特定要求,，所以可以略過,；

地點：用戶分享對所處位置也沒有限制，也可以略過,。

（前面提到過,，時間地點這兩個因素對電商來說影響不大，經?？梢院雎?，但是對像美團、共享單車這樣的產品影響就相當大）

角色：希望是平臺上的全體用戶參加,，越多越好,；所以對商品的挑選就有要求，得大眾化,。

我是一個較少使用電商平臺的用戶,，當我進入“免費送禮”這個版塊時,，我的第一反應可能是帶有疑慮的，會不會是騙人的,？（所以在頁面首屏的banner上是否應該將規(guī)則簡短的說清楚,，并且利用從眾心理，在頁面上加上當前已有多少人成功領取商品,。）

門檻是否會很高,，需要很多人才能完成？（所以制定參與人數(shù)規(guī)則時是否能降低參加門檻,，比如50元的商品,，只需要5個人參加；或者出于成本的控制,，挑選價格不太高的商品,。）

我發(fā)現(xiàn)我感興趣的商品很少甚至沒有怎么辦？（所以初步方案中的由后臺人員挑選的商品才能進行分享這一規(guī)則,，是否能改為商城內所有商品或除一部分特殊商品以外的商品都能分享,？發(fā)現(xiàn)沒有，如果要解決這個問題,，就要從頭改很多流程和功能的邏輯,。）

我是否可以找一堆朋友天天來薅羊毛？（如果新老用戶都可以參與,，為了防止被薅只有在參與的次數(shù)上做限制,；那讓老用戶參與的目的在哪呢，是促活嗎,？我們公司是一個創(chuàng)業(yè)公司,，錢得花在鋼刃上， 是否就限制成只有新用戶才能參與呢,。）

完整的分析還有很多,，這里我就不一一列舉了。

總結,，上面通過場景驗證可以發(fā)現(xiàn),，是不是騙人的這個是產品頁面設計中要注意的問題；門檻是否會很高這個是制定具體規(guī)則需要注意的問題,；感興趣的商品少這個就是整個解決方案可能存在問題；防止薅羊毛這個是具體的流程上有問題,。

所以通過具體的場景驗證可以反推出一些可能存在的問題和需要注意的事項,，只有提前把這些問題推演出來。如果一開始就沒發(fā)現(xiàn)這些問題,，后面的需求排序,，產品設計等步驟可能會存在較大的誤差,，甚至是在做無用功。

因為你不能排除,，把產品設計做好之后再來,，場景推演的時候發(fā)現(xiàn)該需求是個偽需求，導致浪費時間做原型的情況,，或者在設計原型時不斷發(fā)現(xiàn)之前本該發(fā)現(xiàn)的漏洞,，原型不斷地推倒重來；也不能排除因為之前考慮不夠周全漏掉很多情況,，可能該排二級卻排成了一級,。

三、需求的排序

需求一窩蜂來了一堆之后,，該怎么排序呢,？如果僅憑感覺，可能會存在一定的誤差,。我認為可以通過緊急重要四象限法則來進行參考,。

（網圖,，侵刪）

那緊急和重要又是怎么來判斷的呢,？我的方法是通過以下幾個維度來參考：

緊急程度：

1. 任務：是否是公司指派的緊急任務，比如領導明確要求多久之前需要完成,。

2. 類型：上面我在需求記錄板塊提到我將需求類型分為運營類需求,、bug類需求、創(chuàng)意類需求,、優(yōu)化類需求,；比如bug類就比較緊急，創(chuàng)意類需求就比較相對不那么緊急,。

重要程度：

1. 定位：與企業(yè)的戰(zhàn)略定位,，與產品的定位之間的相關程度。

2. 價值：價值就是前面提到的廣度,、頻率,、投入、產出等維度,。

以上就是我所總結的關于需求分析的方法論了,，下面我舉一個從頭到尾完整分析的例子。

八,、舉例

這是前年做過的一個功能,，現(xiàn)在已下線了。

當時公司給了我一個需求,，有一個外部團隊將要在我們商城內上線“醫(yī)療服務”的功能,，也就是有一些醫(yī)院將作為商家在商城發(fā)布商品,。商品主要是類似美團的團購券，用戶購買后可以去相應的醫(yī)院享受服務后核銷,。而外部團隊會給出我一套具體方案,，由我評審后進行開發(fā)。

首先可以對上線“醫(yī)療服務”功能這個需求進行分析,，比如上線這個功能能覆蓋多少用戶,？得到多少回報？和產品定位相不相符合,？

但因為是公司確定要做的需求,，所以就將這個外部團隊提供的這一整套方案看作是一個需求來進行分析。（所以需求的樣式是多種多樣的）

A. 角色,、目的分析：

這個外部團隊是方案的提供方,，目的在于通過這么一個功能能為他們合作的線下醫(yī)院引流。而公司領導愿意對接的原因在于,，能豐富我們平臺的商品,，同時希望創(chuàng)造一定的價值。

B. 定位分析：

首先,，我們是公益農副產品的商城,，和醫(yī)療服務肯定是不搭邊的；那么有沒有辦法能縮小定位上的差距呢,？我和團隊負責人聊了之后發(fā)現(xiàn),，他們是可以上線一些價格便宜的醫(yī)療服務，比如“1元的全面口腔檢查”,。其實這樣性價比高的商品是可以進行一定包裝的,，可以和公益進行掛鉤（但包裝要把握尺度，不然就是在欺騙用戶）,。

C. 廣度,、頻率分析：

像這樣的功的廣度頻率主要得看上線的商品。如果是像“1元的全面口腔檢查”這樣的商品,，是能和我平臺的用戶群體高度重合的,。因為并不是像感冒藥這樣，生病感冒的時候才有需求去購買,。但受到醫(yī)院的地域限制,，所以預計購買用戶的占比可能就比較低；

而頻率肯定就相當?shù)土恕?/p>

D. 回報分析：

能創(chuàng)造多少金錢價值,？當時我們根據(jù)商品的價值和預計有多少用戶購買（總用戶人數(shù)*預計的比例）,，然后根據(jù)返傭比例，做了一個大致的估計,；

能新增多少用戶注冊量,？這個就確實不好估計了，因為這個需求就不是為了我們平臺引流,。

長期收益不光看這個功能帶來的收益,，如果和這個團隊合作得可以，以后可能會有一些資源互換,，更多的商業(yè)價值,。

E. 投入分析：

這些線下醫(yī)院的對接是外部團隊進行，這部分投入就不需要我們負擔,，我們只需投入人力進行開發(fā),；如果按照他們提供的方案，我們大概需要三周的開發(fā)時間,。投入產出比預期的比值是合理的,，投入小風險小

F. 數(shù)據(jù)分析：

我們平臺沒有相關數(shù)據(jù)；但是可以從美團這樣的平臺上通過此類商品的購買量來做一個預估,。

G. 可行性分析：

他們提出的方案僅僅是業(yè)務層的功能,，還得考慮用戶購買之后，商家核銷券這一支持層的功能,，這些是客戶端上的,；還得考慮管理后臺、商家后臺里缺失的功能,。

所以我們是否能找一些替代方案來解決呢,？

如果正向解決他們的需求，就是對他們的方案直接開發(fā),，平臺上缺失的功能也直接開發(fā),；但我們并不知道用戶對這個需求的接受程度。那我們是否可以用一些替代方案,，先快速上到商城,，有了數(shù)據(jù)之后再來考慮后續(xù)的迭代呢？

所以我的想法是逆向解決,，也就是先將他們的一整套方案先進行切割成小的且獨立的板塊,，利用現(xiàn)有平臺上能提供的功能對這些小版塊分別滿足；滿足不了的再進行技術評估,，如果時間成本小那就開發(fā),，時間成本大就先暫時擱置。

當然,，也得和需求的提供方,，也就是那個外部團隊進行溝通、協(xié)調,。

完整的場景驗證應該是,，角色代入到我的解決方案里,，然后進行模擬

從用戶進入商城，有哪些入口可以看到這些商品,？看到時可能有哪些不同的想法,？然后購買，一件甚至多件（贈送親戚朋友）,，購買之后可能多久去核銷,？商家怎么核銷？核銷之后評價,，等等都是需要進行驗證的,。

因為這個需求是公司明確表示需要馬上實施的，所以我將他們的方案進行切割,，并且我進行一些修改后,，分解了一堆小需求，然后討論,，分別進行優(yōu)先級排序,。

以上就是我的需求方法論的全部內容了，如果有不足之處,，還請大佬指出一起討論,。

本文由 @橘鉆 原創(chuàng)發(fā)布于人人都是產品經理 

題圖來自Unsplash，基于CC0協(xié)議,。