像搭积木一样的组件产品该如何设计
下面这篇是笔者整理分享的关于组件产品该如何设计的文章，文章包含组件产品结构、组件拆分规划、组件支撑平台应具备的能力的相关内容，对组件产品感兴趣的同学可以进来看看哦！
有人说提供企业数字化服务是属于劳动密集型企业，随着行业的快速发展，内卷也逐渐升级，以前一个半年交付周期的项目都是百万起步，交付人员只需要3-5个，但发展到如今前后端分离，微服务架构后，项目金额缩到60万起，但交付人员却要10几个（必要岗位：项目经理、产品经理、UI、前端、后端、测试），企业利润下降严重。
纯做定制化的项目，基本很难盈利，那么从项目中积累产品，提升产品的复用度，降低项目交付的不确定性，成为数字化服务企业的重点目标，但是由于项目的个性化及对产品组件抽取的能力不足，最终的结果往往只有系统设置、基础数据可复用，其他还需要基于原来的代码调整，但是基于代码调整的成本有时甚至高于重写；
今年来低代码平台很火，但是B端业务很复杂，低代码提供的能力有限，像搭积木一样的组件产品应该包含低代码+高代码，通过工作流和数据流的组合实现组件的组装，当然产品组件本身的抽取也需要业务专家和产品专家配合不断优化，才能建立高复用度的组件产品；
一、组件产品结构
添加图片注释，不超过 140 字（可选）
下面我们拿仓储产品举例，看看组件产品的抽取及组件平台应具备的能力:
添加图片注释，不超过 140 字（可选）
仓储产品在业务层通用程度高，但是在规则策略层差异较大，因此我们在定义组件时也根据这个特性做了拆分。
对于库存管理（物料、数量、位置、批次）等这些基本不会变的做成一个大组件，对于采购入库、生产入库、销售出库等有些跟行业相关有些差异的分别做成业务组件，对于像规则策略这种差异较大的做成微小组件，通过规则、策略平台支撑做定义和二开然后通过流程配置的方式再组装使用，当然像仓储建模、维度等皆可复用，也做成了标准组件
添加图片注释，不超过 140 字（可选）
二、组件拆分规划
组件拆分
三、组件支撑平台应具备的能力
组件定义完成后，按照组件支撑平台的研发规范，放置在组件平台，供项目选择，选择后加载到组件支撑平台，组件支撑平台支持组件的个性化，也支持自定义组件，通过支撑平台提供的工作流程进行组件间的业务流转和数据流转，从而完成客户的应用场景支持；
添加图片注释，不超过 140 字（可选）
组件产品的优势在于逐步沉淀业务组件，将组件按照行业和最佳案例分类，便于项目组装形成客户所需场景，低代码和高代码的配合又能提升灵活性，预制半成品菜式的方式能提升组件产品的复用度，提升交付的速度，伴随着组件的增多，复用度的提高，是有希望能够解决劳动密集型服务形态
本文由 @抹香鲸 原创发布于人人都是产品经理，未经许可，禁止转载。
题图来自 Unsplash，基于 CC0 协议。