如何在滿足企業(yè)需求的同時，設(shè)計出簡潔易用的解決方案？關(guān)鍵就在于抽象能力。本文將通過案例分析，探討如何在需求分析、功能設(shè)計、產(chǎn)品規(guī)劃等方面運用抽象思維，為讀者提供實用的方法與思路。讓我們一起探索這個神秘而關(guān)鍵的領(lǐng)域吧！

在數(shù)字化時代，SaaS產(chǎn)品經(jīng)理面臨巨大挑戰(zhàn)和機遇。設(shè)計既滿足企業(yè)需求又易于使用的解決方案，關(guān)鍵在于抽象能力。

抽象看似復(fù)雜，實則像馬云所言：“簡單是終極的復(fù)雜?！痹赟aaS產(chǎn)品設(shè)計中，抽象能力是實現(xiàn)簡潔與功能性結(jié)合的核心，可能直接影響產(chǎn)品成敗。

講個小故事。

一、為什么去哪兒比攜程晚成立6年，卻最終可以并駕齊驅(qū)？

去哪兒創(chuàng)始人莊辰超指出，攜程的市場定位是“在線旅游”，包括在線酒店和機票等，當(dāng)時市場占有率超過50%。然而，攜程犯了一個關(guān)鍵錯誤，即錯誤預(yù)估了自己的市場規(guī)模，這為去哪兒提供了機會。

為什么會錯誤預(yù)估市場規(guī)模呢？原因有兩方面：

• 一是“在線旅行”市場每年以40%-50%的速度增長。即使現(xiàn)在占有50%的市場，1-2年后，由于市場高速增長，仍會為后來者留出空間。
• 二是“在線旅行”需求不夠抽象，它不是人的本質(zhì)需求。人的本質(zhì)需求是外出旅行或辦公時有一個住的地方，Airbnb提供的解決方案是共享房屋，而不是在線預(yù)定酒店。所以它的市場遠超攜程與去哪兒之和。

莊辰超最后總結(jié)說：如果你想做事兒，一定要間隔半年或一年，就需要把你所做的事兒向上抽象一個層次。即思考你到底在做什么事兒，滿足什么人的本質(zhì)需求。

說明：這個故事來源于張蕭雨老師的課程分享，如有侵權(quán)，隨時刪除

這個故事帶給我的啟示是：抽象思維是一種關(guān)鍵能力，它超越特定崗位，具有普遍適用性。尤其在高級職位中，抽象能力尤為重要。

在市場定位中，你可以抽象出產(chǎn)品的核心價值。例如，釘釘定位為“AI時代的工作方式”，飛書則是“先進團隊的選擇”。

在業(yè)務(wù)分析上，抽象能幫助我們抓住業(yè)務(wù)本質(zhì)。比如，“不在家時的住處”比“在線旅游”更抽象；“企業(yè)數(shù)字化”比“一體化HR SaaS”更抽象，而“降本增效”又比“企業(yè)數(shù)字化”更抽象。

在產(chǎn)品架構(gòu)設(shè)計上，抽象思維能幫助我們理解業(yè)務(wù)底層架構(gòu)和頁面結(jié)構(gòu)。例如，WorkDay的HR業(yè)務(wù)把產(chǎn)品架構(gòu)抽象為：系統(tǒng) = 流程 + 業(yè)務(wù)對象。頁面架構(gòu) = 對業(yè)務(wù)對象的查詢頁面+對業(yè)務(wù)對象的操作流程頁面+流程的歷史查看頁面。

在需求分析上，抽象能揭示用戶需求的深層本質(zhì)。用戶要錘子，可能真正需要的是一個舒適溫馨的家居空間。

在產(chǎn)品設(shè)計上，通過抽象用戶場景，我們可以設(shè)計出滿足需求的菜單、實體關(guān)系、頁面要素和組件。

抽象思維不僅限于這些場景，它在組織架構(gòu)設(shè)計、企業(yè)愿景、數(shù)據(jù)分析等方面同樣重要。由于篇幅限制，這里不再一一列舉。

