一、 什么是復盤？

1、來源

復盤最開始來源于圍棋術語，本意是對弈者下完一盤棋之后，重新將對弈過程擺一遍，看看哪些地方下的好，哪些地方下的不好，甚至有更好的下法。

在美國，最早采用復盤的是美國軍隊，它們將其稱為“行動后反思”（after action review，AAR）。

美軍對AAR的定義是：“對一個事件的專業討論，以績效表現為核心，重點放在幫助參與者自己發現發生了什么，為什么發生，如何保持優勢，以及改正缺點。”

2、定義

復盤，就是一件事情做完了以后，做成功了，或者沒做成功，尤其是沒做成功的，坐下來把當時的這個事情，我們預先怎么定的目標、中間出了什么問題、為什么做不到，把這個過程要理一遍，理一遍之后，下次再做的時候，自然這次的經驗教訓就吸收了。

3、項目復盤

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

產品項目階段復盤

二、 為什么要做復盤？

1、為職業生涯和個人成長鋪路

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

當然，即使不走向管理崗，復盤的意義亦難以替代。比如說，現在市場上要求越來越專業化的產品經理類型，數據產品經理、策略產品經理、商業化產品經理等，良好的項目復盤習慣，依舊是積累總結項目得失，優化下一步產品策略的最佳方式。

另外，產品經理核心的能力之一，就是總結能力，將收集到的需求建議、競品優勢等進行歸納整理，結合項目自身的差異點才能形成自己的需求思路。復盤能夠幫助你快速反思自己的不足，及時糾正。

2、從0到1建立制度或制度迭代

將問題找出其成功或失敗的關鍵點，知其然，而知其所以然，要有意義的失敗，避免無意義的成功。同時將處理辦法整理成一套可供執行的程序，以便下次遇到相同問題時采用，當然，視情況而定，不可拘泥死板。

科學制度的制定/迭代過程

3、結合PDCA模式，總結經驗，提升項目管理能力

解決問題的制度形成過程

三、 復盤的方法與底層邏輯

通過聯想集團的復盤機制，來學習一下復盤的四個步驟和注意事項。

聯想復盤機制

1、回顧目標

復盤始于對預期目標的回顧。在這一步，主要回答的問題如下所示。

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

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

·我們計劃怎么做？預先制訂的計劃是什么？

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

此階段存在的主要問題及對策建議

在本階段，主要存在的問題包括以下幾個。

①沒有目標

按照復盤的學習機理，如果沒有預期的目標和計劃，就談不上復盤。因為沒有目標，就無所謂做得好與壞，也就沒有差異，沒有從中學習的意義。因此，事先制訂清晰、明確的預期目標與計劃，對于復盤是至關重要的。

如果在進行復盤之前了解到項目/事件沒有目標，我建議應盡快“亡羊補牢”，通過訪談項目負責人或組織項目團隊研討，補充、確認項目/事件目標，并在復盤會議開始階段聲明這一點，提醒大家特別留意。事實上，這本身也應成為一個重要的學習點，是下次改進的重要教訓之一。

②目標不清

在現實世界中，許多人的目標定得比較籠統、模糊，這樣不利于充分從復盤中學習。為此，我們建議在行動前要將目標盡可能明確、細化。同時針對目標制定關鍵里程碑和關鍵結果

在企業管理領域，對于目標的制定，通常認為要符合SMART原則，即滿足如下五方面的要求。

·明確具體（specific）。

·可衡量（measurable）。

·有挑戰但可實現（achievable）。

·相關、可控（related）。

·有時限（time-limited）。

③目標缺乏共識

我建議，應將目標展現出來，即將目標很清晰明確地在某一個地方寫出來，讓每一個參加行動的人都能夠看到。同時，事先要經過團隊的討論，確保團隊成員對任務的目的和成功的標準理解一致，否則就失去了一起評價業績和甄別計劃與結果之間差異的基礎。

④缺乏對實現目標的策略、方法、措施的規劃

