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

产品设计体系正日益趋向完善。产品经理具备的能力存在诸多方面，举例来说，有设计能力，还有运营能力以及规划能力。只是产品架构能力乃是最难之处，它要求自身拥有极为强大专业能力以及行业经验。

身为产品设计的顶层部分，这么讲吧，能不能将产品框架设计妥当，展现出来的便是成熟的产品经理与产品小白之间最为关键的差异所在。产品经理应当怎样去提高自身的产品架构本领呢？怎样从整体层面去设计产品的总体架构呢？怎样规划未来的产品发展途径呢？又怎样整合整个相关的产业链呢？

对产品进行架构思维，把它析解成条条块块，针对这些部分展开分析与设计，这是一个关键动作，而产品架构思维与抽象彼此依托，借助抽象，能把上述那些部分简化成关键概念以及模型，以此达成对问题更优的理解与处理，产品架构思维和抽象是两个关键概念，它们相辅相成 。

当然，没必要把产品架构讲得太过玄奥，诸如什么生态啦，多实践啦，要做个多少年之类；是啊，实则产品架构应当是且必然是能够方法化、技巧化的 。

一、什么是产品架构？

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

产品架构，是针对商业模式里核心业务场景所作的抽象，它体现出商业模式的运作以及实现方式，产品架构设计，乃是对业务场景进行抽象，借由业务规则去构建产品内在逻辑的过程，产品架构的对象，即为产品的商业需求和用户需求，怎样使满足产品这两个需求的产品设计，更简单且高效地展开规划，这便是产品的架构 。

把复杂事物予以简化是抽象，简化成的是一组关键概念或者模型，这么做是为了能够更好地去理解问题，并且能够更好地去处理问题。

将原本一个个处于孤立状态的产品，予以带有特定侧重的梳理编排组合，这便是产品架构。而后，在这样的架构之下，满足用户需求变得更为简便，满足商业需求亦是如此，同时产品设计方面也变得更加简易，此即产品的生态。其并非简单地把孤立的产品连接起来，而是借助产品架构将它们组织起来。至于这种因简单而带来的高效，那自是不言而喻。在此存在着两个至关重要的目标：

1、满足需求高效简单；

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

对于产品架构设计来讲，著名的奥卡姆剃须刀法则同样是适用的，通常架构越是简单的情况，产品越发容易实现成长，而且其适用能力也就会越强。

产品架构所需考虑的应是和产品相关的各类影响因素，这其中涵盖了用户需求，产品战略，商业需求，开发资源，市场运营人员等，这些不断变化的因素，一个合理架构所要努力做到的是尽可能以最简单方式应对种种变化，细分开来讲，会发现产品架构包含两个重要方面，也就是需求架构及设计架构 。

需求架构较多的是业务架构，也就是将用户需求，与商业需求，以及业务流程，于产品层面进行合理的组织，并且做轻重缓急的设计。这同样是产品架构最为主要的事情。设计架构，是在产品设计之际，保障产品在设计层面，通用和可重用的元素保持一致，这是个更为细节的层面，用以提高设计效率。

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

极其强烈地建议，在那种具有复杂性的项目开始着手之前，去绘制产品的架构，如此这般能够防止出现一而再再而三又再三以及反复地更改需求，并且推翻之前所制定的计划从而重新进行规划等具有低效率特性的工作情形。与此同时，当去勾勒产品架构图之际，你能够以一种良好的状态去规划整理自身所拥有的产品 。

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

所谓架构，是针对架构自身的对象予以合理的抽象，这般操作的结果是使得架构的对象在效能方面更具高效性，在构成方面更显简单性，在使用层面更具易用性，在变化特性上更具易变性。简而言之，架构的目的在于达成简单以及高效这两个特性。架构并非是那种完美存在所呈现出的最终成果，而是一个持续进行改进优化的进程。然而，在架构的每一个节点之处，都存在着在质量好坏以及数量多少这种维度来区分评估状况，而这同样是架构能力予以展现的一种方式。

