回顧會議（Retrospective）是Scrum裡重要的一環，目的是讓團隊回顧並討論前兩週所發生的事，並提出改善工作流程和團隊合作的方法，達到持續成長的目標。這篇文章將介紹一個案例，引用回顧會議到設計團隊中，並帶入設計師擅長的腦力激盪，解決設計團隊所面臨的問題。
背景
筆者最近加入了新的設計團隊，此團隊近期從兩個產品設計師配合七個開發團隊擴張到五個設計師（四個產品設計師和一個服務設計師），設計師們不附屬在開發團隊裡，這樣的成長對設計團隊來說理當是好消息，有更多資源投入以往常被忽略的步驟，如產品前期的研究、發展多樣化的概念並驗證等等。但經過兩個月的磨合後，我覺得事情沒有上軌道的感覺，設計分工不均，原本的兩位設計師還是在過勞的邊緣，新加入的設計師不知道該如何介入接手事務，開發團隊認為設計團隊是瓶頸常常被死線壓得不得不自己動手做設計，priority沒人搞得清楚，私下和幾個設計師聊天後大家都覺得，我們明明多了三個人但事情並沒有變少的感覺，所以我提出了這個點子：我們來開個回顧會議吧！
會議籌備
有別於Scrum裡兩週一次的回顧會議，這個會議我希望聚焦在過去的兩個月，設定這個時間點有助於拋開歷史的包袱，避免在公司資歷較久的設計師們提出太多往事，將會議重點放在反思這五人團隊共事的這兩個月，有哪些進步、有哪些困擾，和接下來我們能如何改進。
會議主持人（Facilitator）
我邀請了團隊裡的服務設計師來帶領這個會議，主持人的角色也包含時間的掌控和必要時切斷過長的討論，此外也是因為服務設計師的職責有別與產品設計師，她比較能中立的主持產品設計師們之間的對話。
破冰遊戲
每個工作坊或任何試圖讓人敞開心胸的會議必備。根據時間的許可來決定，可長可短，重點是帶出正向的氣氛和讓團隊彼此熟絡。
回顧會議的各種可能
如上文所述回顧會議原本是根據衝刺（Sprint）的頻率定期召開，所以也發展出各種形式來帶領每次的討論，可根據團隊當時需求找到適合的方法，有效解決團隊的問題，因為這是此設計團隊第一次開回顧會議，所以我們決定用最基本的架構來進行：What went well, What needs improvements, What has to stop.
會議現場
因為COVID的關係會議是在線上進行，我和會議主持人事先把議程和時間都準備好放在協作工具裡，讓參加者也能大略了解接下來兩小時的活動。
1. 簡介（破冰活動）
因為歐洲疫情關係大家都被困在家裡很久了，所以我們在會議邀請禮請大家準備一張紀念品的照片，簡介時間大家輪流簡短分享一下自己的紀念品和相關的旅遊趣事，對於我們這樣的新團隊來說也是藉機認識彼此的好方法。
2. 會議目標
用簡單明瞭的 What, Why and How 再次闡明這個會議的目的，提出我們面臨的挑戰有哪些，還有強調「我們」要如何改變，在我過往經驗裡回顧會議很容易變成抱怨大會，然後開始指責其他人或單位（尤其是不在這會議裡的人），所以在會議開始前將一些守則和該抱持的心態傳達清楚非常重要。另外，也花五分鐘讓大家寫下每個人對這個會議的期待和會議結束後想帶走什麼，當發現期待與所安排的議程有偏差時，此時便是最好的機會討論並在必要時調整會議內容。
3. 回顧
此階段分別討論以下三個問題，通常是給5–10分鐘大家各自寫便利貼，然後5分鐘快速看過大家所寫的並將它們歸類，時間的掌控在此極為重要。
What went well: 最好是從正面的命題開始，有助於帶動正向思考，也是給予彼此讚美的機會，有些人可能會覺得這好像沒必要討論，但其實將這些具體的事項提出來有助於提醒我們繼續保持，或當定期檢視這些回顧會議時，可以看出那些該改善的事項是否進入這個欄位。
What needs improvement: 可以是團隊內的合作，對外的溝通，軟體工具的使用，各種可能需要改善的事都可以提出來，另外也可能是個人的問題、心理狀態等等可能影響工作表現的任何事，有些困擾表面上看起來不太相關，但其實常常被提出來時，會引來一陣恍然大悟和團隊的同理心。What has to stop: 真正惱人、迫切需要關切的議題。
4. 票選最需要被克服的議題
此時三個欄位裡應該有很多組議題，這時我們採用投票的方式，每個人有四票，放在你覺得最需要被解決的議題上，這個階段幾乎無需討論所以通常能快速完成。
5. 腦力激盪
在上輪投票完成後我們選出了前三名，得票數最高的是 Design QA(Quality Assurance)，在這個設計團隊和開發團對各自運行的架構下，常常發現最後上線的產品跟一開始設計的很不一樣，也就是說，設計並沒有在正式的QA process裡，在工程師開發的過程裡，設計和開發團隊也缺乏即時的溝通。
腦力激盪的起點就是把這些挑戰重寫成 “How Might We…”
“How might we create a structured process for design in the product QA process?”
這樣的命題有助於把焦點再次放到「我們」身上，提出我們可以做出的改變，在經過一番快速的腦力激盪後，我們又進行歸類與投票，選出最可行的點子。
6. 決定行動項目
此階段最重要的是產出一個「行動清單」，列出我們決定嘗試的項目，並讓每個人自願認領各個項目，有些行動是每個人都可以做的，所以不限於ㄧ對一。
7. 會議總結
由於是第一次嘗試回顧會議，我們簡短的討論了整個會議下來的心得與成效，還有下一步該如何行動：
- 因為從來沒有這樣的場合，一次把苦水吐完，大家有點資訊量過大，但很多人也發現有些挑戰是我們共有的，並非個人的問題，這除了讓大家覺得心情舒坦一些之外，也給整個團隊一起想辦法克服困難的動力。
- 我們決定一個月後再開一次回顧會議，重新檢視是否完成清單並評估成效，並視情況決定這個會議的頻率。
- 輪流主持會議，由不同組員架構會議內容並主持，分擔工作也保持新鮮感。
結語
其實說穿了回顧會議並不是什麼新點子，我們偶爾都會反省哪些事沒做好，該如何變換策略如何改進，但定期和團隊一起的回顧可以讓這些縈繞在大家心頭的各種大小事有正確的出口，讓團隊更有意識地正視這些問題，並且最重要的是「行動」，想出具體的解決方法並採取行動才能帶來真正的改變。
喜歡我的設計心法分享，請不吝以 拍手10-30下 給予支持和動力，也讓我們更了解你喜歡的方向和主題。
訂閱追蹤 Flow話不完，一起在設計領域與產業新知中，隨時隨處話不完。相關參考資料
