產品如何復盤迭代

① 一個完整的項目復盤到底要怎麼做

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

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

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

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

② 互聯網產品復盤方法論

互聯網項目經常復盤，對產品的迭代進步，至關重要。不廢話，直接來干貨。

1.獲取信息：關鍵點法 【在需要復盤的事件中，首先確定需要復盤的關鍵點• 其次圍繞關鍵點來進行思考和推演】，以下是具體方法步驟

信息：當時現場的外部環境——「有什麼」。比如開會時有誰在場，開會的材料有什麼，天氣怎麼樣，有沒有什麼背景信息。

思維：當時現場每個人自己「是什麼」的狀態。比如自己當時是如何思考的，或者當時大家是如何思考的，或者當時的環境有沒有一些社會的潛規則或者大家的共識等等。

情緒：當時現場的人員，情緒怎麼樣。比如開會的人之間是什麼樣的相互關系，整體的氣氛怎麼樣，大家的心理狀態怎麼樣？

2>復盤問題參考清單：
1.現在情況如何? 【• 現在做到什麼程度？• 當時定的目標是多少?• 現在的結果和目標對比處於什麼狀態？• 有沒有當時沒預計到的結果出現?• 有沒有當時預計過但實際沒出現的情況？】

2.當初是怎麼決定的？ 【• 當初決定的時候，是大家達成共識的嗎？• 有沒有聽取其他人的意見？• 有沒有讓其他人暢所欲言？• 我們當時是如何確定執行目標的?• 支撐我們當初設置目標的依據有變化嗎？】

3.執行過程是怎麼樣的? 【• 是不是完全按照我們的計劃執行的?• 為什麼××部門沒有參加？• 為什麼××活動沒有做？• 我們做對了什麼？• 我們做錯了什麼？】

3>如何判斷復盤結論是否到位？
復盤結論的落腳點是否在偶發性的因素上？
復盤結論是指向人還是指向事？
復盤結論是否能支持多次why或者why not 追問？
是否是經過交叉驗證得出的結論？

4>產品決策：

在公司，產品任何一個任務和決策，都要從多方面考慮是否可以執行：公司戰略/系統協作/產品功能。
具體邏輯：公司規劃/業務規模現狀/產品迭代計劃/風險評估/用戶影響/成本考慮。

③ 產品經理要怎麼做一個復盤總結

很多公司（包括我所在的公司），要求員工要按時提交：每日工作總結、每周工作總結、月度述職報告、季度述職報告、半年度述職報告、年度述職報告。所以，我們每個人，每天都在做著復盤。有些是我們意識到，但更多的是我們無法意識到的復盤。

一、 首先，什麼是復盤

一個項目，不管是0到1或者是版本迭代，基本都會包含以下幾個核心階段（見下圖）。產品復盤就是把每個階段中的具體工作進行分解，分析每一項工作的進展是否順利，問題點在哪、以及如何更好的優化。

二、 其次，為什麼要復盤

之前的文章中，我表述了一個觀點，「產品經理天然的路線就是走向管理」。而作為走向管理的第一步，就是要會總結得失。每一個項目從開始到結束，過程中或多或少都會出現計劃之外的突發狀況。而復盤就是是絕佳的反思的機會，產品上的得與失，通過一條一條的羅列，不斷深入思考，提升自己的總結能力。

產品經理核心的能力之一，就是總結能力，將收集到的需求建議、競品優勢等進行歸納整理，結合項目自身的差異點才能形成自己的需求思路。

三、 最後，怎麼做復盤

前文已經說過，復盤就是對具體工作進行分解，分析問題點和如何改進，以下就任務分解之後的復盤點，進行闡述。

1 項目目標復盤

1.1 項目進度復盤

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

• 1.1.2 原計劃的需求點實現了多少？哪些需求點沒有按計劃實現？每一個需求點延後原因分別是什麼？

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

1.2 項目結果復盤

• 1.2.1 項目中出現了哪些意外？為什麼會出現這些意外？

• 1.2.2 用戶對新增功能點的接受程度和項目規劃中的是否一致？

2 需求階段復盤

2.1 需求定義復盤：

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

• 2.1.2 設計師、交互師、開發人員分別對需求是否明確：如果出現需求不明確的情況，將會嚴重影響項目的進度和質量。

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

2.2 需求變更復盤

• 2.2.1 需求變更次數：敏捷開發已經將需求變更的影響降到最低，但是較少的需求變更仍然是項目進展順利的前提之一。

• 2.2.2 哪些需求變更影響了項目實際進度

• 2.2.3 每次變更的原因：領導干預？前期考慮欠缺？需求無法實現？分析每一次的變更原因，可以在後期項目中進行合理的避免。

• 2.2.4 每個項目成員是否都清晰的知道每一次的變更：只有每位項目成員清楚的了解每次需求變更，並做好充分的溝通，才能保證項目的進度和質量。