雖能力有限，卻想圍繞【抽象能力：SaaS產(chǎn)品經(jīng)理的核心能力】為主題，盡自己所能分享一個小專題，期望對你有所啟發(fā)。

它們可能包含：

• 需求分析：如何從復(fù)雜的需求中抽象出核心問題？
• 功能設(shè)計：如何將復(fù)雜的功能抽象成簡潔易用的設(shè)計？
• 產(chǎn)品規(guī)劃：如何抽象地規(guī)劃產(chǎn)品路線圖和功能優(yōu)先級？
• 實體設(shè)計：如何將復(fù)雜系統(tǒng)進行抽象架構(gòu)設(shè)計？
• 產(chǎn)品架構(gòu)：如何將復(fù)雜系統(tǒng)進行場景化設(shè)計？
• 流程設(shè)計：如何將用戶場景抽象為系統(tǒng)流程？

今天從【需求分析：如何從復(fù)雜的需求中抽象出核心問題】開始。

案例1：如何解決制造業(yè)的停工問題？

客戶A是一家制造業(yè)企業(yè)，面臨生產(chǎn)任務(wù)波動導(dǎo)致的員工停工問題。當(dāng)前系統(tǒng)不支持多人批量請假，導(dǎo)致請假流程繁瑣，需要手動修改考勤結(jié)果?？蛻羝谕到y(tǒng)能夠支持多人批量請假，以簡化流程并自動關(guān)聯(lián)考勤狀態(tài)。如果無法得到有效解決，則要退費。

需求溝通過程：

PM：“在什么情況下，你們需要批量請假？”

客戶：“當(dāng)客戶停工時。這種情況下，我們需要給員工批量請假，并按照70%的薪資發(fā)放?！?/p>

PM：“通常什么原因會導(dǎo)致停工？”

客戶：“我們客戶主要是制造業(yè)，生產(chǎn)任務(wù)會隨市場波動。任務(wù)少時，我們會優(yōu)先安排部分員工停工。為了留住員工，我們?nèi)詴Ц?0%的工資?！?/p>

PM：“那么，一般是誰來發(fā)起這個請假申請？”

客戶：“主要是班組長代為發(fā)起?！?/p>

PM：“員工可以自主發(fā)起申請嗎？”

客戶：“不可以。因為這是企業(yè)行為，不能由員工自行申請。而且，如果員工看到‘請假’選項，可能會感到困惑，不明白為什么停工需要他們申請，而且與普通請假在同一個頁面?！?/p>

PM：“那你們現(xiàn)在是如何處理這個流程的？”

客戶：“我們通過自定義審批流程來處理?？梢耘窟x擇日期和發(fā)起人，但不會自動關(guān)聯(lián)考勤狀態(tài)。審批通過后，管理員會根據(jù)申請手動修改考勤結(jié)果。系統(tǒng)會根據(jù)自定義假期（即停工）自動核算70%的工資?！?/p>

PM：“能告訴我大概的停工頻次和每次停工的人數(shù)情況嗎？”

客戶：“停工頻次會因季節(jié)而異，有時候半天、1天，有時候好幾天。人數(shù)也不確定，有時候1-2人，有時候十幾個人?！?/p>

需求分析與抽象過程：

客戶核心需求：有效地解決制造業(yè)中因市場波動導(dǎo)致的周期性停工問題，同時控制人力成本并避免員工流失。

需求層次分析：

• 第一層是表層需求： 實現(xiàn)批量請假功能，以簡化人工處理考勤狀態(tài)的工作。
• 第二層是實際需求： 自定義假期審批，自動關(guān)聯(lián)考勤狀態(tài)，以應(yīng)對停工需求。
• 第三層是深層次需求： 在停工期間保持員工薪酬，以減少成本并保持員工穩(wěn)定。
• 第四層是核心需求： 在市場波動時，找到平衡人力成本和員工留存的長期解決方案。

解決方案建議：

