立即登入 做产品越久，越觉得基础的东西最见功力。比如各种“图”——功能结构图、信息结构图、产品结构图、业务架构图……刚入行那两年，经常被这些词绕晕。真正能分清它们、用对场合，往往是踩过不少坑、有了三五年经验之后的事。这里我想结合自己的理解，把这些概念梳理一遍，希望能帮还有困惑的人理出一条线。
先从功能结构图说起。它就是按从属关系把功能一层层拆开，画成一张图，每个框代表一个功能模块。模块可大可小，大的可能是完成一组任务的程序集合，小的可以细到一个具体的处理步骤。功能结构图通常不涉及字段细节，只关心功能之间的逻辑关系。拿微信举例，底部四个菜单——微信、通讯录、发现、我——就是顶层功能划分。点进“发现”，里面装着朋友圈、扫一扫、小程序、看一看等子功能。有一个细节很有意思：微信把第一个菜单就叫“微信”，而不是消息或聊天。我更愿意把这看作一种产品上的自信，就像微信一直强调自己是一种生活方式，这个入口就是生活的起点。
信息结构图一般在功能结构确定之后才出现。它要抽象地展示产品背后流转的数据和字段，帮产品经理理清复杂信息的组成，也方便开发做表结构设计。通常，功能框架清楚了，功能结构梳理完了，才会进到这一步。还是用微信的例子，比如一篇公众号文章，背后关联着一整套核心字段：作者、标题、发布时间、阅读量、在看数、评论内容、是否原创等等。把这些信息抽象出来，按逻辑关系排布，产品和开发对方案的数据层面就能心里有数。
产品结构图，可以理解成功能和信息的一张综合总图。看了它，你就能比较快地摸清一个产品到底有哪些功能，每个功能又围绕着哪些信息在转。很多时候，产品结构图一画完，原型上的交互和字段其实已经基本定型了。实际工作中，产品经理很少刻意把功能结构和信息结构分得那么死，因为页面上的功能本身就是围绕信息展开的，两者常常会自然融合在一起。这件事不用太纠结，只要能把逻辑讲清楚就行。我自己的习惯是，产品结构图没理顺之前，不急着画原型，否则很容易陷入细节反复修改，白白浪费精力。
再往上走，就是架构层面的图了。架构的核心价值，是控制系统的复杂度，把业务逻辑和技术实现解耦，让复杂的东西变得简化、标准化、流程化。一般可以分成业务架构、应用架构和技术架构。有一个好记的比喻：业务架构是战略，决定要做什么、怎么赚钱；应用架构是战术，负责把业务落地成系统模块；技术架构是装备，解决具体用什么技术实现、怎么部署。
产品架构图，有时也叫业务架构图，它关注的是产品底层的业务逻辑和商业模式，面向公司层面，偏战略。这张图一旦调整，往往意味着产品维度的大变动，功能和信息都会跟着变。比如美团的业务架构，核心就是吃喝玩乐，围绕优惠、折扣、履约效率展开，拆出外卖、到店、酒旅等业务。落到外卖这个具体业务上，又会进一步拆出用户端、商家端、骑手端，考虑怎么让用户更快找到折扣、骑手更快送达。即便某个骑手送餐时绕了路，从平台整体看，算法追求的是全局的公平和高效。
应用架构图，承接业务架构的落地，也会影响后面的技术选型。常见的划分如单体式架构和分布式SOA架构。在分布式架构里，不同的应用相互独立，内部高内聚，应用之间松耦合，可以灵活地进行分布式部署，但缺点也很明显——应用之间的通信连接需要额外的工作量，整个架构设计变复杂，维护成本也上去了。技术架构图就更贴近实现层面了，虽然涉及的技术模型很多，但拆开看分组其实很直观，可以把它理解成具体的装修施工图，剩下的就是技术人员按模块分批去实现。像美团的技术架构图，背后是极其复杂的业务体系，消息队列、微服务、数据同步、各种中间件都堆在里面，一张图就能看出技术的分量。
最后想提一下组织架构图，它虽然不属于产品设计图的范畴，但很值得产品经理留意。组织架构图决定了企业的部门设置、职能划分和汇报关系，不同公司的差别很大，在不同时期也经常变化。像腾讯的组织架构图，你能从中读出很多信息——微信事业群的地位，内容与平台事业群的重要性，以及某些关键人物的分管范围。这些东西，往往能帮你理解一个产品决策背后的公司逻辑。
以上这些，是我结合项目经验和各种资料梳理出来的一点理解，肯定有不够准确的地方。但这些图之间的区别和联系，真的值得反复琢磨，多用几次，自然会变成自己的东西。