Model Spotify: Squad, Tribe, Chapter, dan Guild Dijelaskan

Model Spotify ialah struktur organisasi agile-berskala yang dibina di sekeliling pasukan produk kecil dan berautonomi yang dipanggil squad. Spotify menerbitkan dua kertas kerja budaya kejuruteraan yang berpengaruh pada 2012, dan model ini cepat tersebar jauh melangkaui dunia penstriman muzik ke dalam bank, peruncit, dan syarikat perisian yang mencari cara untuk berkembang pantas tanpa dicekik birokrasi.

Sebelum meneruskan: Spotify sendiri tidak lagi menjalankan model ini seperti yang digambarkan pada asalnya. Syarikat itu telah berkembang melangkauinya. Itu bukan sebab untuk mengetepikannya, tetapi ia adalah sebab untuk melayannya sebagai sumber idea dan bukan panduan untuk disalin secara literal.

Apakah Model Spotify?

Model Spotify ialah pendekatan untuk meningkatkan skala metodologi agile di seluruh organisasi kejuruteraan yang besar. Berbanding menyusun pasukan mengikut fungsi (front-end, back-end, QA), ia menyusun pasukan mengikut misi: squad kecil yang merentas fungsi memiliki satu bahagian produk secara menyeluruh dan boleh menghantar kerja tanpa menunggu pasukan lain.

Empat unit struktur mentakrifkan model ini:

Dua konsep tambahan muncul dalam huraian model ini yang lebih baharu:

• Trio: seorang Tribe Lead, seorang Product Lead, dan seorang Design Lead yang berkongsi akauntabiliti bagi hasil sesebuah tribe.
• Alliance: satu lapisan penyelarasan antara tribe apabila kerja mereka saling berkait rapat.

Falsafah di sebalik semua ini ialah ketegangan antara autonomi dan penjajaran. Squad memerlukan kebebasan yang cukup untuk membuat keputusan pantas. Tetapi jika setiap squad bertindak mengikut cara masing-masing, produk itu akan berpecah. Chapter dan guild menyediakan jalinan penghubung yang mengekalkan keselarasan tanpa menambah hierarki arahan-dan-kawalan.

Fakta Utama

• Kertas kerja budaya asal Spotify (Henrik Kniberg dan Anders Ivarsson, 2012) menggambarkan model ini sebagai "satu cara berfikir" berbanding proses yang tetap, dan secara jelas menyatakan ia masih berkembang.
• Satu catatan blog pada 2019 oleh Joakim Sunden, ketika itu jurulatih agile kanan Spotify, mengakui syarikat itu telah berkembang jauh melangkaui huraian asal. (Sumber: blog.crisp.se, 2019)
• Kajian McKinsey pada 2022 terhadap 1,000 organisasi perisian mendapati syarikat yang menggunakan struktur pasukan merentas fungsi dan selaras misi adalah 1.5 kali lebih berkemungkinan melaporkan masa-ke-pasaran yang pantas berbanding yang menggunakan silo fungsi. (Sumber: McKinsey Digital, 2022)

Model Spotify lawan SAFe: perbezaan utama

Kedua-duanya menangani masalah teras yang sama: bagaimana anda mengekalkan organisasi kejuruteraan yang besar terus bergerak pantas? Tetapi mereka menjawabnya secara berbeza.

SAFe (Scaled Agile Framework) menyediakan hierarki yang terperinci dan preskriptif: pasukan, program, penyelesaian, portfolio. Terdapat peranan yang ditentukan (Release Train Engineer, Product Management), upacara yang ditentukan (PI Planning, System Demo), dan kadensi keluaran yang berstruktur.

Model Spotify bersifat deskriptif, bukan preskriptif. Ia menyatakan: inilah unit yang berfungsi untuk kami, inilah pemikiran di sebaliknya. Anda perlu menentukan sendiri upacara dan kadensinya.

Syarikat yang memerlukan pematuhan kawal selia, program perkakasan yang besar, atau integrasi rapat dengan vendor luaran sering mendapati struktur SAFe berbaloi dengan overhednya. Syarikat berorientasikan produk yang mahu squad bergerak seperti startup biasanya lebih memilih pendekatan Spotify yang lebih ringan, atau satu gabungan hibrid.

