編輯導語：在項目完結時，我們經常需要進行項目復盤。那么一個好的項目復盤是怎樣的？作者以自己的工作項目為例，進行了一次復盤總結，供你學習參考。

最近所負責的項目順利完結，如期上線，完成初期制定的項目目標。 回顧整個項目歷程，發現問題和不足的同時，也不斷成長。因此，趁正好時間充足，回顧及記錄整個項目歷程。

首先整體回顧總結一下項目復盤會，將結合實際場景和項目需求，從會議前期準備，會議進行中，項目經驗總結三個維度進行描述。其中，項目經驗總結是關于項目過程中遇到的問題以及對應的應對方案，希望可以供大家借鑒和討論。

一、項目背景介紹

本次所負責的項目主要實現公司自建商城的中臺化改造，在項目開展之前，前端業務的承載主要依托已經搭建的各個小后臺系統，存在如下問題：

• 前端業務急速發展，快速變動，現系統無法快速響應變動需求
• 在各大類型活動中，因系統維護成本高，容易引發各類型風險
• 數據分散在各個系統，無法形成統一的標準，進而無法有效發揮數據的價值

因此，基于以上問題，在完成各核心功能的中臺化搭建后，組織立項進行系統的整體遷移，通過中臺化的方式，滿足前后端的發展需求。整體項目具備如下特點：

• 項目范圍大：應用端涉及安卓，IOS，Web，小程序；管理端涉及商品管理，營銷管理，訂單管理。
• 外部系統多：同步需對接包含財務，物調，內部支撐工具，大數據報表等外部系統。
• 影響范圍大：涉及售后，售前，客戶維護，財務，運營，運維等部門。
• 項目難度高：在同步兼容歷史功能及數據的同時，還需響應當前業務需求。
• 項目周期長：項目時間跨度接近3個月。

二、會議前期準備

復盤時間點：項目上線一周后，上線遺留問題基本解決，系統穩定運行。

參會人員：項目成員，項目團隊直接上級，適當邀請公司高層。

內容前期收集：共享文件形式，模板如下：

• 問題描述：以敘述的方式描述項目過程中，遇到的問題或收獲，可以從項目各階段里程碑劃分，例如，上線部署時，測試驗證時間比較長而且覆蓋面不夠全。
• 預期結果：基于問題或收獲，拋開實際結果，理想化的分析目標期望達到的最完美結果。
• 實際結果：實事求是，記錄基于問題描述，實際達到的結果。
• 原因分析：通過對比實際結果和預期結果的不足或超額完成點，分析導致兩者差距的原因。
• 經驗總結：從原因出發，剔除項目因素，總結可適用于后續項目的經驗規律。

討論點：關于模板是否需要添加【提出人】。

個人覺得需要根據團隊的氛圍圍綜合評估，以個人經驗來說，添加【提出人】有如下的優缺點。

• 優點：可直接定位到提出人，會議期間，在冷場的情況下，可直接cue到對應的提出者。
• 缺點：團隊成員可能擔心中傷到其他成員，或害怕會議上被cue到，導致不會按照實際情況如實填寫。

我的方案：在模板上先不添加【提出人】字段，會議期間同步添加【分析人】字段，主要考慮一般復盤會議，會盡量邀請各團隊成員的直屬或隔級上級，需要給團隊成員一個展示的機會，特別是在隔級上級的面前（作為產品/項目人員，有義務讓與我們一起奮斗的小伙伴得到成長和展示）。

小tips：如項目允許，盡量邀請各端對應的上級領導同步參加，一來可以給項目成員一次露臉的機會，二來可以有效提升項目成員的參與積極性。

三、會議進行中

整體流程：團隊成員可以一起按照問題收集表核對，分析，總結，需注意的點如下：

• 問題收集表提前發出，會議前期敦促相關成員積極填寫
• 作為主持人，需熟悉登記的問題，排查重復項
• 前期需初步熟悉問題/收獲所指向的團隊或成員，在會議冷場時，可直接引導對應的人進行回答
• 收集表中，問題描述，預期結果，實際結果要求前期必填，原因分析和經驗總結可依據實際情況填寫，會議期間重點關注原因分析和經驗總結
• 把控整體會議節奏，防止討論蔓延
• 前置安排人協助，包含協助投影，協助記錄，主持人重點關注整個會議流程及問題分析
• 把發言權交項目成員。

1. 復盤會議基本原則

• 對事不對人，基于事情討論不針對到對應的人。
• 要求團隊成員，在整體會議期間，不允許出現項目成員人員，最多能接受出現對應工作端，例如前端，移動端，后臺，產品。
• 每個端，每個人都要求發言（需結合團隊具體情況）。

小提示：雖然明確說明可以添加收獲和亮點，但一般開發成員不會添加，此時，作為產品/項目負責人，可以適當的添加上，可指向具體的團隊，也可指向具體的開發成員，作為對項目工作的肯定，提高對應成員的積極性。

2. 項目經驗總結

本文由 @老鬼 原創發布于人人都是產品經理。未經許可，禁止轉載

題圖來自 Unsplash，基于 CC0 協議