SaaS产品方法论：用户角色与权限自定义

上周四在产品群里，有上海小伙伴提出了用户权限设计的疑问，他和技术经理各执己见，争论的核心是用角色限定权限（固定约束），还是支持在角色之外灵活定义权限。

这个问题表面上是在讨论功能需求，本质上是考察团队对业务是否熟悉，以及产品经理对业务流程进行抽象化梳理之后，归纳总结提炼出关键节点的能力。

日常中使用的C端产品偏多，让我们已经习惯，在虚拟的社区生态里拥有唯一的角色身份，角色（身份?）给我们固定的权限。比如在淘宝上，我们作为消费者，淘宝的PM不会无缘无故给消费者配置商家的收款功能，场景都发生错乱了。在知乎，知乎的PM同样不会给你配置随意删改其他内容创作者回答的权限。一个萝卜一个坑，安排得明明白的，某种意义上其实也是社会的运转法则。

以虎蛙的蓝领送工SaaS产品来拆解举例，熟悉劳务中介公司业务经营流程的同学都清楚，如果要服务劳务中介，过程会比较复杂，涉及到的不同角色多，工作流程跨度大。

产品刚立项，在开始做市场调研前，我们明确了to B产品要输出的价值最终只有两个，二选一，不是绝对的舍弃，而是后期决策时有明确的侧重点。要么产品为客户提供“开源”价值，帮客户通过技术手段创收，要么帮助客户“节流”，降本增效，减少内部资源损耗。

“在哪里产生价值，就要在哪里收费”。理解产品提供的价值属性后，可以把你日常接触到的的SaaS产品梳理一遍，你就能像投资人一样，快速判断同等体量下不同行业的企业服务产品，它可能的未来市场爆发力与潜在价值。任何事物追根溯源要回到本质去看，产品提供的价值出发点在未来决定了它的天花板。

回到正题，我们花近3个月的时间，摸底整个劳务中介市场，从行业到从业个体，从B端的所有部门参与者到C端求职者，对于所有可能的业务场景基本有了大致的了解，不敢说全面充分，目前在我们实际的客户使用过程中仍然能收到客户反馈的特殊场景需求，可见产品是动态的流体，需要不断的与时俱进。

直白的说，面对调研结果，我们当时焦头烂额。唯一的好消息是，确定了赛道的方向选择是正确的。方向对了，我们就吃了定心丸，但是这个行业场景的混乱、业务流程的粗糙以及客户对信息化产品的操作水平，都几乎超出我们的认知下限。虽然我们提前给团队做了心理预期，知道人力资源行业相较其他行业，信息化触网的程度会迟缓5-6年，却没想到细分场景下蓝领赛道上，客户们对于网络的理解都还停留在基础认知上，距离业务数字化SaaS系统的认知还没起步（蕴藏着巨大机会）。也能理解，行业的变革是需要天时地利人和的，基础设施的完善与行业下半场的周期变革也是经历了漫长的铺垫。

首先我们帮助行业定义了3个大场景：制造型的普工/技工、传统服务业（酒旅餐饮商超大卖场）、新经济业态下的服务业（快递物流仓储）。只有全链条打通，才能成为一个高效工具系统。我们把产品价值定位在“开源”，帮助客户解决供给问题，面向B端收费，间接服务C端。

其次，在对内的业务流程梳理上，我们提炼出5个关键角色，其中有原本就存在的角色，也有我们创造出的新角色，包括管理员、行政、财务、驻场和劳务经纪人。确定五个固定的角色，配套关联对应的权限，一方面能够降低客户的学习使用成本，一方面也在帮助客户梳理公司的岗位职责，战略就是分类。产品设计者的核心职责也是分类，帮助客户（用户）提前筛选甄别，给他们一个直接可用最适合的方案。

正常的业务流程，产品按照固定角色去提供对应的操作权限，是已经可以满足客户的使用诉求的。但是在特殊的情况下，比如公司某个人的岗位是跨部门的，比如总助，这个人的角色就会需要产生自定义组合。在我们实际发生的客户使用案例里，就有出现过这类需求，所以我们团队用一个v6.4.0大版本专门来实现权限的自定义，原来的5个角色是基础设置，支持客户在后台创建新角色，来单独为某个人配置特殊权益。角色功能权限的设计，尽量保证角色之间不重合，最少的角色设置，可以组合出足够多的用户权限。

针对标题的讨论，建议的解决方案是：以固化的角色身份为常规配置，支持对个体进行权限自定义组合，权限来源是系统提炼出的业务逻辑，不开放从无到有的创造。

如果出现复杂的场景下角色权限无法区分，建议不要把目光放在功能上，先去梳理业务逻辑。业务流程标准化之后才能实现信息化，系统是基于规则运转的自动化机器，不要在非关键的表层找解决方案，去核心层拆流程。

提升自己在对问题抽象化的能力，归纳总结，找出那堆杂线里的线头，这是庖丁解牛的真本事。

孙子兵法云：夫兵形如水，水之行避高而趋下，兵之形避实而击虚。水因地而制流，兵因敌而制胜，故兵无常势，水无常形，能因敌变化而取胜者，谓之神。