B端產品案例,剖析需求調研的方法策略

0 評論 2346 瀏覽 12 收藏 23 分鐘

編輯導讀:B端產品更加依賴于后端部分的支撐,一些公司也習慣于將這些后端提供支撐的部分,稱為“后端產品”。由于后端產品部分的復雜性,因此負責這部分的產品經理,需要做更多、更深入的需求調研工作,才能完成方案設計。本文作者對此進行了分析,與你分享。

前后端分離的實現方式,使得每一個完整的產品體系都包含了前端和后端部分。

相對而言,B端產品更依賴于后端部分的支撐。

一些公司也習慣于將這些后端提供支撐的部分,稱為“后端產品”。

后端產品甚至不具有視覺化,而僅僅是一些中間件等。

后端產品如冰山之下,卻承擔相當重要的幕后工作:支撐、運算、監控、調度、分配、統計分析、決策……

由于后端產品部分的復雜性,因此負責這部分的產品經理,需要做更多、更深入的需求調研工作,才能完成方案設計。

一、后端需求調研

需求調研,是需求分析的前題。

需求分析,是產品方案決策的前題。

從需求調研到產品決策,占據了產品經理80%的工作精力。

由于調研和分析往往一起完成,所以在本文中我門統一將二者以“需求調研”代替。

按通用的模型表達方式,我們可以簡單畫下:

如上圖:需求調研是一個過程,其產物是解決方案。

后端需求研調,與前端需求調研很大的區別。比如用戶的角色化、業務的全還原、場景的窮舉、新舊邏輯兼容等。

我們簡單說下期中的用戶、業務和兼容性的話題:

1. 用戶

后端產品的用戶非最終的價值用戶,而是服務人員(如客服、運營)。

因此這些用戶具有業務垂直性,是格式化的“人”,具有戒色性和行業屬性。

不同職位不同權重,關心的價值目標、決策權、使用人數不同。

不同用戶的具體使用場景不同。

可以較容易的獲取前端產品用戶畫像,因為我們自身或者所熟悉的人都在扮演著 前端的角色,也就意味著設計過程中也很容易進行角色代入。

而后端用戶畫像的獲取往往艱難得多,最快捷的方式就是和公司的業務層交流,業務部門是最直接與客戶打交道的,他們熟知大量的典型客戶案例,可以幫助我們快速高效的描繪出用戶畫像。

由于我們自身與后端用戶的相剝離性,用戶畫像的作用顯得尤為關鍵,可以時刻提醒我們是在為誰做設計,每一個關鍵訴求都在產品設計中有對應的抓手。

2. 業務

  • 業務目標——>訴求——>用戶需求。
  • 業務手段——>途徑——>產品功能。

了解業務最好的方法,是輪崗參與業務環節中去。此外,更加便捷快速的方法,是調研訪談。

調研之前,最好對業務能有大體的認知,安排好訪談的對象,提前準備好問題,讓訪談更加高效。

調研方式:訪談、數據分析、問卷調查、頭腦風暴、德爾菲、觀察,完成用戶需求的收集;通過親和圖、提示清單等,整合需求信息。

調研目標:

  • 了解業務模式和業務特點
  • 了解業務目標和業務規劃
  • 了解當前業務運轉方式
  • 挖掘當前問題與痛點

對于后端產品,場景往往是很多的,需求的邏輯性大于故事性,需要由遠及近規劃處業務場景地圖,才能勾畫出業務架構,最終聚合出產品生態。

在這個過程中,可以借助用戶故事地圖等等手段。

通過整個業務的架構,厘清整個平臺的用戶對象、業務關系,也就確定了整個產品的業務邊界范圍,確定了整個團隊內的業務語言。

3. 新舊邏輯兼容

掌握后端產品邏輯真相的密碼通常在開發手里,但是開發常常也需要臨時查代碼。

在這種情況下,所有對舊功能的迭代都充滿著風險。

于此同時,無論是集成的大系統,還是拆開的煙囪林立服務,各個體系之間總是有邏輯調用。比如接口、公共數據等。

后端產品大約60%的bug都是來自于這種牽一發而動全身的邏輯耦合。

