Siapa yang Menentukan Apa yang Benar-Benar Sampai ke Pengguna

Pipeline Anda sudah berfungsi. Tes lulus. Build hijau. Tombol deployment ada di depan mata, tinggal diklik. Tapi tidak ada yang menekannya.

Kenapa? Karena seseorang harus memutuskan apakah versi tertentu ini benar-benar layak sampai ke pengguna. Keputusan itu bukan teknis. Ini adalah keputusan produk dan koordinasi. Dan jika tidak diambil dengan jelas, pipeline Anda hanya akan berputar-putar tanpa hasil.

Dua peran menangani keputusan ini: product manager dan release manager. Mereka bukan orang yang sama, dan pekerjaan mereka juga berbeda. Tapi bersama-sama, mereka menjawab pertanyaan yang tidak bisa dijawab oleh sistem CI/CD Anda: "Haruskah ini dirilis sekarang?"

Product Manager Menentukan Apa yang Dibangun

Product manager tidak menulis kode atau menjalankan pipeline. Tugas mereka adalah memahami apa yang benar-benar dibutuhkan oleh pengguna dan bisnis, lalu menerjemahkannya menjadi pekerjaan untuk tim engineering. Dalam konteks CI/CD, peran ini penting bahkan sebelum satu baris kode pun ditulis.

Product manager memutuskan fitur mana yang masuk ke sprint berikutnya, mana yang ditunda, dan mana yang dibatalkan sama sekali. Keputusan itu secara langsung memengaruhi kelancaran pengiriman Anda.

Jika product manager memprioritaskan fitur yang terlalu besar, tim engineering akan kewalahan dan jadwal rilis molor. Jika prioritas terlalu sering berubah, developer membuang pekerjaan yang sudah setengah jadi. Product manager yang baik memahami bahwa prioritas bukan hanya soal "apa yang paling penting." Tetapi juga soal "apa yang benar-benar bisa diselesaikan dan dirilis dalam waktu yang realistis."

Di sinilah product manager dan sistem CI/CD saling berinteraksi. Pipeline yang cepat tidak ada gunanya jika tim terus-menerus mengerjakan hal yang salah. Tugas product manager adalah memastikan pipeline diisi dengan pekerjaan yang terdefinisi dengan baik, lingkupnya tepat, dan selaras dengan kebutuhan pengguna.

Release Manager Mengkoordinasikan Kapan Rilis Dilakukan

Release manager adalah orang yang mengoordinasikan kapan dan bagaimana sebuah rilis benar-benar terjadi. Terkadang ini adalah peran khusus. Terkadang peran ini dirotasi di antara engineer DevOps atau tech lead. Fungsinya tetap sama: memastikan semua orang siap sebelum sebuah versi masuk ke produksi.

Apa yang sebenarnya dikoordinasikan oleh release manager?

Pertama, jadwal rilis. Apakah tim menggunakan jadwal tetap, misalnya setiap Kamis jam 2 siang? Atau mereka rilis begitu fitur selesai? Kedua pendekatan bisa berhasil, tetapi release manager memastikan semua orang tahu jadwal mana yang berlaku.

Kedua, kesiapan teknis. Apakah semua perubahan sudah digabungkan ke branch utama? Apakah semua tes hijau? Apakah migrasi database sudah dijalankan di staging? Pemeriksaan ini terdengar mendasar, tetapi sering terlewat ketika semua orang menganggap orang lain sudah menanganinya.

Ketiga, komunikasi. Apakah tim support tahu akan ada perubahan? Apakah tim marketing siap jika fitur baru membutuhkan pengumuman? Rilis yang mengejutkan tim lain akan menciptakan kekacauan, meskipun kodenya sempurna.

Release manager juga memimpin keputusan go/no-go. Ini adalah momen ketika semua orang berkumpul, seringkali dalam obrolan singkat atau rapat cepat, dan memutuskan apakah rilis dilanjutkan atau ditunda. Jika bug kritis baru saja ditemukan, release manager berkata "tahan dulu." Jika semuanya terlihat aman, release manager memberikan lampu hijau.

