秒速时时彩

400-080-8868
秒速时时彩 > 新闻资讯 > 移动网站 > 微信开发 > 实战:从0到1 搭建营销中心——认识后台系统(上)

实战:从0到1 搭建营销中心——认识后台系统(上)

盛世华彩:2019-03-18 17:01:02 | 阅读数: Loading... | 分享到:

(网经社讯)后台系统就像是建筑根基,假如根基打不稳,装修得再漂亮也都是徒劳。所以,所有的后端开发和优化都应当摆在前端之前,产品经理也应当在产品开发设计之前就完善后端逻辑,为前端产品设计做好“后勤工作”。

本篇文章开始,笔者会带着大家从0到1,搭建一套完完整整的营销中心(集业务、营销、结算为一体)。

秒速时时彩全篇会分为三大主题,分别是:认识后台系统、手把手搭建营销中心、收银结算平台。

每个主题大约会拆分成三大块:规划阶段、设计阶段、开发阶段。

希望能帮助新晋产品经理快速上手,少走冤枉路。

笔者从小白至今,基本都在接触后台系统,大到日GMV上亿的供应链系统、小到内部人员使用的信息维护系统。所以,我会尽可能将自己所知所晓一并奉上。

本文关键词:业务场景串联,逻辑串联,模块化设计。

后台系统的三要点

在后台系统摸爬滚打的这几年里,我总结了三个要点:业务、逻辑、模块化。

本文先阐述:业务和逻辑,模块化会以大量的对比图文,来生动的向大家展示。

1. 业务

要想做好后台系统,最重要的的就是了解整个业务流程和体系。甚至要比其他所有人都要更清晰,能做到各业务线之间的业务场景串联。

举个例子:

我之前从事一家仓储物流公司,负责前后台所有产品线的设计。

假设我把业务线拆分成:仓储、物流、订单,那么就需要3名前台产品经理和3名后台产品经理(不纠结人员配置,仅作为举例)。

此时,作为仓储后台系统的产品经理,不仅需要了解仓储的业务逻辑,还需要清晰的了解物流和订单的业务逻辑,并且要做到将三者的业务逻辑无缝串联,甚至连财务都需要了如指掌。

能够做到以上,才算是踏入了后台系统设计的最低门槛。

那么,如何才能深刻了解业务呢?

笔者很严肃的说:没有任何捷径,只有亲自到一线业务场景中实际操作,才会有最完整的认知。

讲完了业务的重要性,千万别觉得假大空。这的的确确是我从事产品经理以来,最为深刻的认知,希望大家能够细细品味。

关键词:业务场景串联

2. 逻辑

逻辑是个很宽泛的词汇,这里为大家拆分为两点:业务逻辑和系统逻辑。

业务逻辑就是指:在了解完业务场景后,能够将业务场景转换为流程图,从而将业务层的流转关系清晰地表达出来。

众所周知,产品经理都会组织需求评审会,向业务、开发(前后端、测试、运维等)、运营等部门的人讲解本次开发的需求。

那么,有多少产品经理是直接跑上来就丢出PRD文档或交互原型图,侃侃而谈的呢?

秒速时时彩至少笔者做产品之处就是如此,这显然是不对的。因为对于开发和运营等非业务层的人来说,他们不了解业务场景,更别提业务逻辑了。

所以,真正在开始一场评审会前,产品经理需要为在场所有人,清晰地描述本次开发需求的业务场景和业务逻辑。

我继续举个例子:

假设本次评审的是【仓库收货入库】这个功能点,我们需要将仓库收货入库的这个场景形象生动地描述给在场人看,那么,如何形象生动?如何确保大家都能理解呢?

这里推荐大家使用,情景化描述:以角色扮演为表达形式,配以肢体语言和日常化情境比拟作为加深理解

主要步骤分为:

  1. 单人或多人角色扮演:你可以单人多角色,也可以邀请在场人一起参与,这有点像自导自演的一场戏份。你需要将单调的业务,通过场景化的演绎,让在场的人身临其境,仿佛在共同参与收货入库的操作。

  2. 动态地表达:在表演过程中,你不能原地杵着不动,光靠说是不行的,你需要动态地表达——一般通过手舞足蹈的表演(肢体语言)和写黑板(文本传达)两种方式结合阐述。

  3. 代入式的情境比拟:如果业务场景比较罕见,大多数人不太多见,那么,就需要产品经理通过代入式的情境比拟,向在场的人描述一种比较常见的业务场景。

比如:大家对仓库收货的场景不熟悉,你就可以通过类比【在家收快递,收完快递将快递分门别类整理好】这一场景,来帮助大家转化理解。

PS:代入式的情境比拟不到万不得已时,慎用。因为,新的情境或者不恰当的情境可能会带来更多的困惑和费解,从而钻进死胡同无法自拔。

