数据型产品的用户管理相较于其他互联网产品的来说更加复杂，本文作者分析了用户管理的逻辑，并且总结了自身经验，给数据型产品经理们整理了以下几点建议。

随着近年来大数据、人工智能、云计算等新兴技术的火热及逐步成熟，数据的重要性再次引起了人们的重视，从底层的核心数据库，到中间层的数据计算及数据服务，以至于顶层的数据调用，数据型产品层出不穷。

与以往IT时代相比，DT时代的产品不仅业务逻辑更多，而且数据资源的管控要求更加严格，数据资产的变现是每个企业都在谋求的发展之路，因此，关于数据型产品的用户管理，往往比之前的互联网产品更为复杂，想要做好，实属不易。

用户管理类似于一个系统的基础设施建设，重要程度虽不及其他核心功能，但却是必不可少的其中一环，而且随着产品内容和逻辑的增多，用户管理发挥的价值会日渐体现出来。本文以我做过的一个数据产品为例，浅析其中用户管理的逻辑和踩过的坑，以供参考。

用户管理三大模块

由于公司有统一的域库存储用户信息，包括入职离职人员的信息更新，因此我们此处的用户管理是在已有用户群（并且可实时同步数据）的基础上进行角色权限的把控。此模块架构如下：

整个模块为用户管理，下分三块分别是：

1. 部门组织架构：所有部门人员信息的在线展示以及对应的人员列表，此处同步公司域库数据，附加了当前在线状态的显示；
2. 角色权限管理：此处分为角色组的建立以及对应权限的把控，角色组以及所属成员按需创建和添加，建完之后对应做权限的控制，包含功能权限、资源权限、数据权限、集成系统的访问权限；
3. 权限申请管理：此处是针对权限管控后，用户对无权限资源进行的权限申请处理以及对应的权限赋予操作（权限批复结果会自动生成消息通知，与公告消息相通）。

如何做好权限管理

上述组织架构和权限申请部分基本很容易理解，逻辑相对复杂一些的当属角色权限管理这部分，先看一张关系图：

做好权限管理有以下几个重点：

1. 人员组成要灵活

这部分的人员组成不一定是按照岗位角色来的，有可能是跨部门跨岗位形成的自定义角色组，因此不能直接套用之前的岗位角色，需要可以创建新的角色组，当然角色组多了还可以给角色组分大类，以便更清晰一些。

2. 权限覆盖要全面

权限常规来说可以分为功能权限、数据权限、资源权限，当然根据产品不同也可能有更多的权限分类。大到每个顶部导航模块，小到页面上每个功能按钮，都属于权限的范围。与此同时资源内容的全量呈现还是部分呈现就涉及到资源权限的管控；有的数据我能访问，你不能访问，这种权限的区分把控在于数据权限的设置。

在上述案例中，我们的数据权限采取的是黑名单制，顾名思义就是我选择谁不能看到哪些数据，默认情况下是所有人可以看到所有数据，这个可以根据具体情况进行正反向设计。

比如大部分都是可看的，不可看的是少数，那么就用黑名单方便一些；如果大部分都是不公开的，只有少数是公开的，那么白名单会更方便一些，因情况而异。

3. 权限把控要灵活

正常来说角色权限管理对于一个需要此方面把控的产品来说就像空气一样不可或缺，虽然我们不常注意它的存在，但是用的时候一定要确保其规范、安全、可靠。

之前我们在做的过程中有过这样的一次经历，一般被赋予了某个角色的人员具有把私有表转为公共可见表的权限，而对应的删除操作，当时开发则做成了谁建的表谁删除，其余人即使有同样权限也不能进行删除这样的模式。

在一次不经意操作中我们发现共同拥有这个权限的人删除不了别人建的公共表，我跑去告诉同事说这张表是他建的，需要他删除，然后我就去了洗手间，但顿时感觉这样的逻辑存在问题，假使十个人建了十张表然后都转为公共表了，那么如果这十个人离职了，这些表还非这些账号不能进行删除操作了吗？（不包含开发同事从数据库删除的情况，因为我们设计产品的最终目的就是减少进行数据库的操作，最大化方便使用并且逻辑合理）

因此意识到这一问题后，我们小组立即进行了讨论并且及时做了更新。虽然这样也存在不是表的主人删除他人表的可能性，但通常来说：

第一，这样的情况相对较少；第二，对应的解决方案是可以通过把删除表的功能只赋予一个最高管理员，其余角色不能随意操作，这样来管控。总之要保证权限把控的灵活性，这是第一原则。

实际情况其实更复杂一点，因为我们还涉及私有表可删除（所有人都有的功能）、可移动到公共表（部分被赋予权限的人员具有的功能，无权限人员不显示此操作按钮）；公有表的查看（所有人都具有的功能）、公有表的删除（部分被赋予权限的人员具有的功能，无权限人员不显示此操作按钮）等，那天本来约了人，但为了调这个并和开发讲清楚，赴约都临时取消了（捂脸）。

4. 权限申请要智能

权限申请其实和之前的权限把控是对应的，有的权限是把控之后，相应用户看不见被屏蔽的痕迹，也没有申请入口，而有的可以做成暂无权限的提示，同时提供申请入口。

在上述案例中，我们在部分屏蔽场景中提供了权限申请的入口，当用户点击申请后，会自动在后台接收一条权限申请的消息，上面显示申请人基本信息、申请源、申请时间以及批复操作（通过/拒绝），具体的申请处理流程如下图：

在这块令我比较欣慰的一点是我们的技术同事把权限开通做的相对智能化了一些，即在通过权限申请的时候，相继会产生2条动作：

• 一个是在上述的角色权限模块自动开申请用户开通相应权限（包含功能权限、数据权限和资源权限）；
• 另一个则是在开通流程走完之后把申请反馈通知发送到该用户的消息账户，这两个任务完成后，即权限申请“通过”，整个流程基本在1秒内完成。当然即使开放后的权限未来也有可能被收回，所以这块的灵活性是毋庸置疑的。

总结

正如开头所说，角色权限管理并不出众，但属于必不可少的基础设施建设，从0到1的搭建也会涉及很多坑，需要耐心细致的梳理清楚相关逻辑，每个细节方面都尽量不要遗漏，这样才能使得出来的产品严谨而规范，尤其是权限方面的把控，效果和程度不容忽视。

若同一公司内很多产品都涉及这块，其实是可以封装成一个相对通用的产品方案，以免重复造轮子。

当然根据产品各异，繁简程度不同，角色权限管理也是可大可小，在满足自身需求的情况下如何做得更加灵活、扩展性更强，更加高效实用，是搭建本模块的基本原则，希望大家在今后实际工作中能不断精进。

一起加油！

#专栏作家#

慕斯姑娘，微信号：musiguniang，公众号：产品那些年，人人都是产品经理专栏作家。关注金融科技和大数据领域，擅长产品规划和落地。

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

题图来自 Unsplash，基于 CC0 协议