本文中，笔者将团结本身参加产物重构以及做SaaS产物的实践，与各人分享一些关于产物架构设计的思考，但愿对你有所开导。

作为一名产物助理，入职后恰好遇上产物重构，我也就“乘隙”参加个中，主要认真将撰写 PRD，与设计和开拓对接。

当时的我对 SaaS 产物的领略很浅，甚至说对业务场景、产物界说、需求代价，没有一套判定尺度和行为准则。但亏得本身有一股冲劲，不断地做、不断地问，也就这样跌跌撞撞地熬过来了。

随后为了晋升 SaaS 产物本领，系统地进修常识，并对以往的事情内容做复盘。一是反思其时产物团队决定的正确性，二是但愿本身能在接下来的事情中做得更好。

接下来，针对「产物架构设计」的这个问题，与你分享我的思考与 *** ，但愿能与你交换。

01 产物架构设计的前提

产物架构设计的之一步，需要担保业务调研的功效，以及产物计谋上的界说是正确的。

对此最直接的要领，就是画业务流程图。这不只可以将你脑中抽象的业务具象化，并且你可以拿着它直接与客户举办相同，明晰你的领略是否存在毛病。

要知道 SaaS 产物的更大长处，就是需求必然存在于真实的业务中。因此，客户能按照你的描写，判定你的领略是否与他们真实的事情相符。不外这里也需要留意漏掉，究竟一些频率低的场景对方也是会漏掉的。

接下来，以我认真的 SaaS 产物为例，来先容一下其时产物架构设计的整体进程。

1. 业务流程图

我认真的产物主要面向的餐饮加盟行业，是将实体门店巡检线上化，实现信息化打点。

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

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

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

这样做的长处是：

对内可以清晰地叙述一条完整的产物链路，便于后续开拓同事的技能支持；

对外可以或许系统化的向客户展示设计的思路，利于对方指正错误。

2. 流程中涉及到的脚色

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

这类通用特征的人群，在现实顶用「岗亭」分别，而对应到系统中就会用「脚色」来称号。

其实本质是一样的。

我们需要对业务调研功效举办整理，明晰脚色的描写、种类、事情内容、存眷指标、行为界线等信息。

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

但需要留意的是，我们不能仅范围于一家企业，需要调研多家同类企业，做互相间的交错验证以及通用整合。

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

我们需要将精神重点用在通用类脚色身上，本性类脚色不是重点，甚至可以思量用通用类脚色替代本性类脚色。

而详细在系统内的承载 *** ，可以思量在人员部门加一个「岗亭」字段值，用于承载通用类脚色的权限。

一来用户领略起来容易，二来在后头设计权限成果模块的时候可以做到很好的替换。

不得不说，纵然作为产物助理，心里也得有一张蹊径图，需要可以或许看到产物的全貌，需要走一步看两步。

02 架构的设计思路 1. 将场景需求清单拆解到成果

场景需求清单是对实际业务场景的描写，产物司理需要将他们梳理分类，最后泛起出来。

下面是梳理出的 PC 端焦点业务场景需求清单，这里重点检验的是产物司理将需求翻译乐成能的本领。

但实际上，从客户哪里获得的业务场景远比这个多，但对付公司来说不行能一上来就全部满意。

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

在此基本上先能让客户用起来，在这个进程中不绝的累加成果、完善处事。

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

2. 将成果按差异纬度举办分类整合

通用架构有两种——「打点通用架构」和「贸易通用架构」。

而我认真的产物显然属于打点类，因此这里我会先找出切合通用模块的成果，举办归类整合，制止反复造轮子。

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

不外相信你也发明白一个问题，就是数据打点中的这个「签到数据」，它是从哪来的？

先先容一下这个业务配景：

某企业的每个督导认真 10 家阁下的门店，天天按照任务巡检门店，除此之外还要处理惩罚一些门店的琐事。

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

对方今朝的办理方案，是通过钉钉的签到来完成。

而对方但愿能慢慢利用我们的系统完成，同时在一些本性化需求上，好比数据导出方面可以或许满意他们的诉求。

在思量产物定位、需求 ROI 等信息后，最终选择开拓这个「签到」成果，并将数据导出部门放在了数据打点内里。