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

大家好！我是愛喝冰可樂的產(chǎn)品經(jīng)理P仔！

一、需求復(fù)盤=產(chǎn)品經(jīng)理自我迭代

這周看了俞軍的《產(chǎn)品方法論》，里面一章介紹到了滴滴在產(chǎn)品演進(jìn)的路徑上遇到的幾個有意思的產(chǎn)品需求決策問題，比如快車在高峰期應(yīng)該用動態(tài)調(diào)價模式還是排隊模式，如何滿足酒后乘客打車的問題（又要減少對司機帶來的影響），書中寫下了具體實現(xiàn)的方法、遇到的問題以及后續(xù)的優(yōu)化等思考決策的全過程。

受此啟發(fā)，我決定制作一個需求復(fù)盤模板，方便自己對一些重要的需求實現(xiàn)進(jìn)行復(fù)盤和思考，同時也公開給大家使用。復(fù)盤模板具體分為以下5個步驟：

需求復(fù)盤模板：

1. 需求背景
2. 初始做法
3. 遇到的問題
4. 分析原因
5. 下一次行動與洞察

下面我們通過4個具體的需求復(fù)盤例子來看看應(yīng)該如何使用這個模板。

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

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

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

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

因此滴滴推出了排隊的模式：在出行高峰時，會出現(xiàn)排隊隊列序號、排隊計時、預(yù)計打到車的時間等提示給用戶端，控制用戶預(yù)期并給司機供給側(cè)更多的調(diào)度時間。

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

4. 分析與解決：引入排隊功能后，隱含的是大家對于出行的緊急程度都是一樣的一種假設(shè)公平狀態(tài)，事實上還會有很多緊急狀況，導(dǎo)致每個打車用戶的緊急程度（或者說產(chǎn)品效用）是不一樣的。這時需要滴滴需要引入“緊急程度”的處理機制。

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

三、案例② 醉酒乘客打車問題的權(quán)衡

1. 需求背景：醉酒乘客乘車，容易和司機發(fā)生糾紛，平臺也存在比較嚴(yán)重的安全風(fēng)險和服務(wù)難點：

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

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

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

4. 分析原因：在該場景中，不確定性是由酒后乘車的用戶帶來的，作為平臺只能對自身以及司機的行為進(jìn)行約束，而無法約束用戶行為，也就是無法先驗地防止這類事情發(fā)生，平臺能做的事情是意外發(fā)生后進(jìn)行及時的彌補措施。通過引導(dǎo)用戶主動報備，可以提前告知司機潛在的風(fēng)險以及進(jìn)行心理建設(shè)。

5. 下一次行動與洞察：

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

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

1. 需求背景：乘客已經(jīng)上車，在需要修改目的地時，平臺沒有提供對應(yīng)的功能，都是用戶與司機進(jìn)行線下溝通，因此可能產(chǎn)生不可控的司乘糾紛。

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

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

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

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

五、案例④ 門戶內(nèi)容的置頂和排序

1. 需求背景：對于類似今日頭條等資訊類web或者app，發(fā)布在門戶的內(nèi)容，需要人為控制排序，有些內(nèi)容是日常置頂，其余內(nèi)容也想手動調(diào)整排序。

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

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

3. 遇到的問題：屬性開關(guān)多了之后，雖然取了發(fā)布時間進(jìn)行過濾，但是在列表頁上是允許操作比展示數(shù)量上限多的開關(guān)，會造成后臺和前臺的數(shù)量不對應(yīng)（反直覺）；排序調(diào)整在跨頁的情況下失效，在篩選狀態(tài)下執(zhí)行的操作難以理解。

4. 分析原因：屬性開關(guān)的只考慮了需求實現(xiàn)，沒有考慮網(wǎng)站運營人員的使用體驗。排序的功能則是比較粗暴地實現(xiàn)，沒有挖掘背后的需求。

5. 下一次行動與洞察：目前只用一個集中的內(nèi)容列表，是對全狀態(tài)內(nèi)容的維護(hù)，包括審批、二次編輯、刪除、上下架等，但是對展示屬性控制以及順序調(diào)整，要針對已發(fā)布狀態(tài)下的內(nèi)容才有意義，而且一般對內(nèi)容的順序管理會要求在最新的一批，不會總是對內(nèi)容進(jìn)行全量的排序調(diào)整，因此隱含著只對最新一定數(shù)量的內(nèi)容進(jìn)行順序管理。

那么改進(jìn)的做法就是新起一個tab，專門展示狀態(tài)為已發(fā)布的，集中對已發(fā)布的內(nèi)容進(jìn)行置頂和順序的管理。具體改進(jìn)措施有：

1. 對特殊屬性的控制依舊使用開關(guān)的形式，問題轉(zhuǎn)化為如何控制數(shù)量?？梢钥紤]采用冒泡的形式，限定上限為N時，當(dāng)開啟第N+1個屬性時，會自動關(guān)閉第1個，保持總數(shù)最多為N
2. 針對順序控制：列表帶有分頁器，假設(shè)對最新的前50條內(nèi)容進(jìn)行屬性和排序控制（具體X條每頁可以根據(jù)實際情況調(diào)整）。如此可以保證用戶在1頁內(nèi)對內(nèi)容進(jìn)行排序調(diào)整，規(guī)避了排序時跨頁的問題，同時針對已發(fā)布狀態(tài)單獨切tab，也過濾了無關(guān)的內(nèi)容，保持頁面展示的內(nèi)容是必要的。

六、案例需求復(fù)盤模板小結(jié)

經(jīng)過上面幾個具體的例子，我自己給每個步驟定義的具體內(nèi)容如下：

1. 需求背景：描述需求產(chǎn)生的背景、原因、必要性等；
2. 初始做法：記錄第一次產(chǎn)品需求實現(xiàn)的思路和方案；
3. 遇到的問題：產(chǎn)品需求實現(xiàn)后，遇到的新問題；
4. 分析原因：從新的問題，反推是需求處理的時候，是解決方向錯誤/邊界沒有確定好/對分支、異常情況的處理有遺漏等哪些原因?qū)е履壳暗膯栴}。為什么不能提前就考慮到這些方面？
5. 下一步行動與洞察：經(jīng)過1-4的分析，我們就可以得到：①下一次迭代改進(jìn)的方向；②通過錯誤總結(jié)形成經(jīng)驗沉淀；③在同一個需求上進(jìn)行深挖，形成更深或者觸類旁通的洞察！

這次的分享就到這里！希望大家也可以用上這個需求復(fù)盤模板，在產(chǎn)品經(jīng)理的成長路上駛?cè)敫咚俟?！開瓶冰可樂獎勵自己！[]~(￣▽￣)~*?