作者從打車問題和門戶内容的排序和置頂問題為例，制作了一個需求複盤模闆，方便自己對一些重要的需求實現進行複盤和思考，同樣公開分享給感興趣的夥伴們，一起來看看吧~

大家好！我是愛喝冰可樂的産品經理P仔！

一、需求複盤=産品經理自我疊代

這周看了俞軍的《産品方法論》，裡面一章介紹到了滴滴在産品演進的路徑上遇到的幾個有意思的産品需求決策問題，比如快車在高峰期應該用動态調價模式還是排隊模式，如何滿足酒後乘客打車的問題（又要減少對司機帶來的影響），書中寫下了具體實現的方法、遇到的問題以及後續的優化等思考決策的全過程。

受此啟發，我決定制作一個需求複盤模闆，方便自己對一些重要的需求實現進行複盤和思考，同時也公開給大家使用。複盤模闆具體分為以下5個步驟：

需求複盤模闆：

下面我們通過4個具體的需求複盤例子來看看應該如何使用這個模闆。

二、案例① 出行高峰如何打到車？

1. 需求背景：出行行業有明顯的峰值，且峰具有非常強的時間、地點屬性，比如下班時的CBD，同時因為道路擁擠、司機供給等因素，最終結果就是供需失衡：司機在高峰期不願意去熱區；用戶在高峰期打車難。

2. 初始做法：采用動态調價，在高峰期臨時調整打車價格，讓出價意願高的用戶得到打車的機會，其實本質上是用高價格打壓打車的需求，但是用戶打車的需求又是剛需，這樣會導緻用戶體驗很差。要回歸解決問題的本質，要考慮”更快打車“的三層含義：

1. 第一層是對何時能打到車的預期（預計多久打到車倒計時）；
2. 第二層是這個預期是否準确（預測的打車時間是否準确）；
3. 第三次是這個預期能否做得更快。

因此滴滴推出了排隊的模式：在出行高峰時，會出現排隊隊列序号、排隊計時、預計打到車的時間等提示給用戶端，控制用戶預期并給司機供給側更多的調度時間。

3. 遇到的問題：有不可預測的緊急情況下，也有用車需求，排隊功能無法滿足迫切打到車的需求。

4. 分析與解決：引入排隊功能後，隐含的是大家對于出行的緊急程度都是一樣的一種假設公平狀态，事實上還會有很多緊急狀況，導緻每個打車用戶的緊急程度（或者說産品效用）是不一樣的。這時需要滴滴需要引入“緊急程度”的處理機制。

5. 下一次行動與洞察：隻有用戶可以表達自己緊急的訴求，因此這個緊急程度應該是用戶主動評判的，在用戶主動發出“緊急”的信号後，可以走排隊的快速通道（很容易理解），然後通過限制每月使用次數來保證公平性。次數可以通過會員等級獲得，也可以通過積分兌換（這點可以和會員體系、積分系統打通，對産品總效用提升大）。後面類似的增值服務，都可以通過會員體系來解鎖，增加了滴滴的替換成本（加深護城河）。

三、案例② 醉酒乘客打車問題的權衡

1. 需求背景：醉酒乘客乘車，容易和司機發生糾紛，平台也存在比較嚴重的安全風險和服務難點：

1. 容易發生性騷擾或者影響司機駕駛
2. 乘客到目的地後無法保持清醒，司機沒辦法開始下一筆訂單
3. 乘客可能嘔吐弄髒車輛，産生額外的清潔費用

2. 初始做法：保持司機不能随便拒絕訂單的限制（司機每天有2次無責任拒單機會），但引導酒後用車的用戶主動報備。

3. 遇到的問題：沒有特别好的方法滿足該場景下多方的需求，即使用戶主動報備，還是會出現需求背景中提到的問題場景。

4. 分析原因：在該場景中，不确定性是由酒後乘車的用戶帶來的，作為平台隻能對自身以及司機的行為進行約束，而無法約束用戶行為，也就是無法先驗地防止這類事情發生，平台能做的事情是意外發生後進行及時的彌補措施。通過引導用戶主動報備，可以提前告知司機潛在的風險以及進行心理建設。

5. 下一次行動與洞察：

1. 大部分意外情況的結果都轉化為經濟糾紛，比如清理費用、等待超時的費用，這方面可以由平台作為第三方把賬單給用戶進行收取，平台可以墊付或者等用戶支付後轉給司機；
2. 本身滴滴存在會員體系，可以在會員體系中引入黑名單或者通過會員權益收回達到懲罰違規用戶不守信用用戶的目的，書中也提到過“權力三角”的原則，通過教育用戶珍惜和保護自己的權力來進行行為引導和約束。這樣也避免了平台向乘車用戶的絕對傾斜，損害了司機側的效用。

四、案例③ 乘客中途需要修改目的地

