产品架构能力咋提升？一文讲清产品架构设计及关键概念

产品架构能力咋提升？一文讲清产品架构设计及关键概念

产品设计体系，正愈发完备起来。产品经理所具备的能力，存在着诸多方面呢。比如说，有着设计能力，还有运营能力，更有规划能力。然而呵，单单产品架构能力是最具难度的，这需要自身拥有极为强大突出的专业能力，以及丰富的行业经验才行呵。

在产品设计的顶层范畴内，能够这么讲，产品能否呈现出架构设计良好的状态，这所展现的就是成熟的产品经理与产品小白之中最为关键的那种区别，那么产品经理究竟该通过何种途径促使自身的产品架构能力得到提升呢，又该怎样从整体全局态势出发去对产品的笼统架构予以设计，如何对未来的产品走势路径进行规划，以及怎样把整个相关产业链予以整合呢。

产品架构思维、抽象，是两个关键概念，二者相辅相成。借助产品架构思维，能够把产品分解成各个部分，还要对这些部分予以分析以及设计，之后经由抽象，可将这些部分简化成关键概念与模型，以此更好地理解、处理问题。

当然，没必要把产品架构讲得太过玄虚，诸如生态、多实践、要做多少年等，事实上，可方法化、技巧化才是且必定是产品架构应有的样子。

一、什么是产品架构？

产品架构是产品经理用以表达自身产品，整体设计机制以及规划的图，它把产品功能落实成信息化、模块化，且层次清晰的可视化架构，借着不同分层的交互关系、功能模块的组合、数据及信息的流转，去传递产品的业务流程、商业模式和设计思路。

产品架构，是针对商业模式里核心业务场景所作的抽象，其展现出商业模式的运作以及实现方式，产品架构设计，属于抽象业务场景，是经由业务规则构建产品内在逻辑的进程。产品架构的对象，不外乎产品的商业需求与用户需求。怎样使满足产品这两个需求的产品设计能够更简单、更高效地规划，此即产品的架构。

复杂事物被简化成一组关键概念或模型，这一行为被称作抽象，其目的在于能更好地理解问题，进而更好地处理问题。

一种旨在针对原本各自孤立的产品，实施有所侧重的编排组合的架构，便是产品架构。如此这般，得以让满足用户需求更为简便 ，使满足商业需求更为简便 ，让产品设计也更为简便 ，这便是产品的生态。其并非将孤立的产品拼接起来 ，而是凭借产品架构予以组织。至于这种因简单而带来的高效 ，那就更不必多言了。这里存在着两个重要的目标：

1、满足需求高效简单；

2、产品设计过程高效简单。

闻名的奥卡姆剃须刀法则，于产品架构设计里同样具备适用性，通常来讲，架构越是简易的情况，产品越发易于成长，其适用能力也就越强。

产品架构所需考量的是和产品有关的各类影响因素，其中涵盖：用户需求、产品战略或者说商业需求、开发资源、市场运营人员等等，这些因素始终处于不断变化之中，一种合理的架构需致力于尽可能运用最为简单的方式去应对这些变化，进而细分开来讲，产品架构应当包含两个关键方面，也就是：需求架构和设计架构。

需求架构更为偏向业务架构，也就是要在产品层面，对关乎用户需求、商业需求以及业务流程，进行合理的规整，做出有关于轻重缓急方面的设计安排之事。这同样属于产品架构最为关键要处理的事务范畴。而设计架构呢，往往是在产品进行设计活动那个相应环节期间之内，尽力保障产品于设计层次所涉及的通用元素以及足以可重复加以运用的元素，达成前后一致的状态条件，而这是处于一个更为精细详情的层级高度，则是借助这样的方式内容去提升设计工作本身的效率程度之事。

因为产品架构图常常用于相对复杂的大型产品项目里头，当下有关产品架构图的相关书籍以及资料极为稀少，特别是入门级别的资料很少有所提及，然而产品架构却是设计复杂产品的时候不可缺少的一个环节。

