No. 9: 产品架构那些事

2016/9/25

产品经理要不要懂架构？我的答案是：不一定懂代码，但一定要懂”数据怎么流”。

我第一次画产品架构图时，画了一堆方框和箭头，像个功能地图。后来才发现，架构不是”把功能框起来连上线”——它是数据从哪来、经过什么处理、最终变成什么输出的完整路径。

我用一个比喻来理解这件事：产品架构像设计一套水渠系统。

1️⃣ 水渠理论

先做一组映射：

• 产品定位 → 解决哪片区域的用水问题
• 用户需求 → 日常用水量多大
• 数据库 → 水库、江河湖海
• 业务流 → 水渠怎么转弯、分支
• 产品后台 → 大坝——控制数据流转的开关
• 产品终端 → 水龙头、花洒、马桶

数据库是水库——数据表的长度和数据类型，决定了水库的容量。

业务流是水渠——数据怎么流动、在哪转弯、从哪入水、从哪出水。

产品后台是大坝——控制数据流转节点什么时候开闸、关闸、开多久。

产品前后端的数据流转，本质上就是水从水源经过水渠到水库，再通过水管流到用户的过程。

2️⃣ 五层架构

如果把产品从抽象到具体拆开，大概分五层：

战略层： 产品定位和用户需求。我们通过产品得到什么？用户通过产品得到什么？用户是谁，需求是什么。

范围层： 功能和内容。产品有哪些功能模块？需要哪些内容支撑？这一层决定”系统要做多大”。

结构层： 从抽象到具象的转变。把战略和范围的理解，结合用户的实际业务场景，转化为：

• 底层数据架构设计（建数据库）
• 底层数据流转设计（画业务流程图）
• 底层数据展现设计（建业务表）

框架层： 用户体验。基于结构层的积累，设计具体的界面和操作方式——数据怎么交互，功能怎么交互，用户怎么操作。

表现层： 视觉。把框架层的东西用视觉、听觉、触觉的方式呈现出来。

3️⃣ UML 不是让你画的

我费了不少功夫研究 UML。统一建模语言，包含 9 种图、4 种关系、4 种事物。当年觉得这些是产品经理的必修课，现在回头看——UML 是沟通工具，不是考核指标。

对产品经理来说，UML 最有价值的是两个用途：

• 和开发对齐——一张序列图胜过一千字 PRD 描述
• 梳理逻辑——画状态图可以帮你发现隐藏的分支和异常

但不是每张图都该画。类图让工程师去画，产品经理更该关注的是用例图和活动图——它们帮你把业务逻辑讲清楚。

产品架构不是画一张漂亮的大图。是让每个模块都知道自己该做什么、不该做什么、出了事找谁。 就像水渠里的每一段水管，都知道自己要流到哪里去。