抽象|设计产品架构的基本方法( 四 )

这个问题的奥秘在于，产品架构解决的是业务问题，而非功能问题。意思就是，架构只框定这个产品要完成哪些业务，取得哪些成果以及相关的支撑数据，而不解决为了完成这些业务，所需要进行的每一项具体的功能操作。
所以，在整个设计中，我们只看到一些简洁的、概括性的词汇，而没有任何的实际功能，而且这些词汇甚至可能本身就是整个平台中的一个模块或者一个小产品，也可能其中的词汇永远不会在产品中表现为具体的功能，比如“履约”，它代表的就是完成服务的一系列过程。
这种设计思路，就是抽象化，把具象的业务抽象为一种概念性的词汇，其目的不仅是为了架构设计的简洁性，更是为了整个平台业务的完整性，并把离散的业务过程场景化。
通过这一层“抽象”以后，整个平台的业务框架即可完整的呈现只纸面上，我们就能把用户发起请求一直到后续的所有关联性业务完整的进行串联，也就能够发现整个过程的不足和缺陷，去通过产品的优化来促进业务的优化。
这才是真正的产品价值，企业通过部署这一套平台化系统，带来了整个业务流程的优化，提升了用户的体验。
对2B的产品来说，它需要的是系统性的提高整个组织的效率，提升整体的绩效，这其中也必然包括可见的系统部署成本，维护成本，以及相应的管理成本的优化。
对用户来说，也只有这种全链路的触点优化，才是真正的用户体验。
我们再次回到O2O平台的一个“用户故事”来反推如何进行业务的抽象化：“坐席接到用户王五反馈的问题，安排李四上门服务解决用户的冰箱故障”。
在这个描述中实际包括的关键信息有：记录问题，安排资源，工程师接受任务，上门服务。所以这个过程经过抽象处理后就变成如下形式：

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

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

文章插图
通过这种高度抽象后，整个系统非常简洁而又完整，各个环节只需要通过一个订单主线即可完成一系列的任务，不管这个过程将要发生多复杂的业务交互都始终能够围绕用户和订单来进行溯源管理和任务处理。
这种抽象后的业务动作即可作为我们构建产品架构的核心信息，通过业务分层和逻辑分层，严谨进行分拆，形成最终的产品架构设计，并根据这一线索进行恰当的展开和引申，则整个平台雏形便显现在我们眼前。
回到问题的起点，假设我们没有能够进行这种抽象性的架构设计，我们将面临怎样的局面呢？
四、架构，是一个渐进的过程架构，是一个偏向宏观的事情，而设计则是一个偏向细节的事情。
这里要区分的一件事就是技术架构和产品架构，技术架构是将产品需求转变为技术实现的过程，产品架构则是将用户需求转变为产品需求的过程。
我们可以想象一栋楼的地基问题所带来的影响，对任何产品而言，一旦架构定错，轻则楼盖不高，重则根本改不起楼。

文章插图
所以，产品的架构设计，最考验PM的判断力和设计能力——体验是设计出来的，产品是规划出来的。简洁的架构决定产品的调性。