全栈工程师?
嗯.....目前并不是!

B端功能初級方法論

當自身經驗不足,但又遇到“特殊”的功能需求時,可能會顯得力不從心,不知從哪裡着手解決問題,這對我們的工作進度也造成了一定的阻礙。

想必每一個剛進入b端或從c端轉b端的產品經理們都會遇到一個困境:做一個功能想要找到最優解,但沒有可參考的對象。胸中欲裝山海,卻拔劍四顧心茫然。

b端的封閉性導致了我們看不到好的應用/好的系統來當老師,更多的時候是自己閉門造車,根據以往的經驗去解決。如果經驗不足又遇到“特殊”的功能需求,就會無從下手。我曾經就陷入這樣的泥沼里,一個月苦思冥想,一次次的否定自己,沒有輸出。

偶然我在策略產品經理的視頻中,看到一個很有意思的模型。這個模型在我無法輸出成果的日子裡,彷彿上帝打開了一扇窗,讓光照了進來。

一、深入理解業務邏輯

在講方法論之前,我想先談談業務邏輯。這是b端的核心,也是方法論的前提。

理解業務邏輯不能停留於表層,更深層的細節其實就是產品經理挖掘需求的過程。有一個笨辦法是場景模擬並推敲過程的每一個細節。模擬發起者的動作,模擬承接者的動作,模擬中間發生意外情況,模擬最後的收官動作。及時記錄下你想到的每一個細節點。就像做一個演員,自己寫好劇本代入其中。不要業務部門說什麼你就聽什麼,那和傳話筒沒有區別。業務部門只是幫助你初步了解業務走向,補充一些生僻的使用細節和共同敲定你方法可行性的。

我們以投訴業務為例,表層是後台有一個展示投訴單的地方,投訴專員可以上傳投訴結果並完成。更深層的細節是:投訴單是否要根據不同的投訴場景進行分類?投訴單的重要等級如何定義?投訴單按照什麼規則分配到相應的投訴專員?投訴帶來的賠償損失是否要界定到內部人員責任並進行記錄?等等。

二、初級方法論

需要聲明的是,初級方法論只能做到簡單粗暴的解決當下的問題,它並不是最優解,也不是市面上最好的解決方案。但你可以努力讓它成為最適合你們公司的解決方案。

我把它分解為四步:目標-輸入-輸出-結果。

2.1 目標

無論是老功能的調整還是新功能的增加,其實歸根到底都是為了解決問題。目標就是當前你想要解決的問題。

例如:當前的訂單分配太過複雜/當前的傭金體系計算不正確。

2.2 輸入

輸入即是根據目標,拆解問題的關鍵因素。可以簡單的理解為,是哪些因素導致了現在的問題。

以訂單分配太過複雜舉例:訂單進來后需要分配客服進行跟單,分配到哪個客服由後台配置。複雜主要指配置規則上太過複雜。

問題拆解后輸入的因素為:

  1. 沒有考慮特殊商戶的vip服務,常規訂單和特殊商戶的訂單混雜在一起沒有作區分。
  2. 建立客服分組的配置項太多:新建一個衣服訂單的客服分組(即衣服訂單都會由該分組的客服來跟進),需要勾選衣服的性別,衣服的季節,衣服的顏色,展示區域等等(以上僅為示意,非實際業務場景)
  3. 配置重複時沒有自動識別提示。重複勾選時,沒有識別提示,且無法保存成功。不知道到底是多勾了哪個。
  4. 沒有異常訂單歸類。因為是人為建組分配訂單,難免會出現漏掉配置或配置錯誤的情況。而如果沒有對漏單錯單進行歸類展示,不僅會造成業務上的損失,後期排查配置起來也會非常麻煩。

以上都是現有訂單分配功能的問題拆解,找到了輸入因素后,我們就可以針對這些去輸出因素了。

2.3 輸出

輸出即是對上述輸入因素的解決方案。簡單來說,就是去解決上面列出的那些問題。

還是以訂單分配為例,輸出的因素為:

  1. 新建特殊商戶的配置方式,優先級大於常規訂單分配。
  2. 簡化配置項。實際業務場景並不需要這麼細化的配置規則,只需要衣服的性別和季節即可(春夏男裝分配給A客服組,秋冬男裝分配給B客服組),那麼直接去除其他的配置項。
  3. 配置時,已勾選的配置可以灰掉不可勾選或進行提示。
  4. 新建異常訂單的顯示頁,將沒有分配客服或分配異常的訂單進行展示並指明問題點。