唯一能確保系統安全的辦法就是做深入的可能影響的調研。

為了避免空談,我們結合《后端產品經理寶典》一書,介紹需求調研落地的常用方法,和需求的類型。

二、需求調研的落地方法

1. 過濾需求的方法

做后端系統,要學會的第一個技能就是砍需求。也就是過濾需求。

這不是一個貶義詞,反而是體現后端產品價值判斷的基礎。

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

1)用戶場景模擬法

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

如果不能幫助用戶,那么這個需求就可能是偽需求。

以下面的案例說明:

  • 背景:“貨到付款”類型的訂單會因為缺貨而無法發出,如果超過一定的時間,客服就會跟顧客溝通,幫顧客取消訂單。
  • 需求:由于這種訂單的數量還是蠻多的,逐個取消太費時間,因此業務用戶要求在“缺貨訂單”列表頁增加“批量取消訂單”按鈕。
  • 分析:調研到業務操作場景,是先找到該類缺貨訂單,然后和顧客溝通,顧客同意刪除,才進行刪除。也就是逐個溝通確認,再逐個取消訂單的,所以“批量取消訂單”無法被有效使用。

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

2)功能歸屬分析

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

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

如果不屬于該系統范疇,那么直接說服需求方更換方案。以下面的案例說明:

  • 背景:CRM系統(顧客關系管理系統)有一個顧客標簽生成功能,就是根據顧客的消費行為數據,自動對應關聯上標簽,如優質顧客、高潛力顧客、欺詐顧客等。
  • 需求:業務用戶提出需求,除了做上述的基礎標簽之外,還要做出英語版本的標簽(就是把標簽文案翻譯成英文),這樣歐美員工可以在英語版本的系統下使用。
  • 分析:調研到翻譯之后的標簽不是在CRM系統使用的,而是給到SMS(客服系統)使用的。

所以應該由SMS根據CMS提供的基礎標簽數據,自己做二次的衍生。

之所以這樣,首先是為了避免未來更多語言版本的擴展需求或更多系統提出類似的需求;

其次,CRM系統已經完成了“接力賽”的第一棒,創造了基礎數據,那么其他系統要特殊化使用,完全可以自行進行特殊化處理,無需耦合回CRM系統。

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

否則,耦合性過高只會增加系統的復雜程度,難以維護和擴展。

2. 拆分和聚合的方法

1)拆分需求法

收到的需求,很可能只是短短的一段話。

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

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

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

以下面的案例說明:

  • 背景:訂單業務的類型很多,訂單退貨之后需要創建售后單據,但是因為數量大,所以花費很多人力,且手動創建有出錯的風險。
  • 需求:業務提出的需求是“增加退貨訂單自動創建售后單的功能”,這是個一句話需求。
  • 分析:該一句話需求,其實包含了多種具體的訂單類型和場景,那么我們就要拆分調研,拆分的維度比如:

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

這里不一一展開。

2)聚合需求法

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

由于業務用戶分散在不同的部門,各自為政,于是張三、李四可能都對一個業務流程有相同的需求,或者對同一個功能有相同的優化期望,結果倆人分別提了需求過來。那么產品經理就要找到二者背后的相關性和交叉區。

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

3. 利用輔助功能調研需求

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

比如業務用戶需要更新一個功能,為了避免更新出錯或遺漏,產品經理需要知道修改前和修改后是否會能正常運行。

最基礎的辦法就是自己設計一個測試用例,記錄操作方式、狀態變化、數據流向等??纯聪旅娴睦樱?/p>

  • 背景:從銷售網站獲取到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年年度作者?!逗蠖水a品經理寶典》作者,藥學碩士轉行互聯網產品多年;熟悉跨境電商業務,醫藥領域;擅長大型后臺體系,社交APP。

本文原創發布于人人都是產品經理,未經作者許可,禁止轉載

題圖來自Unsplash,基于CC0協議

給作者打賞,鼓勵TA抓緊創作!
2人打賞
更多精彩內容,請關注人人都是產品經理微信公眾號或下載App
評論
評論請登錄
  1. 目前還沒評論,等你發揮!