Faedah Model Spotify

Penghantaran lebih pantas. Squad boleh menghantar kerja secara berterusan kerana mereka memiliki keseluruhan tindanan bagi bahagian produk mereka. Tiada serahan antara "pasukan pembangunan" dan "pasukan QA" dan "pasukan operasi." Ketiga-tiganya berada dalam squad itu sendiri. Ini adalah pemikiran yang sama di sebalik apakah scrum, tetapi digunakan pada skala yang lebih besar.

Kos penyelarasan yang berkurangan. Jika sesebuah squad boleh melancarkan kerja secara bebas, ia tidak perlu menyelaraskan tempoh keluaran dengan tujuh pasukan lain. Model ini menggunakan Hukum Conway secara sengaja: seni bina sistem mencerminkan struktur pasukan, jadi pasukan-pasukan itu kekal tidak terikat rapat antara satu sama lain.

Perkembangan kemahiran tanpa silo fungsi. Chapter menyelesaikan satu masalah sebenar yang diwujudkan oleh pasukan yang sepenuhnya berautonomi: jurutera menjadi terpencil dalam squad mereka dan terlepas komuniti kraf. Sebuah chapter lima jurutera iOS merentasi lima squad bertemu secara berkala untuk berkongsi amalan, meningkatkan asas kemahiran kolektif, dan memberikan Chapter Lead akauntabiliti yang jelas terhadap kualiti teknikal.

Budaya pemilikan. Apabila sesebuah squad memiliki perjalanan pengguna daripada front-end hingga pangkalan data hingga on-call, pasukan itu merasai akibat daripada keputusan mereka sendiri. Pemilikan itu mengubah tingkah laku dengan cara yang tidak mampu dilakukan oleh struktur serahan berasaskan tiket.

Guild mempercepatkan pemindahan pengetahuan. Sesebuah guild pada dasarnya adalah komuniti amalan. Ia tiada kuasa formal, tetapi ia menyebarkan idea baik merentasi syarikat lebih pantas daripada mana-mana memo atas-ke-bawah. Anda mungkin mempunyai guild untuk kebolehcapaian, untuk pemerhatian sistem (observability), atau untuk kejuruteraan data.

Batasan dan Kritikan

Model ini mempunyai mod kegagalan yang telah didokumenkan dengan baik, dan anda perlu membacanya sebelum mula menyusun semula pasukan anda.

Spotify sendiri telah beralih. Kertas kerja asal 2012 ditulis ketika Spotify mempunyai kira-kira 30-40 squad. Menjelang 2019, syarikat itu mempunyai beratus-ratus jurutera dan mengakui bahawa model yang digambarkan dalam kertas kerja itu tidak lagi sepadan dengan cara mereka bekerja. Rangka fikir paling jujur: kertas kerja itu mendokumentasikan satu titik masa, bukan kebenaran organisasi yang kekal.

"Model Spotify" menjadi kultus kargo. Ramai syarikat menyalin perbendaharaan kata (squad, tribe, chapter, guild) tanpa menyalin syarat budaya yang menjadikannya berfungsi di Spotify. Menamakan semula pasukan anda tidak mengubah cara keputusan dibuat.

Chapter Lead membawa akauntabiliti berganda yang janggal. Chapter Lead adalah kedua-dua pengurus manusia (penilaian prestasi, pengambilan pekerja) dan penyumbang individu dalam sesebuah squad. Itu adalah peranan yang sukar dimainkan dengan baik. Fungsi chapter boleh menjadi sama ada sekadar formaliti atau terlalu mendominasi, bergantung pada individu tersebut.

Kebergantungan tidak akan hilang. Model ini mengandaikan squad boleh bekerja secara bebas. Tetapi dalam produk sebenar, squad berkongsi platform, perkhidmatan bersama, dan data. Tribe dan alliance sepatutnya menangani ini, tetapi model ini tidak menerangkan bagaimana secara jelas. Ramai organisasi akhirnya mencipta semula mesyuarat integrasi yang cuba mereka elakkan, hanya dengan nama baharu.

