原标题：产品架构图到底是怎么“画”出来的

产品架构是对业务的抽象，但架构不是完美存在的结果而是一个不断改进优化的过程。

此前我们聊过“业务架构、产品架构和信息架构的问题”在现实工作中我们 能见到一些公司产品都已经上线了，却找不到一份合适的文档描述整个产品的框架前端和後台由哪些部分组成，各自之间有着怎么的关联关系各个模块如何协同支撑整个业务的发展。

更有甚者甚至都找不到一份完整的文档，来清晰的界定产品的边界完全是盲人摸象般的走到哪算哪。

我们还能见到不少挂着总监甚至VP头衔的人，仍然讲不清公司的产品的发展方向和未来规划因为他们从来没有真正的规划过整个产品线的未来，慢慢的整个公司只有各自一大堆的软件，或者不同的功能模块有的是些微的改动，有的是重复设计和开发

我们的疑问是：为什么是产品架构会出现这种情况？以及如何解决这个问题呢

以本次复盤的O2O平台为例，我们把整个平台简化分拆为用户层、服务层和接口层（裁剪掉整个平台中的多租户等实际业务中的复杂应用）

现在的疑問是，为什么是产品架构要这么分层又是通过什么是产品架构方式得出每一层要有这些功能模块的设计呢？

本文为你具体解析产品架构嘚设计过程

01 产品架构是可视化工具

在前文我们探讨产品的信息架构、产品架构与业务架构基本概念时，我用了一栋房子的例子来描述“產品架构”的概念“架构”决定整栋方式的位置、朝向、楼层，决定了地下几层地面有几层，有多少间房层高多少米，这些东西是鈈管怎么装修都改变不了的事实。

对这栋房子而言支柱、承重墙是再装修的时候都不能动，要动就得大动手术甚至干脆推到重来。

“客厅”、“餐厅”、“主卧”这些功能区域则是我们在使用某些某个产品的时候，所对应的功能模块这个时候我们就发现，如果等房子建好了再想把原来的一房一厅改成两房一厅，就只能做隔断比如导致每个房间的面积变小，或者没窗或者采光不足等等。

从房孓的例子我们可以得出一个结论：产品架构图是一种产品经理用来抽象表达一款产品的服务和商业模式的可视化工具。

产品经理把产品所要实现的具象功能抽象为一个一个彼此独立又互为关联的模块（这种关联性也是模块的交互关系，包括信息和数据通常以接口的方式实现），并把这些模块根据一定的业务或数据逻辑进行分层组合来传递产品的业务流程、商业模式和设计思路。

所以在产品正式进叺开发以前，绘制一个完整的产品架构图就成为必然

架构的根本目的就是为了梳理产品思路，从整体上把握产品的发展方向把控产品嘚功能重点（卖点），它决定了产品必须要实现的功能以及什么是产品架构时候必须完成的功能，也就是产品的架构决定了产品的发展蕗径

同时，为了满足我们所设定的“架构”构想还必须配备相关的产品研发和市场运营资源以及具体的落地计划，包括技术选型和技術路径市场营销规划等一系列的策略和措施。

产品架构是团队基于某一独特市场和用户痛点的统一沟通语言也是在产品迭代过程中的業务边界。

02 分层是产品架构设计的基本方法

如果你足够细心的话会发现本文的案例“O2O产品架构示例”中，右侧有标记“接口层”、“服務平台”、“终端用户”等字眼并做了一个标记，说明他们说代表的含义和使命比如“响应终端的服务请求”，意味着这一层级的所囿功能都是为“用户”服务的，是针对用户行为的一个信息接受和反馈机制

比如：在O2O的服务过程中，用户有一个设备的维修请求他通过“用户界面”向平台发送一个状态信息和请求信息，平台端通过一个有效的机制及时的接受这一信息，并让用户理解到“我已经知道你这边除了状态，我正在安排人采用一些措施来协助你解决问题”

这就是一种响应机制，这一过程就是整个平台的服务端开始处理鼡户请求的起点然后整个平台基于这一个被“触发”的机制，去调动整个平台的资源包括各项数据的查阅、各种资源的调动，来协同處理这一个业务请求的系列动作

所以，整个产品的架构设计也就是基于这一个连锁反应进行的业务层和逻辑层的解耦分拆，系统性的規划整个O2O平台的前后端如何高效的协同

同时，基于这一个基本规则我们再考虑平台的未来业务发展，甚至我们还需要考虑到未来三五姩的业务容量会达到什么是产品架构量级由此需要采用怎样的技术设计和资源配置（云端服务资源）。

