后台功能设计的起点：权限方案设计分享

　　权限是一个公司信息系统的起点。我从入职以来就一直想要对公司后台的权限系统进行一个梳理（其实是老板要求的），苦于对后台和公司业务还不够了解，所以想法一直没能成型。终于，经过几个月断断续续的琢磨，我趁最近需求数量不多的时候，把权限的调整方案梳理了出来。
　　这次梳理公司后台的系统，我在原有权限系统的基础上引入了公司组织架构，形成了动态权限管理模式，使得公司的权限管理更加合理化。目前已经把方案提交给开发进行审核，希望可以最终落实。这里就先向大家汇报一下这几个月以来梳理权限的成果，给同样有权限体系设计问题的朋友们一点参考。
　　要设计权限，首先要对权限已有的成熟方案有一定认识，其次要对业务有深入的分析，才可以在业务的基础上有针对性的设计权限模型。
　　关于权限成熟方案，我查了很多资料，主要了解了一些关于RBAC（RoleBasedAccessControl）权限模型的知识。加上在前司对SharePoint的权限分配方案有一定的了解，权限的知识基本就已经足够了（不够也没有更多了，找到一篇从产品的角度解释RBAC的文章，值得一读：请点击查看）
　　关于业务需求分析方面，我对公司后台的权限系统做了梳理。
　　因为公司对数据的保密要求很高，所以后台有大量查看项目、查看投资人的细致权限设置，但是缺乏一致的管理方法，导致经常出现有需求无权限，或调动后权限没有及时清除的问题。
　　公司后台主要是按照RBAC设置了权限体系，另外还根据项目服务小组的机制为每个项目单独设置了权限。
　　后台RBAC的权限角色中，有部门角色、功能角色、临时团队角色等等，相对比较混乱。
　　现在这套系统面对一些问题：
　　权限角色太多，分类混乱。有大量临时建立弃而不用的分组；
　　如果员工调换部门，需要逐个删除他已有的权限，再逐个赋予新部门的权限；
　　如果部门领导更换，需要对部门内员工的所有成员的审批对象都进行调整。
　　为了解决上述问题，我尝试将公司的组织结构信息引入权限管理的系统。
　　尽量以部门为单位分配权限，权限角色过多混乱的情况；
　　出现员工部门调动或领导更换，会根据其部门更改自动重新分配权限；
　　对无法按照部门分配的功能采取原有的权限分配模式，通过给不同的员工分配不同的角色实现，保证灵活性。
　　从上述的思路出发，我定义了新的权限管理需求。新的权限管理分为部门权限制度和非部门权限制度两种：
　　1、部门权限制度
　　部门权限分组默认按照组织结构图。
　　按照小组设置部门，部门分管理者权限和默认权限两种，默认权限为部门管理权限的子集。
　　若组织架构中的小组设置了管理者，则管理者默认拥有管理者权限。除管理者外，所有人加入小组后默认拥有默认权限。
　　（2）管理者权限包括
　　部门权限维护类：新建子权限组、默认权限维护、打破权限集成等权限（可以分配给部门领导使用，也可以掌握在超管手中统一分配）
　　审批类：所有报销、请假和购票的申请（若小组没有设置管理者，则小组成员所有审批事宜由上级层级中的管理者负责）
　　职能类：单个部门的全部权限
　　（2）权限维护类权限详细介绍
　　子权限组：部门内可以根据员工设置子权限组，根据子权限组，分配部门权限；
　　默认权限维护：增删进入部门所默认拥有的权限；
　　打破权限继承：使某位员工失去默认拥有的权限，为其单独分配权限。
　　2、非部门权限制度
　　组织方法参照原有RBAC权限管理；
　　超管可以为单个员工或小组开启非部门权限。
　　可以为非部门权限设置有效时间段；
　　若员工调转部门，则所有非部门权限默认失效，需要超管审批以后方可重新生效。
　　这套规则可以基本解决原来的权限与部门没有关联的问题，以及权限分配混乱难以管理的问题。这仅仅只是产品从业务角度梳理出来的需求，具体实现还需要和开发商量以后解决。而且要真正能够落实实现还需要很漫长的过程。
　　这次设计方案给我最大的体会就是，设计复杂的功能最有效的手段还是从具体是使用场景出发，使用场景决定业务逻辑，业务逻辑决定功能逻辑。我在最初设计的时候执着于寻找成熟的权限管理模式套用，后来发现这样生搬硬套不能提升后台权限分配的效率。在过后的几个月工作中，我接触到了不少分配权限的实际问题，比如不知道分权限给谁，或者分配出去的问题没有办法管理的问题。这些问题直接启发我引入了公司组织架构的概念，也便有了这套方案。
　　所以，产品的设计与实现都服务于使用场景，才是真正好的产品，这一点对业务为导向的后台产品至关重要。与大家分享，也请大家多提意见。