产品人都不喜欢做后台管理系统，具体的原因大家都明白的。今年九月份，入职一家新公司，主要负责的是该电商项目的后台管理系统。是的，一开始也觉得没成就感。但是对于从来没有PC端设计经验的我来说，何尝不是挑战。现在这个项目也接近尾声了（特别想撒花庆祝）我想花时间，写下我的总结，可能包含一些我自己查阅的资料等等，这样我对这一部分有更加系统的了解和认识。
之前接触的是To C的产品，现在转到To B，这两者的区别确实很大。To B更加强调的是专业性、功能的完整性，对于易用性的要求不如C端产品高，用户上手是需要学习成本的，但是我在想万事万物都有自己的规律和套路，而我们在设计后台管理系统在模块的设计和搭建上又应该遵循怎样的一个套路呢？
一、清楚产品的本质
以自己做的产品为例，为什么会存在这个后台管理管理系统，如果没有它，前端的App就无法正常运行了，正所谓前台一小步，后台一大步。后台管理系统是为前端服务的，想要了解到功能点和需求，除了需求调研以外，还需要对前端的需求非常熟悉。你要知道在App上，每一个元素的出处，需要后台系统去提供些什么，这样就不会漏掉需求点，导致前后台没衔接好。所以我们是先调研App的需求，整理好后台的需求，再跟客户进行一个确认，如果他们还有补充，两端又要做什么调整。当然如果不是做为前台服务的后台，就另当别论。
二、后台管理系统的角色权限模块
后台管理系统，功能模块虽然会根据项目的不同作出变化，但是有一个模块是必不可少的，那就是角色权限模块
为什么会提到角色权限模块，因为它不仅是整个系统的一个小模块，而且一直贯穿整个系统，从登录、操作到最后的登出。这一模块应该包含用户管理、角色管理、权限管理（角色管理和权限管理含在一起，也可分开，具体情况具体分析。。。）
1.参考模型——角色权限模型：（RBAC Role-Based Access Control,基于角色的访问控制），构造“用户-角色-权限”的授权模型。该模型的核心为功能权限控制和角色产生关联，角色再和用户账号关联。一个用户可以拥有若干个角色，当一个角色被赋予了某一个用户时，该用户就拥有了该角色所包含的权限。以自己做的产品为例，在创建角色时，需要选择该角色的权限。创建用户时，需要选定该用户的角色。
以上说的都是RBAC0，RBAC1、RBAC2、RBAC3都是在其基础上进行升级，可根据自家产品的复杂程度，选择合适的角色权限模型。参看：RBAC模型
之前看到一个有意思的问题：
如果需要给一个特殊用户增加某一个权限，如何处理？这里有两种做法，一种是创建一个新角色，使其包含该特殊用户所需要的权限。另外种做法是在用户管理里，可针对单个账号二次修改权限，相当于单独把这个账号从用户角色中抽离出来，单个账号的最终拥有的权限为用户角色权限集和二次修改权限集的并集。至于这两种做法哪种好，我一直坚信存在即合理，可根据情况而定。在用户数量不多，角色类型少的情况下，第一种可以考虑，反之就第二种吧
2.后台权限模块的设计流程
梳理角色类型功能架构图——设计功能原型——细化产品方案，形成PRD。
由于我们做的后台管理系统不算庞大，所以整个角色权限并不复杂。只是在给不同的角色梳理功能架构时，不要把权限控制到非常精细的级别（我们做到的是子tab的程度），太过精细，在进行创建、修改角色时，效率会很低。
三、印象最深刻一个模块设计
有点尴尬，可复用的就看看上面，下面说说特别让我抓耳挠腮的一个模块：订单管理，为什么抓耳挠腮，就是因为感觉很简单，不就那么几个状态嘛，这么多电商，照着抄呗。最开始我也这么想，So easy，拍拍胸脯，一周妥妥的。后面做得我黑眼圈都出来了，免疫系统受到了极大的威胁，我才不得不感叹，真心复杂。因为就算有这么多电商，每一家的业务流程、规则也不尽相同，结合自己的业务流程和相应的规则，就呵呵了。
首先奉上张流程图，让大家感受下，还有张更复杂，但是我不想打马赛克了，累！
其实我只是想说明流程图的重要性，对于越复杂的流程，就越应该先把整体的脉络梳理清楚，这样开发也好，客户也好才能有一个总体的把握，毕竟他们真的没有耐心一次性把你的原型看完，除了你自己...
其实就是想把自己做过的，了解的，串起来，也算是个人经验的一个总结，还有很多有待提高的地方，慢慢来吧