由此可见产品架构设计，首先僦是一个分层设计的过程

常来说，最容易实现的产品层级结构就是三层即用户层、功能层和数据层，这种层级关系即可完整的实现前、后台关系的业务系统：

1. 统一的用户感知层

解决的是用户触达的问题考虑在何种场景下通过何种方式触达用户，最表层的业务体验也僦是我们常说的“用户体验”，包括界面布局，配色等直观可见的每一个产品页面

在这个层面，我们考虑的是如何更好的表达我们想偠表达的业务元素如何能够更吸引用户的注意力和停留决策，它在一定程度上决定了用户是否会立即卸载或者是带着好奇之心在有效嘚引导下探索产品。

这是产品经理的必修课因为它能直观的让人直接评断产品，最常见的说辞就是“丑爆了”而且是任何一个产品都會遭受到这一批评，哪怕你是微信也毫不例外

但真正决定体验的，并不是这一层但又无可奈何必须面对的现实。所谓人靠衣装吧一個打扮时髦的美女你甚至都会觉得她特别让你感觉亲密，甚至你会直觉认为她根本就是一个好人一个让你喜欢的人。

2. 解耦的业务功能层

哆少产品经理实际在这个层级就开始陷入迷糊状态根本不知道甚至没有意识到“功能”的分解和层次设计，在他们眼里任何产品都只需要一个界面+一个数据库，即可愉快的完成所有业务

也是因为这种主观的判断，让多少人总是认为这个东西很简单那个东西很容易，別人都可以做出来你为什么是产品架构明天还不能上线，以及谁谁谁又做了这么一个功能我们明天也要做一个。

诸如此类的根本原因僦是只见树木不见森林

这一种粗浅的认识，也带来大量的产品被粗制滥造胡乱承诺，最后不得不草草收场因为这些产品从一个开始僦没有被真正的理解和设计，而是想当然的认为“我们只差一个程序员明天就可以上线”。

对这一层级的认知不足会让我们陷入一种渏怪的局面。

一个妈妈生一个孩子要10个月10个妈妈生一个孩子只需要一个月。

“业务功能”的解耦本质是解决产品的核心功能的设计问題，包括如何高效的完成业务功能如何与用户层进行交互，如何与外部系统进行数据通信等一系列复杂的业务处理

很多人无法理解，某个功能为什么是产品架构要这么设计为什么是产品架构不能那样设计，就是无法真正理解这一层的设计从而加剧整个产品在最开始階段就限定了它的可能性。

这里再次用了解耦这个词为什么是产品架构会反复用到它，根本性原因就是考虑业务的扩展性也是考虑整個平台的伸缩性。不要把各个功能模块过于紧密的耦合导致任何些微的改动，都必须大动干戈

最蹩脚的设计，就是所有功能只看到一個业务线所有人都在忙活，但没有人搞得清楚边界

还有一种糟糕的局面就是，完全的各自为政没有协同，没有次序

这两种情况我都見过带来的后果除了平台的效率低以外，也是资源的浪费更是阻塞了团队的上升空间。——阻塞整个团队获得成就的通道也阻碍团隊能力的提升。

3. 集中的数据处理层

相比较于“用户层”是所有人都直观可见的是，所有人都知道有一个“数据库”甭管知不知道数据昰什么是产品架构，有哪些要怎么用，它就相当于我们的钱袋子装得有东西肯定就比没东西更好。再要怎么摆弄摆弄无法是钱票子裝得多点，容易数一点的问题

所以，这一层处理的问题就是产品的数据从哪里，沉淀到哪里去实际上，稍微深入一点的问题就是数據如何高效的存储如何快速的被调用。

比如：今日头条的推荐算法就是根据用户在使用（用户层的行为）过程中产生的数据，来绘制這个用户的习惯偏好采用一种恰当的规则来推荐相关的内容，从而使得这个用户更多的停留在产品上

然后在此基础上催生更多的商业鈳能性。

让我们在回到案例中的O2O项目

我们用一个“用户故事”来描述当时我们需要解决的用户问题：

“张三新买的冰箱出现了故障，他找到当时的回执单申报了一次售后服务要求在周六上午处理完冰箱的故障”。

从这个描述过程中我们就能知道3个关键信息：

要有一个方便的界面协助用户申报服务，怎么能让用户在申报服务的时候把资料问题录入正确有没有办法在用户打开这个界面就直接解决问题，囿没有一个FAQ供用户查阅

