B端功能初級方法論
當(dāng)自身經(jīng)驗(yàn)不足,但又遇到“特殊”的功能需求時(shí),可能會(huì)顯得力不從心,不知從哪里著手解決問題,這對我們的工作進(jìn)度也造成了一定的阻礙。
想必每一個(gè)剛進(jìn)入b端或從c端轉(zhuǎn)b端的產(chǎn)品經(jīng)理們都會(huì)遇到一個(gè)困境:做一個(gè)功能想要找到最優(yōu)解,但沒有可參考的對象。胸中欲裝山海,卻拔劍四顧心茫然。
b端的封閉性導(dǎo)致了我們看不到好的應(yīng)用/好的系統(tǒng)來當(dāng)老師,更多的時(shí)候是自己閉門造車,根據(jù)以往的經(jīng)驗(yàn)去解決。如果經(jīng)驗(yàn)不足又遇到“特殊”的功能需求,就會(huì)無從下手。我曾經(jīng)就陷入這樣的泥沼里,一個(gè)月苦思冥想,一次次的否定自己,沒有輸出。
偶然我在策略產(chǎn)品經(jīng)理的視頻中,看到一個(gè)很有意思的模型。這個(gè)模型在我無法輸出成果的日子里,仿佛上帝打開了一扇窗,讓光照了進(jìn)來。
一、深入理解業(yè)務(wù)邏輯
在講方法論之前,我想先談?wù)剺I(yè)務(wù)邏輯。這是b端的核心,也是方法論的前提。
理解業(yè)務(wù)邏輯不能停留于表層,更深層的細(xì)節(jié)其實(shí)就是產(chǎn)品經(jīng)理挖掘需求的過程。有一個(gè)笨辦法是場景模擬并推敲過程的每一個(gè)細(xì)節(jié)。模擬發(fā)起者的動(dòng)作,模擬承接者的動(dòng)作,模擬中間發(fā)生意外情況,模擬最后的收官動(dòng)作。及時(shí)記錄下你想到的每一個(gè)細(xì)節(jié)點(diǎn)。就像做一個(gè)演員,自己寫好劇本代入其中。不要業(yè)務(wù)部門說什么你就聽什么,那和傳話筒沒有區(qū)別。業(yè)務(wù)部門只是幫助你初步了解業(yè)務(wù)走向,補(bǔ)充一些生僻的使用細(xì)節(jié)和共同敲定你方法可行性的。
我們以投訴業(yè)務(wù)為例,表層是后臺有一個(gè)展示投訴單的地方,投訴專員可以上傳投訴結(jié)果并完成。更深層的細(xì)節(jié)是:投訴單是否要根據(jù)不同的投訴場景進(jìn)行分類?投訴單的重要等級如何定義?投訴單按照什么規(guī)則分配到相應(yīng)的投訴專員?投訴帶來的賠償損失是否要界定到內(nèi)部人員責(zé)任并進(jìn)行記錄?等等。
二、初級方法論
需要聲明的是,初級方法論只能做到簡單粗暴的解決當(dāng)下的問題,它并不是最優(yōu)解,也不是市面上最好的解決方案。但你可以努力讓它成為最適合你們公司的解決方案。
我把它分解為四步:目標(biāo)-輸入-輸出-結(jié)果。
2.1 目標(biāo)
無論是老功能的調(diào)整還是新功能的增加,其實(shí)歸根到底都是為了解決問題。目標(biāo)就是當(dāng)前你想要解決的問題。
例如:當(dāng)前的訂單分配太過復(fù)雜/當(dāng)前的傭金體系計(jì)算不正確。
2.2 輸入
輸入即是根據(jù)目標(biāo),拆解問題的關(guān)鍵因素。可以簡單的理解為,是哪些因素導(dǎo)致了現(xiàn)在的問題。
以訂單分配太過復(fù)雜舉例:訂單進(jìn)來后需要分配客服進(jìn)行跟單,分配到哪個(gè)客服由后臺配置。復(fù)雜主要指配置規(guī)則上太過復(fù)雜。
問題拆解后輸入的因素為:
- 沒有考慮特殊商戶的vip服務(wù),常規(guī)訂單和特殊商戶的訂單混雜在一起沒有作區(qū)分。
- 建立客服分組的配置項(xiàng)太多:新建一個(gè)衣服訂單的客服分組(即衣服訂單都會(huì)由該分組的客服來跟進(jìn)),需要勾選衣服的性別,衣服的季節(jié),衣服的顏色,展示區(qū)域等等(以上僅為示意,非實(shí)際業(yè)務(wù)場景)
- 配置重復(fù)時(shí)沒有自動(dòng)識別提示。重復(fù)勾選時(shí),沒有識別提示,且無法保存成功。不知道到底是多勾了哪個(gè)。
- 沒有異常訂單歸類。因?yàn)槭侨藶榻ńM分配訂單,難免會(huì)出現(xiàn)漏掉配置或配置錯(cuò)誤的情況。而如果沒有對漏單錯(cuò)單進(jìn)行歸類展示,不僅會(huì)造成業(yè)務(wù)上的損失,后期排查配置起來也會(huì)非常麻煩。
以上都是現(xiàn)有訂單分配功能的問題拆解,找到了輸入因素后,我們就可以針對這些去輸出因素了。
2.3 輸出
輸出即是對上述輸入因素的解決方案。簡單來說,就是去解決上面列出的那些問題。
還是以訂單分配為例,輸出的因素為:
- 新建特殊商戶的配置方式,優(yōu)先級大于常規(guī)訂單分配。
- 簡化配置項(xiàng)。實(shí)際業(yè)務(wù)場景并不需要這么細(xì)化的配置規(guī)則,只需要衣服的性別和季節(jié)即可(春夏男裝分配給A客服組,秋冬男裝分配給B客服組),那么直接去除其他的配置項(xiàng)。
- 配置時(shí),已勾選的配置可以灰掉不可勾選或進(jìn)行提示。
- 新建異常訂單的顯示頁,將沒有分配客服或分配異常的訂單進(jìn)行展示并指明問題點(diǎn)。
2.4 結(jié)果
結(jié)果即是最后交付研發(fā)的產(chǎn)品原型??梢钥吹剑跫壏椒ㄕ摰乃季S角度不是尋找一套最完美的體系,而只是發(fā)現(xiàn)問題解決問題的思維。它只適用于初級產(chǎn)品或在迷茫的時(shí)候帶來突破的可能性。
而更高級的方法論一定是深扎業(yè)務(wù),經(jīng)過打磨的系統(tǒng)化思維了。
三、細(xì)節(jié)
3.1 模塊化思維
經(jīng)常調(diào)用的功能可以做成模塊化,方便后期進(jìn)行維護(hù)。例如訂單中填寫信息一步,如果不同類型的訂單都單獨(dú)做填寫信息功能,一個(gè)是會(huì)導(dǎo)致研發(fā)非常低效,重復(fù)性的體力勞動(dòng)。另一個(gè)是后期如果填寫信息中的某項(xiàng)要進(jìn)行調(diào)整,而這項(xiàng)又是出現(xiàn)在很多類型訂單中,那么首先要找全這些訂單類型,然后一個(gè)個(gè)的調(diào)整過去,也是非常低效。
而做成模塊化,訂單對模塊進(jìn)行調(diào)用,那么只需要對模塊進(jìn)行修改,所有相關(guān)的訂單都會(huì)同步修改。不需要再進(jìn)行重復(fù)性的體力勞動(dòng)。
3.2 代碼語言思維
在設(shè)計(jì)產(chǎn)品原型時(shí),使用代碼邏輯的思維代替日常性口語進(jìn)行設(shè)計(jì)。這樣研發(fā)理解起來會(huì)非常輕松,也不容易走偏方向。同時(shí),也可以使自己的邏輯性更加有條理。
例如:下單時(shí)需要進(jìn)行庫存判定,對比下單數(shù)和庫存數(shù),庫存不足需要提醒商家。
設(shè)計(jì)原型時(shí)如果寫庫存不足,需要向商家發(fā)送庫存增補(bǔ)提醒。默契不足的研發(fā)容易誤解,庫存不足指代庫存=0,其實(shí)還有一種情況是,下單商品數(shù)量>庫存數(shù)。
而正確的思維邏輯:判定若下單數(shù)≤庫存數(shù),則走正常訂單流程。若下單數(shù)>庫存,則向商家發(fā)送庫存增補(bǔ)提醒。就不容易誤解出錯(cuò)。
四、開關(guān)與測試
4.1 做好開關(guān)留條退路
如果是已有功能的重構(gòu)或改版,要視重要程度做好開關(guān),好漢也要給自己留條退路。有問題隨時(shí)切換回去,以免影響業(yè)務(wù)運(yùn)轉(zhuǎn)。
也可以劃定小部分群體/商品分類進(jìn)行試點(diǎn),成熟后全面覆蓋推廣。例如只上線上海區(qū)域或只上線食品這一分類的商品。
當(dāng)然無論是做開關(guān)還是試點(diǎn)都需要提前和研發(fā)討論敲定。等研發(fā)一半了再提出,怕是要被打成小豬佩奇。
4.2 與使用者約會(huì)測試
測試的時(shí)候,有條件就拉上使用該功能的業(yè)務(wù)部門一起跑跑。有些細(xì)節(jié)或體驗(yàn),只有使用者才能切身實(shí)際的感受到。所謂的產(chǎn)品經(jīng)理同理心,容易走入理想化的烏托邦。
五、迭代再迭代
選個(gè)黃道吉日上線,運(yùn)行也一切正常,就要開始考慮迭代的問題了。我們先撇開復(fù)雜功能需要分幾個(gè)大版本的迭代規(guī)劃不談。
這里的迭代,是收集上線后的使用反饋,繼續(xù)進(jìn)行調(diào)優(yōu)的過程。之前也說過,這套初級方法論只能保證以最簡單粗暴的方式解決當(dāng)下,而不是最優(yōu)解。最優(yōu)解需要不斷調(diào)優(yōu)來默契的匹配業(yè)務(wù)場景。自己一遍遍的使用功能,與使用者反復(fù)的確認(rèn)細(xì)節(jié),不斷的去優(yōu)化迭代,你可以讓它成為最適合公司當(dāng)下的解決方案。
六、留檔是功德無量
留檔也是前人栽樹后人乘涼,功德無量的事情。如果一個(gè)功能的產(chǎn)品經(jīng)理溜了,而又沒有任何說明留下來,那么接手會(huì)非常痛苦。
業(yè)務(wù)邏輯得自己默默的跑百八十遍,細(xì)節(jié)還得求爺爺告奶奶找研發(fā)查代碼。最后還不知道前人腦回路是怎么想的,無奈罵一句傻子產(chǎn)品經(jīng)理。當(dāng)然,實(shí)際情況可能真的是傻子做的,也有很大概率是當(dāng)時(shí)的業(yè)務(wù)場景只允許他這么做。那么當(dāng)時(shí)的坑是否你現(xiàn)在也要面對還不自知?
本文由 @作夢家 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理。未經(jīng)許可,禁止轉(zhuǎn)載
題圖來自Unsplash,基于CC0協(xié)議
B端產(chǎn)品看行業(yè),看業(yè)態(tài)等,差異巨大,沒法以點(diǎn)概面,業(yè)務(wù)邏輯,場景,個(gè)性化需求理解不難,落地到架構(gòu),庫里,代碼,匹配起來難度就是目前眾多B端與資本,市場,客戶期望差距巨大。