产品经理在工作中还需要知道一个：用户权限设计能力。权限设计理念贯穿于后台产品、以及用户前端产品。
权限能力包括两类：数据权限、系统操作权限
有的人会好奇，为什么前端产品会有有权限管理的要求？接下来我将以角色、权限、以及RABC权限设计方法来概述权限设计、数据权限设计2个操作。
了解权限系统前，首先要定义角色，角色的分类如下
最高权限角色
超级管理员，这个角色一般为平台创建者。可以拥有最高权限，可分配所有的系统权限到其他用户，一般是把最高权限设计还会映射一个超级管理员作为副管理，方便删除、编辑人员
副管理员角色
副超级管理员，仅次于最高权限，可以分配自己权限下的以外权限。显然在他之上就是超级管理员权限
部分权限所有者角色
是指的是在副管理员下，有子权限的用户。比如在副管理员分层下的权限
特约用户角色
只是定向权限开通，同事这样的用户有大量的。比如PMTalk产品经理社区的签约作者
付费用户角色
付费用户权限在针对产品生命周期早期是与免费直接区分，随着付费用户精细化运营打造用户分层，比如QQ会员的超级会员、普通会员等
角色之间的关系如下，可以看见在超级管理员角色下以树状结构分布到子角色。
▲ 角色之间关系
基于角色权限控制的RABC权限思想
依次为理论的角色设计模型关系图
▲ RABC角色权限
上图是基于用户的会话集合归位角色再分配权限。角色有操作和控制对象的权利，在基础上将用户权限系统氛围：用户管理、角色管理、权限管理。
实际上用户管理在系统早期是可以满足权限使用，但随着系统用户、公司扩张逐渐增多，可能用户会有因为部门的职责区别，造成了部门下的同用户权限是一样的。
因此产品经理务必要在用户管理上增加部门管理对角色区分。
▲ 部门管理
将部门架构的编辑、添加、管理都以系统化的方式管理。
看到部门之间的流转关系，还可以知道部门下有什么基础权限。比如运营部门肯定会涉及到公众号管理、客服号管理，所以在以下部门的员工都要求设置。
同个部门中存在多个角色，比如上有运营总监、副总监、组长、用户，因此权限要给到每个部门负责人进行编辑、删除、添加。
让权限管理者降低了日常运营权限工作量，将权限分配能力分配给了其他成员。
▲ 网上来自部门角色权限管理的配置图
用户管理，给与用户授权角色
最普遍的做法是设计用户名单列表，针对用户信息进行编辑。
用户管理列表如上，可以操作用户属于封禁状态与否、查看用户先有状态。
每个角色下的权限设置，可以编辑权限、和删除权限。以及批量同意权限
设置好角色后，还可以在角色下查看已经开通的用户名单，对用户名单进行管理。
用户名单进行删除、添加。同时当前页面需要下可以展示多少用户、是否需要分页也要注意明确。
2.添加/创建用户
为系统添加新的管理人员，增加权限。增加手机号、邮箱、用户名称，如果企业使用了OA系统，可以和OA系统进行关联。
比如现在的企业微信、钉钉都是支持开放接口，快速同步员工信息。
3.创建添加账户管理流程
系统建设好后，接下来就是规范运营了。以账户开通来说要建立账户开通权限流程规范，比如下图是某个公司开通运营系统管理员权限的流程
▲ 系统权限创建流程
上图“选择字段”可以理解为权限下的子权限。若系统不复杂可以不用在早起权限设计上增加子权限颗粒度。
我们需要先设置角色，给新账号关联对应的角色，如果账号有特殊权限或者相关字段的权限，再单独设置相关字段。
最后基于RABC角色权限系统设置，产品经理可以借鉴的一个思考脑图案例
完成权限设计后，要搭建权限表单。快速罗列各个角色下的权限通道
▲ 图片来自网络
数据权限的设计
操作权限是比较容易做的，但数据权限则比较难了。甚至许多互联网公司都没有考虑数据权限，只要达到不同人员使用的功能不同即可。
数据权限可以控制组织、可以控制数据域（比如，10个门店，有的人能看到1个门店的数据，有的人能看到10个门店的数据）
做个比喻，功能权限就像是容器，觉得了你有什么功能，数据权限就像水，决定了你容器内放的是什么。功能权限和数据权限是相互独立的。
数据权限是指对系统用户进行数据资源的可见性、以及控制性。直白说：“复合条件的用户才能查看和操作对应数据的权限”
比如公司老板需要看到公司的营收、利润、用户增长数据
公司运营总监需要看到互联网产品业务营收
公司公司销售要看实物销售产品的以后
在数据权限设计下，要定义清楚规则元
名词定义：规则元。在本文是指单个独立的数据规则定义，不同用户对规则元可设置具体的规则过滤值，该值用作数据查询时的筛选条件。
规则元配置：规则元名称的配置。一个表中哪些字段可以进行规则设置，以及规则元名称如何与表字段关联。
网友评论