Saat Model Tim Anda Mulai Menghambat Pengiriman

Anda memiliki tiga tim yang membangun fitur. Setiap tim membuat pipeline-nya sendiri. Setiap tim mengelola environment-nya sendiri. Setiap tim punya cara deploy-nya sendiri. Dan sekarang Anda mulai melihat masalah yang sama muncul di setiap rapat tim: deployment memakan waktu terlalu lama, tidak ada yang tahu siapa pemilik infrastruktur, dan setiap rilis terasa seperti mimpi buruk koordinasi.

Inilah momen ketika sebagian besar pemimpin engineering mulai mencari model tim yang sempurna. Mereka membaca tentang stream-aligned teams, platform teams, dan enabling teams. Mereka mencoba meniru apa yang dilakukan Spotify atau Netflix. Namun kenyataannya, model tim bukanlah menu yang bisa Anda pilih sesuka hati. Model tim adalah respons terhadap tekanan spesifik yang dirasakan organisasi Anda saat ini.

Mulailah dari yang Paling Menyakitkan

Sebelum memutuskan struktur tim apa pun, lihatlah apa yang sebenarnya memperlambat Anda. Dalam tim kecil yang terdiri dari lima hingga sepuluh orang, masalahnya jarang terletak pada batasan tim. Semua orang sudah mengerjakan semuanya. Satu orang menulis kode, mengelola server, dan membangun pipeline. Rasa sakit yang sesungguhnya di sini adalah bus factor: jika orang itu sakit, tidak ada yang bisa melakukan deployment.

Untuk ukuran tim seperti ini, model tim formal bukanlah jawabannya. Yang Anda butuhkan adalah dokumentasi dan praktik bersama. Pastikan siapa pun dapat menjalankan deployment. Tuliskan langkah-langkahnya. Otomatiskan bagian yang sering gagal. Jangan membuat platform team jika Anda hanya punya delapan orang. Anda hanya akan menciptakan lebih banyak serah terima.

Tekanan berubah ketika Anda berkembang menjadi tiga atau empat tim fitur. Kini rasa sakitnya bergeser. Setiap tim membangun pipeline-nya sendiri dari awal. Setiap tim menemukan kembali cara mereka menangani environment. Tidak ada standar bersama, dan inkonsistensi mulai memakan waktu. Inilah titik di mana platform team mulai masuk akal. Tapi tidak harus menjadi tim besar. Mulailah dengan satu atau dua orang yang tugasnya menyediakan pipeline standar. Biarkan mereka membuktikan nilainya sebelum Anda melakukan penskalaan.

Kematangan Produk Mengubah Segalanya

Tim yang membangun prototipe menghadapi kendala yang sangat berbeda dibandingkan tim yang menjalankan layanan dengan ribuan pengguna. Produk tahap awal membutuhkan kecepatan dan fleksibilitas. Mereka perlu mengubah arah dengan cepat. Struktur tim yang kaku hanya akan memperlambat mereka. Tim kecil dan lintas fungsi yang bisa bergerak cepat jauh lebih berharga daripada tim yang terorganisir sempurna tetapi tidak bisa bereaksi.

Begitu produk sudah在生产 (production) dengan pengguna nyata yang bergantung padanya, prioritas berubah. Keandalan menjadi kritis. Anda membutuhkan platform yang stabil. Anda membutuhkan tim yang bisa fokus pada kualitas tanpa terganggu oleh insiden produksi. Inilah saatnya stream-aligned teams membutuhkan platform team yang bisa mereka percaya. Ini juga saat enabling team menjadi berharga: tim yang membantu tim lain meningkatkan praktik pengujian, pola deployment, atau pengaturan monitoring mereka.

Jenis Aplikasi Membentuk Model Tim

Aplikasi monolitik yang masih bisa dikelola dapat ditangani oleh satu stream-aligned team. Namun seiring monolit tumbuh dan semakin banyak tim menyentuh basis kode yang sama, muncullah masalah klasik: satu perubahan di satu bagian merusak sesuatu di bagian lain. Deployment melambat karena semuanya harus dirilis bersamaan.

Insting umum adalah memecah monolit menjadi microservices. Tapi itu tidak selalu langkah pertama yang tepat. Sebelum memisahkan kode, pertimbangkan untuk membentuk enabling team yang membantu tim yang ada menulis pengujian yang lebih baik dan meningkatkan praktik deployment mereka. Terkadang disiplin engineering yang lebih baik di dalam monolit memberi Anda lebih banyak waktu daripada migrasi microservices yang prematur.

Jika Anda sudah menjalankan microservices, model tim Anda kemungkinan lebih terdistribusi. Setiap stream-aligned team memiliki satu atau lebih layanan. Namun tantangannya bergeser ke konsistensi: bagaimana Anda menjaga layanan tetap selaras tanpa membunuh otonomi tim? Di sinilah platform team menjadi penting. Mereka menyediakan standar yang dapat diadopsi setiap tim tanpa paksaan. Platform yang baik membuat hal yang benar menjadi hal yang mudah dilakukan.

Model Tim Tidak Bersifat Permanen

Kesalahan terbesar adalah memperlakukan struktur tim sebagai keputusan satu kali. Organisasi berubah. Produk berevolusi. Tim mempelajari keterampilan baru. Model yang berhasil tahun lalu mungkin menjadi hambatan tahun ini.

Stream-aligned team secara alami bisa berevolusi menjadi platform team ketika mereka membangun kemampuan yang mulai diandalkan oleh tim lain. Enabling team yang membantu satu tim meningkatkan pengujian mereka bisa tumbuh menjadi platform team yang melayani seluruh organisasi. Transisi ini sehat. Itu berarti organisasi sedang beradaptasi dengan kebutuhan nyata.

Yang penting adalah evaluasi rutin. Tanyakan pada diri sendiri: apakah model tim kami saat ini membantu pengiriman atau justru memperlambatnya? Jika tim terus-menerus saling menunggu, jika bottleneck komunikasi yang sama muncul setiap sprint, jika deployment memerlukan terlalu banyak persetujuan dan serah terima, sudah waktunya untuk menyesuaikan.

Pemeriksaan Praktis

Gunakan evaluasi cepat ini untuk memutuskan apakah model tim Anda perlu penyesuaian:

• Apakah deployment terhambat karena menunggu tim lain? Anda mungkin membutuhkan kepemilikan yang lebih jelas atau platform team.
• Apakah setiap tim membangun pipeline-nya sendiri dari awal? Platform team kecil bisa menghemat waktu semua orang.
• Apakah Anda mencoba memecah monolit karena gesekan antar tim? Coba enabling team terlebih dahulu untuk meningkatkan praktik di dalam monolit.
• Apakah platform team Anda tumbuh lebih cepat dari tim fitur Anda? Itu mungkin menandakan bahwa platform sedang memecahkan masalah yang salah.

Satu-satunya Aturan yang Penting

Tidak ada model tim yang benar. Hanya ada model yang sesuai dengan konteks Anda saat ini. Tujuannya bukan untuk mencocokkan diagram di buku teks. Tujuannya adalah untuk menghilangkan hambatan dalam pengiriman. Jika struktur tim Anda membuat deployment lebih cepat, lebih aman, dan lebih dapat diprediksi, maka itu berhasil. Jika struktur tim menambah overhead koordinasi dan waktu tunggu, ubahlah.

Evaluasi model tim Anda dengan cara yang sama seperti Anda mengevaluasi pipeline deployment: jika terasa sakit, perbaiki.