• 1.短期解決方案： 改進現(xiàn)有請假流程，支持多人批量請假，簡化操作。
• 2.中期解決方案： 開發(fā)系統(tǒng)功能，實現(xiàn)自定義假期審批與考勤狀態(tài)的自動關(guān)聯(lián)。
• 3.長期解決方案： 設(shè)計并實施一套完整的“停工不停薪”方案，保障員工利益。
• 4.戰(zhàn)略解決方案： 推行綜合工時制度，靈活調(diào)整工作時長，按周期計算總工時，以適應(yīng)市場波動，同時控制成本和保持員工隊伍穩(wěn)定。

案例2：如何從復(fù)雜的加班需求中，抽象出需求場景？

加班是HR SaaS的一個基礎(chǔ)且復(fù)雜的模塊，當(dāng)面臨以下未滿足的需求，如何分析需求后，提煉出場景并進行解決？

第一步：分析并提煉需求（至少提煉2層）?？梢园葱枨蟮膩碓?、方式、規(guī)則、位置等不同維度進行標識。比如加班源-加班模式-加班位置-加班類型-加班時間/休息時間-補償方式-打卡規(guī)則-加班限制-加班舍去等，最后加上關(guān)鍵描述。

注意：上述需求是節(jié)選需求，實際需求量至少是3-5倍以上。

第二步：全面進行需求抽象設(shè)計。你可采取可視化方式，把對應(yīng)需求進行抽象后，形成一張完整的需求迭代進度圖。

第三步：根據(jù)需求量、緊急程度以及產(chǎn)研資源，確認需求優(yōu)先級。你可采取【以終為始，全面設(shè)計；以始至終，最小閉環(huán)】的方式進行落地，而不是所有需求一起做。

二、經(jīng)驗時刻

第一，在需求分析時，采用“豐田經(jīng)典五問”方法，深入挖掘問題的根本原因。

• 什么情況下，需要批量請假？停工
• 什么情況下，會停工？市場需求波動
• 為什么停工，還需發(fā)薪70%？節(jié)約人工成本的同時，避免人員流失

第二，溝通時，避免陷入虛擬空間，通過三個關(guān)鍵問題回歸現(xiàn)實。當(dāng)你面對真實客戶進行溝通時，容易讓你跟客戶之間構(gòu)建起一個虛擬空間，從而忽略現(xiàn)實而輕易承諾。

一般我會用三個關(guān)鍵問題，把它拉回到現(xiàn)實世界。

• 咱們現(xiàn)在是如何進行處理的？
• 咱們大概會涉及到多少員工/用戶？
• 咱們多久會用一次？每天、每周、每月？

第三，明確區(qū)分需求（目的）與解決方案（手段），防止混淆。有時候解決方案，就是需求，卻不一定是真需求。

比如案例1中，需求可能是批量請假，但它卻是一種解決方案，而不是需求；

或案例2中，需可能是不同班次的休息時間不同，而需要按班次設(shè)置休息時間。它的本質(zhì)休息時間不固定，那完全就可以采取根據(jù)加班時長自動扣減休息時長（比如加班8小時扣1小時，10小時扣1.5小時等）

第四，抽象需求的目的是探索需求本質(zhì)，尋找最佳解決方案，而非完美方案。

完美解決方案是理想世界的產(chǎn)物，現(xiàn)實世界的最佳方案是需要權(quán)衡所有利益相關(guān)者后的妥協(xié)方案，它需要考慮成本與收益的平衡。

比如案例1中，最終采取的是簡化版的自定義審批自動關(guān)聯(lián)考勤狀態(tài)（即通過插件定時讀取自定義審批信息后，自動更新考勤狀態(tài)），它是成本最小，卻可以有效解決客戶需求的最佳方案。

第五，分析需求時，按需求的場景、流程、規(guī)則、模式等進行關(guān)鍵詞提煉，且逐級向上抽象后，再進行場景歸類，最終用一種可視化的方式完成表達。它可以是一張圖，也可以是一個表格等，形式不重要，重要的是思維。

三、寫在最后

抽象能力在需求分析方面確實起著至關(guān)重要的作用。它幫助我們從復(fù)雜的信息中提煉出核心要素，從而更準確地理解和滿足用戶需求。