編輯導讀：B端產品更加依賴於後端部分的支撐，一些公司也習慣於將這些後端提供支撐的部分，稱為“後端產品”。由於後端產品部分的複雜性，因此負責這部分的產品經理，需要做更多、更深入的需求調研工作，才能完成方案設計。本文作者對此進行了分析，與你分享。
前後端分離的實現方式，使得每一個完整的產品體系都包含了前端和後端部分。
相對而言，B端產品更依賴於後端部分的支撐。
一些公司也習慣於將這些後端提供支撐的部分，稱為“後端產品”。
後端產品甚至不具有視覺化，而僅僅是一些中間件等。
後端產品如冰山之下，卻承擔相當重要的幕後工作：支撐、運算、監控、調度、分配、統計分析、決策……
由於後端產品部分的複雜性，因此負責這部分的產品經理，需要做更多、更深入的需求調研工作，才能完成方案設計。
一、後端需求調研需求調研，是需求分析的前題。
需求分析，是產品方案決策的前題。
從需求調研到產品決策，佔據了產品經理80%的工作精力。
由於調研和分析往往一起完成，所以在本文中我門統一將二者以“需求調研”代替。
按通用的模型表達方式，我們可以簡單畫下：
如上圖：需求調研是一個過程，其產物是解決方案。
後端需求研調，與前端需求調研很大的區別。比如用户的角色化、業務的全還原、場景的窮舉、新舊邏輯兼容等。
我們簡單説下期中的用户、業務和兼容性的話題：
1. 用户後端產品的用户非最終的價值用户，而是服務人員（如客服、運營）。
因此這些用户具有業務垂直性，是格式化的“人”，具有戒色性和行業屬性。
不同職位不同權重，關心的價值目標、決策權、使用人數不同。
不同用户的具體使用場景不同。
可以較容易的獲取前端產品用户畫像，因為我們自身或者所熟悉的人都在扮演着 前端的角色，也就意味着設計過程中也很容易進行角色代入。
而後端用户畫像的獲取往往艱難得多，最快捷的方式就是和公司的業務層交流，業務部門是最直接與客户打交道的，他們熟知大量的典型客户案例，可以幫助我們快速高效的描繪出用户畫像。
由於我們自身與後端用户的相剝離性，用户畫像的作用顯得尤為關鍵，可以時刻提醒我們是在為誰做設計，每一個關鍵訴求都在產品設計中有對應的抓手。
2. 業務- 業務目標——>訴求——>用户需求。
- 業務手段——>途徑——>產品功能。
瞭解業務最好的方法，是輪崗參與業務環節中去。此外，更加便捷快速的方法，是調研訪談。
調研之前，最好對業務能有大體的認知，安排好訪談的對象，提前準備好問題，讓訪談更加高效。
調研方式：訪談、數據分析、問卷調查、頭腦風暴、德爾菲、觀察，完成用户需求的收集；通過親和圖、提示清單等，整合需求信息。
調研目標：
- 瞭解業務模式和業務特點
- 瞭解業務目標和業務規劃
- 瞭解當前業務運轉方式
- 挖掘當前問題與痛點
對於後端產品，場景往往是很多的，需求的邏輯性大於故事性，需要由遠及近規劃處業務場景地圖，才能勾畫出業務架構，最終聚合出產品生態。
在這個過程中，可以藉助用户故事地圖等等手段。
通過整個業務的架構，釐清整個平台的用户對象、業務關係，也就確定了整個產品的業務邊界範圍，確定了整個團隊內的業務語言。
3. 新舊邏輯兼容掌握後端產品邏輯真相的密碼通常在開發手裏，但是開發常常也需要臨時查代碼。
在這種情況下，所有對舊功能的迭代都充滿着風險。
於此同時，無論是集成的大系統，還是拆開的煙囱林立服務，各個體系之間總是有邏輯調用。比如接口、公共數據等。
後端產品大約60%的bug都是來自於這種牽一髮而動全身的邏輯耦合。
唯一能確保系統安全的辦法就是做深入的可能影響的調研。
為了避免空談，我們結合《後端產品經理寶典》一書，介紹需求調研落地的常用方法，和需求的類型。
二、需求調研的落地方法1. 過濾需求的方法做後端系統，要學會的第一個技能就是砍需求。也就是過濾需求。
這不是一個貶義詞，反而是體現後端產品價值判斷的基礎。
過濾需求的方法，就是通過一定的手段判斷需求是否是偽需求，應該被過濾掉。
1）用户場景模擬法
後端產品的出發點就是幫助業務用户，因此在調研需求的時候要模擬業務的場景，分析業務用户提到的需求是否能解決他的問題。
如果不能幫助用户，那麼這個需求就可能是偽需求。
以下面的案例説明：
- 背景：“貨到付款”類型的訂單會因為缺貨而無法發出，如果超過一定的時間，客服就會跟顧客溝通，幫顧客取消訂單。
- 需求：由於這種訂單的數量還是蠻多的，逐個取消太費時間，因此業務用户要求在“缺貨訂單”列表頁增加“批量取消訂單”按鈕。
- 分析：調研到業務操作場景,是先找到該類缺貨訂單，然後和顧客溝通，顧客同意刪除，才進行刪除。也就是逐個溝通確認，再逐個取消訂單的，所以“批量取消訂單”無法被有效使用。
因此，該需求是個偽需求，應該被過濾掉。
2）功能歸屬分析
專門的系統做專職功能，有助於合理的產品體系建設。
因此需求調研的時候，可以通過系統的定位，判斷需求是否應該在該系統完成。
如果不屬於該系統範疇，那麼直接説服需求方更換方案。以下面的案例説明：
- 背景：CRM系統（顧客關係管理系統）有一個顧客標籤生成功能，就是根據顧客的消費行為數據，自動對應關聯上標籤，如優質顧客、高潛力顧客、欺詐顧客等。
- 需求：業務用户提出需求，除了做上述的基礎標籤之外，還要做出英語版本的標籤（就是把標籤文案翻譯成英文），這樣歐美員工可以在英語版本的系統下使用。
- 分析：調研到翻譯之後的標籤不是在CRM系統使用的，而是給到SMS（客服系統）使用的。
所以應該由SMS根據CMS提供的基礎標籤數據，自己做二次的衍生。
之所以這樣，首先是為了避免未來更多語言版本的擴展需求或更多系統提出類似的需求；
其次，CRM系統已經完成了“接力賽”的第一棒，創造了基礎數據，那麼其他系統要特殊化使用，完全可以自行進行特殊化處理，無需耦合回CRM系統。
結論：案例的需求本身是真需求，並且實現上也沒難度，但是該功能的定位超出了本系統範疇，專門系統做專職功能，化衍生需求應該在下游執行。
否則，耦合性過高只會增加系統的複雜程度，難以維護和擴展。
2. 拆分和聚合的方法1）拆分需求法
收到的需求，很可能只是短短的一段話。
但是不要高興太早，可能這一句話暗含了很多線索，因此要善於拆分：
先找他要解決的核心問題，再圍繞核心點，理清前、後、左、右、上、下的旁系需求點。
每個需求點再當做一個子需求進行調研，最後再聚合在一起。
以下面的案例説明：
- 背景：訂單業務的類型很多，訂單退貨之後需要創建售後單據，但是因為數量大，所以花費很多人力，且手動創建有出錯的風險。
- 需求：業務提出的需求是“增加退貨訂單自動創建售後單的功能”，這是個一句話需求。
- 分析：該一句話需求，其實包含了多種具體的訂單類型和場景，那麼我們就要拆分調研，拆分的維度比如：
自營訂單、第三方訂單、貨到付款訂單、先款後貨訂單、部分退貨訂單、完全退貨訂單、服裝事業部訂單、電子事業部訂單等，其中每一個維度就相當於一個小需求。
這裏不一一展開。
2）聚合需求法
拆分法是對單個需求分解成若干小需求進行調研，聚合法相反，是找到許多個相互關聯的小需求的共性，然後統籌成一個大需求去完成。例如：
由於業務用户分散在不同的部門，各自為政，於是張三、李四可能都對一個業務流程有相同的需求，或者對同一個功能有相同的優化期望，結果倆人分別提了需求過來。那麼產品經理就要找到二者背後的相關性和交叉區。
然後統籌規劃，聚合在一起當作一個需求來調研，最終輸出一個整體的需求調研結果。
3. 利用輔助功能調研需求調研產品現有功能，可以用來確認原有功能的邏輯，或者確定新需求方案是否可行。
比如業務用户需要更新一個功能，為了避免更新出錯或遺漏，產品經理需要知道修改前和修改後是否會能正常運行。
最基礎的辦法就是自己設計一個測試用例，記錄操作方式、狀態變化、數據流向等。看看下面的例子：
- 背景：從銷售網站獲取到OMS系統（訂單管理系統）的訂單信息中帶着顧客的郵箱。顧客下完單，可能會在銷售網站修改郵箱，而此時已經獲取到OMS的歷史訂單中的郵箱是不變的。
- 需求：顧客若在銷售網站修改郵箱，要求已獲取到OMS的該顧客的訂單中的郵箱也要同步修改。
- 分析：需求是很明白的，也有它的意義，但有風險。
因為我們知道訂單信息貫穿於整個訂單流轉過程中，牽扯到訂單編輯、審核、取消、配貨、發貨等，而這些環節跳轉的觸發條件可能就是某個信息更新（這裏面就可能包括有郵箱更新）。
因此，更新郵箱是否會影響流程中的某些環節，一時間很難準確知道。
於是，我們可以採用預測試的方式，設計測試用例，在測試機運行一些訂單，觀察各個環節郵箱變更的影響，然後收集起來分析對策。
測試法就像是探雷一樣，主要用來解決未知風險點。這個方式的重點是記錄和分析操作前狀態、操作位點、操作後狀態、操作後觸發的連鎖反應、數據流向等。
4. “拔蘿蔔帶出泥”的方式調研需求調研需求時，產品經理要拔蘿蔔帶出泥,挖掘用户沒看到的需求點和價值。舉例説明：
背景：公司入駐到銷售平台後，銷售平台會對入駐的店鋪的違規行為進行罰款。
需求：業務用户提出需求，將銷售平台的罰款數據抓取到訂單系統，關聯訂單數據，以便進行人工分析。
分析：
第一步，先拆分需求，確定什麼是罰款數據，總共有哪些罰款種類，需要對接哪些罰款種類，罰款數據與訂單系統關聯方式是什麼，是否都能關聯到，關聯不到怎麼辦，銷售平台是否已經提供了公用的罰款接口，Token（請求權限）如何獲取，抓取頻率怎麼樣，數據增長幅度多大，獲取之後做哪些展示和搜索，用户權限怎麼設置，需要和訂單系統做哪些交互，該需求的價值是什麼……
第二步，挖掘需求：是否需要作分析功能，分析功能的規則是什麼；是否需要做監控和預警，是否需要指派負責人；其他業務人員是否也有類似需求，其他平台是否也有類似需求……
通過“拔蘿蔔帶出泥”的方式，連帶出更多需求點。將上述調研結果重新組裝起來，得到一個系統化的完整需求。
羅列出需求要點和對應的驗收目標，這樣使得需求具象化，同時又不會遺漏細節，內部充實，外部閉環，並且進行了價值挖掘，做成控制閾值、預警、責任人分派、趨勢分析、損失分析等高價值的功能，超出業務的預期。
5. 需求得分權重法該方法的思路就是將需求質量的維度進行權重，然後對需求進行打分，根據最終得分的多少排列順序。
可以採用五個維度：重要、緊急、收益、成本、風險，其中成本和風險是給予負分，五個維度的分值權重分別為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，可以予以淘汰。
以上的維度、分值和權重可以根據實際情況自行設計，但是要多考察和驗證什麼樣的參數是較為合理的。並且也不能唯權重得分是從，而只是把它當做一個輔助工具。
6. 其他需求調研工具需求調研適合核心環節，該過程就會涉及到很多工具或分析方法，以確保需求調研高效、高質量。
比如問卷調查、訪談、名義小組會議、頭腦風暴法、觀察法、親和圖、蒙特卡洛技術、魚骨圖、提示清單等。
三、需求的類型和態度筆者對B端或泛後台產品需求的一個定性劃分：粗淺需求、噱頭需求、踢球需求、過剩需求、建設性需求。
1. 被動的粗淺需求這類需求，屬於想當然的需求，不考慮系統的兼容性和業務兼容性的。
比如：電商場景中，要求：若庫存為0，則果斷給予下架；庫存變為非0，果斷自動上架。
這種強制自然是存在極大風險的。並且庫存為0也有曝光的價值；非零也有下架的場景。二者不等同。
這種情況下實際是“概念偷換”的錯謬，無庫存=下架。
對這類需求，產品可以持保留態度，持續觀望，收集更多用户的深層次數據反饋。但不能輕舉妄動。
2. 戰略的噱頭需求這種很好理解，很多公司其實都是這麼玩沒的。
比如：看到競爭對手有的功能，我們要有；對手無的，我們也要有。這樣可以顯得產品更強大。
或者是強行“組合創新”：一個做醫藥電商的，你讓他做直播帶貨，且不説是否合規，你能想象藥師在店裏當着店長的面做網紅嗎？
這種情況下實際是“感覺謬誤”。理論上，產品經理需要拿數據論證的。
所以產品經理能做的就是慢點做，保留資源。找機會慢慢把意見滲透到高層，試圖止損。
3. 隔壁的踢球需求在多組織的團隊中，這種踢來踢去丟需求的情況相當普遍。
比如，對醫藥商品，配置一段免責聲明，展示在商城。
那麼讓商品後台在商品維度加字段並傳給前端，看似從後端到前端，且商品維度的，似乎沒錯。但是沒必要的。
因為，這是共性字段，商品維度幾乎不需要重複維護，也沒有操作差異性。
這類需求，產品經理需要從分工、系統職能、收益考慮，將事情客觀表述出來，完成博弈。
4. 客服的過剩需求這類需求，往往是客服傳達來自用户的需求。通常目的很明確，但是對功能設計進行了干涉，可能影響產品的分析。
比如，客服傳達某O2O用户的需求：要在商品的實際銷售價旁邊，展示線下零售價格。
產品：然後呢？
客服：若對比到差異，則修改線上價？
產品：怎麼修改？
客服：在線下零售價的基礎上按公式計算，比如上漲1%，得出線上零售價，然後逐個編輯。
產品：是否可以理解為，目的是讓線上價格，按自己期望的賣，不取線下零售價？
客服：是
產品：那麼為什麼不在根源處理呢：創建一組用於線上銷售的價格，直接引用不就可以了嗎？
這類問題，一定是要挖掘到用户的場景的，從用户的場景下尋求同理心，不受制於現有功能的設定。
只有這樣才能不受侷限，找到用户的初心。以解決問題為標準。
5. 產品經理的建設需求所謂建設性需求，可能是每個產品經理心中都有的夙願。前提是，產品經理的決策正確。
比如：自主優化產品模型，拆分微服務，界面統一等，統籌規劃和重構的類的內容。
若前四類需求過多，將會擠壓產品的建設性需求。
產品經理能夠騰出手來做一些真正正確的事情，往往能對全局帶來增益。
#專欄作家#唧唧歪歪PM，公眾號：唧唧歪歪PM（ID：jjyypm），人人都是產品經理專欄作家，2019年年度作者。《後端產品經理寶典》作者，藥學碩士轉行互聯網產品多年；熟悉跨境電商業務，醫藥領域；擅長大型後台體系，社交APP。
本文原創發佈於人人都是產品經理，未經作者許可，禁止轉載
題圖來自Unsplash，基於CC0協議