在数字化时代，SaaS产品经理面临巨大挑战和机遇。设计既满足企业需求又易于使用的解决方案，关键在于抽象能力。
抽象看似复杂，实则像马云所言：“简单是终极的复杂。”在SaaS产品设计中，抽象能力是实现简洁与功能性结合的核心，可能直接影响产品成败。
讲个小故事。
为什么去哪儿比携程晚成立6年，却最终可以并驾齐驱？
去哪儿创始人庄辰超指出，携程的市场定位是“在线旅游”，包括在线酒店和机票等，当时市场占有率超过50%。然而，携程犯了一个关键错误，即错误预估了自己的市场规模，这为去哪儿提供了机会。
为什么会错误预估市场规模呢？原因有两方面：
- 一是“在线旅行”市场每年以40%-50%的速度增长。即使现在占有50%的市场，1-2年后，由于市场高速增长，仍会为后来者留出空间。
- 二是“在线旅行”需求不够抽象，它不是人的本质需求。人的本质需求是外出旅行或办公时有一个住的地方，Airbnb提供的解决方案是共享房屋，而不是在线预定酒店。所以它的市场远超携程与去哪儿之和。
庄辰超最后总结说：如果你想做事儿，一定要间隔半年或一年，就需要把你所做的事儿向上抽象一个层次。即思考你到底在做什么事儿，满足什么人的本质需求。
说明：这个故事来源于张萧雨老师的课程分享，如有侵权，随时删除
这个故事带给我的启示是：抽象思维是一种关键能力，它超越特定岗位，具有普遍适用性。尤其在高级职位中，抽象能力尤为重要。
在市场定位中，你可以抽象出产品的核心价值。例如，钉钉定位为“AI时代的工作方式”，飞书则是“先进团队的选择”。
在业务分析上，抽象能帮助我们抓住业务本质。比如，“不在家时的住处”比“在线旅游”更抽象；“企业数字化”比“一体化HR SaaS”更抽象，而“降本增效”又比“企业数字化”更抽象。
在产品架构设计上，抽象思维能帮助我们理解业务底层架构和页面结构。例如，WorkDay的HR业务把产品架构抽象为：系统 = 流程 + 业务对象。页面架构 = 对业务对象的查询页面+对业务对象的操作流程页面+流程的历史查看页面。
在需求分析上，抽象能揭示用户需求的深层本质。用户要锤子，可能真正需要的是一个舒适温馨的家居空间。
在产品设计上，通过抽象用户场景，我们可以设计出满足需求的菜单、实体关系、页面要素和组件。
抽象思维不仅限于这些场景，它在组织架构设计、企业愿景、数据分析等方面同样重要。由于篇幅限制，这里不再一一列举。
虽能力有限，却想围绕【抽象能力：SaaS产品经理的核心能力】为主题，尽自己所能分享一个小专题，期望对你有所启发。
它们可能包含：
- 需求分析：如何从复杂的需求中抽象出核心问题？
- 功能设计：如何将复杂的功能抽象成简洁易用的设计？
- 产品规划：如何抽象地规划产品路线图和功能优先级？
- 实体设计：如何将复杂系统进行抽象架构设计？
- 产品架构：如何将复杂系统进行场景化设计？
- 流程设计：如何将用户场景抽象为系统流程？
今天从【需求分析：如何从复杂的需求中抽象出核心问题】开始。
案例1：如何解决制造业的停工问题？
客户A是一家制造业企业，面临生产任务波动导致的员工停工问题。当前系统不支持多人批量请假，导致请假流程繁琐，需要手动修改考勤结果。客户期望系统能够支持多人批量请假，以简化流程并自动关联考勤状态。如果无法得到有效解决，则要退费。
需求沟通过程：
PM：“在什么情况下，你们需要批量请假？”
客户：“当客户停工时。这种情况下，我们需要给员工批量请假，并按照70%的薪资发放。”
PM：“通常什么原因会导致停工？”
客户：“我们客户主要是制造业，生产任务会随市场波动。任务少时，我们会优先安排部分员工停工。为了留住员工，我们仍会支付70%的工资。”
PM：“那么，一般是谁来发起这个请假申请？”
客户：“主要是班组长代为发起。”
PM：“员工可以自主发起申请吗？”
客户：“不可以。因为这是企业行为，不能由员工自行申请。而且，如果员工看到‘请假’选项，可能会感到困惑，不明白为什么停工需要他们申请，而且与普通请假在同一个页面。”
PM：“那你们现在是如何处理这个流程的？”
客户：“我们通过自定义审批流程来处理。可以批量选择日期和发起人，但不会自动关联考勤状态。审批通过后，管理员会根据申请手动修改考勤结果。系统会根据自定义假期（即停工）自动核算70%的工资。”
PM：“能告诉我大概的停工频次和每次停工的人数情况吗？”
客户：“停工频次会因季节而异，有时候半天、1天，有时候好几天。人数也不确定，有时候1-2人，有时候十几个人。”
需求分析与抽象过程：
客户核心需求：有效地解决制造业中因市场波动导致的周期性停工问题，同时控制人力成本并避免员工流失。
需求层次分析：
- 第一层是表层需求： 实现批量请假功能，以简化人工处理考勤状态的工作。
- 第二层是实际需求： 自定义假期审批，自动关联考勤状态，以应对停工需求。
- 第三层是深层次需求： 在停工期间保持员工薪酬，以减少成本并保持员工稳定。
- 第四层是核心需求： 在市场波动时，找到平衡人力成本和员工留存的长期解决方案。
解决方案建议：
- 1.短期解决方案： 改进现有请假流程，支持多人批量请假，简化操作。
- 2.中期解决方案： 开发系统功能，实现自定义假期审批与考勤状态的自动关联。
- 3.长期解决方案： 设计并实施一套完整的“停工不停薪”方案，保障员工利益。
- 4.战略解决方案： 推行综合工时制度，灵活调整工作时长，按周期计算总工时，以适应市场波动，同时控制成本和保持员工队伍稳定。
案例2：如何从复杂的加班需求中，抽象出需求场景？
加班是HR SaaS的一个基础且复杂的模块，当面临以下未满足的需求，如何分析需求后，提炼出场景并进行解决？
| 序号 | 需求 |
|---|---|
| 1 | 员工上班是大小周。周一至周五：9点-18点；加班从班后1小时（即19点）计算；周六：9点-17点或9点-12点。加班从下班就计算（即17点或12点） |
| 2 | 在考勤，加班方案，选择范围中，可以添加按班次选择范围。因为在计算规则按所属考勤班次规则中，比如两个人不同的班次下班时间不一样，一个是4:30下班，一个人6:30下班，他们的休息时间也是不一样的，但是系统里只能设置一个休息时间 |
| 3 | 客户表示员工两个班次，白班10:30-19:00，中午休息时间14:00-14；30，晚班15:30-00:：00，休息时间18：30-19:00，在加班规则的休息日加班中设置了两个个时间段的休息时间14:00-14；30和18：30-19:00，如果员工加班时间是10:30-20点加班，是扣除了1个小时的时间，客户希望的扣除半小时的加班时间，已告知客户系统是按照在系统的加班规则所设置的休息时间来扣除的，如果已经包含了两个时间段的休息时间是是扣除1个小时，如果只想扣除半小时，可以在加班记录中的有效时长是修改，客户不同意这个方案，认为加班规则不灵活，强烈要求反馈，上的白班如果加班了就应该按照白班的休息时间去扣除 即使包含了晚班的休息时间这个休息时间不扣除，还是扣除半小时而不是1小时 |
| 4 | 【加班规则里的休息时间支持按照不同班次设置】目前客户公司存在多个班次，同一位员工可能今天班次休息时间是12-13点，明天的班次休息时间又是13-14点，那么管理员就无法设置固定休息时间，也无法保证员工自己申请的时候能填写班次里正确的休息时间 |
| 5 | 加班6小时内40元，6-12小时80元，12小时-24小时160元 |
| 6 | 加班固定时间自动识别，超过10点申请加班单 ；比如 9:00-6:30正常班次7-9点加班，自动识别，无需申请，9点后需要申请加班单 |
| 7 | 中午或上午加班是1:1，晚上加班额外补偿3元 |
| 8 | 客户属于制造业，员工上班存在连班的情况，要求员工16：35下班后如果存在连班的情况，员工正常加班到晚上20点，则系统根据16：35-20点计算员工的加班费，若不存在连班的情况，则按照17：05开始给员工计算加班时长。而现在的考勤计算加班费无法根据同时存在两种情况给员工设置加班规则。 |
| 9 | 1、客户中午会出现连班的情况，比如12点休息，13:30上班，员工中午没休息，出现连班；系统自动把这个1.5小时记为加班时长 2、默认情况，每天上班8.5 小时，其中0.5小时计入加班时长 |
| 10 | 公司存在休息日加班，白班8.30-20.30以及夜班20.30-次日8.30的班次，加班有效时间设置8.30-次日8.30，这样员工必须卡点打卡，不然加班就会无效（或休息日加班，早班8：30-20：30，晚班20：30-8：30（次日）。目前我们加班时间区间24小时。客户两个班次时间重叠了。所以会有加班不能正常打卡。（如加班时间设置00：00-00：00，那么晚班下班卡无法打卡）） |
| 11 | 客户是电子制造业300号人，24小时都有人轮班工作。那么加班的场景下，他们加班时间很宽阔。有可能两位同事，张三从今天早上8点加班到13点， 李四晚上22点加班到次日10点。但问题在于咱们系统这里加班时间区间最大只能24小时，如图设置意味着李四是无法申请从晚上22点加班到次日10点的。所以看咱们有没有办法满足呢？ |
| 12 | 客户制造行业，周末不排班，夜班无法计算加班，客户正常周末是排班，但要算加班，举个例子，客户周日线下会排晚班，当天20-次日04点，4点后员工产生加班，算到周日的加班。但客户周末不会排班，因为一旦排班就会没办法自动计算加班 |
| 13 | 周末或者法节加班，不同加班时长享受不同补贴。例如周末加班4小时，享受30元餐补；加班7.5小时，享受60元餐补。因为平时加班，可以设定晚下班补贴等。但是周末无法计算 |
| 14 | 员工存在周六上班，按照两倍的加班费计算，而不是日薪计算当天日工资，但是员工不来上班的话又要计算考勤。所以只能给员工排成工作日才行，但是工资计算就会有问题，针对这种情况是否可以根据员工工作日加班类型做出分类，来设置相应的补偿规则。 |
| 15 | 法定节假日排了班打了卡算加班，不能算正班。目前系统无法支持。例如2月1日是春节，给门店排了班，系统现在是算正常上班，客户要求是自动算加班。并且补偿方式为调休 |
| 16 | 加班方案可分别设置工作日和休息日每天加班时长上限，客户规则工作日每天加班只能是2小时，要么不加，休息日最多加班10小时。 |
第一步：分析并提炼需求（至少提炼2层）。可以按需求的来源、方式、规则、位置等不同维度进行标识。比如加班源-加班模式-加班位置-加班类型-加班时间/休息时间-补偿方式-打卡规则-加班限制-加班舍去等，最后加上关键描述。
| 序号 | 一级需求场景 | 二级需求场景 |
|---|---|---|
| 1 | 员工申请-班后加班-加班起始时间-周中与周六不同 | - |
| 2 | 员工申请-班后加班-休息时间-班次不同而时间不固定 | 按加班时长扣休息时长，而不按时间段 |
| 3 | 员工申请-公休日加班-休息时间-班次不同而时间不固定 | 同上 |
| 4 | 员工申请-公休日加班-休息时间-班次不同而时间不固定 | 同上 |
| 5 | 员工申请-补偿方式-按加班时长而不同 | 新增按加班时长补贴，而不改变补偿模式 |
| 6 | 固定加班-班后加班-无需申请-限指定时间段 | 所排班次可自带班后加班 |
| 7 | 员工申请-补偿方式-按加班时段而不同 | 新增按加班时长补贴，而不改变补偿模式 |
| 8 | 员工申请/固定加班-班后加班-加班起始时间-连班与不连班不同 | - |
| 9 | 员工申请/固定加班-工作日加班-休息时间-连班加班、固定加班-工作日加班-班后加班-无需申请 | 所排班次可自带休息和班后加班 |
| 10 | 员工申请-公休日加班-打卡规则-超24小时打卡 | 打卡范围支持相对时间模式 |
| 11 | 员工申请-公休日加班-加班时间-超24小时申请 | 取消加班允许时间范围 |
| 12 | 固定加班-公休日加班-自动加班&班后加班 | 所排班次支持日期类型，且自动计为加班 |
| 13 | 员工申请-补偿方式-公休日/节假日-按加班时长而不同 | 新增加班时长补贴，而不改变补偿方式 |
| 14 | 固定加班-公休日加班-加班2倍工资且计算缺勤 | 所排班次支持日期类型，且自动计为加班 |
| 15 | 固定加班-节假日加班-自动计加班且补偿调休 | 所排班次支持日期类型，且自动计为加班 |
| 16 | 员工申请/固定加班-加班限制-工作日（2小时）与公休日（10小时）不同 | 按不同日期类型限制加班时长 |
注意：上述需求是节选需求，实际需求量至少是3-5倍以上。
第二步：全面进行需求抽象设计。你可采取可视化方式，把对应需求进行抽象后，形成一张完整的需求迭代进度图。
第三步：根据需求量、紧急程度以及产研资源，确认需求优先级。你可采取【以终为始，全面设计；以始至终，最小闭环】的方式进行落地，而不是所有需求一起做。
经验时刻
第一，在需求分析时，采用“丰田经典五问”方法，深入挖掘问题的根本原因。
- 什么情况下，需要批量请假？停工
- 什么情况下，会停工？市场需求波动
- 为什么停工，还需发薪70%？节约人工成本的同时，避免人员流失
第二，沟通时，避免陷入虚拟空间，通过三个关键问题回归现实。当你面对真实客户进行沟通时，容易让你跟客户之间构建起一个虚拟空间，从而忽略现实而轻易承诺。
一般我会用三个关键问题，把它拉回到现实世界。
- 咱们现在是如何进行处理的？
- 咱们大概会涉及到多少员工/用户？
- 咱们多久会用一次？每天、每周、每月？
第三，明确区分需求（目的）与解决方案（手段），防止混淆。有时候解决方案，就是需求，却不一定是真需求。
比如案例1中，需求可能是批量请假，但它却是一种解决方案，而不是需求；
或案例2中，需可能是不同班次的休息时间不同，而需要按班次设置休息时间。它的本质休息时间不固定，那完全就可以采取根据加班时长自动扣减休息时长（比如加班8小时扣1小时，10小时扣1.5小时等）
第四，抽象需求的目的是探索需求本质，寻找最佳解决方案，而非完美方案。
完美解决方案是理想世界的产物，现实世界的最佳方案是需要权衡所有利益相关者后的妥协方案，它需要考虑成本与收益的平衡。
比如案例1中，最终采取的是简化版的自定义审批自动关联考勤状态（即通过插件定时读取自定义审批信息后，自动更新考勤状态），它是成本最小，却可以有效解决客户需求的最佳方案。
第五，分析需求时，按需求的场景、流程、规则、模式等进行关键词提炼，且逐级向上抽象后，再进行场景归类，最终用一种可视化的方式完成表达。它可以是一张图，也可以是一个表格等，形式不重要，重要的是思维。
写在最后
抽象能力在需求分析方面确实起着至关重要的作用。它帮助我们从复杂的信息中提炼出核心要素，从而更准确地理解和满足用户需求
今天主要是跟你分享它在需求分析上的运用，希望对你有启发。如果有疑问，也欢迎留言交流。
我后续会在功能设计、实体设计、产品架构和产品规划等方面继续分享关于抽象能力的运用。如果您有任何问题或需要进一步讨论，请随时留言。再次感谢！