建议在复杂项目开启之前绘制产品架构，如此能够防止再度重复那种不断改正需求、推翻先前规划而重新进行规划等效率低下的工作情形。与此同时，当你描绘产品架构图之际，能够妥善地规划整理自身的产品。

二、产品架构与技术架构的区别

就是说架构，是针对架构的对象去做合理的抽象，这么做的结果，是能使架构的对象变得更具高效性，变得更显简单性，变得更有多易用性，变得更具易变性。简单来讲，架构就是为了达成：简单以及高效这两个方面。架构并非那种完美存在而直接产生的结果，架构是一个持续不断地去改进优化的过程。然而，恰恰在每一个节点之上，都存在着好坏程度以及数量多少的区分，这同样也是架构能力的一种体现。

产品架构跟技术架构的区别在于对象，前者架构所关注的是需求以及设计，后者架构关注的是硬件、软件还有数据。不过，产品架构主要涉及的是应用层、服务层、支撑后台 ，技术架构层是一种简化的技术架构。

以技术手段达成产品能力，此为技术架构，会关注服务器、网络、与中间件、还有操作系统这些偏向技术层面的关键点，其中那个技术架构图就在实现维度把软件系统的实现架构给呈现出来了，比如像下面这样。

能将技术架构划分得极为细致，此处不予以详尽阐释，着重介绍技术实现的原理：应用层借助一次用户操作来获取数据，接着透过服务层把那些数据传至逻辑层，逻辑层依据代码所实现的规则对数据层里的数据实施处理，做完处理之后再朝着相反方向告知到应用层，进而反馈给用户，如此便达成了一次用户交互。

从广义来讲，产品架构属于业务结构的镜像，其描绘的是源自实际业务而抽象得出的需求（子需求），以及该需求怎样在系统之中（子系统之间）交互，进而最终得以满足的过程。从狭义来说，产品架构指的是需求与交付物之间的关系。以下用一个表格予以说明：

产品具备这样一种架构，它被划分成五个层面，分别是战略层，范围层，结构层，框架层以及表现层。这五个层面之中，每一个层面都由位于其下方的那个层面予以决定。从战略层一直到表现层，这实际上就是一个从抽象朝着具体转变的过程。这五个层面并非是相互独立存在的，换而言之，并不是要等到彻底完成“底下一层”的工作之后才能够开展“上面一层”的工作，而是要使得每一层面的工作在其下一层面宣告结束之前就能达成。在实现层面，系统架构应当涵盖数据，业务/商务，运营，营销等一系列整体业务流。

三、为什么要画产品架构？

产品经理用以表达自身产品设计机制的概念图是产品架构图，它运用分层的交互关系之中，功能各异模块的组合之内，数据和信息转动流程上的相互作用！把可视化的具体产品功能转变成模块化、信息化、层次明晰有架构，传递产品的商业模式、业务进程以及设计想法！因为它常应用于复杂产品项目里而涉及介绍它的相关书籍资料极少最少入门级别的几乎没提及，可却是设计复杂产品时不能缺少的文档之一！

其一是利于产品规划者知晓自身产品的构成部分，其二是能清晰且直接地领会各业务单元的逻辑关联，其三是便于展开业务分工以及梳理配合协作，其四是有益于产品迭代计划得以开展拆解，其五是可为技术架构乃至运营增长筹划赐予助力，架构图还是高阶PM必备的产品规划能力的直接展现。

产品架构图可以帮助产品经理：

根据产品战略所进行的定位，来明确产品的用户种类以及其需求，进而确定产品包含哪几个端口。

清晰辨析自己针对产品方向所做的判断，即能够相对清晰且简易地展现自身思路，明确自身产品边界，指出未来发展方向。抬头审视道路与低头专注前行虽同样关键，然而在产品方向把控的起始阶段，二者的次序格外关键。思索这张图究竟要怎样进行设计的进程，同样是用以助力你整理如下诸多问题的进程，囊括“半年之内自己的产品理当朝着哪里行进、需求应当怎样分阶段实现与落地、和其他产品存在何种依赖关系、具备怎样的竞争关系、未来的可拓展空间身处何处”等一系列问题。

