广告位

您现在的位置是:主页 > 职场 >

后台产品经理需要知道哪些事

2020-09-22 16:20职场 人已围观

简介编辑导语:后台产品经理对互联网公司来说是很重要的,他是整个后端业务需求的整理者,需要串起整个业务的前中后所有流程。后端业务往往并不像前端需求那样简单易理解,这要求...

编辑导语:后台产品经理对互联网公司来说是很重要的,他是整个后端业务需求的整理者,需要串起整个业务的前中后所有流程。后端业务往往并不像前端需求那样简单易理解,这要求后端产品经理能够让业务正确的运转并对效果进行评估,能将充满个性化理解与执行的业务过程通过与业务各端人员进行平衡和协调以确定标准化方案。

后台产品经理需要知道哪些事

不同发展阶段、不同行业方向的互联网公司都需要后台产品经理,因为后台是支撑业务发展的必备基础,有了后台的基础支持才会有前台的用户增长产品、商业化产品、策略产品、数据产品等细分方向的繁荣。

但是由于后台产品的不可见性、以及跟公司具体业务强相关,不像前台的功能那样有很多参考的竞品,因此刚入行的后台产品经理往往缺乏学习模板,需要靠自己不断的提炼总结。

回顾我的学习路径,发现网上找的后台方法论文章要么写的过于表象,看的很热闹但干货很少,要么没有剥离业务领域进行抽象,让其他领域的人很难学习应用。

希望我写的能摆脱这两种文章的困境,给入门的小白一点真正的帮助。

本文主要内容:

一、什么是后台产品

由于业界没有严格的定义,不同行业不同类型的公司都在招聘后台产品经理,所以后台的范围是相对模糊的,每个人的理解可能也不一样,很多人还把B端和后台划等号。

我认为B端和后端有交集但也有很大的不同,而后端和后台差不多,是一个比较泛的概念,偏指对产品前端进行业务支撑类的产品,范围包括且不限于以下几类:1. C端产品的后台比如社交内容C端产品的CMS(内容管理系统),电商产品的商品系统、订单系统、支付系统,较通用的会员系统、数据统计系统等等,这些后台会直接给前台提供支持。2. 业务处理系统企业内部的业务处理系统一般不是直接支持C端,而是解决企业内部的业务需求,提高企业运转效率,比如OA系统、财务系统、CRM系统、ERP系统等。3. 平台级产品当一个C端产品做大以后,可能会出现第三方,这时的后台不仅需要支持原有的C端,还需要给第三方提供能力,比如开放平台。

或者一个既要面对C端用户,又要整合产品/内容提供方的平台,比如蚂蚁保险的后台,既要承接不同保险公司的保险产品,又要支撑前端提供给用户的服务。

一个大型的互联网产品,它的后台往往是以上几种类型的组合,比如微信公众平台,它是C端公众号的后台管理系统,也是一个CMS系统,还是一个开放平台。

二、后台产品的特点

既然随着产品的细化区分出了前端和后台产品,那各自就承担了不同的职责。

前端产品直接面对用户,侧重于对用户需求、用户心理的把握,通过好的用户体验来获得用户提升收入,而后台产品的特点体现在以下几个方面:1. 更偏重于流程的设计,而非页面体验首先基于业务需求定义好业务流程、核心的功能模块、它们之间的数据交互规则等等,这些都是不可见的需求;其次才是对一些可操作的数据提供管理后台页面,而且管理后台对用户体验的要求不高,只要满足功能需求,操作简单即可。2. 更关注效率提升,而非功能创新后台的需求一般都会有业务方,是公司业务发展的需要,而不完全来源于用户调研。

因此后台产品很重要的特点是把业务需求翻译成最合理的开发需求并落地,如何结合当前公司系统现状,在改动工作量、兼容性、拓展性等方面做出权衡,以最合理的方式来支持业务,提高系统使用效率,减少业务人员工作量,这些才是最主要的。

而对于功能创新,后台产品的玩法相比前端比较少:一个原因是因为很多情况没必要,不是直接迎合用户的功能;另一个是刻意的追求功能创新反而会增大工作量,效果不一定好。3. 提供逻辑和数据支撑的基础能力后台产品的逻辑性和兼容性比较强,前端功能可能随着业务变化随时更新玩法,有时为了试错很多功能直接废弃。但后台对应的系统需要经过调整继续支撑新的玩法,而且由于交叉太多很难直接废弃,这对系统的兼容能力挑战很大。

