以B端系統案例，解析需求調研5個方法

-------

對產品經理來說，絕大多數工作時間都是圍繞需求展開的——需求分析、需求調研、跟進實現需求等。

那麼關於需求調研這部分，一般都有哪些落地的調研方法呢？我們又該如何使用這些方法呢？

本篇結合《後端產品經理寶典》書中的內容，單從需求調研案例出發，看幾種常用的調研方法。

▐ 一、過濾需求的方法

做後端系統，要學會的第乙個技能就是砍需求。也就是過濾需求。

這不是乙個貶義詞，反而是體現後端產品價值判斷的基礎。

過濾需求的方法，就是通過一定的手段判斷需求是否是偽需求，應該被過濾掉。

後端產品的出發點就是幫助業務使用者，因此在調研需求的時候要模擬業務的場景，分析業務使用者提到的需求是否能解決他的問題。

如果不能幫助使用者，那麼這個需求就可能是偽需求。

以下面的案例說明：

背景：「貨到付款」型別的訂單會因為缺貨而無法發出，如果超過一定的時間，客服就會跟顧客溝通，幫顧客取消訂單。

需求：由於這種訂單的數量還是蠻多的，逐個取消太費時間，因此業務使用者要求在「缺貨訂單」列表頁增加「批量取消訂單」按鈕。

因此，該需求是個偽需求，應該被過濾掉。

專門的系統做專職功能，有助於合理的產品體系建設。

因此需求調研的時候，可以通過系統的定位，判斷需求是否應該在該系統完成。

如果不屬於該系統範疇，那麼直接說服需求方更換方案。以

下面的案例說明：

背景：crm系統（顧客關係管理系統）有乙個顧客標籤生成功能，就是根據顧客的消費行為資料，自動對應關聯上標籤，如優質顧客、高潛力顧客、欺詐顧客等。

需求：業務使用者提出需求，除了做上述的基礎標籤之外，還要做出英語版本的標籤（就是把標籤文案翻譯成英文），這樣歐美員工可以在英語版本的系統下使用。

所以應該由sms根據cms提供的基礎標籤資料，自己做二次的衍生。

之所以這樣，首先是為了避免未來更多語言版本的擴充套件需求或更多系統提出類似的需求；

其次，crm系統已經完成了「接力賽」的第一棒，創造了基礎資料，那麼其他系統要特殊化使用，完全可以自行進行特殊化處理，無需耦合回crm系統。

結論：案例的需求本身是真需求，並且實現上也沒難度，但是該功能的定位超出了本系統範疇，專門系統做專職功能，化衍生需求應該在下游執行。

否則，耦合性過高只會增加系統的複雜程度，難以維護和擴充套件。

▐ 二、拆分和聚合的方法

業務使用者提出乙個需求，很可能只是短短的一段話。

但是不要高興太早，可能這一句話暗含了很多線索，因此要善於拆分：

先找他要解決的核心問題，再圍繞核心點，理清前、後、左、右、上、下的旁系需求點。

每個需求點再當做乙個子需求進行調研，最後再聚合在一起。

以下面的案例說明：

背景：訂單業務的型別很多，訂單退貨之後需要建立售後單據，但是因為數量大，所以花費很多人力，且手動建立有出錯的風險。

需求：業務提出的需求是「增加退貨訂單自動建立售後單的功能」，這是個一句話需求。

自營訂單、第三方訂單、貨到付款訂單、先款後貨訂單、部分退貨訂單、完全退貨訂單、服裝事業部訂單、電子事業部訂單等，其中每乙個維度就相當於乙個小需求。

這裡不一一展開。

拆分法是對單個需求分解成若干小需求進行調研，聚合法相反，是找到許多個相互關聯的小需求的共性，然後統籌成乙個大需求去完成。例如：

由於業務使用者分散在不同的部門，各自為政，於是張

三、李四可能都對乙個業務流程有相同的需求，或者對同乙個功能有相同的優化期望，結果倆人分別提了需求過來。那麼產品經理就要找到二者背後的相關性和交叉區。

然後統籌規劃，聚合在一起當作乙個需求來調研，最終輸出乙個整體的需求調研結果。

▐ 三、利用輔助功能調研需求

調研產品現有功能，可以用來確認原有功能的邏輯，或者確定新需求方案是否可行。

比如業務使用者需要更新乙個功能，為了避免更新出錯或遺漏，產品經理需要知道修改前和修改後是否會能正常執行。

最基礎的辦法就是自己設計乙個測試用例，記錄操作方式、狀態變化、資料流向等。看看下面的例子：

背景：從銷售**獲取到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，可以予以淘汰。

以上的維度、分值和權重可以根據實際情況自行設計，但是要多考察和驗證什麼樣的引數是較為合理的。並且也不能唯權重得分是從，而只是把它當做乙個輔助工具。

▐ 六、其他需求調研工具

需求調研適合核心環節，該過程就會涉及到很多任務具或分析方法，以確保需求調研高效、高質量。

比如問卷調查、訪談、名義小組會議、頭腦風暴法、觀察法、親和圖、蒙特卡洛技術、魚骨圖、提示清單等。

（完）圖書推薦

▊《後端產品經理寶典：泛後台pm知識與實戰一本通》

趙世哲 著

隨著產品經理行業的發展，後端產品開始成為企業提公升業務效率的關鍵，是產品經理學習和高階的熱點領域。後端產品與b端產品有一定相似性，但也有所不同，新入行的產品經理在積極學習b端產品的同時，也應該學習後端產品。

本書是市場上少有的針對後端產品經理職業學習和高階的圖書，內容來自筆者多年一線工作經驗的總結，每乙個知識點都源於實戰，每乙個章節都有歸納總結。本書的知識成體系，方法可複製，收穫可預期，能夠幫助讀者獲得寶貴的一手知識，輕鬆入職，並使個人能力得到穩定提公升。

什麼是B端C端

b，business 通常為企業或商家為工作或商業目的而使用的系統型軟體 工具或平台。c，consumer 意為消費者 個人使用者或終端使用者，使用的是客戶端。b端，面對企業客戶，多為乙個群體使用，本質是滿足工作需求，多為多種功能的整合，講究協同合作。使用b端往往是長時間 沉浸式，b端是服務於公司或...

B端專案需求 如何識別系統需求？

今天結合專案與大家討論需求的分析階段和相關完成相關分析任務時使用的技術。在需求分析階段有兩個關鍵任務，即根據系統需求確定系統需求和建立系統需求模型。通常，負責開發軟體專案的專案經理或系統分析師需要盡可能多地了解軟體專案中涉及的業務活動的詳細資訊，因為只有熟悉專案業務活動的詳細資訊才能熟悉專案，確保系...

B 以貳之名（新生賽）

b.以貳之名 description 眾所周知，dv學長和tyy學長是關係非常好的 他們經常以 兒子 互稱。有一天dv學長給tyy學長出了一道題，如果tyy學長解出了這道題就可以擁有一半的糖果，否則dv學長將吃掉所有的糖果。tyy學長非常想吃到糖果，你能幫幫她嘛？具體來說 現在有從2到n這n 1個的...