2、根据用户的需求，推导产品端的功能

也就是，当一个角色做完一件事情以后，由另外一个角色来开始履行职责，那么就把这两个角色的职责拆分成两个业务。比如说电商业务，用户下完订单之后，轮到平台去发货，如此下单和发货能够拆分成两个业务。

3、将产品功能填充到对应的端

要是讲一刻不停歇地去搞产品开发属于只顾埋头行路，那么像是先对未来一年要设计怎样的产品、需求该怎么分期并落实、跟其他产品的依赖以及竞争关系是啥、未来的可拓展之处在何方等诸多问题展开思考与规划，这便是抬头去瞧路，瞅准路之后再迈步，如此方能踏实走好脚下的段段路。于获取功能之后，便能把功能点填到相应的端。倘若功能数量众多，那就可适度为功能进行分类，从而让架构图更具层次感。架构图是在产品规划的早期阶段所使用的，因而仅仅需要展现出产品的总体那种轮廓，以及大的功能方面的方向性内容就行，并不需要去涉及过多的功能细节部分，此处也是没有办法去涉及的，原因在于距离产品真正出来的时间还很早呢。

4、为技术&运营的输出形成支撑，为其他人的输出节奏提供依据

在产品架构图被设计完成之后，依据产品架构图的结构以及路径，项目的里程碑（）便能够被清晰地拆解出来，清晰的产品思路有助于他人迅速建立对项目的产品结构、功能、交互、复杂度等方面问题的认知，与此同时，能助力技术和运营成员依据这张架构图产出项目推广计划、技术系统架构方案等高度依赖产品方向的方案。

产品架构视角下的系统化创新:

在业务发展刚开始的那个早期时期，产品设计开发方面的工作常常是落在业务创新之后的，其主要做的工作内容就是去响应以及配合业务的需求，产品经理还有工程师，常常会有一种忙得四处奔波筋疲力尽的带有失控感觉的状态，不过这却是一个基础设施建设所必需的阶段。跟着对业务了解程度的加深以及产品系统架构的完备，产品领先于业务，进入到系统化创新阶段的那种情况就会来临。系统化创新常常是以这样的一种方式来开展进行的：业务流程被抽象成颗粒度极其细小的节点，借助四个办法然后呈现出全新的形态出现：

（存在这四个方法，它们和《简约至上：交互式设计四策略》里边是相似的情形，然而层面并非相同）

产品架构对产品业务的影响:

在新零售话题里头，组织架构方面的变革常常被提到处于颇值得重视的位置，系统中台化的趋势对组织结构有着液态化的要求，目的在于去响应商业环境以及业务形态那快速的转变；而在产品架构话题当中，组织架构以及产品经理个人的成长却常常遭受忽视。这直接对产品技术研发类的组织架构产生影响，产品架构的最后交付物乃是系统架构。系统架构会划分好各子系统，也就是子模块之间的内容。如此一来，PM和RD的工作内容以及协作关系也就随之被确定了。间接对整个业务流里各参与角色的职责内容以及协作关系产生影响，伴随业务发生变化以及系统得到改进，参与角色的工作内容乃至角色自身，都存在改变或者取消的可能性。达成业务结构、产品/系统架构、个人成长这三者的合一，是用以衡量产品架构是否出色的一个关键视角。产品架构的评判要点，优质的产品架构，应当如同容器一般，能够提供空间（诸如性能冗余、数据监控分析、损失管理等能力），去包容业务的不确定性（也就是创新），它是一种系统机制。评判要点的说明：

四、产品架构图应具备的特点

一张优秀的产品架构图需要具备哪些特点？大致总结为以下4点：

1、清晰的模块功能边界

