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