Sukar meningkatkan skala konsep tribe. Tribe kekal koheren apabila ia berjumlah 40-80 orang. Melebihi itu, budaya bersama dan komunikasi tidak formal yang menyatukan sesebuah tribe mula runtuh. Tetapi model ini tidak memberikan panduan jelas tentang bila hendak memisahkan sesebuah tribe atau cara mengendalikan pemisahan itu.

Tidak sesuai untuk setiap budaya. Autonomi squad yang tinggi memerlukan jurutera yang mahu memiliki keputusan, pengurus produk yang boleh bekerja tanpa hierarki yang mendalam, dan pengurus yang selesa melepaskan kawalan. Organisasi dengan budaya arahan-dan-kawalan yang kuat mendapati model ini menggugat kestabilan tanpa perubahan kepimpinan yang intensif.

Cara Menggunakan Model Spotify

Jika anda hendak menerima pakai ini, layankannya sebagai titik permulaan dan jangkakan untuk menyesuaikannya secara ketara. Berikut satu urutan yang pragmatik.

Langkah 1: Petakan produk anda ke dalam misi bersaiz squad

Mulakan dengan perjalanan pengguna atau bahagian produk yang dimiliki oleh organisasi kejuruteraan anda. Sesebuah squad sepatutnya memiliki sesuatu yang bermakna secara menyeluruh: pengalaman checkout, sistem notifikasi, saluran data. Jika anda tidak dapat menamakan apa yang dimiliki oleh squad itu, ia bukan saiz atau skop yang betul.

Elakkan perangkap mencipta squad yang mencerminkan struktur pasukan fungsi sedia ada anda. "Squad back-end" mengalahkan tujuannya. "Squad pembayaran yang memiliki segalanya daripada UI hingga penyelesaian (settlement)" lebih hampir dengan niat model ini.

Langkah 2: Tentukan tribe sebelum squad bertambah

Kumpulkan squad ke dalam tribe pada peringkat awal, sebelum anda mempunyai begitu banyak squad sehingga pengelompokan itu menjadi sewenang-wenangnya. Sesebuah tribe sepatutnya mempunyai domain yang koheren: pertumbuhan, produk teras, platform, data. Trio (Tribe Lead, Product Lead, Design Lead) sepatutnya dinamakan pada peringkat ini.

Sasarkan tribe di bawah 100 orang. Lebih besar daripada itu, rangkaian kepercayaan tidak formal yang menyatukan sesebuah tribe tidak akan terbentuk secara semula jadi.

Langkah 3: Bina chapter untuk setiap disiplin

Kenal pasti disiplin teknikal yang merentasi squad: front-end, back-end, mobile, data, QA. Bagi setiap satu, lantik seorang Chapter Lead yang kukuh dari segi teknikal dan boleh dipercayai sebagai pengurus manusia. Tentukan apa yang menjadi tanggungjawab chapter itu: piawaian pengekodan, sesi temu duga, onboarding, hala tuju teknikal.

Jangan jadikan chapter terlalu besar. Lima hingga lima belas orang boleh diuruskan. Chapter dengan tiga puluh jurutera bukan lagi komuniti, ia sudah menjadi sebuah jabatan.

Langkah 4: Lancarkan guild secara organik, bukan melalui arahan

Guild berfungsi apabila orang ramai cukup mengambil berat untuk menyusun diri secara sukarela. Anda boleh menyemai beberapa guild dengan mengenal pasti jurutera yang sudah menjadi penganjur bagi sesuatu topik (pemerhatian sistem, kebolehcapaian, amalan ujian) dan meminta mereka mengendalikan forum bulanan.

Jangan mewajibkan keahlian guild atau menjadikan penyertaan guild sebahagian daripada penilaian prestasi. Itu akan membunuh sifat tidak formal yang menjadikan guild berguna.

Langkah 5: Tentukan mekanisme penjajaran anda secara jelas

Ini adalah langkah yang paling kerap dilangkau oleh pasukan, dan di sinilah kebanyakan penerimaan pakai model Spotify runtuh. Autonomi tanpa penjajaran menghasilkan tujuh belas pasukan yang membina tujuh belas sistem pengesahan yang berbeza.

