说起产品架构，有些人或许会觉得陌生，但说起“技术架构”就会比较熟悉，产品架构，本质上与技术架构类似，是站在使用者的角度完成对业务需求的解读。本文总结了产品架构图如何画的方法，一起来看看吧。
有没有遇到过这样的场景：
老板：我们最近打算要上一个**产品，你先规划规划，回头我们一起讨论一下？
那么，规划什么？讨论什么？
这就是我们今天一起去讨论的话题：产品架构图。
说起产品架构，有些人可能会觉得陌生，但说起另外一个词“技术架构”大多数人都会感觉熟悉。
技术架构，从技术角度完成了对线上业务的解读，将企业的业务需求转化为可实现的技术方案，既需掌控整体又需兼顾局部。
那么产品架构，本质上与技术架构类似，是站在使用者的角度完成对业务需求的解读。借助技术架构中流行的一句话：一切脱离业务的架构都是耍流氓，产品架构亦是如此。
产品架构图，是产品经理站在使用角度对业务需求的解读，是产品经理表达其对产品整体设计和规划的可视化图形。产品经理根据产品的战略定位，将产品功能信息化、模块化、层次化的呈现，并展现出不同层级的交互关系、功能模块的组合关系及数据和信息的流转关系，以此传递产品的战略定位、商业模式、业务流程，甚至是发展规划。
从产品架构图的定义就不难看出，产品架构图图的主要作用有以下几点：
a、根据产品战略定位，确定产品的用户角色和需求；
b、根据用户需求，推导出产品功能；
c、对产品功能进行统筹和规划；
d、对技术&运营等环节的输出形成支撑，为其他人的输出节奏提供依据。
要画好产品架构图，需要既有全局思维，又有考虑细节。这个过程不会一蹴而就，多尝试积累，总会有进步。这里总结了画好产品架构图的六大步骤：
在画产品架构图之前，先要确定产品的战略定位。这个战略定位，有可能是老板直接给你的，也有可能是你根据公司的产品组合确认的，还有可能是你通过竞品分析得来的。
无论哪种方式，你都先确认好产品的战略定位，它帮助我们：
a、确保产品与企业战略一致；
b、确认产品的目标人群；
c、确认产品与其他产品或平台的系统边界和组合关系；
d、确认产品的市场定位目标；
有了战略战略定位，就能确定产品的目标用户是谁，这些用户是否又有细分，他们的需求又是什么？举个例子来解释一下：
比如：To C类产品，购物网站，用户大致分为3大类：购物物品的消费者、发布商品的商家、维护网站运行的平台运营者，这3类用户，他们的角色不一样，在网站上的诉求也不一样。消费者需要搜索到产品，需要查看商品详情，需要完成产品购买，需要对订单（购买）进行管理；商家需要发布商品、需要对店铺进行线上装修、需求咨询答疑、需要订单（售卖）进行管理等；平台运营者的需求又不一样。
再比如：To B类产品，某银行的零售营销平台，分为：营销策划人员、营销主管、渠道管理人员、系统管理人员等，他们的角色和需要亦不一样。营销策划人员需完成客户分析、客群探索、活动创建、活动评估等；营销主管需对活动进行审批、活动执行情况查看等。
（示例：营销平台功能和角色对照表，部分）
确定了用户角色和需求，其对应的业务流程亦出来了。每个角色，要完成什么工作，涉及到哪些功能，就很好梳理了。
比如ToB营销平台的案例，其活动流程涉及2个角色：营销策划人员和营销主管。
（整体活动流程）
在整体流程下，有时又可能按场景再细分，同一个功能，在不同角色下，需求也不一样，如审批功能：
（营销策划人员）
（营销主管）
这些业务流程的梳理，串联起整个业务线的架构。
业务流程的推导，常用的有以下几种方式：
A、根据业务边界来推导，即某个业务具有相对独立性，比如购物网站中的物品搜索业务和物品下单业务；
B、根据业务场景来推导，如上文所示，这种推导方式，对业务沉淀要求较高，容易覆盖不到所有场景，但有助于多角色和多功能间的逻辑关系梳理；
C、根据角色的职责边界来推导，即当一个角色完成一件事后，由另一个角色开始履行职责，如公司内部常见的请假流程、报销流程等。
当每个角色的所涉及到的业务流程梳理清楚后，我们就需要推演每个业务流程所涉及的各个业务点上，用户需要完成什么工作，输入输出是什么，会遇到什么样的问题，我们需要用什么样的功能、页面或处理机制，才能支持用户目标的达成？
如此这样，依次推演出所有业务流程所需功能。
根据业务流程完成功能推演之后，还不够，还需对功能进行聚合，这种聚合可分为2个方面：
A、对功能进行模块聚合
按模块进行聚合，可以是同一功能的不同面进行组合，如：审批功能（审批者的审批功能和提交审批者的撤回审批功能）；亦可以是不同功能，按业务场景或业务定义和理解放到一起的功能组合，如：营销中的“客群”生成，可以由多种功能完成（名单上传、标签圈选、预测模型生成、外系统接入等），这些功能组合成“客群”模块。
B、对模块进行层级划分
当功能模块化后，我们就需要按照一定的规则对模块进行划分。这种划分规则，没有固定的标准，常见的有：数据层、功能层、应用层、用户/终端等。
（示例：源启指标管理平台）
实际操作时，建议可以从以下几点进行考虑：
A、明确架构分层（需同时注意横向和纵向）；
B、处理不同信息层级的边界；
C、处理同一级内子模块的边界；
D、明确产品间的边界（组合产品形成产品矩阵时）；
信息流转机制，是产品架构图的最后一步，也是最容易被忽略的一步。产品架构图除了对核心功能的表达外，还应体现信息流转的路径：当前层级或模块的数据，产生新的数据，新的数据又推动下一层级或模块数据的产生。
这种信息流转机制，通常用箭头表示，但对比较明显的层级关系，也有不少隐藏箭头的。总的来说，一定有一个数据流的方向性，或从下往上，或从左到右，或者从下往上中局部包含从左到右等。
（示例：源启数字构建平台）
至此，产品架构图就完成了从想法到落地的，从业务需求到功能实现的转化，将不可能变成可能。
文末再提一点，现今单独一个产品完成所有业务需求的可能性越来越小，随着对行业的深耕，更多的时候是以产品组合或产品矩阵的方式存在，形成整体解决方案，为客户提供全方位服务。
所以，我们作为产品经理，在进行产品架构图的设计时，系统边界、与外系统的上下文交互、合力形成整体产品卖点等，也是我们需要重点考虑的。
本文由 @产品路上 原创发布于人人都是产品经理。未经许可，禁止转载。
题图来自Unsplash，基于 CC0 协议
该文观点仅代表作者本人，人人都是产品经理平台仅提供信息存储空间服务。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。