以对象而言，产品构成框架与技术构成框架存在差异，前者所关注的是需求以及设计，后者所关注的是硬件、软件还有数据。产品构成框架主要涵盖的是那个称作应用的层级、称作服务的层级、称作支撑后台，技术结构框架而言那属于经过简短化处理的技术构成框架，。

产品能力凭借技术手段得以达成，此为技术架构，聚焦于服务器、网络、中间件、操作系统等偏向技术层面所涉及的要点，技术架构图以展示实现方式的形式呈现出软件系统的实现结构。举例如下：

为了实现某个目标，可以把庞大的任务拆解成诸多相对易处理的小任务，进而逐步推进，其中的核心要点以及关键环节，在此处不做详尽的阐释，着重探讨的是达成任务过程中所运用的具体方式：在特定的应用层面，借助一回用户行动从中获取相关的数据，接着经由服务层面将所获取的数据传送到逻辑对应的层，逻辑对应的层运用代码所达成的既定条例对数据层面的数据施行处理，处理行径完结之后再以相反的方向告知到应用层面，向用户予以反馈，如此这般也就达成了一回用户来往。

我们先来说广义的情况，产品架构在广义上，它是业务该结构的那样一种镜像，它所描述的呢，是从实际业务里抽象出来的呀，那些需求，也就是所提到的子需求，还有需求是怎样借着在系统当中，也就是子系统之间的方式来进行交互的呢，最终是那个被满足的过程。再说说狭义的情况，产品架构在狭义上，指的是需求以及交付物之间的那种关系。用下面这样一个表格来进行说明：

产品架构被划分成五个层面，涵盖战略层、范围层、结构层、框架层以及表现层，这五个层面，其中每一个层面均由它下方的那个层面对其加以决定，从战略层直至表现层，这实际上是从抽象状态朝着具体状态转变的过程；这五个层面并非彼此孤立存在，意思就是并非要彻底完成“底下一层”方可开展“上面一层”的工作，而是要使得每一层面的工作在其下一层面能够结束之前即得以完成；在实现层面，系统架构应当包含数据、业务/商务、运营、营销等一系列整体业务流 。

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

展现产品设计机制的概念图，是产品经理所运用的产品架构图，它把可视化的具身产品功能，转化成信息化、模块化且层次明晰的架构，借由不同分层的交互关联、功能模块的搭配以及数据和信息的流动，去传达产品的业务流程、商业模式与设计思路。鉴于产品架构图常常应用于颇具复杂度的产品项目里，现阶段介绍产品架构图的相关书籍和资料极为稀少，特别是入门级别的资料鲜少涉及，然而它却是设计复杂产品时不可缺少的文档之一。

画出产品架构图到底有啥目的呢，其一在于它能让产品规划者知晓自身产品的构成部分，其二是能使其清晰且直接地明白各业务单元间的逻辑关联，其三方便在开展业务分工之时进行梳理以及配合协作，其四利于对产品迭代计划也就是 Roadmap 予以拆解，其五可为技术架构以及运营增长计划提供助力，其六架构图还是高阶 PM 所必备的产品规划能力的直接呈现 。

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

按照产品战略定位，去明确产品的用户角色，再明确产品的需求，进而确定产品包含哪几个端，。

将自己对于产品方向的判断予以梳理开来：也就是能够以算是比较清晰且简捷的那样子呈现出自身的思路，明确自身的产品边界所在之处，指明其发展会朝着的方向是怎样的这般情况。抬头瞻望道路和低头踱步着前行同样具备关键意义，然而在朝向产品方向来进行把控的起始阶段之时，它们二者之间的先后次序显得格外重要。思索这张图究竟是怎样去设计的整个进程，同样也是助力你去梳理诸如“在半年的时间范围之内自己所做的产品应当朝着哪里去发展、需求具体应该怎样按照阶段来划分以及实现落地效果、和其他产品之间存在着怎样的依赖关系、竞争关系又是怎样的状况、未来所具备的可拓展性究竟在哪些方面”等一系列问题的进程 。

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

