對產品經理來說，絕大多數工作時間都是圍繞需求展開的——需求分析、需求調研、跟進實現需求等。那麼關於需求調研這部分，一般都有幾種調研方法呢？我們又該如何使用這些方法呢？
需求調研是需求實現的前提。
需求調研主要內容有：瞭解需求背景、明確需求目標、過濾不當需求、確定大致方案。
需求的使用者是誰？需求解決的核心問題是什麼？使用場景有哪些？哪些是主要和次要場景？業務的流程是什麼？除了主要業務還有哪些流程可能使用這個功能？除了本系統還有哪些系統會關聯到這個功能……
這就是需求調研的“十萬個為什麼“。
本篇結合《後端產品經理寶典》書中的內容，單從需求調研案例出發，看幾種常用的調研方法。
一、過濾需求的方法
做後端系統，要學會的第一個技能就是砍需求。也就是過濾需求。
這不是一個貶義詞，反而是體現後端產品價值判斷的基礎。
過濾需求的方法，就是透過一定的手段判斷需求是否是偽需求，應該被過濾掉。
1. 使用者場景模擬法
後端產品的出發點就是幫助業務使用者，因此在調研需求的時候要模擬業務的場景，分析業務使用者提到的需求是否能解決他的問題。
如果不能幫助使用者，那麼這個需求就可能是偽需求。
以下面的案例說明：
背景：“貨到付款”型別的訂單會因為缺貨而無法發出，如果超過一定的時間，客服就會跟顧客溝通，幫顧客取消訂單。
需求：由於這種訂單的數量還是蠻多的，逐個取消太費時間，因此業務使用者要求在“缺貨訂單”列表頁增加“批次取消訂單”按鈕。
分析：調研到業務操作場景,是先找到該類缺貨訂單，然後和顧客溝通，顧客同意刪除，才進行刪除。也就是逐個溝通確認，再逐個取消訂單的，所以“批次取消訂單”無法被有效使用。
因此，該需求是個偽需求，應該被過濾掉。
2. 功能歸屬分析
專門的系統做專職功能，有助於合理的產品體系建設。
因此需求調研的時候，可以透過系統的定位，判斷需求是否應該在該系統完成。
如果不屬於該系統範疇，那麼直接說服需求方更換方案。以
下面的案例說明：
背景：CRM系統（顧客關係管理系統）有一個顧客標籤生成功能，就是根據顧客的消費行為資料，自動對應關聯上標籤，如優質顧客、高潛力顧客、欺詐顧客等。
需求：業務使用者提出需求，除了做上述的基礎標籤之外，還要做出英語版本的標籤（就是把標籤文案翻譯成英文），這樣歐美員工可以在英語版本的系統下使用。
分析：調研到翻譯之後的標籤不是在CRM系統使用的，而是給到SMS（客服系統）使用的。
所以應該由SMS根據CMS提供的基礎標籤資料，自己做二次的衍生。
之所以這樣，首先是為了避免未來更多語言版本的擴充套件需求或更多系統提出類似的需求；
其次，CRM系統已經完成了“接力賽”的第一棒，創造了基礎資料，那麼其他系統要特殊化使用，完全可以自行進行特殊化處理，無需耦合回CRM系統。
結論：案例的需求本身是真需求，並且實現上也沒難度，但是該功能的定位超出了本系統範疇，專門系統做專職功能，化衍生需求應該在下游執行。
否則，耦合性過高只會增加系統的複雜程度，難以維護和擴充套件。
二、拆分和聚合的方法
1. 拆分需求法
業務使用者提出一個需求，很可能只是短短的一段話。
但是不要高興太早，可能這一句話暗含了很多線索，因此要善於拆分：
先找他要解決的核心問題，再圍繞核心點，理清前、後、左、右、上、下的旁系需求點。
每個需求點再當做一個子需求進行調研，最後再聚合在一起。
以下面的案例說明：
背景：訂單業務的型別很多，訂單退貨之後需要建立售後單據，但是因為數量大，所以花費很多人力，且手動建立有出錯的風險。
需求：業務提出的需求是“增加退貨訂單自動建立售後單的功能”，這是個一句話需求。
該一句話需求，其實包含了多種具體的訂單型別和場景，那麼我們就要拆分調研，拆分的維度比如：
自營訂單、第三方訂單、貨到付款訂單、先款後貨訂單、部分退貨訂單、完全退貨訂單、服裝事業部訂單、電子事業部訂單等，其中每一個維度就相當於一個小需求。
這裡不一一展開。
2. 聚合需求法
拆分法是對單個需求分解成若干小需求進行調研，聚合法相反，是找到許多個相互關聯的小需求的共性，然後統籌成一個大需求去完成。例如：
由於業務使用者分散在不同的部門，各自為政，於是張三、李四可能都對一個業務流程有相同的需求，或者對同一個功能有相同的最佳化期望，結果倆人分別提了需求過來。那麼產品經理就要找到二者背後的相關性和交叉區。
然後統籌規劃，聚合在一起當作一個需求來調研，最終輸出一個整體的需求調研結果。
三、利用輔助功能調研需求
調研產品現有功能，可以用來確認原有功能的邏輯，或者確定新需求方案是否可行。
比如業務使用者需要更新一個功能，為了避免更新出錯或遺漏，產品經理需要知道修改前和修改後是否會能正常執行。
最基礎的辦法就是自己設計一個測試用例，記錄操作方式、狀態變化、資料流向等。看看下面的例子：
背景：從銷售網站獲取到OMS系統（訂單管理系統）的訂單資訊中帶著顧客的郵箱。顧客下完單，可能會在銷售網站修改郵箱，而此時已經獲取到OMS的歷史訂單中的郵箱是不變的。
需求：顧客若在銷售網站修改郵箱，要求已獲取到OMS的該顧客的訂單中的郵箱也要同步修改。
分析：需求是很明白的，也有它的意義，但有風險。
因為我們知道訂單資訊貫穿於整個訂單流轉過程中，牽扯到訂單編輯、稽核、取消、配貨、發貨等，而這些環節跳轉的觸發條件可能就是某個資訊更新（這裡面就可能包括有郵箱更新）。
因此，更新郵箱是否會影響流程中的某些環節，一時間很難準確知道。
於是，我們可以採用預測試的方式，設計測試用例，在測試機執行一些訂單，觀察各個環節郵箱變更的影響，然後收集起來分析對策。
測試法就像是探雷一樣，主要用來解決未知風險點。這個方式的重點是記錄和分析操作前狀態、操作位點、操作後狀態、操作後觸發的連鎖反應、資料流向等。
四、“拔蘿蔔帶出泥”的方式調研需求
調研需求時，產品經理要拔蘿蔔帶出泥,挖掘使用者沒看到的需求點和價值。
舉例說明：
背景：公司入駐到銷售平臺後，銷售平臺會對入駐的店鋪的違規行為進行罰款。
需求：業務使用者提出需求，將銷售平臺的罰款資料抓取到訂單系統，關聯訂單資料，以便進行人工分析。
分析：
第一步，先拆分需求，確定什麼是罰款資料，總共有哪些罰款種類，需要對接哪些罰款種類，罰款資料與訂單系統關聯方式是什麼，是否都能關聯到，關聯不到怎麼辦，銷售平臺是否已經提供了公用的罰款介面，Token（請求許可權）如何獲取，抓取頻率怎麼樣，資料增長幅度多大，獲取之後做哪些展示和搜尋，使用者許可權怎麼設定，需要和訂單系統做哪些互動，該需求的價值是什麼……
第二步，挖掘需求：是否需要作分析功能，分析功能的規則是什麼；是否需要做監控和預警，是否需要指派負責人；其他業務人員是否也有類似需求，其他平臺是否也有類似需求……
透過“拔蘿蔔帶出泥”的方式，連帶出更多需求點。將上述調研結果重新組裝起來，得到一個系統化的完整需求。
羅列出需求要點和對應的驗收目標，這樣使得需求具象化，同時又不會遺漏細節，內部充實，外部閉環，並且進行了價值挖掘，做成控制閾值、預警、責任人分派、趨勢分析、損失分析等高價值的功能，超出業務的預期。
五、需求得分權重法
該方法的思路就是將需求質量的維度進行權重，然後對需求進行打分，根據最終得分的多少排列順序。
如表所示，採用五個維度：先`先`重要、緊急、收益、成本、風險，其中成本和風險是給予負分，五個維度的分值權重分別為30%、30%、20%、10%、10%。
那麼一旦對需求打了分，就可以用分數*權重，得到最終得分。
注意：負分的要減。並且為了方便計算，分值最好設定0.5-5.0之間，或者0-10之間。這樣避免打分的跨度過大出現較大偏差。
如表所示，需求1的得分=6*30% 6*30% 8*20%-3*10%-7*10%=4.6。而需求2得分3.5，需求3的得分為-0.1。
由此可以判斷需求的價值順序為：需求1>需求2>需求3。對於需求3，可以予以淘汰。
以上的維度、分值和權重可以根據實際情況自行設計，但是要多考察和驗證什麼樣的引數是較為合理的。並且也不能唯權重得分是從，而只是把它當做一個輔助工具。
六、其他需求調研工具
需求調研適合核心環節，該過程就會涉及到很多工具或分析方法，以確保需求調研高效、高質量。
比如問卷調查、訪談、名義小組會議、頭腦風暴法、觀察法、親和圖、蒙特卡洛技術、魚骨圖、提示清單等。
以上整理自《後端產品經理寶典》。
#專欄作家#
本文原創釋出於人人都是產品經理，未經作者許可，禁止轉載。
題圖來自Unsplash，基於CC0協議