像搭积木一样的组件产品该如何设计

0 评论 2165 浏览 3 收藏 5 分钟

下面这篇是笔者整理分享的关于组件产品该如何设计的文章,文章包含组件产品结构、组件拆分规划、组件支撑平台应具备的能力的相关内容,对组件产品感兴趣的同学可以进来看看哦!

有人说提供企业数字化服务是属于劳动密集型企业,随着行业的快速发展,内卷也逐渐升级,以前一个半年交付周期的项目都是百万起步,交付人员只需要3-5个,但发展到如今前后端分离,微服务架构后,项目金额缩到60万起,但交付人员却要10几个(必要岗位:项目经理、产品经理、UI、前端、后端、测试),企业利润下降严重。

纯做定制化的项目,基本很难盈利,那么从项目中积累产品,提升产品的复用度,降低项目交付的不确定性,成为数字化服务企业的重点目标,但是由于项目的个性化及对产品组件抽取的能力不足,最终的结果往往只有系统设置、基础数据可复用,其他还需要基于原来的代码调整,但是基于代码调整的成本有时甚至高于重写。

今年来低代码平台很火,但是B端业务很复杂,低代码提供的能力有限,像搭积木一样的组件产品应该包含低代码+高代码,通过工作流和数据流的组合实现组件的组装,当然产品组件本身的抽取也需要业务专家和产品专家配合不断优化,才能建立高复用度的组件产品。

一、组件产品结构

下面我们拿仓储产品举例,看看组件产品的抽取及组件平台应具备的能力:

仓储产品在业务层通用程度高,但是在规则策略层差异较大,因此我们在定义组件时也根据这个特性做了拆分。

二、组件拆分规划

对于库存管理(物料、数量、位置、批次)等这些基本不会变的做成一个大组件,对于采购入库、生产入库、销售出库等有些跟行业相关有些差异的分别做成业务组件,对于像规则策略这种差异较大的做成微小组件,通过规则、策略平台支撑做定义和二开然后通过流程配置的方式再组装使用,当然像仓储建模、维度等皆可复用,也做成了标准组件。

组件拆分

三、组件支撑平台应具备的能力

组件定义完成后,按照组件支撑平台的研发规范,放置在组件平台,供项目选择,选择后加载到组件支撑平台,组件支撑平台支持组件的个性化,也支持自定义组件,通过支撑平台提供的工作流程进行组件间的业务流转和数据流转,从而完成客户的应用场景支持。

组件产品的优势在于逐步沉淀业务组件,将组件按照行业和最佳案例分类,便于项目组装形成客户所需场景,低代码和高代码的配合又能提升灵活性,预制半成品菜式的方式能提升组件产品的复用度,提升交付的速度,伴随着组件的增多,复用度的提高,是有希望能够解决劳动密集型服务形态。

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

题图来自 Unsplash,基于 CC0 协议。

该文观点仅代表作者本人,人人都是产品经理平台仅提供信息存储空间服务。

更多精彩内容,请关注人人都是产品经理微信公众号或下载App
评论
评论请登录
  1. 目前还没评论,等你发挥!