因为公司对数据的保密要求很高，所以后台有大量查看项目、查看投资人的细致权限设置，但是缺乏一致的管理方法，导致经常出现有需求无权限，或调动后权限没有及时清除的问题。

公司后台主要是按照RBAC设置了权限体系，另外还根据项目服务小组的机制为每个项目单独设置了权限。

后台RBAC的权限角色中，有部门角色、功能角色、临时团队角色等等，相对比较混乱。

现在这套系统面对一些问题：

权限角色太多，分类混乱。有大量临时建立弃而不用的分组；

如果员工调换部门，需要逐个删除他已有的权限，再逐个赋予新部门的权限；

如果部门领导更换，需要对部门内员工的所有成员的审批对象都进行调整。

为了解决上述问题，我尝试将公司的组织结构信息引入权限管理的系统。

尽量以部门为单位分配权限，权限角色过多混乱的情况；

出现员工部门调动或领导更换，会根据其部门更改自动重新分配权限；

对无法按照部门分配的功能采取原有的权限分配模式，通过给不同的员工分配不同的角色实现，保证灵活性。

从上述的思路出发，我定义了新的权限管理需求。新的权限管理分为部门权限制度和非部门权限制度两种：

1、部门权限制度

部门权限分组默认按照组织结构图。

按照小组设置部门，部门分管理者权限和默认权限两种，默认权限为部门管理权限的子集。

若组织架构中的小组设置了管理者，则管理者默认拥有管理者权限。除管理者外，所有人加入小组后默认拥有默认权限。

（2）管理者权限包括

部门权限维护类：新建子权限组、默认权限维护、打破权限集成等权限（可以分配给部门领导使用，也可以掌握在超管手中统一分配）

审批类：所有报销、请假和购票的申请（若小组没有设置管理者，则小组成员所有审批事宜由上级层级中的管理者负责 ）

职能类：单个部门的全部权限

（2）权限维护类权限详细介绍

子权限组：部门内可以根据员工设置子权限组，根据子权限组，分配部门权限；

默认权限维护：增删进入部门所默认拥有的权限；

打破权限继承：使某位员工失去默认拥有的权限，为其单独分配权限。

2、非部门权限制度

组织方法参照原有RBAC权限管理；

超管可以为单个员工或小组开启非部门权限。

可以为非部门权限设置有效时间段；

若员工调转部门，则所有非部门权限默认失效，需要超管审批以后方可重新生效。

这套规则可以基本解决原来的权限与部门没有关联的问题，以及权限分配混乱难以管理的问题。这仅仅只是产品从业务角度梳理出来的需求，具体实现还需要和开发商量以后解决。而且要真正能够落实实现还需要很漫长的过程。

这次设计方案给我最大的体会就是，设计复杂的功能最有效的手段还是从具体是使用场景出发，使用场景决定业务逻辑，业务逻辑决定功能逻辑。我在最初设计的时候执着于寻找成熟的权限管理模式套用，后来发现这样生搬硬套不能提升后台权限分配的效率。在过后的几个月工作中，我接触到了不少分配权限的实际问题，比如不知道分权限给谁，或者分配出去的问题没有办法管理的问题。这些问题直接启发我引入了公司组织架构的概念，也便有了这套方案。

所以，产品的设计与实现都服务于使用场景，才是真正好的产品，这一点对业务为导向的后台产品至关重要。与大家分享，也请大家多提意见。