本文由做者朱夢珺受權網易雲社區發佈。html
從5月份接手嚴選分銷系統到如今,被坑過無數次優化
因此不能我一我的被坑,被坑過的那些事要告訴大家spa
1. 從用戶端到後臺系統,最大的區別就是業務自己設計
以前作郵箱大師的時候,產品需求多數來源於市場調研和用戶需求分析,咱們能夠用數據來講明功能的重要性,用使用率來決定功能的優化方向。而嚴選現有的後臺系統多數是基於現有流程的設計,現有的流程存在即顆粒。它不須要有發現需求的眼睛,而是須要深入理解業務的能力。只有正確的梳理現有流程及其問題,才能合理的流程線上化。若是沒有深刻的理解,直接的結果就是隻解決了表層的問題,根本的問題會一直存在於業務中。htm
好比一直以來困擾渠道運營不少的庫存問題。原有的庫存分配採用的人工劃撥的方式,即劃撥多少銷售多少。直接致使的問題就是每次庫存耗盡都須要運營人工增長庫存,而主站即將售罄時有須要運營回撥剩餘庫存,會消耗大量的人工。因此在第一次設計解決方案設計時,重點關注人工消耗的問題了,打算採用自動劃撥代替了人工劃撥,以圖達到節省人工的目的。而實際上線後發現,人工劃撥的請求並無變少,一者是發現系統調度的規則還有優化的空間,兩者是發現庫存回撥操做實際上商品快速銷售和渠道庫存佔用的矛盾,這纔是真正核心須要解決的問題。blog
2. 後臺的產品再也不僅僅是功能的設計接口
以前作郵箱大師的時候,功能設計的過程當中關心功能流程如何?用戶體驗如何?UI展現如何?在接觸後臺系統後發現,不是全部的產品設計,都是完整的方案呈現,也不都是設計功能自己。開發
先說完整方案呈現這件事,在分銷系統的迭代過程當中,完全的體驗了把小步快跑的快感。以商品爲例,原策劃中,完整的設計了從信息錄入、分級斷定、到分級使用的完整業務場景,開發時間評估須要1個月以上。而商品分級在渠道中推廣的核心數據只有分級數據自己,其餘步驟能夠暫時經過人工計算錄入來完成,這部分的系統開發會大大影響了功能上線推廣的速度,不該該放在同等的開發優先級上。get
再來講設計功能這件事,後臺系統和用戶端相比,數據的重要性大大凸顯。對於分銷系統來講,數據能夠是商品、能夠是庫存、也能夠是訂單。對於我來講,在設計功能的方面,也須要深刻了解我所擁有的數據,才能提供更多的功能。好比分銷以前的商品數據間接從商品中心獲取,咱們直接簡單的將信息傳遞給第三方。而隨着商品數據的擴充,簡單的信息提供已經不能知足需求。我須要詳細瞭解商品的每一個信息字段,閱讀每個接口的信息,才能針對分銷的場景,對商品字段二次包裝,在提供給渠道方。簡單的停留在功能設計,只能成爲過去式。產品
3 覆盤很重要,多忙都不能忘
曾經的我最懼怕覆盤,我單純的認爲,我本身內心知道就行了,覆盤什麼不重要。如今的我,不管工做多忙,都要對功能進行復盤。寫策劃的時候我更多的關注功能細節,而覆盤的時候可以讓我更加完整的審視整個方案,認真思考是否正確的解決了問題。尤爲是對於線上已有的功能,BUG的發現和修復終究只是打補丁,按期的覆盤纔可以發現真正問題的核心。
以訂單結算爲例,始終是內控和財務對帳的心病。每次對帳都會發現有很多的訂單計算錯誤,錯誤的緣由也是五花八門,沒有必定的規律。雖然有針對發現的問題,修正系統,可是始終沒有解決核心的問題。因而我決定從原有系統每一個計算步驟入手,發現核心的問題在於原有產品不清楚業務邏輯,混淆了銷售流水和結算流水,須要針對實際的使用場景進行拆分,才能正確的計算金額。至此以後的修改,才真的起到了做用。
到如今,我還依稀記得接手分銷系統時的一臉懵逼。同時,我也感謝分銷系統,雖然無數次掉進坑裏再爬出來,可是我也真正得到了成長。如今的我,對於分銷業務的認識更加的深入,對於它的發展也有更多的想法。2018,我和嚴選分銷一塊兒繼續成長
更多網易技術、產品、運營經驗分享請訪問網易雲社區。
相關文章:
【推薦】 Structure Streaming和spark streaming原生API訪問HDFS文件數據對比
【推薦】 【重磅發佈】最風騷的走位,最撩人的峯會,裂變!變!變!變!變!變!搶!