Kapan Tim Fitur Sebaiknya Tidak Menyentuh Kode: Studi Kasus Tim Subsystem yang Rumit

Tim Anda sedang membangun platform e-commerce. Anda memiliki alur checkout, katalog produk, dan halaman profil pengguna. Semuanya berjalan lancar hingga modul pembayaran perlu diubah. Tiba-tiba, pembaruan paling sederhana pun membutuhkan tiga review kode, dua persetujuan, dan doa sebelum deployment. Satu baris yang salah bisa menggandakan tagihan pelanggan atau menghilangkan transaksi sepenuhnya. Tim melambat, bukan karena mereka insinyur yang buruk, tetapi karena mesin pembayaran adalah "binatang" yang berbeda.

Situasi ini umum terjadi. Setiap aplikasi memiliki bagian yang terlalu berisiko, terlalu terspesialisasi, atau terlalu rumit untuk ditangani dengan aman oleh tim fitur generalis. Struktur tim stream-aligned standar bekerja sangat baik untuk sebagian besar fitur, tetapi akan bermasalah ketika kode membutuhkan keahlian yang dalam dan sempit. Di sinilah tim complicated-subsystem (tim subsystem rumit) berperan.

Apa yang Membuat Sebuah Subsystem Menjadi Rumit

Tidak semua kode membutuhkan tim khusus. Sebuah subsystem yang rumit memiliki karakteristik spesifik. Ia jarang berubah, tetapi ketika berubah, dampaknya luas dan berbahaya. Ia membutuhkan pengetahuan yang membutuhkan waktu berbulan-bulan atau bertahun-tahun untuk dibangun. Perilakunya tidak jelas: kasus tepi, race condition, dan ketergantungan state halus yang hanya muncul di production.

Bayangkan mesin pembayaran, skema database inti, sistem penagihan, atau modul deteksi fraud. Ini bukan sekadar kompleks dalam arti memiliki banyak baris kode. Mereka rumit karena biaya kesalahan sangat tinggi, dan jalur untuk melakukannya dengan benar sangat sempit. Tim fitur yang mengerjakan halaman produk tidak bisa menghabiskan tiga minggu mempelajari keanehan payment gateway hanya untuk menambahkan metode pembayaran baru.

Bagaimana Tim Complicated-Subsystem Bekerja

Tim ini ada untuk satu tujuan: memiliki dan memelihara subsystem tertentu yang membutuhkan keahlian mendalam. Mereka tidak membangun fitur yang berhadapan langsung dengan pengguna. Mereka tidak merespons permintaan pelanggan secara langsung. Tugas mereka adalah menjaga subsystem tetap stabil, aman, dan siap digunakan oleh tim lain.

Model interaksinya adalah X-as-a-Service. Tim complicated-subsystem menyediakan antarmuka yang jelas, biasanya API, yang dapat dipanggil oleh tim stream-aligned tanpa perlu memahami internalnya. Tim pembayaran mengekspos endpoint untuk memproses pembayaran, memeriksa status transaksi, dan memulai pengembalian dana. Tim fitur memanggil endpoint tersebut dan melanjutkan pekerjaan mereka. Mereka tidak perlu tahu bagaimana koneksi bank bekerja atau bagaimana logika rekonsiliasi menangani transaksi duplikat.

Batas ini sangat penting. Ini melindungi tim fitur dari kompleksitas yang tidak mereka butuhkan, dan melindungi subsystem dari perubahan yang dilakukan oleh orang yang tidak sepenuhnya memahaminya.

Kapan Kolaborasi Menjadi Diperlukan

Model X-as-a-Service bekerja dengan baik untuk operasi rutin, tetapi terkadang tim fitur membutuhkan sesuatu yang baru dari subsystem. Mungkin mereka membutuhkan kemampuan pengembalian dana parsial yang belum ada. Dalam kasus ini, kedua tim berkolaborasi sementara. Tim fitur menjelaskan kebutuhannya. Tim complicated-subsystem merancang perubahan, mengimplementasikannya, dan memperluas API. Setelah kemampuan baru tersedia, kolaborasi berakhir. Tim fitur kembali memanggil API, dan tim complicated-subsystem kembali memelihara subsystem.

Kolaborasi sementara ini bukanlah kegagalan model. Ini adalah cara model tetap berguna. Kuncinya adalah kolaborasi memiliki ruang lingkup yang jelas dan akhir yang ditentukan. Ini tidak berubah menjadi ketergantungan permanen di mana tim fitur menunggu tim complicated-subsystem untuk setiap perubahan kecil.

Menghindari Hambatan (Bottleneck)

Risiko terbesar dengan tim complicated-subsystem adalah menjadi hambatan. Jika setiap perubahan pada subsystem membutuhkan keterlibatan tim, tim fitur akan melambat. Solusinya adalah berinvestasi besar-besaran pada antarmuka. API harus fleksibel, terdokumentasi dengan baik, dan dirancang untuk mencakup kasus penggunaan umum tanpa memerlukan pembaruan terus-menerus. Tim juga harus memelihara pipeline CI/CD yang kuat untuk subsystem mereka sendiri, termasuk pengujian integrasi yang menyeluruh dan strategi deployment yang aman seperti blue-green atau canary release.

Ketika antarmuka sudah baik, sebagian besar tim fitur tidak perlu berbicara dengan tim complicated-subsystem. Mereka cukup menggunakan API dan melanjutkan pekerjaan. Tim hanya terlibat ketika sesuatu yang benar-benar baru diperlukan.

Daftar Periksa Praktis untuk Mengidentifikasi Subsystem yang Rumit

Sebelum membentuk tim complicated-subsystem, periksa apakah kode benar-benar sesuai dengan profil:

• Apakah satu kesalahan dalam kode ini memiliki biaya finansial, keamanan, atau operasional yang tinggi?
• Apakah membutuhkan pengetahuan khusus yang membutuhkan waktu berbulan-bulan untuk dikuasai?
• Apakah jarang berubah, tetapi dengan dampak luas ketika berubah?
• Apakah tim fitur akan jauh lebih lambat jika harus memiliki kode ini?

Jika Anda menjawab ya untuk sebagian besar pertanyaan ini, tim complicated-subsystem layak dipertimbangkan. Jika tidak, pertahankan kode di tim fitur dan berinvestasilah pada pengujian dan dokumentasi yang lebih baik.

Kesimpulan

Tim complicated-subsystem bukan tentang menjaga kode atau menciptakan hierarki. Ini tentang melindungi subsystem dan tim fitur dari risiko yang tidak perlu. Tim fitur tetap cepat karena mereka tidak perlu mempelajari internal mesin pembayaran. Subsystem tetap aman karena hanya orang yang benar-benar memahaminya yang melakukan perubahan. Antarmuka di antara mereka adalah kontrak yang membuat ini berhasil. Investasikan pada antarmuka itu, dan kedua tim akan menang.