起點課堂會員權益
職業體系課特權
線下行業大會特權
個人IP打造特權
30+門專項技能課
1300+專題課程
12場職場軟技能直播
12場求職輔導直播
12場專業技能直播
會員專屬社群
榮耀標識B端產品經理快速提升法——復盤
產品經理要怎樣才可以提高產品能力？一個重要方面在于經驗積累，而這個過程中，復盤是重要的一個步驟，這個步驟可能會比你持續不斷地做新功能更有效。那么，怎么做好全面的復盤？一起來看看作者的總結。
一、為什么要做復盤？
產品經理沒有專業，也沒有科班之說，學計算機的，法律的，設計的…只要想做，都可以成為產品經理。正因為人人都是產品經理，我在剛開始做產品經理的時候，心里很沒底。還特地請教了幾位大佬：怎樣才能提高產品能力呢？要看哪些書呢？
結果，答案很一致：經驗積累。
我以為不停的做功能，做上個三五年，自然就成熟了。然而，埋頭苦干了2年，發現自己還一直在門外徘徊。
不止是我，很多人都不愿意去復盤。覺得功能上線就是終點，其實，這只是個開始。每一次復盤時對自己的批判和肯定，逐漸構建了自己的知識體系。知道哪邊可能會有坑，知道如何最小成本試錯，知道怎么找到用戶需求和開發成本之間的平衡點，知道怎么推動項目，知道怎么和其他團隊協作…
毫不夸張的說，復盤比不停的做功能更加有效，對我來說，絕大部分的能力提升，都來源于復盤。
二、什么時候需要做復盤？
時時刻刻。
是的，你沒有看錯，當發現問題時，就可以去復盤，總結經驗，需要行動的就快速落實。
但這種復盤是不全面、不系統的。我們可以先把日常零散的點記著，再在這些重要的節點上做全面的復盤：
新功能上線半個月后，每1個月后，直到非常穩定。
年中，以及年終對整個系統的全面復盤。
三、如何做好全面復盤？
復盤要從用戶的使用情況入手，通過真實的數據和回訪來分析。功能設計肯定是我們重點關注的，但內部的項目協作方面也不能忽視。下面就來說說具體復盤的內容。
1. 用戶使用情況分析
這步收集和分析主要是為了下面的功能分析。
1）實際使用者數量是否達到預期？
我們在做功能的時候，會先進行用戶調研，這部分用戶就是我們的潛在使用者。功能剛上線時，他們可能是最先開始使用的。在針對新功能剛上線復盤時，我們會先看這些用戶是否已經使用起來，使用情況如何。如果這部分用戶都不能用起來，那功能設計可能存在很大的問題，整個方案都可能是錯誤的。
在后面使用的一段時間內，持續的關注用戶數量。如果沒有增長，那很可能這個功能是一些特殊用戶的偽需求。如果穩定的在增長，說明這是一個合理，且有價值的功能。
2）用戶對功能的整體評價如何？
有時候新功能上線了，不怕用戶提一堆優化，就怕沒人提。一點反饋都沒有，要么就是沒人用，要么就是沒問題。但后者可能性還是很小的。
我們會先統計出用戶對功能的使用量，選擇數據量大的一些用戶進行回訪。題目設置如下：
- 實際場景中是否能用起來這個功能？
- 有哪些細節場景不滿足使用？
- 對這個功能打幾分？
回訪樣本足夠多時，我們對功能的理解和迭代規劃就會有更深層次的思考。
2. 產品功能驗證
很多時候，B端產品經理并不是用戶，沒有B端業務的親身經歷，做功能的時候常常感到很虛，就怕需求調研不充分，被部分用戶帶偏；也怕功能設計不合理，做出來以后沒人用。
通過上面的用戶使用情況調研分析，我們可以有理有據地來分析下功能層面的問題了。
1）整體方案是否合理？
這其實考驗的是需求調研和功能設計能力。在調研階段，有沒有挖掘到用戶的真實需求？在功能設計時，有沒有基于用戶的使用場景？
這時要反推這幾點：
- 調研的是否是目標用戶？
- 調研的是否是功能實際使用者？
- 調研對象是否具有代表性？
- 調研樣本量是否充足？
- 是否獲得了用戶的真實需求？
- 是否是基于用戶的實際場景給出的解決方案？
- 是否走通了功能的閉環？
- 是否全面考慮了對系統其他模塊的影響？
如果這是一個成功的功能，那么那些調研過的用戶，可以歸到我們的vip庫里，下次有類似功能需求時，可以先聽聽他們的意見。
如果很不幸，這是一個失敗的功能，那么我們需要分析下，到底是上面的哪幾點導致了失敗。是因為調研的用戶數太少？還是用戶根本就不典型？那下次在選取調研對象時需要謹慎。
或者是因為設計能力差，沒有弄清用戶真實所需，那下次做完產品設計后，一定要內部多討論，集大家的智慧。在產品原型出完后，多調研一些用戶，請他們看方案是否合理。
前置環節做的越足，開發時就越順利。功能做錯了，后面再在那上面修改，或者推倒重來，成本是非常高的。特別是產生了一些數據后，不得不考慮老數據的兼容問題。
目前來說，基本上不會遇到整體方案不正確的情況。關于如何做需求調研，之前在”人人都是產品經理“上講過直播課，大家可以去看看。
具體功能整體設計，可以看看之前寫的這2篇：《全面解析：就診預約應如何設計？》《叫號系統設計指南》
2）有哪些細節沒有考慮到？
細節多少都是會有點問題的，但不是所有問題下次都可以規避的。這里要分2部分來看。
① 特殊的正常場景沒考慮到
這就屬于那種難以規避的類型。他屬于正常的業務場景，但是屬于正常場景中的異常流程。除非很了解B端業務，否則調研的時候，這類問題很難調研到。
比如說輸液臺。正常流程就是醫生開輸液單->藥房發藥–>護士輸液。此時的特殊場景就是：醫生開了3天的藥，輸了1天，第二天換藥了，如何提醒護士不要輸錯了？
還有一種更想不到的：因為護士扎針沒扎好，患者生氣，早上不輸了，藥品都被扔了，然后下午又來輸液了，如何告訴護士，3天的輸液量，2天輸完了，還沒有結束輸液，不是系統的bug？
要想減少這種場景的考慮步驟，最好的辦法找幾個用戶看原型，先體驗功能。在功能上線后，短期內及時跟進。如果對這項業務不熟悉，心理沒底，一定要多問用戶。
② 產品設計細節考慮不周
這部分的能力是可以提升的，甚至做到基本不出現設計層面的缺陷。一方面是當前功能的設計細節。另一個最大、隱藏最深的問題就是對現有功能的影響考慮不周。
往往體現在這幾方面：
- 當前功能細節不明。比如說統計報表中，最長的時間篩選跨度是多長？文本字段中，字數限制是多少？
- 和原有功能有沖突。比如說在做叫號功能的時候，需要增加預約后就給號的模式，但這和原來的預約模式產生了沖突，無法協調，只能二選一。
- 原有功能同步不到位。比如說增加了患者在手機端填寫體重、血壓等指標數據的功能，但是這些數據沒有記錄到系統的病人指標庫里面，導致數據缺失。
遇到這類問題的時候，隨時記下來，多復盤，下次在做功能的時候，就會很敏感，哪些地方可能有坑。對其他功能影響考慮不周，還有個笨辦法就是，一頁頁去看原型，看看是否有哪一點被忽略了。
3）功能迭代計劃是否合理？
我們都懂MVP這個道理，但是做的時候，可能就把握不好度了，一不小心就做多了。產品經理很多都有完美心理，以為做的越多，功能越豐富，用戶使用就越滿足。恰恰相反，做的越多，錯的越多。在確認功能價值前，要懂得規劃。
如果功能上線后，能被正常使用，且沒有多余的，這是最理想的狀態。比如叫號雖然復雜，有登記給號模式，預約給號模式，但都能被用戶用到，且模式的占比差不多是1：1，就不適合做模式的分割迭代了。
如果功能上線后，有多余用不到的，或者急缺的。那首次的規劃就不合理。比如說優惠券功能，實際上用戶每次都只使用一張，但做到了多張疊加使用的程度，就造成了浪費。
需求優先級怎么劃分，可以看下我之前寫的這篇《B端產品的需求優先級選擇》。
3. 開發過程回顧
團隊項目的協作，難度一點都不低于產品設計，甚至是產品經理更加頭痛的事情。明明我設計的很好，是開發沒有做到位；我文檔很早就給了，但開發沒有按期交付。為什么都要我背鍋？
產品經理不只是用戶和產品的黏合劑，也是各部門的黏合劑。開發過程的回顧，不僅要看開發功能實現上的問題，還要看項目管理上的問題。
1）功能實現不了怎么辦？
開發說的最多的一句：這個做不了。
是不想做還是做不了？
剛開始的時候，開發說做不了，我們就以為真的沒辦法做。時間長了就會發現，做不了的功能很少很少。我們為了功能能順利上線，就要對癥下藥。
如果是不想做，那就整理讓他做的對策：
- 時間緊來不及?！@期不上線，慢慢做，下期或者下下期上線。
- 覺得麻煩不想做?！宜I導，要么做，要么換人做。
如果是做不了，也有做得了的對策：
- 能力有限不會做?！o他找能解決的人指導。
- 底層設計如此，確實做不了?！姨娲桨?。
2）項目中的介入節點是否合理？
項目周期截點有這幾個：需求調研–>初評–>詳評–>設計稿–>靜態頁面完成–>聯調完成–>測試驗收–>產品驗收–>上線。
正常需要產品經理介入的環節是這幾個：需求調研，初評，詳評，設計稿，產品驗收。
如果是小功能，產品最后驗收一下就行，也不會有很大的問題。但如果功能比較大、比較復雜，我們需要注意介入的時間截點。盡量把工作都提前，以防上線時發現錯誤很多，來不及改。
我們在做大功能時，就會增加靜態頁面和聯調后的驗收。先把控頁面字段對不對，功能有沒有漏，等后面產品驗收時就主要看流程通不通就行了。
產品經理最終要對產品負責，如何分散風險，保質量是需要在實踐中不斷調整的。
3）各部門的合作方式是否需要改進？
涉及到合作，最大的問題就是信息不同步，以此產生互相推鍋。
功能沒做，開發說是因為產品經理需求有變更，我不知道。產品經理說，我都當面和你說了，你怎么不認賬了呢…類似的扯皮可能每天都會發生。
我們必須把合作流程定下來，按照規定來執行。如果執行中又發現了其他問題，也要納入流程中，直到各方達成一致，不會有大問題出現。
比如說我們會要求設計出完一部分設計稿后，先同步給我們審查。需求變更的通知要在群里發送，@對應的人，并私聊發送變動內容，還會兩至三天發送變更郵件，確保大家都知道。
只要涉及到合作的部分，都建議規范化流程。這樣即使碰到人事變更，都一樣能有序進行。
四、總結
我們每天都在學習，在接收信息，也在積累經驗。但為什么有的人能快速成長，有的人老是栽在同一個坑里？
因為知識太零散，不能學以致用。
而復盤就是一個系統化思考的過程。當我們的知識體系結構化了、系統化了，我們才能舉一反三，融匯貫通，提升自己的綜合能力。
再怎么忙，都要定時去復盤，特別是新功能上線后的一段時間內。不僅要分析產品設計是否合理，還要反思開發過程中的協作問題。因為產品經理不只是寫文檔、畫原型就可以了，溝通協作也是必備技能。
本文由 @wenshyhao 原創發布于人人都是產品經理，未經許可，禁止轉載
題圖來自 Unsplash，基于 CC0 協議
該文觀點僅代表作者本人，人人都是產品經理平臺僅提供信息存儲空間服務。
我想出來一個點子，我要把它實現出來。
