后台权限管理设计（手把手带你设计B端产品后台）

在系统设计中，账号的用户权限设计是最令人头痛的，但又有着至关重要的作用。本文就B端产品后台的用户权限该如何设计展开探讨，总结了自己在实战中的相关经验，希望对你有所启发。

前一篇文章账号篇跟大家聊了聊产品后台的基本逻辑和账号体系设计相关的经验。本文继续聊最让人头痛的用户权限设计。

开始之前，先回顾一下后台信息的分类，对于理解用户权限设计有至关重要的作用。后台最核心的对象就是数据，B端后台一切的操作行为，本质上是对数据增、删、改、查的操作。

数据可以大体分为：

• 产品数据（文图音视等数字内容、实体商品、算法模型等）。
• 用户信息（个人资料、账号、权限、组织等）。
• 用户行为数据（PV、UV、点击、用户反馈等）。
• 业务数据（如用户的订单、商家的库存、发布的内容等）。

带有用户信息的账号访问、使用服务商提供的产品数据，在整个过程中会留存大量的访问、点击、跳出等用户行为数据，用户购买产品、发布内容、提交表单等行为会产生业务数据。

一、系统权限的分类

根据笔者的经验，后台的系统权限可以大致分为三类：

1. 功能权限：该用户在系统中，可以使用哪些功能模块，使用哪些具体的功能。
2. 数据权限：该用户在系统中，可以访问哪些数据，是否可以对数据进行增、删改、查等操作。
3. 组织权限：对于B端产品来说，往往也涉及到组织架构。该用户在不同的组织和不同的位置上，天然具有某些权限。比如在OA系统中的审批权限。与功能和数据权限有一些交叉，但是比较重要，所以单独归为一类。

为什么说权限系统复杂呢？有过权限系统设计经验的同仁可能深有体会。

首先，用户前端、用户后台、系统后台都有自己的一套权限体系，而且三者之间也会存在一定的关联关系。三个系统的权限交织在一起，相互依存、相互限制，会导致整体的权限系统极其难以设计。

其次，功能权限、数据权限和组织权限同样是密不可分的。在一个组织特定位置的用户，其权限一定涉及功能权限和数据权限。访问功能的同时，一定会涉及到调取数据。而数据的访问，也必然也要依赖数据查询相关功能的支持。

最后，权限系统是要为业务服务的。需要根据业务合理设计权限系统，为相应的账号赋予满足业务需求的权限。但是不同的业务有不同的特点、流程、客户&用户需求，那么权限系统必然也会因此产生各种个性化、定制化的需求。

二、系统权限的设计原则

既然后台权限的设计如此复杂和困难，那么我们如何掌握设计后台权限的方法论呢？

笔者先介绍几个设计原则，然后各位读者可以结合后续的具体方法论进行实际的体会。

原则1 权限系统要为业务服务

这一条原则不证自明，也是最重要的设计原则。因此也自然要求涉及权限系统之前，一定要把业务逻辑梳理清楚。

原则2 权限系统设计一定要解耦合

无论在产品设计上还是技术架构上，务必注意功能权限、数据权限、组织权限之间和内部的解耦合。如果设计和技术架构不合理，将不同的权限耦合在一起，可能在未来业务变更的时候，出现大坑。

比如，如果将业务入口的权限和其内部具体功能模块的权限耦合起来。一旦页面需要调整业务入口，那么其内部功能模块都可能会受到影响。

原则3 权限系统设计要有兼容性

业务是不断变化的，其相应的权限也一定会随之变化，因此权限系统设计要保证兼容性，避免因为写死、没有为新功能留后路等导致无法适应业务的发展。

原则4 权限系统设计要尽量简洁

奥卡姆剃刀原理告诉我们，“如非必要，勿增实体。”权限系统本身就是复杂性很高的系统，每增加一个要素，其设计和开发、测试复杂度都会激增。因此在满足解耦合和兼容性的基础上，权限系统设计要尽量简洁。在成本和效率、长期和短期等之间寻找平衡。

原则5 从前台到后台依次设计

建议从用户前端、用户后台、系统后台的顺序，从前到后、由易到难的顺序设计权限系统。从简单的权限开始设计，上手会比较容易，而且在设计过程中也能为更复杂权限的设计提供思路。而且一旦设计出现问题，局部优化或推翻重构的成本会更小。

各位读者可以看出，以上的五个设计原则其实也是产品设计原则通用的一些原则。符合用户习惯、易用性、可读性、即时反馈等设计原则权限系统设计同样要遵守。 不过在笔者的过往经历中，认为以上五个原则是最重要的且容易踩坑的地方，因此特意拎出来加以强调。

三、系统权限的设计方法

权限系统的设计一般可以分成如下几种思路：

• 完全写死。对于非常简单、基本不需要迭代的系统，可以直接写死权限。
• 设置可选模板。固定几种权限角色，比如超级管理员、管理员、一般用户等，直接将模板关联给账号。适用于权限划分清晰、业务相对简单的系统使用。
• 可配置的模块化权限系统。将权限通过梳理、归纳，设计为一个个独立的可配置项，允许为每个账号灵活配置权限。该方法最为灵活、普适，但是设计和开发难度最大。

笔者选取难度最大的可配置的模块化权限系统，并且综合功能权限、数据权限、组织权限，讲解权限系统的设计思路。

掌握了最复杂的情况，其它相对简单的权限系统设计自然手到擒来。

1. 系统权限分析

在着手设计之前，建议首先对系统的业务流程和需求、并结合权限进行完整的系统权限分析。

如何合理地分析系统的业务流程和需求，计划放到后续的业务系统重点讲解。如果该系列大家喜欢、且投票踊跃，笔者会坚持继续更新。 分析脑图的样例如下。

脑图中涉及的概念解释如下。

• 部门：服务客户的组织架构，可能存在多个层级。部门内的员工账号关联到对应的部门下，以和实际的组织架构保持一致。
• 角色：每种角色作为一种权限设置的集合。可以通过为账号配置角色，让账号获得相应的权限。系统：提供服务不同的系统，可能为用户前端、用户后台、系统后台。
• 模块：系统中的功能模块。可能存在多个层级。比如旅行软件，可以分为机票、酒店、火车票出行等，出行又可以分为网约车、租车等。
• 功能：根据业务需求，需要管控功能的最小颗粒度，比如网约车可以分为快车、专车、拼车，以及因公付款、个人垫付等。注意功能拆分一定要遵循MECE原则，完整且独立。
• 数据：某些功能可能涉及到数据的增、删、改、查，比如说账号管理、用户发布内容管理等权限。

需要特殊说明的是，考虑到组织是客户实际存在的组织架构，且有可能用到多个系统。因此把部门作为第一层级。

这样去做梳理，可能对产品经理的全局观和逻辑思维能力要求比较高，但是更符合实际业务情况。最终完成的权限系统兼容性也更强。

如果只负责一个系统，那么也可以以系统为第一层级，先把自己负责系统的权限梳理清楚。

注意如果多个系统是统一的账号体系、且存在一个部门使用多个系统的情况，也需要与相关的产品同时做好同步，保证大家都设计思路一致。否则万一后续要做系统之间的整合，那么重构的工作量会大大增加。

2. 系统权限设计

根据梳理出的权限系统脑图，就可以比较清晰、方便地完成系统权限的产品设计工作。

笔者简单模拟了一个系统权限的线框图，以方便各位读者理解。

首先设计部门列表，根据客户的组织架构设计各级部门的列表和显示重要的字段即可。对部门的操作同样包括增、删、改、查。

然后是部门下的员工列表。每一个员工即代表一个可使用系统的实际账号。那么如何快速为不同的账号配置权限呢？

关键在于角色这个字段的设计。在实际组织中，虽然一个部门内有很多的员工组成，但是可以按照其工作属性进行分类。比如从职级维度，部门长、组长、员工、实习生等等。从职能上划分，财务、会计、销售、售前、售后等等。 有了角色，我们便可以根据该角色在系统中承担的业务范围，为其分配不同的系统权限，避免相同权限的账号要重复配置。

下一步就是角色管理。根据业务需要，可以为该部门在不同的系统中设置角色，以满足该部门员工在不同系统中的业务需求。

为了使用方便，可以提供一些系统中最常见的角色模板，方便客户的管理员直接使用，比如超级管理员、管理员等。

其中比较特殊的是超级管理员，其是一个系统中配置账号的最基本、默认要有的角色。其最起码应当有最全的账号管理权限，以为其它同事创建账号、分配权限。故该角色不应当被编辑和删除。

如果默认的角色模板不能满足业务需求，还可以再新增角色，完成个性化的权限设置。

最后也是最重要的，就是角色具体的权限设置。包括角色名称、角色权限配置、角色备注等字段。

权限配置就是将脑图中拆解的各模块的功能权限和数据权限罗列出来，以为该角色勾选需要的权限。

为了使用方便，还可以有复制角色权限的功能（也可以放到角色列表中），可以直接沿用已有的、近似的角色权限，再进行微调，就可以快速完成一种新角色的添加。

3. 系统权限拾遗

本文主要讲统一的设计方法论，也不宜结合具体的业务案例讲。因为不同业务的差别太大，一旦过于具体，通用性和可迁移性就比较差。

“授人以渔，而不是授人以鱼”，一直是笔者的经验分享之一。

虽然本文看起来可能也没有想象的那么复杂。但是等到结合具体业务执行的时候，各位同仁就能发现很多困扰和难以取舍的点。

就比如做系统权限分析时，功能权限拆分到什么颗粒度？如何做到MECE原则要求的完整性和独立性？

拆得越细，自然越灵活，但是开发成本越高，也越容易出现功能耦合的情况；但是拆得过粗，可能无法满足业务权限的精确管控，后续需要拓展时，就需要考虑到新老数据的兼容性问题。

还有账号的角色变更或角色权限变更的时候，是否要即时生效？

如果需要即时生效，就需要每个功能在执行的时候都要校验权限，系统开销会很高、效率也会很低。

如果只在登录时候访问权限，那么系统权限变更就会存在较大的延迟。

折中的方案可能是定时刷新账号的权限，那么也可能涉及到主动通知系统前端时机的问题。

而且当账号使用过程中出现了权限变更的情况，那么该如何处理？刷新页面隐藏功能还是有新的请求时候报错？

管理员做删除和禁用操作的时候也存在类似的问题。而且删除和禁用的时候一定要判断是否满足删除的条件。

比如删除部门时，要考虑部门下是否还有子部门和账号，如果有是否允许删除？

再比如删除角色时，如果有账号关联着该角色，是否允许删除？如果需要先取消所有账号的关联才允许删除，那么如何方便地批量操作？如果允许直接删除，那么如何方便地为受影响账号分配新的角色？

这些问题，笔者也很难给出标准的、普适的答案，要根据具体的业务情况具体分析。

本次关系到系统权限的设计经验就这里。相信大家都能看到笔者的用心，不仅毫无保留地介绍经验，还贴心地自己画了线框图，以帮助大家理解。码字不易，请大家投票支持，给笔者继续分享下去的动力！

为我投票

我在参加人人都是产品经理2022年度作者评选，希望喜欢我的文章的朋友都能来支持我一下~

点击下方链接进入我的个人参选页面，点击红心即可为我投票。

每人每天最多可投35票，投票即可获得抽奖机会，抽取书籍、人人都是产品经理纪念周边和起点课堂会员等好礼哦！

专栏作家

一直产品汪，apmdogy，人人都是产品经理专栏作家。逻辑型产品经理，致力于将科学思维与产品经理方法论结合。关注人工智能、教育领域，擅长产品孵化、需求挖掘、项目管理、流程管理等产品技能。

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

题图来自Unsplash，基于CC0协议。

该文观点仅代表作者本人，人人都是产品经理平台仅提供信息存储空间服务。

,