此外,后台对数据的沉淀也越来越重要,前台丰富的业务产生了不同的数据,后台如何进行挖掘和利用,把散乱的数据转化成对业务有用的资产。这是后台的数据支撑能力,细分点说就是从后台剥离出的数据中台。

三、后台产品经理的作用

在很多人的印象里,后台产品经理就是负责管理后台,这是非常片面的。

后台产品经理需要了解整个产品的架构设计,在业务发展变化过程中持续的为前台提供能力支持,根据业务边界整合不同业务系统、提升运转效率,还要提供数据沉淀和分析等等,挑战是非常大的。

具体可以从三个层面来理解岗位的价值:1. 满足业务需求,提供底层能力支撑首先是满足业务的需求,后台产品的需求方可能来自于运营、销售、客服、合作公司、领导等等,行业属性较强的比如医疗、教育、金融领域,复杂的后台需求更多来自于业务方。

如何真正理解业务想要的是什么,并结合公司当前已有的系统能力,快速的实现对新业务需求的满足,是后台产品经理第一价值。2. 提高企业运转效率,减少重复工作当业务不断发展,业务需求不断的迭代扩充,首先会发现做了很多非常相似的需求,其次会发现后台支撑系统会出现很多问题,比如系统之间数据不一致等各种bug。

这时候产品经理的价值就是梳理这些业务逻辑,把有共性的进行收归,把不合理的进行重构,目的就是提高后台系统的稳定性和效率,进而提高了公司的效率,节省公司的成本开支。3. 对外赋能如果以上两点都做的非常好了,可以把后台的能力进行拆解、包装,对公司其他系统和业务提供支持,甚至对外部公司提供服务,形成to B模式,通过技术方案输出为公司提供新的增长点。

比如目前国内最大的云服务厂商阿里云,就是从最初的1688网站后台雏形演化形成的。

四、后台产品涉及的主要内容

互联网产品是区分行业的,不同领域的产品业务逻辑相差很大,但分析完业务后落实到具体后台系统的设计时是有很多共性的,只要把其中核心的设计要点和思路进行提炼,结合具体行业的业务规则,就能应用到不同后台产品中去。

下面从产品经理的角度简单概述后台产品具体在设计的时候主要都包括了哪些内容,由于内容过多篇幅有限,每一点仅介绍其主要内容。1. 数据类型与数据结构后台系统之间的交互基本都是数据交互,首先我们应该了解基本的数据类型,以及不同数据结构对应在不同需求场景中的使用。以下内容过于基础,基本上大学一年级C语言就学过了,我们简单复习一下。

数据类型可以理解为数据的属性,为了便于计算机的识别和计算,把有相同属性的数据定义为一个集合,形成了一个数据类型。

1)最常见的数据类型整型:即用来表示整数的数据,由于是整数,这类数据可以进行各种数学运算。比如用户的年龄、身高体重等。浮点:用来表示实数的数据,特别是有小数的数据,常用于货币等字段。字符串:用来表示文本型的数据,注意这类数据是不能进行数学运算的,比如用户画像里的一个“爱好”标签就是字符串型,它的值“打篮球”是一段文本。布尔:用来描述事物真假的数据类型,只有两个值,true和false。比如用户画像中,“是否已婚”就是布尔型字段。日期和时间:日期和时间是一种特殊的数据类型,不算整型也不算小数,不能直接用于计算,但也不能只当做文本来展示,很多时候也需要进行换算。具体可分为date(日期)、datetime(日期和时间)、timestamp(时间戳)等。了解了数据的基本类型,还需要了解常见的数据结构。

数据结构是指相互之间存在着一种或多种关系的数据元素的集合和该集合中数据元素之间的关系组成,不同数据结构适用于不同的业务场景。