雖然一些團隊在行動前擬定了目標，但是往往沒有認真地規劃如何實現這些目標，也就是說，缺乏對實現目標的策略、方法以及行動措施的規劃。在這種情況下，匆匆地開始行動，即使團隊成員對目標的理解一致，也可能因為團隊中每個人對如何實現目標有自己的理解，從而導致行動過程中出現分歧，難以產生合力。

當然，通過復盤，可以讓團隊成員明白：在行動前，需要擬定清晰的目標、達成共識，并就如何實現目標群策群力。這樣有助于提高團隊效能。

2、評估結果

明確了目標之后，就要回顧實際發生了什么

在這一步中，要回答的主要問題如下。

·實際上發生了什么事？

·在什么情況下？是怎么發生的？

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

有效的AAR必須建立在“鐵的事實”的基礎上。如果現實難以陳述清楚，并取得一致，將導致復盤進展緩慢或無法深入下去。

3、分析原因

一旦事實確定下來了，就可以開始診斷、分析存在差異的原因。這一階段的目標是找出導致成功或失敗的根本原因。這一步要回答的問題包括以下幾個。

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

·如果有，為什么會發生這些差異？是哪些因素造成了我們沒有達到預期目標？失敗的根本原因是什么？

·如果沒有，成功的關鍵因素是什么？

在實際操作中，許多人從這個階段開始回顧，他們想當然地認為忽略前兩個步驟沒有什么問題。但是，在預期目標（步驟一）和實際結果（步驟二）兩個方面取得一致，對于提高溝通效率、避免陷入無休止的爭吵非常必要。

（1）把握關鍵，深入分析

對于一些復雜的項目/事件，不必對所有差異一一分析，而是應該把握關鍵，針對一些關鍵事件/議題進行深入分析，找到根本原因

要回答這些問題，需要參與AAR的人員具備解決問題的技能，以及開放、坦誠、愿意承擔責任的心態。團隊必須針對幾個可能的解釋進行“頭腦風暴”思考，從有限或彼此矛盾的信息中搜尋線索，發掘答案。為此，他們必須做到絕對誠實，敢于面對自己的缺陷，勇于承認錯誤，而不是推脫責任，在錯誤或缺點面前裝聾作啞

事實上，決定下次做什么常常是和診斷、分析不可分割的。只有真正理解了問題是什么、根本原因在哪里，參與者才能想到并提出行之有效的解決方案。

在這方面，可以使用的工具與方法包括：頭腦風暴法、五個為什么、魚骨圖、因果回路圖等。而對于許多動態復雜性問題，系統思考的技能尤為重要。

（2）對成功的剖析與對不足的分析同樣重要

復盤的核心價值包括兩個方面：鞏固成功與改正錯誤

明白為什么會成功、哪些關鍵行為起了作用、這些行為有沒有適用條件（也就是說，在何種條件下采取這些行為才是可行的），對于提高后續行動的成功率才是有價值的。

復盤時堅持下列精神：成功了，多想想客觀因素；失敗了，多找找主觀原因。只有保持謙虛的態度，實事求是，客觀地分析和評價，不夸大或高估自己，找到真正的原因，才能有效地從行動中學習，否則就是自己騙自己。

（3）“what…if…”分析

在分析原因階段，可以做一些“what…if…”分析。也就是說，可以敞開心扉，設想一下如果出現了另外一些狀況，或者當時換了另外一種做法（if…），做法（if…），會是一幅什么景象（what…）。這類似于在頭腦中對各種可能性做一些“推演”。但這種推演不應天馬行空，成為“馬后炮”或“后悔藥”，還是應該建立在關鍵原因分析的基礎之上。

4.總結經驗

復盤的核心目的在于從行動中學到經驗教訓，并將其付諸后續的改進。因此，確定導致行動成敗的關鍵原因，找出解決方案，也是復盤整個過程中最重要的步驟。這我們從過程中學到了什么新東西？

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

·接下來我們該做些什么？哪些是我們可直接行動的？哪些是其他層級才能處理的？是否要向上呈報？

四、如何做產品項目復盤？

復盤就是對具體工作進行分解，分析問題點和如何改進，以下就任務分解之后的復盤點，進行闡述。

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等

UML分類：https://www.cnblogs.com/vathe/p/7349816.html

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出現回滾，原因是什么？

