Fitur Selesai Bukan Saat Pull Request Di-merge

Pull request sudah di-merge, pipeline hijau, dan halaman bisa dibuka. Dari sisi developer, pekerjaan terlihat selesai. Dari sisi orang yang harus memakai fitur itu besok pagi, belum tentu.

Apakah datanya benar? Apakah orang yang tepat punya akses? Kalau ada input keliru, bisa diperbaiki? Siapa yang dihubungi ketika prosesnya berhenti di tengah jalan?

Pertanyaan seperti ini relevan dengan pekerjaan saya sebagai Software Engineer dan IT Digitalization Staff di G-Tekt Indonesia Manufacturing. Saya menjadi developer utama DX-Platform, sistem internal untuk kebutuhan training karyawan, inspeksi produksi, sales, dan quality management. Pekerjaannya mencakup percakapan dengan pengguna, implementasi, pengujian, rilis, dan dokumentasi.

Di tulisan ini saya membahas cara menilai kesiapan sebuah fitur untuk dipakai, bukan membagikan proses internal perusahaan. Contoh alur di bawah bersifat ilustratif; tidak ada data operasional atau tangkapan layar sistem internal.

Sebelum membuka editor, pahami satu pekerjaan sampai selesai

Permintaan awal sering datang dalam bentuk solusi: “Bisa dibuatkan form?” atau “Tambahkan tombol export.” Masuk akal. Pengguna menjelaskan bagian yang terlihat menghambat pekerjaannya.

Tetapi form itu bagian dari proses yang lebih panjang. Ada orang yang mengisi, orang yang memeriksa, dan orang lain yang memakai hasilnya. Membuat halaman input tanpa memahami hubungan tersebut bisa memindahkan masalah dari kertas ke database.

Misalnya, sebuah tim meminta form pemeriksaan. Ini contoh, bukan spesifikasi fitur tertentu. Sebelum menentukan field, saya ingin pertanyaan berikut terjawab:

• Pemeriksaan dimulai karena apa, dan siapa yang mengerjakannya?
• Data mana yang harus tersedia sebelum pekerjaan dimulai?
• Setelah disimpan, siapa yang membaca atau menindaklanjutinya?
• Apa yang terjadi jika ada kesalahan, data belum lengkap, atau pekerjaan harus dibatalkan?
• Bagian mana yang perlu ditelusuri kembali saat muncul pertanyaan?

Jawabannya membantu membedakan kebutuhan data, aturan akses, dan alur koreksi. Baru setelah itu bentuk antarmukanya menjadi lebih jelas. Kadang solusi yang dibutuhkan memang form sederhana. Tidak semua permintaan perlu berubah menjadi workflow besar.

Sepakati bukti selesai, bukan daftar halaman

“Halaman sudah jadi” mudah dicentang, tetapi terlalu lemah untuk menjadi ukuran penerimaan.

Untuk contoh form tadi, bukti selesai bisa ditulis seperti ini:

Pengguna yang berhak dapat menyimpan hasil pemeriksaan yang valid, pemeriksa dapat menemukannya kembali, dan koreksi tercatat tanpa menghilangkan jejak perubahan yang diperlukan.

Kalimat itu belum menjadi test case lengkap, tetapi sudah lebih berguna daripada “CRUD selesai”. Ada pengguna, tindakan, aturan, dan hasil yang bisa diperiksa.

Saya ingin kriteria penerimaan cukup konkret untuk dicoba bersama pengguna. Untuk satu fitur, misalnya:

• Input valid tersimpan dan muncul pada daftar yang benar.
• Input yang belum lengkap ditolak dengan pesan yang menjelaskan perbaikannya.
• Pengguna tanpa wewenang tidak bisa membaca atau mengubah data tersebut, termasuk lewat API.
• Perubahan pada record mengikuti aturan koreksi yang disepakati.
• Data yang sama terbaca konsisten pada halaman detail dan laporan terkait.

Daftar ini harus mengikuti kebutuhan sebenarnya. Jika proses tidak memerlukan approval, jangan menambahkannya sekadar agar aplikasi terlihat lengkap.

Demo lebih awal saat arah masih mudah diubah

Ada asumsi yang sulit terlihat dari dokumen. Urutan kolom masuk akal bagi developer, tetapi berbeda dari urutan orang memeriksa barang. Istilah status tampak jelas di kode, tetapi memiliki arti lain bagi tim yang memakai aplikasi.

Demo versi kecil memberi kesempatan untuk menemukan perbedaan itu sebelum terlalu banyak bagian dibangun. Yang diperlihatkan tidak harus semua halaman. Satu alur yang bisa dicoba biasanya lebih berguna daripada banyak tampilan yang belum saling tersambung.

Dalam pekerjaan saya, prioritas pengembangan mengikuti arahan manajemen. Saya mendemokan fitur kepada pengguna dan memperbaikinya melalui percobaan serta masukan. Ada batas yang perlu dijaga: menerima masukan bukan berarti setiap ide harus langsung masuk ke rilis yang sama.

Saat muncul masukan, pisahkan:

• Alur yang salah: perilaku fitur tidak sesuai pekerjaan yang hendak dibantu.
• Kekurangan yang menghalangi penggunaan: misalnya data penting belum terlihat atau pesan kesalahan tidak menjelaskan tindakan berikutnya.
• Pengembangan berikutnya: berguna, tetapi tidak menghalangi tujuan rilis saat ini.

