開會=浪費時間？阿里技術團隊這樣開項目覆盤會

阿里妹導讀：覆盤是項目結束後必不可少的階段，好的覆盤會議可以有效地促進團隊成長。今天，阿里項目管理專家鹿迦以自身的經驗，爲你們分享如何作好一個項目的覆盤。這篇文章分紅兩個部分，第一部分簡單闡述對這種回顧會議的理解，認識會議的真正價值；第二部分是分享我的操做的團隊回顧會議流程。

在阿里天貓新零售的天地會項目中，由於我參與的團隊是成立不到2個月的feature team，再加上團隊成員來自於多個不一樣的BU（有釘釘的、天貓新零售的、手淘的），團隊處在一個快速磨合成長期，在合適的節點上開展一個有效的團隊回顧會議（也能夠叫作覆盤會議）能夠對團隊成長和進化起到一個很是明顯的加速做用。

抱着這樣的信念，咱們上週組織了一個團隊回顧會議，基於團隊成員的反饋這個會議算是取得了使人滿意的結果，你們不只加深了相互的瞭解、公開暴露了一些團隊中隱藏的問題，更幫助你們對這些問題作了比較深刻的探討和分析，併產出了可落地的行動。

1、我理解的團隊回顧會議

回顧會議（retrospective meeting）是來自敏捷方法scrum，這個會議是Scrum檢視與調整的一個重要的環節，在這個會議上，咱們鼓勵團隊對本身的開發過程進行改進，並肯定什麼樣的調整可使下一迭代的效率更高、結果更使人滿意和更易於工做。

就像咱們頻繁的迭代和交付是爲了快速地得到外部用戶的反饋，進而幫助咱們作產品需求的調整同樣，每一個迭代的回顧會議就是想更快地獲得你們對團隊工做問題和改進點的反饋，幫助團隊內部的工做效能和能力的不斷提高。

可是開好回顧會議並不簡單，甚至我認爲回顧會議是團隊中最難開好的一個會議，但開好了也是價值最大的一個會議。咱們整理了一下，認爲這個會議可能達到的五個層次：

•  

• 單向宣講式的回顧會議：團隊管理者事先完成了整個回顧分析，會上只是面向團隊成員作一個回顧結論的宣講和說明。很明顯，這種層次的回顧會議不只頗有可能不能發現團隊最重要的問題，更不利的是很難讓結論取得團隊成員發自心裏的認同。

• 各自表達式的回顧會議：團隊成員沒有真的想敞開心裏參與回顧會議，每每只是迫於會上的點名而擊鼓傳花式地各自講本身的內容和觀點，對其餘人的觀點沒有迴應，也沒有質疑。這是明顯的團隊成員懼怕衝突的表現，團隊成員之間沒有真正的融合，背後真正的問題多是沒有創建團隊成員之間的信任。

• 爭論推責式的回顧會議：你們搶着發言，可是氣氛緊張，常常有不禮貌地打斷他人講話的狀況出現，你們都極力避免責任被認定到本身的頭上，每每須要老闆在最終的時候決策。定責式的回顧會議是咱們須要極力避免的，這個不是咱們回顧會議的目標，定責的行動每每會致使你們關閉溝通的門，致使真正的問題被掩蓋。

• 發散討論式的回顧會議：回顧中拋出的問題不少，討論的的過程當中每每還會從一個問題跳躍到其餘問題上，致使會議中涉及的論點不斷髮散，最終每每因爲問題過多，沒有時間也沒辦法造成能落地的結論。沒有結論的會議，也就沒有辦法拿到最終的會議價值。

• 聚焦共創式的回顧會議：明確回顧的目標是經過團隊共創的方式發現團隊持續進化的機會，鼓勵你們用坦誠、合做、成長的心態挖掘團隊改進的機會，並經過區分優先級以在最有價值的機會點上切實落地改進的行動。這個層次纔是咱們理想的狀況，是咱們追求的目標。

2、可參考的回顧會議流程

咱們操做的回顧會議基本流程是參考了《Agile Retrospectives》這本書中所劃分的會議5個階段：

1. 準備

2. 收集數據

3. 產生看法

4. 肯定改進項

5. 結束會議

