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

在数字化时代，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的一个基础且复杂的模块，当面临以下未满足的需求，如何分析需求后，提炼出场景并进行解决？

第一步：分析并提炼需求（至少提炼2层）。可以按需求的来源、方式、规则、位置等不同维度进行标识。比如加班源-加班模式-加班位置-加班类型-加班时间/休息时间-补偿方式-打卡规则-加班限制-加班舍去等，最后加上关键描述。

注意：上述需求是节选需求，实际需求量至少是3-5倍以上。

第二步：全面进行需求抽象设计。你可采取可视化方式，把对应需求进行抽象后，形成一张完整的需求迭代进度图。

第三步：根据需求量、紧急程度以及产研资源，确认需求优先级。你可采取【以终为始，全面设计；以始至终，最小闭环】的方式进行落地，而不是所有需求一起做。

二、经验时刻

第一，在需求分析时，采用“丰田经典五问”方法，深入挖掘问题的根本原因。

• 什么情况下，需要批量请假？停工
• 什么情况下，会停工？市场需求波动
• 为什么停工，还需发薪70%？节约人工成本的同时，避免人员流失

第二，沟通时，避免陷入虚拟空间，通过三个关键问题回归现实。当你面对真实客户进行沟通时，容易让你跟客户之间构建起一个虚拟空间，从而忽略现实而轻易承诺。

一般我会用三个关键问题，把它拉回到现实世界。

• 咱们现在是如何进行处理的？
• 咱们大概会涉及到多少员工/用户？
• 咱们多久会用一次？每天、每周、每月？

第三，明确区分需求（目的）与解决方案（手段），防止混淆。有时候解决方案，就是需求，却不一定是真需求。

比如案例1中，需求可能是批量请假，但它却是一种解决方案，而不是需求；

或案例2中，需可能是不同班次的休息时间不同，而需要按班次设置休息时间。它的本质休息时间不固定，那完全就可以采取根据加班时长自动扣减休息时长（比如加班8小时扣1小时，10小时扣1.5小时等）

第四，抽象需求的目的是探索需求本质，寻找最佳解决方案，而非完美方案。

完美解决方案是理想世界的产物，现实世界的最佳方案是需要权衡所有利益相关者后的妥协方案，它需要考虑成本与收益的平衡。

比如案例1中，最终采取的是简化版的自定义审批自动关联考勤状态（即通过插件定时读取自定义审批信息后，自动更新考勤状态），它是成本最小，却可以有效解决客户需求的最佳方案。

第五，分析需求时，按需求的场景、流程、规则、模式等进行关键词提炼，且逐级向上抽象后，再进行场景归类，最终用一种可视化的方式完成表达。它可以是一张图，也可以是一个表格等，形式不重要，重要的是思维。

三、写在最后

抽象能力在需求分析方面确实起着至关重要的作用。它帮助我们从复杂的信息中提炼出核心要素，从而更准确地理解和满足用户需求。

版权声明

本文来自互联网用户投稿，文章观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若转载，请注明出处。如若内容有涉嫌抄袭侵权/违法违规/事实不符，请点击 举报 进行投诉反馈！