写在前面，为什么要写权限系统的设计呢？
由于每一个项目，有管理后台，90%会有权限管理。在我自己历史以往的项目，实在对付权限始终是一个相对表面的认知。直到我去年研究了钉钉的管理系统、以及今年做了产品重构，让我对权限有了一个深度的认知。
一、权限是什么
我对付权限的理解，一开始是一个账号，管理着后台的某些模块；这个时候，权限很大略，他是一个账号列表，可以编辑账号信息以及设置账号查看菜单，即账号yimi可以管理订单列表。
后面接了一些门店真个项目，在区分菜单查看上，也加上了数据区分，即账号yimi可以管理门店的订单列表数据；上面这两项，我以为可以基本可以支持中小型的项目是足够利用的。
然后更深一个层级的，当你接了一个大型的项目，你的后台管理员是一个集团的人，或者是上百人，这个时候一个账号区分是远远不能知足的；也延伸了在做CRM系统的时候研究了钉钉的逻辑，权限不仅仅是开通一个账号（仅有账号+密码）这么大略，权限是对付不同部门的人的管理。那么这个时候会将账号跟菜单权限独立开来。
账号即部门下面的某个成员，可通过手机号作为唯一标识。菜单权限按照不同角色去区分，财务有拥有什么菜单、采购拥有哪几个菜单。
听到这里，权限就涉及了：部门、成员、角色、菜单。那我会以为，权限可繁芜可简化，实在无非是人管事。那么不同的权限设计会有什么差异呢？
二、最小权限设计
最小的权限设计，如下图所示，有登录账号、密码、以及菜单勾选。实在还有个XS版本的，即仅有账号，无菜单权限分隔。
最小权限设计-图示1
那什么情形会利用这种最小的权限设计，我个人的理解是小型的项目，或者说客户内部运营构造相对大略；这个时候须要把稳几点，第一个拥有全体菜单即拥有菜单所有操作，第二点是没有数据隔离，即每个拥有菜单权限的管理员查看内容同等。
对付需求梳理如下所示：
三、中型项目权限设计
中型大小的项目，类似于多门店、或者是卖力角色不同，同个模块须要查看不同数据、进行不同的操作。如下图所示：
中型项目权限设计-编辑管理员-图示2
中型项目权限设计-编辑角色-图示3
相对付最小权限设计，你可以理解为菜单+账号的拆分，并且在菜单的根本上，扩展了操作权限；也通过角色的区分，扩展了数据权限，此时的权限=菜单权限+操作权限+数据权限。
相对付上一个会繁芜很多，为什么我前面会说建议按照产品体系，再去做这一套中型的权限系统？
一方面，众所周知是由于开拓事情量以及难度，对应报价会高；另一方面是，这个的繁芜度也提高了他利用难度，如果是没有这种业务情形需求(类似于多门店、或者是卖力角色不同)，就不建议用了。
末了也是最主要一个方面，针对不可持续性产品的解释：不断向软件增加功能，是不可持续的。增加繁芜性意味着遗留代码越来越沉重，导致产品掩护本钱越来越高，而且也越来越难以灵巧应对市场变革；这个道理我想不仅仅适用于用户前端，对管理后台也同样适用。
对应的需求梳理如下：
四、大型项目权限设计
大型项目的权限，最大的一个变革，是有部门组织架构，不同部门的人利用系统，即将管理员管理拆解为部门管理+成员管理，但是又不仅仅于此。
在一个接入审批的系统、或者CRM中，每每数据是相对独立的，可以按照部门组织架构数，去区分数据的权限。如下图所示：
大型项目权限设计-部门组织架构-图示4
如果说，中型项目的数据权限是按照门店或者区域划分，那么部门树则是数据权限的另一个维度。按照创建者所在部门，将这条数据归属于某个成员某个部门（此处还要考虑成员存在多部门的情形），同个部门间数据独立，而主管可以查看所有人的数据。
则这个数据划分，并不适用于后台管理的所有列表，例如用户列表、订单列表此类数据来源并非后台的，或者是一些文案管理的列表，并没有必要做数据的区分；以是在开拓的时候，还须要在每个列表列出解释，是否利用；这个逻辑实现的确是相比拟较繁芜的，全体权限系统可以相称于一个小型项目了，这个需求我大概写了一下功能点，有须要的小伙伴可以再问我要。
五、总结
权限还是一个可大略可繁芜的系统模块，但是还是要按照需求，进行设计。
熟习产品体系跟需求后，提出的方案才能更贴合、更有说服力，才能真正办理问题；以是也建议，对权限系统感兴趣的话，有空的时候多研究一下钉钉、飞书这类型的软件，虽然并不能完备复用，大厂的办理方案，每个模块乃至于每个文案内容，都凝聚着一全体技能团队的心血，还是很值得我们学习的。
本文由 @yimi 原创发布于大家都是产品经理。未经容许，禁止转载
题图来自Unsplash，基于CC0协议
