阿里系企業總是忙碌的，有幸參與了“移動端從上線到迭代全過程”的覆盤分析，一起來看看吧，enjoy~

1. 梳理覆盤思路-避免閉門造車

切忌領了任務就去行動，行動前請做好自己的計劃！盲目的做一件事，唯熟能生巧爾。不適合應對時刻變換著的需求，更不能從“工具人階段”，成長為一個有獨立思考能力的“產品負責人”。

接到覆盤任務的第一時間，我並沒有像往常一樣拿著就開幹。“覆盤”這件事不同於其他明確的任務，按著流程做就好。背後可能是領導簡單的想讓我做這麼一件事，也可能是想通過這件事本身，考驗我對於這類事情的處理是否達到了預期，再或者想知道我是否有獨當一面的能力可以升職加薪向下一階段邁進。

所以，在和人人都是產品經理社群的校友、師長們交流之後，咱們開始了有條例有方法的去做覆盤這件事，特此感謝期間答疑解惑的社群同學和老師們。

1.1 挖掘覆盤的原因

覆盤為了什麼，給誰看，預期是什麼？

杜絕瞎琢磨，合理的詢問上級，快速落實需求的意圖，統一思路！通過和leader的直接交流，我瞭解到覆盤是一個臨時決定（可能有原因沒明說），一方面給領導看，另一方面給部門反思用。

• 覆盤專案給領導過目，彙報工作，
• 覆盤專案給部門開會，反思工作。

1.2 整理覆盤的思路

想實現什麼結果，需要準備什麼材料，大致的流程？

給領導彙報，要精煉！本來用Excel表格一個個整理的專案細節，但是考慮到彙報時間和場景優先，咱們選擇了採用PPT的形式，簡單快捷的彙報“專案概述”、“覆盤結果”和“後期規劃”這三個點，彙報時間控制在30min內。

• 覆盤專案給領導過目，彙報工作。

時間-30min內

地點-領導辦公室

場景-拿著PPT宣講

期望-領導聽了很感動，認可了部門的工作（升職加薪）

給同事開會，要接地氣！像電視劇裡那種死板的開會是不符合我們團隊氛圍的，而且成員大多是研發同學，所以採用Excel表格羅列專案清單的形式來開會，簡單直接的對接到具體細節和研發同學。主要分為四個步驟“肯定專案中的成果”、“指出專案中的不足”、“共同回顧專案歷程”和“討論出具體的的解決方案”。（開會不是拿著雞毛當令箭，大家都喜歡先給塊糖再輕輕打一下，所以先誇再指出問題同事給出解決方案，這樣工作才容易開展下去，成為合格的團隊管理人員。）

• 覆盤專案給部門開會，反思工作。

時間-不限

地點-會議室

場景-按照專案清單，詳細聊聊近期情況

期望-在分享專案過程中，總結出潛在的問題，讓今後的專案執行過程的變得更好

2. 落實關鍵流程和產出

2.1 版本管理情況

按照版本去講，研發容易會議，領導容易理解！一方面，專案週期長細節難以回憶，一年時間這是第一次做覆盤，研發同學回憶不起來具體的點很正常；另一方面，領導不關心每個版本具體有啥，列出版本號和主要功能即可。

（1）上線版本（0-1）

這一步列出來上線版本（0-1）中主要的功能項。

• 有什麼功能模組？
• 當時的預期是什麼？
• 是否達到了預期？
• ……

（2）迭代版本（1-100）

• 有什麼功能模組？
• 當時的預期是什麼？
• 是否達到了預期？
• ……

值得一提的是，做覆盤才知道，好的整理習慣是真的很重要。因為專案比較趕，好多資訊沒有及時更新到需求池、週報日報甚至SVN和GIT上也沒有備註比較細節的需求點，對這次覆盤的資料核對造成了一定影響。

可能會存在的文件：版本迭代記錄、需求池、產品需求文件、測試用例等

如果你也有敏捷開發（趕進度）的情況，遇到了部分資料對不上的處境。可以去研發同學那裡尋求幫助，比如：日報、週報，GIT、SVN，這些上面會有記錄。

