阿里妹導讀：復盤是項目結束后必不可少的階段，好的復盤會議能夠有效地促進團隊成長。今天，阿里項目管理專家鹿迦以自身的經驗，為大家分享如何做好一個項目的復盤。這篇文章分成兩個部分，第一部分簡單闡述對這種回顧會議的理解，認識會議的真正價值；第二部分是分享個人操作的團隊回顧會議流程。
在阿里天貓新零售的天地會項目中，因為我參與的團隊是成立不到2個月的feature team，再加上團隊成員來自于多個不同的BU（有釘釘的、天貓新零售的、手淘的），團隊處在一個快速磨合成長期，在合適的節點上開展一個有效的團隊回顧會議（也可以叫做復盤會議）可以對團隊成長和進化起到一個非常明顯的加速作用。
抱著這樣的信念，我們上周組織了一個團隊回顧會議，基于團隊成員的反饋這個會議算是取得了令人滿意的結果，大家不僅加深了相互的了解、公開暴露了一些團隊中隱藏的問題，更幫助大家對這些問題做了比較深入的探討和分析，并產出了可落地的行動。
一、我理解的團隊回顧會議
回顧會議（retrospective meeting）是來自敏捷方法scrum，這個會議是Scrum檢視與調整的一個重要的環節，在這個會議上，我們鼓勵團隊對自己的開發過程進行改進，并確定什么樣的調整可以使下一迭代的效率更高、結果更令人滿意和更易于工作。
就像我們頻繁的迭代和交付是為了快速地獲得外部用戶的反饋，進而幫助我們做產品需求的調整一樣，每個迭代的回顧會議就是想更快地得到大家對團隊工作問題和改進點的反饋，幫助團隊內部的工作效能和能力的不斷提升。
但是開好回顧會議并不簡單，甚至我認為回顧會議是團隊中最難開好的一個會議，但開好了也是價值最大的一個會議。我們整理了一下，認為這個會議可能達到的五個層次：
單向宣講式的回顧會議：團隊管理者事先完成了整個回顧分析，會上只是面向團隊成員做一個回顧結論的宣講和說明。很明顯，這種層次的回顧會議不僅很有可能不能發現團隊最重要的問題，更不利的是很難讓結論取得團隊成員發自內心的認同。
各自表達式的回顧會議：團隊成員沒有真的想敞開內心參與回顧會議，往往只是迫于會上的點名而擊鼓傳花式地各自講自己的內容和觀點，對其他人的觀點沒有回應，也沒有質疑。這是明顯的團隊成員害怕沖突的表現，團隊成員之間沒有真正的融合，背后真正的問題可能是沒有建立團隊成員之間的信任。
爭論推責式的回顧會議：大家搶著發言，但是氣氛緊張，經常有不禮貌地打斷他人講話的情況出現，大家都極力避免責任被認定到自己的頭上，往往需要老板在最終的時候決策。定責式的回顧會議是我們需要極力避免的，這個不是我們回顧會議的目標，定責的行動往往會導致大家關閉溝通的門，導致真正的問題被掩蓋。
發散討論式的回顧會議：回顧中拋出的問題很多，討論的的過程中往往還會從一個問題跳躍到其他問題上，導致會議中涉及的論點不斷發散，最終往往由于問題過多，沒有時間也沒辦法形成能落地的結論。沒有結論的會議，也就沒有辦法拿到最終的會議價值。
聚焦共創式的回顧會議：明確回顧的目標是通過團隊共創的方式發現團隊持續進化的機會，鼓勵大家用坦誠、合作、成長的心態挖掘團隊改進的機會，并通過區分優先級以在最有價值的機會點上切實落地改進的行動。這個層次才是我們理想的情況，是我們追求的目標。
二、可參考的回顧會議流程
我們操作的回顧會議基本流程是參考了《Agile Retrospectives》這本書中所劃分的會議5個階段：
準備
收集數據
產生見解
確定改進項
結束會議
那我就按這幾個階段來講講怎么做。
2.1 準備
準備階段其實是非常重要的，一些初次主持回顧會議的同學往往會忽視這個階段，一上來就讓大家寫小卡片，這樣不僅效果不好，次數多了更給人枯燥重復、走形式的感覺。
準備階段我往往會選擇做下面幾件事：
設定一個安全的環境
回顧會議不僅僅希望大家能參與進來，更重要的是能敞開心扉，大家沒有顧慮地把問題暴露出來，找到改進的辦法。但事實是肯定有人擔心回顧會議會成為一個批判會議，在認為這個會議的目的是找到這個迭代中犯錯的那個人，并把他拎出來痛批一頓，看以后還有誰敢再犯。如果這樣大家肯定會有所保留，擔心說錯話，會議上就找不到真正的問題。
一般我
