后台产品经理的成长是一个厚积薄发的过程，需要长期的坚持、积累、思考。继上篇之后，本篇继续介绍后台产品经理入门的剩余几章内容。
- 后台产品设计要点
- 分析复杂业务的几个思考维度
- 后台与中台的关系
- 后台产品的未来
05 后台产品设计要点
后台产品作为支撑系统往往涉及到具体的行业和业务特点，当我们直接拿具体业务来阐述后台设计经验时，往往会陷入其中无法进行通用性的提炼，也很难让其他领域的产品经理读者受益。因此我从产品设计的角度而不是结合业务的角度来总结一些有共性的后台设计要点，这套思路是适合所有后台产品的。
1、对状态的强化认知
对于一个后台系统，状态无处不在，灵活多变的业务需求是靠一张张数据库的表在记录的，除了业务数据的记录，状态是非常重要的基础。订单必须有状态，用于区分不同业务环节；一个上线的活动必须要有状态，是进行中、已暂停、还是已下线；一个员工账号也要有状态，是启用中、禁用中还是已注销。设计一个功能或系统通常需要先绘制流程图，而流程图中一个个状态的连接支撑起了整个功能设计的骨架，然后才是具体细节的设计。如何正确的强化对状态的认知和理解，我大概总结以下几点：
a）状态的独立互斥
这点与上面说的唯一判断字段有点类似，但实际不是一回事。因为状态是用于描述不同业务节点的，每个状态要与实际业务的关键节点进行一一对应，状态之间不能出现二义性，否则会出现多个状态对应同一个业务关键节点，不但会造成理解混淆，还可能使系统做具体判断时出问题。
b）状态在时间维度上是稳定的
这点其实也很好理解，一个具体业务的发展是有阶段性的，而状态就是在每个阶段取一个值，各个值连接起来就串联的业务，但如果状态的值取在各个阶段的临界点，这就很不好描述业务了。比如一个运营活动，可以用“进行中”和“已下线”两个状态来区分发生和不发生两个阶段，这是合理的，但如果状态叫做“下线中”，这就不是处在一个稳定的状态，而像一个瞬时态，到底是上线还是下线，我们从状态命名中就感觉很模糊。
c）注意子状态和组合状态
当业务相当复杂时，一个状态下面还可以设置子状态，比如单据的撤销状态，可以包括用户主动撤销、系统撤销、人工撤销，用于区分具体是怎么被撤销的。
而组合状态的意思是在用户侧展示的状态不单是订单表里存的状态名称，而是一个组合状态，比如在用户侧显示“已发货”，其实包含了订单状态为“创建成功”、支付状态为“已付款”、物流状态为“已出库”。像比较复杂的保险订单状态，还会包含订单状态、支付状态、续保状态等，因此不能用一维的线性的思维来看待状态。
d）状态机的流转路线
状态机图的确定，基本确定了系统和功能主体结构，各状态之间的起点终点、流转路线、判断条件决定了功能的玩法和限制，状态机图是梳理并对照实际业务的必备工具。当业务有功能拓展时，首先查看状态机图是否满足，如何调整才能满足，已经涉及到哪些相关调整，都需要用到这个图。
e）合理的状态有利于数据统计
当状态的设计都按照上述原则进行，状态与状态之间非常清晰，这对数据统计是非常有益的，因为很多的数据统计都强依赖对状态的定义，如果你在做数据统计的时候发现很难准确的提需求，或者发现无法按照业务需要的维度来进行统计，可以反思下系统的状态是否合理。
2、模块化抽象
对变量的抽象是一种模块化思维，能够减少很多重复的工作量，提高后期的开发效率，我将分成两种情况来描述。
一种是当多个页面都用到同一个内容时，该内容应该被抽象为公共变量，供各页面调用。比如一个常用联系人组件包含姓名、证件类型、证件号码、性别、出生日期这五要素，那么可以把这五要素设置成一个公共变量模块，在不同产品下单需要用到时直接调用即可。如果有的产品下单时只需要用到姓名、证件类型、证件号码三要素，则可以把五要素的变量模块拆细为五个变量元素，这样可以达到最大自由度的组合。
另一种情况是两个页面绝大部分内容相同，只有几个元素有差异时，这几个有差异的元素应该抽象为配置变量，做成一个配置文件或者管理后台，这样在调整该配置时就不用再写代码。有的同学可能对配置文件不太懂，它可以理解为一段未被编译器编译的配置代码，是对一个软件运行时状态的本地储存形式，可以实现对软件灵活的实时调整。比如同样一个商品的详情页需要在A平台是红色背景，有评论模块，在B平台是绿色背景，不要评论模块。如果事先将背景色、有无评论模块这两个变量做成配置项，只需要更改配置文件或在管理后台做相应勾选即可。
3、合理的配置化程度
有了模块化思维后，在做一些有配置的后台功能时，还有一个非常重要的点是掌握配置的尺度，针对不同产品设定合理的配置功能。
配置化功能有时候会提高系统的灵活度，有时候反而会限制系统的灵活性，这就要看配置化的程度是否与具体业务的需求相结合，对于业务上没有严格定义的内容最好不要做成固定的配置值，而是做成开放的配置项，可以随时更改和扩充。
比如我负责的一个推荐产品的功能，根据用户的个性化信息推荐不同的产品，且不同产品展示的样式和内容不一样，考虑到推荐结果页产品介绍图、特性、推荐语可能会变动，我把这些可能变动的项都做成了管理后台的开放字段，可以让运营随时修改，而产品名称、价格、在售状态这些随着平台统一调整的项则从产品后台去拉取，保证了与平台其他位置展示的一致性。
合理的配置化程度其实就是把该配置的都做成可配置，几乎不会修改的做成固定逻辑，这样既能支持业务，又能减少不必要的配置化开发工作量。
4、系统的拓展性
我之前经常遇到一种情况，当我做一个功能上线之后，业务方有时会再提一个与这个非常类似的需求，有时候仅仅只是改动很少的内容。如果在第一次设计时并没有预留可能的拓展性，就算只是很少的改动，还是要排期开发和测试，特别是有的功能还需回归测试，非常浪费开发资源，而且影响迭代速度。这时就考验在设计之初能否大概看出可能有的拓展性，在开发工作量几乎不变的情况下预留一些类似的逻辑，这样会非常便于类似功能的迭代。
举个例子，对于一个人工审核的结论页，有多种状态，每种状态下结论页的不同模块的元素、文案、以及对用户的触达文案，都是首次开发时配置好的。首次开发时业务方提出有三种状态，上线之后业务方说要再加一种特殊的状态，如果事先在状态机中预留了待定的状态，只需要把该待定状态下页面的元素、文案、对用户的触达进行设置即可，改动的工作量很小，可以快速的上线。
不过值得注意的一点是，在预留拓展性时尽量保证首次开发的工作量影响很小，如果为了暂时使用不到的预留需求消耗过多开发资源，就有点本末倒置了。最好的针对复制一份代码、预留一个状态这种相似功能进行考虑。
5、异常处理机制
稳定性是一个后台系统非常重要的职责，代码上的异常报警有开发人员来跟进，但后台功能上的异常处理机制是需要产品经理在设计时就考虑的。
比如产品上架时需要灰度验证，那么需要一个白名单功能，如果细分到具体功能的上架，那这个白名单功能还要细化到具体功能入口。
还比如某个功能接口挂了之后的兜底逻辑，如果是一个定时取数的接口，是否可以在接口挂了无法更新数据时仍然展示上次拉到的数据，并给前端一个字段反馈，让前端可以展示一个文案提示用户。
异常处理机制就像一个个应急的创可贴，在系统出问题时能够第一时间应急处理，让系统不至于大出血而影响使用，是非常必要的临时解决问题机制。
06 分析复杂业务的5个思考维度
很多时候我们在面对一个复杂的业务需求时，容易被业务的表象所迷惑，看起来非常复杂，这不只是后台产品，所有产品需求都会遇到。但如果有良好的结构化思维和本质思维，就可以剥开业务外表，把问题归纳为数学和物理上的关系，再复杂的业务往往也可以快速的理清头绪。 当然，理解业务是前提，理解业务后可以再从以下几个维度来思考其中的逻辑关系：
1、对应关系
任何业务需求一定会涉及到几个业务主体，它们之间要么毫不相干，要么就存在一定联系，当有联系时就涉及到它们的对应关系，理清这层关系后才能进行具体的方案设计。
在数学上，两个数据的基本对应关系只有三种，一对一，一对多，多对多。看似很常见的对应关系，却在后台产品的设计中无处不在。
举个最简单的例子，比如账号的注册，一个账号注册后生成一个uid，用户可以绑定手机号、微信号，也可以输入身份证号进行实名认证，手机号和微信号还支持更换，这时uid与手机号就是一对多的关系，uid与身份证号是一对一关系。
搞清数据之间的对应关系非常有必要，它直接关系到开发人员对数据库表字段的设计，以及后续要进行的相关数据传输和统计查询。其实对应关系也是UML图里类图部分的内容，是理清业务逻辑过程中必备的。
2、主从关系
主体之间的关联关系除了对应关系，还会存在主从关系。比如在静态条件时，两个主体之间的包含和被包含关系，以哪个主体为准，哪个主体次之；在动态变化时，哪个主体的变化会影响其他主体，哪个主体是被动受到制约。我将这类关系统称为主从关系。比如下图：
B主体全部被包含于A中，C主体部分包含于A中，当B发生变化时，A一定受影响，而C变化时则不一定。
对多个主体主从关系的正确判断，可以帮助我们更客观的认识事物，判断需求的优先级，做出更好的选择。
比如在产品经理日常工作经常会遇到一个情况，就是反复实现几个类似的需求，明明好像上次做过类似的，这次只是改动了一点点又要重新做。这种情况常常是由于没有抓住需求的根源，只是在从属系统（模块）中解决问题，没有在这个需求对应的源头主系统中解决，也或者说是需求实现的方案不是一个根源上的主方案，而是一个浅层的从属方案。
3、关联程度
当多个主体之间都有互相影响的关联关系时，我们需要把这个关联的程度进行量化和大小对比。比如A和B两个主体之间影响的因子很少，那便是弱关联程度，A和C之间有多个变量相互作用，那相对来说 属于强关联关系。在分析业务时，我们可以把所有的相关主体通过粗细不同的线条来描述它们之间的关联程度大小。
理解不用主体之间的关联程度可以帮助我们做出更好的选择。
比如在实际处理业务需求时，同样一个需求一般有多种实现方案，如果每个方案看做一个主体，现有的相关系统模块也看做一个个主体，在进行选择时需要基于该需求与当前系统哪个模块关联程度最高，根据高内聚低耦合的设计原则，应该把需求放在相关性最高的模块中实现。
4、时间维度
在物理世界中，我们常用三维空间和时间用来描述事物，即时间和空间上都有顺序。而互联网的世界主要就是数据按照一定规则进行的交换与传递，不受三维空间的限制，因此可以认为只有时间维度的顺序。
对应到产品设计的细节来看，不管什么复杂的业务，其中的具体事件一定有时间发生顺序，它们发生的先后之间是否有对应不同的限制条件，是否为了实现的方便可以不按照业务事件的发生顺序？在哪个时间点进行哪个事件更为合理？这些细节最终都会落到具体的对应到代码的处理，也会一定程度影响到整个系统的实现方案和效果。
比如在互联网保险投保的流程中，系统需要对用户大量的信息进行校验，来判断用户是否符合投保要求，即通常说的核保。用户的一些直接输入的信息通过前端实时校验进行拦截，复杂的信息通过整个页面提交后接口来进行校验，该用户更深层的一些诸如征信风险、信用风险等信息再通过风控接口进行拦截。这就把数据校验这个功能从数据的传输时间维度上拆解成了三步。
这其实也就是研发的时序图思路，只不过产品经理在业务梳理阶段就要理清关键业务的时序。
5、因果关系
凡事有因必有果，不是不报，是时候未到。因果关系看起来非常简单，但现实中我们却常常陷入两个误区。
- 把事件的结果归纳为单一原因造成的
- 把一个事件的结果当原因
这两个误区会使我们无法找到问题的根本原因，也就无法从根本上解决问题。
举个例子，在上周A产品的销量提升了，产品详情页的页面转化率提高了，而上周产品经理刚好给页面加了指示引导功能，如果我们就认为产品经理上周做的功能是销量上升的原因，那就陷入了第一个误区，因为可能还存在其他很多的变量，比如可能是产品上周减价了。如果认为产品详情页转化率提高是销量上升的原因，那就陷入了第二个误区，因为页面转化率提高也是一个产品卖得更好的表现结果，而不是原因。也许我们全面盘查销量提升的变量后会发现，根本原因其实是该产品可以使用刚发的优惠券进行大额折扣。
要避免陷入误区一，需要更全面地看待影响事件的变量，不能停留在线性的因果视角；
要避免陷入误区二，需要区分什么是结果什么是原因，一般只有变量事件才可能是原因，而数据、效果方面呈现的内容都是结果。
以上5个思考维度，前三个是静态分析视角，后两个是动态分析视角，并不是什么新的高大上的理论，但却是我总结出来并真正在实践中受益的。
后台产品的建设本身就更偏向严谨的工程思维，抽去业务的外衣，从产品层面进行高度归纳的东西才能让我们举一反三。
07 后台与中台的关系
后台是一个广泛的范围，是一个与前台对应的概念，对于大多数公司，后台其实就是所有的业务支撑系统，比较小的公司是没有产品经理专门来负责后台产品。
但随着大公司大平台的出现，并行的业务线发展得越来越大，每条业务线都要一个后台，各个后台之间又相对独立，形成了烟囱式的技术架构，这样很难以实现多业务数据的整合和共享，也很难快速对类似的新业务进行支撑响应，于是才诞生了中台。
国内最早实践的应该是阿里巴巴，简单点说，中台是后台的精细化设计衍生出的概念，是为了更高效率的提升对前端业务支撑的系统，偏重与对技术、数据、业务的共性抽象和复用。
因此，我认为后台与中台是相辅相成的，在不同公司背景下的重合情况并不相同，我们不用刻意为了概念上的区分而分离后台与中台的具体内容，特别是在行业内真正在做需求的产品经理，要做好中台需要先做好后台的事情，掌握后台设计的原理、方法，在公司发展壮大后需要进行中台建设时才能把后台相关能力抽象成为中台。
08 后台产品的未来
最后来聊聊后台产品的未来。
互联网蓬勃发展的初期，产品经理是供不应求的，非常多来自各个专业的毕业生只要多体验APP、写点竞品分析报告、画画交互，就能进入行业获得一份不错的工作。
然而时间已经来到2020年，做纯互联网的产品早就不再是主流，互联网已经与各行各业相结合并产生了不同的化学反应，再加上经济下行的背景，企业对效率提升的重视，资本也不再盲目砸钱投新项目，产品经理的招聘越来越细分了，各个领域公司需要的是既懂业务又懂互联网的产品经理，而这些与各领域业务有着高度结合的需求正是后台、B端产品的主要工作，这些都需要很多软件设计底层的基本功。一个不懂UML、不懂数据库、不懂算法、不懂软件开发流程，只会分析用户、交互设计、线上活动策划的C端产品经理的竞争壁垒会越来越低，也很难在有行业深度的领域担当大任。
作为业内人士，特别是从事后台产品经理的人来说，一定能看到企业内部非常多环节都是不合理不够高效的，公司对外的PR稿写的都是高大上的人工智能，真正到做需求时我们这帮人会发现更多的是人工智障。
现在还是互联网与各行业的融合期，各领域的公司也有非常大的改善空间，未来的企业内部组织效率提升一定会发挥更大的价值，这也是后台产品经理价值的所在。
后台产品经理，任重道远，但未来可期。