那我就按這幾個階段來說講怎麼作。

2.1 準備

準備階段實際上是很是重要的，一些初次主持回顧會議的同窗每每會忽視這個階段，一上來就讓你們寫小卡片，這樣不只效果很差，次數多了更給人枯燥重複、走形式的感受。

準備階段我每每會選擇作下面幾件事：

• 設定一個安全的環境

回顧會議不只僅但願你們能參與進來，更重要的是能敞開心扉，你們沒有顧慮地把問題暴露出來，找到改進的辦法。但事實是確定有人擔憂回顧會議會成爲一個批判會議，在認爲這個會議的目的是找到這個迭代中犯錯的那我的，並把他拎出來痛批一頓，看之後還有誰敢再犯。若是這樣你們確定會有所保留，擔憂說錯話，會議上就找不到真正的問題。

通常咱們會直接聲明這個會議的目的，絕對沒有想追究任何人的責任的意思。不只如此，咱們還須要在會議過程當中避免討論任何我的責任的問題。

• 瞭解與會人的心態

這是個頗有意思的事情。會議原本就使人沮喪，更何狀是回顧會議這種看似是錦上添花的會議。與會者都是帶着什麼心態來參加的呢？這裏有一種很是有意思的收集與會者心態的小活動，叫作「ESVP」：

•  

• Explorer （探索者）

• Shopper （推銷者）

• Vacationer （度假者）

• Prisoner （囚犯）

這四個角色表明了四種與會的心態，能夠經過與會者不記名的投票（匿名的在貼紙上寫上表明本身真實心態的角色首字母），統計完現場公開結果，就能知道會議室裏你們的實際心態狀況。統計的結果不必定總讓人歡欣鼓舞，但這個小小的活動每每能有效的喚起你們心裏的思考，幫忙肯定會議的基調，頗有價值。

• 激活你們的發言慾望

事實證實，一個會議上，若是一開始你們就能夠不須要發言，只是聽，那麼很大機會你們在整個會議上都將保持沉默，沒有什麼想說的，儘管會議中後期你但願更多人蔘與發言。辦法是一開始就破冰。簡單經常使用的方法是讓你們按座位順序輪流用一個詞形容他/她對這個迭代的感覺。只讓用一個詞說實話很是難，不過不要緊，這個時候你們就會開始腦子飛快的轉起來了，到底哪一個詞比較合適。這樣不只把你們帶到了回顧的思路里，更重要的是你們一開始就有機會開口表達本身的想法了。

• 把你們帶到這個迭代歷史的回憶中來

在開始收集數據以前，讓你們先回憶這個迭代到底發生了什麼，這個相當重要，否則暴露的問題極可能變整天馬星空的抱怨。上面用一個詞描述這個迭代的感覺是一個很好的方法，但除此以外還有心情曲線法也是頗有意思的方式。方法很簡單，就是讓你們畫一條基於時間軸（標註團隊的關鍵時刻或里程碑）的心情曲線。如圖是一個團隊真實的曲線結果，每一個人都不同，分享這個曲線的過程甚至能增強團隊成員的相互瞭解，增強信任感。

2.2 收集數據

收集數據通常包含收集作得好的部分，作得很差的部分，有時還會創新想法部分。這個環節是回顧會議最具表明性的，發貼紙，而後你們各自寫，一個問題一張貼紙……以下圖就是一個真實的例子：

上面這個方式用得很是普遍，就很少講了。除此以外還有一些變形的方式：

• 經過視覺化的、隱喻性的方法作引導，好比帆船回顧法。

• 模擬論壇接力留言的方式，一個問題一張A4紙，你們按順序傳遞加上本身的簡介，經過書寫來收集數據。

•  

2.3 產生看法

收集到了數據只是第一步，若是順利，到此爲止咱們就能收集到大量的、反應真實狀況的好的和須要改進的點。接下來咱們須要整理了。

先分類，由於你們是各自獨立寫的，因此確定會有重複的，因此把同類的放到一塊兒咱們才能讓滿牆的紙片不那麼凌亂。分類須要花一點時間，但這個過程也是恰好讓你們都瞭解其餘人寫了什麼的好機會，因此我每每會邀請組員上來和我一塊兒來作分類，一我的作卡片宣讀，容許你們討論，一我的把相贊成思的卡片貼到一塊兒。

