后台设计小结

2016-04-11 21:29:00

后台系统，在目前接触来看，主要分几种：管人、管事、管物。管人的，有对内和对外的两种类型，对外的CRM（客服管理系统）、对内的考勤系统；管事的，简而言之，就是人可以做什么事、可以怎样去做事，这种最经典的就是数据统计后台、业务流管理后台；管物的，主要是指电商类型的商城管理后台，用于管理商品的交易

但是，从本质上看，后台主要有权限管理、工作流、记录流三大方面。可以归结为一句话，谁可以对什么进行怎样的操作，需要产生什么记录：简称who-where-how-what

权限管理（who-where）

权限管理，目前主要是通过用户、角色、资源三方面来进行权限的分配。具体来说，就是赋予用户某个角色，角色能访问及操作不同范围的资源。通过建立角色系统，将用户和资源进行分离，来保证权限分配的实施。

那么，权限可以怎样设计呢？

如果是业务流后台，在设计权限时，可以按业务类型进行角色设计，比如客服、运营、充值员；如果是数据统计后台，可以按用户类型来进行角色设计，如对外用户、内部人员；如果是CRM，则可以按用户的职位等级进行划分。在进行一级划分后，往往还需要对角色进行细分，例如客服，可以细分为普通客服、客服组长、客服总监，通过级别的划分来控制可访问及操作的数据。

另外，在进行角色的细化时，有两点是需要注意的：

虽然我们将权限管理放在第一位，但是在实际开发过程中，权限的分配往往是在整个后台开发完毕后才去实现的（主要是为了避免权限设置对开发造成影响）。

工作流（how）

工作流主要解决的主要问题是：为了实现某个业务目标，利用计算机在多个参与者之间按某种预定规则自动传递文档、信息或者任务。

设计工作流时，除了最基本的单个后台工作流的设计，还有多个后台之间进行工作流的设计。OK，先从最基本的单个后台开始聊聊，工作流的设计，其实和2C产品的需求设计很相似：

在了解业务需求后，产出适合的业务流程图（业务流程图此处不展开，稍后另开一章来写）、状态图（部分简单的工作流不需要出这个），通过业务流程图，向开发更好的传递业务需求
搭建工作流的产品架构图，主要是罗列工作流涉及到的功能模块（广度思考），这个时候，就可以将产品架构图和其他人进行碰撞；为什么不使用产品原型图来碰呢？这个以下几点原因：
通过前两步，基本可以把工作流较好的传递给研发那边；紧接着，可以将产品架构图进行细化，细化到什么程度呢？最好是把工作流涉及的点都能够细化在上面，这样，在产出产品原型图的时候，可以更加全面的是思考单个模块与整个后台系统之间的交互

4.在第三点，有提到了产品架构图的细化，接着，就是放大招的时候— 出产品原型图

5.适当的重复上述3、4点，这样，一个较完整的工作流就设计好了

在出了产品原型图，就要开始和研发大大进行更凶残的肉体碰撞了，关于肉体碰撞的细节，在这里就不展开了，但是可以补充一句：做产品得耐操！

上面讲述的都是单个系统内的工作流设计，那么多个系统协同处理的工作流有什么不同呢？

首先在设计上，基本流程不会有区分。主要是要和系统架构师多多沟通，让一整套系的工作流能够更好的满足业务需求。在进行沟通的时候，最好可以先自己拟定一份假想架构图，这份产出物更多关注的是不同系统之间的数据交互，表明系统间的输出、输入，这样，在定好满足需求的架构上，才能够更好的对工作流进行设计。

其次，还有一点细节是需要关注的，那就是在不同后台的原型图中，要注意描述清楚工作流是否与其他模块有所交互，这样方便自己，也方便他人。