pm|产品领域的元宇宙：aPaaS产品解构( 四 )

在data层面，往往是记录（record）的权限。比如“椅子采购系统”的超级管理员应该可以看到并修改全部“椅子实体”数据，而采购助理可能只能查看、编辑自己提交的记录，不能编辑别人创建的的“椅子采购记录”，这就是record级别的管控，一般是用于区分业务内的不同岗位、角色。所以对于aPaaS的权限系统来说，至少要设计2个层次的权限：

领域、实体层面的profile权限
数据、记录层面的role权限

在这个基础上，还有更多的场景需要考虑，比如：

人员变更
申请、审批
冲突、叠加
过期、续期
授权、回收
…

如上，单单一个权限模块，可能就有几十个feature需要实现，而一个好的权限模块，是一个aPaaS产品的基石，一定程度上决定了用户复杂度和量级天花板。
四、aPaaS产品的PM在设计什么从aPaaS产品PM视角出发，想回答“aPaaS产品设计和常规产品设计的不同“，就不得不从PM的核心工作要素谈起：

文章插图
从用户来说，纯无代码aPaaS产品的用户，一般是业务运营人员。这个群体的特征是：

离业务近，会有大量的业务洞见和需求
无代码能力，需要可视化界面甚至实施的辅助下完成搭建

特征1决定了：用户会有大量的长尾需求特征2决定了：aPaaS编辑器的可用性极大影响迁移成本所以，我个人认为，aPaaS产品经理的关键在于如下三点：

在大量的长尾需求中，抽象并找到价值排序
按照价值排序，不断支持aPaaS产品的能力
优化编辑器和配置成品的体验

从aPaaS产品的能力来说，这里面最重要的，私以为，是“灵活度”。上文提到，灵活度来自于配置能力。而配置能力的关键在于能把“不变的逻辑”元数据化，同时把“灵活可变的逻辑”配置化、描述化。具体来说：

支持越复杂的object，比如数值、金额等，就能支持更多种数据进入平台
支持的action越多，比如搜索、筛选、排序等，可配置的功能类型就越多
支持的layout越多，比如移动端界面、PC端界面、组件化，界面可配置能力越强

这里面，object是基础，action经过扩充和编排可以流程化成为工作流，整体又通过灵活的多租户、多角色权限体系来管控，共同构成了aPaaS平台的灵活性。这样分析下来，aPaaS产品经理做的工作，实际上是把研发流程变得可视化、配置化。从一次做一个SaaS产品，到一次做一批SaaS产品的配置能力。这需要出众的实体抽象和领域设计能力，以及良好的体验品味。
五、总结aPaaS产品经理，是软件行业蓬勃发展和企业数字化进程下对软件要求不断提高的产物。从需求和供给的角度上来说，aPaaS产品的发展都将是一种必然。希望所有的软件相关PM都能了解这个领域、研究这个领域，这样就相当于站在“产品之外”来设计产品，会有更高层次的抽象意识。
但反过来说，aPaaS本质是一套生态，如果大家都在做自己的生态，又不能互通，就会导致生态缺乏完整性，那么也就失去了价值。目前的TOB市场上，salesforce、企业微信等都有自己的生态，但国内大量的企业还在数字化进程中，最终这些生态何去何从，能建设到多大，仍存在较多变数。所以aPaaS领域最终会演化成怎样的模式、有多久的周期，仍是未知。理性地讲，aPaaS要抽象起来，或许能装下整个宇宙。
但是，抽象的成本也是无限增加的。需要兼具智慧和勇气的各位不断探索，既不能把aPaaS做成强大但没有场景的“屠龙之术”，也不能钻牛角尖闭门造车，让产品很难复用。“抽象归纳和具象定制平衡”的设计哲学，在aPaaS领域成为了核心问题，但在其它产品设计领域，也尤为重要。