后台系统就像是建筑根基，假如根基打不稳，装修得再漂亮也都是徒劳。所以，所有的后端开发和优化都应当摆在前端之前，产品经理也应当在产品开发设计之前就完善后端逻辑，为前端产品设计做好“后勤工作”。
本篇文章开始，笔者会带着大家从0到1，搭建一套完完整整的营销中心（集业务、营销、结算为一体）。
全篇会分为三大主题，分别是：认识后台系统、手把手搭建营销中心、收银结算平台。
每个主题大约会拆分成三大块：规划阶段、设计阶段、开发阶段。
希望能帮助新晋产品经理快速上手，少走冤枉路。
笔者从小白至今，基本都在接触后台系统，大到日GMV上亿的供应链系统、小到内部人员使用的信息维护系统。所以，我会尽可能将自己所知所晓一并奉上。
后台系统的三要点
在后台系统摸爬滚打的这几年里，我总结了三个要点：业务、逻辑、模块化。
本文先阐述：业务和逻辑，模块化会以大量的对比图文，来生动的向大家展示。
1. 业务
要想做好后台系统，最重要的的就是了解整个业务流程和体系。甚至要比其他所有人都要更清晰，能做到各业务线之间的业务场景串联。
举个例子：
我之前从事一家仓储物流公司，负责前后台所有产品线的设计。
假设我把业务线拆分成：仓储、物流、订单，那么就需要3名前台产品经理和3名后台产品经理（不纠结人员配置，仅作为举例）。
此时，作为仓储后台系统的产品经理，不仅需要了解仓储的业务逻辑，还需要清晰的了解物流和订单的业务逻辑，并且要做到将三者的业务逻辑无缝串联，甚至连财务都需要了如指掌。
能够做到以上，才算是踏入了后台系统设计的最低门槛。
那么，如何才能深刻了解业务呢？
笔者很严肃的说：没有任何捷径，只有亲自到一线业务场景中实际操作，才会有最完整的认知。
讲完了业务的重要性，千万别觉得假大空。这的的确确是我从事产品经理以来，最为深刻的认知，希望大家能够细细品味。
关键词：业务场景串联
2. 逻辑
逻辑是个很宽泛的词汇，这里为大家拆分为两点：业务逻辑和系统逻辑。
业务逻辑就是指：在了解完业务场景后，能够将业务场景转换为流程图，从而将业务层的流转关系清晰地表达出来。
众所周知，产品经理都会组织需求评审会，向业务、开发（前后端、测试、运维等）、运营等部门的人讲解本次开发的需求。
那么，有多少产品经理是直接跑上来就丢出PRD文档或交互原型图，侃侃而谈的呢？
至少笔者做产品之处就是如此，这显然是不对的。因为对于开发和运营等非业务层的人来说，他们不了解业务场景，更别提业务逻辑了。
所以，真正在开始一场评审会前，产品经理需要为在场所有人，清晰地描述本次开发需求的业务场景和业务逻辑。
我继续举个例子：
假设本次评审的是【仓库收货入库】这个功能点，我们需要将仓库收货入库的这个场景形象生动地描述给在场人看，那么，如何形象生动？如何确保大家都能理解呢？
这里推荐大家使用，情景化描述：以角色扮演为表达形式，配以肢体语言和日常化情境比拟作为加深理解
主要步骤分为：
单人或多人角色扮演：你可以单人多角色，也可以邀请在场人一起参与，这有点像自导自演的一场戏份。你需要将单调的业务，通过场景化的演绎，让在场的人身临其境，仿佛在共同参与收货入库的操作。
动态地表达：在表演过程中，你不能原地杵着不动，光靠说是不行的，你需要动态地表达——一般通过手舞足蹈的表演（肢体语言）和写黑板（文本传达）两种方式结合阐述。
代入式的情境比拟：如果业务场景比较罕见，大多数人不太多见，那么，就需要产品经理通过代入式的情境比拟，向在场的人描述一种比较常见的业务场景。
比如：大家对仓库收货的场景不熟悉，你就可以通过类比【在家收快递，收完快递将快递分门别类整理好】这一场景，来帮助大家转化理解。
PS：代入式的情境比拟不到万不得已时，慎用。因为，新的情境或者不恰当的情境可能会带来更多的困惑和费解，从而钻进死胡同无法自拔。
这里稍稍总结一下，业务逻辑的目的在于：开始需求评审前，以生动形象的方式向大家描述业务场景，帮助大家更好的理解本次开发的需求和产品可能的延展性。
业务逻辑更强调场景和流程，而系统逻辑更强调开发视角的底层逻辑和数据库（表结构）的关系。
就此可以看出，系统逻辑讨论和讲述的对象更偏向于开发人员。
很多人在讨论：产品经理到底应不应该懂技术？需不需要会写代码？
我个人观点：产品经理需要会写代码，需要懂技术，但切忌精通。
对于产品经理来说：懂技术能够帮助自己了解开发的设计逻辑，不至于提出离谱的需求。并且可以通过开发设计逻辑，优化自己的产品思维，在产品初期的MVP设计，尤为重要。
写代码（这里强调至少会写简单的SQL语言）能够帮助产品经理自助查询某些数据，便于数据统计和分析。但是切忌精通，是因为有很多职场上从技术转产品的同学，会非常纠结于产品实现的难易度和可能性，抑制了对产品本身价值体现的思考和创新思维。
好了，扯的有点远了，我们继续说回系统逻辑。
系统逻辑是指：与开发人员就当前产品和未来产品可能存在的延展性，进行讨论，得出的一套系统流程图。
想必很多产品同学都碰到过这种场景：产品在不断迭代过程中发现，原本的架构无法支撑未来发展的可能。
举个简单的例子：在做仓储系统时，如果前期开发没有考虑到总分仓和之间的业务逻辑关系，那么往后如果公司发展需要总分仓时，底层逻辑的改动量会比较大，甚至可能大量返工。
那么，作为产品经理，应该如何与开发讨论，得出一套比较完整的系统逻辑呢？
给大家几点建议：
业务逻辑刚刚讲过，在评审会开始前需要向大家阐释清楚，那么会后为什么还要找开发人员确认呢？
道理就在于沟通过程中，信息传递和理解的递减效应。我们无法保证评审会上，所有人精神都高度集中，所有人的理解都完全相同。
从理论角度上说，信息的传递成功率大致在60%，那么另外的40%就需要通过会后反复确认和沟通中弥补。
将已知和未知的产品发展可能性告知开发：
在会后沟通过程中，除了再次描述业务逻辑外，更重要的是将已知和未知的产品可能性告知开发，比如：公司既定的业务发展和脑暴的发展可能性。
这是为了帮助开发更深刻地理解业务和未来可能存在的技术瓶颈，将底层框架想的更全面，满足往后更多的业务需求。
从产品角度解决问题或提出建议：在与开发讨论完所有产品可能后，并不是将问题全部留给开发同学，而是需要从产品的角度出发，想想是否可以从产品设计上帮助共同解决。
PS：系统逻辑的决定权在于开发设计；底层数据库，表结构的搭建也在于开发设计。
但是产品经理务必在开发设计前找开发人员，至少是后端开发，详细的讨论清楚产品往后的推演路径和发展的可能性，以便开发人员获取可能遗漏的信息，完善后端逻辑。
笔者一直在强调后端开发。不是因为前端开发不重要，而是后端犹如高楼大厦的地基，如果地基不稳或者地基打的不深，那么哪怕装修的再漂亮，也不稳不高。
