本文中，笔者将结合自己参与产品重构以及做SaaS产品的实践，与大家分享一些关于产品架构设计的思考，希望对你有所启发。

作为一名产品助理，入职后刚好赶上产品重构，我也就“趁机”参与其中，主要负责将撰写 PRD，与设计和开发对接。

那时的我对 SaaS 产品的理解很浅，甚至说对业务场景、产品定义、需求价值，没有一套判断标准和行为准则。但好在自己有一股冲劲，不停地做、不停地问，也就这样跌跌撞撞地熬过来了。

随后为了提升 SaaS 产品能力，系统地学习知识，并对以往的工作内容做复盘。一是反思当时产品团队决策的正确性，二是希望自己能在接下来的工作中做得更好。

接下来，针对「产品架构设计」的这个问题，与你分享我的思考与方式，希望能与你交流。

01 产品架构设计的前提

产品架构设计的第一步，需要保证业务调研的结果，以及产品战略上的定义是正确的。

对此最直接的方法，就是画业务流程图。这不仅可以将你脑中抽象的业务具象化，而且你可以拿着它直接与客户进行沟通，明确你的理解是否存在偏差。

要知道 SaaS 产品的最大好处，就是需求一定存在于真实的业务中。因此，客户能根据你的描述，判断你的理解是否与他们真实的工作相符。不过这里也需要注意遗漏，毕竟一些频率低的场景对方也是会遗漏的。

接下来，以我负责的 SaaS 产品为例，来介绍一下当时产品架构设计的整体过程。

1. 业务流程图

我负责的产品主要面向的餐饮加盟行业，是将实体门店巡检线上化，实现信息化管理。

总得来说是后端 PC 派发任务，前端 App 执行任务。

此图在细节上做过改动，并不完全代表真实场景

找出最全的业务链条，从产品定位、客户角色、业务流程、阶段分布等多个角度绘制业务流程图。

这样做的好处是：

1. 对内可以清晰地阐述一条完整的产品链路，便于后续开发同事的技术支持；
2. 对外能够系统化的向客户展示设计的思路，利于对方指正错误。

2. 流程中涉及到的角色

大多数 SaaS 产品面向的不是单个的人，而是由一群具有通用特征的人群，组成的一个组织。

这类通用特征的人群，在现实中用「岗位」划分，而对应到系统中就会用「角色」来称呼。

其实本质是一样的。

我们需要对业务调研结果进行整理，明确角色的描述、种类、工作内容、关注指标、行为边界等信息。

这是因为系统早期没有资源做权限模块的设计，因此我们可以根据这些信息，在系统中预置这些角色的权限，在之后直接调用即可。

但需要注意的是，我们不能仅局限于一家企业，需要调研多家同类企业，做彼此间的交叉验证以及通用整合。

最后将角色分为「通用类」和「个性类」两种。

我们需要将精力重点用在通用类角色身上，个性类角色不是重点，甚至可以考虑用通用类角色替代个性类角色。

而具体在系统内的承载方式，可以考虑在人员部分加一个「岗位」字段值，用于承载通用类角色的权限。

一来用户理解起来容易，二来在后面设计权限功能模块的时候可以做到很好的替换。

不得不说，即使作为产品助理，心里也得有一张路线图，需要能够看到产品的全貌，需要走一步看两步。

02 架构的设计思路

1. 将场景需求清单拆解到功能

场景需求清单是对实际业务场景的描述，产品经理需要将他们梳理分类，最后呈现出来。

下面是梳理出的 PC 端核心业务场景需求清单，这里重点考验的是产品经理将需求翻译成功能的能力。

但实际上，从客户那里得到的业务场景远比这个多，但对于公司来说不可能一上来就全部满足。

因此 SaaS 产品最初的设计同样遵循 MVP（最小可行化）原则，即完成核心业务场景的闭环。

在此基础上先能让客户用起来，在这个过程中不断的累加功能、完善服务。

况且客户在系统上产生数据，实际上就是产生依赖，随之用户的替换成本也会一点点的提高。

2. 将功能按不同纬度进行分类整合

通用架构有两种——「管理通用架构」和「商业通用架构」。

而我负责的产品显然属于管理类，因此这里我会先找出符合通用模块的功能，进行归类整合，避免重复造轮子。

由于刚开始的业务比较简单，因此符合度很高，并没有做过多的拆分。

不过相信你也发现了一个问题，就是数据管理中的这个「签到数据」，它是从哪来的？

先介绍一下这个业务背景：

某企业的每个督导负责 10 家左右的门店，每天根据任务巡检门店，除此之外还要处理一些门店的琐事。

这就会导致督导在当天没有完成对应门店的巡检，而上级需要知道他们的行踪。

对方目前的解决方案，是通过钉钉的签到来完成。

而对方希望能逐步使用我们的系统完成，同时在一些个性化需求上，比如数据导出方面能够满足他们的诉求。

在考虑产品定位、需求 ROI 等信息后，最终选择开发这个「签到」功能，并将数据导出部分放在了数据管理里面。

话说回来，SaaS 产品的每一个功能，都是在明确解决一个具体的业务问题。因此在设计架构的时候，我们要注意功能模块的包容性，而不是单纯的累加。

当然还有一种情况，接下来随着业务的发展，一定会出现不符合通用模块的功能。

到那时，我会根据业务重要程度和复杂性单独进行整合，例如任务管理模块，目前在 App 端允许执行人将任务移交给他他人，但目前 PC 端并没有记录。

因此随着后续的业务发展，会结合整改业务的部分，将任务管理整个抽离出来单独形成一个模块做设计。

当然这就是后话了，但我们要知道架构不会一成不变，它会随着业务复杂程度的提高，慢慢地拓展成长。

3. 梳理模块之间的逻辑关系

要知道业务是一个链条，上下游的衔接一定会产生数据。

因此我们可以将模块分为两类，一是存在基础信息，但不产生数据流的「静态模块」，二是产生数据流通的「动态模块」。

对于上面我提到的模块，品牌管理、任务管理属于静态模块，数据管理、数据看板属于动态模块。

数据从哪来到哪去，会在哪些节点发生变化，这些产品经理也需要做到心中有数。到此，就是我目前产品的架构形态。

写在最后

这次产品设计的过程虽然存在很多问题，直到现在之前的坑都还没填完。即使痛苦，但对我来说确实是一次巨大的成长。

而做这次复盘的目的，也是希望之后的我在做产品设计时，能思考的更加全面。

在产品这条道路上，我们很难做到避坑，但有意识地意识到自己的处境，及时调整与止损非常重要。

愿你我都能成为不“坑”的产品人，做出让用户满意的产品。

作者：空；公众号：小木盒产品记

本文由 @空 原创发布于人人都是产品经理。未经许可，禁止转载

题图来自Pexels，基于CC0协议