為什麼Spotify Squads是產品團隊常見的失敗案例？ - Berry

banq發表於2021-06-04

Spotify 以開發一種吸引大量關注的工程文化而聞名：一切都圍繞著建立“小隊squads”；許多產品團隊試圖效仿它，但很少有人能成功。儘管 Spotify 不再使用產品小隊，但該方法可以為其他敏捷產品團隊帶來好處。在本文結束時，您將對 Spotify Squad 框架有一個清晰的瞭解，以及哪些部分可以幫助您的產品團隊文化蓬勃發展。 
 

Spotify Squad 框架的簡史
Spotify 於 2008 年推出，為其開發方法使用了一個 Scrum 團隊框架。然而，他們的快速增長突顯了傳統的 Scrum 實踐並不總是 Spotify 最敏捷的選擇。團隊決定替換 Scrum方法和術語。
Spotify Squads 是由八人或更少人組成的跨職能、自力更生的團隊。他們對任何產品構建負有端到端的責任。這包括： 

  • 構思
  • 設計
  • 測試
  • 部署
  • 最佳化

每個小隊都有一個獨特的使命、短期目標和一些長期目標——所有這些都有助於實現更大的公司使命。
就Spotify 而言，公司的使命是：釋放人類創造力的潛力。
工程小組做出本地決策，這意味著他們擁有推進專案或啟動專案的自主權，而無需依賴高層的批准。 
Spotify 建立團隊是出於信任——依靠僱傭聰明的人來做出明智的決定，並以建立一支自主的勞動力為目標。  
 

什麼是 Spotify 小隊Squads、部落tribes和行會guilds？
Spotify 將工程文化提升到了新的高度——以及新的名稱。您需要了解一些術語才能處理整個產品團隊結構。 

  • 小隊Squads：由八名或更少的產品人員組成的任務驅動型小組。一個產品生態系統可以有任意數量的小隊，只要他們能在更大的產品使命上保持一致。 Spotify 模型小隊合作尋找解決方案。特定的小隊將擁有特定的系統或流程——他們的目標是讓彼此能夠使用這些系統或流程，以便其他小隊可以完成他們的任務。 小隊往往專注於產品交付和質量。
  • 部落Tribes：小隊的組。部落可以包括任意數量的小隊，並且通常會出於某種目的將它們組合在一起。這可以是位置、產品區域、問題的整體概覽或更多。  
  • 章Chapters：整個小隊的能力領域，在Spotify 小隊部落內。 
    例如，四個小隊中可能有一個專門從事應用程式開發的人。這四個人將組成四個小隊的一章。 
    每個guilds都有一名負責人擔任正式的直線經理。這種結構使人們能夠從一個小隊跳到另一個小隊，並在不失去他們的經理和領導者的情況下開展不同的計劃。 
  • 行會guild：一個由不同小隊和部落具有共同興趣的人組成的輕量級社群。 
    公會可以有來自同一個小隊的多個人。它們對於建立超越其角色的文化和員工敬業度至關重要。 
    人們可以隨心所欲地來來去去，公會可以圍繞 Python 或 Google Analytics 等專業開發領域展開。或者，他們可以專注於個人興趣，例如讀書俱樂部、瑜伽或權力的遊戲。 
    Spotify 強調社群勝過等級制度，並相信一個足夠強大的社群可以做出正確的決定，而無需得到高度重視一致性的領導者的批准。 
    Spotify 相信，透過小隊、部落、分會和公會建立一個自治社群，他們正在建立一個有潛力“創造更好的東西”的產品團隊。 

 

Spotify產品開發方法
自主的 Spotify 產品小組使產品釋出順利進行。產品團隊希望輕鬆且頻繁地釋出，他們鼓勵“可管理”和頻繁釋出。 

“我們的目標是比任何人都更快地犯錯。” - Spotify 的創始人
Spotify 更改了其產品的架構以實現解耦釋出。這意味著，某些小隊負責應用程式的某些功能或特定區域，而不是所有小隊都負責整個應用程式。 
小隊分為三個核心區域： 

  • 客戶端功能組 
  • 基礎設施隊
  • 客戶端應用程式小隊 

解耦釋出會產生“有限的爆炸半徑”，這意味著如果產品部署失敗，則它僅限於其直接半徑，並且不會使整個產品失敗。 
  • 首先構建原型或MVP