这里稍稍总结一下,业务逻辑的目的在于:开始需求评审前,以生动形象的方式向大家描述业务场景,帮助大家更好的理解本次开发的需求和产品可能的延展性。

说完了业务逻辑,我们来说说系统逻辑。

系统逻辑与业务逻辑的侧重点不同。

业务逻辑更强调场景和流程,而系统逻辑更强调开发视角的底层逻辑和数据库(表结构)的关系。

就此可以看出,系统逻辑讨论和讲述的对象更偏向于开发人员。

很多人在讨论:产品经理到底应不应该懂技术?需不需要会写代码?

我个人观点:产品经理需要会写代码,需要懂技术,但切忌精通。

对于产品经理来说:懂技术能够帮助自己了解开发的设计逻辑,不至于提出离谱的需求。并且可以通过开发设计逻辑,优化自己的产品思维,在产品初期的MVP设计,尤为重要。

写代码(这里强调至少会写简单的SQL语言)能够帮助产品经理自助查询某些数据,便于数据统计和分析。但是切忌精通,是因为有很多职场上从技术转产品的同学,会非常纠结于产品实现的难易度和可能性,抑制了对产品本身价值体现的思考和创新思维。

好了,扯的有点远了,我们继续说回系统逻辑。

系统逻辑是指:与开发人员就当前产品和未来产品可能存在的延展性,进行讨论,得出的一套系统流程图。

想必很多产品同学都碰到过这种场景:产品在不断迭代过程中发现,原本的架构无法支撑未来发展的可能。

举个简单的例子:在做仓储系统时,如果前期开发没有考虑到总分仓和之间的业务逻辑关系,那么往后如果公司发展需要总分仓时,底层逻辑的改动量会比较大,甚至可能大量返工。

那么,作为产品经理,应该如何与开发讨论,得出一套比较完整的系统逻辑呢?

给大家几点建议:

评审会后,与开发人员再次确认业务逻辑:

业务逻辑刚刚讲过,在评审会开始前需要向大家阐释清楚,那么会后为什么还要找开发人员确认呢?

道理就在于沟通过程中,信息传递和理解的递减效应。我们无法保证评审会上,所有人精神都高度集中,所有人的理解都完全相同。

秒速时时彩从理论角度上说,信息的传递成功率大致在60%,那么另外的40%就需要通过会后反复确认和沟通中弥补。

将已知和未知的产品发展可能性告知开发:

在会后沟通过程中,除了再次描述业务逻辑外,更重要的是将已知和未知的产品可能性告知开发,比如:公司既定的业务发展和脑暴的发展可能性。

秒速时时彩这是为了帮助开发更深刻地理解业务和未来可能存在的技术瓶颈,将底层框架想的更全面,满足往后更多的业务需求。

从产品角度解决问题或提出建议:在与开发讨论完所有产品可能后,并不是将问题全部留给开发同学,而是需要从产品的角度出发,想想是否可以从产品设计上帮助共同解决。

PS:系统逻辑的决定权在于开发设计;底层数据库,表结构的搭建也在于开发设计。

但是产品经理务必在开发设计前找开发人员,至少是后端开发,详细的讨论清楚产品往后的推演路径和发展的可能性,以便开发人员获取可能遗漏的信息,完善后端逻辑。

笔者一直在强调后端开发。不是因为前端开发不重要,而是后端犹如高楼大厦的地基,如果地基不稳或者地基打的不深,那么哪怕装修的再漂亮,也不稳不高。(来源:人人都是产品经理 文/小鸡腿;编选:网经社-盛世华彩)

关于我们
公司简介 资质荣誉 团队介绍 联系我们
电子商务
B2C电商 O2O电商 BBC电商
网站建设
企业网站建设 品牌网站建设 响应式网站建设 营销网站建设

与我们合作

与盛世华彩合作,您将会得到更成熟的品牌建设服务。力求呈现最好的品牌建设成果 主营业务:商城网站建设、电子商务网站建设、购物网站建设
品牌咨询热线400-080-8868
© 2003-2017 深圳市盛世华彩科技有限公司 All Rights Reserved   
营业执照:4403011039233575站长统计深圳网站建设_深圳网站制作_深圳网页设计_网站设计公司_深圳网站建设公司 版权所有

在线客服

当前非工作时间
回复可能会有延迟
请稍适等候!
官方二维码
微信扫一扫

400-080-8868

服务监督
0755-83692230
返回顶部
qq分分彩投注 幸运飞艇机器人 天津11选5和值 赛车秒秒彩 天津十一选五前三走势 河北11选5 河北11选5和值分布 天津11选5走势图 秒速三分彩 三分时时彩