一個完整的專案覆盤到底要怎麼做？

覆盤，是運營必不可少的能力，小到一次買菜的經歷，大到百億千億的投資專案，都可以透過覆盤來總結規律、提升水平。

簡單說來，覆盤可以達到的效果有兩條：

① 最佳化弱項，強化強項

② 明確自己的價值，明確工作的價值

那麼，覆盤到底該怎麼做呢？或者說，做好覆盤有比較高效、實用的方法嗎？有的。

以下內容來源於我工作中的思考，同時參考了柳傳志的關於覆盤的方法論，力圖展現一個完整的、可實踐的專案覆盤流程。

一、覆盤的底層邏輯

覆盤首先是要做的是事實陳述，一個有效的AAR（After Action Review）必須建立在“鐵的事實”的基礎上，如果現實難以陳述清楚，並取得一致，將導致覆盤進展緩慢或無法深入下去。

一旦事實確定下來了，就開始診斷、分析存在差異的原因，找出導致成功或失敗的根本原因後進行規律總結。明白為什麼會成功、哪些關鍵行為起了作用、這些行為有沒有適用條件，對於提高後續行動的成功率有沒有價值。

因此，一個完整的覆盤就包括如下四個步驟：目標回顧、結果陳述、過程分析、規律總結。

目標回顧

當初行動的意圖或目的是什麼？

事件/行動想要達到的目標是什麼？

我們計劃怎麼做？

預先制訂的計劃是什麼？

事先設想要發生的事情是什麼？

2、結果陳述

實際上發生了什麼事？

在什麼情況下？是怎麼發生的？

與目標相比，哪些地方做得好？哪些未達預期？

3、過程分析

實際狀況與預期有無差異？

如果有，為什麼會發生這些差異？是哪些因素造成了我們沒有達到預期目標？

失敗的根本原因是什麼？

如果沒有失敗，成功的關鍵因素是什麼？

4、規律總結

規律總結也就是我們從過程中學到了什麼新東西？

如果有人要進行同樣的行動，我會給他什麼建議？

接下來我們該做些什麼？

哪些是我們可直接行動的？

二、專案覆盤的階段流程

一個專案，基本都會包含幾個核心階段：目標、需求、設計、開發、測試、上線，把每個階段中的具體工作進行分解，才能分析出每一項工作的進展是否順利，問題點在哪、以及如何更好的最佳化。

這裡分享一個專案覆盤的小技巧：按照專案執行的時間線記工作日記。

不一定要每天都寫，但一定要在各個重要的時間節點留下工作記錄，這樣才會對整個活動過程瞭如指掌。覆盤的時候，只需要重新去翻這部分日記，列出一個實際工作的時間表，對比策劃書中的計劃時間表，哪部分工作提前，哪部分工作延後，哪部分工作是臨時加進去，完成度怎麼樣。在效率上的成功與失敗就顯而易見了，而且還可以歸因到個人，表揚或批評。

比如第一步是專案目標回顧，優質的專案往往都伴隨著明確的預設目標，目標本身要是不合理的話，覆盤得出的結論也很難有說服力。所以在覆盤的時也有從目標設定合理性開始覆盤，當初是基於怎樣的條件設定的目標。

如果專案整體目標較大，建議進行目標分解，確定專案實施里程碑，形成子目標或階段性目標，便於目標的衡量與跟進。以電商類活動策劃為例為例，影響交易額的子目標包含：流量、轉化率、客單價、復購率。

後續步驟也是這樣，透過不斷分解對整個專案流程做出完整的、可量化的梳理。從而對專案指標的實際情況和預期對比做到了解。

三、如何做產品專案覆盤？

覆盤最重要的兩個環節：過往演繹和覆盤最佳化。明確產生偏差的原因，並提出針對性意見。

1、 專案目標覆盤

1。1 專案進度覆盤

是否按照原計劃交付時間交付？

原計劃的需求點實現了多少？哪些需求點沒有按計劃實現？

每一個需求點延後原因分別是什麼？

哪些里程碑有延遲，延遲原因是什麼？

1。2 專案結果覆盤

專案中出現了哪些意外？為什麼會出現這些意外？

使用者對新增功能點的接受程度和專案規劃中的是否一致？

2、需求階段覆盤

是否提供完整的需求輸出？包括：原型、MRD、PRD、UML等

設計師、互動師、開發人員分別對需求是否明確？如果出現需求不明確的情況，將會嚴重影響專案的進度和質量。

是否對典型使用者和使用場景有清晰的描述？

3、設計階段覆盤

是否確定視覺設計的最終稽核人？

UI設計產出是否符合統一標準？

設計工作是否影響開發工作的進度？影響原因是什麼？

產品設計工作在什麼時候，由誰來完成的？

4、開發階段覆盤

4。1 工期評估覆盤

開發實施前，是否有充分的時間做工期預估？工期評估一方面是讓專案成員能夠對專案的整體進度有所準備，也是對專案需求進行詳細梳理的過程。

工期預估與實際開發時間是否有差異，及差異原因分析。

4。2 開發文件覆盤

是否有撰寫開發文件？

開發文件是否符合規範？

4。3 突發狀況覆盤

是否出現需求無法實現的狀況？原因是什麼？

是否出現團隊成員變動情況？如何應對成員變動？後期如何避免？

是否出現功能模組與需求不符的情況？出現原因是什麼？

5、測試階段覆盤

5。1 測試計劃覆盤

是否有完整、準確的測試用例？

是否有一個測試計劃？這樣的計劃是否有效？

團隊是如何測試並跟蹤產品開發效果的？

5。2 測試工具覆盤

使用了哪些測試工具來幫助測試？是否可以持續使用？

測試的時間、人力和軟體/硬體資源是否足夠？

5。3 測試結果覆盤

哪個功能模組產生的Bug最多，為什麼？

哪些BUG出現回滾，原因是什麼？

（回滾：即程式版本回退。出現較大bug，程式從1。1回退到1。0，迭代之後全是bug，修復成本高。）

6、上線階段覆盤

6。1 驗收復盤

是否進行了正式的上線驗收？

在正式釋出的過程中是否有出現狀況？後續如何避免？

上線前是否和運營、文案進行充分的溝通？

是否檢查了資料埋點，資料埋點是否滿足運營要求？

6。2 上線後效果覆盤

在上線之後是否出現重大bug？ 為什麼測試階段沒有發現？

產品上線後的問題反饋渠道是否流程？

產品上線後收集到哪些問題反饋？都是什麼型別？如何改進？

每次的專案覆盤，都是對自己的一次拷問和錘鍊，迭代型產品每逢3個版本進行一次覆盤，

一般情況下，發版的節奏是一個月一個版本，因此可以按照3個月的節奏進行復盤。

在覆盤結束後，最短時間開復盤會議，這樣很多活動執行細節和使用者反饋都歷歷在目，做覆盤的可靠性比較高。

彼此坦誠剖析，既不推卸責任，也不妄自菲薄，而是儘可能地呈現一個完整真實的專案流程。每個參與者都有平等的發言權，都能真實地表達想法。

要有專人控制時間和記錄要點，開會最忌諱的就是不著邊際地開得又臭又長，控制每個部分的時間很重要，另外記錄要點也是一種會議成果的輸出，有利於總結經驗並開展下一步行動。