产品经理如何做产品架构设计

何少甫 2023-07-26 10:35:07

杰夫贝佐斯曾经在一次演讲中提到「人们经常问我：未来10年什么会被改变？但从来没有人问我：未来10年，什么不会变？」。在一款产品里中，架构就是那个不容易变的东西。

产品架构是产品经理发展到一定阶段都需要具备的能力，只是多年来互联网产品一直以来都处于舍命狂奔的状态。这种情况下产品经理往往也没有太多的机会去锻炼自己的架构能力，毕竟产品架构是个细活，不像功能体验那么能够被直接感知到。

埋了坑不一定自己填，功能没上线肯定是要背锅的。

然而，近年来新的app越来越少，各巨头们都在做深耕和提效，架构这件事情开始变得越来越受到重视了，从18年底-19年突然中台建设成为IT圈的大热点也充分体现了这一点。

一、产品架构是什么，为什么要做架构？

架构这个词往往代表了骨架和脉络，是抽象模型。

产品架构就是产品的骨架和模型，假设人体是一个产品，那么人这个产品最粗粒度的架构就有头、四肢、躯干，通过骨骼支撑起来。

在这个架构之上附着了肌肉、器官和皮肤等，构成了整个人体。

在日常工作中，我们常常会听到好几个架构，业务架构、信息架构和技术架构，这些和产品架构是什么关系呢？我的理解是这样的：

业务架构：往往是为了达到业务目标（通常是商业目标）所搭建的业务体系和商业模式，比如著名的亚马逊飞轮效应和Google搜索的印钞机模式。业务架构包括且不仅限于产品，产品架构是为了更好的支撑业务架构而构建的。
信息架构：主要是产品在结构层的一部分，通常是在交互设计阶段考虑的产品给用户呈现的产品全貌，让用户可以清晰快速的找到功能的方法。有些说法会把产品架构和信息架构当成一回事，在一些2C产品里，从信息架构里就能看出产品架构，如新闻资讯类的app。但实际上信息架构只是产品架构的一种表现形式，并不能完全代表产品架构。
技术架构：是产品架构的实现，并还覆盖有其他范畴，是个独立的大话题。在一些偏向技术型的产品里，产品架构和技术架构很接近，比如云计算产品，其用户本身就是程序员，所以云计算产品的产品架构和技术架构就非常接近了。

产品架构本身也有三个层次：

独立可交付客户价值的业务产品；
单一产品内的模块化；
单一个模块的抽象设计，也就是功能设计的架构。

整体的关系见下图：

产品经理，产品经理网站

好的产品架构能够带来哪些价值呢？借鉴云计算产品的说法，本文这里也提出一个三高的说法：

高可用：在多业务产品组成的产品矩阵中，每个产品可独立交付价值，也可组合成不同的解决方案。
高可靠：在单一产品内，基于解耦化和模块化的设计，对模块类逻辑的调整，其复杂逻辑所造成的影响往往控制在模块内，模块之间依然还是通过定义好的输入输出进行交互。
高可扩展：在单一产品内，基于模块化定义好的规则，不需要事无巨细的了解整个产品的所有细节逻辑就可以快速扩展产品功能。

由此可见，好的产品架构是相对稳定的，在业务方向本身不发生重大变化的情况下，是可以事半功倍的支持业务发展的。

二、如何做产品架构？

1. 从具象到抽象

目前各大厂商对互联网产品经理的要求里往往非常注重同理心和用户体验，这是一个具象化的过程，在一个具体的场景里以用户的视角来体验和设计产品。

而做产品架构则有了不同的要求，产品经理需要基于用户场景找出一类需求，并且还需要考虑到背后的需求，衍生的需求。

对于这些需求进行抽象和建模，找出一些通用型的解放方案去满足他们的需求。并且，由于B端产品的价值流和功能逻辑相对于C端产品往往要复杂很多，对于B端产品经理而言，产品架构的要求往往更高。

2. 各层次的产品架构搭建

前面已经介绍到产品架构有三个层次，接下来具体介绍三个层次是如何做产品架构的。

1）可独立交付价值的产品架构

可独立交付价值的产品架构，这类架构往往和业务是强相关的，每个产品可以独立使用交付客户价值，形成采购，也可以针对客户不同场景的需求进行组合，提供综合解决方案。

云计算产品就是最典型的例子，用户可以在云计算厂商官网根据自己的需求勾选一些产品，然后独立采购和使用，以视频云涉及到的几类常见产品：

对象存储：主要进行非结构化数据(文件)的存储；
CDN：内容分发网络，主要解决跨地域的海量用户资源访问速度的问题；
点播：主要是指音视频的播放问题，音视频会被转码成标准编码格式，并可通过指定播放器解码和播放；
直播：主要是实时音视频的直播，主要包括普通推流直播和实时互动直播。

对于客户而言：

