"Kurang Lebih": Frasa Paling Berbahaya (dan Berguna) dalam SDLC
I am an enthusiastic researcher and developer with a passion for using technology to innovate in business and education.
Sebagai developer, kita hidup dalam dunia biner: true atau false, 1 atau 0. Namun, saat berhadapan dengan manajemen proyek atau klien, kita sering terjebak dalam zona abu-abu bernama "Kurang Lebih."
Mungkin terdengar sepele, tapi dalam Software Development Life Cycle (SDLC), frasa ini adalah bom waktu jika tidak dikelola dengan benar. Mari kita bedah anatomi "kurang lebih" di setiap tahapan proyek.
Shutterstock
1. Inisialisasi: "Kurang Lebih Kayak Aplikasi X"
Saat kick-off, klien sering berkata: "Kita ingin fiturnya kurang lebih seperti Instagram."
Analisis Developer:
Ini adalah red flag terbesar. "Kurang lebih" di sini berarti Scope Creep. Tanpa dokumentasi yang presisi, fitur "sederhana" bisa membengkak menjadi sistem kompleks yang tidak masuk dalam budget awal.
Tips: Ubah "kurang lebih" menjadi User Stories yang konkret. Jika mereka bilang "Kurang lebih seperti X", segera buat daftar Must-have dan Nice-to-have.
2. Perencanaan: "Kira-kira Selesai Kurang Lebih 2 Minggu"
Ini adalah tahap di mana kita melakukan estimasi. Di sini, "kurang lebih" adalah bentuk Manajemen Risiko.
Analisis Developer:
Kita tahu ada faktor "X" seperti technical debt, API pihak ketiga yang down, atau bug yang sulit dilacak. Di sini, kita menggunakan estimasi untuk memberikan ruang bernapas (buffer).
Pro Tip: Jangan hanya bilang "kurang lebih". Gunakan Cone of Uncertainty. Semakin awal tahap proyeknya, rentang "kurang" dan "lebih"-nya harus semakin lebar. Gunakan formula estimasi yang lebih saintifik daripada sekadar tebakan insting.
3. Eksekusi: "Kodenya Sudah Kurang Lebih Beres"
Pernah mendengar rekan setim (atau diri sendiri) bilang: "Kodenya sudah jalan, kurang lebih sesuai requirement"?
Analisis Developer:
Dalam fase eksekusi, frasa ini adalah tanda Technical Debt. Artinya:
Unit test mungkin belum lengkap.
Edge cases belum ditangani.
Dokumentasi? Nanti saja.
Risiko: Jika "kurang lebih" ini lolos ke production, bersiaplah untuk on-call di jam 2 pagi karena ada bug yang tidak terduga.
4. Penutupan: "Hasilnya Kurang Lebih Sudah Oke, Kan?"
Saat demo atau UAT (User Acceptance Testing), frasa ini muncul sebagai upaya negosiasi untuk segera deployment.
Analisis Developer:
Ini adalah fase Definisi Selesai (Definition of Done/DoD). Di tahap ini, "kurang lebih" tidak boleh ada. Sebuah fitur harus memenuhi kriteria:
Lolos QA.
Lolos Review Code.
Sesuai dengan spesifikasi awal.
Kesimpulan: Kapan Harus Menggunakan "Kurang Lebih"?
"Kurang lebih" adalah alat komunikasi, bukan standar teknis.
Gunakan "Kurang Lebih" saat berdiskusi tentang estimasi waktu atau visi kasar di awal proyek untuk memberi fleksibilitas.
Haramkan "Kurang Lebih" saat menulis kode, menentukan kriteria keberhasilan, dan membuat kesepakatan fitur.
Sebagai developer, tugas kita adalah mengubah "kurang lebih" dari sisi bisnis menjadi instruksi if-else yang absolut bagi mesin. Karena bagi server kita, tidak ada yang namanya "kurang lebih" dalam eksekusi perintah.
Apakah Anda punya pengalaman buruk (atau lucu) gara-gara frasa "kurang lebih" ini dalam proyek? Share di kolom komentar ya!