Tuliskan: bagaimana squad berkomunikasi mengenai kebergantungan merentas squad? Bagaimana pilihan teknologi ditadbir? Siapa yang menentukan bila sesuatu keupayaan platform menjadi perkhidmatan bersama berbanding setiap squad membina versinya sendiri? Jawapan-jawapan ini tidak akan datang daripada model Spotify itu sendiri. Anda perlu menentukannya sendiri.

Langkah 6: Jalankan retrospektif ke atas struktur itu sendiri

Setiap enam bulan, tanya Trio dan Chapter Lead: adakah struktur squad itu masih betul? Adakah dua squad menjadi begitu saling bergantung sehingga sepatutnya digabungkan? Adakah sesebuah tribe terlalu besar? Jenis retrospektif struktur ini sama pentingnya dengan retrospektif sprint di dalam squad.

Contoh Model Spotify

Model ini tersebar merentasi industri selepas kertas kerja 2012. Berikut contoh terdokumentasi bagaimana pelbagai organisasi menyesuaikannya:

Kes ING mungkin adalah pelaksanaan perusahaan besar yang paling banyak dipetik. Penyesuaian utama mereka ialah melayan chapter pematuhan sebagai komponen utama berbanding sekadar renungan tambahan, yang menjadi pengajaran bermakna bagi mana-mana industri terkawal.

Amalan Terbaik

Beberapa prinsip yang membezakan penerimaan pakai model Spotify yang berjaya daripada pelaksanaan kultus kargo:

Padankan sempadan squad dengan seni bina. Jika anda mahu squad melancarkan kerja secara bebas, sistem anda perlu longgar terikat antara satu sama lain. Reka bentuk organisasi dan seni bina teknikal perlu bergerak bersama-sama. Inilah sebabnya pasukan yang menggunakan upacara agile atau amalan extreme programming mendapati model ini lebih mudah diterima pakai: tabiat teknikal mereka sudah menyokong ketidakterikatan.

Jangan menamakan semula tanpa mengubah suai. Memanggil pasukan anda "squad" dan jabatan anda "tribe" tidak mengubah apa-apa dengan sendirinya. Perubahan yang bermakna terletak pada cara keputusan dibuat, cara kerja diberi keutamaan, dan cara konflik antara squad diselesaikan.

Laburkan dalam Chapter Lead. Peranan Chapter Lead lebih sukar daripada yang kelihatan. Chapter Lead yang baik secara aktif meningkatkan asas kualiti teknikal merentasi chapter mereka, mengendalikan sesi 1:1 yang berkesan, dan kekal boleh dipercayai sebagai penyumbang individu. Kekurangan pelaburan dalam peranan ini adalah salah satu cara paling biasa model ini merosot.

Jangan terlalu formalkan guild. Jika mesyuarat guild menjadi wajib atau output guild menjadi pintu semakan, anda telah mengubah komuniti amalan menjadi jawatankuasa. Kekalkan ia ringan.

Pinjam secara terpilih. Anda tidak perlu menerima pakai keseluruhan perbendaharaan kata. Sesetengah organisasi menjalankan squad dan tribe tetapi melangkau guild kerana mereka terlalu kecil. Yang lain menjalankan chapter tetapi memanggilnya "bidang amalan." Konsepnya lebih penting daripada labelnya.

Jangan layan kertas kerja 2012 sebagai dokumentasi semasa. Ia adalah gambaran sejarah satu syarikat yang sedang berkembang pesat pada satu ketika tertentu. Bacalah, ekstrak penaakulannya, kemudian bina versi yang sesuai dengan organisasi anda.

Jika anda membandingkan irama penghantaran merentas squad, kadensi sprint Scrum dan model aliran berterusan Kanban kedua-duanya digunakan di dalam squad dalam organisasi bermodel Spotify. Sesetengah squad menjalankan Scrumban, satu hibrid yang memberikan mereka disiplin perancangan sprint bersama had WIP Kanban. Pertukaran Scrum lawan Kanban berbaloi difahami sebelum anda memutuskan apa yang dijalankan oleh setiap squad.

Soalan Lazim

Adakah model Spotify sama dengan SAFe?

