通过深入探讨如何将复杂的功能和规则抽象成简洁易用的设计，本文带您领略抽象能力的丰富性和广泛应用，从班次异常规则到排班规则设计，揭示如何通过高阶抽象思维提升设计的灵活性和扩展性，为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产品经理的核心能力】主题的第三篇，前两篇是：
后续会继续这个主题，分享实体设计、产品架构、产品规划等。敬请期待，也非常欢迎留言交流。
专栏作家
邢小作，微信公众号：邢小作之家，人人都是产品经理专栏作家。一枚在线教育的产品，关注互联网教育，喜欢研究用户心理。
本文原创发布于人人都是产品经理。未经许可，禁止转载。
题图来自 Unsplash，基于CC0协议
该文观点仅代表作者本人，人人都是产品经理平台仅提供信息存储空间服务。
友情提示
本站部分转载文章，皆来自互联网，仅供参考及分享，并不用于任何商业用途；版权归原作者所有，如涉及作品内容、版权和其他问题，请与本网联系，我们将在第一时间删除内容！
联系邮箱：1042463605@qq.com