Tiga Cara Tim Bekerja Sama Tanpa Menimbulkan Hambatan

Kamu memiliki tim platform yang sudah membangun pipeline CI/CD yang hebat. Sebuah tim stream-aligned perlu menggunakannya. Tapi alih-alih langsung menjalankan deployment mereka, mereka terus-menerus bertanya ke tim platform. Tim platform pun terseret ke setiap rilis. Akhirnya, tidak ada yang mengerjakan tugas inti mereka.

Inilah saatnya mengetahui tipe tim saja tidak cukup. Kamu juga perlu tahu bagaimana tim berinteraksi. Team Topologies menjelaskan tiga pola interaksi yang membantu tim berkolaborasi tanpa menciptakan ketergantungan baru atau saling memperlambat. Setiap pola cocok untuk situasi yang berbeda, dan mengetahui kapan harus menggunakan -- dan kapan harus beralih -- menjadi pembeda antara pengiriman yang lancar dan beban koordinasi yang terus-menerus.

Kolaborasi: Bekerja Sama untuk Masalah yang Belum Jelas

Kolaborasi terjadi ketika dua tim bekerja sama secara erat untuk periode waktu tertentu. Mereka berbagi saluran komunikasi, sering sinkron, dan sering duduk di ruang yang sama. Pola ini berguna ketika masalah belum sepenuhnya dipahami dan membutuhkan keahlian dari kedua tim.

Bayangkan sebuah tim stream-aligned ingin menambahkan fitur yang membutuhkan perubahan di subsistem yang dikelola oleh tim complicated-subsystem. Tidak ada tim yang bisa menyelesaikannya sendirian. Tim stream-aligned tahu kebutuhan fitur. Tim complicated-subsystem tahu arsitektur internal. Mereka perlu bekerja sama untuk menemukan desain yang tepat, menulis kode yang terhubung, dan memverifikasi tidak ada yang rusak.

Kolaborasi itu kuat, tapi ada biayanya. Ini menyita perhatian kedua tim. Ini menciptakan ketergantungan sementara. Itulah mengapa kolaborasi tidak boleh berlangsung selamanya. Setelah masalah terpecahkan dan polanya menjadi jelas, interaksi harus beralih ke pola yang lebih ringan. Kolaborasi yang berkepanjangan membuat tim saling bergantung dan mengalihkan perhatian dari value stream mereka sendiri.

Pertanyaan kuncinya: Apakah kita masih membutuhkan kerja bersama yang mendalam, atau bisakah kita mendokumentasikan apa yang telah dipelajari dan melanjutkannya?

X-as-a-Service: Menyediakan Kemampuan Tanpa Pendampingan

Dalam pola X-as-a-Service, satu tim menyediakan kemampuan yang bisa dikonsumsi tim lain tanpa perlu tahu detail implementasinya. Tim penyedia memiliki kendali atas antarmuka, ketersediaan, dan kualitas. Tim konsumen tinggal menggunakannya -- seperti memanggil API atau menjalankan pipeline yang sudah jadi.

Ini adalah interaksi alami antara tim platform dan tim stream-aligned. Tim platform menyediakan environment, pipeline CI/CD, atau alat monitoring sebagai layanan. Tim stream-aligned tidak perlu memahami bagaimana pipeline dibangun atau dipelihara. Mereka tinggal menggunakannya.

Keberhasilan pola ini bergantung pada satu hal: antarmuka yang stabil dan jelas. Jika layanan sering berubah, atau dokumentasi tidak lengkap, tim konsumen akan frustrasi. Mereka mulai membangun solusi sendiri. Itu akan menggagalkan tujuan memiliki tim platform.

X-as-a-Service mengurangi beban komunikasi dan memungkinkan setiap tim bergerak dengan kecepatannya sendiri. Tapi ini hanya berhasil ketika tim penyedia memperlakukan antarmuka sebagai produk, bukan sebagai sesuatu yang dipikirkan belakangan.

Fasilitasi: Mengajari Tim Agar Mandiri

Fasilitasi adalah pola di mana satu tim membantu tim lain meningkatkan kemampuan tertentu tanpa mengambil alih pekerjaan. Ini adalah pola inti untuk enabling teams.