2.4 結果

結果即是最後交付研發的產品原型。可以看到,初級方法論的思維角度不是尋找一套最完美的體系,而只是發現問題解決問題的思維。它只適用於初級產品或在迷茫的時候帶來突破的可能性。

而更高級的方法論一定是深扎業務,經過打磨的系統化思維了。

三、細節

3.1 模塊化思維

經常調用的功能可以做成模塊化,方便後期進行維護。例如訂單中填寫信息一步,如果不同類型的訂單都單獨做填寫信息功能,一個是會導致研發非常低效,重複性的體力勞動。另一個是後期如果填寫信息中的某項要進行調整,而這項又是出現在很多類型訂單中,那麼首先要找全這些訂單類型,然後一個個的調整過去,也是非常低效。

而做成模塊化,訂單對模塊進行調用,那麼只需要對模塊進行修改,所有相關的訂單都會同步修改。不需要再進行重複性的體力勞動。

3.2 代碼語言思維

在設計產品原型時,使用代碼邏輯的思維代替日常性口語進行設計。這樣研發理解起來會非常輕鬆,也不容易走偏方向。同時,也可以使自己的邏輯性更加有條理。

例如:下單時需要進行庫存判定,對比下單數和庫存數,庫存不足需要提醒商家。

設計原型時如果寫庫存不足,需要向商家發送庫存增補提醒。默契不足的研發容易誤解,庫存不足指代庫存=0,其實還有一種情況是,下單商品數量>庫存數。

而正確的思維邏輯:判定若下單數≤庫存數,則走正常訂單流程。若下單數>庫存,則向商家發送庫存增補提醒。就不容易誤解出錯。

四、開關與測試

4.1 做好開關留條退路

如果是已有功能的重構或改版,要視重要程度做好開關,好漢也要給自己留條退路。有問題隨時切換回去,以免影響業務運轉。

也可以劃定小部分群體/商品分類進行試點,成熟后全面覆蓋推廣。例如只上線上海區域或只上線食品這一分類的商品。

當然無論是做開關還是試點都需要提前和研發討論敲定。等研發一半了再提出,怕是要被打成小豬佩奇。

4.2 與使用者約會測試

測試的時候,有條件就拉上使用該功能的業務部門一起跑跑。有些細節或體驗,只有使用者才能切身實際的感受到。所謂的產品經理同理心,容易走入理想化的烏托邦。

五、迭代再迭代

選個黃道吉日上線,運行也一切正常,就要開始考慮迭代的問題了。我們先撇開複雜功能需要分幾個大版本的迭代規劃不談。

這裡的迭代,是收集上線后的使用反饋,繼續進行調優的過程。之前也說過,這套初級方法論只能保證以最簡單粗暴的方式解決當下,而不是最優解。最優解需要不斷調優來默契的匹配業務場景。自己一遍遍的使用功能,與使用者反覆的確認細節,不斷的去優化迭代,你可以讓它成為最適合公司當下的解決方案。

六、留檔是功德無量

留檔也是前人栽樹後人乘涼,功德無量的事情。如果一個功能的產品經理溜了,而又沒有任何說明留下來,那麼接手會非常痛苦。

業務邏輯得自己默默的跑百八十遍,細節還得求爺爺告奶奶找研發查代碼。最後還不知道前人腦迴路是怎麼想的,無奈罵一句傻子產品經理。當然,實際情況可能真的是傻子做的,也有很大概率是當時的業務場景只允許他這麼做。那麼當時的坑是否你現在也要面對還不自知?

 

版权声明:本文采用知识共享 署名4.0国际许可协议 [BY-NC-SA] 进行授权
文章名称:《B端功能初級方法論》
文章链接:https://www.pmbear.com/b%e7%ab%af%e5%8a%9f%e8%83%bd%e5%88%9d%e7%b4%9a%e6%96%b9%e6%b3%95%e8%ab%96/
本站资源仅供个人学习交流,请于下载后24小时内删除,不允许用于商业用途,否则法律问题自行承担。

评论 抢沙发

  • 昵称 (必填)
  • 邮箱 (必填)
  • 网址

大前端WP主题 更专业 更方便

联系我们联系我们