实体设计:如何将复杂系统进行抽象架构设计?

0 评论 2529 浏览 4 收藏 15 分钟

在SaaS产品开发中,实体设计是将抽象概念转化为具体操作对象的关键步骤。它不仅关系到产品的可用性和用户体验,还直接影响到产品的维护和扩展性。文章详细介绍了实体设计的六个步骤,旨在帮助读者更好地理解和实践实体设计。

在SaaS产品的世界里,抽象能力不仅是构建高效解决方案的基石,更是推动创新和满足用户需求的关键。我们已经探讨了如何从复杂的需求中抽象出核心问题,如何将复杂的功能抽象成简洁易用的设计,以及如何将复杂系统进行场景化架构设计。今天,我们将深入探讨一个经常被忽视但同样重要的领域:实体设计。

实体设计,在SaaS产品中,指的是将抽象的概念转化为具体、可操作的对象或模块。它不仅关乎产品的外观和感觉,更关乎产品如何在实际中运作,以及如何与用户和其他系统交互。实体设计的好坏,直接影响到产品的用户体验、性能和可维护性。

让我们开始这场实体设计的探索之旅,看看它是如何将抽象的构想转化为具体的产品价值。

它主要分为六步:

  • 第一步:构建场景化产品架构:基于用户场景,抽象产品结构
  • 第二步:构建关键角色流程:依据角色工作流,抽象产品流程
  • 第三步:提取关键实体:从产品架构与流程中提取所有关键实体
  • 第四步:关联实体关系:对不同实体,建立相应的关联关系
  • 第五步:丰富实体设计:补充缺失实体,完善实体关系和属性
  • 第六步:场景验证与调整:根据用户场景和需求,验证并调整实体结构的扩展性

咱们还是以HR SaaS产品为例,一步一步拆解,希望对你有所启发。

第一步:构建场景化产品架构:基于用户场景,抽象产品结构

实体设计依赖于产品架构设计,两者共同构成产品架构的完整视图。

产品架构图是静态的,为实体设计提供基础;实体设计图则是动态的,实现产品架构的具体化。有关产品架构图的详细内容,可以参考“如何将复杂系统进行场景化架构设计”一文。

第二步:构建关键角色流程:依据角色工作流,抽象产品流程

HR SaaS的关键角色是HR,其次是决策者(即CEO/HRD),再次是业务管理者(即部门/门店负责人),最后是员工。

以考勤业务为例。

我们将创建关键角色的主要流程图,重点关注考勤HR和业务管理者。

建议:为每个角色绘制独立的流程图,以便更清晰地理解其工作流程和场景。特别是对新产品伙伴,避免像我一样偷懒。

第三步:提取关键实体:从产品架构与流程中提取所有关键实体

这一步的关键是基于产品架构和用户流程图进行“按图索骥”,提取所有相关名词,确保它们相互独立且不重复。

每个实体应像工种一样,拥有独特的名称和在系统中的明确职责,理想情况下,每个实体负责一个特定的功能。

以考勤业务为例,各个模块的独立且不重复实体情况如下:

考勤管理:员工、考勤档案、考勤确认规则;

排班管理:员工、排班日历、节假日、班次时间、排班组、排班规则;

假期管理:员工、假期规则、请假记录、请假审批、假期余额;

加班管理:员工、加班规则、加班审批、加班记录;

调班管理:员工、调班规则、调班记录、调班审批;

出差/外出管理:员工、出差/外出规则、出差/外出记录、出差/外出记录;

工时管理:员工、工时规则、工时记录;

设置:考勤周期、考勤机、出勤规则、打卡规则、打卡记录、补贴规则、补贴记录、扣款规则、扣款记录;

班次设置:班次、班次组、循环模版;

报表:员工、字段、日报、月报

第四步:关联实体关系:对不同实体,建立相应的关联关系

每个实体作为一个静态名词,只有通过赋予其明确的职责和合作关系,才能发挥价值,就像职位一样,需要明确的分工和与上下级、同级的协作,以产生有效的成果。

实体关系通常分为三类:1对1、1对N、N对N。利用这三种关系,我们可以关联实体,实现它们之间。

第五步:丰富实体关系:补充缺失实体,完善实体关系和属性

实体设计的价值是在灵活性、体验性和扩展性之间进行权衡。实体的独立性、关键属性设计以及实体间的关系共同塑造了实体架构,影响其效率和适用性。

所以当你在设计实体架构图时,可通过以下四个方向进行丰富:新增子实体、拆分关键实体、完善实体关系、完善实体属性。

首先是新增子实体。

在大框架设计中,深入特定场景流程后,可能发现实体缺失,影响场景的灵活性、扩展性或体验。

比如假期管理可按类型分为年假、事假、调休等多种假期,按额度分为有余额和无余额,按计算方式分为按工作日或自然日计算。为此,可新增“假期模板”子实体,提供自定义假期。

第二是拆分关键实体。

