产品架构

说实话，产品架构这个东西，我之前一直觉得是架构师的活。
产品经理嘛，画画原型、写写PRD、跟开发吵吵架就完了，架构这种高大上的词，跟我有啥关系？
直到我真正经历了一个从0到1的B端项目。
那个项目，我一上来就开始画原型、写需求，各种功能堆上去，看起来热热闹闹的。结果做到一半，发现模块之间的关系乱成一锅粥，改一个地方要动十个地方，开发天天追着我问"这个功能到底归哪个模块"。
那段时间，我被折磨的够呛。
后来痛定思痛，我才真正开始认真研究产品架构这件事。走了不少弯路之后，我总结出了4个步骤，现在做新项目，基本就是按这个套路来，屡试不爽。

一. 先把业务架构搞清楚

很多产品经理一上来就想着"我要做哪些功能"，这其实是错的。
你得先搞清楚，业务是怎么跑的。
什么意思呢？就是站在业务的角度，把整个业务流程从头到尾捋一遍。
举个例子。
比如你做的是快消品行业的访销系统，那业务流程大概就是这样的：业务员出门 → 拜访门店 → 看看货架 → 录入订单 → 门店签收。
再比如你做的是电商系统，那核心业务流程可能就是：用户浏览商品 → 加入购物车 → 下单支付 → 商家发货 → 用户收货。
这一步看起来简单，但其实特别关键。
因为如果你连业务怎么跑的都没搞清楚，后面设计出来的产品架构，大概率是拍脑袋拍出来的。
我之前就犯过这个错。
有一次做一个会员权益系统，我直接上手就开始分模块，结果漏掉了一个关键的业务环节——权益核销。导致后面系统上线了，运营那边说"这个权益发出去了，怎么核销啊？"
我当场就傻了。
所以第一步，一定要老老实实的，把业务流程画出来。别嫌麻烦，这一步省了，后面要还的债是十倍百倍的。
你可以找业务方聊，找运营聊，找销售聊，甚至找客服聊。把整个业务从头到尾走一遍，每个环节是谁在操作、操作什么、产出什么，都搞清楚。
这就是所谓的业务架构梳理。
说白了，就是回答一个问题：这个产品要服务的业务，到底是怎么运转的？

二. 梳理出有哪些产品模块

业务架构搞清楚了，接下来就是把业务流程里的每个环节，对应到产品模块上。
这一步其实不难，就是一个翻译的过程。
把业务语言翻译成产品语言。
还是拿快消品访销来举例：
  • 业务员拜访门店 → 对应的产品模块就是拜访管理
  • 业务员录入订单 → 对应的就是销售订单管理
  • 门店签收货物 → 对应的就是配送管理或者签收管理
  • 查看业绩数据 → 对应的就是数据报表
你看，其实就是把业务流程里的每一个关键环节，都找到它对应的产品模块。
但这里有个坑，我必须提醒一下。
就是很多人梳理模块的时候，容易犯两个极端：
一种是颗粒度太粗。把一堆功能塞到一个模块里，什么订单啊、库存啊、财务啊全揉在一起，最后这个模块变成了一个"万能模块"，啥都有但啥都说不清。
另一种是颗粒度太细。恨不得每个按钮都是一个模块，最后模块列表拉出来几十个，看着就头大，模块之间的关系更是理不清。
我的经验是，一个模块应该对应业务中一个相对独立的职能或环节。
如果你发现一个模块要服务好几个完全不同的业务场景，那它可能太大了，得拆。如果你发现好几个模块其实做的是同一件事，那它们可能太碎了，得合。
这个度，说实话，需要一些经验。
但有个简单的判断方法：你试着用一句话描述这个模块是干啥的。如果一句话说不清，大概率是太大了。如果一句话说完感觉"就这？"，大概率是太碎了。

三. 定义模块之间的关系

好了，到这一步，你已经有了一个业务流程图，也有了一堆产品模块。
但是，这些模块不是孤岛。
它们之间一定是有关系的，而这个关系怎么定义，直接决定了你的架构好不好。
这一步是整个产品架构设计中最核心的部分，没有之一。
我把它拆成三个小点来讲。

1. 定义模块的边界

啥叫模块边界？
就是每个模块的"管辖范围"。这个功能归你管，那个功能归他管，边界要清晰。
比如，销售订单是一个模块，库存管理是另一个模块。虽然下单的时候要查库存，但"查库存"这个能力属于库存模块，不属于订单模块。
用一个专业点的词来说，就是"高内聚"。
翻译成大白话就是：一个模块内部的功能，应该是紧密相关的，都是围绕同一件事展开的。
你可以把模块想象成一个部门。一个好的部门，内部的人做的事情是相关的、协同的。如果你发现一个部门里，有人管销售、有人管财务、有人管仓库，那这个部门的组织架构大概率有问题。
模块也是一样的道理。

