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

做后台系统其实很重要，能够比较好的提升系统架构的能力。但是产品人很少讨论后台怎么做，一是因为相比app端变化并不多，二是因为后台并不能提升业绩，在绩效上也无法合理体现。虽然能够提供效率、降低成本，但是其实很多情况下并不被重视。

我最近又开始做数据后台，折腾得很，想了想，就正好分享一下做后台的一些简单经验，希望对大家有个启发。

一、什么是后台

后台其实有两种理解的方式：

一种是最常见的解释，表示这是一个产品或者服务，是给内部用户使用的，譬如打开一个操作后台所指的后台；

一种是专业视角的后台，譬如后台产品经理，指的是做后台系统的产品经理，这里的后台系统不仅仅包含操作界面，还包含了信息流和业务流，很多时候未必在界面上体现。

譬如电商物流，你买了东西，你就知道商家会打包并把快递委托给快递公司进行运输和投递，这种业务流程在任何界面中都是不可见的，但大家都知道流程是这样的，这也是后台系统的一部分。

我认知里面的后台其实更倾向于是第二种解释，这是一个产品经理应该认知到的后台。

当然如果是和业务人员进行交流的时候，说后台那就指的是界面意义的后台，我们今天聊的也是和界面后台相关的问题。

二、后台怎么分类

一般来说后台分成两大类：功能后台和数据后台。

功能后台就是提供给特定人员进行操作使用的，它影响的是在app端展示的内容和服务。数据后台就是给特定人员查看数据的，它主要是统计和反应业务的运营情况。

对于一家公司来说其实这两种后台都是必须有的。

三、后台怎么设计

后台的设计其实也是需要遵循产品的设计理论的，一般是根据使用对象和功能类型进行聚合分类。

我们先说说功能后台。

功能后台一般先根据内部部门的划分，把各部门需要使用的功能列出来。像运营部门需要操作app内部各种资源位(banner和icon)的配置，所以必然会有单独的运营管理模块。

那么资源位又有在app上的位置(首页还是我的)、资源位的类型(banner还是icon)的区别，那你怎么设计这个架构？是按照app的位置分成多个二级页面？还是按照类型，分成banner和icon两类进行设计？还是不区分，按照统一框架设计？

这都是有区别的，不同的分类逻辑决定了怎么设计架构和界面。一般来说按照类型区分或者不区分会合适一点。有些功能可能涉及到多个部门同时使用的问题，这就看职责和重要程度，一般看这个功能谁用得多就划给谁。

譬如获客投放，有的公司会把付费投放的放在市场部门，免费投放的放在运营部门(通常是内部其他产品投放或者公众号投放)，但是从功能上来说，一般是放在市场部门的所属模块下面的，因为实际上这个功能对于市场部门来说更重要，以及最主要的还是市场部门在使用。

数据后台比功能后台好处理，一般是按照各部门的数据需求来处理。

当然如果是产品的角度进行规划的话，可以先根据各部门的指标和业务链路进行拆分设计。不过从我的经验来看还是以各部门的需求为基础进行设计比较好，因为在看报表这件事情上每个人的想法是不一样的，细分程度和特殊要求还是差别很大的，没必要自己做一个规划，适用性不好。

数据后台按照大盘和各部门分表设计就行，但需要对数据的可靠性做大量验证。

首先是需要确保统计口径是对的，这个的话在给定义的时候不能有含糊的地方。其次是在每个页面都加一下统计口径的说明，有的情况下会出现同样的一个统计字段，但是统计口径是不一样的。这个时候光看字段名是不行的，没有说明就区分不出来，使用的人就会觉得有问题。最后是需要根据明细去对一下统计数据是否准确，做一下数据校验。

这是一个非常细致和工作量非常大的活，做的时候其实比较麻烦。如果公司流程合理留了足够的测试时间，那么就在测试环节验数据，如果测试环节没法验或者没有留时间，那就直接发布，然后在线上对数据，一边对一边修bug。

如果是在小公司其实后面那种情况遇到的概率会非常大，业务领导都是上来就问明天能不能上，完全没有合理性的概念，不必纠结。如果技术靠谱点问题就少，如果不是很靠谱那就问题非常多。

我最近的经验就是开发了2天，bug断断续续修了3天。你感受一下。

四、后台设计需要注意哪些问题

1. 后台要好用

