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

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

对象:非技术人员

优信彩票购彩大厅 1

目的:高效与技术人员沟通

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

掌握技能包含主要3点:

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

  1. 技术职能划分了解

  2. 常用技术术语了解

  3. 理解开发人员思维(技术思维vs产品思维)

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

用户代言人:产品经理

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

实现代言人:技术人员

优信彩票购彩大厅 2

第一部分 技术思维vs产品思维

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

技术思维

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

  1. 功能实现

  2. 开发难易

  3. 后期维护

  4. 改动成本

后台系统的三要点

产品思维

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

【要站在用户思维,否则以技术思维可能最后做出来产品过于生硬,偏工具】

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

  1. 产品定位

  2. 需求场景

  3. 用户体验

  4. 业务目标

优信彩票购彩大厅 3

产品思维vs技术思维实例:

  1. 业务

微信通讯录及会话设计:

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

从微信第二个“tab”进去,点击好友主页,点击“发消息”,点击左上角“返回”,却退回了第一个tab“微信”

举个例子:

技术思维:堆栈式设计,即从哪里进入,就返回到哪里。(路径为1-2-3 / 回退路径即为3-2-1)

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

产品思维:更加符合场景,贴合用户使用习惯,遵从人性。

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

备注:以上的微信通讯录及会话设计操作路径示例,本人按照上面操作实操时却发现回退到的是上一个页面,而非作者说的返回第一个tab“微信”,可能是新版本的微信改了吧,作者当时是旧版本吧。不过实际中确实很多类似这种例子。尤其是用户使用习惯。

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

优信彩票购彩大厅 4图片发自简书App

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

其他:技术人员往往不具备同理心,及换位思考的能力(产品方面,生活其他角度除外)。但是产品经理必须同理心及换位思考的能力。这是产品经理必须具备的一种必备素质。所以产品经理需要内心强大。来抵抗一些来自程序员方面的压力。但最终产品经理任然需要站在产品角度,用户角度去完成产品设计。也是基于此方面(思维方式及心理能力)产品经理和技术人员是不同的,所以这也是产生分歧的根本原因。

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

第二部分:技术职能划分

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

CTO:技术部门leader或产品

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

架构师:负责系统整体技术架构和技术选型仅次于CTO。

关键词:业务场景串联

前端开发:分为网页前端、移动客户端前端,移动客户端又分为Android、ios、Windows Phone【安卓设计和ios有不同的开发设计规范】

  1. 逻辑

后端开发:服务端开发,包括数据库设计与开发,应用接口开发。

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

系统运维:服务器管理与整体维护,应用发布。如服务器数量是否够等。

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

优信彩票购彩大厅 5图片发自简书App

优信彩票购彩大厅 6

上图为作者的创业公司的一个工作流程。具体公司可能不太一样,但大同小异。

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

几点:周为节点进行产品迭代。高保真的demo。这块是作者公司需要做的。根据笔者经历而言,有的创业公司需要做代码可运行的高保真demo,如需要用demo和投资人沟通融资。大部分公司只需要评审非代码层面的原型及需求文档即可。

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

个人总结:利用用户思维去跟开发解释更符合用户场景。而不是技术实现。这也是我在工作中经常遇到的。有时候可能太过于同理心了【比如特别“同情”技术人员】就会把一些“不易”开发的省却成简单的,这其实很多时候是不正确的做法。这样往往设计的产品过于机械化、工具化。产品经理应该站在用户思维,不要走偏记得!

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

第三部分 常用技术术语

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

【此处需要划重点,着重记忆,对你以后和技术沟通和理解技术有很大帮助】

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

1. API:服务器端的应用接口。应用接口类似于服务器端定义好的一个协议,这个协议有一些的数据结构,会有一个固定的标识。前端同学需要访问这个协议,通过这个协议将具体的数据传送给服务器端,服务器端基于这个固定好的协议接受数据,实现前后端互联互通。API就是协议,前后端共同遵从的协议。

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

eg:登陆功能:后端定义好需要用户名和密码,前端需要将用户名和密码传送给服务器端,服务器端验证成功就好了。

主要步骤分为:单人或多人角色扮演:你可以单人多角色,也可以邀请在场人一起参与,这有点像自导自演的一场戏份。你需要将单调的业务,通过场景化的演绎,让在场的人身临其境,仿佛在共同参与收货入库的操作。动态地表达:在表演过程中,你不能原地杵着不动,光靠说是不行的,你需要动态地表达——一般通过手舞足蹈的表演和写黑板两种方式结合阐述。代入式的情境比拟:如果业务场景比较罕见,大多数人不太多见,那么,就需要产品经理通过代入式的情境比拟,向在场的人描述一种比较常见的业务场景。

2. Json/xml:属于数据协议。eg:登录名/密码。实际就是通过json这个承载体,可以理解为打包文件,把用户名和密码放到里面,然后通过API这个协议传送给服务器。

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

  1. URL:地址。

  2. html/css:web网页使用的布局语言、装饰表

  3. 数据库:存储数据,数据查询,检索

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