2、功能做到标准化、互相独立

3、上下游产品功能边界清晰，架构分层明确合理

4、具备持续迭代优化的能力

依据产品的进展情形，你能够持续去更新产品架构图，每一回修改环节，对于提升产品架构能力所起到的助力是极为显著的。

关于具体产品架构设计的原则以及方法，能查阅我的另外一篇文字，这里就不再详细叙述了。

五、谁来评判产品架构

因产品架构是需求间的关系以及需求实现的过程，参与产品架构评估的角色，要涵盖具备业务抽象能力的业务方，还有产品、研发等，是以业务场景作为基本维度，产品架构设计实施存在一般方法，产品架构与技术上的架构设计实施过程具有一致性。

乐高一般的开放系统架构应包括三个基本要素：

六、产品架构如何实施？

最近这段时间，也一直在思索这个问题，然而得到结论相对简单直接，粗暴的那种，可不知道是对还是错，故而发送出来，寻求交流讨论。

于理论层面而言，我觉着上面给出的回答均极具合理性。然而就我于实践过程之中所获得的感悟来讲，实际上产品架构便是在充分领会产品用户需求的基础之上，针对产品数据流转的逻辑予以梳理。或许因太过抽象，故而粘贴了上面那个回答里的内容，情况如下：

其一，我对于“产品架构”的领会，是在全面理解面向用户的需求之后的那种情形吗，这是从0起始去设计完整产品体系方案，并且把它予以实现的进程、这里面涵盖着一个产品生成的整个过程，诸如数据层的数据库表，还有后台数据处理平台以及运营维护平台，再者前后端数据交互体系，前端的基础产品框架等一系列系统的构建和运转逻辑，这便是所谓一个产品能够诞生之前所需要的“骨架”，当这套骨架完工后，大家所熟知的前端功能、数据接口等具有实体属性的产品开发才正式拉开帷幕。

有两点可以概括产品架构的特点：

1. 架构最为突出之处在于，其眼中不存在与产品形态相关连的概念，有的仅仅是数据流转的整个过程。

产品架构工作的本质在于梳理数据流，要是梳理得顺畅，那未来产品做起来会极为顺畅，用户所需功能能够迅速实现，产品的稳定性颇佳，并且能有力支撑数年乃至十几年的业务发展。界面不过是数据的窗口或者入口罢了，这是日后各位前端产品经理，或者后端产品经理要考虑的事儿。

要深刻领会不同岗位所承担的职责，还要深切明白相应工作的具体内容，同时也得深入理解最终面向的用户。

打个比方来讲，要是开发的目标是成功塑造美妙产品，并且运营做这件事的目的也是制造出优质好物，产品方面的目标同样设定为努力打造出色产品，市场的目标亦是为此打造良好产品，那么架构师要费心寻思的就是怎样使得这一群人合力打造出优良产品。知乎上面有个经典问题是，产品经理究竟是否应当懂得技术，它并非说需要产品经理知晓书写各类码，而是在于理解技术在达成需求之际所具备的优势之处、体现的劣势方面、潜藏的风险状况。同样的道理，对于运营所处的各个环节而言，对于市场的各个流程来说，对于销售的各个步骤来讲，都是如此这般的情况。

因为本人所从事的是B端产品，或许跟C端产品在形态以及产品模式方面存在较大差异，然而我认为追根溯源任何产品皆是由一堆数据与一个用于和用户进行数据交互的体系所构成。因此进行产品架构工作，从本质上来说最为核心的便是数据的架构。

我理解的产品架构，对应《用户体验要素》中的「结构层」。

架构分2个层面，1是物理架构，2是逻辑架构，举个例子，

物理架构，举例来说，就如同一个楼盘，从楼盘起，接着是期，然后是栋，再之后是单元，随后是楼层，跟着是房号，最后是房间。

逻辑架构：

处于指示状态的系统，中央控制的空调系统，涉及水、电、气的网络系统，存在进水以及排水情况的系统，具备监控功能的系统，有关房屋结构方面的系统……