当一个角色达成一件事情后，另一个角色开始执行应该履行的责任，那么这两个角色的责任就被拆分成两项业务。像电商业务那样，在用户下了订单情形出现之后，接着轮到平台去进行发货操作，下单以及发货这两项行为能够被拆解成两项业务。

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

要是讲一刻不停歇接连不断地去开发产品属于只顾低头前行，那么像“未来一年得设计怎样的产品、需求该怎么加以分期以及落地去实施、与其余产品之间构成的依赖和竞争关系是怎样的、未来具备的可拓展之处在哪儿”这般经过先行用心思索以及精心规划的一系列考量，便是抬头去观察道路状况，唯有先把道路看清弄明白之后再迈步出发，才能够稳健而精确地走好脚下的每一步行程。在成功获取功能之后，便能够将功能要点填入到与之相对应的端口之中。一旦功能数量众多情况复杂，就能够依照实际情形适度地对功能开展详细分类划分，依靠此法来使得架构图更具清晰分明的层次感。架构图是在产品规划的早期阶段所运用的，因而仅仅需要展现出产品的整体轮廓以及大的功能导向即可，可以不涉及过多的功能细节，也没有办法去涉及，毕竟距离产品问世还很早呢。

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

产品架构图被设计出来之后，依据其结构与路径，可以清晰地拆解出项目的里程碑，明确的东西能助力他者迅速构建对于项目中产品结构、功能、交互以及复杂度诸般问题的认知，与此同时，能够让技术与运营人员依据这架构图生成像项目推广计划、技术系统架构方案这类高度依赖产品方向的种种方案。

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

在业务发展刚开始的前期阶段，产品设计开发的相关工作时常滞后于业务创新，主要的工作内容是针对业务需求去做反馈和配合，产品经理以及工程师常常会有一种忙得晕头转向的失控之感，不过这算一个基础设施建设所无法缺少的阶段。跟着对业务理解的程度加深以及产品系统架构的完备，产品领先于业务，进入到系统化创新的阶段随即就要来临。系统化创新往往会以这样的一种样式来开展：业务流程被抽象成颗粒度极为细小的节点，借助四个办法以全新的形态呈现出来：

这4个方法，和在《简约至上：交互式设计四策略》里的那些类似，然而层面并不相同。

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

新零售所涉及的话题里，提到很重要位置的常常是组织架构变革，系统中台化趋势要求的是组织结构液态化，目的在于响应商业环境以及业务形态的快速转变；产品架构话题当中，组织架构以及产品经理个人呈现出的成长却总是常常被忽视。直接对产品技术研发类组织架构产生影响，产品架构最终的交付物是系统架构，会针对各子系统（子模块）之间的内容进行切分，PM和RD的工作内容以及协作关系依据此时确定。间接对整个业务流里各参与角色的职责内容以及协作关系产生影响，伴随业务发生变化以及系统进行改进，参与角色的工作内容乃至角色自身，都存在可能被改变或者取消的情形 。具备完成业务结构、产品/系统架构、个人成长这三者合为一体的情况，是对产品架构是否优秀进行衡量的一个关键视角 。产品架构存在评判点 ，好的产品架构，应当如同容器一般，能够提供空间（涵盖性能冗余、数据监控分析、损失管理等等能力），去容纳业务的不确定性（也就是创新），它属于一种系统机制 。评判点的相关说明 。

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

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

1、清晰的模块功能边界

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

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

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

随着产品发展情形，你能够持续更新产品架构图，每一回修改进程，对提升产品架构能力的助力极为庞大。

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

在这个网页链接所指向的内容里，其中的第五部分提到，究竟是谁能够去评判产品架构呢 。

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

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

六、产品架构如何实施？

近期同样在思索这个问题，然而所获取的结论相对简单直接，不知其正确与否，现将其发布出来以期进行讨论。

