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

大家好！我是愛喝冰可樂的產品經理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的分析，我們就可以得到：①下一次迭代改進的方向；②通過錯誤總結形成經驗沉淀；③在同一個需求上進行深挖，形成更深或者觸類旁通的洞察！

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

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

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

該文觀點僅代表作者本人，人人都是產品經理平臺僅提供信息存儲空間服務。