产品也是这样的，物理架构：频道→页面→模块→元素

逻辑架构：登录注册系统、导航系统、搜索系统……

所以，我觉得产品架构能力，就是说其在这2个方面，是否做到考虑得全面周到，并且架构得合乎情理。

七、如何画出一份优秀的产品架构图？

1. 搭建基础框架

脱胎于业务流程的基础产品框架呢，它和业务流程相比较而言，更着重于产品功能的一一列举，以及功能模块相互之间的界限划分。

2. 详细操作步骤

对照业务流程，依据自己所设想的产品机制，以及基本产品形态，还有用户的使用路径，罗列出需要的页面，以及功能，还有模块等前后端逻辑。

针对从刚获取的多个流程图里，把那些功能存在相似之处，亦或是范围存在包含关系的机制、功能，放置至一起，凭借模块化的形态，塑造出一张简洁款的矩阵图。

把明显属于同一个产品范围的模块放置在一起，将明显是同一组产品功能的模块也放置在一起，并且要把它们放在同一层级，如此这般就能得到一个基础的产品框架。

3. 明确架构分层

关于一个有着前后台关系的产品架构图，它至少要分成三层，其一为用户感知层，即探讨在怎样的场景之下，会借助何种方式去触达到用户，其二是功能模块层，也就是研究通过哪些功能模块能够达成产品的核心功能，以及和哪些外部平台功能存在信息交互，其三是数据层，即关注产品的数据源自何处，以及产品的数据会沉淀到什么地方去。

上一步做完简单分层后，我们有了个初步框架，不过分层不明确的问题难以避免，这时要按两种维度处理架构图的层级，即不同信息层级的边界，以及同一层级内模块和模块的边界。

4. 处理不同信息层级的边界

架构图的层级所表达的，实际上是信息之间的流转关系，不同的信息层级之间，必定是存在逻辑关系的。

其中，用户感知层以及数据层，通常能够简化成一层。那是因为，用户端的功能表达常常逻辑简单，并且数据的来源问题并非是自身产品的核心功能。然而，功能模块层却需要依照自身产品的逻辑，把功能模块层里面的主要模块变为新的层级。

5. 处理同一层级内子模块的边界

各层次互相之间尽管存在关联，然而处于同一层次范围之内的子模块彼此之间必定是相互独立的，界限清晰明确。把针对不同问题的功能划分成两个子模块，达成一个问题仅仅在同一层予以解决，防止出现牵一发而动全身这种状况的发生。

6. 明确产品间的边界

产品边界，对开发设计那个与系统架构相关的内容而言很重要，对于业务间所存在的合作模式也极其关键。要运用不同颜色，清晰地标明在包含各个部分的产品框架里，每个部分归属于产品的边界，通常情况下，其中属于自身团队的那部分，会用亮色来进行表示。

7. 加入信息流转机制

不但产品架构图，当它在展现产品核心功能之外的时候；而且，原本是要体现信息流动路径的哟：也就是在目前这般层级那儿，数据之间展开交互之后，才得以形成产品功能，而这个产品功能，接着又会产生全新的数据，靠着这些新数据，才去推动下一层级相应功能能够运转起来。

要是当下产品的主要使用角色仅仅只有一个，那只用箭头把模块间信息流动的方式标明就行，要是当下产品涉及的主要角色比较多，就得用不同颜色的线条将他们与各个模块之间的信息交互关系展现出来。

8.最终检查

一张好的产品架构图，应该具备以下特点：

经过抽象的清晰模块功能边界，做到标准化、互相独立，上下游产品功能边界清晰，架构分层明确合理，具备迭代优化的能力，记得要依据你产品的发展情况不断更新产品架构图，每次修改过程对提升产品架构能力帮助巨大，认真完成，才会成功。

八、产品经理应该如何提升自我？

