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

1 评论 8784 浏览 69 收藏 11 分钟

本文中,笔者将结合自己参与产品重构以及做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协议

给作者打赏,鼓励TA抓紧创作!
更多精彩内容,请关注人人都是产品经理微信公众号或下载App
评论
评论请登录
  1. 管理通用架构和商业通用架构是?

    回复