6. Git/SVN:管理代码,代码存储的服务。实现多分支管理,远程和本地的开发。不同的代码同学共同协作。

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

前端术语

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

Activity:每一个屏幕展示的页就是这个,这个界面上所有的逻辑,所有的展示

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

ViewController:每一个屏幕展示的页就是这个。同上,只是一个是ios一个是安卓。

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

lib:eg:用百度地图的sdk,可直接使用这项服务第三方库帮助我们做复杂的事情

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

ListView:其实就是app里面经常能看到的列表,例如微信里面的聊天页面就是个列表。

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

TableView:同上。

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

View:基础组件都是一个view,如一个按钮,一个选择框,一个复选框都是一个view,甚至一段文字的展示都是一个view。指的是具体前端页面展示的一个具体的组件。

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

第四部分 如何与技术人员沟通

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

【很重要,非技术产品经理90%都会遇到】

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

产品经理说白话,技术人员说黑话。产品经理需要自己翻译给自己听,给用户听。

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

产品经理主导沟通方向,实际工作中讨论往往从原本的产品讨论很容易陷入技术细节讨论。应该避免陷入技术细节讨论,从场景和用户体验出发。对实现方案的讨论,非技术产品经理是无法参与的。技术人员找产品经理讨论,往往是确认产品需求但最终就成了讨论技术问题。如何解决这个问题:1)从场景出发,2)从用户体验出发。

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

真正用户能用的产品。

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

因此产品经理与开发人员沟通的过程中要把握沟通的方向,要知道聊的是什么,每一次沟通要有目的和结论。沟通要往哪个方向引导。一切以用户场景和用户体验为主。否则讨论就会走向偏题的状态。这也不是自己擅长的。

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

如下图为技术人员经常会对产品经理说的话,你是不是很有同感?

给大家几点建议:

如果遇到以上问题:产品经理是改产品设计还是改需求。

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

优信彩票购彩大厅 7图片发自简书App

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

产生上述原因可能有产品需求文档里面没写,或者技术人员觉得这个重新做成本太大。实现不了,或者技术人员直接告诉你只是后端的问题。

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

如何解决上述问题,举两个例子:

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

【引导型沟通,有序的沟通】

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

第一个“这个实现不了”:不要被技术所限制,但要在技术边界之内。产品是需要衡量投入产出比。挖掘技术人员背后的初衷,是因为时间不够(讲清楚紧急程度,就改为可实现了),还是技术难度(技术人员也是需要技术调研),另一种是确实技术实现不了。一定要搞清楚是哪一种,不要随意更改需求,不然是对用户的不负责,是对产品的不负责。

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

第二个“这是后端的问题”:当我们使用产品时发现了一个bug,可能第一时间直接问开发同学或测试,问怎么解决,技术人人员往往告诉你是后端的问题。那么你应该找谁,是找前端是找后端,正确的方式是不应该直接找后端,而是需要问前端:你是如何排查这个问题的,我们应该怎么解决这个问题,如果要解决这个问题,我能为你做什么,一起探讨这个问题的解决方案。

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

分析技术人员的需求:Want or Need。需求的本质。

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

用户:需要一个更快的马

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

福特:提供了一个汽车

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

第五部分 非技术背景产品经理学习指南

笔者一直在强调后端开发。不是因为前端开发不重要,而是后端犹如高楼大厦的地基,如果地基不稳或者地基打的不深,那么哪怕装修的再漂亮,也不稳不高。

懂用户比懂产品重要,懂产品比懂技术重要

本文由 @小鸡腿 原创发布于人人都是产品经理,未经许可,禁止转载

设计一款产品:最先考虑的不应该是技术,而应该是用户,需要我们在什么场景下位他们解决什么问题。这样才能更好的设计,呈现给用户。产品本身不能过于流程化和机械化。设计一款符合用户使用习惯的产品。

题图来自 Unsplash,基于 CC0 协议

总结

  1. 发挥非实现模式思维的优势,理解并思考场景

  2. 多与技术人员沟通,理解实现模型思维

3. 学会讲故事。讲故事能力非常重要,往往都说产品经理就是ceo的学前班,这个我很认同。产品经理需要面向运营、市场、财务、法务等等。产品经理要让这个故事讲得精彩,让大家一起把事情做好。这个故事的引导者和制造者就是产品经理。并且产品经理需要有广度思维。

最终我们所创造的用户价值,才是最终能带来实际效果的,才能造福用户,被这个行业和市场所接受,我们应该为这个行业创造价值,为这个行业改变一些事情,为这个世界做一些事情。

最后送给大家

本文由优信彩票购彩大厅发布于互联网资讯,转载请注明出处:从0到1,搭建营销中心——认识后台系统(上)优

您可能还会对下面的文章感兴趣: