为什么面试 SaaS 产品经理一定要问权限管理？

前言

今年面试了不少产品经理，对于简历上有 B 端产品经验的产品经理，我一定会问的一个问题是他们的权限管理模块是如何设计的。为什么一定要问这个问题呢？本篇我们就来看看权限管理如何反映一个 B 端产品经理的能力。

基本的权限管控理解

对于初级产品经理面试，典型的问题就是有没有 RBAC 的权限管理设计的概念。实际上，在面试会发现有不少刚入门的产品经理可能连 RBAC 是什么都不知道，尤其是那些做后台管理产品设计比较的产品经理。

RBAC，Role Based Access Control，基于角色的访问控制。

在使用 RBAC 进行权限管理之前，大多都是下面两种权限管理方式：

• 系统固定一个管理账员，一个普通账号，管理员有高级的权限，普通账号权限低一些。权限都是写死的，要调权限需要“跪舔”程序员改代码或者修改数据库。

• 按照账号授权，每个账号单独管理权限，通常适用于那种后台使用没几个人的情况。

我们来看 RBAC 解决了什么问题。

上述的依赖程序员改代码或修改数据库的情况，仅适用于小作坊似的产品，根本满足不了 B 端产品的使用场景，这里就不多赘述。我们来看按账号授权的方式有什么弊端。通过下面这张图可以看到，随着账号和权限的增多，基于账号授权将变得非常混乱，导致权限的维护复杂度非常高。

RBAC 解决的就是按账号授权导致的混乱。实际经常维护管理后台的话，我们会发现很多账号的权限是相同的，因此可以把这些相同的权限抽象为角色。比如一个 CMS （内容管理系统）会包括系统管理员、编辑、审核、数据分析等角色。有了角色这个概念后， 就可以通过角色和权限点关联，基于角色来授权。这样，我们的账号就不需要再直接和权限点进行关联了，而是和某个角色关联。由于系统的角色的数量远远小于账号的数量，这样就带来了如下好处：

• 账号只需要和少数的角色关联，维护账号权限的复杂度降低了很多；

• 增加和收回权限的时候，只需要维护角色对应的权限就可以了，极大地简化了权限的管控。

进阶考察：用户组

RBAC 解决了小规模后台实用用户基数的权限问题，但是如果使用的账号数量继续增加，意味着角色数量也会增加，而且在 B 端产品中，一个账号对应多个角色（一个人可能跨岗位职责跨部门工作）的情况也很常见。这个时候，我们又会遇到基于账号管理类似的问题，就是账号和角色之间的关联关系变得复杂起来。这个时候就需要引入用户组来简化权限的设计。用户组实际上就是实用用户组和多个角色关联，然后将账号加入的对应的用户组就能够完成授权。整个结构就变成了下面的样子：

可以看到，用户组的思想其实和 RBAC 是类似的，也就是抽象出共通的权限对象来简化权限分配。用户组的一个例子就是比如我们按职能部门分组，比如财务部门可以建立一个财务组、人力资源部门建立一个人力资源组，然后按组将对应部门的员工划到相应的用户组里面，这样我们可以基于组来维护权限。

对于 B 端产品而言，一般做过中大型的 B 端产品（涉及多个部门业务）且服务的客户规模比较大，才会涉及到用户组的权限设计，所以如果产品经理了解用户组的话说明他至少接触过或做过中大型的 B 端产品。

进阶考察：权限继承

权限继承是什么？我们举个例子，比如我们给财务部的员工统一授予了普通财务这个角色的权限。但是，财务部还会有财务总监、会计、出纳等细分的角色。他们拥有一些相同的权限，但是也会有些许差异。这个时候，我们可以通过定义父级权限来满足相同权限的授权，然后通过定义一些下级权限，这些下级权限集成父级权限之外还拥有自己独有的权限，从而满足部分细分角色权限的管理。比如下图中的子角色继承了父角色，也就意味着它拥有父角色拥有的权限，同时它比父角色还多了权限点 N 的权限，这就是子角色独有的细分权限。。

通过权限继承，一方面是可以利用父级权限对财务部的相同权限进行统一管控，另一方面是简化了细分权限角色的权限维护工作。

有权限继承产品设计经验的产品经理，意味着他已经做过了大型企业的产品设计。因为，大型企业才会有比较大的职能部门，这些部门的员工数会达到成百上千人，这就需要通过权限集成来简化部门内部权限细分的维护。

进阶考察：数据权限管理

前面讲到的 RBAC、用户组、权限继承通常是用于功能权限的控制。对 B 端产品，还有一个绕不过去的权限管理是数据权限的管理。数据权限，或者说资源权限，即控制一个账号能够访问哪些资源。举个例子，对于 CRM 系统来说，有些公司会按地区划分拓客范围，因此在客户公海中，可能会按地区限制市场营销人员能够查看的客户档案。比如北京的市场营销人员就无法查看上海的客户档案。再比如，对于同一项数据，还会精细到限制账号能够查看或者编辑的字段，典型是合同管理中，一份合同对于商务可以看到价格，而对于其他人员可能不能查看价格。

对于按范围控制数据访问权限的，通常在产品设计中需要定义好最小划分的范围。比如上面讲到的 CRM 系统中，地区你可以划分为城市，也可能可以按大区划分，最终取决于业务管理模式。当然，好的产品经理就可以利用类似 RBAC 的模式，支持自定义区域来组合城市既满足按城市授权的需求也能够满足按大区授权的需求。

同样，数据权限管理也可以基于角色来简化授权管理，如果涉及到的权限点比较多的话，引入角色是比较合适的。比如对于合同的字段权限管理，我们就可以按合同的环节，分为商务、项目实施、售后、法务几类角色来限制不同角色能够看到的合同的字段。

数据权限更多地考察的是产品经理对数据敏感的设计能力。通常来说，面向集团企业的 B 端产品必须需要考虑数据权限的设计，尤其是对于上市企业而言，其数据是十分敏感的，一般都会限制员工访问的数据范围和某些敏感数据项。

面试应对

如果你没有做过后台管理系统的权限设计，推荐先了解一下 RBAC 的思想，然后自己尝试着做一个 RBAC 的权限设计原型，并整理出对应的产品需求文档，这能够让你应对大部分的 B 端产品经理岗位的面试。

如果是应聘大中型的 SaaS 公司的产品经理，那么你需要对用户组、权限继承和数据权限管控有比较深入的了解。个人推荐是拆解一些大型的 To B 平台，比如阿里云（阿里云的权限设计非常全面，但是有点重）、钉钉、纷享销客等等。申请一个体验账号，然后去看看他们的权限系统的设计，并整理成相应的文档，会让你对权限的管理理解更为深刻，也能够轻松应对关于权限管理的面试。

产品设计建议

B 端产品，通常一开始就需要考虑权限系统的设计。因为，你的产品推向市场的时候，企业客户很难接受一个不分权限的系统 —— 这意味着整个企业的业务无法管控。对于具体的推进节奏，可以先基于 RBAC 完成功能权限的管控，后续再根据产品的需要细化或升级权限管理系统。当然，如果你的目标客户本身的业务就需要有数据隔离（不同业务单元的人员无法看到彼此的数据）的管控要求，那么数据权限也需要一并考虑。

当然，权限管理越精细就意味着权限的维护越复杂，如果一个产品涉及到企业的多项不同的业务（比如人力、财务、生产），那么最好是有子系统（或子应用）的概念，权限可以在各个子系统中单独管理，这是因为一般不同的业务单元的人员不会跨业务系统使用系统功能。这样也可以避免设计一个庞大的权限管理系统，导致复杂度过高而难以使用和难以维护。

总结

本篇介绍了 权限管理系统常见的几种模式，包括 RBAC、用户组、权限继承和数据权限管理。权限管理作为 B 端产品经理面试常问的问题，建议大家可以多参考其他优秀 B 端产品的权限模块的设计，从而提高自身对权限管理的理解，更好地应对面试和产品的权限模块设计。