什麼是Spotify模型的團隊拓撲？

有效的軟體團隊對於任何組織持續不斷地創造價值至關重要。但是，如何根據您的特定目標，文化和需求建立最佳的團隊組織呢？

2012年，音樂流媒體服務Spotify的人們發表了一篇著名的文章，描述了他們如何組織團隊使用半自治小隊模型，該模型有助於強調快速的變更流程，因為每個小隊都有工程師，測試人員，業務分析師，運維人員等各種技能人才，使得一個小隊擁有Spotify產品的一部分，並從概念中汲取靈感通過編碼到生產。

一組團隊被組織成一個叫做部落的部門。每個團隊都打算成為一個自主的小型初創企業，產品經理將擔任功能區域的小型CEO。這些團隊的設計師和軟體工程師具有一系列專業知識。目的是使一個團隊應該擁有一切必要的技能，而不必依賴另一個團隊來獲得成功。

產品經理具有傳統的管理結構。團隊的產品經理向其部門的產品總監（“部落負責人”）報告。設計師也一樣。但是，軟體工程師是在團隊結構之外進行管理的。

“Chapter章節負責人”管理的軟體工程師專門負責整個部門的特定型別的軟體開發。例如，該部門內所有團隊的所有使用後端API的軟體工程師都將擁有一名經理，而該部門中的所有Android移動工程師將擁有一名不同的經理。目的是允許工程師在部門內的團隊之間移動，以最好地滿足業務需求，而無需更換經理。

許多組織都試圖複製Spotify模型，但結果往往好壞參半。

團隊拓撲是一種實用的，逐步的，自適應的模型，用於組織設計和團隊互動，它基於四種基本的團隊型別和三種團隊互動模式。該模型將團隊視為交付的基本手段，團隊結構和溝通途徑可以隨著技術和組織的成熟而發展。

Spotify嘗試了一個長期存在的矩陣團隊結構，只是選擇了一個不同的單詞”Spotify模型“。“全棧式”敏捷團隊運作良好，但是軟體工程師的矩陣管理引入的問題多於解決的問題。

• Spotify的團隊壽命很長。轉移到另一個團隊時不必更換經理的好處是有限的。
• 在這種模式下，工程經理除了所管理人員的職業發展外，幾乎沒有其他責任。即使那樣，他們幫助人際交往能力發展的能力仍然是有限的。工程經理不會在團隊中管理足夠多的其他人，也不會在日常工作中投入足夠的精力來獨立評估團隊內部的衝突。

由於沒有一個工程經理負責團隊中的工程師，因此產品經理缺乏同等的同事，沒有一個人對工程團隊的交付負責，也沒有人可以以同等的責任級別商議工作的優先順序。

當工程團隊內部出現分歧時，產品經理需要與團隊中的所有工程師進行談判。如果工程師無法達成共識，則產品經理需要升級為與團隊中具有工程專業知識的工程師一樣多的工程經理。一個由後端，Web應用程式和移動應用程式工程師組成的團隊將至少擁有3名工程經理，他們可能需要參與其中。如果這些工程經理無法達成共識，那麼一個團隊的問題就必須升級到部門的工程主管。

Spotify模型的合著者和在Spotify工作的許多敏捷教練一直在告訴人們多年來不要複製它。不幸的是，真理並沒有像人們想要相信的想法那樣迅速或廣泛地傳播。
“即使在我們編寫它的時候，我們也沒有這樣做。這部分是野心，部分是近似。人們真的很難複製不存在的東西。”
— JoakimSundén，Spotify 2011-2017的敏捷教練
 

“當人們看到我們所做的事情並認為這是他們可以複製和實施的框架時，這讓我感到擔憂。……我們現在真的在努力強調我們也有問題。並不是所有的東西都“閃閃發光，一切都運轉良好，我們所有的小隊都很棒”。”
-Spotify白皮書合著者Anders Ivarsson
 
“ Spotify模型”是潮流效應的受害者。敏捷和Scrum也發生了同樣的情況。在您不知情的情況下，人們會從中製造出科學怪人怪物。這就是它開始脫軌的地方。