产品架构图到底是怎么“画”出来的？ _架构图

文章插图
此前我们聊过“业务架构、产品架构和信息架构的问题”在现实工作中我们能见到一些公司，产品都已经上线了，却找不到一份合适的文档描述整个产品的框架，前端和后台由哪些部分组成，各自之间有着怎么的关联关系，各个模块如何协同支撑整个业务的发展。
更有甚者，甚至都找不到一份完整的文档，来清晰的界定产品的边界，完全是盲人摸象般的走到哪算哪。
我们还能见到不少挂着总监，甚至VP头衔的人，仍然讲不清公司的产品的发展方向和未来规划，因为他们从来没有真正的规划过整个产品线的未来，慢慢的，整个公司只有各自一大堆的软件，或者不同的功能模块，有的是些微的改动，有的是重复设计和开发。
我们的疑问是：为什么会出现这种情况？以及如何解决这个问题呢？
以本次复盘的O2O平台为例，我们把整个平台简化分拆为用户层、服务层和接口层（裁剪掉整个平台中的多租户等实际业务中的复杂应用）。
如下图所示：

文章插图
O2O产品架构示例
现在的疑问是，为什么要这么分层，又是通过什么方式得出每一层要有这些功能模块的设计呢？
本文为你具体解析产品架构的设计过程。

01 产品架构是可视化工具在前文我们探讨产品的信息架构、产品架构与业务架构基本概念时，我用了一栋房子的例子来描述“产品架构”的概念，“架构”决定整栋方式的位置、朝向、楼层，决定了地下几层，地面有几层，有多少间房，层高多少米，这些东西是不管怎么装修，都改变不了的事实。
对这栋房子而言，支柱、承重墙是再装修的时候都不能动，要动就得大动手术，甚至干脆推到重来。
“客厅”、“餐厅”、“主卧”这些功能区域，则是我们在使用某些某个产品的时候，所对应的功能模块。这个时候我们就发现，如果等房子建好了，再想把原来的一房一厅改成两房一厅，就只能做隔断，比如导致每个房间的面积变小，或者没窗，或者采光不足等等。
从房子的例子，我们可以得出一个结论：产品架构图是一种产品经理用来抽象表达一款产品的服务和商业模式的可视化工具。
产品经理把产品所要实现的具象功能，抽象为一个一个彼此独立又互为关联的模块（这种关联性也是模块的交互关系，包括信息和数据，通常以接口的方式实现），并把这些模块根据一定的业务或数据逻辑进行分层组合，来传递产品的业务流程、商业模式和设计思路。
所以，在产品正式进入开发以前，绘制一个完整的产品架构图就成为必然。
架构的根本目的就是为了梳理产品思路，从整体上把握产品的发展方向，把控产品的功能重点（卖点），它决定了产品必须要实现的功能，以及什么时候必须完成的功能，也就是产品的架构决定了产品的发展路径。

文章插图
同时，为了满足我们所设定的“架构”构想，还必须配备相关的产品研发和市场运营资源以及具体的落地计划，包括技术选型和技术路径，市场营销规划等一系列的策略和措施。
产品架构是团队基于某一独特市场和用户痛点的统一沟通语言，也是在产品迭代过程中的业务边界。

02 分层是产品架构设计的基本方法如果你足够细心的话，会发现本文的案例“O2O产品架构示例”中，右侧有标记“接口层”、“服务平台”、“终端用户”等字眼，并做了一个标记，说明他们说代表的含义和使命，比如“响应终端的服务请求”，意味着这一层级的所有功能，都是为“用户”服务的，是针对用户行为的一个信息接受和反馈机制。
比如：在O2O的服务过程中，用户有一个设备的维修请求，他通过“用户界面”向平台发送一个状态信息和请求信息，平台端通过一个有效的机制，及时的接受这一信息，并让用户理解到，“我已经知道你这边除了状态，我正在安排人采用一些措施来协助你解决问题” 。
这就是一种响应机制，这一过程就是整个平台的服务端开始处理用户请求的起点，然后整个平台基于这一个被“触发”的机制，去调动整个平台的资源，包括各项数据的查阅、各种资源的调动，来协同处理这一个业务请求的系列动作。