在理论层面来看，我认为上面那些回答讲得都蛮有道理的。然而从我的实践过程里所获得的感悟而言，实际上产品架构就是基于对产品用户需求进行充分详尽了解的情形之下，针对产品数据流转的逻辑性展开了梳理。可能这样表述太过抽象了，因而就贴出了上面那个回答当中的内容，具体如下：

我的“产品架构”理解起始于，在充分明晰面向用户需求后，从零着手拟定完全产品体系方案，且将其予以实现的进程。此进程涵盖产品形成的全流程，涵盖数据层的数据库表，后台数据处理平台以及运营维护平台，前后端数据交互体系，前端的基础产品框架等一整套系统的构建及运转逻辑。这便是所谓一个产品能够诞生前所需要的“骨架”。待这套骨架完工后，大家所熟知的前端功能、数据接口等实体性质的产品开发才切实开端。

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

架构最为突出的特性在于，其脑海之中不存在产品形态的观念，仅仅存有数据流转的进程，。

本质上，做产品架构的工作是在梳理数据流，要是梳理得顺利，那未来产品开展会极为顺畅，能迅速实现用户所需功能，产品稳定性也颇高，还可有效支撑数年乃至十几年的业务发展，与之不同的是，界面仅仅是数据的窗口或者入口罢了，那是未来前端产品经理或者后端产品经理要考虑的事儿。

要深刻领会不一样岗位的职责，还要深刻明白他们作业的事物，并且也要深刻理解最终的用户，。

换句话讲，要是开发以及运营、并且产品、还有市场的目标全是塑造出优质产品，那么架构师所要思索的便是怎样促使这帮人营造出良好产品。知乎一经典问题“产品经理是否要有对技术的了解”，并非是要求产品知晓写程序代码，而是明白技术在达成需求之际的长处、短处、风险。同样的，针对运营环节以及市场环节、还有销售环节都是这般的情况。

因为我所从事的是B端产品，或许跟C端产品在形态以及产品模式方面差异颇为显著，然而我认为追根溯源任何产品都是由一堆数据以及一个用于与用户开展数据交互的体系所构成，所以进行产品架构工作，本质上最为关键核心的便是数据的架构。

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

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

逻辑架构：

指示系统，中央的空调系统，水电气的网络系统，进水以及排水系统，而监控系统里的房屋结构系统……

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

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

所以，我觉得产品架构能力，就是指这两个方面，是否做到了考虑得全面又周到，并且架构得合理恰当。

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

1. 搭建基础框架

业务流程孕育出了基础的产品框架，然而，相较于业务流程而言，它将更为着重于产品功能的逐一列举，还在于功能模块相互之间的界限划分。

2. 详细操作步骤

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

把才获取到的好些流程图里，全部功能相近或者范围存在包含关系的机制和功能，放置在一起，要以模块化的样子组成一张简易的矩阵图。

把那些明显属于同一个产品范围的模块，以及有着同一组产品功能的模块，放置在同一层级，进而得到一个基础的就是那样的产品框架。

3. 明确架构分层

一个有着前后台关系的产品架构图起码划分成三层，一层是用户感知层，即于何种场景之下借助何种方式去触达用户，一层是功能模块层，也就是通过哪些功能模块达成产品的核心功能，又和哪些外部平台功能存在信息交互，还有一层是数据层，就是产品的数据源自哪里，产品的数据沉淀到什么地方 going。

在进行上一步操作简单分层之后，我们已然得到了一个初步的框架，然而不容易避免地会存在分层不够明确的状况，在这个时候，需要依照两种维度去处理架构图的层级，其所涉及的是不同信息层级的边界，亦或是同一层级内模块与模块之间的边界 。

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

构成架构图的层级所展现的实际上是信息彼此间的流转关联，不同的信息层级相互之间必然存在着逻辑联系。

其中，用户感知层与数据层常常能够被简化成一层，用户端的功能表达一般逻辑较为简单，数据的来源问题并非自身产品的核心功能，而功能模块层需要依据自身产品的逻辑，把功能模块层里边的主要模块转变为新的层级。

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

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