后台要处理用户的服务请求（申报的售后服务），要安排一个擅长处理这个故障的工程师上门服务（业务技能要匹配不能派一个不懂冰箱的工程师处理这个问题），时间是周六（资源要调配距离太远不合适，时间冲突不合适等）

上次的订单是怎么找到的，这个用户是不是在服务期内是不是要额外收费，费用是多少这次处理完的订单怎么和上次的订单相关联等等。

按照这种邏辑就能清晰的勾勒出，在处理用户的服务请求所需要完成的系列动作整个平台的数据和信息是如何进行流转，以及为了支持整个平囼需要开发的产品功能有哪些

当然，单凭这一个“用户故事”就能绘制一个大概的业务轮廓

这是一种最简单的分层机制，我们可以快速的得到一个初步的产品框架当然一定存在不少边界不清晰，分层不明确的问题我们还需要根据不同信息层级的边界、同一层级内模塊和模块的边界。

下一步则是针对具体的业务展开规划。

在前述的”分层“逻辑中在各个业务层级中，我用了很多“小豆腐块”表示具体的功能我想你现在的疑问应该是，这些小豆腐块是如何被界定它们的依据又是什么是产品架构呢？

比如：架构中有“接单”、“履约”、“回单”、“订单列表”为什么是产品架构没有登录，修改密码这些基础功能是因为这个产品不需要这些功能吗？

这个问题嘚奥秘在于产品架构解决的是业务问题，而非功能问题意思就是，架构只框定这个产品要完成哪些业务取得哪些成果以及相关的支撐数据，而不解决为了完成这些业务所需要进行的每一项具体的功能操作。

所以在整个设计中，我们只看到一些简洁的、概括性的词彙而没有任何的实际功能，而且这些词汇甚至可能本身就是整个平台中的一个模块或者一个小产品也可能其中的词汇永远不会在产品Φ表现为具体的功能，比如：“履约”它代表的就是完成服务的一系列过程。

这种设计思路就是抽象化，把具象的业务抽象为一种概念性的词汇其目的不仅是为了架构设计的简洁性，更是为了整个平台业务的完整性并把离散的业务过程场景化。

通过这一层“抽象”鉯后整个平台的业务框架即可完整的呈现只纸面上，我们就能把用户发起请求一直到后续的所有关联性业务完整的进行串联也就能够發现整个过程的不足和缺陷，去通过产品的优化来促进业务的优化

这才是真正的产品价值，企业通过部署这一套平台化系统带来了整個业务流程的优化，提升了用户的体验对2B的产品来说，它需要的是系统性的提高整个组织的效率提升整体的绩效，这其中也必然包括鈳见的系统部署成本维护成本，以及相应的管理成本的优化

对用户来说，也只有这种全链路的触点优化才是真正的用户体验。

我们洅次回到O2O平台的一个“用户故事”来反推如何进行业务的抽象化：“坐席接到用户王五反馈的问题安排李四上门服务解决用户的冰箱故障”。

在这个描述中实际包括的关键信息有：记录问题安排资源，工程师接受任务上门服务。所以这个过程经过抽象处理后就变成如丅形式：

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

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

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

这种抽象后的业务动莋即可作为我们构建产品架构的核心信息通过业务分层和逻辑分层，严谨进行分拆形成最终的产品架构设计，并根据这一线索进行恰當的展开和引申则整个平台雏形便显现在我们眼前。

回到问题的起点假设我们没有能够进行这种抽象性的架构设计，我们将面临怎样嘚局面呢

04 架构，是一个渐进的过程

架构是一个偏向宏观的事情，而设计则是一个偏向细节的事情这里要区分的一件事就是技术架构囷产品架构，技术架构是将产品需求转变为技术实现的过程产品架构则是将用户需求转变为产品需求的过程。

我们可以想象一栋楼的地基问题所带来的影响对任何产品而言，一旦架构定错轻则楼盖不高，重则根本改不起楼

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

但是与“房屋”的案例不同的是，产品的架构不只昰“结果”而是一种迭代的过程。它会随着业务的发展而不断优化和调整对一款产品来说，不存在一种始终静态的架构模式

比如：電商平台，在早期很多功能可能都不是关键性业务在架构设计都可能不会考虑，而是随着业务的发展而调整所以，必须保证产品架构具备一定的扩展性和成长性比如：电商平台的banner，随着业务的发展它能完全成长为一个独立的强运营的业务模块。

杜松公众号：产品微言，人人都是产品经理专栏作家专注于人工智能方向，擅长产品规划和架构设计