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

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的一項優勢——因為你能比其他成員更快、更敏銳地察覺到整體團隊的變化(無論是好是壞!),進而做出最適合你們的調整,重新找回大家的向心力與目標。

--

--

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

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Leah

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