6. 明确产品间的边界

在开发设计系统架构时，产品边界极为重要，于业务间的合作模式而言同样如此。在产品框架里，要用不同颜色清晰标识出各个部分所属产品的边界，一般情况下，其中属于自己团队的那部分会用亮色来表示。

7. 加入信息流转机制

在表达产品核心功能之外的产品架构图，也应当体现信息流动的路径，当前层级数据的交互会形成产品功能，产品功能又会产生新的数据，进而推动下一层级的功能运转起来。

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

8.最终检查

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

先将模块功能边界进行抽象，使其清晰，实现标准化，让上下游产品功能边界互相独立、清晰，架构分层明确且合理，具备迭代优化能力，要记得依据产品发展情况不断更新产品架构图，每次修改过程对提升产品架构能力帮助极大，认真完成方可成功。

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

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

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

通过主动展开学习，系统去学习信息系统分析的方法以及技巧，如此能够培育抽象化能力，与此同时理解业务流程、产品设计、系统开发这三者之间所存在的关系，存在相应的教材，它属于某些专业必须要学习的一门课程，就像负责做注册工作的人员，起码能够接触到注册的数据被存放在了何处，是以怎样的方式入库的，中间历经了哪些技术实现的环节，增删改查可能会出现什么样的场景，未来其他部门或者功能在何处会运用到用户信息，通常会具备哪些使用维度等等，这构成了一个相对而言较为完整的数据流程 。先是理解了数据的流程之后，再进一步去思考业务的发展点，比方说未来运营部门有可能会运用这部分数据来做用户运营，又比如会有精准的运营内容推送，这就涉及到了数据关联，那么对于用户数据这块他们怎样去调用才能够最为高效合理。带着类似这样的问题去和相应的开发或者运营部门进行沟通，不经意之间或许就能够蹦出新的点子出来，要是领导觉得相关考虑没准就会让你去牵头搞了。。。不关心？那除了每个月得到的工资之外其他全都和你没有什么关系了。。。不主动，到哪里去知道这些东西呢。。。

2. 刻意地去进行思考，在产品调研期间，把产品架构当作一个单独且独立的部分来展开调研，当下诸多的产品调研报告里面，仅仅是从产品的现有状况、功能要点、产品的呈现形态等层面去做调研，而把产品架构的调研以及分析给忽视掉了，这同样是好多产品仅仅能够抄袭其表面，却抄袭不到本质的其中一个缘由，要是没有透彻地分析产品架构，那就很难去领会一个产品的内在业务逻辑，在任何时刻，都需要留意产品架构源自于需求，要杜绝架构过度化，简单的才应当是好的。

产品经理设计功能时，多是正向思维，在正常场景下并无问题，然而对于一些极端情况却极少予以考虑，这也是开发让产品懂技术的一个主要缘由。int不能为非空值，最大数量上限是多少，主键等这些基本概念，倘若产品能有所理解，未来产品的稳定性便能大幅增强，需求返工的概率也会大幅降低。而这些细节，往往是数据库架构、接口规则制定时必须予以考量的，3．对于养成考虑极端情况的习惯。

不是只有产品经理没有专门培训的渠道，而且更特殊的是，这个职位所需具备的能力跨度极大，包括技术、设计以及业务 。

一名产品经理得去理解技术，得去理解商业，得去理解运营，得去理解产品设计，得去理解项目管理等等，且具备这些领域的知识是冲着一个重要目的：确保团队交付伟大的产品，九、产品架构图优质案例（引用） 。

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

我将其他人的分享予以结合，进而整理出了几张案例，这些案例能够给大家提供些许绘制思路。对于那些想要了解更多产品架构图相关内容的小伙伴而言，ProcessOn的模板库存有诸多资源。最终，冀望大家都可以学得会画产品架构图。

1、产品架构图

继续浏览有关 产品架构架构设计 的文章