架构|设计产品架构的基本方法( 三 )

文章插图
我们用一个“用户故事”来描述当时我们需要解决的用户问题：
“张三新买的冰箱出现了故障，他找到当时的回执单申报了一次售后服务，要求在周六上午处理完冰箱的故障”。
从这个描述过程中，我们就能知道3个关键信息：

文章插图
用户信息：
要有一个方便的界面协助用户申报服务，怎么能让用户在申报服务的时候把资料问题录入正确，有没有办法在用户打开这个界面就直接解决问题，有没有一个FAQ供用户查阅；
业务信息：
后台要处理用户的服务请求（申报的售后服务），要安排一个擅长处理这个故障的工程师上门服务（业务技能要匹配，不能派一个不懂冰箱的工程师处理这个问题），时间是周六（资源要调配，距离太远不合适，时间冲突不合适等）；
数据信息：
上次的订单是怎么找到的，这个用户是不是在服务期内，是不是要额外收费，费用是多少。这次处理完的订单怎么和上次的订单相关联等等。
按照这种逻辑，就能清晰的勾勒出，在处理用户的服务请求所需要完成的系列动作，整个平台的数据和信息是如何进行流转，以及为了支持整个平台需要开发的产品功能有哪些。
当然，单凭这一个“用户故事”就能绘制一个大概的业务轮廓。
这是一种最简单的分层机制，我们可以快速的得到一个初步的产品框架，当然一定存在不少边界不清晰，分层不明确的问题，我们还需要根据不同信息层级的边界、同一层级内模块和模块的边界。
下一步，则是针对具体的业务展开规划。
三、抽象与解耦在前述的”分层“逻辑中，在各个业务层级中，我用了很多“小豆腐块”表示具体的功能。我想你现在的疑问应该是，这些小豆腐块是如何被界定，它们的依据又是什么呢？
比如架构中有“接单”、“履约”、“回单”、“订单列表”，为什么没有登录，修改密码这些基础功能，是因为这个产品不需要这些功能吗？
这个问题的奥秘在于，产品架构解决的是业务问题，而非功能问题。意思就是，架构只框定这个产品要完成哪些业务，取得哪些成果以及相关的支撑数据，而不解决为了完成这些业务，所需要进行的每一项具体的功能操作。
所以，在整个设计中，我们只看到一些简洁的、概括性的词汇，而没有任何的实际功能，而且这些词汇甚至可能本身就是整个平台中的一个模块或者一个小产品，也可能其中的词汇永远不会在产品中表现为具体的功能，比如“履约”，它代表的就是完成服务的一系列过程。
这种设计思路，就是抽象化，把具象的业务抽象为一种概念性的词汇，其目的不仅是为了架构设计的简洁性，更是为了整个平台业务的完整性，并把离散的业务过程场景化。
通过这一层“抽象”以后，整个平台的业务框架即可完整的呈现只纸面上，我们就能把用户发起请求一直到后续的所有关联性业务完整的进行串联，也就能够发现整个过程的不足和缺陷，去通过产品的优化来促进业务的优化。
这才是真正的产品价值，企业通过部署这一套平台化系统，带来了整个业务流程的优化，提升了用户的体验。
对2B的产品来说，它需要的是系统性的提高整个组织的效率，提升整体的绩效，这其中也必然包括可见的系统部署成本，维护成本，以及相应的管理成本的优化。
对用户来说，也只有这种全链路的触点优化，才是真正的用户体验。
我们再次回到O2O平台的一个“用户故事”来反推如何进行业务的抽象化：“坐席接到用户王五反馈的问题，安排李四上门服务解决用户的冰箱故障”。
在这个描述中实际包括的关键信息有：记录问题，安排资源，工程师接受任务，上门服务。所以这个过程经过抽象处理后就变成如下形式：

受理：坐席把用户反馈的问题记录在案，并形成一个单据
调度：坐席根据用户信息，安排恰当的工程师
接单：工程师接受坐席安排的任务
履约：工程师上门处理用户反馈的问题

我们可以把这种抽象后的关键节点称之为“业务动作”，他们将像一栋房子的支柱和承重墙一样，牢牢的支撑起整个平台的运转。

文章插图
通过这种高度抽象后，整个系统非常简洁而又完整，各个环节只需要通过一个订单主线即可完成一系列的任务，不管这个过程将要发生多复杂的业务交互都始终能够围绕用户和订单来进行溯源管理和任务处理。