導語：B端業務場景專一化、業務背景復雜，業務方提的需求一般都較為明確，如“我想要一個….功能” 但產品經理在判斷和設計需求時時往往摸著石頭過河，沒有可以衡量判斷的標準，如果能借助生活場景經驗應用在決策中，會讓思路豁然開朗，也對自身判斷有了可預知的底氣。

產品經理最重要的工作是什么？——做決策。

對于1～3年的B端產品經理，面對業務需求，經常需要判斷：

這個業務提的需求該不該做？做或者不做帶來的收益和風險是什么？有比原需求更好的解決方式嗎？未來的擴展性有哪些？

B端不像C端，可以依據數據反饋做決策。

B端產品經理在工作中最常做的是主觀判斷決策，這個感覺就跟摸著石頭過河很像，如果產品sense不夠好，很容易被需求方提的需求帶到一條思維的小路上，雖然修好了小路，但是只能給部分人走，失去了擴展性。

表現形式就是后面系統架構愈加雜亂，功能點散沒有結構性，功能效果藏在代碼邏輯里，對后人和用戶都是黑盒子。

如何才能快速發現問題的本質，判斷需求的合理性、設計方案的可行性呢？運用抽象思維很重要。

下面我介紹一種我自己常用的方法——抽象類比法

抽象類比法，是把事物的表象抽離提煉為一種通用的模式，這種模式可以直接套用在其他不同的場景中直接應用或擴展。

而生活化場景的抽象好處在于生活場景聯想門檻低，易接觸到。同時生活場景的流程模式在得到過廣泛的應用和驗證，是值得信賴的經典模型。

下面給大家介紹下，我借助生活場景模型解決的一個B端產品的任務調度難題。

一、問題背景

在首篇文章中提到過，我重構了一個風控數據測試系統，系統的核心功能是數據的批量匹配。

數據匹配的邏輯是：

把批量樣本文件以一次任務的形式，向不同產品的API接口發起批量的調用請求，收到響應后將接口返回的數據回寫入一個文件中。

如下圖：

這個功能的視覺效果跟多任務下載文件有些相似，不同的是，由于底層API接口有并發數的限制，也就是資源是有限的，因此任務的匹配速度就受到了限制。

此前，系統可以支持最多10個用戶的任務同時進行，各個任務的并發資源數是按當前任務數等分的，如下圖：

即：單任務并發數=總并發數/當前任務數，即任務越多，每個任務的進度就越慢。

除了受到并發數影響，不同任務的匹配時長還受到下面幾個因素的影響：

• 樣本量級不同（不同任務量級跨度大，50條～500w條）
• 調用產品數量不同（不同任務間數量跨度大，1個～50個）
• 不同產品接口的請求響應時間不同（如：評分類產品的請求耗時通常較長）

當然，并發資源是權重最高的因子，如果并發數提升了，整體任務效率都是同比增長的。

其他背景：

• 出于公平性和API底層的考量，一個用戶如有多個任務，在發起后，同一時間只能一個任務在進行中，其他任務均為等待中。
• 匹配列表為唯一數據權限公開的模塊，可供所有用戶查看當前系統的任務匹配和資源占用情況，以便了解自己的任務是否需要排隊等待。

二、改造前的問題

因為原流程資源是均分制的，也就是對所有任務一視同仁，不區分任務的緊急程度、樣本大小等因素，按時間次序將任務依次放進匹配通道中，如果此時10個匹配通道均已占用，那后面的任務就都需要等待。

任務高峰期，系統上最多有50個任務在等待中，最長一個任務從發起到匹配結束花了將近3天的時間。

大任務測不完，小任務測不上；10個通道持續滿載，任務堆積嚴重。是這個核心功能最大的問題。

系統用戶（分析師）找我反饋的次數也不少，都是希望我能給他們插隊的：

• “我這個是付費測試，你們不給優先處理嗎？”
• “我就50條樣本，能讓我先測下不？”
• “我的任務緊急，客戶明天就要，能不能插隊呀”
• …

大概這樣的嚴重擁擠情況持續了1周左右，我意識到務必要做出改變，在并發數有上限的情況下，如何實現資源的最大化利用，這應該是需要精細化策略設計的問題。

三、問題分析

既然決定要改原有的邏輯，如何設計才合理？難道要像用戶所提的，增加一個插隊功能？管理員可以改變任務順序，可以隨意把后面的任務放置前面？

當然不行！

這是一個與調度秩序有關的問題，假如說開了這個口子，且不說系統技術邏輯復雜度加重，而是從常理的公平性角度想：

• 把一個等待中的任務放在匹配隊列中，必然會影響一個匹配中任務
• 把任務提到等待隊列的最前位，也影響了后面其他人的等待中任務

這些都是不公平的，不論怎么做，都是影響了其他用戶的利益。

如果每個人因為想因為要加速都來找管理員開這個口子，那系統的匹配功能將失去秩序，操作頻繁時，系統來不及更新狀態，可能會影響調用結果的準確性，風險性極大。