回滾：

即程序版本回退。出現較大bug，程序從1.1回退到1.0，迭代之后全是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個月的節奏進行復盤。最后，每次的復盤結果都要形成文字記錄。

五、項目復盤案例---xxx服務號

項目名稱：xxx服務號

項目復盤周期：2019.1.3--2019.2.3

項目目標：2018.1.18，微信服務號上線

項目現狀：項目延期，換小程序來實現，分版本開發， 第一版本開發進度70%

項目歷程：

項目歷程

以下，我將按照上述產品項目復盤的方法，對此項目進行復盤，主要針對【項目目標階段】【項目需求階段】【開發階段】三個階段進行復盤。

1、項目目標復盤

1.1 項目進度復盤

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

否

目標：

2019.1.18 服務號全部功能上線

現狀：

項目延期，換小程序來實現，分版本開發， 第一版本開發進度70%

原因：

1）前期需求確認與需求分析時間較長

此項目目的是將現有線下流程通過小程序幫助用戶便捷化操作，提升線下效率，但線下流程并沒有明確的規范，產品需求確認花時間較長。

個人流程圖繪制技能較弱，沒有繪制完整且可辨識度高的的全流程流程圖

原型繪制上，沒有明確邏輯與異常標注，交互提示不明確，排列排版不美觀

需求尚不明確，無法對需求任務進行合理的時間預估和時間安排，沒有統籌需求、設計、開發與測試的時間

產品設計布局不合理，無法直接美觀告訴用戶所需求的內容

2）需求目標不明確，上線目標時間制定不合理

沒有按照SMART原則進行明確目標，沒有合理評估整個項目的時間

沒有合理規劃實現目標的策略和方法

陷入無休止的修改流程圖和原型的惡戰中

沒有指定明確的版本迭代計劃和合理的需求流程

2、需求階段復盤

2.1 需求定義復盤：

是否提供完整的需求輸出

是，? 輸出：流程圖+原型+交互+頁面文本標注

2.2 需求變更復盤

*? 2.2.1 需求變更次數：4

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

首頁頁面布局、重新設計

新增訂單詳情頁、訂單列表頁

主業務頁面重新設計

服務號變更為小程序實現

*? 2.2.3 每次變更的原因：

前期考慮欠缺：

一方面，個人對市面上布局研究較少，所以能夠選擇的布局較少；

另一方面，沒有針對本產品的情況和用戶，做針對性的細節考慮，盲目采用競品的布局設計，只想著快速完成設計，進行需求評審；

領導變更實現平臺：服務號變更為小程序

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

因變更較頻繁，同時每次變更部分細節較多，僅和開發進行過溝通，與測試、設計人員溝通不及時。

3、開發階段復盤

3.1 工期評估復盤

*? 3.1.1 開發實施前，是否有充分的時間做工期預估

需求評審階段，開發有進行工期的預估，但因前端頁面需求一直在更改，前端開發工期一直未定，后臺邏輯方面影響較小，基本可確定

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

有差異，實際開發過程中，后臺方面不僅進行小程序的邏輯梳理，還需要與ERP后臺聯合開發很多接口，開發時間加長。

3.2 開發文檔復盤

*? 3.2.1 是否有撰寫開發文檔？

開發有梳理技術流程圖

3.3 突發狀況復盤

*? 3.3.1 是否出現需求無法實現的狀況？原因是什么？

需求無法實現：

主業務服務中，初始設計為：用戶可以根據A和B顯示Z，幫助用戶做選擇，減少用戶輸入。

原因:

選擇A需采用第三方應用，存在不穩定因素，同時采用A選擇B，可能因第三方應用用戶無法查詢到，導致出現錯誤，所以最終決定采用用戶主動輸入,放棄讓用戶主動選擇。

六、后續行動計劃與改進措施

（一）需求管理與需求計劃

1、產品需求靈魂五問

是否應該制定版本迭代計劃？

什么時間制定？（需求評審前，中，后）

如何制定？？？

每次的需求梳理是否有需求的版本迭代【即每次需求的范圍如何界定，是一次性上全部功能，還是梳理最小可使用版本？有什么指標來確定？】

