资源位|设计后台系统的几项原则和注意事项车路协同|l5|车联|蘑菇|apollo|阿

编辑导语：后台系统虽然很重要，但由于绩效方面性价比不高，很少得到足够的重视。本文简述了后台的概念、类别、设计的方法要求和需要注意的事项等，并对“应不应该做后台产品经理”这个问题作出了解答，推荐对后台系统设计感兴趣的朋友阅读。

文章插图
做后台系统其实很重要，能够比较好的提升系统架构的能力。但是产品人很少讨论后台怎么做，一是因为相比app端变化并不多，二是因为后台并不能提升业绩，在绩效上也无法合理体现。虽然能够提供效率、降低成本，但是其实很多情况下并不被重视。
我最近又开始做数据后台，折腾得很，想了想，就正好分享一下做后台的一些简单经验，希望对大家有个启发。
一、什么是后台后台其实有两种理解的方式：
一种是最常见的解释，表示这是一个产品或者服务，是给内部用户使用的，譬如打开一个操作后台所指的后台；
一种是专业视角的后台，譬如后台产品经理，指的是做后台系统的产品经理，这里的后台系统不仅仅包含操作界面，还包含了信息流和业务流，很多时候未必在界面上体现。
譬如电商物流，你买了东西，你就知道商家会打包并把快递委托给快递公司进行运输和投递，这种业务流程在任何界面中都是不可见的，但大家都知道流程是这样的，这也是后台系统的一部分。
我认知里面的后台其实更倾向于是第二种解释，这是一个产品经理应该认知到的后台。
当然如果是和业务人员进行交流的时候，说后台那就指的是界面意义的后台，我们今天聊的也是和界面后台相关的问题。
二、后台怎么分类一般来说后台分成两大类：功能后台和数据后台。
功能后台就是提供给特定人员进行操作使用的，它影响的是在app端展示的内容和服务。数据后台就是给特定人员查看数据的，它主要是统计和反应业务的运营情况。
对于一家公司来说其实这两种后台都是必须有的。
三、后台怎么设计后台的设计其实也是需要遵循产品的设计理论的，一般是根据使用对象和功能类型进行聚合分类。
我们先说说功能后台。
功能后台一般先根据内部部门的划分，把各部门需要使用的功能列出来。像运营部门需要操作app内部各种资源位(banner和icon)的配置，所以必然会有单独的运营管理模块。
【 资源位|设计后台系统的几项原则和注意事项】那么资源位又有在app上的位置(首页还是我的)、资源位的类型(banner还是icon)的区别，那你怎么设计这个架构？是按照app的位置分成多个二级页面？还是按照类型，分成banner和icon两类进行设计？还是不区分，按照统一框架设计？
这都是有区别的，不同的分类逻辑决定了怎么设计架构和界面。一般来说按照类型区分或者不区分会合适一点。有些功能可能涉及到多个部门同时使用的问题，这就看职责和重要程度，一般看这个功能谁用得多就划给谁。
譬如获客投放，有的公司会把付费投放的放在市场部门，免费投放的放在运营部门(通常是内部其他产品投放或者公众号投放)，但是从功能上来说，一般是放在市场部门的所属模块下面的，因为实际上这个功能对于市场部门来说更重要，以及最主要的还是市场部门在使用。
数据后台比功能后台好处理，一般是按照各部门的数据需求来处理。
当然如果是产品的角度进行规划的话，可以先根据各部门的指标和业务链路进行拆分设计。不过从我的经验来看还是以各部门的需求为基础进行设计比较好，因为在看报表这件事情上每个人的想法是不一样的，细分程度和特殊要求还是差别很大的，没必要自己做一个规划，适用性不好。
数据后台按照大盘和各部门分表设计就行，但需要对数据的可靠性做大量验证。
首先是需要确保统计口径是对的，这个的话在给定义的时候不能有含糊的地方。其次是在每个页面都加一下统计口径的说明，有的情况下会出现同样的一个统计字段，但是统计口径是不一样的。这个时候光看字段名是不行的，没有说明就区分不出来，使用的人就会觉得有问题。最后是需要根据明细去对一下统计数据是否准确，做一下数据校验。
这是一个非常细致和工作量非常大的活，做的时候其实比较麻烦。如果公司流程合理留了足够的测试时间，那么就在测试环节验数据，如果测试环节没法验或者没有留时间，那就直接发布，然后在线上对数据，一边对一边修bug。