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

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

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

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

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

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

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

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

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

• 各自表示式的回顧會議：團隊成員沒有真的想敞開內心參與回顧會議，往往只是迫於會上的點名而擊鼓傳花式地各自講自己的內容和觀點，對其他人的觀點沒有回應，也沒有質疑。這是明顯的團隊成員害怕衝突的表現，團隊成員之間沒有真正的融合，背後真正的問題可能是沒有建立團隊成員之間的信任。

• 爭論推責式的回顧會議：大家搶著發言，但是氣氛緊張，經常有不禮貌地打斷他人講話的情況出現，大家都極力避免責任被認定到自己的頭上，往往需要老闆在最終的時候決策。定責式的回顧會議是我們需要極力避免的，這個不是我們回顧會議的目標，定責的行動往往會導致大家關閉溝通的門，導致真正的問題被掩蓋。

• 發散討論式的回顧會議：回顧中丟擲的問題很多，討論的的過程中往往還會從一個問題跳躍到其他問題上，導致會議中涉及的論點不斷髮散，最終往往由於問題過多，沒有時間也沒辦法形成能落地的結論。沒有結論的會議，也就沒有辦法拿到最終的會議價值。

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

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

我們操作的回顧會議基本流程是參考了《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 結束會議

結束會議如果有必要的話我們可以簡單對本次會議的組織做個總結建議，可以幫助我們提高下次回顧會議的組織能力。

但我最喜歡的結束會議的方式是讓大家每個人通過一張紙片的形式感謝團隊裡的一個人，並附上理由。我覺得這是一個很好的激勵團隊更多合作和相互幫助的好辦法。寫好紙片之後，我會請大家當眾宣讀一下卡片內容，並親手交給自己感謝的人，紙片格式如下：

三、提供幾個需要注意的地方

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

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

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

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

你可能還喜歡

點選下方圖片即可閱讀

阿里畢玄：技術人應如何選擇職業發展路線？

首次公開！2018雙11技術數字全記錄

雙11大隊長霜波：

從手忙腳亂到胸有成竹，我們如何走過這十年？

關注「阿里技術」

把握前沿技術脈搏