2)常见的数据结构数组:数组是最基本的数据结构类型,它是一组具有相同类型变量的有序集合。按照元素的类型不同,可以分为整型数组、浮点型数组、字符数组等,一个数组可以分解成多个数组元素,还可以有一维、二维、多维的表现形式,我们日常需求里的很多用户数据都是通过数组来表现和传递的。队列:队列是一种特殊的线性表,简单理解可以说是一个“先进先出”的数据处理机制,只能把先插入的数据处理完再处理后插入的数据。常见的如给用户发触达的需求都是通过队列的方式来实现,只有把先计算出来的用户触达发完才会再发后加入的用户。栈:栈也是一种线性表,与队列的数据处理方式相反,是“后进先出”的数据结构,只能在表的固定端进行数据插入和删除。树状结构:上述三种都是线性结构,而树状结构数据是非线性结构。它是数据元素按照节点和分支关系组成的,可以用来表达有层级的数据集合,比如家庭成员、公司部门架构之间的关系,通过树状数据结构可以快速的查询和修改。除此之外还有链表、图状结构、堆、散列表等数据结构,产品经理可以根据自己业务涉及情况对应深入的了解。2. 接口后台系统之间的数据传递和交互几乎全部依赖接口,也是后台开发打交道最多的。

作为后台产品经理,在跨系统和公司合作时,经常需要看接口文档,也需要把自己的业务能力对外提供接口,虽然不需要自己写,但需要理解接口的基本组成和使用方法。

1)接口的请求方式

最常见的http请求方式有两种:get请求:这类请求方式常用于数据的查询和获取,请求的参数会直接展示在URL上,用“?”连接,多个参数时用“&”连接。由于参数的暴露,有安全风险,不适用安全性要求较高的数据请求方式。post请求:这类请求方式用于向系统提交数据,适用于数据量大和安全性要求较高的场景。2)接口的组成请求地址:即用来传输数据的通道,接口的数据交互是在这个通道下完成的。请求参数(报文):即请求接口时,告诉被请求方的参数,一般包含签名、唯一ID、必填和非必填字段,如果是非实时接口,还会有回调地址。返回结果:被请求方根据请求返回的参数,一般包含返回的状态码和数据,用来表示是否成功,或者返回了什么数据。错误码:当请求方没有按照既定规则进行参数请求,或者被请求方由于系统问题导致请求失败时,会返回相应的错误码,每个错误码代表一种错误的原因。3)接口按照响应机制可分为两种同步接口:发起请求后会等待结果的返回,直到拿到响应才会执行下一步动作。适用于对实时性要求较高的场景,比如登录、支付,必须验证通过后才能成功。异步接口:发起一个请求后不需要等待返回就可以发起下一个请求。请求方会给被请求方一个回调接口,用于异步通知请求结果。适用于实时性不高的批量操作场景,比如提交较大文件、发送优惠券等。3. 状态机设计1)什么是状态机

状态机描述的是系统各个关键状态节点之间的流转路径和条件。对于业务复杂度较高的后台功能,从产品设计层面来说,除了业务流程图之外,状态机是一个直观了解系统工作流程的重要工具,也是跟开发人员高效清晰的表达业务流程的工具。

如果把一个后台产品比作人体,那状态机就是它的骨架,其他功能都是基于这个骨架去丰富的皮肉,骨架搭的好,整个产品才能健康的成长迭代,如果骨架畸形或者有缺陷,表层功能再丰富也掩盖不了整个产品的残疾。

2)状态机图组成

状态机图主要由四部分组成:起始状态、条件、动作、目标状态。

下面举个最简单的下单支付流程的状态机图:

后台产品经理需要知道哪些事

3)画状态机图的注意点

首先:状态的命名要简洁,根据关键的业务节点命名,不能有不稳定的状态名称,比如“发货中”这种不稳定态不适合作为状态命名;

其次:为了方便业务拓展,需要预留一些子状态,以及状态之间的流转逻辑,方便后续迭代时无需太大开发工作量即可支持。4. 数据更新与传输在处理数据相关的后端需求时,数据传输的方式是非常重要的概念,面对不同需求采取的方式也是不一样的,一般分为以下两种:

1)实时触发方式

即操作事件后即触发了数据传递的操作,这跟同步接口的概念很类似,适用于对数据时效性要求高的场景,而且会由于高并发增加系统的负荷。

后台产品经理需要知道哪些事

2)定时任务方式