2.2 專案管理情況

前面的“版本管理情況”，是幫助大家會議的。接下來這個“專案管理情況”，是和部門開會的時候，重點拿出來，大家一起看到文件，所以要做的更細。

（1）預計時間和上線時間

這裡的目的是反饋“進度情況”！上線時間總是會被拖延，討論過很多次也沒有解決實際問題，所以藉著這次機會，咱們再好好聊聊這件事，集思廣益，想想措施。（給領導彙報的時候，這個資料可以酌情改一下，領導一看全都延期了心裡會不舒服，所以提前給上級過一下，讓大家都舒服）

關於進度管理這塊，我非常贊同“新浪網高階產品經理的觀點”：

現在的敏捷開發真的是在規劃階段無法保證結果的‘質量’。

1.要把需求/功能進行拆分，確認是短平快專案還是長週期專案，明確優先順序及‘關鍵元件’；

2.拆分後的需求進行排期（設計、開發、測試各個階段），‘關鍵元件’及‘前置條件’；

3.如果是短平快的專案那就每天進行20分鐘左右的站會，如果是長週期的專案那就進行周例會；

4.實時跟進專案進展，抓住‘關鍵元件’及‘前置條件’要素；

5.做好溝通、彙報工作，措辭需要精確，清楚，不要出現‘模稜兩可’的答案。

（2）功能概述和詳細資訊

這裡的目的是幫助部門同事，回憶跟進XX需求時的過程，一步步反思總結當時“遇到的困難”、“臨時解決方案”和“更好的解決方案。”

同時，大家一起評估功能是否達到預期效果，回顧研發過程中遇到的問題、解決方案和建議，為以後處理好同類問題打下基礎。

（3）任務類別和優先順序

這一步，是總結用的。

任務類別可以看出咱們的研發精力到底主要投入在哪裡，分類有“BUG修復”、“功能新增”、“功能迭代”、“介面優化”等。（畢竟總是修復BUG是很有問題的事，要明確咱們投入在哪裡了）

優先順序是一個見仁見智的東西。俗話說，找10個女人也不能一個月生下孩子。做專案也是，排10個最高優先順序也不能一天實現。

對於優先順序排布，有太多方法和結論。但是咱們深入想一下，為什麼要排優先順序。假設訂好了一期需求，突然來了緊急需求，這時候就需要優先順序！一般就按著優先順序高的去做或者加班完成，但是真沒有必要啊。

對於緊急需求，一般產品同學能想到“置換優先順序低的需求（不緊急的需求）”或者“加班加點完成”。在和中科軟的10年資深產品經理聊過後，我認為“緊急需求”的優先順序是可以的拆分的，別因為緊急就不去分析他，咱們更要分析這個“緊急需求”，拆分他到底哪裡優先順序高，是否有替代方案。一級一級拆分下去，自然方案就出來了。可以大幅避免無意義的加班。

3. 關於覆盤方法論

3.1 戴明環（PDCA）

戴明環（PDCA）法

P（Plan）計劃：產品可靠的目標預測與訂定、可靠的計劃研擬與確定、可靠的組織與分工

D（Do） 執行：可靠的任務激勵、命令與實施

C（Check）查核：產品可靠的評定與評估、可靠的作業管制與稽核

A（Adjust）修正：尋找改良方案使下次計劃變得更加完美

出自維基百科-2018年6月19日修訂

3.2 六何法（5W1H）

六何法（5W1H、6W）

何人（Who）

何事（What）

何時（When）

何地（Where）

何解（Why）

如何（hoW）

Tip：叫啥名字都可以，5W1H和6W的區別就是對“how”的定義不同罷了，有人偏愛“How”所以叫5W1H，有人偏愛“hoW”所以叫6W。

出自維基百科-2019年9月2日修訂

3.2 你自己總結的方案

適合自己的方法才是最好的方法，不然就是邯鄲學步，得不償失。

以上，是“木深”最近做自己所在專案的覆盤分析的工作總結時，對“覆盤分析”有了一些新的總結與思考，整理後與大家分享，希望有小夥伴一起交流學