1. 需求背景：乘客已經上車，在需要修改目的地時，平台沒有提供對應的功能，都是用戶與司機進行線下溝通，因此可能産生不可控的司乘糾紛。

2. 初始做法：滴滴上線了允許修改目的地的功能，用戶在上車後，可以在app上更改目的地。

3. 遇到的問題：對用戶來說，提供了功能代表允許（至少功能上允許）更改目的地，但是這引起了司機的不滿。對于滴滴平台來說，司機代表供給側的用戶，乘客代表消費側的用戶。消費者的效用提升是以司機側的效用降低為代價的，長遠來說帶來的總效用可能是負的。

4. 分析原因：在平台、司機、乘客的三角關系中，其地位乘客>平台>司機，司機處在相對弱勢的地位，同時修改目的地的需求損害了司機的效用（具體可能表現為訂單收益降低，期望收益受損，人是有損失厭惡的），但是平台和司機也隻是合作關系，司機離開滴滴的沉沒成本低，可能會導緻司機出走，供給端被削弱，直接擡高了運力成本，最終還是反映到用車成本上升上。那麼修改目的地的決策問題就轉化成滿足乘客修改目的地的效用提升和用車價格上升，最終還是成本問題。

5. 下一次行動與洞察：保持司機無法随意拒單的限制（實際一天有2次拒單機會），在此基礎上允許乘客有限制地修改目的地（隻能改一次/隻能改為原目的地範圍内/加錢改目的地等），在盡量不損失司機收獲效用地基礎上，滿足乘客修改目的地的需求。

五、案例④ 門戶内容的置頂和排序

1. 需求背景：對于類似今日頭條等資訊類web或者app，發布在門戶的内容，需要人為控制排序，有些内容是日常置頂，其餘内容也想手動調整排序。

2. 初始做法：在列表頁中直接加操作列，控制某個屬性的開關，比如首頁的輪播位置，對應的開關列屬性就是首頁輪播。不過輪播的位置容納的數量有限，因此如果有超過容器上限的内容數量開啟了輪播，會再過濾最新的N條（N是容器上限）。

排序則直接新增排序操作列，通過控件的置頂、上移一位、下移一位、置底4個icon操作按鈕進行位置的調整。

3. 遇到的問題：屬性開關多了之後，雖然取了發布時間進行過濾，但是在列表頁上是允許操作比展示數量上限多的開關，會造成後台和前台的數量不對應（反直覺）；排序調整在跨頁的情況下失效，在篩選狀态下執行的操作難以理解。

4. 分析原因：屬性開關的隻考慮了需求實現，沒有考慮網站運營人員的使用體驗。排序的功能則是比較粗暴地實現，沒有挖掘背後的需求。

5. 下一次行動與洞察：目前隻用一個集中的内容列表，是對全狀态内容的維護，包括審批、二次編輯、删除、上下架等，但是對展示屬性控制以及順序調整，要針對已發布狀态下的内容才有意義，而且一般對内容的順序管理會要求在最新的一批，不會總是對内容進行全量的排序調整，因此隐含着隻對最新一定數量的内容進行順序管理。

那麼改進的做法就是新起一個tab，專門展示狀态為已發布的，集中對已發布的内容進行置頂和順序的管理。具體改進措施有：

1. 對特殊屬性的控制依舊使用開關的形式，問題轉化為如何控制數量。可以考慮采用冒泡的形式，限定上限為N時，當開啟第N 1個屬性時，會自動關閉第1個，保持總數最多為N
2. 針對順序控制：列表帶有分頁器，假設對最新的前50條内容進行屬性和排序控制（具體X條每頁可以根據實際情況調整）。如此可以保證用戶在1頁内對内容進行排序調整，規避了排序時跨頁的問題，同時針對已發布狀态單獨切tab，也過濾了無關的内容，保持頁面展示的内容是必要的。

六、案例需求複盤模闆小結

經過上面幾個具體的例子，我自己給每個步驟定義的具體内容如下：

1. 需求背景：描述需求産生的背景、原因、必要性等；
2. 初始做法：記錄第一次産品需求實現的思路和方案；
3. 遇到的問題：産品需求實現後，遇到的新問題；
4. 分析原因：從新的問題，反推是需求處理的時候，是解決方向錯誤/邊界沒有确定好/對分支、異常情況的處理有遺漏等哪些原因導緻目前的問題。為什麼不能提前就考慮到這些方面？
5. 下一步行動與洞察：經過1-4的分析，我們就可以得到：①下一次疊代改進的方向；②通過錯誤總結形成經驗沉澱；③在同一個需求上進行深挖，形成更深或者觸類旁通的洞察！

這次的分享就到這裡！希望大家也可以用上這個需求複盤模闆，在産品經理的成長路上駛入高速公路！開瓶冰可樂獎勵自己！~(￣▽￣)~*

更多精彩资讯请关注tft每日頭條，我们将持续为您更新最新资讯!

查看全部