各位在产品经理这方面的相关能力，应当转变为具有具体化、针对性的，着重关注产品经理的核心能力，也就是框架思维。不要再是诸如逻辑能力、沟通能力、文档能力、学习能力等这类，在任何岗位都或多或少需要的抽象能力。

尽管产品架构和传统产品经理以用户为中心的基本精神是相通的，这里的用户并非公司产品的用户，而是公司内部的运维团队、产品团队以及技术团队。不过因其作为系统，复杂程度和扩展性要求，相较于做一个支付流程、做一个评论功能要大得多，所以一般的产品经理很难有接触的机会。除产品经理常规能力要求外，还有几个重点感悟想单独讲述一番：

去主动地学习这回事，那是要系统地去学习信息系统分析的方法以及技巧的，如此这般能够培养抽象化能力，与此同时还要理解业务流程、产品设计、系统开发相互之间的关系，存在相应的教材，它属于某些专业必修的那门课，比如说负责做注册工作的，起码可以接触得知注册的数据存放在何处，是怎样进行入库操作的，中间经由了怎样的技术实现环节，增删改查可能会出现何种场景，未来其他部门或者功能在哪些地方会用到用户信息，一般会具备哪些使用维度等等情况，这是一个相对较为完整的数据流程了。理解了数据流程以后，再去进一步思索业务发展点，诸如有未来运营部门有可能会运用这部分数据来搞用户运营，好比会存在精准的运营内容推送，如此就牵扯到数据关联，那对于用户数据这块儿他们怎样调用方能够最高效且合理。怀揣着类似这类问题去跟相应的开发或者运营部门进行沟通，不经意之时兴许就能够蹦出新颖的点子来，要是领导觉得考量没准便会让你去牵头开展了。 不予以关心？那除了每个月的工资其余的都跟你没什么关联了。 不主动积极 ，到哪儿去知晓这些事物呢。

2. 刻意地进行思考，在产品调研里，把产品架构当作一个单独的部分来开展调研。如今众多的产品调研报告之中，仅仅是从产品的现状，功能的要点，产品的形态等方面着手去做调研，却忽略了对于产品架构的调研以及分析。这还是致使很多产品只能抄袭到表面，而抄袭不到本质的一个缘由。要是没有透彻地剖析产品架构，便很难去领会一个产品的内在业务逻辑。在任何时候，都得留意产品架构源自于需求，要杜绝架构过度化，简单的才是优良的。

要是养成考虑极端情况惯常。眼下产品经理设计功能之际，全是正向思维，正常场景里不存在问题，然而针对一些极端情况却极少予以考虑。这同样是开发促使产品懂得技术的一个关键缘由。int不可以处于空值态，最大数量的上限究是多少，主键这些基础概念要是产品略知一二的话，往后产品的稳定性能够极大增强，需求返工的概率也会大幅降低。而这些细微之处常常是在数据库架构、接口规则制定之时必然得考虑的。

产品经理不但不存在专门用于培训的渠道，而且更为特殊的是，该职务所要求具备的能力范围极为宽泛，包含技术、设计以及业务。

一位产品经理所要理解的有技术，有商业，有运营，有产品设计，有项目管理等等，然而拥有这些领域方面的知识是为了达成一个关键的目的，那就是保证团队交付出色的产品。九、优质的产品架构图案例（引用）

产品结构图，看上去好像是一张简简单单的图，然而实际上，其背后暗藏着极大的复杂程度，而且这部分复杂，被提前放置到了思考的层面之上。要是你能够借助一张简洁的原型图、流程图，将一个产品、一项服务、一种生态以及一种商业模式呈现明白，那就表明你对这件事情做到理解透彻。

依据其他人分享的情况，我进行了整理，整理出了几张案例，这些案例能够给大家提供一些绘制方面的思路。对于那些想知道更多产品架构图相关内容的小伙伴而言，其模板库存有数量非常众多的资源。最后，期望大家都能够学会绘制产品架构图。

1、产品架构图