定时任务是后台非常常见的数据处理方式,就是建立一个计算脚本,按一定频率从数据源按照业务条件查询所需的数据,然后提供给数据需求方。

由于脚本计算的时间较长,一般都是间隔几小时才定时计算一次,因此这种方式适用于实时性要求不高的场景,比如每天查询上一日符合某某条件的用户并导入奖品发放系统。

值得注意的是,定时任务的查询频率必须高于数据源的更新频率,才能防止数据遗漏。比如数据源是每12小时更新一次,则定时任务查询频率必须小于12小时。

后台产品经理需要知道哪些事5. 账号账号是记录用户行为的基本条件,如果用户没有登录就没有账号,就无法识别该用户,也无法进行数据记录和查询。从我个人经验看来,账号设计主要注意以下几点:

1)主账号和子账号对应关系

一般C端产品账号体系比较简单,手机号注册即生成一个账号,但多于较复杂的商家系统,账号体系有多个层级,一个企业下有多个门店,每个门店有多个员工,于是存在多级对应的关系。

2)多平台的账号统一性

除了比较传统的邮箱、手机号注册方式,现在移动互联网时代还比较流行第三方登录。这时容易造成用户的账号混乱,在何种情况下对用户不同登录方式的账号进行关联,来保证用户账号的统一性以及数据安全,是必须要考虑的。

3)账号绑定与更换流程

如果是以手机号作为绑定基础的账号体系,在用户更换手机号之后无法接受验证码的情况,该如何找回密码?如何进行账号的解绑更换?是否有相关的提供用户资料申诉进行人工解绑的流程?

这也是账号设计非常关键的点。6. 权限后台权限设计一般分为以下两种:

1)功能权限设计

每个功能模块甚至每个功能点都可以对每个账号进行权限配置,比如具体对应字段的显示、按钮点击、数据查询导出权限等。

这种方式优点是灵活,可以很方便的对每个账号权限进行调整;缺点是账号太多且分多层级时不方便统一设置和管理,容易遗漏。

2)RBAC权限设计模型

Role-Based Access Control(角色访问控制),简单理解就是基于角色的来进行权限设计,账号、角色与具体功能权限三者按照关联关系进行配置,相同角色的权限是相同的,如果两个人需要权限不一样,那必须先把二者的角色进行区分。7. 管理后台页面设计管理后台的页面只是后台产品的一小部分,但却是很多后台产品经理最常接触的产品形态。

最常见的管理后台是列表式页面,主要用于对业务数据进行查询和处理,这种管理后台页面一般由两个页面、三个部分组成:

后台产品经理需要知道哪些事

1)检索区

主要由不同业务筛选条件组成,满足不同组合的查询。

一般检索功能分为精准搜索和模糊搜索,精准搜索往往是直接匹配ID,或者对表字段的值通过下单框直接选择,而模糊匹配则一般是通过字母、汉字进行匹配。

2)列表区

根据查询结果展示查询到的数据的核心字段,同时需支持翻页、排序、数据导出、批量选中、增删改等快捷操作。

3)单据详情页

单条单据的详情,通常由列表页点击单条数据查看详情进入,会展示该单据的所有信息,并可结合实际的业务功能进行全部的操作。8. 配置开关做后台功能时,很多情况下由于业务的迫切性或时间要求,我们需要快速的变更某个规则,但又不想每次都找开发同学走发布流程,这时就需要配置开关。

它的主要作用是对于某些比较简单的功能可以实现管理后台配置即生效,一般有两种做法:

1)管理后台开关功能

需要做成可操作性界面,还可以结合开关的功能范围、定时生效等需求,做成功能较全的配置开关。

2)配置文件

通过直接修改研发配置文件即可生效,优点是不需要开发管理后台工作量小,缺点是使用不够直观,一般是研发没时间做后台时使用的。9. 跨系统对接当我们负责的后台系统要与公司其他系统或者其他公司功能对接时,通常涉及到以下几种对接方式:

1)API对接

即把系统的能力定义成一个个接口,合作方可以根据自己的需要来调用,是比较灵活的对接方式,适用于业务属性较强的功能点。

2)SDK对接

这种方式是把系统的功能打包成一个合集,合作方无需关心其中的逻辑也不需拆解,而是拿来即用,一般适用于工具性质较强的功能,比如APP监控、人脸识别、智能客服等较完整的功能。

