我們的團隊到底怎麼了?——運用Spotify健檢模型,找出團隊的痛點

Sunny
Sunny
Oct 31 · 6 min read
Photo by Jon Tyson on Unsplash

作為產品經理,我一直認為這個角色必須能隨時掌握團隊整體的工作狀況,因為當團隊開始出現持續性的異常反應,對於PM在未來需求的規劃上會造成猶疑、無法做出正確的決定,甚至會影響到產品的品質。

這次很開心可以在HPX 產品經理讀書會分享關於我在 Softall 索夫特科技任職PM的期間,是如何從一些日常工作的蛛絲馬跡,發現團隊開始出現狀況,以及後續採取怎麼樣的行動,協助成員一起做出改變。

怎麼發現團隊開始出現狀況?

我們公司從2018成立以來,一直都是採用Scrum做專案管理,開發週期則訂立為2週。我主要負責B2B、B2C產品的規劃,跟開發夥伴們至少2週會有1次的Sprint Planning,Daily Standup則是必備的日常。

也因此,在這樣緊密的合作關係中,當我察覺到3項指標變成規律性發生的狀況,而不是個案的時候,整個團隊的默契也已漸漸喪失,我當時認真反思起:我們究竟怎麼了?

這3個指標分別為:

  • 沈默的會議
  • 持續性延遲產出
  • 不穩定品質

當Sprint Planning儼然成為折磨的過程,長達2小時的會議都沒有任何互動,變成是主持人(也就是我QQ)的獨角戲,而參與的工程師夥伴則是一臉厭世或放空,完全沒有提出任何意見;接下來就會因為雙方對需求的資訊不對等,接連產生Story Point預估不精準、Delayed Release、或者造成反覆修改同樣Feature的困擾,最後容易演變成互相指責的戲碼——

PM會這樣想工程師夥伴:「這個在會議上已經有特別強調了啊!為什麼做的時候沒注意到?」

工程師則會反過來質疑PM:「每次需求不講清楚,最後還反過來壓我們的開發時間!」

嘿!這不是我們雙方樂意見到的結果。我希望我們建立的團隊文化是能引導大家說出真正想法,當遇到困難也願意提出,尋求成員幫助,合作往眾人都同意的目標與共識一起前進。

期間我試過很多不同方式,試圖找出團隊的癥結點,包含跟HR部門討論舉辦Team Building活動、私下找工程師吃飯聊天….等等。的確這些做法為團隊帶來調劑,但這都像是短暫的安慰劑效果,並沒有真的找出我們當時遇到的困境,問題仍一直存在。

怎麼找出團隊的痛點?

某天我在一個國外的PM社團Product Management,看到也有PM同伴正為類似情形困擾,大家熱心提出不同的解決方案;其中我看到一個方法,當下立刻心想:這就是我要的!

這個方法全名為Squad Health Check Model,是Spotify內部發展出的一套模型。會讓我選擇它的理由是它擁有的幾項特點:

  1. 前置作業簡單:準備與成員數量同樣的投票卡和指標卡,以及一面夠大的白板。
  2. 過程中可以引導團隊互動:我們成員年齡層平均都在25~35之間,團隊平時無論在工作間或私下的交流都相當良好(當然是撇除到團隊發生狀況的時候:P)
  3. 可以快速看到模型成果:整套模型運作下來不會超過2小時,能馬上讓所有人都看到結果,並可以就成果進行更多後續的討論。

接下來我會簡單介紹如何運用這模型,找出團隊的痛點。

第一步驟,先找出你的團隊日常關鍵字。以我們團隊來說,我訂定了10項主要指標,包含Sprint Planning、Daily Standup、Health of Code Base….。

接著,寫出什麼對於我們而言是「綠燈(代表我們喜歡做這件事)」、什麼狀況又是我們認同的「紅燈(做這件事讓我們感到困擾、這簡直是一場災難!)」。

特別注意:在分配這些卡片到團隊成員手上後,一定要逐一說明每項卡片所代表的涵義,確保大家的認知都是一樣的。如果有人提出對於健康指標的不同想法,當場可以提出來討論,並做出相對應的調整。

投票卡&健康指標,以及它們所代表的用意。

說明規則後,就進到分組討論的時間了!在組別開始針對指標卡討論的過程,記得也要不時路過(XD),引導大家提出更多討論(為什麼你覺得這項是紅燈?但我覺得是綠燈,因為blah blah……)。這才是模型真正的有效之處:聽取每個人對於團隊的意見,並從互動的過程中找出大家認為困境的發生原因或理由。

討論時間抓差不多1小時以內結束,接著必須由一位主持人蒐集組別的意見,並在事先畫好表格的白板上做上相對應的記號(如下圖)。

2019/9月,我在團隊施行Squad Health Check Model的過程

白板左方第一行是指標,右邊三行則是紅綠燈,標註組別得出的結論燈號,最後則迅速將其視覺化成右方的圖型,方便所有人能一眼就看出每個組別對於目前團隊的看法。

在大家都看到模型產出的結果之後,讓組別針對每一項內容提出明確的結論,例如我們團隊就提出了:「我認為Sprint Planning讓我們投出紅燈的原因是,每次會議都太冗長,PM對於需求講得太仔細,一下子消化太多內容,事後不可能記得,但是我們(=工程師)又沒有地方可以再找到參考資料…」

當下不用急著提出解決方案,重要的是聆聽大家的想法。建議可以找一位小幫手,紀錄每個人/組的意見,最後再彙整。

找到問題了,然後呢?

終於進到最難的步驟——要怎麼協助團隊一起做出改變?

在熱烈的互動結束後,我自己做了3件事:

  • 同步訊息:「我們重視你的意見」。將當天討論結果,以文字及圖片紀錄,寄給所有參與的人員
  • 從小地方做出改變:「讓團隊開始看到不一樣」。從大家的意見中,找出簡單下手的地方,一步步做出調整。過程有可能會需要其他部門或是主管的支援。

例如:我要求產品團隊在開每一個Story都必須清楚以文字說明需求的目標、需要工程師協助的內容、以及可接受的驗收成果,解決工程師反應的「會議後找不到參考資料」問題;關於技術的問題,則與CTO討論,請他安排明確的時間,跟所有工程師夥伴們討論、訂立公司的Coding Standard…等等。

  • 堅持對的做法:「沒有一個決定可以滿足所有人」。有時改變是必要之惡,雖然它可能讓成員感到不適應,不過為了專案管理的效率,要很清楚跟大家說明這是不得不做的調整。

最後,這個模型(或是其他你找到的更好、更適合你們團隊的方法)它不是萬靈丹,不是施行一次就能讓我們變成100分的團隊。它是幫助你以及你的團隊,用最有效率的方式找出大家的困難點,後續做出相對應的改變。

這需要一段時間持續性地施作與反覆檢驗,才能真正建立起我們都想要的工作文化(所以我和團隊約定好2個月後我們再一起跑這個模型,看看是否真的有讓大家感受到進步)。我也認為這是屬於Coordinator角色的PM的一項優勢——因為你能比其他成員更快、更敏銳地察覺到整體團隊的變化(無論是好是壞!),進而做出最適合你們的調整,重新找回大家的向心力與目標。

Sunny

Written by

Sunny

As a Product Manager, I love exploring new possibilities in product development and enhancement. My profile: https://www.linkedin.com/in/yu-wen-huang3721/

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade