作為產品經理，當你接到需求時，是直接摩拳擦掌開始梳理需求流程呢還是首先進行需求調研呢？作者從經驗出發，對B端產品的需求調研進行了梳理總結，與大家分享。
需求調研的第一步是確定需求背景，那麼應該如何確定需求背景呢？
一、何為需求？需求=預期-現狀
需求是用戶在產品使用過程中對產品的預期和使用現狀的差距；B端產品的使用者為個人，但實際服務對象是企業或組織，企業使用B端產品的目的是為了降本增效，幫助企業解決實際問題提高工作效率，當問題未得到解決或未得到高效解決的時候，就會產生需求。
以商家管理系統中的訂單篩選功能為例，在商家管理系統中，平臺會為商家提供訂單篩選功能，篩選字段包括訂單狀態、物流狀態等；訂單篩選功能作為搜索框架的一部分，核心要解決的問題是幫店主快速精準的定位到他要找的某類訂單，並將同一類型的訂單聚類展示；映射到實際的應用場景中，店主A昨天直播賣貨倆小時，產生1000條新訂單，一覺醒來發現新增500條退貨申請，他速速打開商家管理後臺要統一查看哪些商品被退貨了，但是平臺沒有按照訂單分類篩選的功能，他只能導出訂單在excel表格中進行篩選，在excel表格中要看到完整信息還需要調整表格格式，讓他格外頭疼，這時候就產生了在訂單列表中新增按照訂單類型篩選的需求。
二、何為需求的背景？
B端產品需求背景是指需求產生的原因及想達到的目標，也就是需要分析誰(who)需要通過怎樣的途徑(how)去達到什麼目標(what)，可以提煉為what、who、how三個核心元素：
what:是指本次項目目標，在進行背景分析時，我們需要明確項目目標，在明確項目目標的前提下，可更清晰的確定需求的邊界;
Who：是指本次項目的干係人，包括直接干係人和間接干係人，我們需要盡可能窮盡的確定需求干係人並對其進行用戶訪談，通過用戶訪談確定干係人目前的問題及其關註點以及需求的重要程度，並以此進行後期的功能設計；
How：是指該項目的策略級實施方案，通過對需求進行背景分析，我們需要確定項目的策略級實施方案，並根據干係人關註點、項目目標、項目資源確定當前最優解決方案。
三、如何進行需求的背景分析？
接下來我將以告警系統為例，從目標的確定、干係人分析、問題分析三個層面來梳理怎樣對需求進行背景分析。
1. 確定項目目標
項目目標是貫穿整個項目周期的產品方向，B端項目的目標通常是基於當前的業務形態制定的，且每個版本均需明確該版本的項目目標。
明確的項目目標可幫助我們確定產品的核心功能，一方面產品經理可專註於產品核心功能進行產品設計，在滿足核心功能的基礎上儘量做功能減法，以確保每個功能每一步操作都是必須的；另外一方面，明確的目標也可以減少時間和開發資源的投入，在項目各參與方都明確項目目標的前提下，需求溝通、產品設計、項目開發、項目驗收都會更高效的進行，且明確的目標可減少項目中的需求變更。
而在項目目標不明確的情況下，產品經理對產品核心功能把控不到位，無法明確的判斷哪個功能必須要，哪個功能可以不要，最終導致產品中有很多非必須功能，一則影響用戶實際使用，二則增加項目成本。
那麼，該如何確定項目目標呢？確定項目目標的關鍵是明確【業務場景+當前情況+目標】；具體的業務場景是需求分析的基礎，業務場景具有故事化的功效，可幫助產品經理進行產品設計，也可幫助技術同學理解需求；明確當前情況可確定當前的問題，而目標即是需求人對產品的期望，通過明確現狀期望即可提煉出產品需求。
比如在上面所列舉的訂單列表中增加按照訂單類型篩選功能的需求，明確的項目目標是：在商家需要批量查看某種類型商品比如下單但是未付款或者申請退款的商品時，商家無法直接在系統中進行篩選，而是要導出到excel表格中進行篩選，所以本次項目目標是解決商家無法快速精準的批量查看某種同類訂單的問題。
2. 確定干係人
確定干係人是需求分析必不可少的一個環節；與C端產品需求分析過程中的用戶分析不同，B端產品的干係人分析不僅包括產品的用戶(直接使用人)，也包括產品的直接和間接相關人。
確定干係人是為了盡可能窮盡的確定項目相關人員，以進行用戶訪談，充分瞭解項目干係人的關註點以及擔心點，更充分的瞭解業務以便進行產品設計。
如果不明確項目干係人，導致需求調研不充分，可能會在項目開發過程中臨時更換需求而導致項目延期；在業務複雜，機構內人員組織架構複雜的情況下，用戶調研不充分也可能導致項目上線後才發現項目在符合一方使用需求的情況下影響了另一方的直接利益。
那麼我們應該如何判斷項目干係人呢？干係人可從目標和風險兩個維度進行識別：
（1）根據目標識別關鍵干係人
- 直接相關部門負責人：因為直接相關部門通常是該產品的使用部門，通過對該部門負責人進行用戶訪談，可以明確該部門員工在產品使用過程中的工作流程，並瞭解該項目是否會涉及員工kpi考核等問題；
- 間接相關部門負責人：因為映射到實際業務流程中，間接相關部門會為直接相關部門提供業務支持，在產品設計過程中，也需要考慮他們之間的信息交互等問題；
- 資深負責人：還需要確認該項目是否存在資深負責人，資產負責人通常對項目有更深層次的認知和期望，所以也要將他們列為訪談對象。
（2）根據風險識別關鍵干係人
- 該功能的直接使用人：直接使用人是我們的重點訪談對象，因為直接使用人最熟悉業務流程，明確瞭解在實際業務場景中哪些是重點，哪裡可能會有坑，通過對他們進行用戶訪談，可以幫助產品經理更好的理解業務流程且可以規避流程中的風險；
- 具有一票否決權的評價者：具有一票否決權的評價者通常不是業務的直接或間接相關者，但是為大部門領導，他們對項目可能有產品矩陣或整體生態建設層面的規劃，所以也需要認真分析他們的意見。
- 技術部門負責人：需要和技術部門負責人溝通項目是否存在技術風險，項目前的溝通可以避免項目中的風險，也可以避免出現產品經理已經完成產品設計方案，但是由於技術風險問題不得不推倒重來的情況；明確干係人後我們需要對干係人做基礎瞭解，如干係人在組織架構中的職位、負責的工作、聯絡方式及合適的聯絡時間，以便可以在合適的時間點進行用戶訪談。
比如在某高端藝術品交易平臺的拍賣項目中，我們識別到的關鍵干係人包括：
- 負責線上拍賣的團隊負責人：需要和直接負責人確定拍賣的具體流程和規則，比如用戶參與競拍是否需要繳納押金，拍賣的商品金額大致區間，確定能否滿足線上支付的要求等問題；
- 負責倉儲和訂單的團隊負責人：確定商品競拍成功後大致的發貨時間等問題；
- 負責線上拍賣的運營同學：確定運營同學主持競拍的具體流程，以及在競拍過程中系統需要怎樣進行支持；
- 整個拍賣項目的總負責人：確定他對整個項目的項目預期以及規劃，以便進行產品規劃。
3. 訪談干係人、確定問題並產出策略級解決方案
確定干係人後，需對干係人進行用戶訪談，收集干係人當前遇到的問題以及問題發生的頻率及影響，再對問題進行歸納整理，進而產出策略級的解決方案。
（1）記錄原始問題在進行干係人訪談時，我們需要記錄用戶對遇到的問題及問題產生的影響的原始描述，原始描述有助於後期對原始需求的追溯。
（2）整理問題並分析影響第二步我們需要對干係人提出的問題進行歸納整理，並分析其影響；問題的影響包括直接影響和間接影響，在分析影響時，需要註意以下兩點：
- 問題的影響需要具體到明確的用戶；
- 闡述影響時需加入合理的推理，合理的推理更令人信服。
（3）產出策略級解決方案明確問題影響後，則可產出策略級的解決方案，並對比不同的解決方案的優缺點，在權衡干係人關註點、問題影響、當前資源等情況後，產品負責人和關鍵干係人對當前需解決問題的優先級及問題的解決方案達成共識。
以下是B端產品需求背景分析的產物：
寫在最後
通過對需求進行背景分析，我們可以深入的瞭解需求，並通過對相關干係人進行訪談，也可剖析用戶深層次的需求以及確定每個子任務的重要程度。
下一篇中，我將梳理如何進行B端產品的需求調研，感謝閱讀，期待再見~
本文由 @周伯通 原創發佈於人人都是產品經理，未經作者許可，禁止轉載。
題圖來自Unsplash，基於CC0協議。