原创： Kevin改变世界的点滴 Kevin改变世界的点滴 昨天
We're here to put a dent in the universe. Otherwise why else even be here?
——乔布斯
近期在负责角色与权限需求，分享后台产品经理在系统考虑角色与权限的设计方法。
角色与权限在生活中其实非常容易理解，一个角色对应的权限是什么？最为直接的案例：会员体系。
例如健身房中的普通会员：健身房使用权
健身房中的VIP会员：1对1私教顾问+健身房使用权+营养套餐
不同于面向普通用户的角色权限，后台产品经理更多考虑的是在公司内部业务运转下所需要的角色，和相应角色需要的权限。
角色与账号
使用后台系统的人员我们称呼为业务人员。他们需要通过系统完成某样任务操作，才能保证业务的正常流转。
账号的概念在后台系统中是以真实用户为单位。一个用户在一个业务流转下，只需要用一个账号就可以达到相应的权限操作。
类似超级管理员账号，其实他至少会有2个角色存在。角色1是普通用户，角色2则是管理员角色。为此，我们在设计角色与权限的时候，首先要考虑的是账号概念。针对后台系统中，账号的管理机制是如何？内部用户如何开通账号，外部用户如何注册账号？
基于账号所在的部门、账号使用人员的职位、账号当前的状态，做出相应的字段进行管理，方便查找和筛选账号。
角色与权限
上图说到，一个账号可能对应多个角色。我们在权限设计中，最低的纬度就应该是角色。不能允许比角色还小的颗粒存在。如果一个账号A权限>账号B权限，那么只能是因为账号A存在多个角色。
账号设计中切记保持最小权限颗粒度：角色
如果没有角色的概念，产品经理需要把系统中每一个click或页面考虑权限设计。当系统从0到1搭建到1到10的扩展期，涉及的页面和业务会持续增加，产品经理很难把握每个账号的权限标准。
如此多的页面事件和click，我们需要一个角色的纬度将权限与角色捆绑起来。
角色在业务的流转中也是很具体的人物。例如电商系统中的客服流程
上诉的业务流转是一个典型的需求收集流程。当客户投诉相应的问题时候，客服可以交给组长，如果是产品缺陷问题可以汇总到产品经理。角色的出现清洗的界定了每个业务需要的权限操作。
角色与权限什么时候考虑
在搭建后台系统中，核心解决的需求还是来自业务的需求。后台系统作为支撑公司产品的基础系统，我建议产品经理不要一开始就考虑角色权限。而是考虑如何快速满足业务的需求。
如果没有预约，就先做预约系统。如果没有客户管理，就先做用户管理。如果来不及，就先用第三方
后台产品经理的kpi，不同于C端产品里的考虑如何拉新、促活，一个后台产品经理的功力深厚：解决业务需求。
业务人员能够没毛病跑起来，并且提高业务效率，才是一个出色的后台产品。
好啦，今天的分享就在这里。我争取每周分享2篇
近期专题
产品助理（专员）、产品经理、高级产品经理、产品总监是什么样子？
另外我个人第一本书籍《从零到壹：PM改变世界的点滴》电子档正式上线这本我归纳222篇产品原创，涵盖产品经理面试、算法、交互等不同维度的内容，如果你感兴趣可以打赏后留言你的邮箱。我会在每天中午12点左右发送到你邮件中（希望大家勿外传支持，支持版权）。如果你需要预览书籍大纲，可以跳转链接
