详解产品经理的流程/结构/架构图
在工作中，全方位地了解产品设计的前因后果，需要通过结构/流程/架构图，配合文字说明，对解决方案进行阐述。
具体场景，需要用这三种图去进行阐述，让业务员、研发员、测试员、UI师等人员看懂、快速理解，已降低沟通、交流成本，三种图分别的功能如下：
结构图：用来说清楚产品有什么、是什么。
流程图：用来讲清楚产品功能的主要业务逻辑，把业务关系、业务规则及主要流程讲清楚。
架构图：这里指业务/产品架构图，用来说明产品底层的设计，偏战略；比如展示如何为用户提供价值，以及企业可以通过什么方式来实现盈利的问题。
一、结构图：
关键在于结构化的拆解，要通过需求方法论、场景化的需求分类，将该产品设计分解成对应的结构层次中以功能模块为类别（产品常用的脑图/思维导图，也是结构图），结构化更加清晰，也方便查漏补缺。
在产品梳理具体场景中，我们通常分为功能/信息结构图（产品结构图=功能结构图+信息结构图）。
功能结构图：以功能模块为类别，介绍模块下其各功能组成的图表。专注在产品功能模块的逐级延展，如微信底部的微信、通讯录、发现、我四个模块，然后逐级展开罗列子页面功能。图例如下
信息结构图：脱离产品实际页面，将信息进行结构化梳理。专注在产品不同类型的信息，逐级延展，罗列信息字段；如当一个人写简历的时候，大致包括姓名，性别，联系方式，工作单位、时间、职位，毕业院校，毕业时间等，但是一一罗列就会十分繁杂，所有我们会将其梳理成几个分组，包括基本信息、工作经历、教育经历。这就是对“一个人”的结构化信息描述。而信息结构图就是将业务中的对象按上述方式进行梳理。图例如下
二、流程图
流程图五个要素：角色、活动、协助关系、分支、产出物
角色：业务相关方，通常需要用泳道来分隔不同角色，也就是涉及到的系统/角色有哪些。
活动：业务角色做的具体每件事情，也就是每一步流程，也就是业务流程需要进行哪些活动/动作。
协助关系：协作关系包括并行、顺序、异步等等，这里主要是形容不同活动之间的发生顺序，也就是系统之间是如何进行这些活动的。
分支：流程图中的分叉，通常由判断产生。
产出物：通常指的是文档或者数据表等。
抛开简易主线流程图，介绍两种常用的流程图展示形式：
泳道图：产品经理最常用也是最简单的流程图展现形式，常常被用于描绘完整的业务流程和简单的产品流程，日常工作中常用多泳道图来构建整个的业务流程。通过这个如下这个泳道图，可以清楚的看到在业务的过程中，四个不同角色在申请GPS的不同阶段可以做出的全部选择和应对，从而形成整体的流程闭环。
时序图：需要多个系统参与的产品流程，那么多泳道图会显得不够直观。那么针对于这种情况，更推荐使用的是时序图，时序图本来就是用作专门描述产品流程的一种专门的流程图形式，能够清晰的展现出在产品中复杂的前后模块之间的关联关系，整体的数据流走向，各个模块在不同流程中所应该承担的工作以及各种判断过程，当产品经理能够准确的使用时序图来展示产品流程时候，意味着这个产品经理的技术能力已经差不多过关了，可以和大部分的研发无障碍的battle
将流程图按照描述内容的维度进行切分，分为业务流程图，功能流程图，页面流程图。呈现效果根据不同画法呈现结果差不多就不放图了，（上述泳道或时序图是不同画法，这个是不同说法，且说法多于市场流传，UML中并没有这些说法概念，这种归类并不严谨，边界也并不固定，但架不住行内外都用，肯定需要懂）
任务/功能流程图——描写系统或模块内部的任务/功能流向的图表（比如登陆功能、添加购物车功能等等）
页面流程图——具体到了网站、系统、产品功能设计的时候，表现页面之间的流转关系——用户通过什么操作进了什么页面及后续的操作及页面。相比功能流程图，它把系统呈现的更体系了，到了页面的层级，通过页面流程图甚至可准确评估整个产品需要多少张页面了。
业务流程图——业务关系，作业顺序和管理信息流向的图表，大白话就是按顺序描述某一事项执行流程的图形化展示形式，描述业务流程的时候，业务流程的活动之间有严格的先后顺序限定（流程），业务流程里活动的内容、方式、责任等也都必须有明确的安排和界定（角色），除了上述的逻辑规范，还有个简单小技巧去校验流程是否考虑完整（课本学过的故事六要素：时间地点人物、起因经过结果）。
三、架构图
企业架构分为业务架构、应用架构、技术架构
其中业务架构是战略，后两个是战术装备，归属IT，具体架构的内容后续企业架构内容会做详解，这次以讲图为主，本文均以业务架构（又叫产品架构）作为作图案例。
对产品架构最直观的感受是，产品架构是一个由框框组成的架构图，类似于下图一样
实际上，产品架构是产品经理用来表达自己产品设计机制的图，一种表达业务层级和关系的工具，设计的核心在于多维度的结构化分层。
它将产品功能落地为信息化、模块化、层次清晰的可视化架构，并通过不同分层的交互关系、功能模块的组合、数据和信息的流转，来传递产品的业务流程、商业模式和设计思路，一般是在复杂的产品或者规划初期出现，用于呈现产品的大致规划。
作用就是：将复杂的业务逻辑简单化，降低理解难度，在复杂项目开始前画产品架构，这样可以避免就不断改需求、推翻之前的计划重新规划等低效工作的情况。
产品架构图规范：
思考产品架构是一个体系化、流程化的思考过程，它总共区分为四个层面。
第一层面：层面范围，在范围层面主要思考一个产品主要涉及哪些系统，比如支付体系作为一个产品，可以由上图四个系统组成，通过对范围的思考，从而界定产品是什么不是什么的问题，从而可以界定思考产品架构的思考范围。
第二层面：在确定了组成产品架构的系统有哪些之后，我们需要进一步思考每个系统的组成。先不要思考具体功能和技术是什么，而是对系统进行分层。比如我们经常听到系统由业务层、数据层、表现层组成。对系统分层的思考实际上是系统组成部分的分类，比如技术相关的部分组合成为技术层，业务相关的部分组合成为业务层，数据部分相关部分组成数据层。分层的意义在于每一层由不同人员负责，比如业务层是由产品经理负责，技术层就由技术架构师负责。
第三层面：将系统分层之后，需要对系统进一步的研究，系统是具体由哪些功能模块组成，在这个层面需要明确每个系统模块之间如何通过不同的数据进行连接
第四层面：在思考完成框架图之后，就要对每个模块进行进一步的拆解，这个层面的拆解主要是从流程上进行深入的思考。通过对产品流程的思考来思考具体的产品是怎样使用和运行的。
画业务架构图实际上就是对业务的一种收集、提炼、拆解、归纳、分类的一个过程，可以分为三个步骤：
功能穷举聚类:将业务流程图中每个节点下所有的页面、功能或处理机制以模块化的形式功能矩阵，然后通过业务的边界来归类，比如一个内容电商产品，内容运营就存在三个不同的端的业务：官网、公众号、营销触达媒介，其中官网产品，可以如下模块功能穷举
横向体现：将同一范围或产品功能放在一个横向层级中，在同一个层级中，有哪些独立模块，可以代表一个完整的产品或是同类型的业务聚合。如图
纵向体现：架构层级的关系，明确不同产品或系统之间的边界逻辑，下层更抽象，上层更具体，比如下层为上层服务，或者提供能力支撑。如图
通过这种方式，一份清晰的模块功能边界 功能做到标准化、互相独立，上下游产品功能边界清晰，架构分层明确合理的产品架构图就做好了，产品架构图的绘制并不复杂，关键在于实际工作中的运用,看似是一张简单的图，其实背后蕴含着巨大的复杂，这部分复杂被前置到了思考层面。
四、总结
流程/结构/架构图使用总结：
用来表达操作流程，用流程图。
用来表达每个模块或页面有什么功能，用结构图。
用来表达底层设计和边界，表达功能之间的关系，用架构图
文章摘自知乎《三种图-流程/结构/架构图，搞懂产品经理的业务梳理和展示》作者：产品钟善
