身為產品或專案負責人,你帶領團隊開發出一項又一項的功能、改版、實驗,做出更好的用戶體驗,達成商業目標 — 你非常重視體驗,不過同樣不可忽視的是團隊內部成員在開發過程的「體驗」。畢竟有健康的團隊,才會有健康的產品。但,要如何定義團隊的「健康」?又如何有系統的了解「開發團隊的體驗」並優化它呢?在 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)溝通等等,若認為互為關聯或有因果關係的問題也可以用線條相連結。每次的健檢結果和問題群組整理,我們會確保文件化,以方便未來的追蹤和整理。

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

後續追蹤

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

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


References:

  1. SCRUM: The Art of Doing Twice the Work in Half the Time, Jeff Sutherland , J. J. Sutherland, 2018
  2. 只有一位開發人員的專案也需要了解如何消除七種浪費
  3. Squad Health Check model – visualizing what to improve