想想；建造了它；交付它；調整一下！
Spotify Squads 的產品開發方法基於精益創業原則。他們透過研究確定問題，定義描述來總結解決方案，並就該新產品更新或功能的目標和效果建立一個假設（或多個假設）。 
一旦上述所有內容都到位，Spotify Squads 就會構建原型來執行使用者測試。將此方法整合到您的產品開發團隊中的一個絕妙方法是使用 Chameleon 執行 fake door測試。  
  • 如何執行 Chameleon fake door測試以獲取使用者反饋

  1. 在您的產品中上傳樣機影像- 低保真原型。 
  2. 當該樣機透過點選觸發或懸停，啟動應用程式內Microsurvey。
  3. 向使用者解釋這是一個 WIP。詢問他們是否有興趣試用新功能並提供反饋。  
  4. 您還可以詢問使用者在看到樣機後他們希望、想要或期望從新功能中看到什麼。 
  5. 收集您的反饋並就產品構建做出資料驅動的決策。

接下來，Spotify（你可以）構建一個最小可行產品（MVP）。Spotify 也將其稱為最小可愛產品（MLP）——非常可愛。 
這個初始產品足以滿足我們上面提到的敘述，但遠非完美。      
 
  • 測試影響並分析資料

接下來，MVP 會發布給一小部分使用者。該小組執行 A/B 測試和其他使用者測試方法，以幫助做出最佳化調整的決策。 
 
  • 如何使用 Chameleon 分析 UX 和 UI

這是嘗試客戶反饋調查以獲取有關新產品的一些定性資料的最佳時機。如果您使用 Chameleon 分析進行應用內定量評估，您還可以輕鬆獲得大量整合，包括： 
  • Mixpanel
  • Amplitude 
  • FullStory 
  • Heap
  • Kissmetrics

然後，負責的釋出小組將繼續調整並將產品釋出給同一個使用者測試組，直到他們對自己的工作感到滿意並可以開始向 Spotify 的整個使用者群推出。 
當然，它不止於此。有一個持續的反饋迴圈和對新功能或產品的持續測試。 
噓。像Microsurveys這樣的變色龍工具可以成為收​​集連續定量 和定性資料以用於未來產品調整並突出顯示需要注意的 UI 錯誤的好方法。  
 

從 Spotify Squads 失敗中學習

以上似乎是敏捷產品開發彩虹和雛菊的集合。然而，情況並非總是如此。多年來，Spotify Squads 框架受到了相當多的批評，其中很多來自前僱員。它被批評為： 

  • 從未真正存在過
  • 解決錯誤的問題
  • 過於自主 
  • 假設人的情商能力
  • 取代產出問責制

今天，Spotify 不再使用——或渴望使用——這個看似輝煌的框架。這就引出了一個問題：為什麼？ 
  • 缺乏工程經理阻礙了與 PM 的溝通

從 Spotify Squads 框架中學到的一個重要知識是需要某種層次的層次結構——管理者的存在是有原因的。該框架讓產品所有者在沒有工程經理的情況下管理設計和工程團隊——或者至少是供不應求時。 

“當工程團隊內部出現分歧時，產品經理需要與團隊中的所有工程師協商。如果工程師無法達成共識，則產品經理需要升級為與團隊內有工程專業的人數一樣多的工程經理。”
這些角色對工作成果幾乎沒有責任；相反，他們對某人的職業發展和專業技能發展負責。 
這讓產品經理與成群結隊的工程師進行溝通，而不是與工程師的一位領導進行溝通，從而導致時間浪費、來回頻繁，或許還有一點自主權。
 

  • 跨團隊協作和自主性難以平衡

Spotify 追求高度自治和高度一致性。 
例如，業務領導提出問題，解釋問題的原因，並要求小隊尋找、構建和釋出解決方案。然而，其中許多問題需要跨小隊協作。 
這並不總是一種選擇，因為擁有急需的流程或工具的其他小隊無法及時獲得響應。
這導致小隊為自己找出解決方案的工具，儘管同行評審程式碼流程到位，但仍有大量時間浪費和未共享的知識 - 沒有他們希望的那麼敏捷。   
  • 協作需要技巧和實踐

當然，Spotify 聘請了聰明人；產品負責人、工程師、資料負責人。他們的目標是成為一傢俱有成長心態、敏捷原則和匹配人員的敏捷公司。 
然而，聰明的人不一定是熟練的人。Spotify 工程團隊框架需要某些人才並不總是具備的技能，協作就是其中之一。 

“人們缺乏有效討論流程問題的通用語言、解決問題的教育以及評估績效的經驗。它不是真的敏捷。只是不是瀑布而已。”
 

  • 聽起來很酷的名字會造成額外的障礙

最後，儘管我們這麼說很痛苦，但聽起來很酷的名字並不總能帶來很酷的解決方案。 
如果您的命名結構不是以員工為中心編寫的，那麼人們可能很難理解什麼是什麼。你正在教授一種新語言，以及一個新框架；有很多問題要問。
小隊、公會、分會、部落，聽起來更像是《權力的遊戲》的情節，而不是建立的產品文化，工作場所經濟因此而受到影響。


 

相關文章