专注于角色的业务，而不是每一个具体的功能。
<让产品从0到1> 第 12 辑
文 | 杜松，公众号 | 产品微言
我们之前谈到了如何 基于用户洞察设计产品的业务架构 ，其目的是为了实现业务的解耦，以便构建一个“轻型”的2B业务系统，实现可扩容的架构，使得整个系统能够跟上业务快速发展的步伐，而不必为了新业务的增长而重构系统。
随之而来的第一个问题，就是整套业务系统里面，到底应该如何构建一个能够“容纳”不同角色的用户体系并行处理业务，如何实现跨流程的协作。
01、基于工作流梳理用户对象
不管各种新奇的理论如何，我们首先做的第一件事情始终都是在围绕用户展开，通过实地的业务模拟，考察和分析推演，结合具体的业务流程和工作流程，拆分各个“群体”——系统的服务实体对象。
1、业务还原
在构建整个 O2O平台的过程，我们大致梳理的业务过程，包括用户发起服务请求、后台处理服务请求、前端完成服务请求三个过程。
简单描述如如下图所示：
业务闭环示意图
服务请求
用户（不管是2B的客户，还是2C的终端用户）可以通过多种方式发起客服服务请求，在这个过程中，坐席端的首要任务就是如何及时响应用户端的请求，完整的记录用户的问题，并快速解决用户的问题。
从这个过程中，可以拆分的产品价值包括用户端的体验问题以及坐席端的效率问题。
也就是，在这个过程中，需要拆分和解决的问题包括：
如何建立完整的用户请求的通道（全覆盖的通道能够提升用户的整体体验）；
如何解决坐席的快速解决用户的问题（任何一个服务平台都希望尽可能的提高一次服务过程解决用户问题的比例，这需要一个足够高效的知识库）；
如何帮助坐席快速，完整的记录用户请求的内容，也涉及到当服务请求过大时如何分配合理的坐席资源。
这些问题不但涉及到产品的架构设计，也是产品的交互和视觉设计的重要参考依据，必须充分结合实际工作场景，方式和流程，来考虑在交互上的便捷性，甚至视觉上减轻使用者的疲劳感。
实际上，这也是技术选型的重要指标性因素，所以通常来说，产品的需求文档必须要有明确的技术性指标，包括响应时间，并发数等。
ps：在前文 浅析产品的信息架构、产品架构与业务架构谈到的" 产品的抽象能力 "，指的是这种从上往下的业务分析能力，而不是指能从下往上看各个细节。
对产品经理来说，面向任何一个业务需求，都首先要从大方面思考，再深入到细节性流程，一旦反过来，则整个产品只有功能，而没有业务。
服务调度
调度，指的是针对某类型用户/客户，发起服务请求的响应和处理。
也就是基于“效率至上”的原则，如何调配最合适的工程师解决用户的问题是最经济，最高效，在这个过程，涉及到很多种场景的优先考虑，比如有些问题只是一般性的咨询，有的问题则严重的质量问题，还有的问题可能已经引发了群体性和舆论性问题。
这不但需要建立一种完备的处理机制和流程，首先则是需要赋予一线“接线员”相应的权限和能力，能够第一时间识别到风险，也能快速调动相关的资源，及时处理用户问题。
在产品和技术上的处理细节，还需要考虑到资源的瓶颈性，系统必须要能人工干预的调度资源，还要能建立一个“众包”的通道，打通更多的社会性资源加入“平台”，同时也在一定程度上激发工程师的积极性，来提高服务的处理效率。
服务履约
这个环节，也是最终如何处理用户服务请求的过程，也是一个对服务质量考核的关键节点，包括服务响应时间、服务质量、用户评价等过程。
业务上，这个环节在某些场景还可能存在服务和产品的二次销售行为。
综上所述，我们就能够把整个复杂的业务过程，抽象成三大“业务动作”，也就是支撑整个系统能够正常运转的基本节点，想象一下房子的支柱，即可理解这种思路设计的系统有那些优势。
换言之，我们在第一阶段设计产品的架构时，根本无需过多的考虑分支流程和细节性逻辑，只需要构建一个支撑平台即可完整的还原整个业务流程。
也就是，我们可以想象自己在打造一个桌面，只需要考虑桌子的四个角之间的构造合理性、稳定性和承重能力，就可以保障未来的业务扩展。
在架构设计的阶段，我们可以把上述的业务流程进一步抽象，整个的业务模型可以表达如下：
O2O平台业务模型
从整个模型上，我们既能看到要服务的用户对象，也能看到各个服务的实体，以及在整个过程中关键业务动作，围绕这些动作，即可完成各种不同场景下的业务订单。
这个平台是一个高度解耦的系统，能够兼容不同的业务和不同的单据格式和内容，对整个系统而言，表现层的内容对业务本身不构成影响因子，整个平台仅依赖“业务动作”的高效运转。
2、实体拆分
从整个业务模型中，我们梳理出了一个业务全貌，可以清晰的识别到各个服务层所承载的服务能力，即可根据各自的能力进一步的拆分出实体的“业务范围”。
角色示例
在整个平台中，首先定义了三个不同的实体，也就是不同的业务应用对象。（ps，为方便描述，本文示例进行了大量的简化工作。）
从上图可以清晰的看到不同的实体，他们的业务边界非常的清晰，在这个逻辑下，我们可以清晰的设计各自的工作流，也就能清晰的界定不同的用户角色权限。
以“门店”为例，TA在这个角色关系中，实际上处于一种承接的关系。
向上对接订单的调度，负责总部的调度机制和工单协调机制；向下，对接其旗下的服务工程师，负责工程师的调度和工单的协调。
按照这种思路，我们在设计“门店”这个角色和工单的流转业务中，就能很明确的限定它在这个平台中的地位，换句话说，也就能界定它的权限范围和需求范围。
也就不会再出现随意性的变更，因为它受制于整个平台的管理规范。
基于这种思路，我们就能够有效的拆分复杂的应用，解耦整个系统的框架设计，也就能清晰的描述各个用户角色在平台上的职责、权限和价值体现。
整个平台是基于角色的工作流作为出发点，而不是账户，两者可实现柔性的关联关系，而不是强制性的管理关系。
任何用户，只需要符合某种角色身份就可以在平台中自由完整的执行业务动作。这也是整个平台账户体系设计的基本思路。
02、设计用户标签系统
“标签”的目的，除了简化系统设计以后，还有一个重要属性就是构建柔性的网络管理规则，可以根据不同的业务需求，直接配置不同对象。
标签系统可以根据角色的类别、属性、业务动作等进行分解。如下图所示：
这个图，有出现“类别”、“属性”、“可视范围”、“业务动作”，实际上这四个名词并非通用性术语，而是在构建这个平台以及制定整个平台的SOP采用的一种项目化语言。
根据我的经验，采用这一约束性的项目化语言，有助于团队快速的理解需求，并在规范的范围内加速产品的应用落地。
这里还引入了一个重要的属性：可视范围。简单的说，就是一个坐席、或者门店，工程师可以根据他们的实际情况，配置他们所能履约完成的业务范围，比如A门店具备上门服务的能力等。
对于一个产品 / 系统来说，决定业务的是每一个独特的实体对象，也就是在整个工作流过程中的角色，只需要紧扣角色对象，就能够清晰的界定整个平台的边界范围。
越是大型的系统，越是要能界定边界，沥青责权。
03、专注于用户的动机
“当用户使用某个产品的时候，他们是为了完成某个特定的工作(到达某种结果)”，这是一句产品名言。
在设计产品时，真正值得高度关注的是用户的目标、产品的使用场景以及用户与产品的关键交互阶段，而不是把焦点集中在用户的任务是什么以及如何完成任务。
比如，调研发现用户需要频繁的打印那些有规划地点、线路的订单，如果只是去设计一个高效的打印、排版的订单处理和调研界面，显然不是更好的解决方案。
换句话说，我们在用户调研过程中，过于倾向于关注用户的行为动作，而不是动机，用户画像过多的停留在个人信息和人口学属性的集合，而没有能够深入到实际业务中。
对产品而言，不能提供关于“用户态度和行为特性”的人物角色只是一个“鸡肋”般的存在，因为无法真正理解用户的痛点，无法真正解决用户的“绩效问题”，也就根本不能设计一款真正符合用户预期的产品。
所以，
在设计用户角色模型时，应该分成两个步骤来完成：
1、建立对人物角色的同理心
包括用户的履历和年龄、收入等人口学属性。
2、关注人物角色的动机
包括用户的态度和行为，使用产品的目的和动机，以及在使用产品时的行为细节、偏向和心理感受。
<本文完>
关注公众号：产品微言，回复“从0到1”，即可下载完整 PPT
我将通过17篇文章，解密推动产品落地的全过程，包括产品的定义和设计、开发过程的管理，以及由此引发的系列问题，更包括在此过程中我所学到的宝贵经验和深刻教训。
欢迎交流，下辑预告：
用户权限管理与RBAC模型
网友评论