2. 定义模块的集成

模块之间总归是要打交道的嘛。
比如销售订单模块下单的时候，需要去库存模块查一下"这个商品还有没有货"。这就是模块之间的集成。
但这里的关键是：模块之间的交互方式要简单、清晰。
用专业的话讲，就是"低耦合"。
翻译成大白话：模块之间的连接点要少，每个连接点要简单。不要搞出那种"我改了A模块的一个小功能，结果B、C、D模块全崩了"的惨案。
我之前就经历过这种事。
当时有个项目，订单模块和库存模块耦合特别深，深到什么程度呢？订单里直接写了库存的计算逻辑。结果有一天库存规则变了，开发改完库存模块，发现订单模块也得改，改完订单模块，发现报表模块又受影响了。。。
那一周，整个团队都在连锁反应里疲于奔命。
所以，好的架构设计，总结起来就六个字：高内聚，低耦合。
说真的，你只要把这六个字吃透了，很多架构设计上的问题，你都能回答上来。
这不是什么高深的道理，但真正能做到的人，其实不多。

3. 定义模块的复用

这一点，在实际工作中也特别重要。
什么叫复用？就是同一个模块，能不能被多个业务场景共用。
举个例子。
你公司同时有大客户销售和小客户销售两种业务。那客户信息管理模块，大客户和小客户用的其实是同一套数据，完全可以复用同一个模块。
但是销售订单管理就不一定了。
因为大客户的下单流程可能特别复杂，要经过层层审批，还有账期、合同、对账等环节。而小客户可能就是简单的下单付款。
这两个业务差异太大了，如果硬要塞到一个模块里，最后这个模块会变成一个四不像，谁都不好用。
这时候就得分开设计。
但这里有个很关键的点，我想特别说一下。
复用策略跟你做的产品类型有很大关系。
如果你做的是SaaS产品，那就要尽可能复用。因为SaaS的核心逻辑就是用一套产品服务一千个客户，研发成本必须摊薄。你每多一个独立模块，就意味着更多的维护成本。
但如果你做的是自研产品，那情况就不一样了。自研产品服务的就是你自己的业务，这时候你需要在复用和个性化之间找平衡。
复用率当然重要，但不能为了追求复用率，就把业务方的个性化需求给憋回去。毕竟你做产品的目的是帮业务达成目标，而不是为了让架构图看起来更优雅。
在研发成本可控的前提下，优先响应业务的个性化需求。
这句话听起来简单，但在实际工作中做决策的时候，你会发现它真的很管用。

四. 绘制产品架构图

好了，到了最后一步。
前面三步做完了，其实你脑子里已经有一个比较清晰的架构了。
这一步要做的，就是把它画出来。
绘制产品架构图，其实就是把你前面梳理的所有东西，用一张图的方式呈现出来。
一般来说，产品架构图会包含这些内容：
  • 最底层是基础服务和数据层
  • 中间是各个业务模块
  • 最上层是面向用户的应用和入口
  • 模块之间的调用和依赖关系用连线表示
当然，不同公司、不同产品的架构图风格不太一样，这个没有标准答案。
但有几个原则我觉得挺重要的：
第一，架构图要让人一眼看懂整体结构。 如果别人看了你的架构图，5秒钟之内还找不到北，那这张图就需要优化。
第二，层次要清晰。 别把所有模块平铺在一个层面上，要有层次感。哪些是基础能力、哪些是业务模块、哪些是应用层，分清楚。
第三，别贪全。 架构图不是功能清单，不需要把每一个小功能都画上去。它的目的是展示"全局关系"，不是"功能列表"。
我自己画架构图的工具用的比较杂，什么draw.io、ProcessOn、甚至PPT都用过。工具不重要，重要的是你脑子里那个架构是清晰的。
如果你前面三步做的扎实，画图这一步其实非常快。反过来，如果你画图的时候发现画不下去、画不清楚，那大概率是前面某一步没做到位，回头重新梳理就好了。

写在最后

回过头来看，产品架构设计这事儿，其实就四步：
搞清业务怎么跑 → 翻译成产品模块 → 定义模块关系 → 画出架构图。
看起来不复杂对吧？
但难的不是知道这四步，难的是每一步都做到位。
尤其是第三步，定义模块关系，里面涉及到的边界、集成、复用这三个问题，真的是做产品架构里最考验功力的地方。
我自己也是在经历了好几个项目的坑以后，才慢慢有了感觉。
所以如果你现在觉得产品架构离自己很远，或者觉得自己画不好架构图，别急，多做几个项目，多踩几个坑，自然就有感觉了。
毕竟产品经理这个岗位，很多东西就是得靠实战来练的。
看理论只能让你知道"原来是这么回事"，但真正理解为什么要这么做，还得靠自己趟过那条河。