Tidak. SAFe adalah rangka kerja preskriptif dengan peranan, upacara, dan struktur keluaran yang ditentukan. Model Spotify adalah reka bentuk organisasi yang deskriptif: ia menamakan unit-unit (squad, tribe, chapter, guild) dan falsafahnya (autonomi dan penjajaran), tetapi meninggalkan upacara, kadensi, dan tadbir urus kepada setiap organisasi. Syarikat kadangkala menggabungkan elemen kedua-duanya, menggunakan struktur unit Spotify bersama PI Planning gaya SAFe yang jelas untuk menguruskan kebergantungan merentas squad.

Adakah model Spotify berfungsi untuk syarikat bukan teknologi?

Ia direka bentuk untuk kejuruteraan perisian, dan andaian-andaiannya (penghantaran berterusan, pemilikan tindanan teknikal, perkongsian pengetahuan berasaskan guild) sesuai secara semula jadi dengan pasukan teknologi. Syarikat bukan teknologi telah menerima pakainya, tetapi mereka biasanya perlu menyesuaikan takrifan squad secara ketara. Squad pemasaran atau squad operasi tidak mempunyai model pemilikan menyeluruh yang sama seperti squad kejuruteraan yang mengawal saluran penerapan (deployment) mereka sendiri. Prinsip-prinsipnya (autonomi, penjajaran, komuniti amalan) dapat diterjemahkan; mekanisme khusus selalunya tidak.

Sebesar mana sesebuah syarikat perlu untuk mendapat manfaat daripada model Spotify?

Model ini direka bentuk untuk menyelesaikan masalah penyelarasan yang timbul apabila skala meningkat. Di bawah kira-kira 50-80 jurutera, satu struktur pasukan agile rata tunggal atau persediaan squad ringkas tanpa tribe dan chapter mungkin sudah mencukupi. Tribe dan guild mula berbaloi dengan overhednya apabila anda mempunyai cukup banyak squad sehingga komunikasi tidak formal tidak lagi dapat menyelaraskan mereka.

Apakah yang tidak berjalan lancar apabila syarikat gagal melaksanakan model Spotify?

Corak kegagalan paling biasa: syarikat menerima pakai perbendaharaan kata tanpa mengubah struktur pembuatan keputusan. Autonomi squad memerlukan squad benar-benar dapat membuat keputusan mengenai teknologi, seni bina, dan pengutamaan tanpa perlu menyalurkan segalanya melalui hierarki. Apabila sesebuah "squad" masih memerlukan enam kelulusan untuk melancarkan kerja, ia tidak berautonomi dalam apa jua erti yang bermakna. Kegagalan kedua paling biasa: kekurangan pelaburan dalam peranan Chapter Lead, yang menyebabkan piawaian teknikal bercabang dan kualiti hanyut merentasi squad.

Bolehkah anda menggabungkan model Spotify dengan Scrum?

Ya, dan kebanyakan organisasi berbuat demikian. Model Spotify mentakrifkan struktur pasukan dan unit organisasi; Scrum mentakrifkan irama penghantaran dan upacara di dalam sesebuah squad. Sesebuah squad menjalankan sprint dua minggu, mengadakan retrospektif, dan menyikat backlog sambil tetap tergolong dalam sesebuah tribe, mempunyai chapter, dan menyertai guild. Kedua-duanya beroperasi pada tahap yang berbeza dan tidak bercanggah secara langsung.

---

Model Spotify memberikan dunia perisian satu perbendaharaan kata untuk membincangkan pasukan berautonomi dan didorong misi pada skala besar. Walaupun Spotify sendiri telah berkembang melangkaui reka bentuk asalnya, konsep squad memiliki bahagian produk secara menyeluruh, chapter mengekalkan disiplin yang koheren, dan guild menyebarkan pengetahuan secara tidak formal telah terbukti berguna jauh melangkaui satu startup Sweden. Gunakannya sebagai lensa, bukan undang-undang, dan anda akan mendapat sebahagian besar nilainya tanpa terjebak dalam perangkap kultus kargo.

Bacaan Berkaitan

• Apakah metodologi agile?
• Apakah Scrum?
• Scaled Agile Framework (SAFe)
• Scrum lawan Kanban
• Upacara agile
• Scrumban
• Apakah Kanban?
• Extreme programming