概括的四大步驟適用於以個人為主體的復盤分析，分析的對象可以是自己、產品或項目。本文主要介紹的方法論是概括的四大步驟，enjoy~
1. 復盤分析的方法論
復盤分析的核心思路，就是戴明環（PDCA）的應用，由此來分析過去某一段時間內產品和項目的工作情況以及成果總結，更重要的是獲得可驗證的規律/經驗。
概括的四大步驟適用於以個人為主體的復盤分析，分析的對象可以是自己、產品或項目。
細分的八大步驟適用於以團隊為主體的復盤分析，形式通常是會議，分析的對象可以是產品或項目。
本文主要介紹的方法論是概括的四大步驟（因為使用範圍和對象更廣，實際應用的頻率也會高，Sue過往的工作經驗中，有勇氣有意識開復盤分析會議的公司和領導不算常見，會有互撕耍鍋的情況發生）。
1.1 回顧目標
P-plan，所設定的計劃/目標是怎麼樣的？
大到項目立項，小到版本迭代，我們任何一項工作的開展，都不能忘了初衷和目的。
在工作開展的過程中，應當始終朝著所設定的目標去努力實現。但理想與現實往往都有偏差，有各種各樣的因素存在，也有各種各樣的情況會出現，最終導致不同結果的發生。
所以復盤分析的第一步，是回顧目標。走到了今天，不妨回過頭去看看當初的目標。
1.2 評估結果
D-do，做了什麼？執行的情況如何？
結果是既成的事實了。結果的好與差，多好或多差，它需要有一個參照標準來對比的。
我們第一步回顧的目標就是參照物了。
通過對比，會找到目標和實際結果的差距。類似兩個數字之間的比大小，情況可分為三種：
「大於」，結果大於目標，就是指完成的情況比設定的目標要好；「等於」，結果等於目標，就是指完成的情況剛好達到設定的目標；「小於」，結果小於目標，就是指完成的情況比設定的目標要差。除了上面的三種情況，還有兩種情況需要注意的：
一是，目標裡面的事項沒有做，那結果可視為0，這種情況也屬於結果不如目標，但需要單獨討論，是因為差距的原因是根本沒有行動，那為什麼設定了目標且始終沒有行動呢？二是，結果裡面的事項是沒在目標內的，通俗的說法就是，明明是數字比大小，你卻把結果改成了字母，那跟目標（數字）的對比，就不能是單純的大小了。這說明差距是我們做了目標計劃之外的事情，為什麼會出現這樣的情況呢？需要強調，關注的重點不是差距的大小，而是出現差距的地方，可以是試著去思考：為什麼會出現這樣的差距？
1.3 分析原因
check，檢查分清對錯好壞，找到原因和問題。
通過第二步的對比，找到了差距，那這些差距造成的原因是什麼，我們失敗了嗎？失敗的根本原因是什麼？如果沒有失敗，那我們成功的關鍵因素是什麼……這些都需要深入去思考。
對發生過的事情，尤其是特殊時間節點的舉措，一一羅列然後進行反思，分析得出的原因要包括主觀和客觀兩個方面的，都要儘量窮盡，且儘量觸達最深刻的「根因」。
1.4 總結規律
action，總結經驗、吸取教訓，得到規律，行動驗證，不斷循環。
這是復盤分析最重要的一步。上面所有的步驟都是為了得出一般性的規律，形成符合真相的認識。總結規律得出的結論是否正確，最好的方式是檢驗。
復盤得出的結論是否可靠，必須在復盤的當時做出判斷，一般來說可以通過 4 原則來評判：
（1）復盤結論的落腳點是否在偶發性的因素上？
當復盤的結論落腳在偶發性因素上，那一定是錯誤的。如果復盤沒有進入到邏輯層面，沒有經受住邏輯的驗證，則這樣的復盤結論，一定是不可信的。
（2）復盤結論是指向人還是指向事？
復盤的結論如果是指向人，則很可能說明復盤沒有真正到位。因為復盤得出的是規律性的認識，而人是具體的，各不相同。
指向事，則復盤到規律的可能性更高。當然，這裡的「事」不僅僅是指某件具體的事，而是人之外的事物。不要隨意外部歸因，比如：「如果計程車司機都開這麼慢，那我以後都會遲到」等等，這會將事件引導到陰謀論上。
復盤的結論不是指向人，而是從事物的本質去理解分析，這是驗證復盤結論是否可靠的標準之一。
（3）復盤結論的得出，是否有過3次以上連續的 why 或者 why not 的追問？
復盤得出的結論，至少應該有過三次以上的連續的 why 或者 why not 的詢問。如果次數不夠，也很可能意味著復盤沒有找到真正的原因。
探尋問題背後的問題，找出答案之後的答案，這就是追問的目的。
（4）是否是經過交叉驗證得出的結論？
「孤證不能定案」是法律上的術語，用來比喻復盤得出的結論通過其他事情交叉驗證，也可以為結論的有效性提供一定的保障。
2. 復盤分析的應用和技巧
2.1 對項目的復盤分析
項目復盤的時間：最好在項目結束後的一個星期。這個時間節點，項目剛結束不久，參與項目的人員對項目各情況的印象還比較清楚，比較容易回憶。
項目復盤的參與人員：最好參與過項目的人都能參與進來，在項目開展過程承擔關鍵角色的人員是必須要參與的，例如項目經理、產品經理、研發經理、運營經理等等。
項目復盤的提前準備：通知需參與會議的相關人員，讓各自準備相關的材料、邀請一位復盤會議的引導者。
材料包含但不僅限：
文檔：版本迭代記錄、用戶反饋記錄等；數據：過程中的數據、最終的數據等。項目復盤的階段流程：
套用上面分享的四大步驟，對項目復盤分析的工作可分成以下3個步驟：
（1）對項目做整體的回顧
這一步將四大步驟中的（1）回顧目標和（2）評估結果進行了合併，從「起點」（目標）到「終點」（結果），對項目進行整體的回顧。
為了避免一上來就「唯結果論」，相互搶功或耍鍋，開場應該相對輕鬆點，可以讓大家先來聊聊對項目的理解：
項目服務的對象是否符合項目定位的客戶/用戶？項目開展的過程中我們遇到了哪些機遇？什麼挑戰？項目取得的成果是否符合我們的期望值？好在哪？差在哪？……（2）對關鍵事件進行回顧
項目的起止，有時間線，那自然就會對應有故事線。
過程中發生的各個關鍵事件，是影響項目運營和項目結果的重要因素，我們應當一一列舉並分析。這時候讓參與會議的人員提前準備，就很有意義了。
從項目立項開始畫一條時間線，在時間線上標註出各個關鍵的節點，讓所有人對應時間點，把自己印象深刻的、對項目當時有影響的事情寫在便條上，然後貼上去。
便條需要講清楚幾點：當時發生了什麼事，是怎麼發生的，造成了什麼問題，最後是怎麼解決的。
（3）產出團隊和個人收穫
付出必然會有收穫的（這不是一句毒雞湯）。這裡想說的收穫，更多的是對人對事的收穫。
還是那句話，項目的結果是既成的事實。結果有可能是不如預期的，有可能是剛好達到設想的，也有可能超出預期的，這始終不是關注的重點。
復盤的意義在於總結，找到對項目有貢獻的人，肯定和學習ta；總結對項目有利的經驗，校驗然後放大它。
對人的部分，可以把項目關鍵角色的人頭像貼出來或名字寫出來，讓大家把跟這個人合作的經歷、感受和評價寫下來，肯定ta過往對項目的貢獻。
對經驗的部分，可以從溝通、人員、流程和實踐等方面進行收穫總結。
2.2 對產品的復盤分析
對產品的復盤，更準確的說法，應該是對版本的復盤。
產品復盤的周期：這需要具體依據產品的版本迭代速度而定。一般是3個版本迭代完就應該進行一次產品復盤。
產品復盤的參與人員：參與版本設計、研發和運營的相關人員，例如產品經理、美術、研發、測試、運營、客服、商務等。
產品復盤的提前準備：通知需參與會議的相關人員，讓各自準備相關的材料、邀請一位復盤會議的引導者。
材料包含但不僅限：
文檔：版本迭代記錄、需求管理表、需求文檔、設計圖稿、開發文檔、測試用例、用戶反饋記錄等；數據：版本迭代前一個周期的數據、版本迭代後一個周期的數據。產品復盤的階段流程：
同樣套用上面分享的四大步驟，對產品復盤分析的工作可分成以下4個步驟：
（1）回顧版本目標
依據準備好的版本迭代記錄和需求管理表，先來回顧一下復盤版本的迭代內容，這些內容都是圍繞什麼重點/目標展開的，屬於新增功能還是優化已有功能，這些功能點是服務於哪些人群的，他們的群體特徵是什麼樣的，主要是想滿足他們什麼樣的需求？表層需求是什麼？底層需求又是什麼？如何驗證版本的效果？
所以這就要求我們接到需求後，要對需求進行足夠的分析，在設計產品和規劃版本的時候，要提前想好驗證產品設計的方式，羅列出希望改善的數據/指標。它有可能是營收類指標比如訂單金額，也可能是功能使用率的漏鬥模型指標，或者用戶好感度相關的指標等等。
（2）評估版本結果
用數據說話。將版本發布前後的兩個周期進行對比，數據/指標上有哪些變化？版本面向用戶的意見反饋怎麼樣？他們喜歡和認可新版本發布的內容嗎？認為還有未被滿足的需求嗎？或者是還有期待被服務得更好的場景？
（3）分析關鍵環節
這一步，可以按產品開發生產線的各個節點劃分為關鍵環節，依次可以劃分為：需求——設計——開發——測試——上線。
A. 需求
這個環節，主要復盤的內容有以下幾項：
需求對接：需求方的需求表述是否清楚？產品經理的需求分析是否準確？需求定義：需求文檔的輸出是否完整清晰？設計師、交互師、開發、測試對需求是否了解？產品經理需求方的對接：
需求變更：需求變更的次數是否頻繁？存在需求變更影響到了版本進度？需求變更的原因是什麼？需求變更後是否有對文檔進行及時的更新？是否做好溝通工作，把需求變更的事宜清楚地傳遞給相關人員？
B. 設計
這個環節，主要復盤的內容有以下幾項：
設計確認：是否有確定視覺設計的最終審核人？設計標準：UI設計產出是否符合統一標準？工期進度：產品設計工作在什麼時候，由誰來完成的？設計工作是否影響開發工作的進度？影響原因是什麼？C. 開發
這個環節，主要復盤的內容有以下幾項：
工期進度：開發實施前，是否有充分的時間做工期預估？工期預估與實際開發時間是否有差異，及差異原因分析。開發文檔：是否有撰寫開發文檔？開發文檔是否符合規範?突發狀況：是否出現需求無法實現的狀況？原因是什麼？是否出現團隊成員變動情況？如何應對成員變動？後期如何避免？是否出現功能模塊與需求不符的情況？出現原因是什麼？
D.測試
這個環節，主要復盤的內容有以下幾項：
測試計劃：是否有完整、準確的測試用例？是否有一個測試計劃？這樣的計劃是否有效？團隊是如何測試並跟蹤產品開發效果的？測試工具：使用了哪些測試工具來幫助測試？是否可以持續使用？測試的時間、人力和軟體/硬體資源是否足夠?測試結果：哪個功能模塊產生的Bug最多，為什麼？哪些BUG出現回滾，原因是什麼？E. 上線
這個環節，主要復盤的內容有以下幾項：
版本驗收：是否進行了正式的上線驗收？在正式發布的過程中是否有出現狀況？後續如何避免？是否檢查了數據埋點，數據埋點是否滿足要求？上線通知：是否有通知到相關人員？上線前是否和運營、文案進行充分的溝通？發版效果：在上線之後是否出現重大bug? 為什麼測試階段沒有發現？產品上線後的問題反饋渠道是否流程？產品上線後收集到哪些問題反饋？都是什麼類型？如何改進？（4）總結版本經驗
順著產品開發生產線的各個關鍵節點逐一去反思總結存在的問題，得出版本迭代的經驗：有哪些錯誤我們要去改正的？哪些情況可以去避免的？有哪些避免的措施可以做？哪些好的經驗和配合我們要繼續保持的？
2.3 對個人的復盤分析
同樣套用上面分享的四大步驟，對個人復盤分析的工作可分成以下4個步驟：
（大白話的復盤思路就是：我是誰？做了什麼？做得怎麼樣？還能不能更好？）
（1）自我定位
不要用類似「我是xxx項目xx產品的產品經理」這種簡單的表述作為你的自我定位，這更準確的說法是「職位/title」，不能算「自我定位」。
試著去描述你在團隊/項目中，承擔著什麼樣的角色，這個角色存在的價值是什麼？除了在企業的角度上看你作為產品經理的價值，更重要的是在你的理解下，你的價值是什麼？你不可替代或難以替代的地方是什麼？甚至都可以是你在承擔這個角色時的人物性格、人格魅力的自我剖析。
假設Sue作為一名數據型的產品經理，除了負責數據採集、加工、分析；負責整個項目的數據平臺搭建，還有應該做到充分理解平臺項目業務，為業務增長和用戶體驗提供數據服務支持，很好地對數據進行應用與實踐，優化產品策略和提高業務收入，實現數據驅動、數據賦能的價值。
（2）個人產出
根據自我定位的職責和價值，和你實際的產出進行對比，找出差距。
你在項目發展中，做了什麼事情？這些事情對項目的推進有什麼作用？
你在版本迭代中，做了什麼事情？這些事情對產品的發展有什麼影響？
你在整個團隊中，貢獻的價值是什麼？有多大？
簡單的說就是：你做了什麼？結果怎麼樣？有哪些亮點？哪些不足？
（3）深入分析
對差距存在的原因進行反思和分析，取得成績（亮點）的原因是什麼？造成問題（不足）的原因是什麼？
這裡可提供幾個參考角度：
依據差距去追查原因：對比往期結果、對比同行分析分析原因時明辨內外：是自己的努力帶來的？外在環境造成的？釐清線索判定是否可控：可控？不可控？半可控？（4）總結成長
可以從以下幾個方面，進行思考和總結，幫助自己更好的成長。
A. 工作流程
需求方面：需求對接、需求管理、需求設計、需求評審。版本管理方面：周期確認、周期跟進、驗收確認、跟進反饋。B. 產品技能
流程梳理能力：業務流程、頁面流程、涉及多角色的跨職能流程；文檔撰寫能力：互動設計、頁面布局設計、文字表述能力。C. 工作習慣
是否養成記錄工作日誌的習慣？是否養成定期體驗產品的習慣？是否養成關注行業動向的習慣？產品經理是個綜合性要求很強的職位，除了上面簡單提到的幾個方面外，還有很多需要不斷學習的地方：類似企業經營、團隊管理、運營推廣等等。
以上，是Sue最近做自己所在項目的復盤分析以及個人的工作總結時，對「復盤分析」有了一些新的總結與思考，整理後與大家分享，希望有小夥伴一起交流學習。
項目具體的復盤分析不便分享，跟大家分享一下梳理的學習腦圖（https://kdocs.cn/l/sRcLmnp5U?f=131）
本文由 @素小白 原創發布於人人都是產品經理，未經許可，禁止轉載
題圖來自 Unsplash，基於 CC0 協議