Mengapa Tim Anda Membutuhkan Governance (Meskipun Anda Benci Kata Itu)

Tim Anda semakin cepat dalam mengirimkan perubahan. Yang awalnya hanya beberapa deployment per minggu kini berubah menjadi beberapa deployment per hari. Pengguna bertambah. Produk semakin baik. Semua terasa lancar.

Kemudian halaman login mulai lambat setelah sebuah deploy. Sebuah fitur pencarian menghilang tanpa ada yang menyadari sampai ada pelanggan yang melaporkannya. Insiden seperti ini terjadi sekali, pengguna memaafkan Anda. Terjadi dua kali, kepercayaan mulai terkikis.

Namun ada sisi lain dari cerita ini. Mungkin tim Anda menjadi sangat takut merusak sesuatu sehingga setiap perubahan membutuhkan review dari engineer senior, rapat, dan tiga persetujuan. Perbaikan typo di halaman about membutuhkan dua hari untuk sampai ke production. Perbaikan bug kecil mengantre karena reviewer sedang sibuk. Inovasi melambat. Tim frustrasi. Pengguna tidak mendapatkan perbaikan yang mereka butuhkan.

Inilah dilema yang coba dipecahkan oleh governance. Bukan governance yang menambah birokrasi atau memperlambat segalanya. Melainkan governance yang membantu Anda menjaga perubahan tetap terkendali tanpa mengorbankan kecepatan.

Jebakan Satu-Ukuran-Untuk-Semua

Banyak tim terjebak dalam pola umum: mereka menerapkan proses yang sama untuk setiap perubahan. Setiap pull request butuh review dari senior. Setiap deployment butuh rapat. Setiap perubahan butuh persetujuan dari banyak orang.

Logikanya terdengar masuk akal. "Kami ingin berhati-hati. Kami tidak ingin merusak sesuatu." Namun hasilnya bisa ditebak. Perubahan kecil berisiko rendah tersangkut di pipeline yang sama dengan migrasi database besar. Anggota tim mulai mencari cara untuk menghindari proses resmi. Mereka push langsung ke production pada Jumat malam karena jalur resmi terlalu lama. Atau mereka menimbun perubahan dan mendeploy semuanya dalam satu rilis besar, berharap tidak ada yang salah.

Keduanya tidak baik. Yang pertama menciptakan perubahan tanpa pengawasan yang tidak direview siapa pun. Yang kedua menciptakan deployment berisiko tinggi yang sulit di-rollback.

Risiko Tidak Sama untuk Setiap Perubahan

Perbaikan typo di halaman about tidak sama dengan mengubah skema database. Pembaruan konfigurasi untuk level logging tidak sama dengan memodifikasi alur autentikasi. Memperlakukan keduanya dengan cara yang sama hanya membuang waktu pada hal yang tidak perlu dan mengabaikan hal yang justru penting.

Governance yang baik dimulai dari ide sederhana: setiap perubahan memiliki tingkat risiko yang berbeda, dan tingkat risiko tersebut menentukan seberapa banyak pengawasan yang dibutuhkan.

Perubahan berisiko rendah bisa bergerak cepat. Koreksi teks, tweak CSS, pembaruan dokumentasi. Perubahan ini kecil kemungkinannya menyebabkan kerusakan berarti. Perubahan ini bisa melalui review ringan atau bahkan push langsung jika tim cukup percaya pada pemeriksaan otomatis.

Perubahan berisiko sedang membutuhkan pasangan mata kedua. Fitur baru di balik feature flag, optimasi performa, refaktor yang tidak mengubah perilaku. Perubahan ini diuntungkan oleh code review dan pengujian otomatis, tetapi tidak perlu komite.

Perubahan berisiko tinggi membutuhkan lebih banyak struktur. Migrasi database, perubahan infrastruktur, patch keamanan, perubahan pada logika pembayaran atau autentikasi. Perubahan ini membutuhkan review menyeluruh, pengujian otomatis yang mencakup jalur kritis, dan mungkin rencana peluncuran bertahap.