如果只需存储海量数据，就只需要购买对象存储即可；
服务于不同地域的大量用户访问，就需要使用CDN；
类似于映客这样的直播类产品，就购买直播+CDN+对象存储；
像抖音、爱奇艺这种完整的视频类产品，就需要有直播+点播+CDN+对象存储。

2）产品内的模块化

用户在一个较复杂产品里进行操作，其需求被满足的整个的流程会涉及到很多功能，其中这些功能可以进行分类，同一类功能组合成一个模块。

因此一个复杂产品内部可以划分出多个模块，每个模块负责业务流中相似的一类功能。

以淘宝为例，商家在淘宝上开店并发布商品，用户到淘宝上搜索到商品，下单购买。这一套业务流程里在淘宝这个超级app里，除了人机交互的那层壳以外，产品被划分成了以下模块。

产品经理如何做产品架构设计

其中每个模块虽不能单独满足用户想要的商品购买的完整体验，但可以专注的解决购买过程中一类问题。而当这些模块抽象到能够服务淘宝以外其他的产品时，这就是中台了。

关于中台我之前也有过分享，我的教育中台一年实战录。

3）单个模块的架构

即使是只满足一类需求的单模块，其在设计时也需要做好其架构。

以在线考试模块为例，如果你对在线考试流程有一定的了解，就会大概想到整个过程。用户进入考试、完成题目并提交，系统判分，低于60分就未通过，超过80分就是优秀。

如果仅仅只是做一个满足这个需求的在线考试系统，把细节再补充下，就可以直接出交互了。

但前面我们也提到过了，产品经理在面对需求时要进行抽象，考虑到未来拓展的需求，那么我们就需要对此模块做架构设计和抽象拆解。

首先，考试的核心价值是对通过一些设计好的题目去检验学生对知识点的理解情况，检验学生的最小的功能单元并不是试卷，而是题目。

一道题目就完成了知识点的考核，和用户进行了价值交换。所以题目应该被抽象出来成为一个独立的子模块。

通常一道题目会包括了题干、答案输入、标准答案、判题输出(对/错，答案解析)等部分，而从需求扩展的角度来看，在不同的年龄层次以及不同的学科里会有很多不同类型的题目，比如：

客观题：单选、多选、判断、填空等等；
主观题，无标准答案，一般是大题，输入方式也有多种，有文字录入、画图、拍照录题等等。

所以把题目这个结构抽象出来，有利于后期各种题型的拓展。

试卷是整个系统性知识点检验的模块，是多个题目的组合。在题目的基础上，试卷还需要具备一些其他的能力，包括：

组卷规则：比如随机组卷，AB卷的能力；
一些时间限制：开始作答、提交截止、答案公布等等。

并且其实试卷只是一个抽象的概念，实际上试卷可以具象化成课后作业、小测验、考试等等多种使用形式交付给用户。

产品经理如何做产品架构设计

把题目和试卷拆开成两个模块，有利于维护和拓展，那么这样是否就已经拆解得足够好了呢？

实际上在线考试系统里，题目的自动化批改是一个很重要的部分。因为题型的不同，批改的方式也有很多种：

简单的标准答案比对；
人工批改；
AI自动批改，拍照上传；
接入第三方批改系统，比如一些在线编程的判题系统。

我们也可以把批改系统抽离出来，一道题可以使用多个批改系统，一张试卷里的每道题都可能用不同的批改系统，这样的拓展性会更好。

当然，一个好的在线考试系统实际还会有很多其他的能力拓展，如题库、知识点标签等等，这里就不做过多展开了。

三、进行抽象建模

产品架构设计核心的抽象建模，主要涉及到：

归纳法：归纳法是在大量经验的基础上进行抽丝剥茧，总结到其内在规律的。
演绎法：在归纳法的基础上基于演绎法去推测系统如何去支持可能延伸的需求，可用来验证当前的架构设计是否合理。

UML是一个表述产品架构的好工具，上面画考试系统架构时就是一个很简化的UML图，相关的文章和书籍有很多。

通常来说，研发人员会比较擅长做架构设计。因为计算机专业学生在学校就必须学习设计模式和面向对象的程序设计，其中类和对象的概念本身就是在建模和做架构。

——这也是我为什么会认为好的产品经理需要懂一些技术的原因。

对于产品经理而言，技术实现的细节不是重点，而以下几点是需要着重注意的：

产品在做模块化设计时使用起来容易变得「技术化」，用户体验不那么好。如何做到用户在使用产品时的体验是简单且流畅的，但产品内部其实是模块化的设计，这是要在交互设计上下功夫的；
归纳法很怕遇到黑天鹅事件，所以再归纳的时候要尽量整合尽可能全的场景，特别是要做中台产品时，难度是很高的。所以在进行产品架构设计前，一定要尽可能全面的去了解各类典型的场景，和有经验的人多交流；
不要做过度抽象，抽象得没有了业务特性，就好像要解微积分时，1+1=2这个公式是不解决问题的。