3)页面对接

在跨公司合作时,会经常遇到合作公司并不想把数据进行开放,而只是想嵌入前端页面的方式还是进行对接,这种情况就用到页面对接,这种方式可以在请求页面链接时实现简单的数据传递,但无法获取页面中具体功能的数据。10. 旧数据兼容互联网产品迭代速度快,当进行大版本迭代,升级了新功能新数据规则时,很容易造成旧数据的不可用,这时就必须要做好向后兼容。

通常的做法是按照新的业务规则建立新表,然后把旧表数据按照映射关系批量全部插入新表,接着使用新表,废弃旧表,就完成了数据兼容。

很多时候也不一定非要兼容,如果旧的业务数据在新的规则下几乎不会使用时可以考虑直接丢弃旧数据,具体情况还是要根据业务来取舍。五、后台产品设计要点后台产品作为支撑系统往往涉及到具体的行业和业务特点,当我们直接拿具体业务来阐述后台设计经验时,往往会陷入其中无法进行通用性的提炼,也很难让其他领域的产品经理读者受益。

因此我从产品设计的角度而不是结合业务的角度来总结一些有共性的后台设计要点,这套思路是适合所有后台产品的。1. 对状态的强化认知对于一个后台系统,状态无处不在,灵活多变的业务需求是靠一张张数据库的表在记录的,除了业务数据的记录,状态是非常重要的基础。

订单必须有状态,用于区分不同业务环节;一个上线的活动必须要有状态,是进行中、已暂停、还是已下线;一个员工账号也要有状态,是启用中、禁用中还是已注销。

设计一个功能或系统通常需要先绘制流程图,而流程图中一个个状态的连接支撑起了整个功能设计的骨架,然后才是具体细节的设计。如何正确的强化对状态的认知和理解,我大概总结以下几点:

1)状态的独立互斥

这点与上面说的唯一判断字段有点类似,但实际不是一回事。

因为状态是用于描述不同业务节点的,每个状态要与实际业务的关键节点进行一一对应,状态之间不能出现二义性,否则会出现多个状态对应同一个业务关键节点,不但会造成理解混淆,还可能使系统做具体判断时出问题。

2)状态在时间维度上是稳定的

这点其实也很好理解,一个具体业务的发展是有阶段性的,而状态就是在每个阶段取一个值,各个值连接起来就串联的业务,但如果状态的值取在各个阶段的临界点,这就很不好描述业务了。

比如一个运营活动,可以用“进行中”和“已下线”两个状态来区分发生和不发生两个阶段,这是合理的;但如果状态叫做“下线中”,这就不是处在一个稳定的状态,而像一个瞬时态,到底是上线还是下线,我们从状态命名中就感觉很模糊。

3)注意子状态和组合状态

当业务相当复杂时,一个状态下面还可以设置子状态,比如单据的撤销状态,可以包括用户主动撤销、系统撤销、人工撤销,用于区分具体是怎么被撤销的。

而组合状态的意思是在用户侧展示的状态不单是订单表里存的状态名称,而是一个组合状态,比如在用户侧显示“已发货”,其实包含了订单状态为“创建成功”、支付状态为“已付款”、物流状态为“已出库”。

像比较复杂的保险订单状态,还会包含订单状态、支付状态、续保状态等,因此不能用一维的线性的思维来看待状态。

4)状态机的流转路线

状态机图的确定,基本确定了系统和功能主体结构,各状态之间的起点终点、流转路线、判断条件决定了功能的玩法和限制,状态机图是梳理并对照实际业务的必备工具。

当业务有功能拓展时,首先查看状态机图是否满足、如何调整才能满足、已经涉及到哪些相关调整,都需要用到这个图。

5)合理的状态有利于数据统计

当状态的设计都按照上述原则进行,状态与状态之间非常清晰,这对数据统计是非常有益的。

因为很多的数据统计都强依赖对状态的定义,如果你在做数据统计的时候发现很难准确的提需求,或者发现无法按照业务需要的维度来进行统计,可以反思下系统的状态是否合理。2. 模块化抽象对变量的抽象是一种模块化思维,能够减少很多重复的工作量,提高后期的开发效率,我将分成两种情况来描述。