版本計劃制定最終拍板人是誰？

版本計劃影響到每次需求評審的目標【以當前版本實現為目標還是以全部功能需求為目標】，以及當前版本的實現目標與測試用例的編寫，UI設計的布局，技術架構的實現等等。

2、統籌整個項目各個環節的時間

首先最重要的是評估個人出需求的時間，結合項目上線時間和上線目標，安排個人需求時間、設計、開發和測試的時間，明確可實現性，合理安排項目時間周期

（二）需求確認

1、需求及時確認，有無明確的實現目標或實現效果，半天內，整理需求不明確的地方及時與相關人員進行聯系確認，并記錄有道云，針對每個項目建立需求確認記錄，逐個擊破。

2、嚴格控制拿到需求到輸出需求過程中各個部分的時間，【以下時間視實際情況變更】

接到需求---熟悉需求內容并需求確認【0.5天】----查看競品并分析總結【0.5天】----繪制業務流程圖【0.5天】-----梳理頁面流程【0.5天】------手繪原型+axure原型【1-2天】-----產品內部評審并修改+二次產品評審并修改【1-2天】-----公開評審并修改【0.5-1天】-----交付設計

ps：需求過程中及時與產品內部和產品需求提出方不斷做需求確認，無論是頁面設計還是流程設計，以免需求評審時才提出，造成返工，浪費團隊時間，這就要求多一些深思熟慮！！！

3、因公司內部產品多與目前現行的線下場景相結合，所以多了解實際的應用場景，市場上存在的某些功能或新穎需求不一定適合本產品使用，一定以公司實際情況為基礎。

4、明確平臺的服務用戶是哪些？在需求確認的時候要明確，自己也要想清楚，不然要返工啊！！！

（三）需求評審

1、個人對需求評審有方向性和目標性，這次改版所要解決的問題以及所要達成的目標都應銘記于心，避免因發散思維，最終偏離會議方向。

2、把控需求評審時間，對某個需求點相持不下，以會議目標為主，避免導致場面混亂，長時間僵持下去，可以會后解決。

3、對技術方案探討不定，會中把大概的技術方案定下來，具體技術實現細節，會后討論；認真傾聽各位建議，再提出解決方案。對會議上提出的每一個問題都應該記錄下來并作出解答，要冷靜客觀的把自己的觀點給陳述出來。

4、每次評審之前，自己走一遍業務流程，并對應頁面，查看是否有邏輯遺漏的地方，同時查看頁面是否有不明確或遺漏的標注，以及是否添加交互跳轉說明。

輸出：業務流程圖和原型圖【html壓縮包為宜。可附帶png圖片格式】

5、針對需求評審提出的新需求，判斷是否與當期目標實現有重要關聯，有則新增，明確一下需求，無則加在下期需求整理中，制定需求計劃！！！沒有評審目標，需求評審無休止！

6、需求評審的時候，著重講需求的背景，需求的主要流程，把需求的主要思路理清楚。避免過早進入細節，以及過度糾結細節~

7、需求評審各人員

開發：前端著重實現層面，每個部分是什么元素； 后臺關注邏輯與數據的相關性

測試：關注流程和細節

UI:著重頁面布局、交互設計

8、需求評審前小范圍的溝通（確認方案）

提前與項目相關人員做好溝通，針對技術方案可實現性提前了解，不能實現的提前準備備用方案。

不要什么都等到需求評審會議上才去確認/解決，提前做好溝通工作，能大大提高需求評審的效率。但不是說提前把所有的需求都溝通一遍啦！大家都很忙，動好腦子帶好方案再去溝通！

9、產品內部需求評審

為了保證邏輯的一致性，最好先進行產品團隊內部的小范圍評審。

一次內部的小范圍評審可以規避大部分需求不合理的地方，可以直接有效的提升需求評審的效率，同時也能增加其他團隊對產品團隊的信任感。.如果功能邏輯涉及到多個產品負責人，這一步還是很有必要的！

10、評審完畢，進行開發周期與設計周期的確認

合理評估項目時間，是否與上線時間沖突，及時溝通，看是否需求調整需求計劃