Pemisahan ini membantu tim memperbaiki masalah yang relevan tanpa terus menggeser arti “selesai”.

Uji juga pekerjaan lama yang bisa ikut terganggu

Fitur baru jarang berdiri sendiri. Perubahan pada status, relasi data, atau aturan akses dapat memengaruhi halaman yang tidak sedang dikerjakan.

Saya memikirkan pengujian dalam dua arah. Pertama, apakah perilaku baru sesuai kriteria penerimaan? Kedua, bagian lama apa yang mungkin berubah karena implementasi ini?

Untuk contoh pemeriksaan, jalur uji dapat mencakup penyimpanan data valid, penolakan data yang salah, izin akses pada API, pembacaan detail, dan laporan yang menggunakan record tersebut. Jika status baru memengaruhi filter, filter lama juga perlu diperiksa.

Pengujian otomatis membantu menjaga aturan yang berulang. Percobaan bersama pengguna menguji hal yang berbeda: apakah urutan tindakan dan informasi yang tampil cocok dengan pekerjaan mereka. Salah satunya tidak otomatis menggantikan yang lain.

Data uji pun perlu dipilih dengan sengaja. Nama panjang, field kosong yang memang boleh kosong, record lama, serta kombinasi status yang jarang muncul sering lebih berguna daripada lima baris data contoh yang semuanya rapi.

Siapkan jalan kembali sebelum merilis

Rilis bukan sekadar memindahkan kode terbaru ke server. Ada pertanyaan operasional yang perlu dijawab sebelum perubahan dipakai:

• Apakah perubahan membutuhkan migrasi skema atau penyesuaian data?
• Apakah versi lama masih bisa berjalan setelah migrasi tersebut?
• Apakah konfigurasi dan secret yang diperlukan tersedia di lingkungan tujuan?
• Bagaimana cara memeriksa satu alur penting setelah deployment?
• Jika pemeriksaan gagal, apakah harus rollback kode, memperbaiki ke depan, atau memulihkan data?

Rollback kode tidak selalu membatalkan perubahan database. Migrasi yang menghapus kolom atau mengubah arti data memerlukan rencana berbeda dari perubahan tampilan. Karena itu, “tinggal pakai image sebelumnya” bukan jawaban yang cukup untuk semua rilis.

Untuk sistem yang menyimpan data penting, backup juga perlu dapat dipulihkan. Saya membahas perbedaannya di tulisan Backup Belum Tentu Bisa Restore.

Setelah deployment, lakukan smoke test pada lingkungan tujuan. Periksa alur yang relevan dengan perubahan: masuk menggunakan akun uji yang sesuai, buka data, jalankan tindakan yang aman, lalu lihat hasilnya. Jangan menganggap proses yang hidup atau respons HTTP 200 sebagai bukti seluruh fitur bekerja.

Serah terima adalah bagian dari implementasi

Fitur akan dipakai saat developernya sedang mengerjakan hal lain. Dokumentasi perlu membantu orang di situasi tersebut.

Pengguna membutuhkan petunjuk untuk menyelesaikan pekerjaan. Tim teknis membutuhkan konteks untuk merawat sistem. Keduanya tidak harus membaca dokumen yang sama.

Panduan pengguna bisa singkat: siapa yang boleh melakukan tindakan, urutan pemakaian, arti status, cara memperbaiki kesalahan, dan kontak bantuan. Catatan teknis menyimpan alasan keputusan, perubahan konfigurasi, migrasi, langkah deployment, serta pemeriksaan setelah rilis.

Di proyek platform keanggotaan APMNU, kebutuhan dokumentasi dan handover juga menjadi bagian dari pekerjaan saya sebagai PM sekaligus developer. Sistem tidak berhenti pada implementasi API dan antarmuka; orang lain perlu memahami cara mengoperasikan serta melanjutkannya.

Checklist kecil sebelum menyebut fitur siap dipakai

Saya akan memakai pertanyaan berikut sebagai titik awal, lalu menyesuaikannya dengan risiko perubahan:

1. Pahami pekerjaan: pengguna, input, hasil, dan alur koreksi sudah jelas?
2. Sepakati bukti selesai: kriteria penerimaan bisa diperiksa bersama?
3. Demo dan perbaiki: asumsi penting sudah dicoba oleh pengguna?
4. Uji perubahan: perilaku baru dan alur lama yang terdampak sudah diperiksa?
5. Rilis dengan aman: migrasi, konfigurasi, smoke test, dan jalan pemulihan sudah dipikirkan?
6. Serahkan konteks: panduan, batasan, dan penanggung jawab sudah diketahui?

Tidak semua fitur memerlukan proses yang sama panjang. Mengganti label tombol tentu berbeda risikonya dengan mengubah perhitungan atau struktur data. Checklist ini membantu memilih pemeriksaan yang sesuai, bukan menambah upacara di setiap perubahan.

Pull request yang di-merge adalah satu langkah. Saya lebih nyaman menyebut sebuah fitur siap ketika orang yang dituju bisa menyelesaikan pekerjaannya dengan fitur itu, dan tim tahu apa yang harus dilakukan jika hasilnya tidak sesuai.