又是一场旷日持久的评审，经过整整一上午的沟通讨论，才算各方就新版本的一个功能设计达成一致。虽然同样是面向人提供服务，但是在设计的过程中，ToB的产品和ToC的产品还是会有很大的不同，一个又一个大坑埋伏在前进的道路上，需要时刻注意！趁着今天刚刚经过激烈的讨论，简单整理一下。陷阱1：角色分离要说ToB产品和ToC产品在设计上最大的不同，小不认为排第一的就属角色分离对于ToC产品来说，我们只需要面向单个用户提供服务，创造良好的体验即可，而对于ToB的产品来说，产品是面向整个组织提供服务的，而且很多时候，这些服务面向的群体之间存在千丝万缕的关联和不同的权责划分。一般来说，ToB产品中至少会包含一个管理员的角色和多个普通用户，对于复杂的系统可能会划分出更多的角色来承担不同业务。系统中的角色分离，其实是对现实适用场景中，不同人职能不同的高度抽象，每个角色都是一大堆职能的集合。然而，这种角色的分立与企业组织架构的关系也不是完全对应的，比如大多数时候，最高权限的管理员对应的就不是企业CEO，而往往是IT人员。所以，在设计角色的时候，我们需要分析清楚，到底这些角色都是谁，他们会如何使用产品。在分析角色的时候，其实也有非常多的陷阱。其中，最大的陷阱就是用自己代表用户！虽然同样是ToB的产品，但是企业内的协作方式、组织架构、企业文化等的不同都可能会对使用体验造成比较大的影响，这是和ToC产品非常大的不同。所以，在ToB端，很多成功的产品要么超级复杂，能够满足各种强大的定制和自定义，要么超级简单，会比较少受到不同企业个性的影响，当然，这里的简单不是指功能上，而是指逻辑上。角色分离另一个比较坑人的点就是，组织架构上的管理职责不一定能够映射到产品上的管理职责。举个简单的例子，对于部门内员工权限的管理，理论上来说，应该是部门负责人最清楚，但是，如果你傻傻地在产品上给部门负责人太多人员、权限相关的管理职责，结果很可能相当酸爽！当然，这块的大坑还很多，在此小不就不逐一列举了。陷阱2：操作冲突因为是多人操作的情况，在稍复杂一点的系统中，操作冲突可能就是不可避免的状况，尤其是一些涉及后台执行、多点登录等功能的产品。在处理这类问题的时候，需要考虑如何友好地展现冲突的状态，冲突内容的保存，冲突内容的处理机制等各种问题。这里可以参考一些比较成熟的产品的处理方式，比如SVN等，不同的冲突也会有不同的解决方案。SVN中的冲突是按照基准版本来判定的，也就是假设有两个用户在版本C的基础上修改了内容，上传后更新后变成了C+1版本，而此时B也是在C版本的基础上做了修改，上传之后就产生了冲突，对于B来说，他修改的冲突版本中，内容还保存着，可以重命名一下，再更新到C+1版本中，提交为C+2版本。而大家比较熟悉的采用的是另一种冲突处理方式。几年前，金山出过一款面向企业的网盘产品，叫做金山快盘企业版（现在应该已经合到金山企业云了），这款产品当时处理冲突的方法就比较简单粗暴了，只要发生了冲突，就对冲突的文件的文件名后面加上时间戳做区分，继续同步使用。