Seorang enabling team tidak datang untuk mengerjakan pekerjaan tim stream-aligned. Mereka datang untuk mengajar, melatih, dan memberikan contoh atau panduan. Misalnya, enabling team yang berspesialisasi dalam keamanan aplikasi dapat membantu tim stream-aligned memahami cara menulis kode yang aman, mengelola secret, atau mengintegrasikan pemindaian keamanan ke dalam pipeline mereka. Begitu tim stream-aligned bisa melakukannya sendiri, enabling team mundur dan beralih ke tim lain yang membutuhkan bantuan.

Fasilitasi berbeda dari kolaborasi karena enabling team tidak membangun produk. Ini berbeda dari X-as-a-Service karena enabling team tidak menyediakan layanan permanen. Tujuan fasilitasi adalah membuat tim lain mandiri.

Jebakannya di sini adalah fasilitasi yang tidak pernah berakhir. Jika enabling team terlalu lama bersama satu tim, mereka menjadi pengasuh permanen. Tim tidak pernah belajar beroperasi tanpa mereka.

Ketiga Pola Bisa Berjalan Secara Paralel

Ketiga pola ini tidak eksklusif. Dalam organisasi yang sehat, semuanya berjalan bersamaan. Sebuah tim stream-aligned mungkin menggunakan layanan tim platform melalui X-as-a-Service, berkolaborasi dengan tim complicated-subsystem untuk fitur yang rumit, dan menerima fasilitasi dari enabling team tentang praktik pengujian.

Yang penting adalah menyadari pola mana yang aktif dan kapan harus beralih. Kolaborasi yang berlanjut tanpa alasan jelas menciptakan ketergantungan baru. X-as-a-Service dengan antarmuka yang tidak stabil menghancurkan kepercayaan. Fasilitasi yang tidak pernah berakhir mencegah tim menjadi mandiri.

Daftar Periksa Praktis untuk Memilih Pola Interaksi

Sebelum mengatur interaksi baru antar tim, lakukan pemeriksaan cepat ini:

Diagram alir berikut merangkum titik keputusan utama dari daftar periksa:

flowchart TD A[Interaksi tim baru diperlukan] --> B{Masalah sudah dipahami dengan baik?} B -- Tidak --> C[Kolaborasi] C --> D[Tetapkan tanggal akhir] B -- Ya --> E{Bisakah kemampuan disediakan tanpa pendampingan?} E -- Ya --> F[X-as-a-Service] F --> G[Perlakukan antarmuka sebagai produk] E -- Tidak --> H[Fasilitasi] H --> I[Rencanakan keluarnya enabling team]
  • Apakah masalahnya tidak jelas dan membutuhkan penemuan bersama? Gunakan kolaborasi, tapi tetapkan tanggal akhir.
  • Apakah satu tim memiliki kemampuan stabil yang dibutuhkan tim lain? Gunakan X-as-a-Service, dan perlakukan antarmuka sebagai produk.
  • Apakah sebuah tim perlu mempelajari keterampilan baru? Gunakan fasilitasi, dan rencanakan enabling team untuk keluar.
  • Apakah kolaborasi berlangsung lebih lama dari yang diharapkan? Tanyakan apakah pola ini sudah menjadi kebiasaan, bukan kebutuhan.
  • Apakah antarmuka X-as-a-Service menyebabkan frustrasi? Perbaiki antarmuka atau dokumentasi sebelum menambahkan lebih banyak fitur.
  • Apakah enabling team masih dibutuhkan setelah beberapa bulan? Tim mungkin tidak belajar. Beralihlah ke pendekatan yang berbeda.

Intisari

Pola interaksi bukan sekadar teori. Ini adalah alat praktis untuk memutuskan seberapa banyak koordinasi yang sehat dan seberapa banyak yang sia-sia. Kolaborasi memecahkan masalah sulit tapi harus bersifat sementara. X-as-a-Service mempercepat pengiriman tapi membutuhkan antarmuka yang stabil. Fasilitasi membangun kemampuan tapi harus memiliki rencana keluar.

Tim yang mengirim dengan baik bukanlah tim yang berkolaborasi dalam segala hal. Mereka adalah tim yang tahu kapan harus bekerja sama, kapan harus menyediakan layanan, dan kapan harus mengajar lalu mundur.