Kuncinya adalah mendefinisikan kategori-kategori ini dengan jelas sehingga tim tahu apa yang harus dilakukan tanpa menebak-nebak. Ketika kriterianya kabur, orang cenderung menyetujui semuanya secara berlebihan atau menyetujui semuanya secara kurang.

Seperti Apa Governance dalam Praktik

Governance bukanlah dokumen yang tersimpan di shared drive. Governance adalah kumpulan jawaban praktis untuk pertanyaan yang dihadapi tim Anda setiap hari:

• Perubahan mana yang bisa saya deploy langsung?
• Perubahan mana yang perlu dilihat orang lain terlebih dahulu?
• Perubahan mana yang membutuhkan persetujuan orang atau tim tertentu?
• Pemeriksaan otomatis apa yang harus lulus sebelum perubahan dikirim?
• Apa yang harus saya lakukan jika perubahan menyebabkan masalah setelah deployment?

Jawabannya tidak perlu rumit. Tabel sederhana atau diagram keputusan lebih efektif daripada dokumen kebijakan setebal 20 halaman. Tujuannya adalah membuat proses dapat diprediksi sehingga orang bisa bergerak cepat tanpa menebak-nebak.

Misalnya, sebuah tim mungkin sepakat bahwa perubahan apa pun yang menyentuh skema database membutuhkan review dari seseorang yang memahami model data. Perubahan apa pun yang memodifikasi pipeline deployment membutuhkan review dari tim platform. Sisanya bisa melalui code review normal dan pemeriksaan otomatis.

Yang penting adalah aturan-aturan ini eksplisit dan diketahui semua orang. Ketika aturan bersifat implisit, orang membuat asumsi yang berbeda dan konflik pun muncul.

Tujuan Sebenarnya: Kepercayaan dan Kecepatan

Governance bukan tentang siapa yang memiliki otoritas paling besar. Governance adalah tentang bagaimana tim bisa yakin bahwa perubahan telah melalui pemeriksaan yang cukup sebelum mencapai pengguna. Ketika tim percaya pada proses, mereka bergerak lebih cepat. Ketika mereka tidak percaya pada proses, mereka melambat atau menghindarinya.

Proses governance yang dirancang dengan baik melakukan dua hal sekaligus. Ia melindungi pengguna dari perubahan yang buruk, dan ia melindungi tim dari gesekan yang tidak perlu. Ia menjaga halaman login tetap cepat dan fitur pencarian tetap terlihat, sambil juga membiarkan perbaikan typo keluar dalam hitungan menit, bukan hari.

Daftar Periksa Praktis untuk Tim Anda

Jika Anda baru pertama kali menyiapkan governance, mulailah dengan pertanyaan-pertanyaan ini:

• Apa saja kategori risiko untuk perubahan Anda? (rendah, sedang, tinggi)
• Pemeriksaan apa yang diperlukan untuk setiap kategori? (pengujian otomatis, code review, penyetuju spesifik)
• Siapa yang memutuskan kategori mana yang dimiliki suatu perubahan? (penulis, reviewer, sistem otomatis)
• Apa yang terjadi ketika perubahan menyebabkan masalah? (proses rollback, respons insiden)
• Seberapa sering Anda meninjau dan memperbarui aturan-aturan ini? (triwulanan, setelah insiden)

Menjawab pertanyaan-pertanyaan ini memberi Anda model governance yang berfungsi. Tidak perlu sempurna di hari pertama. Yang penting cukup jelas sehingga semua orang tahu apa yang harus dilakukan.

Intisari

Governance bukanlah penghalang kecepatan. Governance adalah hal yang memungkinkan Anda melaju kencang tanpa merusak kepercayaan. Ketika tim Anda tahu persis pemeriksaan apa yang dibutuhkan setiap perubahan, mereka berhenti menebak, berhenti menunggu, dan berhenti menghindari proses. Hasilnya adalah sistem yang melindungi pengguna dan kemampuan tim untuk mengirimkan perubahan.