比如加班是一个关键场景,则可将【加班规则】实体进一步拆分为:计算规则、补偿规则、限制规则、舍去规则、使用规则,每个子规则负责一个具体的功能。

或排班也是一个关键场景,则也可增加不同维度的实体。

第三是完善实体关系。

实体关系的设计对实体架构的扩展性和用户体验有直接影响。

比如出勤方案与排班规则可以设计为N对N的灵活关系,也可以是N对1的简化关系。N对N关系提供最大灵活性,允许每个出勤方案独立关联多个排班规则;而N对1关系将排班规则视为整体,牺牲灵活性以简化配置。

第四是完善实体属性。

关键属性的设计对实体架构的扩展性和用户体验,也有直接影响。

比如适用范围作为规则/方案的关键属性,决定了哪些人适用于哪些规则。可以设计每个规则有独立的适用范围以增加灵活性,或者让关键实体如出勤方案拥有适用范围,其他规则实体共享,从而简化规则的管理。

第六步:场景验证与调整:根据用户场景和需求,验证并调整实体结构的扩展性

当实体架构设计完成后,避免考虑不周全的情况,以我的经验的话,就会用目前可以想象到的所有场景来进行“验证”。

这就像是一个思想实验一样,你把整理好的(目前)所有已知场景,分别代入到你的实体设计中进行验证。

一般验证三部分:体验性、灵活性、扩展性。

第一是体验性。基于用户流程,进行完整场景式的演绎,看看在现有流程中,是否体验足够好。

比如考勤HR在配置各类规则时,我们可以有两种不同思路:

  • 思路1是每个规则相互独立,相互之间无关联。比如打卡规则、出勤规则、加班规则等,都有自己不同的适用范围,互不影响;
  • 思路2是每个规则组合使用,由一个中间实体(即考勤方案)进行统一管理,共享同一个适用范围。

从用户体验角度,思路2优于思路1。这类似于与客户对接时,思路2只需对接一人,而思路1则需对接多人,显然更繁琐。

第二是灵活性。确保系统能适应不同客户场景,保持用户操作自由度。

在HR考勤管理中,除了执行考勤规则,还需对分区域/部门的员工考勤数据进行纠错、归档和确认。例如,北京总部员工由张三管理,而成都、武汉、重庆等分公司员工由李四管理。每月确认出勤后,数据交给王五进行工资发放。

思路1:考勤方案兼职多能,同时负责权限划分。例如,北京总部员工使用考勤方案A,由张三管理;成都、武汉、重庆员工使用考勤方案B,由李四管理。

思路2:考勤组专职专能。考勤方案仅负责规则制定,数据管理由考勤组独立负责。例如,北京总部员工属于考勤组1,由张三管理;成都、武汉、重庆员工属于考勤组2,由李四管理。

从自由度看,思路2在自由度和效率上优于思路1,类似于职场中的专职专岗,职责明确,工作安排灵活。

第三是扩展性。如果体验性和灵活性无法兼得,需考虑当前架构设计的可扩展性,确保以最小成本进行后期扩展,避免前期成本低但后期难以扩展的方案。

排班管理是考勤的核心功能之一,不同行业/企业需求各异。例如,制造业排班可能按时间规律性交替或按任务量调整;复杂度高时,员工只需选择白班或夜班。门店连锁行业则常见小时工不固定上班时间,正式员工常支援、调店/调班。

延伸场景包括按人员排班、按任务排班、按小时排班,支援调班、调店调班等,以及自动规律性排班和指定周期内自动复杂排班。

如果当前实体关系架构,不支持快速扩展,则需考虑调整。

总结一下

本文主要分享了如何将构想转化为具体的实体架构设计,介绍了设计的六步:

第一步:构建场景化产品架构:基于用户场景,抽象产品结构。关键动作是基于用户场景绘制全景产品架构图;方法论是【以终为始,全面设计;以始为终,最小闭环】。

第二步:构建关键角色流程:依据角色工作流,抽象产品流程。关键动作是明确产品的所有服务角色,根据产品阶段确定角色优先级,并绘制关键角色流程图;

第三步:提取关键实体:从产品架构与流程中提取所有关键实体。关键动作是找出产品架构与角色流程中的所有关键名词;

第四步:关联实体关系:对不同实体,建立相应的关联关系。关键动作是把所有关键名词用三种关系(即1对1/1对多/多对对)进行关联,让它们相互实现协同;

第五步:丰富实体设计:补充缺失实体,完善实体关系和属性。关键动作是查缺补漏实体关系,该加则加,该删则删;

第六步:场景验证与调整:根据用户场景和需求,验证并调整实体结构的扩展性。关键动作是收集足够需求场景,进行逐一验证,并在体验性、灵活性与扩展性之间进行权衡取舍。

本文由人人都是产品经理作者【邢小作】,微信公众号:【产品方法论集散地】,原创/授权 发布于人人都是产品经理,未经许可,禁止转载。

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

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