产品经理关于「产品架构设计」,我的实践思考

1、本文中，笔者将结合自己参与产品重构以及做SaaS产品的实践，与大家分享一些关于产品架构设计的思考，希望对你有所启发。作为一名产品助理，入职后刚好赶上产品重构，我也就 “趁机 ”参与其中，主要负责将撰写PRD,与设计和开发对接。那时的我对SaaS产品的理解很浅，甚至说对业务场景、产品定义、需求价 值，没有一套判断标准和行为准则。但好在自己有一股冲劲，不停地做、不停 地问，也就这样跌跌撞撞地熬过来了。随后为了提升SaaS产品能力，系统地学习知识，并对以往的工作内容做复 盘。一是反思当时产品团队决策的正确性，二是希望自己能在接下来的工作中 做得更好。接下来，针对产品架构设计的这个问题，与你分享我的思

2、考与方式，希望能与你交流。产品架构设计的第一步，需要保证业务调研的结果，以及产品战略上的定义是正确的。对此最直接的方法，就是画业务流程图。这不仅可以将你脑中抽象的业务具象化，而且你可以拿着它直接与客户进行沟通，明确你的理解是否存在偏 差。要知道SaaS产品的最大好处，就是需求一定存在于真实的业务中。因此，客户能根据你的描述，判断你的理解是否与他们真实的工作相符。不过这里也需要注意遗漏，毕竟一些频率低的场景对方也是会遗漏的。接下来，以我负责的SaaS产品为例，来介绍一下当时产品架构设计的整体 过程。我负责的产品主要面向的餐饮加盟行业，是将实体门店巡检线上化，实现信息化管理。总得来说是后端PC派发

3、任务，前端App执行任务。此图在细节上做过改动，并不完全代表真实场景找出最全的业务链条，从产品定位、客户角色、业务流程、阶段分布等多个角度绘制业务流程图。这样做的好处是：大多数SaaS产品面向的不是单个的人，而是由一群具有通用特征的人群， 组成的一个组织。这类通用特征的人群，在现实中用岗位划分，而对应到系统中就会用角色来称呼。其实本质是一样的。我们需要对业务调研结果进行整理，明确角色的描述、种类、工作内容、关注指标、行为边界等信息。这是因为系统早期没有资源做权限模块的设计，因此我们可以根据这些信息，在系统中预置这些角色的权限，在之后直接调用即可。但需要注意的是，我们不能仅局限于一家企业，需要调

4、研多家同类企业，做彼此间的交叉验证以及通用整合。最后将角色分为通用类和个性类两种。我们需要将精力重点用在通用类角色身上，个性类角色不是重点，甚至可以考虑用通用类角色替代个性类角色。而具体在系统内的承载方式，可以考虑在人员部分加一个岗位字段值，用于承载通用类角色的权限。一来用户理解起来容易，二来在后面设计权限功能模块的时候可以做到很好的替换。不得不说，即使作为产品助理，心里也得有一张路线图，需要能够看到产品的全貌，需要走一步看两步。场景需求清单是对实际业务场景的描述，产品经理需要将他们梳理分类，最后呈现出来。下面是梳理出的PC端核心业务场景需求清单，这里重点考验的是产品经 理将需求翻译成功能的能

5、力。但实际上，从客户那里得到的业务场景远比这个多，但对于公司来说不可能一上来就全部满足。因此SaaS产品最初的设计同样遵循 MVP （最小可行化）原则，即完成核 心业务场景的闭环。在此基础上先能让客户用起来，在这个过程中不断的累加功能、完善服务。况且客户在系统上产生数据，实际上就是产生依赖，随之用户的替换成本也会一点点的提高。通用架构有两种 管理通用架构和商业通用架构。而我负责的产品显然属于管理类，因此这里我会先找出符合通用模块的功能，进行归类整合，避免重复造轮子。由于刚开始的业务比较简单，因此符合度很高，并没有做过多的拆分。不过相信你也发现了一个问题，就是数据管理中的这个签到数据，它是从哪来

6、的？先介绍一下这个业务背景：某企业的每个督导负责10 家左右的门店，每天根据任务巡检门店，除此之外还要处理一些门店的琐事。这就会导致督导在当天没有完成对应门店的巡检，而上级需要知道他们的行踪。对方目前的解决方案，是通过钉钉的签到来完成。而对方希望能逐步使用我们的系统完成，同时在一些个性化需求上，比如数据导出方面能够满足他们的诉求。在考虑产品定位、需求ROI 等信息后，最终选择开发这个签到功能，并将数据导出部分放在了数据管理里面。话说回来，SaaS产品的每一个功能，都是在明确解决一个具体的业务问题。因此在设计架构的时候，我们要注意功能模块的包容性，而不是单纯的累加。当然还有一种情况，接下来随着业

7、务的发展，一定会出现不符合通用模块的功能。到那时，我会根据业务重要程度和复杂性单独进行整合，例如任务管理模块，目前在App端允许执行人将任务移交给他他人，但目前PC端并没有记录。因此随着后续的业务发展，会结合整改业务的部分，将任务管理整个抽离出来单独形成一个模块做设计。当然这就是后话了，但我们要知道架构不会一成不变，它会随着业务复杂程度的提高，慢慢地拓展成长。要知道业务是一个链条，上下游的衔接一定会产生数据。因此我们可以将模块分为两类，一是存在基础信息，但不产生数据流的静态模块，二是产生数据流通的动态模块。对于上面我提到的模块，品牌管理、任务管理属于静态模块，数据管理、数据看板属于动态模块。数据从哪来到哪去，会在哪些节点发生变化，这些产品经理也需要做到心中有数。到此，就是我目前产品的架构形态。这次产品设计的过程虽然存在很多问题，