那既然這樣，如何思考才能有效解決這個問題？

我們需要撥開表象看本質，抓住問題的主要矛盾，防止被用戶的訴求帶偏。

如何抓住核心矛盾？我們可以借助抽象類比的方法。

四、抽象類比

這個問題的本質是流量調度，那么聯想生活場景，哪些場景跟流量有關？

是不是能想到“人潮涌動、排隊檢票”的場景？進而聯想到機場、火車站或景區門口的景象。

我們拿機場舉例，將實際事物與系統場景進行類比：

• 樣本可以比作旅客
• 樣本量大小可以比作一個旅行團的大小
• 任務數可以比作安檢通道的個數
• 每個任務的并發數，可以比作每個安檢通道內可以同時做檢查的工作人員數（人數越多安檢越快）
• 每次匹配的產品多少可以類比為旅行團的行李（行李越多安檢越慢）

綜上所述，能確定基于流量場景的調度設計可參考抽象后的“安檢口”模型。

那機場安檢口是怎么解決流量調度問題的？

• 「針對普通用戶」普通旅客走常規安檢口，常規安檢口數量有一般有多個。
• 「針對高級用戶」VIP旅客走VIP安檢口，解決VIP旅客對時間要求高的問題
• 「針對特殊用戶」長期開放快速通道安檢口，為殘疾人等需要關注的旅客提供便利
• 「針對緊急用戶」當旅客著急趕飛機時，可以在機場工作人員的允許后，走快速通道安檢口

上面四種解決問題的邏輯恰好跟我上面收集的用戶反饋情況對應上了

• “我這個是付費測試，你們不給優先處理嗎？”——高級用戶問題
• “我就50條樣本，能讓我先測下不？”——特殊用戶問題
• “我的任務緊急，客戶明天就要，能不能插隊呀”——緊急用戶問題

這剛好是所有流量場景中最常遇到的三種問題，它們的應對辦法分別是：

• 按重要性對資源進行有差別劃分
• 特殊情況給予特殊資源傾斜照顧
• 緊急非重要情況給予通融的機會

五、方案設計

有了上面的生活場景參考，我們具體到系統的功能邏輯里，在“安檢口”模型的基礎上，考慮到了并發資源最大化利用的問題（不能讓資源空著不用）我是這樣設計的：

首先，我們假設系統匹配任務的總并發數為N：

1. 「重」解決付費工單要求提高優先級高的需求

• 【任務分類】根據測試目的把工單分為兩種：高優先級工單（付費測試）、低優先級（免費測試）
• 【評估配比】計算歷史任務中，高優先級工單與低優先級工單的數量比，為1:7，這個比例跟上面的「高級用戶」場景相似，都是重要的事物，量少；普通的事物，量多。
• 【套用模型】故類比安檢口「高級用戶」模型，遵從二八法則，將原有的10任務通道分類，最多2個高速通道、最多8個普通通道。高優先級任務走高速通道，低優先級任務走普通通道。高速任務如超過2個順位走普通通道，后續按次序自動補位進入高速通道。
• 【動態分配】當平臺僅有普通任務時，假設任務數為x，此時每個任務的并發數為N/x。當此時出現高速通道任務，任務數為y，系統自動劃分N/2并發數支持高速通道，因此每個高速任務最少有N/4個并發數，這一步是為了保護高速任務的進行效率。此時低速通道任務并發數自動減半變為N/2x。
• 【資源釋放】高速任務一般任務數量少，速度有保障的前提下匹配的時間短，故在高速任務完成后，將自動釋放N/2的總并發數，歸還于普通任務。

2. 「輕」解決量小高頻的小樣本快速測試需求

• 【量級分類】考慮到約80%的用戶在全量樣本測試前都需要用小量樣本做驗證測試，要保證驗證測試的敏捷性，故需要增加量級分類。如，200行以內的樣本，為小樣本任務。200行以上的為普通任務。
• 【獨立邏輯】類比上述安檢口「特殊用戶」模型，小樣本任務走專用通道單獨排隊，不與普通任務同時排隊。且因量級小平均一個任務僅需1～3min，故不需要判讀任務優先級等情況。
• 【額外資源】基于小樣本每次量級小，對底層基本無壓力的情況，我向架構組成功了申請在原有并發數N的基礎上，額外增加N/10的并發，一般情況下只給小樣本任務單獨使用。
• 【快速通道】因為小樣本任務高頻，約占40%的總任務量，且匹配快速，故設置小樣本任務通道數為最多為5，在假設小樣本任務數為m的情況下，每個小樣本匹配時的并發量最少可為N/10m，這樣基本上用戶一提交小樣本測試就能直接進入匹配隊列中，降低對小樣本驗證的等待焦慮。

3. 「急」解決緊急普通任務的加速需求

【提速審批】與在機場安檢口，普通旅客趕飛機需要經過安檢人員的同意才能走快速通道的情況相似。普通任務一般只能走普通通道，但緊急情況下，如果想加速必須經過領導審批，證明你是真正的緊急。有了審批這一步會減少非真正緊急的提速需求，防止公共資源被不合理占用。

