产品经理设计后台产品的核心思路
编辑导语:在实际工作中,产品经理会时常听到到前台产品、中台产品和后台产品,这三者有何区别?本文作者对前中后台产品作了一个简单的区分,并以后台产品经理为例,分享如何进行后台产品设计的核心思路。
一、前言
在实际工作中,我们经常听到前台产品、中台产品和后台产品。
前台产品就是直接和用户产生联系的产品,很多时候大家会认为用户经常接触到的产品页面和交互就是前台产品,其实并不完全正确。产品交互和页面属于“前端产品”,但“前端产品”仅是前台产品的一部分。前台产品除了包含“前端产品”外,还包含各种对用户请求与响应进行处理的各种业务逻辑。
中台产品是近些年兴起的产品概念。中台产品的核心价值是“承上启下”,从而提升效率,节约成本。
以电商产品为例,假如我们要做一个推荐系统,需要从用户系统、订单系统、搜索系统、浏览日志、商品系统等多个系统甚至是跨平台去获取这些数据,就需要完成同这些系统的对接,如果后续这些系统有变动,也要同步进行维护。工作量很大,数据流与信息流也很难统一。如果直接从数据中台获得信息,就便捷了许多。
后台产品,简而言之就是不直接面向用户,主要由企业内部人员使用的产品。
例如运营人员使用的配置管理,财务人员使用的结算管理、营销人员使用的销售管理。后台产品承载着企业最为核心的业务功能。
如果中台产品是企业的战地指挥部的话,那么后台产品就是企业的司令部。在这里掌握着企业几乎全部的资金、信息、数据资源。运筹帷幄,决胜千里。
不同企业虽然业务属性不同,后台产品也会有一定的区别,但是不论业务逻辑怎么变,后台产品总会有一些非常核心的东西,体现着产品的内涵,正所谓万变不离其宗。
本文今天主要通过日常工作中产品经理在设计后台产品时常面临的些困惑进行讨论分析,结合自己的工作经验以及成功案例,提炼出,从而打造一个可伸缩的后台产品,使后台产品可以应对不断变化的业务需求,增强产品的竞争力。
二、后台产品经理的困惑
实际工作中,后台产品经理往往会存在几个困惑。
1. 功能冗余
一些产品经理觉得后台产品往往公司是不太重视,产品经理觉得负责后台产品在工作上很难出彩,因此在进行后台产品设计时,往往投入也不够,仅是产品能满足基本的业务功能即可,交互逻辑也非常简单,没有长远的规划,业务需要一个功能就实现一个功能,造成后台产品功能重复开发,使用起来非常冗余。
2. 理念陈旧
不同的公司,后台产品的功能也有很大的差别。有的公司主营业务单一,发展稳定,后台产品功能也相应比较简单,而且多年不发生变化。
这种情况下,后台产品仅是满足基本的业务需要而已,有的公司主营业务多样,发展迅速,不断扩张,后台产品迭代就非常迅速。
产品经理在设计后台产品时,还停留在传统的后台产品阶段,认为后台产品就是一个后端的管理系统,这样就导致了后台产品跟不上公司发展的需求,不断反复,从而影响了公司业务开展,影响效率与收益。
3. 扩展性差
产品经理在设计后台产品时,往往是只着眼于眼前的功能需求,导致后期产品功能扩展受到非常大的制约。
后台产品功能往往也要服务于前台或是中台产品,扩展性差,导致后台产品功能不能承载前台产品的功能需要,产品功能相互制约,导致后台产品的升级改造成本非常高,继续在原产品架构上优化,维护成本很高,舍弃掉原有后台,重建又觉得可惜,进退两难。而即便是重建,产品经理未来可能还是面临扩展性差的问题,得不偿失。
三、后台产品设计的核心思路
面对后台产品经理在负责后台产品设计时存在困惑,我们该去如何解决?
会不会有一种通用的方法,可以应对后台产品设计中存在的普遍问题?
这些年我们在日常实际工作中,也接触过非常多的后台产品设计,结合实际产品经验,我们提炼出产品经理在设计后台产品时的核心思路。
1. 明确后台产品业务范围
我们在设计后台产品时,需要问自己一个灵魂深处的问题:你做的后台产品,价值体现在哪里?
一般来说,我们做任何产品都要考虑ROI(Return on Investment,投资回报率)。有些产品的ROI是显性的,比较容易量化,比如你的产品直接给你带来多少收入;而有些产品的ROI是隐性的,比如我们做一个公益产品,这个产品的价值到底是多少,可能要几年后才能真正体现。
产品价值取决于后台产品业务范围。如果产品的业务范围仅仅是做一个简单的用户密码修改,那么根本就没必要去实现一个后台产品。而公司业务的不同,后台产品实现的业务功能也不同。
很明显,如果你是电商产品的后台,ERP产品的后台或是内容产品的后台,业务流程是不一样的。我们只有明确了后台产品未来要实现的业务范围,才可以在后台产品的可伸缩设计做到心中有数,胸有成竹。
2. 构建后台产品核心功能
后台产品承载的业务千变万化,但是在核心功能上不同的后台产品总会出奇的相似。结合这些年工作中接触到的各种后台产品,我们提炼出构建后台产品需要的几大核心功能。
总体而言我们在构建后台产品时,首先要构建以下核心功能,如下图所示。
员工管理:主要用于对使用后台产品或是同后台产品有业务关系的企业员工进行管理。因为使用后台产品的员工会来自于不同的业务部门。员工的权限,角色也会不同,并且还会有员工的变动,例如员工的入职、离职或是其他信息变化。
组织管理:后台产品往往会涉及企业内部或是外部的多个组织,不同组织在使用后台产品的功能上也会有所不同。在组织管理这个核心功能中,主要涉及组织的新增和维护,组织名称定义,组织范围等。
组织和员工之间为一对多的关系,即一个组织下可以有多名员工,极特别情况,有多对多,比如一个员工是公司的分管副总,会存在于总经办这个组织,也会存在于他所分管的部门,比如他分管的财务部,财务部这个组织中也会有这个员工。
用户管理:这个一般指的是使用企业前台产品所提供服务的用户。最常见的功能就是对用户信息管理,账号禁用与启用。用户属性维护。用户是属于个人用户,还是机构用户。对于SaaS后台产品,用户管理里面还包含用户银行账号、电话、联系方式。
同样,对于购物类App产品,金融类App产品或是内容类App产品,对用户的身份真实性也有一定要求,也会有包含有许多用户敏感信息。这种情况下,需要对用户相关信息查看、编辑进行权限管理和日志记录。
角色管理:角色管理是在后台产品中非常常见的一个核心模块。简单的后台产品,角色管理仅需要定义角色名称,并将角色赋予给用户。而复杂的用户管理,不仅仅是管理后台产品用户权限,还会对前台产品的用户角色进行定义,进一步对不同用户使用产品功能的范围进行划分。
角色管理是连接用户和权限的纽带。为用户直接赋权做法虽然可行,但后期维护成本太高。通过角色管理,定义使用后台产品或是前台产品的用户角色,可以简化用户使用产品的功能控制,便于扩展。
权限管理:权限管理是一套对于用户可使用产品功能范围的一个规则集,定义了产品的哪些功能哪些用户可以使用,而哪些功能哪些用户不能使用。
权限管理,除了权限要定义或管理权限名称这样的基础功能外,更多的是需要定义产品可执行范围的规则集。
对于复杂的后台产品,权限管理还在定义相关的激活参数,即用户在同样角色范围内,在某个时点,或是在某种特定场景下可使用的产品功能范围不同。
资源管理:这个核心功能主要是对整个前台产品或是后台产品的所用到的资源进行控制。这些资源涉及企业内部的,也涉及企业外部。正如我们工作中经常使用的财务管理后台产品,对于企业内部的资源,涉及公司的各种企业银行账户、结算时间、结算方式,同时也会定义同公司有业务往来的外部资源,包括对方的结算时间、结算方式、交互信息等。
日志管理:日志管理功能很多时候大家都不认为是后台产品的核心功能,最初往往不受重视。主要是觉得日志管理不产生直接的经济效益。也有很多人觉得,日志管理就是一个记录操作日志的东东,会记录到程序的日志中,后台产品不需要日志。
实际工作中我们也遇到太多,由于在后台产品中没有规划日志管理,而导致的操作信息无法追溯而导致的操作风险。合规是一方面。
更多的是,体验非常良好的日志管理功能,后台人员可以很方便地定位用户操作过程中的问题,提高产品反馈效率,增加用户产品体验。通过技术人员后台查看日志的方式,虽然可行,但是往往比较耗费时间,沟通成本高,沟通效率低下。
配置管理:配置管理主要会对所有后台产品以及前台产品涉及的相关参数进行配置。常见的,诸如用户登录的Token有效期,密码长度限制,发送相关邮件的数据参数,发送短信的相关参数,前台产品同后台产品信息交互的密钥配置。后台产品与第三方产品进行交互的相关接口信息,连接方式,IP配置等。
3. 后台产品模块化设计方式
完成构建后台产品的核心功能后,我们就开始规划后台产品的其他功能。我们知道,不同领域的产品,业务千差万别,这就需要我们有后台产品模块化的设计思路。
简而言之,就是类似于搭乐高积木一样,搭建后台产品模块,做到业务需求快速响应,产品功能灵活可伸缩。因此我们在设计后台产品时,在设计思路上就要将后台产品看作是一个花瓶一样,不同的产品功能就是不同的花,需要的功能插入花瓶,而不需要的产品功能,从花瓶中拿出即可。
如上图所示,模块可以有多个。各种模块根据实际业务的不同进行针对性地定义。以实际工作为例,如果业务是属于电商类,这些模块可以是:订单管理、物流管理、库存管理、商品管理等。
如果业务是属于金融类,这些模块可以是:资产管理、支付管理、清分与结算管理等。并可以随着业务扩展进行定制化新增,从而满足增长需要。
四、总结
很多时候产品经理在负责后台产品时,会觉得负责后台产品不容易做出业绩而导致动力不足,对后台产品的各种功能得过且过能用就可以,还有一些产品经理是由于对业务认识不足,导致不知道后台产品设计从哪里入手。
同时,在一些公司,往往也只有前台产品经理,后台的产品实现,往往由开发人员自己搭建。总体看下来,要么是公司领导对后台产品不重视,要么是产品经理自己觉得后台产品不重要,要么是不知道后台产品如何设计。
结合实际工作,后台产品其实是在公司中非常关键的产品。因为后台产品承载着公司最核心的业务。前台产品仅是公司业务的呈现而已。
大家都知道,往往前台产品风格变化比较快,而后台产品的核心功能却能一直保持。例如公司要做一个金融类的App,可以短时间包装多多个金融App产品,但是真正是后台产品承载着账户、对账、清结算这些最核心的功能。
同时也建议,如果是新入职的产品经理,在熟悉公司业务阶段,最好先负责一阶段的后台产品,这样可以短时间快速了解公司的业务流程。在熟悉了核心流程之后,再深入市场,从而实现后续的创新。
#专栏作家#
王佳亮,微信公众号:佳佳原创,人人都是产品经理专栏作家。中国计算机学会(CCF)会员,专注于互联网产品设计理念分享。
本文原创发布于人人都是产品经理,未经许可,禁止转载。
题图来自Unsplash,基于CC0协议。
用户管理和员工管理是不是冗余了?
估计不是成都的产品经理,妈的,老子做了这么多年,没这么区分,都是一起上的,难道一个人干了几个人的活?
从技术层面了解目前平台构建架构现状,多找后端开发聊目前痛点、优化思路,找用户聊使用场景、期望的能力,然后结合目前的资源投入,给出整合的方案
你所指的用户是?
请问后台重构,怎么进行后台模块聚合提炼,目前思路稍微混乱
请问有思路了吗
请问有思路了吗
比较粗暴的话,就看后台对应业务大类分,颗粒度再细一点,根据流程分或者数据分