其他分享
首页 > 其他分享> > 数栈产品经理分享:干货解读数据中台产品「模块化」设计思路

数栈产品经理分享:干货解读数据中台产品「模块化」设计思路

作者:互联网

一、前言

在做企业服务类(ToB)的产品时,我们经常会遇到如下场景:

每个客户拿着他们的需求清单,来咨询我们的产品是否可满足他们的诉求。如图所示:

每个客户的需求有重叠的内容,也有不一样的内容,而这些需求,在某一领域均具有较强的通用性。

如何满足这些客户需求的同时又能使各个需求沉淀为标准功能,而不仅仅是为了交付项目?这成为ToB类产品经理思考最多的问题。

为支撑客户诉求,基本的做法是抽象各个需求,落地为标准功能,将各个功能拼装成一个产品。但是一段时间后大家就会发现功能越堆越多、产品越做越庞大,但是用户体验却越来越差,产品开发维护越来越困难。
如何既能满足客户诉求,又能解决产品存在的这些问题?模块化设计是一个方向。后面我们展开介绍下,数栈在模块化设计方面的一些经验供参考。

二、模块化设计介绍

(一)目的

 

(二)落地经验
模块化设计在数栈平台的落地实施,从大到小主要分为下面三种方式:

1、子产品化
1)需求背景:
每个客户,甚至同一个客户在不同阶段,对数据中台的理解都不尽相同。

2)设计思路:

3)落地成果:
数栈作为一款数据中台产品,其中包含了:离线开发、实时开发、算法开发、数据服务、数据资产、数据质量、智能标签等子产品,每个子产品可解决不同的业务场景诉求,并支持独立、组合部署。

2、公共模块
1)需求背景:
数栈的各个模块独立化成子产品后,虽然可以解决不同的业务场景诉求,但是在数据中台这个框架内,仍然会存在一些相同的基础功能诉求,比如用户体系、数据源管理、任务运维等。如果每个子产品内部独立实现,会存在两个问题:

2)设计思路:


3、组件/插件化开发
1)需求背景:
如果说前两部分的模块化设计是对产品经理能力的考验,那这部分内容更多是对开发人员的要求。

下面介绍我们在日常工作中遇到过三个问题场景:
a、产品设计时,需要新增一个输入框,要求是:属于必填项、内容格式限制中英文、长度限制255字符。

需求很简单,但是每次评审时,产品经理都得给研发说明如果为空时怎么提示、内容不符合格式要求时怎么提示、长度超过限制时怎么处理,沟通成本极大,而这仅仅是整个原型设计中1%都不到的内容。

b、产品设计时,需要复用另一个模块中的表单,表单中维护的各个表单项、表单项关联逻辑均相同。
功能完全一致,但是研发调研后发现,原有的表单处理逻辑和业务处理逻辑强耦合,导致表单代码无法复用,需要重新独立开发。

c、在产品迭代过程中发现存在一类需求,更新相对频繁,需求逻辑具有一定共性,而且更新不会涉及已有功能的改动。
这类需求对于开发,和公共模块之于产品类似,可以抽象为一种公共技术能力对外提供服务。比如我司经常会遇到的需求有:新增支持一种数据源、引擎新增一种任务类型等。

2)解决方案:

三、总结思考

模块化设计是一种解决方案,并不是最终目的,因此,在产品设计时不能为了模块化而模块化。尤其是产品初期,此时产品功能并不丰富,而且为了快速迭代抢占市场,并不适合投入较多的精力去做这个事情。但是一旦产品进入稳定发展期,产品经理和研发同学都应该开始思考模块化设计在日常工作中的应用了。

模块化设计并不是产品换个名称、独立做个页面就是模块化了,业务层面如何划分、模块之间如何配合、插件剥离的边界在哪,代码逻辑怎么解耦等等,这些都是需要思考的地方。

 

数栈是云原生—站式数据中台PaaS,我们在github和gitee上有一个有趣的开源项目:FlinkXFlinkX是一个基于Flink的批流统一的数据同步工具,既可以采集静态的数据,也可以采集实时变化的数据,是全域、异构、批流一体的数据同步引擎。大家喜欢的话请给我们点个star!star!star!

github开源项目:https://github.com/DTStack/flinkx

gitee开源项目:https://gitee.com/dtstack_dev_0/flinkx

标签:插件,模块,模块化,干货,产品,设计,数栈,诉求
来源: https://www.cnblogs.com/DTinsight/p/14759148.html