一种是当多个页面都用到同一个内容时,该内容应该被抽象为公共变量,供各页面调用。

比如一个常用联系人组件包含姓名、证件类型、证件号码、性别、出生日期这五要素,那么可以把这五要素设置成一个公共变量模块,在不同产品下单需要用到时直接调用即可。

如果有的产品下单时只需要用到姓名、证件类型、证件号码三要素,则可以把五要素的变量模块拆细为五个变量元素,这样可以达到最大自由度的组合。

另一种情况是两个页面绝大部分内容相同,只有几个元素有差异时,这几个有差异的元素应该抽象为配置变量,做成一个配置文件或者管理后台,这样在调整该配置时就不用再写代码。

有的同学可能对配置文件不太懂,它可以理解为一段未被编译器编译的配置代码,是对一个软件运行时状态的本地储存形式,可以实现对软件灵活的实时调整。

比如同样一个商品的详情页需要在A平台是红色背景,有评论模块;在B平台是绿色背景,不要评论模块。如果事先将背景色、有无评论模块这两个变量做成配置项,只需要更改配置文件或在管理后台做相应勾选即可。3. 合理的配置化程度有了模块化思维后,在做一些有配置的后台功能时,还有一个非常重要的点是掌握配置的尺度,针对不同产品设定合理的配置功能。

配置化功能有时候会提高系统的灵活度,有时候反而会限制系统的灵活性,这就要看配置化的程度是否与具体业务的需求相结合,对于业务上没有严格定义的内容最好不要做成固定的配置值,而是做成开放的配置项,可以随时更改和扩充。

比如我负责的一个推荐产品的功能,根据用户的个性化信息推荐不同的产品,且不同产品展示的样式和内容不一样,考虑到推荐结果页产品介绍图、特性、推荐语可能会变动,我把这些可能变动的项都做成了管理后台的开放字段,可以让运营随时修改,而产品名称、价格、在售状态这些随着平台统一调整的项则从产品后台去拉取,保证了与平台其他位置展示的一致性。

合理的配置化程度其实就是把该配置的都做成可配置,几乎不会修改的做成固定逻辑,这样既能支持业务,又能减少不必要的配置化开发工作量。4. 系统的拓展性我之前经常遇到一种情况,当我做一个功能上线之后,业务方有时会再提一个与这个非常类似的需求,有时候仅仅只是改动很少的内容。

如果在第一次设计时并没有预留可能的拓展性,就算只是很少的改动,还是要排期开发和测试,特别是有的功能还需回归测试,非常浪费开发资源,而且影响迭代速度。

这时就考验在设计之初能否大概看出可能有的拓展性,在开发工作量几乎不变的情况下预留一些类似的逻辑,这样会非常便于类似功能的迭代。

举个例子:对于一个人工审核的结论页,有多种状态,每种状态下结论页的不同模块的元素、文案、以及对用户的触达文案,都是首次开发时配置好的。

首次开发时业务方提出有三种状态,上线之后业务方说要再加一种特殊的状态;如果事先在状态机中预留了待定的状态,只需要把该待定状态下页面的元素、文案、对用户的触达进行设置即可,改动的工作量很小,可以快速的上线。

不过值得注意的一点是,在预留拓展性时尽量保证首次开发的工作量影响很小,如果为了暂时使用不到的预留需求消耗过多开发资源,就有点本末倒置了。

最好的针对复制一份代码、预留一个状态这种相似功能进行考虑。5. 异常处理机制稳定性是一个后台系统非常重要的职责,代码上的异常报警有开发人员来跟进,但后台功能上的异常处理机制是需要产品经理在设计时就考虑的。

比如产品上架时需要灰度验证,那么需要一个白名单功能,如果细分到具体功能的上架,那这个白名单功能还要细化到具体功能入口。

还比如某个功能接口挂了之后的兜底逻辑,如果是一个定时取数的接口,是否可以在接口挂了无法更新数据时仍然展示上次拉到的数据,并给前端一个字段反馈,让前端可以展示一个文案提示用户。

