功能架构图是产品经理的基本功，但很多人画成了功能清单或菜单树。本文从本质出发，拆解功能架构图应回答的三个问题，通过设备管理系统案例演示四步画法，并总结四个常见坑与三个检验标准，帮你画出清晰、有用的架构图。

产品经理接手一个新系统，或者要规划一个新系统，第一步往往就是画功能架构图。

打开 Visio、ProcessOn 或者 PPT，鼠标停在那半天，不知道该先放哪个框。

放一个”用户管理”？那”账号管理”要不要单独放？”组织架构”算不算？”权限”归谁管？

越画越乱，最后干脆把需求池里的功能一个个往上堆，堆出一张密密麻麻、谁看了谁眼花的图。

这张图交上去，领导看都不想看，研发也觉得不知所云，你自己回头再看，好嘛，太多了，也有点看不下去了。

功能架构图是产品经理的基本功，也是最容易画成四不像的图。

之前写用户故事地图那篇，专门提醒过别把故事地图画成功能架构图。今天就反过来，聊聊功能架构图本身：它到底是干嘛的，怎么画才算画对。

先给结论：功能架构图画不好，根子不在画图工具，在于没想清楚它到底要回答什么问题。

一、功能架构图是干嘛的

简单来说，就是把一个产品的功能，按照”给谁用、干什么、靠什么支撑”分层摆放，让人一眼看清这个产品由哪几块组成，每块管什么，边界在哪里。

它回答三个问题：

1. 这个产品覆盖哪些业务？
2. 哪些功能是直接干活的，哪些是给别的功能帮忙的？
3. 哪些自己做，哪些靠对接外部系统？

打个比方，它有点像房子的户型图。

户型图不会告诉你沙发买什么牌子、墙刷什么颜色，它只说清楚几室几厅、哪边是动区哪边是静区、厨房和卫生间在什么位置。

你拿着它，一眼就知道这个房子的结构合不合理。

功能架构图也一样。它不关心某个按钮放在哪、某个接口怎么调，它关心的是，这一整个产品的能力，能不能被拆成几块说得清的部分。

所以，一张满当当的图不一定是好图。

能回答清楚上面三个问题的，才是。

二、先分清几种图，别画串了

产品工作里，各种各样的图一大堆；在实际工作的时候，很多”架构图”的问题，出在一开始就画串了。

常见的几种图，各管各的事儿：

• 功能架构图，画的是静态结构，系统由哪些模块组成。
• 业务流程图，画的是动态过程，一件事从哪里开始，经过谁，到哪里结束。
• 用户故事地图，画的是用户完成任务的路径，横着是做事顺序，竖着是每步的细节。这个之前专门聊过。
• 菜单树，画的是页面怎么组织，用户点什么能看到什么。

举个例子，还是上次说过的报销系统。

1. 它的业务流程图是：员工填单，提交，领导审批，财务复核，付款。
2. 它的菜单树是：首页、我的报销、审批中心、统计分析。
3. 它的功能架构图则是另一回事：报销管理、审批管理、发票管理、账户管理、消息通知、报表统计，各自占一块。

看出区别了吗？

流程图里”领导审批”是一个环节，架构图里”审批管理”是一块能力。菜单树上”审批中心”只是一个入口，背后可能同时调用了审批、消息、报表好几个模块。

三张图说的是同一个系统，但视角完全不同。

如果一张图里，左边画着模块，右边画着箭头表示审批流转，角落里还塞了几个页面名称，那它大概率已经串了。

串了的图，自己画得累，别人看着也累。

三、怎么画：举个例子

假设我们要做一个设备管理系统，管巡检、维保、备件这些事。分四步。

第一步，把功能摊开，先不管放哪

设备台账、巡检计划、巡检执行、巡检记录、维保工单、备件入库、备件出库、备件库存、费用统计、故障报警、用户管理、角色权限、消息通知、操作日志、报表导出……

先全列出来，不用着急归类。

这时候它就是一堆名词，没关系。

第二步，按业务域归类，不按页面、不按部门

判断标准很简单：围绕同一个业务对象、同一批人做的事，放一起。

设备台账，管的是设备这个对象的基础信息，自己一组。巡检计划、巡检执行、巡检记录，是一件事的三个阶段，一组。维保工单一组。备件入库、出库、库存，是备件从进到出的一生，一组。各种费用统计和趋势分析之类的，算设备运行分析，一组。驾驶舱，领导们喜欢看的，单独一组吧。

归完类，图上第一层大概是：设备台账、巡检管理、维保管理、备件管理、统计分析、大屏驾驶舱。

