# "Kurang Lebih": Frasa Paling Berbahaya (dan Berguna) dalam SDLC

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.

![Software Development Life Cycle diagram, AI generated](https://encrypted-tbn1.gstatic.com/licensed-image?q=tbn:ANd9GcSCpsDVXnFqKbvqAJPAJtvA_wMzID3NQb_WgqjDoPte0lldywIz3_wHfQBqJBYjLmJnTdLvzIhQ9bWigX_RyGsNB_21ESpcr6Pala95ImZ6N2J9fnA align="center")

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:

1.  Lolos QA.
    
2.  Lolos Review Code.
    
3.  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!**