异常处理机制就像一个个应急的创可贴,在系统出问题时能够第一时间应急处理,让系统不至于大出血而影响使用,是非常必要的临时解决问题机制。六、分析复杂业务的5个思考维度很多时候我们在面对一个复杂的业务需求时,容易被业务的表象所迷惑,看起来非常复杂,这不只是后台产品,所有产品需求都会遇到。

但如果有良好的结构化思维和本质思维,就可以剥开业务外表,把问题归纳为数学和物理上的关系,再复杂的业务往往也可以快速的理清头绪。

当然,理解业务是前提,理解业务后可以再从以下几个维度来思考其中的逻辑关系:1. 对应关系任何业务需求一定会涉及到几个业务主体,它们之间要么毫不相干,要么就存在一定联系,当有联系时就涉及到它们的对应关系,理清这层关系后才能进行具体的方案设计。

在数学上,两个数据的基本对应关系只有三种:一对一、一对多、多对多。看似很常见的对应关系,却在后台产品的设计中无处不在。

举个最简单的例子:比如账号的注册,一个账号注册后生成一个uid,用户可以绑定手机号、微信号,也可以输入身份证号进行实名认证,手机号和微信号还支持更换,这时uid与手机号就是一对多的关系,uid与身份证号是一对一关系。

搞清数据之间的对应关系非常有必要,它直接关系到开发人员对数据库表字段的设计,以及后续要进行的相关数据传输和统计查询。其实对应关系也是UML图里类图部分的内容,是理清业务逻辑过程中必备的。2. 主从关系主体之间的关联关系除了对应关系,还会存在主从关系。

比如在静态条件时,两个主体之间的包含和被包含关系,以哪个主体为准,哪个主体次之;在动态变化时,哪个主体的变化会影响其他主体,哪个主体是被动受到制约。

我将这类关系统称为主从关系,对多个主体主从关系的正确判断,可以帮助我们更客观的认识事物,判断需求的优先级,做出更好的选择。

比如在产品经理日常工作经常会遇到一个情况,就是反复实现几个类似的需求,明明好像上次做过类似的,这次只是改动了一点点又要重新做。

这种情况常常是由于没有抓住需求的根源,只是在从属系统(模块)中解决问题,没有在这个需求对应的源头主系统中解决,也或者说是需求实现的方案不是一个根源上的主方案,而是一个浅层的从属方案。3. 关联程度当多个主体之间都有互相影响的关联关系时,我们需要把这个关联的程度进行量化和大小对比。比如A和B两个主体之间影响的因子很少,那便是弱关联程度,A和C之间有多个变量相互作用,那相对来说属于强关联关系。

在分析业务时,我们可以把所有的相关主体通过粗细不同的线条来描述它们之间的关联程度大小,理解不用主体之间的关联程度可以帮助我们做出更好的选择。

比如在实际处理业务需求时,同样一个需求一般有多种实现方案,如果每个方案看做一个主体,现有的相关系统模块也看做一个个主体,在进行选择时需要基于该需求与当前系统哪个模块关联程度最高,根据高内聚低耦合的设计原则,应该把需求放在相关性最高的模块中实现。4. 时间维度在物理世界中,我们常用三维空间和时间用来描述事物,即时间和空间上都有顺序。而互联网的世界主要就是数据按照一定规则进行的交换与传递,不受三维空间的限制,因此可以认为只有时间维度的顺序。

对应到产品设计的细节来看,不管什么复杂的业务,其中的具体事件一定有时间发生顺序,它们发生的先后之间是否有对应不同的限制条件,是否为了实现的方便可以不按照业务事件的发生顺序?在哪个时间点进行哪个事件更为合理?

这些细节最终都会落到具体的对应到代码的处理,也会一定程度影响到整个系统的实现方案和效果。

比如在互联网保险投保的流程中,系统需要对用户大量的信息进行校验,来判断用户是否符合投保要求,即通常说的核保。

用户的一些直接输入的信息通过前端实时校验进行拦截,复杂的信息通过整个页面提交后接口来进行校验,该用户更深层的一些诸如征信风险、信用风险等信息再通过风控接口进行拦截。

