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