• 2.2.5 項目成員是否能接收需求變更：這就要求每次需求變更，都要和相關人員做好溝通。

3 設計階段復盤

• 3.1 是否確定視覺設計的最終審核人？

• 3.2 UI設計產出是否符合統一標准？

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

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

4 開發階段復盤

4.1 工期評估復盤

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

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

4.2 開發文檔復盤

• 4.2.1 是否有提供開發文檔？

• 4.2.2 開發文檔是否符合規范

4.3 突發狀況復盤

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

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

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

4.4 Code Review復盤

• 4.4.1 是如何進行的：包括如何分工，如何復查等。

• 4.4.2 Code Review結果是什麼？

• 4.4.3 是否嚴格執行了代碼規范？對不規范的代碼如何處理？

5 測試階段復盤

5.1 測試計劃復盤

• 5.1.1 是否有完整、准確的測試用例？

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

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

5.2 測試工具復盤

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

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

5.3 測試結果復盤

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

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

6 上線階段復盤

6.1 驗收復盤

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

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

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

• 6.1.4 是否檢查了數據埋點，數據埋點是否滿足運營要求？

6.2 上線後效果復盤

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

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

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

每次的項目復盤，都是對自己的一次拷問和錘煉，迭代型產品每逢3個版本進行一次復盤，一般情況下，發版的節奏是一個月一個版本，因此可以按照3個月的節奏進行復盤。

最後，每次的復盤結果都要形成文字記錄，這將是你成長路上的重要積累！

④ 產品設計之如何做好功能迭代

功能迭代是每個產品同學日常工作的一部分。下邊就來梳理一下如何做好一次功能的迭代。

功能迭代定義：在原有功能基礎上，再不改變現有功能主邏輯的前提下，針對該功能已知的問題，進行優化和補全。

功能迭代原動力當然是需求，來源方式分類如下：

方式1： 來自用戶、客戶、業務的反饋。

方式2： 來自數據分析。需要監測用戶的每條使用路徑是否通暢，對於其中不通的地方加以進一步查找原因和分析。

具體實際中發生的場景如下：

場景1：之前產品設計時未考慮到的場景，多為異常流程。 舉個栗子：某同學在設計客戶端超時自動鎖屏功能時，用戶使用賬號、密碼來解鎖。但是未考慮通過微信掃碼登錄的用戶，不會強制設置密碼，換言之，微信掃碼登錄的用戶是可以沒有密碼的，那麼這類用戶無法通過賬號、密碼方式來解鎖了。

場景2：與該功能強耦合的功能更新了，但該功能未隨之更新。 舉個栗子：隨著產品發展，陸續支持同釘釘、AD、ADFS、OA系統等同步創建用戶功能，並且支持掃碼登錄、統一身份認證等登錄方式。之前設計的超時自動鎖屏功能，就需要跟隨用戶登錄方式支持更多的解鎖方式，而不是簡單的使用賬號、密碼來解鎖。

場景3：業務發展或用戶使用習慣帶來的更多的功能使用場景。 舉個栗子：隨著產品發展，用戶越來越多，用戶使用的支付方式也越來越多，微信、支付寶、銀聯等，那麼支付功能就要支持更多的支付方式來擴大支付功能的使用場景。

需要防止的誤區：功能上線後，如果評價不好或沒人使用，一定要優先復盤該功能的核心場景而不是急著繼續拓展功能。舉個栗子：公司新開發了一個功能可以統計用戶發出去文件閱讀時長等數據，上線後無人問津，這個時候需要退回到核心場景，用戶是否真的需要文件分發後的數據反饋？而不是急著去做評論、點贊等拓展功能。

Step 1：；分析清楚功能現狀與邏輯

找到用戶：產品對應用戶模型中的哪幾類用戶會用到這個頁面/功能？

流程：這幾類用戶使用流程是怎樣的？

邏輯：產品功能的底層邏輯（業務流程）是怎樣的？

Step 2：現在功能出現了什麼問題？

現象：哪些用戶出了什麼問題？

原因：為什麼會出問題呢？

影響面：出現問題的pinl和受影響的用戶量是怎麼樣的？

Step 3：如何解決這些問題？

關鍵點：在業務流程中，找到最關鍵因素。

多種方案：有沒有更多方案？還是只有一種方案？

難度評估：開發難度與效果的選擇。可以用四象限法來評估，難度最小，效果最好的。逐步迭代方式。

Step 4：結果如何評定？

考核指標：用什麼指標來評估產品的表現？

數據對比：前後的數據對比是如何的？

PS：做功能迭代的時候，往往是迫於一個第三方的壓力，產品內心其實並不認同，那麼通過數據對比產品可以驗證自己的想法的正確性，從而對於第三方不適宜要求進行反擊。