通过深入探讨如何将复杂的功能和规则抽象成简洁易用的设计，本文带您领略抽象能力的丰富性和广泛应用，从班次异常规则到排班规则设计，揭示如何通过高阶抽象思维提升设计的灵活性和扩展性，为B端产品设计提供持久的解决方案。

上篇《功能设计：如何将复杂的功能抽象成简洁易用的设计？》探讨了在功能设计中运用抽象能力的方法，并通过班次设计的两个案例展示了其应用。

虽然这些案例展示了抽象能力的重要性，但个人认为它们不足以全面体现抽象能力的丰富性和应用范围。

因此，计划在接下来的文章中，先插入一期内容，然后再继续探讨实体设计和产品架构等主题。

一般来说，功能设计的抽象可以分为两类：一类是我们最常见的对功能本身的抽象（比如班次、排班、加班、假期等），另一类是常被我们忽略的对功能规则的抽象（如班次规则、排班规则等）。

前者是之前反复重点分享的内容，后者则是本文想补充分享的内容。

案例1：如何设计班次异常规则，保持考勤灵活性？

场景：客户A考勤规则是：员工每月有3次迟到或早退机会，每次不超过30分钟。超出30分钟，扣款标准如下：迟到或早退1-10分钟，扣10元；11-30分钟，扣20元；31-60分钟，扣50元。迟到或早退超过1小时但不超过4小时，按旷工0.5天计算；超过4小时的，按旷工1天计算。

1. 方案1：通过扣款规则自定义阶梯实现

扣款逻辑统一由扣款规则，按异常类型（即迟到/早退/缺卡/旷工）进行阶梯式扣款规则的配置。

2. 方案2：通过考勤项目自定义字段组合实现

扣款逻辑由考勤项目关联对应自定义字段，通过公式单独配置字段的计算逻辑实现。

3. 解析

方案1是一阶抽象（即只抽象扣款规则本身），而方案2是二维抽象（即对扣款规则本身抽象的同时，还对规则的规则进行抽象）。

方案1由于规则简单，易于理解和实施，但缺乏应对复杂情况的能力，且难以适应未来可能的变化（即无法有效扩展）。方案2虽然初始理解和使用成本较高，但其设计考虑了多种情况和未来的扩展性，能够更好地应对复杂的工作场景和变化的需求。

比如员工每月有3次15分钟内的免费迟到机会。第4次及以后，1-15分钟按15分钟扣款，超过15分钟按实际迟到时间计算扣款。例如，迟到30分钟，则按30分钟除以工作日480分钟，即0.5小时旷工扣款，扣除相应的计薪天数。

或员工每月有3次10分钟以内的迟到或早退免责机会。超过3次，每分钟迟到或早退将按2元扣款。若单次迟到或早退超过2小时，将按每小时旷工计算扣款。

方案1就无法扩展支持上述复杂场景，而方案2却可以。

案例2：如何设计排班规则，让排班灵活且合规？

场景：客户B是一家门店连锁企业，面临一线员工多为兼职和小时工，工作时长依客人数量和用餐时长而定，按实际工作时长支付工资。

方案1：单一排班规则抽象，仅进行合规限制

• 划线排班（下图一）：默认每天00:00-24:00之间，允许店长自由给员工安排工作时长，且无论时长数，最终都统计为1天。
• 排班规则（下图二）：可直接按每日、每周、每月限制/提醒排班时长、排休天数等；

方案2：二阶排班规则抽象，对排班本身与合规进行限制

• 划线排班配置规则（下图一）：可配置划线排班时，每天的开始与结束时间、每天的统计天数、休息时数、打卡范围、是否加班等；
• 排班规则配置规则：可单独配置每个排班属性的规则（下图二），再将N个配置规则灵活组合后（下图三），作用于对应排班员工。

3. 解析

方案1是一阶抽象（即只抽象功能本身的规则），采取“可见即可得”和“能默认就默认”的方式，对使用者和设计者来说，都是直来直往，容易理解。不过它有“致命”的不足之处，不够抽象而导致灵活性与扩展性不足。

方案2是二阶抽象（既抽象功能本身规则，又抽象对功能规则的配置规则），采取“极度抽象，保持配置化”的方式，对使用者的使用有要求，却足够灵活，所支持的场景数与扩展性更强。它的“不足”之处是用户使用的理解成本和研发成本相对高。

比如划线排班时，门店员工上班时间大多是6:00-22:00（默认00:00-24:00体验不佳），且可能上半天或全天（默认1天不合理），方案1就不能灵活满足，也不便于扩展，而方案2就可以灵活满足。

同理，排班的合规性校验规则也类同。

方案1的排班规则是一个整体（即排班方案与排班规则是1对N的关系），无法有效区分工作日/节假日等限制时长，也无法灵活配置以及扩展。比如只限制工作日的排班时长，或新增一个每月连续排休天数限制等。

方案2的排班规则是N个排班规则配置项的组合（即排班规则与排班规则配置项是N对N的关系），用户自由组合规则项即可实现需求。同时，如果有新增项时，可快捷增加对应的【对象】即可。

三、经验分享

1. 收集多样化的案例对于功能设计至关重要。

丰富的场景不仅有助于揭示需求的多样性，还能引导设计者进行更深入的抽象思考。特别是对于那些缺乏想象力和架构能力的人来说，每个场景都是具体的学习材料，场景间的差异能激发更高级别的抽象设计。

2. 即使最终选择一阶抽象方案，也应经历二阶抽象的设计过程。

一阶抽象直观、易于理解和实施，但缺乏灵活性和扩展性。相比之下，二阶抽象虽然不那么直观，却能提供更高的灵活性和可扩展性，为未来的变化和复杂需求留下空间。

3. 切忌追求需求上线的速度，而放弃产品的扩展性。

B端产品设计是一场马拉松，考验的是持续性和耐力。急于求成地将长期策略转变为短期冲刺，把马拉松比赛变成短跑，结局就是陷入反复重构的“魔怔”里。

四、写在最后

本文是【抽象能力：SaaS产品经理的核心能力】主题的第三篇，前两篇是：

需求分析：如何从复杂的需求中抽象出核心问题？

功能设计：如何将复杂的功能抽象成简洁易用的设计？

后续会继续这个主题，分享实体设计、产品架构、产品规划等。敬请期待，也非常欢迎留言交流。