Ada percakapan yang hampir selalu terjadi di setiap tim engineering:
Engineer ingin memperbaiki sesuatu. Sistem sudah mulai lambat, kode makin sulit di-maintain, atau ada celah keamanan yang belum ditangani. Tapi ketika dibawa ke diskusi prioritas, jawabannya hampir selalu sama: "nanti dulu, sekarang fokus ke fitur."
Dan di sisi lain, ada engineer yang menghabiskan sprint untuk refactoring yang tidak mengubah apapun dari perspektif user atau bisnis.
Keduanya bermasalah. Yang pertama mengabaikan hutang teknis sampai ia jatuh tempo dengan bunga. Yang kedua membuang kapasitas tim untuk kepuasan teknis yang tidak memberi nilai.
Pertanyaannya bukan "apakah improvement ini bagus secara teknis?" Pertanyaannya adalah: kapan sebuah improvement teknis layak diprioritaskan?
---
Satu Aturan Sederhana
Lakukan improvement kalau berdampak pada minimal salah satu dari tiga hal berikut:
Kalau sebuah improvement tidak bisa ditelusuri ke salah satu dari tiga itu, ia bukan prioritas — setidaknya bukan sekarang.
Ini bukan berarti improvement tersebut tidak penting. Tapi dalam bisnis yang sumber dayanya terbatas, setiap keputusan adalah trade-off. Dan trade-off yang baik membutuhkan kriteria yang jelas.
---
Increase Revenue: Ketika Masalah Teknis Menggerus Pendapatan
Tidak semua masalah teknis terlihat seperti masalah bisnis. Tapi beberapa di antaranya diam-diam mempengaruhi revenue — dan baru ketahuan setelah terlambat.
Contoh: sistem tidak punya rate limiting.
Tanpa rate limiting, bot bisa mengakses endpoint harga produk ratusan kali per menit. Kompetitor yang menggunakan bot semacam ini bisa memantau harga secara real-time dan melakukan undercutting otomatis — menurunkan harga mereka tepat di bawah hargamu setiap kali kamu update.
Ini bukan serangan teknis. Ini serangan bisnis yang dilakukan lewat celah teknis.
Memasang rate limiting bukan soal keamanan semata. Ini tentang melindungi keunggulan kompetitif — dan keunggulan kompetitif adalah fondasi revenue.
Cara menyajikannya ke stakeholder: "Tanpa ini, kompetitor bisa tahu perubahan harga kita dalam hitungan menit dan menyesuaikan harga mereka sebelum user kita sempat melihat penawaran terbaik."
---
Lowering Cost: Ketika Absennya Improvement Lebih Mahal dari Improvement-nya
Beberapa improvement terlihat seperti pengeluaran, padahal sebenarnya mereka mencegah pengeluaran yang jauh lebih besar.
Contoh: tidak ada backup database.
Bayangkan server crash. Tidak ada backup. Tim harus merekonstruksi data dari log, dari export parsial, dari ingatan. Proses itu bisa memakan waktu tiga hari kerja engineer senior.
Hitung biayanya: tiga hari × gaji harian engineer senior. Tambahkan opportunity cost — selama tiga hari itu, tidak ada fitur yang dikerjakan, tidak ada bug lain yang diperbaiki. Tambahkan lagi risiko data yang tidak bisa dipulihkan sepenuhnya.
Bandingkan dengan biaya backup otomatis: beberapa dolar per bulan untuk storage, satu hari engineer untuk setup awal.
Angka-angka ini tidak perlu presisi untuk menjadi argumen yang kuat. Bahkan estimasi kasar sudah cukup untuk membalik perspektif: "Kita sedang menghemat Rp 500 ribu per bulan dengan risiko kerugian Rp 50 juta sekali kejadian."
Lowering cost bukan hanya tentang infrastruktur yang lebih murah. Ini tentang menghindari biaya besar yang belum terjadi — tapi bisa terjadi.
---
Achieve Compliance: Ketika Regulasi Adalah Batas Minimum
Compliance sering diperlakukan sebagai formalitas — sesuatu yang dikerjakan karena harus, bukan karena ingin. Tapi cara berpikir itu berbahaya, karena regulasi bukan hanya soal audit. Ada denda, ada reputasi, dan kadang ada konsekuensi hukum.
Contoh: menyimpan data user tanpa enkripsi.
Kalau terjadi breach — baik karena serangan eksternal maupun kesalahan internal — dan data user tersebut bocor dalam bentuk plaintext, konsekuensinya bisa berlapis:
Di sini, risk dan compliance overlap langsung. Memperbaikinya bukan karena khawatir — tapi karena biaya tidak memperbaikinya sudah bisa dihitung, dan angkanya besar.
Cara menyajikannya ke stakeholder: "Regulasi mewajibkan enkripsi data user. Kalau terjadi breach dan kita tidak comply, fine-nya bisa melebihi total revenue kuartal ini."
---
Bagaimana dengan Risk?
Risk perlu menjadi pertimbangan tersendiri ketika dampaknya nyata tapi tidak bisa langsung ditelusuri ke uang atau regulasi — dan tidak ada yang memaksanya secara eksternal.
Contohnya: sistem tidak punya circuit breaker untuk third-party API. Kalau payment gateway tiba-tiba down, seluruh aplikasi ikut hang. Tidak ada revenue yang hilang sekarang, tidak ada compliance yang dilanggar, tidak ada fine yang mengancam. Tapi kalau terjadi, dampaknya bisa menghentikan bisnis selama berjam-jam.
Ini yang bisa disebut operational risk — risiko terhadap kemampuan bisnis untuk tetap beroperasi. Bukan soal profit atau compliance, tapi soal apakah bisnis masih bisa menjalankan tiga poin di atas sama sekali.
Dalam situasi ini, risk layak diperlakukan sebagai justifikasi keempat — tapi dengan satu syarat: dampaknya harus bisa dijelaskan secara konkret. Bukan "mungkin bisa jadi masalah", tapi "kalau terjadi, ini yang akan berhenti bekerja, dan ini estimasi dampaknya."
Risk yang tidak bisa dijelaskan konkret masih tetap penting untuk dicatat — tapi belum cukup kuat untuk menjadi prioritas.
---
Semua Masalah Perlu Diketahui, Tidak Semua Perlu Diselesaikan Sekarang
Ini perbedaan yang penting: mengabaikan masalah dan menunda masalah adalah dua hal yang berbeda.
Mengabaikan artinya tidak tahu atau tidak peduli. Menunda artinya tahu, sudah menimbang, dan memutuskan bahwa saat ini ada yang lebih mendesak — dengan risiko yang dipahami.
Tim yang sehat melakukan yang kedua. Mereka punya backlog teknis yang terlihat, dikategorikan, dan di-review secara berkala. Setiap item punya estimasi dampak. Ketika ada kapasitas, mereka bisa langsung memilih mana yang paling bernilai untuk dikerjakan — bukan hanya yang paling mengganggu secara teknis.
---
Sudah Lolos Filter — Lalu Urutkan Bagaimana?
Setelah improvement lolos filter tiga kategori tadi, masalah berikutnya muncul: ada lebih dari satu yang lolos. Mana yang dikerjakan duluan?
Di sinilah tiga pertanyaan lanjutan membantu:
Budget — apakah ada sumber daya untuk menyelesaikannya?
Sumber daya bukan hanya uang. Waktu engineer, kapasitas sprint, dan fokus tim semuanya adalah bentuk budget. Improvement yang paling berdampak pun tidak bisa dikerjakan kalau tidak ada yang bisa mengerjakannya sekarang.
Yang penting adalah jujur soal ini. Kalau budget tidak ada sekarang, jadwalkan — jangan biarkan mengambang tanpa kepastian. Improvement yang terus ditunda tanpa tanggal konkret biasanya tidak pernah dikerjakan.
Dampak — kalau tidak diselesaikan, apa yang terjadi?
Ini tentang besaran konsekuensi. Dua improvement bisa sama-sama masuk kategori "lowering cost", tapi satu mencegah kerugian Rp 1 juta dan satu lagi mencegah kerugian Rp 100 juta. Urutannya jelas.
Buat dampaknya konkret. Bukan "sistem bisa tidak stabil" — tapi "setiap bulan ada rata-rata X jam downtime yang bisa dicegah, dan setiap jam downtime artinya Y transaksi gagal." Angka yang kasar lebih berguna dari tidak ada angka sama sekali.
Urgensi — kapan dampak itu mulai terasa?
Dampak besar yang terasa lima tahun lagi tidak selalu lebih mendesak dari dampak kecil yang terasa bulan depan. Urgensi menentukan kapan kamu mulai membayar harga dari tidak mengerjakan improvement tersebut.
Tanda urgensi tinggi: masalah sedang aktif terjadi, ada deadline regulasi yang mendekat, atau ada kejadian pemicu (breach kecil, near-miss insiden) yang menunjukkan risiko bukan lagi hipotetis.
---
Cara menggunakan ketiganya bersama:
Bukan formula matematis — tapi kerangka percakapan. Ketika dua improvement bersaing untuk slot yang sama, tanyakan: mana yang budgetnya tersedia sekarang, mana yang dampaknya lebih besar, mana yang urgensinya lebih tinggi. Jawaban dari tiga pertanyaan itu biasanya cukup untuk membuat keputusan yang bisa dijelaskan ke siapapun.
---
Template Berpikir
Sebelum mengajukan improvement teknis ke stakeholder, jawab tiga pertanyaan ini:
1. Kalau tidak diperbaiki, apa yang terjadi? Jadikan konkret. Bukan "sistem jadi tidak stabil" — tapi "setiap minggu ada rata-rata X jam downtime yang bisa dicegah."
2. Masuk kategori mana? Revenue, cost, compliance, atau operational risk? Kalau tidak bisa dimasukkan ke salah satu, tanyakan kembali apakah ini prioritas atau sekadar preferensi teknis.
3. Berapa perbandingan biayanya? Biaya memperbaiki vs biaya tidak memperbaiki. Tidak harus presisi — estimasi yang jujur sudah jauh lebih baik dari tidak ada angka sama sekali.
Tiga pertanyaan ini mengubah percakapan dari "tolong percaya saya ini penting" menjadi "ini datanya, kita putuskan bersama."
Dan itu adalah percakapan yang jauh lebih produktif.