對作得好的部分，咱們須要提出來鼓勵你們，但願咱們能堅持下來，甚至作得更好。這個部分在實際操做中每每比較忽視，你們更願意快點調到待改進部分。不管如何，若是發現團隊士氣低落，須要鼓勵的話，這時就是很好的機會，每一個作得好的地方你都能有感而發。

對待改進的部分，這個是本次會議的核心內容，不過很不幸，每每團隊總結出來的待改進方面會比較多（>5個就算多吧），可會議時間有限，對這個部分，咱們首先要作的就是肯定優先級最高的核心問題（不超過3個）。肯定的辦法最經常使用的就是投票，好比每人兩票。

2.4 肯定改進項

當咱們肯定了待改進的重點以後，咱們就須要討論得出針對這些問題的改進方案。

不過別急，不要這麼快就跳到了改進方案上來，針對問題咱們要先分析問題的根源，找到問題最根本的緣由，咱們再針對緣由採起改進行動，這樣才能對問題作到根本的解決。

• 魚骨圖或5W的方法尋找問題根源

最多見的方法有魚骨圖法，以下圖，使用方法就不解釋了，你們本身google。

還有一個理論就是5個WHY，也是一個很好用的方法。

• 分組討論

討論尋找問題根源的的過程每每很是費時，這裏經常使用的一個方式是把組員分組，每一個小組專門討論一個問題，咱們能夠限時讓他們討論出問題的根源和推薦出改進計劃，這樣咱們一個能節省時間，更有價值的是能夠調動每個成員的積極參與度。

• SMART的改進計劃

一個老調重彈的就是全部的改進計劃都必須是SMART的，SMART原則也不介紹了。這點說得容易，但作起來每每困難很大，你們很是容易產出一些相似建議同樣的東西，徹底沒辦法執行。這裏給你們一個小竅門，在每產出一個action的時候就問一下你們「這個action能夠執行嗎？能判斷是否完成嗎？」，這樣每每就能幫忙準確判斷是否SMART。

• 避免產出過多改進計劃

固然還有一個陷阱就是改進計劃過多，到時候團隊根本沒有時間完成這麼多的改進計劃，這個也須要排優先級；還有超出團隊能力範圍的改進要避免，否則也無法落實。

2.5 結束會議

結束會議若是有必要的話咱們能夠簡單對本次會議的組織作個總結建議，能夠幫助咱們提升下次回顧會議的組織能力。

但我最喜歡的結束會議的方式是讓你們每一個人經過一張紙片的形式感謝團隊裏的一我的，並附上理由。我以爲這是一個很好的激勵團隊更多合做和相互幫助的好辦法。寫好紙片以後，我會請你們當衆宣讀一下卡片內容，並親手交給本身感謝的人，紙片格式以下：

3、提供幾個須要注意的地

1. 通常狀況不建議團隊的經理參加回顧會議。這有悖於準備環節中提到的設立一個安全的環境，你們會擔憂在會議上暴露團隊問題會對他們績效產生很差的影響。但也有一種狀況咱們須要經理在場，那就是團隊已經積累了不少很是嚴重的問題，可是經理可能都不大瞭解狀況，你們都期盼的經理在場能聽到並推進解決這些問題。

2. 會議產生的改進計劃怎麼有效地跟蹤？通常咱們建議把這些action之間放到團隊下個迭代的工做列表中，和普通開發工做同樣對待跟蹤，只有這樣纔能有效地使得改進落地。

3. 先後回顧會議產出相同或相似的改進計劃。這說明老問題一直沒有解決，有的時候會發現每次改進計劃都完成了，可是老問題仍然還在。通常若是想改進能力或是外部依賴的問題每每會致使這樣的狀況，這些不像團隊本身的流程那樣能立竿見影，面對這樣的問題，團隊最好能計劃一些長期的（週期跨迭代的）改進計劃，下次回顧會議能夠監控進展，而不是提重複的問題。

4. 若是須要，別忘了在回顧會議前面簡單過一下上次回顧會議產出的改進計劃完成狀況。

原文連接