产品架构图是每个产品线经理日常都需要画的一张图，属于产品经理必学基本功。
今天重点和大家聊聊怎么画产品架构图，以及为什么产品架构图画的挺好，但是系统还是做的很烂的问题。
基本功这玩意，没人会在意，除非是害怕跳槽，面试官问到这个知识点，才有人去学基本功。
没办法，大部分产品经理都是 to money 导向，什么值钱咱学什么。
最近发现有人不会画产品架构图，甚至连什么时候画产品架构图还分不清。
比如看我的一位读者朋友的回答怎么做产品规划：
"那我斗胆给大佬补充一下规划后执行的部分
1、产品架构出来后，还需要梳理一下业务流程
2、根据产品架构 业务流程，整理功能清单，用剥洋葱理论，一层层细化功能点及相关的逻辑限制
3、梳理功能流程以及数据流向，相关产出文件为功能流程图、时序图
4、动手画原型，写需求文档
6、进入研发（到项目管理阶段），写产品使用手册/用户手册"
首先鼓励他能够有自己的思考,并且爱发言，但是他第一点其实描述是有问题的，正确的流程应该是先梳理业务流程，出业务架构图，再画产品架构图。
最近还遇到一个问题，有些人产品架构图和系统架构图傻傻分不清的情况。
其实这也好区分只要记住系统架构图大多是研发参与画的，系统架构图是研发为了梳理好内部各个系统的关系。
如果产品经理要梳理好系统各个功能模块之前的关系，本质都是各自岗位希望一张图能把系统内部的层次和连接关系讲清楚。
只不过一个是产品角度，一个是技术角度。
当然很多产品经理也懒得画产品架构图，于是乎拿系统架构图来当产品架构图来用。
也有很多人的产品架构图画着画着就变成了系统架构图和产品架构图的混血儿。
画出来的图也好像这么回事，不细看你还真挑不出他们的毛病。
那么产品架构图具体要怎么画呢?
第一个是抽象思想，将业务流程图中所有功能类似或者范围有包含关系的机制/功能放在一起，以模块化的形式形成一张简单的矩阵图。
第二是将明显是同一个功能的模块放在同一层级，得到一个基础的产品框架。
第三是对产品架构进行分层，一般是分为用户感知层、功能模块层、数据层、基础配置层
第四是明确各个功能模块的边界问题，比如信息传递相邻的模块直接可以放到一起。
最后是明确信息流的交互方式，比如最底层向上传递信息，最上层收集信息反馈到底层。
这样一张产品架构图就出来了。
网络截图
那么有了产品架构图，产品系统就能做的很牛皮吗？
答案是否定的，特别是互联网产品小步快跑的情况，初期系统都是非常简单的，无非是增删改查的合集。
而不管是产品架构还是技术架构图都只是个大概意思，很多只是一个样子货，与实际技术实现差异很大。
一来是因为整个软件系统的关系特别复杂，很难展示很多细节，大部分是系统的简化，同时在汇报和对外展示的时候，也需要简洁，所以只要画的关系明白就可以。
于是乎变成了你画你的，实际系统开发还是怎么简单怎么来，所以迭代多了，屎上雕花成了必然现象。
除非业务稳定之后，那么有机会对系统进行重构，那么这时候的系统可以考虑好好设计一下产品架构。
现实情况是大部分互联网公司是产品概念一出来，就开始发pr稿，系统要求一个月就开发好，其实很难有抽象的思想在里面。
如果最开始就没有做好分模块去设计系统，最后的结局就是系统在最后冗余字段非常多，后接手的产品经理看不懂前人做的系统。
当要做一个新功能的时候，由于不理解前人的业务，或者前人设计的系统没有扩展性，最后是相似的业务，做了两套不同的功能。
建议产品总监除了要做产品规划，也要是一个合格的产品架构师，去整合不同产品经理的需求，以及不同业务的需求，对其进行抽象复用。
这样才能谈得上有产品架构。
具备产品架构师能力的人需要对整体业务非常了解，能够把业务进行很好的抽象能力，这需要和细节以及业务不断的死磕。
其实要做到也不难，为什么没人想去做呢？
现实生活中是大部分业务系统其实根本不care产品架构。
只要系统能跑就行，大部分公司的业务指标考核大于系统指标。
所以规划是一码事，实际产品设计又是另外一码事。
根本原因还是资源问题，资源决定了系统的好坏，资源好造汽车也能给你造车来。
作者：陈雪涛 分享产品技能和产品思维干货，广交产品好友，促进产品经理文化普及。
,
