从0到1，搭建一套完完整整的营销中心

在本文的开头，作者将带您从0到1建立一个完整的营销中心（集业务、营销、结算为一体）。整篇文章将分为三个主题：了解背景系统，携手搭建营销中心，收银结算平台。每个主题大约分为规划阶段、设计阶段和开发阶段三部分。希望能帮助新产品经理快速上手，避免走错路。从小白到现在，笔者基本都在接触后台系统，从日GMV数亿的供应链系统到内部人员使用的信息维护系统。因此，我会尽可能多地把我所知道和所知道的奉献给我。本文关键词：业务场景串联、逻辑串联、模块化设计。近年来，我总结了后台系统的三个要点：业务、逻辑和模块化。本文首先阐述：业务和逻辑，模块化将以大量的对比图形，生动地向您展示。1.要做好后台系统，最重要的是了解整个业务流程和系统。它甚至比其他所有人都更清楚，可以连接各业务线之间的业务场景。能做到以上，才算是踏入后台系统设计的最低门槛。那怎样才能对业务有深刻的了解呢？作者严肃地说：没有捷径，只有亲自到一线业务场景进行实际操作，才能有最完整的认知。说完业务的重要性，不要觉得假大空。这确实是我从事产品经理以来最深刻的认知。我希望你能仔细品尝。关键词：业务场景串联2。逻辑逻辑是一个非常广泛的词，分为两点：业务逻辑和系统逻辑。业务逻辑是指在了解业务场景后，可以将业务场景转换为流程图，从而清晰地表达业务层的流通关系。众所周知，产品经理将组织需求评估会议，向业务、开发（前后端、测试、运维等）、操作等部门的人员解释了本次开发的需要。那么，有多少产品经理直接跑出PRD文档或交互原型图，侃侃而谈呢？至少作者做产品是这样的，这显然是错误的。因为对于开发和运营等非业务层的人来说，他们不了解业务场景，更不用说业务逻辑了。因此，在真正开始审查会议之前，产品经理需要清楚地描述开发所需的业务场景和业务逻辑。我继续举个例子：这里推荐你使用，情景描述：以角色扮演为表达形式，以肢体语言和日常情境比较作为加深理解的主要步骤分为：单人或多人角色扮演：你可以单人或多个角色，也可以邀请在场的人参与，这有点像导演和表演的场景。通过场景化的演绎，你需要让在场的人身临其境，仿佛在一起参与收货入库的操作。动态表达：在表演过程中，你不能站在原地，只是说不好，你需要动态表达——一般通过舞蹈表演（肢体语言）和写黑板（文本交流）两种方式。替代情境比较：如果业务场景相对罕见，大多数人并不少见，那么产品经理需要通过替代情境比较向在场的人描述一个更常见的业务场景。比如你不熟悉仓库收货的场景，可以通过类比【在家收快递，收快递后分类整理快递】来帮助你转化理解。PS：当代入式情境不到万不得已时，谨慎使用。因为，新的情况或不恰当的情况可能会带来更多的困惑和困惑，从而无法从死胡同中解脱出来。这里有一点总结。业务逻辑的目的是在开始需求评估之前，以生动的方式描述业务场景，帮助您更好地了解本次开发的需求和产品可能的延展性。在完成了业务逻辑之后，让我们谈谈系统逻辑。不同的侧重点是系统逻辑和业务逻辑。业务逻辑强调场景和流程，系统逻辑强调开发视角的底层逻辑与数据库(表结构)之间的关系。由此可见，系统逻辑讨论和叙述的对象更倾向于开发人员。很多人都在讨论:产品经理应该懂技术吗？你需要能写代码吗？我个人的观点:产品经理需要会写代码，懂技术，但不要精通。对于产品经理来说，了解技术可以帮助他们理解开发的设计逻辑，而不会提出离谱的需求。通过开发设计逻辑，优化产品思维，MVP设计在产品初期尤为重要。编写代码(这里强调至少可以编写简单的SQL语言)可以帮助产品经理自己查询一些数据，方便数据统计和分析。但不要精通，因为有很多学生从技术到产品在工作场所，将非常纠结于产品实现的难度和可能性，抑制思维和创新思维反映产品本身的价值。好了，有点远了。让我们继续谈谈系统逻辑。系统逻辑是指与开发人员讨论当前产品和未来产品可能存在的延展性，得到的一套系统流程图。想必很多产品同学都遇到过这样的场景:产品在不断迭代的过程中发现，原有的结构无法支撑未来发展的可能性。举个简单的例子:在做仓储系统的时候，如果前期开发没有考虑到总分仓和之间的业务逻辑关系，那么如果公司未来开发需要总分仓，底层逻辑的变化会比较大，甚至可能会大量返工。那么，作为一名产品经理，我们应该如何与开发讨论，获得一套相对完整的系统逻辑呢？给你一些建议：评审会议结束后，与开发人员再次确认业务逻辑：业务逻辑刚刚提到，你需要在评审会议开始前向你解释清楚，那么为什么要在会议结束后找到开发人员来确认呢？事实在于信息传递和理解在沟通过程中的递减效应。在评审会上，我们不能保证每个人的精神都是高度集中的，每个人的理解都是一样的。从理论上讲，信息传递的成功率约为60%，因此其他40%需要在会后反复确认和沟通中弥补。告知已知和未知产品开发的可能性：在会后沟通过程中，除了再次描述业务逻辑外，更重要的是告知已知和未知产品的可能性，如公司既定的业务发展和脑暴发展的可能性。这是为了帮助发展更深入地了解业务和未来可能存在的技术瓶颈，更全面地思考底层框架，满足未来更多的业务需求。从产品的角度解决问题或提出建议：在与开发人员讨论所有产品的可能性后，我们不应该把所有问题都留给开发人员，而应该从产品的角度考虑我们是否能帮助共同解决产品设计中的问题。PS：决定系统逻辑的权利在于开发设计；底层数据库，表结构的构建也在于开发设计。但产品经理在开发设计前必须找到开发人员，至少是后端开发，详细讨论产品未来的演绎路径和开发的可能性，以便开发人员获取可能遗漏的信息，提高后端逻辑。作者一直强调后端开发。不是因为前端开发不重要，而是因为后端就像高层建筑的基础。如果基础不稳定或者基础不深，即使装修漂亮，也不稳定。