六个词，六个业务域。领导三十秒能看完。

第三步，把公共能力沉下去

再看剩下那几个：用户管理、角色权限、消息通知、操作日志、报表导出。

它们不属于任何业务域，但每个业务域都要用。巡检超期要发消息，备件不足要发消息，维保工单转派还是要发消息。

这类功能沉到下面，单独一层，通常叫公共支撑层。

说清楚，这一步不是为了省图上的空间。图上每个模块都画一遍权限，你保不住就真的有开发把每个模块各写一套权限。

公共能力沉下去，其实是逼着大家在动手之前对齐，有些能力，只做一份就够了。

第四步，标边界

格子里放不下的信息，用标注补：哪些本期做，哪些放二期；哪些自建，哪些对接已有系统。

比如操作日志，公司已经有统一日志平台，那就标”对接”，不用自己做。

功能架构图经常出现在立项方案里，它在这个场合的实际作用就是圈范围。哪些在圈内，哪些在圈外，比图好不好看重要得多。

画完大致长这样：上面一层业务应用，下面一层公共支撑，旁边标注本期二期。再往下如果要画基础设施，点到为止就好，那是技术架构图的领土，产品经理不用替架构师加班。

B端产品有个比较常用的分层方式，供参考：

• 最上面是用户层，写清楚谁在用。员工、审批人、财务、管理员。
• 中间是应用层，也就是核心功能模块，这张图的主角。
• 往下是数据层，说明系统管哪些数据。单据数据、发票数据、账户数据。
• 最底下是基础层，放支撑能力。账号权限、日志、消息推送、接口对接。

不一定非要四层，简单的系统三层也够。

分层的好处是，别人看图的时候有个阅读顺序：先看谁用，再看能干什么，再看底下靠什么支撑。

四、最容易踩的几个坑

第一个坑，画成了功能清单。

一堆框从上到下排开，申请管理、审批管理、消息管理、统计管理，看着整整齐齐，但没有层级、没有关系。

这只是一张打了格子的需求池，不是架构。架构要有”分”和”连”，光有分没有连，就是清单。

第二个坑，画成了菜单。

首页、申请列表、申请详情、审批详情、我的待办，这一串是页面的导航结构，不是功能架构。

菜单回答”用户在哪个页面点哪”，架构回答”系统由哪些模块组成”。两者长得像，回答的问题不一样。

第三个坑，模块边界不清。

“用户管理””账号管理””组织架构””权限”这四个框，在系统里面到底谁管谁，画的时候连自己都一团浆糊。

一个判断方法：拿一个具体功能来对，比如”给某个部门的人开放审批权限”，它应该落在哪个模块，只能有一个答案。对不上，就是边界没切清。

第四个坑，一上来就求全。

把需求池里所有功能都塞进图里，恨不得一张图装下未来三年的规划。

图越全，越没人看。

功能架构图是可以分版本的，第一版画当期要做的，往后的用虚线或者不同颜色标出来就行。

越当前的越详细，越往后的可能就越粗。

五、怎么知道画对了

三个检验，按顺序来。

第一个，外行能不能三十秒看懂产品全貌。

拉一个没接触过这个项目的人，看三十秒，让他说出这个系统管几摊事。说不出来，是图的问题。

第二个，开发能不能从图上看出要建几个模块。

开发看图的维度和产品不一样，产品看功能，开发看边界。

功能架构图的分组，就是将来代码模块的雏形。开发看完如果一个问题都问不出来，要么图太浅，要么他没认真看。

第三个，也是日常最有用的：新需求来了，能不能马上知道放哪。

功能架构图画完之后，最长期的价值就是当靶子用。来一个新需求，往图上一放。能放进去，说明在产品规划内。放不进去，两种可能：需求越界了，那就想想要不要接；或者图该更新了，产品扩展出新东西了。

两种都比稀里糊涂随便接需求要强。

最怕的是图挂在那当摆设，需求该接接，模块该乱乱。那当初画它干嘛，不如多写两页方案。

写在最后

功能架构图画不好，问题多半出在动手之前。

哪个功能归哪个域，公共能力沉不沉下去，本期圈到哪，每一个格子背后都是一次判断。图，只是这些判断的输出。

所以改图的过程，就是重新思考产品的过程。

评审会上大家指着图吵，吵的从来不是格子怎么摆，是范围怎么圈、模块怎么分。

下次再画功能架构图的时候，先别急着开PPT拉格子。摊开，归类，沉层，圈边界。想完这些，图基本自己就成了。