【人工控制】控制任務是否提速的按鈕權限在管理員這里，沒有直接做成對接線上審批流的原因有兩點。

1. 希望在上線后觀察用戶使用效果，看看經過改造后是否還有任務提速的需求。
2. 管理員評估會讓這個流程更可控，比如當前就有2個高速任務在進行中，高速列表占用，就算審批結束也不能一下子解決問題，這里需要人為決策的維度更多。

【任務升級】普通任務手動提速后，會給予更多并發資源。在這里設計的是，如果提速成功，可與高優先級任務共享高速通道，通道數依舊最大為2個，如當前已占用則依舊在普通通道等待。（權重與高優先級任務齊平）

4. 「緩」解決部分接口的降速需求

這是一個基礎架構組基于服務安全考慮給我們提的需求，一小部分產品的接口底層性能有限，不支持過大并發調用，因此在本次需求中，兼顧了部分接口降速的需求。即當任務中出現某些接口時，直接進入小并發池中匹配。

• 【并發分配】系統在高速通道、普通通道、小樣本通道的基礎上，兼顧了慢速通道。慢速通道的總并發數為總并發數的1/6（根據需要限流的接口能承受的最大并發數賦值的），即為N/6個并發數。從普通任務的并發數中劃分出來，如普通任務的并發數為N，則有低速任務時普通任務并發數為，5/6N。
• 【通道共享】慢速任務可以理解為被迫限流的普通任務，故與普通任務共享8個通道數，當8個通道在占用時，第九個任務無論是普通任務還是低速任務均進入等待隊列

5. 針對少數情況的前置規則先行

前面說了，通過歷史數據的統計分析，得出高速任務的需求占比為1/8，大多數情況下，不會出現高速任務數大于普通任務數的情況。

• 少數情況如：當前普通任務為0、高速任務為1時，照此前邏輯將啟用高速通道，此高速任務的并發數為N/2，但此時的最優解應是高速任務獨享整個并發資源N。故需考慮到這種情況，并增加前置規則。
• 為了清晰的找到前置規則，我在下方用了枚舉法，假設普通任務數（x）、高速任務數（y）、低速任務數（z），即可得出當{ 0 <= x< y<=2 } 時，系統不啟用高速通道，是資源最大化利用的最優解。

6. 小結

以上設計思路，參考了機場安檢口的旅客優先級規則，同時結合實際業務需求場景，在保證并發資源高效利用的原則下，運用抽象類比法將原有的“數據測試等待時間長的問題”抽象為“流量池問題”，引入的5種調度策略，一口氣解決了原流程“輕/重/緩/急”的四種任務調度難題。

六、上線效果

這個策略升級的版本上線后，用戶反饋很好。我在頁面增加了人性化的匹配說明，便于用戶理解改造后的資源調度原則。上線后這么久，沒有一個用戶對改造提出質疑或者反對，我認為是模型在底層提供了合理性保障，給用戶無形中提高了熟悉感，用戶的接納和認可度較高。

同時再次面對問題時，系統都有相應的策略去應對：高優先級的任務能享受高速、小樣本測試能快速得到驗證、緊急任務出現時也能有提速的口子，徹底解決了流量調度中常見的三種問題。平均任務耗時從118min降到了41min，匹配時間減少了近70%，高峰期任務擁擠的情況在上線后也得到了有效的緩解，用戶滿意度自然也就提升了。

七、總結

B端平臺類產品，在產品設計中如果能使用策略手段，提升資源綜合利用率，進而減少使用耗時，提升用戶效率，是產品賦能業務和提高用戶滿意度的一種有效方式。

因為業務場景的復雜多樣，在B端產品經理在設計方案時，沒有像C端產品一樣有競品可以參考。但我們可以對問題進行深挖，多想想這個業務流程的本質到底是什么要解決什么事（比如上面分析的流量調度問題）。

總結一下，當遇到不知如何設計的問題，或者不確定產品方案是否正確時，可以這樣做：

1. 搞清問題本質，聯想現實場景中本質相同的生活模型，一針見血找到核心矛盾點所在。
2. 借助現實場景中同質問題的解決辦法，融入當前產品方案中，拓寬產品設計思路。
3. 參考現實場景的實際效果，預計當前方案效果是否符合現實模型，確認產品設計的合理性。

生活場景模型，是在現實生活中被人無數次驗證過的能解決問題的有效手段。

而產品設計的本質，也是解決問題。

寫這篇文章是想分享自己在工作中解決問題的思路，希望大家在工作時，不妨多嘗試抽象類比法，多想想事物的本質。這樣，能使復雜問題簡單化，讓我們瞬間豁然開朗！

作者：Fancy劉，現某金融科技公司B端產品經理。

本文由@Fancy劉 原創發布于人人都是產品經理，未經許可，禁止轉載。

題圖來自 Unsplash，基于CC0協議。