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

比如，在O2O的服务过程中，用户有一个设备的维修请求，他通过“用户界面”向平台发送一个状态信息和请求信息，平台端通过一个有效的机制，及时的接受这一信息，并让用户理解到，“我已经知道你这边除了状态，我正在安排人采用一些措施来协助你解决问题”。
这就是一种响应机制，这一过程就是整个平台的服务端开始处理用户请求的起点，然后整个平台基于这一个被“触发”的机制，去调动整个平台的资源，包括各项数据的查阅、各种资源的调动，来协同处理这一个业务请求的系列动作。
所以，整个产品的架构设计，也就是基于这一个连锁反应进行的业务层和逻辑层的解耦分拆，系统性的规划整个O2O平台的前后端如何高效的协同。
同时，基于这一个基本规则，我们再考虑平台的未来业务发展，甚至我们还需要考虑到未来三五年的业务容量会达到什么量级，由此需要采用怎样的技术设计和资源配置（云端服务资源）。
由此可见，产品架构设计，首先就是一个分层设计的过程。

文章插图
常来说，最容易实现的产品层级结构就是三层，即用户层、功能层和数据层，这种层级关系即可完整的实现前、后台关系的业务系统：
1. 统一的用户感知层解决的是用户触达的问题，考虑在何种场景下通过何种方式触达用户，最表层的业务体验，也就是我们常说的“用户体验”，包括界面，布局，配色等直观可见的每一个产品页面。
在这个层面，我们考虑的是如何更好的表达我们想要表达的业务元素，如何能够更吸引用户的注意力和停留决策，它在一定程度上决定了用户是否会立即卸载，或者是带着好奇之心在有效的引导下探索产品。
这是产品经理的必修课，因为它能直观的让人直接评断产品，最常见的说辞就是“丑爆了”，而且是任何一个产品都会遭受到这一批评，哪怕你是微信也毫不例外。
但真正决定体验的，并不是这一层，但又无可奈何必须面对的现实。所谓人靠衣装吧，一个打扮时髦的美女你甚至都会觉得她特别让你感觉亲密，甚至你会直觉认为她根本就是一个好人，一个让你喜欢的人。
2. 解耦的业务功能层多少产品经理实际在这个层级就开始陷入迷糊状态，根本不知道甚至没有意识到“功能”的分解和层次设计，在他们眼里，任何产品都只需要一个界面+一个数据库，即可愉快的完成所有业务。
也是因为这种主观的判断，让多少人总是认为这个东西很简单，那个东西很容易，别人都可以做出来，你为什么明天还不能上线，以及谁谁谁又做了这么一个功能，我们明天也要做一个。
诸如此类的根本原因就是只见树木不见森林。
这一种粗浅的认识，也带来大量的产品被粗制滥造，胡乱承诺，最后不得不草草收场，因为这些产品从一个开始就没有被真正的理解和设计，而是想当然的认为“我们只差一个程序员，明天就可以上线”。
对这一层级的认知不足，会让我们陷入一种奇怪的局面。
“一个妈妈生一个孩子要10个月，10个妈妈生一个孩子只需要一个月”。
“业务功能”的解耦，本质是解决产品的核心功能的设计问题，包括如何高效的完成业务功能，如何与用户层进行交互，如何与外部系统进行数据通信等一系列复杂的业务处理。
很多人无法理解，某个功能为什么要这么设计，为什么不能那样设计，就是无法真正理解这一层的设计，从而加剧整个产品在最开始阶段就限定了它的可能性。
这是“重构”的原罪。