编辑导语：权限管理是所有后台系统的都会涉及的一个重要组成部分，在管理后台中对于权限的标准需要准确地把握，并且根据各种需求进行设计，达到最终目的；本文作者分享了关于权限系统的设计，我们一起来了解一下。

写在前面，为什么要写权限系统的设计呢？

因为每一个项目，有管理后台，90%会有权限管理。在我自己历史以往的项目，其实对于权限始终是一个相对表面的认知。直到我去年研究了钉钉的管理系统、以及今年做了产品重构，让我对权限有了一个深度的认知。

一、权限是什么

我对于权限的理解，一开始是一个账号，管理着后台的某些模块；这个时候，权限很简单，他是一个账号列表，可以编辑账号信息以及设置账号查看菜单，即账号yimi可以管理订单列表。

后面接了一些门店端的项目，在区分菜单查看上，也加上了数据区分，即账号yimi可以管理**门店的订单列表数据；上面这两项，我觉得可以基本可以支持中小型的项目是足够使用的。

然后更深一个层级的，当你接了一个大型的项目，你的后台管理员是一个集团的人，或者是上百人，这个时候一个账号区分是远远不能满足的；也延伸了在做CRM系统的时候研究了钉钉的逻辑，权限不仅仅是开通一个账号（仅有账号+密码）这么简单，权限是对于不同部门的人的管理。那么这个时候会将账号跟菜单权限独立开来。

账号即部门下面的某个成员，可通过手机号作为唯一标识。菜单权限按照不同角色去区分，财务有拥有什么菜单、采购拥有哪几个菜单。

听到这里，权限就涉及了：部门、成员、角色、菜单。那我会觉得，权限可复杂可简化，其实无非是人管事。那么不同的权限设计会有什么区别呢？

二、最小权限设计

最小的权限设计，如下图所示，有登录账号、密码、以及菜单勾选。其实还有个XS版本的，即仅有账号，无菜单权限分隔。

最小权限设计-图示1

那什么情况会使用这种最小的权限设计，我个人的理解是小型的项目，或者说客户内部运营结构相对简单；这个时候需要注意几点，第一个拥有整个菜单即拥有菜单所有操作，第二点是没有数据隔离，即每个拥有菜单权限的管理员查看内容一致。

对于需求梳理如下所示：

三、中型项目权限设计

中型大小的项目，类似于多门店、或者是负责角色不同，同个模块需要查看不同数据、进行不同的操作。如下图所示：

中型项目权限设计-编辑管理员-图示2

中型项目权限设计-编辑角色-图示3

相对于最小权限设计，你可以理解为菜单+账号的拆分，并且在菜单的基础上，扩展了操作权限；也通过角色的区分，扩展了数据权限，此时的权限=菜单权限+操作权限+数据权限。

相对于上一个会复杂很多，为什么我前面会说建议按照产品体系，再去做这一套中型的权限系统？

一方面，众所周知是由于开发工作量以及难度，对应报价会高；另一方面是，这个的复杂度也提高了他使用难度，如果是没有这种业务情况需求(类似于多门店、或者是负责角色不同)，就不建议用了。

最后也是最重要一个方面，针对不可持续性产品的说明：不断向软件增加功能，是不可持续的。增加复杂性意味着遗留代码越来越沉重，导致产品维护成本越来越高，而且也越来越难以灵活应对市场变化；这个道理我想不仅仅适用于用户前端，对管理后台也同样适用。

对应的需求梳理如下：

四、大型项目权限设计

大型项目的权限，最大的一个变化，是有部门组织架构，不同部门的人使用系统，即将管理员管理拆解为部门管理+成员管理，但是又不仅仅于此。

在一个接入审批的系统、或者CRM中，往往数据是相对独立的，可以按照部门组织架构数，去区分数据的权限。如下图所示：

大型项目权限设计-部门组织架构-图示4

如果说，中型项目的数据权限是按照门店或者区域划分，那么部门树则是数据权限的另一个维度。按照创建者所在部门，将这条数据归属于某个成员某个部门（此处还要考虑成员存在多部门的情况），同个部门间数据独立，而主管可以查看所有人的数据。

则这个数据划分，并不适用于后台管理的所有列表，例如用户列表、订单列表此类数据来源并非后台的，或者是一些文案管理的列表，并没有必要做数据的区分；所以在开发的时候，还需要在每个列表列出说明，是否使用；这个逻辑实现的确是相对比较复杂的，整个权限系统可以相当于一个小型项目了，这个需求我大概写了一下功能点，有需要的小伙伴可以再问我要。

五、总结

权限还是一个可简单可复杂的系统模块，但是还是要按照需求，进行设计。

熟悉产品体系跟需求后，提出的方案才能更贴合、更有说服力，才能真正解决问题；所以也建议，对权限系统感兴趣的话，有空的时候多研究一下钉钉、飞书这类型的软件，虽然并不能完全复用，大厂的解决方案，每个模块甚至于每个文案内容，都凝聚着一整个技术团队的心血，还是很值得我们学习的。

本文由 @yimi 原创发布于人人都是产品经理。未经许可，禁止转载

题图来自Unsplash，基于CC0协议