需求分析:如何從復雜的需求中抽象出核心問題?
如何在滿足企業需求的同時,設計出簡潔易用的解決方案?關鍵就在于抽象能力。本文將通過案例分析,探討如何在需求分析、功能設計、產品規劃等方面運用抽象思維,為讀者提供實用的方法與思路。讓我們一起探索這個神秘而關鍵的領域吧!
在數字化時代,SaaS產品經理面臨巨大挑戰和機遇。設計既滿足企業需求又易于使用的解決方案,關鍵在于抽象能力。
抽象看似復雜,實則像馬云所言:“簡單是終極的復雜?!痹赟aaS產品設計中,抽象能力是實現簡潔與功能性結合的核心,可能直接影響產品成敗。
講個小故事。
一、為什么去哪兒比攜程晚成立6年,卻最終可以并駕齊驅?
去哪兒創始人莊辰超指出,攜程的市場定位是“在線旅游”,包括在線酒店和機票等,當時市場占有率超過50%。然而,攜程犯了一個關鍵錯誤,即錯誤預估了自己的市場規模,這為去哪兒提供了機會。
為什么會錯誤預估市場規模呢?原因有兩方面:
- 一是“在線旅行”市場每年以40%-50%的速度增長。即使現在占有50%的市場,1-2年后,由于市場高速增長,仍會為后來者留出空間。
- 二是“在線旅行”需求不夠抽象,它不是人的本質需求。人的本質需求是外出旅行或辦公時有一個住的地方,Airbnb提供的解決方案是共享房屋,而不是在線預定酒店。所以它的市場遠超攜程與去哪兒之和。
莊辰超最后總結說:如果你想做事兒,一定要間隔半年或一年,就需要把你所做的事兒向上抽象一個層次。即思考你到底在做什么事兒,滿足什么人的本質需求。
說明:這個故事來源于張蕭雨老師的課程分享,如有侵權,隨時刪除
這個故事帶給我的啟示是:抽象思維是一種關鍵能力,它超越特定崗位,具有普遍適用性。尤其在高級職位中,抽象能力尤為重要。
在市場定位中,你可以抽象出產品的核心價值。例如,釘釘定位為“AI時代的工作方式”,飛書則是“先進團隊的選擇”。
在業務分析上,抽象能幫助我們抓住業務本質。比如,“不在家時的住處”比“在線旅游”更抽象;“企業數字化”比“一體化HR SaaS”更抽象,而“降本增效”又比“企業數字化”更抽象。
在產品架構設計上,抽象思維能幫助我們理解業務底層架構和頁面結構。例如,WorkDay的HR業務把產品架構抽象為:系統 = 流程 + 業務對象。頁面架構 = 對業務對象的查詢頁面+對業務對象的操作流程頁面+流程的歷史查看頁面。
在需求分析上,抽象能揭示用戶需求的深層本質。用戶要錘子,可能真正需要的是一個舒適溫馨的家居空間。
在產品設計上,通過抽象用戶場景,我們可以設計出滿足需求的菜單、實體關系、頁面要素和組件。
抽象思維不僅限于這些場景,它在組織架構設計、企業愿景、數據分析等方面同樣重要。由于篇幅限制,這里不再一一列舉。
雖能力有限,卻想圍繞【抽象能力:SaaS產品經理的核心能力】為主題,盡自己所能分享一個小專題,期望對你有所啟發。
它們可能包含:
- 需求分析:如何從復雜的需求中抽象出核心問題?
- 功能設計:如何將復雜的功能抽象成簡潔易用的設計?
- 產品規劃:如何抽象地規劃產品路線圖和功能優先級?
- 實體設計:如何將復雜系統進行抽象架構設計?
- 產品架構:如何將復雜系統進行場景化設計?
- 流程設計:如何將用戶場景抽象為系統流程?
今天從【需求分析:如何從復雜的需求中抽象出核心問題】開始。
案例1:如何解決制造業的停工問題?
客戶A是一家制造業企業,面臨生產任務波動導致的員工停工問題。當前系統不支持多人批量請假,導致請假流程繁瑣,需要手動修改考勤結果。客戶期望系統能夠支持多人批量請假,以簡化流程并自動關聯考勤狀態。如果無法得到有效解決,則要退費。
需求溝通過程:
PM:“在什么情況下,你們需要批量請假?”
客戶:“當客戶停工時。這種情況下,我們需要給員工批量請假,并按照70%的薪資發放?!?/p>
PM:“通常什么原因會導致停工?”
客戶:“我們客戶主要是制造業,生產任務會隨市場波動。任務少時,我們會優先安排部分員工停工。為了留住員工,我們仍會支付70%的工資。”
PM:“那么,一般是誰來發起這個請假申請?”
客戶:“主要是班組長代為發起?!?/p>
PM:“員工可以自主發起申請嗎?”
客戶:“不可以。因為這是企業行為,不能由員工自行申請。而且,如果員工看到‘請假’選項,可能會感到困惑,不明白為什么停工需要他們申請,而且與普通請假在同一個頁面。”
PM:“那你們現在是如何處理這個流程的?”
客戶:“我們通過自定義審批流程來處理??梢耘窟x擇日期和發起人,但不會自動關聯考勤狀態。審批通過后,管理員會根據申請手動修改考勤結果。系統會根據自定義假期(即停工)自動核算70%的工資?!?/p>
PM:“能告訴我大概的停工頻次和每次停工的人數情況嗎?”
客戶:“停工頻次會因季節而異,有時候半天、1天,有時候好幾天。人數也不確定,有時候1-2人,有時候十幾個人?!?/p>
需求分析與抽象過程:
客戶核心需求:有效地解決制造業中因市場波動導致的周期性停工問題,同時控制人力成本并避免員工流失。
需求層次分析:
- 第一層是表層需求: 實現批量請假功能,以簡化人工處理考勤狀態的工作。
- 第二層是實際需求: 自定義假期審批,自動關聯考勤狀態,以應對停工需求。
- 第三層是深層次需求: 在停工期間保持員工薪酬,以減少成本并保持員工穩定。
- 第四層是核心需求: 在市場波動時,找到平衡人力成本和員工留存的長期解決方案。
解決方案建議:
- 1.短期解決方案: 改進現有請假流程,支持多人批量請假,簡化操作。
- 2.中期解決方案: 開發系統功能,實現自定義假期審批與考勤狀態的自動關聯。
- 3.長期解決方案: 設計并實施一套完整的“停工不停薪”方案,保障員工利益。
- 4.戰略解決方案: 推行綜合工時制度,靈活調整工作時長,按周期計算總工時,以適應市場波動,同時控制成本和保持員工隊伍穩定。
案例2:如何從復雜的加班需求中,抽象出需求場景?
加班是HR SaaS的一個基礎且復雜的模塊,當面臨以下未滿足的需求,如何分析需求后,提煉出場景并進行解決?
第一步:分析并提煉需求(至少提煉2層)。可以按需求的來源、方式、規則、位置等不同維度進行標識。比如加班源-加班模式-加班位置-加班類型-加班時間/休息時間-補償方式-打卡規則-加班限制-加班舍去等,最后加上關鍵描述。
注意:上述需求是節選需求,實際需求量至少是3-5倍以上。
第二步:全面進行需求抽象設計。你可采取可視化方式,把對應需求進行抽象后,形成一張完整的需求迭代進度圖。
第三步:根據需求量、緊急程度以及產研資源,確認需求優先級。你可采取【以終為始,全面設計;以始至終,最小閉環】的方式進行落地,而不是所有需求一起做。
二、經驗時刻
第一,在需求分析時,采用“豐田經典五問”方法,深入挖掘問題的根本原因。
- 什么情況下,需要批量請假?停工
- 什么情況下,會停工?市場需求波動
- 為什么停工,還需發薪70%?節約人工成本的同時,避免人員流失
第二,溝通時,避免陷入虛擬空間,通過三個關鍵問題回歸現實。當你面對真實客戶進行溝通時,容易讓你跟客戶之間構建起一個虛擬空間,從而忽略現實而輕易承諾。
一般我會用三個關鍵問題,把它拉回到現實世界。
- 咱們現在是如何進行處理的?
- 咱們大概會涉及到多少員工/用戶?
- 咱們多久會用一次?每天、每周、每月?
第三,明確區分需求(目的)與解決方案(手段),防止混淆。有時候解決方案,就是需求,卻不一定是真需求。
比如案例1中,需求可能是批量請假,但它卻是一種解決方案,而不是需求;
或案例2中,需可能是不同班次的休息時間不同,而需要按班次設置休息時間。它的本質休息時間不固定,那完全就可以采取根據加班時長自動扣減休息時長(比如加班8小時扣1小時,10小時扣1.5小時等)
第四,抽象需求的目的是探索需求本質,尋找最佳解決方案,而非完美方案。
完美解決方案是理想世界的產物,現實世界的最佳方案是需要權衡所有利益相關者后的妥協方案,它需要考慮成本與收益的平衡。
比如案例1中,最終采取的是簡化版的自定義審批自動關聯考勤狀態(即通過插件定時讀取自定義審批信息后,自動更新考勤狀態),它是成本最小,卻可以有效解決客戶需求的最佳方案。
第五,分析需求時,按需求的場景、流程、規則、模式等進行關鍵詞提煉,且逐級向上抽象后,再進行場景歸類,最終用一種可視化的方式完成表達。它可以是一張圖,也可以是一個表格等,形式不重要,重要的是思維。
三、寫在最后
抽象能力在需求分析方面確實起著至關重要的作用。它幫助我們從復雜的信息中提煉出核心要素,從而更準確地理解和滿足用戶需求。
專欄作家
邢小作,微信公眾號:邢小作之家,人人都是產品經理專欄作家。一枚在線教育的產品,關注互聯網教育,喜歡研究用戶心理。
本文原創發布于人人都是產品經理。未經許可,禁止轉載。
題圖來自 Unsplash,基于CC0協議
該文觀點僅代表作者本人,人人都是產品經理平臺僅提供信息存儲空間服務。
作為攜程員工我必須回應一下,去哪兒和攜程并駕齊驅純屬搞笑,去哪兒被攜程收購之后,到現在就是個攜程的殼子
是嗎?那看來是我唐突了,時過境遷,可能確實如你所說
班次管理:將班次分成日班、夜班兩大類。日班時間范圍0點至次日6點。夜班時間范圍12點至次日6點。每個班次可設置第一段上班時間段、第二段上班時間段、加班時間段、是否強制打卡、打卡時間是否限制時間范圍。不同部門制定不同班次類型。排班管理:排班時,每個部門內設置排班模板(可多個),方便批量應用于部門內員工。也可針對單個員工進行調節每日的排班班次。加班管理:每個部門的班次,可支持單獨設置不同的加班計費規則(固定時間段、自動時間計算、是否自動生成、是否需要申請)??记诠芾恚焊鶕總€員工每日設置的班次實際每日的打卡時間核算。薪酬管理:可對每個班次設置不同的薪酬結算系數(例如工作日1、節假日3、停工日0.7)。這樣如果發生停工日,就提前設置停工日班次,并設置為無需打卡,在考勤核算時可解決這個場景需求。
嗯,可能是個思路,唯一需要探討的是:班次跟薪酬結算系數進行耦合設計,是否便于擴展?
請假
員工普通請假
主動提交
組長批量請假
1、批量選擇人員,同時選擇請假起止時間,勾選請假類型,例如:公司生產安排
2、提交之后進入審批流程
3、審批通過之后抄送各員工,僅可查看,不可修改
4、工作日內的請假自動關聯考勤,系統判斷只要勾選了請假類型為公司生產安排的請假則為正常出勤,且計算70%工資
從功能邏輯說,可能大差不差,但從需求來說,停工與批量請假還是有所區別,用批量請假只能算是一直折中方案
期待后續內容~
已更新一大部分,期待更多交流、反饋