Sebelum Membangun Pipeline, Anda Perlu Tiga Hal Ini
Beberapa bulan lalu, saya duduk dalam rapat perencanaan di mana sebuah tim sangat antusias dengan pipeline CI/CD baru mereka. Mereka telah menghabiskan waktu berminggu-minggu mengonfigurasi alat, menulis file YAML, dan menyiapkan pengujian otomatis. Pipeline-nya hijau. Deployment-nya cepat. Semua orang merasa puas.
Lalu seseorang bertanya: "Apa sebenarnya yang ingin kita capai dengan semua ini?"
Ruangan menjadi hening. Beberapa orang berbicara tentang rilis yang lebih cepat. Yang lain menyebutkan lebih sedikit bug. Beberapa mengatakan ingin mengurangi pekerjaan manual. Tidak ada yang memiliki jawaban yang sama. Pipeline-nya berfungsi, tetapi tidak ada yang bisa menjelaskan seperti apa kesuksesan itu.
Tim itu telah membangun pipeline tanpa menjawab tiga pertanyaan fundamental terlebih dahulu. Dan itulah mengapa pipeline mereka, meskipun direkayasa dengan baik, tidak menyelesaikan masalah yang tepat.
Mulai dengan Mengapa: Business Outcome
Setiap upaya rekayasa membutuhkan tujuan. Tanpa tujuan, tim akan hanyut. Mereka membangun fitur yang tidak diminta siapa pun. Mereka mengoptimalkan proses yang tidak penting. Mereka mengukur hal-hal yang terlihat bagus di dashboard tetapi tidak memiliki hubungan dengan hasil nyata.
Business outcome bukanlah daftar fitur. Bukan juga spesifikasi teknis. Ini adalah hasil terukur yang berarti bagi orang-orang yang menggunakan produk Anda atau membayarnya.
Contoh business outcome:
- Pengguna baru dapat menyelesaikan registrasi dalam waktu kurang dari dua menit.
- Waktu pembuatan laporan bulanan turun dari tiga hari menjadi satu jam.
- Tiket dukungan pelanggan terkait masalah login berkurang 40 persen.
Perhatikan apa yang bukan contoh-contoh ini. Mereka bukan "kami akan mengimplementasikan OAuth" atau "kami akan migrasi ke Kubernetes." Itu adalah solusi teknis. Business outcome menggambarkan efek yang ingin Anda ciptakan, bukan bagaimana Anda berencana menciptakannya.
Ketika tim memiliki business outcome yang jelas, keputusan menjadi lebih mudah. Haruskah kami menambahkan fitur baru ini atau memperbaiki masalah stabilitas? Lihat business outcome-nya. Opsi mana yang mendekatkan pada tujuan? Tanpa jangkar ini, setiap tim mendefinisikan kesuksesan secara berbeda. Tim frontend mengukur waktu muat halaman. Tim backend mengukur latensi API. Tim platform mengukur uptime. Semua orang sibuk. Tidak ada yang selaras.
Petakan Alur: Value Stream
Setelah Anda tahu apa yang ingin dicapai, Anda perlu memahami bagaimana pekerjaan benar-benar mengalir dari ide ke pengguna. Inilah value stream Anda.
Value stream tidak sama dengan pipeline CI/CD. Pipeline adalah implementasi teknis. Value stream adalah perjalanan lengkap: dari saat seseorang menulis kode, melalui pengujian, pembangunan, peninjauan, persetujuan, deployment, verifikasi, dan akhirnya sampai ke pengguna yang mendapatkan nilai darinya.
Value stream juga mencakup hal-hal yang sering diabaikan pipeline:
- Proses peninjauan kode dan persetujuan
- Langkah verifikasi manual
- Waktu tunggu antar serah terima
- Umpan balik ketika terjadi kesalahan
- Overhead komunikasi antar tim
Memetakan value stream berarti mendaftar setiap langkah yang terjadi antara "kode ditulis" dan "pengguna mendapatkan nilai." Untuk setiap langkah, ajukan tiga pertanyaan:
- Apa yang dihasilkan langkah ini?
- Siapa yang terlibat?
- Bagaimana kita tahu apakah itu menambah nilai?
Banyak tim menemukan bahwa setengah dari langkah dalam value stream mereka tidak secara langsung berkontribusi pada business outcome. Langkah-langkah itu ada karena "begitulah cara kami selalu melakukannya." Rapat persetujuan mingguan yang tidak dihadiri siapa pun. Tanda tangan manual yang hanya formalitas. Fase pengujian yang menjalankan pemeriksaan yang sama dengan pipeline otomatis.
Langkah-langkah ini adalah pemborosan. Mereka memperlambat pengiriman tanpa meningkatkan kualitas. Ketika Anda melihatnya dalam value stream, Anda memiliki dua pilihan: hapus atau desain ulang.
Tetapkan Kepemilikan: Tim
Anda memiliki tujuan dan peta. Sekarang Anda butuh orang untuk bergerak.
Komponen tim adalah tentang siapa yang memiliki bagian mana dari value stream. Ini bukan tentang struktur organisasi atau garis pelaporan. Ini tentang kejelasan tanggung jawab.
Setiap langkah dalam value stream harus memiliki pemilik yang jelas. Pemilik itu tahu:
- Apa yang menjadi tanggung jawab mereka untuk hasilkan
- Bagaimana output mereka terhubung ke business outcome
- Siapa yang bergantung pada pekerjaan mereka
- Apa yang mereka butuhkan dari orang lain untuk melakukan pekerjaan mereka
Ketika tanggung jawab tidak jelas, celah muncul. Tim aplikasi menganggap deployment adalah pekerjaan tim infrastruktur. Tim infrastruktur menganggap deployment adalah pekerjaan tim aplikasi. Versi baru tertahan di staging selama berminggu-minggu karena tidak ada yang mengambil kepemilikan push akhir ke produksi.
Organisasi yang berbeda menata tim secara berbeda. Beberapa menggunakan tim fitur yang mencakup pengembang, QA, dan operasi dalam satu grup. Yang lain memiliki tim platform terpisah yang menyediakan infrastruktur dan alat untuk tim aplikasi. Tidak ada pendekatan yang secara inheren lebih baik. Yang penting adalah setiap bagian dari value stream memiliki pemilik yang disebutkan namanya, dan pemilik itu memahami bagaimana pekerjaan mereka berkontribusi pada business outcome.
Bagaimana Ketiganya Terhubung
Business outcome, value stream, dan tim tidak independen. Mereka membentuk sebuah sistem.
Diagram di bawah menunjukkan bagaimana ketiga elemen ini membentuk sistem yang mendorong desain pipeline.
- Business outcome memberikan arah. Tanpanya, tim membuat keputusan berdasarkan preferensi pribadi atau optimasi lokal.
- Value stream memberikan jalur. Tanpanya, tim tidak bisa melihat di mana penundaan dan pemborosan bersembunyi.
- Tim memberikan kapabilitas. Tanpa kepemilikan yang jelas, pekerjaan jatuh ke celah-celah.
Ketika salah satu dari ini hilang, yang lain kesulitan. Tim yang tidak tahu business outcome akan mengoptimalkan hal yang salah. Value stream yang tidak dipetakan akan menyembunyikan hambatan. Tim tanpa tanggung jawab yang jelas akan menciptakan penundaan serah terima dan saling menyalahkan.
Hanya setelah ketiga komponen ini jelas, Anda harus mulai berbicara tentang platform, pipeline, dan strategi deployment. Alat dan otomatisasi mempercepat proses. Tetapi jika prosesnya sendiri tidak selaras, percepatan hanya akan memperburuk keadaan lebih cepat.
Pemeriksaan Cepat Sebelum Membangun
Sebelum Anda mendesain pipeline berikutnya atau memilih alat deployment berikutnya, jalankan daftar periksa singkat ini dengan tim Anda:
- Dapatkah semua orang menyebutkan satu atau dua business outcome utama yang sedang dikerjakan tim Anda?
- Sudahkah Anda memetakan value stream lengkap dari kode ke pengguna, termasuk langkah manual dan waktu tunggu?
- Apakah setiap langkah dalam value stream itu memiliki pemilik yang jelas?
- Dapatkah setiap pemilik menjelaskan bagaimana pekerjaan mereka terhubung ke business outcome?
Jika ada jawaban tidak, perbaiki itu dulu. Pipeline bisa menunggu.
Intisari
Pipeline adalah alat. Strategi deployment adalah teknik. Tidak ada yang menggantikan kebutuhan akan kejelasan tentang apa yang ingin Anda capai, bagaimana pekerjaan mengalir untuk mencapainya, dan siapa yang bertanggung jawab untuk setiap bagian dari alur itu.
Mulai dengan business outcome. Petakan value stream Anda. Tetapkan kepemilikan yang jelas. Kemudian bangun pipeline yang melayani sistem itu, bukan sebaliknya.