11、會后及時輸出會議紀要，羅列出會議中有爭議仍待解決的問題、改動的部分和結論，將完善后最終更新過的需求文檔發送給參會人員，通知需求評審已完成。之后對問題進行跟蹤，保證評審結果的落實。

12、細節分歧解決辦法~建立原則：

建立一個團隊大部分人員都認可的較全面的方向和目標，當面對分歧和難以說服對方的情景的時候，依據建立的目標或者方向，可以解決的問題或者提出當前最優的解決方案。

例如騰訊內部的原則就是一切以用戶體驗。

（四）產品技能

1、重視業務流程圖與頁面流程圖，這是梳理整個需求業務邏輯與頁面實現過程的重要步驟，如果確認了這兩個部分，后續原型繪制會順利更多。

2、針對多角色，直接用visio繪制跨職能流程圖，放棄axure，processon等流程圖繪制軟件，把時間放在梳理實際需求流程上，而不是花費在工具選擇和準備階段！浪費時間！

3、流程圖要直觀，個人去學習一下流程圖的繪制意義是什么~不要添加過多和業務沒關系的元素，每個流程圖講明白一件事，就可以，復雜的流程，可以分開描述，學習一下怎么簡化流程圖！

4、頁面布局設計的時候，多換位思考，模擬用戶使用的過程，看是否流暢，是否有衍生需求，是否當前版本滿足。

5、明確各個平臺的特點：小程序、微信服務號、app、網站、h5鏈接，多與技術溝通，同時個人多學習，掌握要做的功能能否實現，以及如何實現，避免作出不切實際的功能；

另外，如果轉換平臺實現，有哪些優缺點，技術實現上，前后端有什么差別，針對不同部分是否可以換平臺來實現，不能實現是否有替代措施。技術評估需要多長時間

6、競品分析時，一定時間內多查看各種類型的APP,包括但不限于UI、設計頁面布局，頁面元件組成與作用，頁面交互跳轉。【個人每周周末至少出一篇針對某應用的全面分析總結【新熱門產品優先】-簡書】【嚴格控制時間~用時0.5天】

（五）工作習慣

1、項目周期內與測試溝通較少，同時沒有針對性的給到測試相應的文檔說明，以致自己都不清楚如何驗收，測試到什么程度可以上線！！所以個人花時間學習一下應該怎么交付測試，有哪些需求，什么時間交付測試，同時明確測試對上線的重要性。

2、針對每個項目，建立對應的文字記錄，便于后期復盤。

項目有道云文件夾【需求文字邏輯梳理----需求確認記錄----最終版需求----需求評審記錄----需求變更記錄----待解決的問題、疑問----需求迭代計劃安排~等等待補充】

流程圖文件夾、原型圖文件夾、設計圖文件夾

3、每日日報，明確一下具體工作內容，將進度寫進去，把控個人工作進度，便于后期復盤

4、需求評審記錄筆記，當日更新到有道云筆記中，并逐個解決

5、多站在客觀角度看待別人給予建議的可行性，先感謝建議，個人再去辨識，嘗試從產品的角度去說服，不要執拗啊，少年！

6、為確保需求更改等項目相關消息及時通知所有人，建立項目所有相關人的群，即時溝通解決問題

七、總結

本文主要闡述了復盤的來源，復盤的意義，復盤的方法與底層邏輯，并針對性的描述產品項目復盤方法論，結合個人項目實戰案例進行講述，希望能夠幫助到有需要的人。其中部分內容來源于本人所閱讀文章和書籍，希望加上個人的理解，能夠讓更多人意識到復盤的重要性。

人生是一場每天都在現場直播的旅途，在忙碌工作和生活的間隙，不妨花點時間停留一下，復盤一下自己一段時間內的工作與生活，是否朝著你最開始定的目標在前進，找出其成功或失敗的關鍵點，知其然，而知其所以然，要有意義的失敗，避免無意義的成功，更高效率的去投入到下一場旅程中，離你的目標，近一點，更近一點。

給文章點個贊吧，從今天開始，做個深度思考，定期復盤的人。

善弈者，通盤無妙手，持續的復盤與經驗復利，萬事可謀矣！