Bagaimana Kedua Peran Ini Bekerja dengan Tim Engineering

Product manager dan release manager tidak bekerja sendiri. Mereka terus-menerus berinteraksi dengan tim engineering.

Product manager berbicara dengan developer untuk memahami seberapa besar usaha yang dibutuhkan sebuah fitur. Sebuah fitur yang terdengar sederhana bagi orang non-teknis bisa memakan waktu berminggu-minggu. Product manager membutuhkan masukan itu untuk membuat keputusan prioritas yang realistis.

Release manager berbicara dengan QA untuk mengetahui apakah pengujian sudah memadai. Mereka berbicara dengan DevOps untuk mengetahui apakah infrastruktur siap untuk versi baru. Mereka berbicara dengan product manager untuk mengetahui apakah penundaan pada satu fitur memengaruhi rencana rilis secara keseluruhan.

Di tim yang matang, interaksi ini menjadi lebih lancar karena praktik seperti feature flags. Dengan feature flags, product manager dapat mengontrol fitur mana yang aktif untuk pengguna mana tanpa harus menunggu jadwal rilis. Release manager juga merasa lebih sedikit tekanan karena kode sudah ada di produksi, meskipun belum aktif.

Tetapi feature flags bukanlah solusi ajaib. Mereka tetap membutuhkan koordinasi. Flag yang menumpuk tanpa dibersihkan menjadi utang teknis. Product manager dan release manager perlu melacak flag mana yang ada, mana yang aktif, dan mana yang bisa dihapus.

Peran Ini Bukan Penghalang

Mudah untuk melihat product manager dan release manager sebagai penghalang. Developer ingin mengirimkan kode. Pipeline sudah siap. Mengapa harus menunggu seseorang untuk mengatakan "ya"?

Tetapi peran ini ada untuk mencegah pekerjaan yang sia-sia. Bayangkan developer membuat kode selama berhari-hari, hanya untuk mengetahui bahwa fitur tersebut tidak sesuai dengan kebutuhan pengguna. Atau bayangkan tim siap untuk deploy, tetapi tim marketing belum menyiapkan pengumuman. Kedua situasi ini membuang usaha dan menciptakan frustrasi.

Product manager mencegah skenario pertama dengan memastikan tim membangun hal yang benar. Release manager mencegah skenario kedua dengan memastikan organisasi siap menerima versi baru.

Daftar Periksa Praktis untuk Product dan Release Manager

Jika Anda menjalani salah satu peran ini, atau jika Anda bekerja dengan orang-orang di peran ini, berikut adalah daftar periksa singkat untuk menjaga kelancaran pengiriman:

• Sebelum sprint planning: Pastikan fitur terdefinisi dengan baik dan lingkupnya realistis. Jika terlalu besar, pecah menjadi lebih kecil.
• Sebelum kode ditulis: Bicaralah dengan developer tentang estimasi usaha. Jangan berasumsi sebuah fitur kecil hanya karena terdengar sederhana.
• Sebelum merge: Verifikasi bahwa semua perubahan sudah di-review dan diuji. Jangan biarkan "nanti kita perbaiki" menjadi kebiasaan.
• Sebelum hari rilis: Pastikan tim support, marketing, dan tim lain tahu bahwa rilis akan terjadi. Kejutan menyebabkan kekacauan.
• Sebelum go/no-go: Periksa hasil tes, status migrasi, dan masalah yang diketahui. Jika ada yang tidak jelas, tunda.
• Setelah rilis: Lacak feature flags mana yang masih aktif. Bersihkan sebelum siklus rilis berikutnya.

Intisari

Pipeline yang cepat tidak ada gunanya jika fitur yang salah sedang dibangun atau jika organisasi belum siap menerimanya. Product manager dan release manager tidak ada untuk memperlambat Anda. Mereka ada untuk memastikan bahwa ketika Anda menekan tombol, itu benar-benar berarti sesuatu.