從0到1,搭建營銷中心——認識后臺系統(tǒng)(上)
后臺系統(tǒng)就像是建筑根基,假如根基打不穩(wěn),裝修得再漂亮也都是徒勞。所以,所有的后端開發(fā)和優(yōu)化都應當擺在前端之前,產(chǎn)品經(jīng)理也應當在產(chǎn)品開發(fā)設(shè)計之前就完善后端邏輯,為前端產(chǎn)品設(shè)計做好“后勤工作”。
本篇文章開始,筆者會帶著大家從0到1,搭建一套完完整整的營銷中心(集業(yè)務、營銷、結(jié)算為一體)。
全篇會分為三大主題,分別是:認識后臺系統(tǒng)、手把手搭建營銷中心、收銀結(jié)算平臺。
每個主題大約會拆分成三大塊:規(guī)劃階段、設(shè)計階段、開發(fā)階段。
希望能幫助新晉產(chǎn)品經(jīng)理快速上手,少走冤枉路。
筆者從小白至今,基本都在接觸后臺系統(tǒng),大到日GMV上億的供應鏈系統(tǒng)、小到內(nèi)部人員使用的信息維護系統(tǒng)。所以,我會盡可能將自己所知所曉一并奉上。
本文關(guān)鍵詞:業(yè)務場景串聯(lián),邏輯串聯(lián),模塊化設(shè)計。
后臺系統(tǒng)的三要點
在后臺系統(tǒng)摸爬滾打的這幾年里,我總結(jié)了三個要點:業(yè)務、邏輯、模塊化。
本文先闡述:業(yè)務和邏輯,模塊化會以大量的對比圖文,來生動的向大家展示。
1. 業(yè)務
要想做好后臺系統(tǒng),最重要的的就是了解整個業(yè)務流程和體系。甚至要比其他所有人都要更清晰,能做到各業(yè)務線之間的業(yè)務場景串聯(lián)。
舉個例子:
我之前從事一家倉儲物流公司,負責前后臺所有產(chǎn)品線的設(shè)計。
假設(shè)我把業(yè)務線拆分成:倉儲、物流、訂單,那么就需要3名前臺產(chǎn)品經(jīng)理和3名后臺產(chǎn)品經(jīng)理(不糾結(jié)人員配置,僅作為舉例)。
此時,作為倉儲后臺系統(tǒng)的產(chǎn)品經(jīng)理,不僅需要了解倉儲的業(yè)務邏輯,還需要清晰的了解物流和訂單的業(yè)務邏輯,并且要做到將三者的業(yè)務邏輯無縫串聯(lián),甚至連財務都需要了如指掌。
能夠做到以上,才算是踏入了后臺系統(tǒng)設(shè)計的最低門檻。
那么,如何才能深刻了解業(yè)務呢?
筆者很嚴肅的說:沒有任何捷徑,只有親自到一線業(yè)務場景中實際操作,才會有最完整的認知。
講完了業(yè)務的重要性,千萬別覺得假大空。這的的確確是我從事產(chǎn)品經(jīng)理以來,最為深刻的認知,希望大家能夠細細品味。
關(guān)鍵詞:業(yè)務場景串聯(lián)
2. 邏輯
邏輯是個很寬泛的詞匯,這里為大家拆分為兩點:業(yè)務邏輯和系統(tǒng)邏輯。
業(yè)務邏輯就是指:在了解完業(yè)務場景后,能夠?qū)I(yè)務場景轉(zhuǎn)換為流程圖,從而將業(yè)務層的流轉(zhuǎn)關(guān)系清晰地表達出來。
眾所周知,產(chǎn)品經(jīng)理都會組織需求評審會,向業(yè)務、開發(fā)(前后端、測試、運維等)、運營等部門的人講解本次開發(fā)的需求。
那么,有多少產(chǎn)品經(jīng)理是直接跑上來就丟出PRD文檔或交互原型圖,侃侃而談的呢?
至少筆者做產(chǎn)品之處就是如此,這顯然是不對的。因為對于開發(fā)和運營等非業(yè)務層的人來說,他們不了解業(yè)務場景,更別提業(yè)務邏輯了。
所以,真正在開始一場評審會前,產(chǎn)品經(jīng)理需要為在場所有人,清晰地描述本次開發(fā)需求的業(yè)務場景和業(yè)務邏輯。
我繼續(xù)舉個例子:
假設(shè)本次評審的是【倉庫收貨入庫】這個功能點,我們需要將倉庫收貨入庫的這個場景形象生動地描述給在場人看,那么,如何形象生動?如何確保大家都能理解呢?
這里推薦大家使用,情景化描述:以角色扮演為表達形式,配以肢體語言和日?;榫潮葦M作為加深理解
主要步驟分為:
- 單人或多人角色扮演:你可以單人多角色,也可以邀請在場人一起參與,這有點像自導自演的一場戲份。你需要將單調(diào)的業(yè)務,通過場景化的演繹,讓在場的人身臨其境,仿佛在共同參與收貨入庫的操作。
- 動態(tài)地表達:在表演過程中,你不能原地杵著不動,光靠說是不行的,你需要動態(tài)地表達——一般通過手舞足蹈的表演(肢體語言)和寫黑板(文本傳達)兩種方式結(jié)合闡述。
- 代入式的情境比擬:如果業(yè)務場景比較罕見,大多數(shù)人不太多見,那么,就需要產(chǎn)品經(jīng)理通過代入式的情境比擬,向在場的人描述一種比較常見的業(yè)務場景。
比如:大家對倉庫收貨的場景不熟悉,你就可以通過類比【在家收快遞,收完快遞將快遞分門別類整理好】這一場景,來幫助大家轉(zhuǎn)化理解。
PS:代入式的情境比擬不到萬不得已時,慎用。因為,新的情境或者不恰當?shù)那榫晨赡軙砀嗟睦Щ蠛唾M解,從而鉆進死胡同無法自拔。
這里稍稍總結(jié)一下,業(yè)務邏輯的目的在于:開始需求評審前,以生動形象的方式向大家描述業(yè)務場景,幫助大家更好的理解本次開發(fā)的需求和產(chǎn)品可能的延展性。
說完了業(yè)務邏輯,我們來說說系統(tǒng)邏輯。
系統(tǒng)邏輯與業(yè)務邏輯的側(cè)重點不同。
業(yè)務邏輯更強調(diào)場景和流程,而系統(tǒng)邏輯更強調(diào)開發(fā)視角的底層邏輯和數(shù)據(jù)庫(表結(jié)構(gòu))的關(guān)系。
就此可以看出,系統(tǒng)邏輯討論和講述的對象更偏向于開發(fā)人員。
很多人在討論:產(chǎn)品經(jīng)理到底應不應該懂技術(shù)?需不需要會寫代碼?
我個人觀點:產(chǎn)品經(jīng)理需要會寫代碼,需要懂技術(shù),但切忌精通。
對于產(chǎn)品經(jīng)理來說:懂技術(shù)能夠幫助自己了解開發(fā)的設(shè)計邏輯,不至于提出離譜的需求。并且可以通過開發(fā)設(shè)計邏輯,優(yōu)化自己的產(chǎn)品思維,在產(chǎn)品初期的MVP設(shè)計,尤為重要。
寫代碼(這里強調(diào)至少會寫簡單的SQL語言)能夠幫助產(chǎn)品經(jīng)理自助查詢某些數(shù)據(jù),便于數(shù)據(jù)統(tǒng)計和分析。但是切忌精通,是因為有很多職場上從技術(shù)轉(zhuǎn)產(chǎn)品的同學,會非常糾結(jié)于產(chǎn)品實現(xiàn)的難易度和可能性,抑制了對產(chǎn)品本身價值體現(xiàn)的思考和創(chuàng)新思維。
好了,扯的有點遠了,我們繼續(xù)說回系統(tǒng)邏輯。
系統(tǒng)邏輯是指:與開發(fā)人員就當前產(chǎn)品和未來產(chǎn)品可能存在的延展性,進行討論,得出的一套系統(tǒng)流程圖。
想必很多產(chǎn)品同學都碰到過這種場景:產(chǎn)品在不斷迭代過程中發(fā)現(xiàn),原本的架構(gòu)無法支撐未來發(fā)展的可能。
舉個簡單的例子:在做倉儲系統(tǒng)時,如果前期開發(fā)沒有考慮到總分倉和之間的業(yè)務邏輯關(guān)系,那么往后如果公司發(fā)展需要總分倉時,底層邏輯的改動量會比較大,甚至可能大量返工。
那么,作為產(chǎn)品經(jīng)理,應該如何與開發(fā)討論,得出一套比較完整的系統(tǒng)邏輯呢?
給大家?guī)c建議:
評審會后,與開發(fā)人員再次確認業(yè)務邏輯:
業(yè)務邏輯剛剛講過,在評審會開始前需要向大家闡釋清楚,那么會后為什么還要找開發(fā)人員確認呢?
道理就在于溝通過程中,信息傳遞和理解的遞減效應。我們無法保證評審會上,所有人精神都高度集中,所有人的理解都完全相同。
從理論角度上說,信息的傳遞成功率大致在60%,那么另外的40%就需要通過會后反復確認和溝通中彌補。
將已知和未知的產(chǎn)品發(fā)展可能性告知開發(fā):
在會后溝通過程中,除了再次描述業(yè)務邏輯外,更重要的是將已知和未知的產(chǎn)品可能性告知開發(fā),比如:公司既定的業(yè)務發(fā)展和腦暴的發(fā)展可能性。
這是為了幫助開發(fā)更深刻地理解業(yè)務和未來可能存在的技術(shù)瓶頸,將底層框架想的更全面,滿足往后更多的業(yè)務需求。
從產(chǎn)品角度解決問題或提出建議:在與開發(fā)討論完所有產(chǎn)品可能后,并不是將問題全部留給開發(fā)同學,而是需要從產(chǎn)品的角度出發(fā),想想是否可以從產(chǎn)品設(shè)計上幫助共同解決。
PS:系統(tǒng)邏輯的決定權(quán)在于開發(fā)設(shè)計;底層數(shù)據(jù)庫,表結(jié)構(gòu)的搭建也在于開發(fā)設(shè)計。
但是產(chǎn)品經(jīng)理務必在開發(fā)設(shè)計前找開發(fā)人員,至少是后端開發(fā),詳細的討論清楚產(chǎn)品往后的推演路徑和發(fā)展的可能性,以便開發(fā)人員獲取可能遺漏的信息,完善后端邏輯。
筆者一直在強調(diào)后端開發(fā)。不是因為前端開發(fā)不重要,而是后端猶如高樓大廈的地基,如果地基不穩(wěn)或者地基打的不深,那么哪怕裝修的再漂亮,也不穩(wěn)不高。
本文由 @小雞腿 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理,未經(jīng)許可,禁止轉(zhuǎn)載
題圖來自 Unsplash,基于 CC0 協(xié)議
跟營銷毫無關(guān)系
這屬于產(chǎn)品設(shè)計
這個不是營銷系統(tǒng)
這跟營銷系統(tǒng)有啥關(guān)系
我也是一個負責后端的產(chǎn)品,我發(fā)現(xiàn)一個毛病,就是規(guī)劃一個系統(tǒng)我沒辦法給出完整的流程圖,但是整個系統(tǒng)我又能做出來,這個是什么毛病,要怎么解決
做的過程中,一切順利嗎?還是有沒想到的,臨時補上的
模塊化的含義是什么呢?文章中似乎沒有明確![:mrgreen:](http://www.codemsi.com/wp-includes/images/smilies/mrgreen.png)
系統(tǒng)很多模塊,很復雜,要怎么畫流程圖呢,我是UI,公司原型要UI畫
你指的流程圖是哪種?一個個方塊加箭頭的那種嗎?可以看下我的另外篇文章,有提到流程圖
寫的很棒,但是對于非物流倉儲行業(yè)的PM很難看懂,對于小白來說還是比較深
倉儲這塊筆者只是舉了幾個例子,大家不用太在意
我也是一個后端開發(fā),但是缺乏一個指路人……
歐耶!我要變成海綿啦