不同发展阶段、不同行业方向的互联网公司都需要后台产品经理，因为后台是支撑业务发展的必备基础，有了后台的基础支持才会有前台的用户增长产品、商业化产品、策略产品、数据产品等细分方向的繁荣。但是由于后台产品的不可见性、以及跟公司具体业务强相关，不像前台的功能那样有很多参考的竞品，因此刚入行的后台产品经理往往缺乏学习模板，需要靠自己不断的提炼总结。
回顾我的学习路径，发现网上找的后台方法论文章要么写的过于表象，看的很热闹但干货很少，要么没有剥离业务领域进行抽象，让其他领域的人很难学习应用。
希望我写的能摆脱这两种文章的困境，给入门的小白一点真正的帮助。
本文主要内容：
- 什么是后台产品
- 后台产品的特点
- 后台产品经理的作用
- 后台产品涉及的主要内容
- 后台产品设计要点
- 分析复杂业务的几个思考维度
- 后台与中台的关系
本篇为本文上篇，包含前4节内容
01 什么是后台产品
由于业界没有严格的定义，不同行业不同类型的公司都在招聘后台产品经理，所以后台的范围是相对模糊的，每个人的理解可能也不一样，很多人还把B端和后台划等号。我认为B端和后端有交集但也有很大的不同，而后端和后台差不多，是一个比较泛的概念，偏指对产品前端进行业务支撑类的产品，范围包括且不限于以下几类：
1、C端产品的后台
比如社交内容C端产品的CMS（内容管理系统），电商产品的商品系统、订单系统、支付系统，较通用的会员系统、数据统计系统等等，这些后台会直接给前台提供支持。
2、业务处理系统
企业内部的业务处理系统一般不是直接支持C端，而是解决企业内部的业务需求，提高企业运转效率，比如OA系统、财务系统、CRM系统、ERP系统等。
3、平台级产品
当一个C端产品做大以后，可能会出现第三方，这时的后台不仅需要支持原有的C端，还需要给第三方提供能力，比如开放平台；或者一个既要面对C端用户，又要整合产品/内容提供方的平台，比如蚂蚁保险的后台，既要承接不同保险公司的保险产品，又要支撑前端提供给用户的服务。
一个大型的互联网产品，它的后台往往是以上几种类型的组合，比如微信公众平台，它是C端公众号的后台管理系统，也是一个CMS系统，还是一个开放平台。
02 后台产品的特点
既然随着产品的细化区分出了前端和后台产品，那各自就承担了不同的职责。前端产品直接面对用户，侧重于对用户需求、用户心理的把握，通过好的用户体验来获得用户提升收入，而后台产品的特点体现在以下几个方面：
1、更偏重于流程的设计，而非页面体验
首先基于业务需求定义好业务流程、核心的功能模块、它们之间的数据交互规则等等，这些都是不可见的需求，其次才是对一些可操作的数据提供管理后台页面，而且管理后台对用户体验的要求不高，只要满足功能需求，操作简单即可。
2、更关注效率提升，而非功能创新
后台的需求一般都会有业务方，是公司业务发展的需要，而不完全来源于用户调研。因此后台产品很重要的特点是把业务需求翻译成最合理的开发需求并落地，如何结合当前公司系统现状，在改动工作量、兼容性、拓展性等方面做出权衡，以最合理的方式来支持业务，提高系统使用效率，减少业务人员工作量，这些才是最主要的。
而对于功能创新，后台产品的玩法相比前端比较少，一个原因是因为很多情况没必要，不是直接迎合用户的功能，另一个是刻意的追求功能创新反而会增大工作量，效果不一定好。
3、提供逻辑和数据支撑的基础能力
后台产品的逻辑性和兼容性比较强，前端功能可能随着业务变化随时更新玩法，有时为了试错很多功能直接废弃，但后台对应的系统需要经过调整继续支撑新的玩法，而且由于交叉太多很难直接废弃，这对系统的兼容能力挑战很大。
此外，后台对数据的沉淀也越来越重要，前台丰富的业务产生了不同的数据，后台如何进行挖掘和利用，把散乱的数据转化成对业务有用的资产，这是后台的数据支撑能力，细分点说就是从后台剥离出的数据中台。
03 后台产品经理的作用
在很多人的印象里，后台产品经理就是负责管理后台，这是非常片面的，后台产品经理需要了解整个产品的架构设计，在业务发展变化过程中持续的为前台提供能力支持，根据业务边界整合不同业务系统、提升运转效率，还要提供数据沉淀和分析等等，挑战是非常大的。具体可以从三个层面来理解岗位的价值：
1、满足业务需求，提供底层能力支撑
首先是满足业务的需求，后台产品的需求方可能来自于运营、销售、客服、合作公司、领导等等，行业属性较强的比如医疗、教育、金融领域，复杂的后台需求更多来自于业务方。
如何真正理解业务想要的是什么，并结合公司当前已有的系统能力，快速的实现对新业务需求的满足，是后台产品经理第一价值。
2、提高企业运转效率，减少重复工作
当业务不断发展，业务需求不断的迭代扩充，首先会发现做了很多非常相似的需求，其次会发现后台支撑系统会出现很多问题，比如系统之间数据不一致等各种bug，这时候产品经理的价值就是梳理这些业务逻辑，把有共性的进行收归，把不合理的进行重构，目的就是提高后台系统的稳定性和效率，进而提高了公司的效率，节省公司的成本开支。
3、对外赋能
如果以上两点都做的非常好了，可以把后台的能力进行拆解、包装，对公司其他系统和业务提供支持，甚至对外部公司提供服务，形成to B模式，通过技术方案输出为公司提供新的增长点，比如目前国内最大的云服务厂商阿里云，就是从最初的1688网站后台雏形演化形成的。
04 后台产品涉及的主要内容
互联网产品是区分行业的，不同领域的产品业务逻辑相差很大，但分析完业务后落实到具体后台系统的设计时是有很多共性的，只要把其中核心的设计要点和思路进行提炼，结合具体行业的业务规则，就能应用到不同后台产品中去。
下面从产品经理的角度简单概述后台产品具体在设计的时候主要都包括了哪些内容，由于内容过多篇幅有限，每一点仅介绍其主要内容。
一、数据类型与数据结构
后台系统之间的交互基本都是数据交互，首先我们应该了解基本的数据类型，以及不同数据结构对应在不同需求场景中的使用。以下内容过于基础，基本上大学一年级C语言就学过了，我们简单复习一下。
数据类型可以理解为数据的属性，为了便于计算机的识别和计算，把有相同属性的数据定义为一个集合，形成了一个数据类型。
1、最常见的数据类型
1）整型
即用来表示整数的数据，由于是整数，这类数据可以进行各种数学运算。比如用户的年龄、身高体重等。
2）浮点
用来表示实数的数据，特别是有小数的数据，常用于货币等字段。
3）字符串
用来表示文本型的数据，注意这类数据是不能进行数学运算的，比如用户画像里的一个“爱好”标签就是字符串型，它的值“打篮球”是一段文本。
4）布尔
用来描述事物真假的数据类型，只有两个值，true和false。比如用户画像中，“是否已婚”就是布尔型字段。
5）日期和时间
日期和时间是一种特殊的数据类型，不算整型也不算小数，不能直接用于计算，但也不能只当做文本来展示，很多时候也需要进行换算。具体可分为date（日期）、datetime（日期和时间）、timestamp（时间戳）等。
了解了数据的基本类型，还需要了解常见的数据结构。
数据结构是指相互之间存在着一种或多种关系的数据元素的集合和该集合中数据元素之间的关系组成，不同数据结构适用于不同的业务场景。
2、常见的数据结构
1）数组
数组是最基本的数据结构类型，它是一组具有相同类型变量的有序集合。按照元素的类型不同，可以分为整型数组、浮点型数组、字符数组等。一个数组可以分解成多个数组元素，还可以有一维、二维、多维的表现形式。我们日常需求里的很多用户数据都是通过数组来表现和传递的。
2）队列
队列是一种特殊的线性表，简单理解可以说是一个“先进先出”的数据处理机制，只能把先插入的数据处理完再处理后插入的数据。
常见的如给用户发触达的需求都是通过队列的方式来实现，只有把先计算出来的用户触达发完才会再发后加入的用户。
3）栈
栈也是一种线性表，与队列的数据处理方式相反，是“后进先出”的数据结构，只能在表的固定端进行数据插入和删除。
4）树状结构
上述三种都是线性结构，而树状结构数据是非线性结构。它是数据元素按照节点和分支关系组成的，可以用来表达有层级的数据集合，比如家庭成员、公司部门架构之间的关系，通过树状数据结构可以快速的查询和修改。
除此之外还有链表、图状结构、堆、散列表等数据结构，产品经理可以根据自己业务涉及情况对应深入的了解。
二、接口
后台系统之间的数据传递和交互几乎全部依赖接口，也是后台开发打交道最多的。作为后台产品经理，在跨系统和公司合作时，经常需要看接口文档，也需要把自己的业务能力对外提供接口，虽然不需要自己写，但需要理解接口的基本组成和使用方法。
1、接口的请求方式
最常见的http请求方式有两种
1）get请求
这类请求方式常用于数据的查询和获取，请求的参数会直接展示在URL上，用“？”连接，多个参数时用“&”连接。由于参数的暴露，有安全风险，不适用安全性要求较高的数据请求方式。
2）post请求
这类请求方式用于向系统提交数据，适用于数据量大和安全性要求较高的场景。
2、接口的组成
1）请求地址
即用来传输数据的通道，接口的数据交互是在这个通道下完成的。
2）请求参数（报文）
即请求接口时，告诉被请求方的参数，一般包含签名、唯一ID、必填和非必填字段，如果是非实时接口，还会有回调地址。
3）返回结果
被请求方根据请求返回的参数，一般包含返回的状态码和数据，用来表示是否成功，或者返回了什么数据。
4）错误码
当请求方没有按照既定规则进行参数请求，或者被请求方由于系统问题导致请求失败时，会返回相应的错误码，每个错误码代表一种错误的原因。
3、接口按照响应机制可分为两种
1）同步接口
发起请求后会等待结果的返回，直到拿到响应才会执行下一步动作。适用于对实时性要求较高的场景，比如登录、支付，必须验证通过后才能成功。
2）异步接口
发起一个请求后不需要等待返回就可以发起下一个请求。请求方会给被请求方一个回调接口，用于异步通知请求结果。适用于实时性不高的批量操作场景，比如提交较大文件、发送优惠券等。
三、状态机设计
1）什么是状态机
状态机描述的是系统各个关键状态节点之间的流转路径和条件。对于业务复杂度较高的后台功能，从产品设计层面来说，除了业务流程图之外，状态机是一个直观了解系统工作流程的重要工具，也是跟开发人员高效清晰的表达业务流程的工具。
如果把一个后台产品比作人体，那状态机就是它的骨架，其他功能都是基于这个骨架去丰富的皮肉，骨架搭的好，整个产品才能健康的成长迭代，如果骨架畸形或者有缺陷，表层功能再丰富也掩盖不了整个产品的残疾。
2）状态机图组成
状态机图主要由四部分组成：起始状态、条件、动作、目标状态。
下面举个最简单的下单支付流程的状态机图。
3）画状态机图的注意点
首先，状态的命名要简洁，根据关键的业务节点命名，不能有不稳定的状态名称，比如“发货中”这种不稳定态不适合作为状态命名；
其次，为了方便业务拓展，需要预留一些子状态，以及状态之间的流转逻辑，方便后续迭代时无需太大开发工作量即可支持。
四、数据更新与传输
在处理数据相关的后端需求时，数据传输的方式是非常重要的概念，面对不同需求采取的方式也是不一样的，一般分为以下两种：
1）实时触发方式
即操作事件后即触发了数据传递的操作，这跟同步接口的概念很类似，适用于对数据时效性要求高的场景，而且会由于高并发增加系统的负荷。
2）定时任务方式
定时任务是后台非常常见的数据处理方式，就是建立一个计算脚本，按一定频率从数据源按照业务条件查询所需的数据，然后提供给数据需求方。由于脚本计算的时间较长，一般都是间隔几小时才定时计算一次，因此这种方式适用于实时性要求不高的场景，比如每天查询上一日符合某某条件的用户并导入奖品发放系统。
值得注意的是，定时任务的查询频率必须高于数据源的更新频率，才能防止数据遗漏。比如数据源是每12小时更新一次，则定时任务查询频率必须小于12小时。
五、账号
账号是记录用户行为的基本条件，如果用户没有登录就没有账号，就无法识别该用户，也无法进行数据记录和查询。从我个人经验看来，账号设计主要注意以下几点：
1）主账号和子账号对应关系
一般C端产品账号体系比较简单，手机号注册即生成一个账号，但多于较复杂的商家系统，账号体系有多个层级，一个企业下有多个门店，每个门店有多个员工，于是存在多级对应的关系。
2）多平台的账号统一性
除了比较传统的邮箱、手机号注册方式，现在移动互联网时代还比较流行第三方登录，这时容易造成用户的账号混乱，在何种情况下对用户不同登录方式的账号进行关联，来保证用户账号的统一性以及数据安全，是必须要考虑的。
3）账号绑定与更换流程
如果是以手机号作为绑定基础的账号体系，在用户更换手机号之后无法接受验证码的情况，该如何找回密码，如何进行账号的解绑更换，是否有相关的提供用户资料申诉进行人工解绑的流程，这也是账号设计非常关键的点。
六、权限
后台权限设计一般分为以下两种：
1）功能权限设计
每个功能模块甚至每个功能点都可以对每个账号进行权限配置，比如具体对应字段的显示、按钮点击、数据查询导出权限等，这种方式优点是灵活，可以很方便的对每个账号权限进行调整，缺点是账号太多且分多层级时不方便统一设置和管理，容易遗漏。
2）RBAC权限设计模型
Role-Based Access Control（角色访问控制），简单理解就是基于角色的来进行权限设计，账号、角色与具体功能权限三者按照关联关系进行配置，相同角色的权限是相同的，如果两个人需要权限不一样，那必须先把二者的角色进行区分。
七、管理后台页面设计
管理后台的页面只是后台产品的一小部分，但却是很多后台产品经理最常接触的产品形态。最常见的管理后台是列表式页面，主要用于对业务数据进行查询和处理，这种管理后台页面一般由两个页面、三个部分组成：
1）检索区
主要由不同业务筛选条件组成，满足不同组合的查询。
一般检索功能分为精准搜索和模糊搜索，精准搜索往往是直接匹配ID，或者对表字段的值通过下单框直接选择，而模糊匹配则一般是通过字母、汉字进行匹配。
2）列表区
根据查询结果展示查询到的数据的核心字段，同时需支持翻页、排序、数据导出、批量选中、增删改等快捷操作。
3）单据详情页
单条单据的详情，通常由列表页点击单条数据查看详情进入，会展示该单据的所有信息，并可结合实际的业务功能进行全部的操作。
八、配置开关
做后台功能时，很多情况下由于业务的迫切性或时间要求，我们需要快速的变更某个规则，但又不想每次都找开发同学走发布流程，这时就需要配置开关，它的主要作用是对于某些比较简单的功能可以实现管理后台配置即生效。
一般有两种做法：
1）管理后台开关功能
需要做成可操作性界面，还可以结合开关的功能范围、定时生效等需求，做成功能较全的配置开关。
2）配置文件
通过直接修改研发配置文件即可生效，优点是不需要开发管理后台工作量小，缺点是使用不够直观，一般是研发没时间做后台时使用的。
九、跨系统对接
当我们负责的后台系统要与公司其他系统或者其他公司功能对接时，通常涉及到以下几种对接方式：
1）API对接
即把系统的能力定义成一个个接口，合作方可以根据自己的需要来调用，是比较灵活的对接方式，适用于业务属性较强的功能点。
2）SDK对接
这种方式是把系统的功能打包成一个合集，合作方无需关心其中的逻辑也不需拆解，而是拿来即用，一般适用于工具性质较强的功能，比如APP监控、人脸识别、智能客服等较完整的功能。
3）页面对接
在跨公司合作时，会经常遇到合作公司并不想把数据进行开放，而只是想嵌入前端页面的方式还是进行对接，这种情况就用到页面对接，这种方式可以在请求页面链接时实现简单的数据传递，但无法获取页面中具体功能的数据。
十、旧数据兼容
互联网产品迭代速度快，当进行大版本迭代，升级了新功能新数据规则时，很容易造成旧数据的不可用，这时就必须要做好向后兼容。
通常的做法是按照新的业务规则建立新表，然后把旧表数据按照映射关系批量全部插入新表，接着使用新表，废弃旧表，就完成了数据兼容。很多时候也不一定非要兼容，如果旧的业务数据在新的规则下几乎不会使用时可以考虑直接丢弃旧数据，具体情况还是要根据业务来取舍。
下篇将继续分享下面三节内容，敬请期待。
5、后台产品设计要点
6、分析复杂业务的几个思考维度
7、后台与中台的关系