因为是内部使用的后台，其实很多小公司都是很不重视后台的可用性的，界面难看、难用，模块划分不清晰。如果遇到这种情况可以让技术选一个好的框架，在开发的时候注意一下页面干净和布局清晰一点。

我就遇到了这种情况，后台整个界面扭七扭八的，非常难看。

2. 后台尽可能少

我现在的公司功能后台有6个，更新一下app版本要同时登录3个后台修改数据，这TM真是绝了。如果有条件的话尽可能合并成1-2个后台，或者在设计的时候就不用分开设计。

但也不是说合并成一个最好，譬如如果涉及到电销系统，系统本身就很复杂且只有电销部门使用，这种情况下其实是可以单独做后台的。

从实际的情况来看其实合并后台是不大现实的，因为成本高、周期长、风险大以及对于业绩的提升难以估量，公司层面比较难通过。我做过一次后台合并，开发了3个月，修bug断断续续修了2个月，惨不忍睹。

所以如果不是领导提这个事情，尽量不要主动提，因为绩效上来说很难给你加分，甚至搞不好会减分。

3. 权限设计要合理

权限设计有两种方式：

一种是根据岗位设计，不同的岗位权限不同，同一个岗位权限一致。这种方式的好处是设置一次后，来新人只要挂一下部门，权限就有了，比较适合规模比较大的公司，职能比较清晰，变动也比较少；

一种是根据用户进行选择，每次来一个人都需要配置权限，好处是非常灵活，比较适合初创型企业，一切都还在变化，人员也不多，所以需要这种方式。

这里面可能需要注意一下，在页面内可能还会细分权限，譬如页面上有导出按钮，有的公司要求比较细就会针对这个导出功能也会有单独的权限。

有的公司会做成和钉钉的组织架构关联的方式，也可以，扫一下登录，安全性也挺好，而且产品经理就不需要设计权限系统了。

4. 分类要合理

这个比较容易把握，一般是按部门和职能组合后台就行。

但是一定要说明的是，最好不要把数据和功能混在一个后台上，不伦不类的。倒不是说实现上有问题，但是这就会导致分散在不同的地方，使用起来并不方便的问题。以及很多公司都有单独的BI系统，然后就会导致两边都有数据，两边还不一定对的上的问题，处理起来更麻烦。

然后一定要注意的是对原有功能的适配。

大量的情况下并不是新增全新的功能，而是针对原有功能进行优化和新增，这就涉及到对原有功能的适配问题，如果产品不提的话技术很可能是不会做额外的处理的，建议在提需求的时候提一下适配问题。

我最近的经验就是在原有功能上加了一个新功能点，但是技术发布之后没有任何说明，等到业务部门观察数据的时候才知道，需要做一次更新保存新功能才会生效，我真的是服了，没做处理没关系，连个说明都没有。

5. 最好有一个后台功能使用说明书

因为总是会有新人来，一些功能可能会更新，没有记录就每次都会问产品经理，还不如写一个说明文档，让各部门查看使用比较好。

当然我也知道会遇到有些同事就是不看文档，就喜欢问你，这也是很烦人的。你看情况处理，关系还行就说一下，关系一般就告诉他文档里面有，可以自行查阅。

五、应不应该做后台产品经理

最后聊一下这个问题，可能还是有朋友是有点困惑的。

这个问题每个人的见解不一样，但我们认为判断的标准在于可迁移性好不好，也就是你这个经验拿到其他公司是否可以沿用，如果不可以那就不行，如果可以那就行。这个其实和是什么类型的产品经理没关系，主要是考虑经验和技能的可迁移性。

举个例子，在电商做仓储履约的产品经理，就是归属到后台产品的大类下面的，这种产品经理目前还是蛮吃香的，经验和技能的可迁移性也很好。这种需要考虑系统和现场人员如何互动的产品经理其实蛮考验经验和洞察的，核心是优化流程提升效率，没有足够的经验是不可能做好的。

做后台在大部分时候都是一件重要但对于绩效来说性价比不高的一件事情，所以大部分情况下也没办法投入大多精力去做。尽可能的在设计的时候就把架构设计的好一点，然后在框架里设计，做了之后如非必要不改动，一改动的话就涉及到对于历史功能的适配问题，其实很麻烦。

今天想聊的就这么多，希望对你有个启发。