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

8 评论 4667 浏览 53 收藏 14 分钟

如何在满足企业需求的同时,设计出简洁易用的解决方案?关键就在于抽象能力。本文将通过案例分析,探讨如何在需求分析、功能设计、产品规划等方面运用抽象思维,为读者提供实用的方法与思路。让我们一起探索这个神秘而关键的领域吧!

在数字化时代,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中,最终采取的是简化版的自定义审批自动关联考勤状态(即通过插件定时读取自定义审批信息后,自动更新考勤状态),它是成本最小,却可以有效解决客户需求的最佳方案。

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

三、写在最后

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

专栏作家

邢小作,微信公众号:邢小作之家,人人都是产品经理专栏作家。一枚在线教育的产品,关注互联网教育,喜欢研究用户心理。

本文原创发布于人人都是产品经理。未经许可,禁止转载。

题图来自 Unsplash,基于CC0协议

该文观点仅代表作者本人,人人都是产品经理平台仅提供信息存储空间服务。

更多精彩内容,请关注人人都是产品经理微信公众号或下载App
评论
评论请登录
  1. 作为携程员工我必须回应一下,去哪儿和携程并驾齐驱纯属搞笑,去哪儿被携程收购之后,到现在就是个携程的壳子

    来自北京 回复
    1. 是吗?那看来是我唐突了,时过境迁,可能确实如你所说

      来自北京 回复
  2. 班次管理:将班次分成日班、夜班两大类。日班时间范围0点至次日6点。夜班时间范围12点至次日6点。每个班次可设置第一段上班时间段、第二段上班时间段、加班时间段、是否强制打卡、打卡时间是否限制时间范围。不同部门制定不同班次类型。排班管理:排班时,每个部门内设置排班模板(可多个),方便批量应用于部门内员工。也可针对单个员工进行调节每日的排班班次。加班管理:每个部门的班次,可支持单独设置不同的加班计费规则(固定时间段、自动时间计算、是否自动生成、是否需要申请)。考勤管理:根据每个员工每日设置的班次实际每日的打卡时间核算。薪酬管理:可对每个班次设置不同的薪酬结算系数(例如工作日1、节假日3、停工日0.7)。这样如果发生停工日,就提前设置停工日班次,并设置为无需打卡,在考勤核算时可解决这个场景需求。

    来自上海 回复
    1. 嗯,可能是个思路,唯一需要探讨的是:班次跟薪酬结算系数进行耦合设计,是否便于扩展?

      来自北京 回复
  3. 请假
    员工普通请假
    主动提交
    组长批量请假
    1、批量选择人员,同时选择请假起止时间,勾选请假类型,例如:公司生产安排
    2、提交之后进入审批流程
    3、审批通过之后抄送各员工,仅可查看,不可修改
    4、工作日内的请假自动关联考勤,系统判断只要勾选了请假类型为公司生产安排的请假则为正常出勤,且计算70%工资

    来自北京 回复
    1. 从功能逻辑说,可能大差不差,但从需求来说,停工与批量请假还是有所区别,用批量请假只能算是一直折中方案

      来自北京 回复
  4. 期待后续内容~

    来自山东 回复
    1. 已更新一大部分,期待更多交流、反馈

      来自北京 回复