这就把数据校验这个功能,从数据的传输时间维度上拆解成了三步。这其实也就是研发的时序图思路,只不过产品经理在业务梳理阶段就要理清关键业务的时序。5. 因果关系凡事有因必有果,不是不报,是时候未到。因果关系看起来非常简单,但现实中我们却常常陷入两个误区。误区一:把事件的结果归纳为单一原因造成的;误区二:把一个事件的结果当原因。这两个误区会使我们无法找到问题的根本原因,也就无法从根本上解决问题。

举个例子:在上周A产品的销量提升了,产品详情页的页面转化率提高了,而上周产品经理刚好给页面加了指示引导功能。

如果我们就认为产品经理上周做的功能是销量上升的原因,那就陷入了第一个误区,因为可能还存在其他很多的变量,比如可能是产品上周减价了。

如果认为产品详情页转化率提高是销量上升的原因,那就陷入了第二个误区,因为页面转化率提高也是一个产品卖得更好的表现结果,而不是原因。

也许我们全面盘查销量提升的变量后会发现,根本原因其实是该产品可以使用刚发的优惠券进行大额折扣。要避免陷入误区一,需要更全面地看待影响事件的变量,不能停留在线性的因果视角;要避免陷入误区二,需要区分什么是结果什么是原因,一般只有变量事件才可能是原因,而数据、效果方面呈现的内容都是结果。以上5个思考维度,前三个是静态分析视角,后两个是动态分析视角,并不是什么新的高大上的理论,但却是我总结出来并真正在实践中受益的。

后台产品的建设本身就更偏向严谨的工程思维,抽去业务的外衣,从产品层面进行高度归纳的东西才能让我们举一反三。七、后台与中台的关系后台是一个广泛的范围,是一个与前台对应的概念,对于大多数公司,后台其实就是所有的业务支撑系统,比较小的公司是没有产品经理专门来负责后台产品。

但随着大公司大平台的出现,并行的业务线发展得越来越大,每条业务线都要一个后台,各个后台之间又相对独立,形成了烟囱式的技术架构。

这样很难以实现多业务数据的整合和共享,也很难快速对类似的新业务进行支撑响应,于是才诞生了中台。

国内最早实践的应该是阿里巴巴,简单点说,中台是后台的精细化设计衍生出的概念,是为了更高效率的提升对前端业务支撑的系统,偏重与对技术、数据、业务的共性抽象和复用。

因此,我认为后台与中台是相辅相成的,在不同公司背景下的重合情况并不相同,我们不用刻意为了概念上的区分而分离后台与中台的具体内容。

特别是在行业内真正在做需求的产品经理,要做好中台需要先做好后台的事情,掌握后台设计的原理、方法,在公司发展壮大后需要进行中台建设时才能把后台相关能力抽象成为中台。八、后台产品的未来最后来聊聊后台产品的未来。

互联网蓬勃发展的初期,产品经理是供不应求的,非常多来自各个专业的毕业生只要多体验APP、写点竞品分析报告、画画交互,就能进入行业获得一份不错的工作。

然而时间已经来到2020年,做纯互联网的产品早就不再是主流,互联网已经与各行各业相结合并产生了不同的化学反应,再加上经济下行的背景,企业对效率提升的重视,资本也不再盲目砸钱投新项目。

产品经理的招聘越来越细分了,各个领域公司需要的是既懂业务又懂互联网的产品经理,而这些与各领域业务有着高度结合的需求正是后台、B端产品的主要工作,这些都需要很多软件设计底层的基本功。

一个不懂UML、不懂数据库、不懂算法、不懂软件开发流程,只会分析用户、交互设计、线上活动策划的C端产品经理的竞争壁垒会越来越低,也很难在有行业深度的领域担当大任。

作为业内人士,特别是从事后台产品经理的人来说,一定能看到企业内部非常多环节都是不合理不够高效的,公司对外的PR稿写的都是高大上的人工智能,真正到做需求时我们这帮人会发现更多的是人工智障。

现在还是互联网与各行业的融合期,各领域的公司也有非常大的改善空间,未来的企业内部组织效率提升一定会发挥更大的价值,这也是后台产品经理价值的所在。

后台产品经理,任重道远,但未来可期。

 

给作者打赏,鼓励TA抓紧创作!赞赏

广告位
    广告位
    广告位

站点信息

  • 文章统计14931篇文章
  • 寻求报道:86345@qq.com
  • 微信:扫描二维码,关注我们