“APP”分分合合的本质｜日X：81

今天，有同事在群里问，为什么咨询师和来访者不能再同一个app里操作？这看起来是一个常识性的结论，但可能没有多少人真正想过背后的原因。

引用《人人都是产品经理 2.0》中的观点：

看不同用户角色背后的自然人重合度高不高。

如果高就倾向于一个端搞定，如果低就倾向于分离。

于是，我拍脑袋分析了一下自家的产品：
咨询师角色和来访者角色有重合的自然人，但是不多，而且咨询师更多的不会去找心理咨询而是找督导。如果两个角色公用一个app，就出现一些问题，比如：咨询师的订单和来访者的订单模块，虽然都叫我的订单，但具体的功能点是不一样的。咨询师的订单分为，待处理，已接受，已拒绝，已完成。来访者的订单分为待支付，待审核，进行中，已完成，已取消，已退款，因此他们订单的内容和操作都是不一样的。混合在一起，对某一方的角色来说，另一方的信息和功能是无用的，干扰的，令人混淆的。如果是让不同角色看到的东西不一样，那盘算下来，不一样的东西有点多，甚至框架都差得很远，对技术开发，维护，和版本管理都会有问题。

另外，再回头看看另外一个产品，豆瓣app。
几年前，豆瓣有很多个小app，最后还是合成了一个大app。我猜想，因为豆瓣的大部分自然人用户都有多个角色，比如一个人喜欢看电影和看书，如果你把豆瓣电影和豆瓣读书分开，其实对这个用户的来讲，整体感受是不好的，而且，这些信息内容可能存在很强的相关性，比如你看了一部的电影的介绍，发现这其实是一本书改编，就会想着去找原书介绍看看。另外，运营多个小app的整体成本肯定是大于运营一个大app。

最后，说一个我比较熟悉的小众产品，一个线下活动平台Someet。它的用户角色，也有两种，一个活动发起人，一个是活动参与人。他们的思路则是让两种角色，在同一个微信服务号里进行相关操作。因为，这个平台上很多发起人都是从活动参与人发展来的，并且，即使成为发起人后，也会参加其他发起人举办的活动。

最后留一个问题：滴滴为什么要让滴滴企业版，成为一个单独的app？