如何做團隊流程回顧會議：Spotify 的健康檢查模型

身為產品或專案負責人，你帶領團隊開發出一項又一項的功能、改版、實驗，做出更好的用戶體驗，達成商業目標 — **你非常重視體驗，不過同樣不可忽視的是團隊內部成員在開發過程的「體驗」。畢竟有健康的團隊，才會有健康的產品。**但，要如何定義團隊的「健康」？又如何有系統的了解「開發團隊的體驗」並優化它呢？在 Fourdesire，我們引入不同的回顧方法，從中調整合作的模式，讓團隊運作得越來越好。

《記帳城市》團隊原本在每個敏捷開發週期（2 至 4 週）結束後定期進行回顧會議（Retrospective Meeting），設計師、藝術家、工程師就合作的不同面向切入，檢視每次協作是否順利，包括以下 3 個簡單的問題：

有什麼做得好的地方？
有什麼做不好的地方？
下次想進行的調整

對於如何進行回顧會議，找出開發流程當中的改善機會，可以參考敏捷開發流程相關的資源。**如果將時間軸拉比較長遠來看，除了協作流程以外，其實有更多深層的面向需要關注，例如：對於產品的認同感、覺得自己的工作是否有趣、是否有所學習等等。**這些指標雖然主觀，卻和團隊工作的成效以及成員的幸福度息息相關，我們參考 Spotify 的團隊健康檢查模型（Squad Health Check Model），進行了深度回顧。

進行健康檢查

團隊健康檢查模型規則很簡單，定義好要使用什麼深度指標，例如：Speed（速度）、Fun（樂趣）、Delivering Value（提供價值給用戶）等等，每個人根據每項指標給出個人的燈號：紅、黃、綠。針對個別指標的綠燈狀況（理想）以及紅燈狀況（不理想），給予明確的定義。例如：Fun 的綠燈定義就是「我覺得工作充滿樂趣」，紅燈定義就是「噢 ... 好無聊」。

使用「指標卡」給予指標明確的定義

對每個人溝通各項指標以及不同燈號的意義後，就開始檢查的流程囉！針對每一項指標，我們的做法是在出牌前，先在便條貼寫出你給這個燈號的原因。大家都準備好時：「1、2、3 ，同時翻牌！」每個人的燈號就攤在陽光下了。當團隊一起跑完各項指標，就會產出像這樣的健檢報告。

如何判讀這份報告呢？舉例來說，七位成員其中有四位對於 Delivering Value 都給了黃燈，代表團隊成員認為團隊的產出並沒有提供給用戶足夠的價值。看到指標的燈號分佈，立即就能察覺組織運作不盡理想的地方。

值得一提的是，關於指標選擇，Spotify 模型提供了 10 個預設指標可以作為入門參考。團隊需要討論出最適合自己需求的指標組合。例如在《記帳城市》團隊，我們將原本只適用於工程師的指標 Health of codebase （程式碼品質），擴增為適用於所有團隊成員的品質指標。同時進一步劃分為外部和內部品質：外部品質指的是「用戶體驗到的品質」，內部品質指的是「團隊成員能察覺但用戶看不到的品質」— 工作成果是否方便維護，是否存在技術債、設計債、美術債等。另外考量團隊產品為 App，App 的更新需要通過 Apple、Google Play 的審查，在發佈流程能優化的部分有限，因此我們移除 Easy to Release（發佈流程）這項指標。

預設指標與《記帳城市》團隊採用的指標比較

整理問題

還記得前面說，我們在準備給出燈號卡牌前，有個步驟請大家在便條貼上寫出給燈號的原因嗎？我們將給黃燈或紅燈燈號所列出的「背後問題」留下，相近的問題聚集成群組，形成一落落的「問題分群」。案例當中是我們的第一次健檢所找出的問題群組，包括：缺乏好的 QA 流程、缺乏完整技術文件、應提早使用線稿（wireframe）溝通等等，若認為互為關聯或有因果關係的問題也可以用線條相連結。每次的健檢結果和問題群組整理，我們會確保文件化，以方便未來的追蹤和整理。

把相近的問題組成一落落的「問題分群」

後續追蹤

在有限的資源下，任何事情都存在優先序，團隊流程問題也不例外。從眾多的問題群組中，我們共同討論找出希望在下一季解決的問題，討論大致的處理方向。接下來指派團隊中的一位成員做為負責人，在下一個季度負責規劃並執行。指派負責人以及定時追蹤進度很重要，沒有人負責的話，這個改善項目可能會石沉大海 ...

由資料中得知，剛開始進行團隊健康檢查的團隊，頻率可以是每季一次，因為三個月的長度應該夠長去發現一些問題，也夠長用來改善之前的問題了。團隊組織一起進步和成長，從不是簡單的事，以上的模型可以作為一個很好的開始。切記千萬別將這個模型綁定任何形式的績效評量，畢竟初衷是為了讓成員們對於這個團隊的運作方式和現狀給予回饋，先覺察問題，再致力於追求更好的協作流程和團隊表現。嘿，團隊領導者或專案負責人，準備好為你的團隊做一個深度健康檢查了嗎？