Mengelola Technical Debt Tanpa Menunda Semuanya

Hampir setiap developer pernah dengar kalimat "nanti kita refactor" yang ujung-ujungnya tidak pernah terjadi. Technical debt itu nyata, dan di lingkungan kerja seperti sistem klinik atau rumah sakit yang saya geluti, tekanan untuk terus mengirim fitur baru sering membuat utang teknis hanya menumpuk di kepala, bukan di catatan. Masalahnya bukan karena tim malas, tapi karena tidak ada tempat yang jelas untuk menaruh "saya tahu ini kurang rapi, tapi belum sempat" selain memori masing-masing orang. Begitu orang itu resign atau lupa, utang itu jadi bom waktu yang tidak terlihat siapa pun sampai meledak.

Catat Dulu, Prioritaskan Belakangan

Langkah pertama yang paling sering dilewati adalah sekadar mencatat. Tidak perlu sistem rumit, yang penting konsisten. Saya biasa memakai kombinasi komentar kode dengan tag khusus dan issue tracker, misalnya:

// TODO(tech-debt): query ini N+1, perlu eager loading
// dampak: lambat saat data > 10rb baris, belum diukur presisi

Kuncinya, setiap catatan utang teknis idealnya punya tiga hal: apa masalahnya, kenapa dulu itu diputuskan begitu (biasanya karena deadline), dan perkiraan dampak kalau dibiarkan. Tanpa konteks "kenapa", catatan lama sering disalahartikan sebagai kesalahan orang, padahal itu keputusan sadar dengan trade-off waktu. Mencatat dulu, memprioritaskan belakangan, membuat kita tidak perlu memutuskan semuanya saat sedang terburu-buru mengejar rilis.

Prioritas Berdasarkan Risiko, Bukan Rasa Tidak Nyaman

Godaan terbesar saat punya daftar utang teknis adalah membereskan yang paling mengganggu secara estetika dulu, padahal itu belum tentu yang paling berisiko. Saya lebih suka menilai tiap item dari dua sumbu: seberapa sering bagian kode itu disentuh, dan seberapa besar dampak kalau ia gagal. Kode yang jarang disentuh dan dampaknya kecil bisa didiamkan bertahun-tahun tanpa masalah berarti. Sebaliknya, modul yang sering diubah tim lain dan menyentuh data sensitif, misalnya alur autentikasi atau proses yang menyentuh data pasien, layak diprioritaskan meski "kelihatannya" baik-baik saja.

Pendekatan praktis yang saya pakai: setiap kali ada perubahan fitur di suatu file, cek dulu apakah ada catatan utang teknis di file itu. Kalau ada, dan usaha untuk membereskannya kecil dibanding fitur yang sedang dikerjakan, selesaikan sekalian selagi konteksnya masih segar di kepala. Ini jauh lebih murah daripada menjadwalkan "sprint khusus tech debt" yang pada praktiknya sering digeser terus oleh prioritas bisnis.

Alokasikan Kapasitas Kecil Secara Konsisten

Menunggu momen ideal untuk membereskan utang teknis biasanya berarti menunggu selamanya, karena selalu ada fitur baru yang "lebih penting". Cara yang lebih realistis adalah mengalokasikan kapasitas kecil dan tetap, misalnya menyisakan sebagian kapasitas sprint khusus untuk item dengan risiko tertinggi di daftar, alih-alih menunggu proyek besar terpisah. Sebagai ilustrasi, sebagian tim menyisihkan sekitar 10-20% kapasitas per siklus kerja untuk ini, tapi angka pastinya tergantung ukuran tim dan seberapa kritis sistemnya, bukan angka baku yang harus ditiru mentah-mentah.

Yang lebih penting dari angka adalah kebiasaannya: pembahasan singkat soal daftar utang teknis di rapat rutin, supaya item berisiko tinggi tidak diam-diam terlupakan sampai jadi insiden produksi. Kebiasaan kecil dan konsisten jauh lebih tahan lama dibanding niat besar yang sekali jalan.

Intinya

Technical debt tidak akan pernah nol, dan itu wajar selama diakui dan dikelola secara sadar. Catat dengan konteks, prioritaskan berdasarkan risiko nyata bukan sekadar rasa tidak nyaman, dan alokasikan kapasitas kecil secara konsisten daripada menunggu "waktu yang tepat" yang tidak akan pernah datang.