Belajar Technical Product Manager - Technical Debt & Quality
Mengelola technical debt sebagai produk: definisi presisi dan analogi bunga, kuadran deliberate-reckless, menetapkan budget debt vs feature, debt register dengan metafora interest, dan kapan quality justru adalah fitur yang dijual
#Pendahuluan
Setelah di episode 9 kita belajar menerjemahkan permintaan "tambahkan AI" menjadi fitur fraud alert yang bisa dieval, episode ini membahas harga diam-diam dari setiap rilis cepat: technical debt. Di NusaPay, engineer sering protes "kode settlement sudah rapuh", sementara sales terus menuntut fitur baru — dan TPM-lah arbiter antara keduanya.
Kenapa debt adalah isu produk, bukan hanya isu engineering? Karena dampaknya selalu berujung ke metrik produk: fitur makin lambat keluar, insiden makin sering, dan engineer terbaik resign karena mual memelihara kode zombie. Debt yang tidak dikelola adalah hipotek yang cicilannya dibayar oleh roadmap kalian.
#Definisi Presisi: Hutang dan Bunga
Analoginya klasik tapi efektif: ambil jalan pintas (kode cepat-jadi) = pinjam uang; setiap pekerjaan berikutnya yang tersulitkan oleh jalan pintas itu = bunga. Definisi operasional yang kita pakai:
Technical debt adalah keputusan desain masa lalu yang hari ini menaikkan biaya perubahan atau risiko kegagalan, dan yang kita tahu cara memperbaikinya.
Definisi ini penting karena memfilter dua hal yang sering salah label: kode jelek yang tidak mengganggu siapa pun (bukan prioritas debt) dan sistem tua yang berfungsi baik (bukan debt — itu aset). Fokus kalian adalah area dengan bunga aktif: tempat velocity squad turun terukur.
Cara mengukur bunganya secara pragmatis:
- Berapa % sprint yang habis untuk bug di area itu?
- Berapa lama rata-rata menambah fitur kecil di modul itu vs modul sehat?
- Berapa insiden 90 hari terakhir yang root cause-nya di sana?
Angka-angka ini mengubah debat "engineer bilang kodenya buruk" menjadi diskusi biaya yang bisa diputuskan.
#Kuadran Debt: Deliberate-Reckless
Semua debt tidak sama moralnya. Kuadran klasik Martin Fowler memberi kosakata untuk mendiskusikannya:
| Prudent (disadari) | Inadvertent (tidak sadar) | |
|---|---|---|
| Deliberate (sengaja) | "Kita rilis MVP pakai monolith; refactor saat PMF" | — |
| Reckless (ceroboh) | "Tidak sempat test, kirim saja" | "Apa itu idempotency?" |
Debt deliberate-prudent adalah alat strategi: NusaPay sengaja menunda split service settlement demi kecepatan MVP. Debt reckless adalah kegagalan proses. TPM yang baik membiarkan jenis pertama dan memusnahkan jenis kedua — misalnya dengan definition of done yang mencakup test dan observability.
Note
Saat mewarisi codebase baru, tanyakan pada tim: "keputusan masa lalu mana yang saat itu rasanya masuk akal?" Jawabannya membedakan debt prudent dari recklessness — dan menentukan nada percakapan kalian: hormat pada konteks, atau evaluasi proses.
#Feature vs Debt Budget
Cara paling tahan banting mengelola debt adalah budget persentase kapasitas: misalnya 15-20% kapasitas sprint dialokasikan permanen untuk debt & reliability, sisanya feature.
Kelebihan pendekatan budget:
- Tidak perlu memenangkan debat setiap sprint; alokasinya sudah keputusan tetap.
- Manajemen mudah memahaminya ("20% investasi pemeliharaan") versus daftar refactor abstrak.
- Fleksibel saat darurat: kuartal dengan migrasi besar bisa naik ke 30%, dengan kesepakatan eksplisit turun lagi setelahnya.
Variabel yang perlu kalian kalibrasi: produk muda bisa 10%, platform enterprise yang menjual SLA bisa 25% ke atas karena reliability adalah bagian dari janji jual. Yang tidak boleh: 0%. Tim tanpa budget debt hanya menunda pembayaran dengan bunga majemuk.
#Debt Register: Inventaris yang Bisa Diputuskan
Sama seperti risk register di episode 3, debt wajib terinventaris. Format register NusaPay:
| ID | Item debt | Bunga (dampak kini) | Biaya bayar | Opsi | Keputusan |
|---|---|---|---|---|---|
| TD-1 | Settlement batch single-thread | Fitur T+0 terbatas; bug fix rata-rata +3 hari | 6 minggu | Bayar penuh / patch lokal | Patch dulu, bayar penuh Q4 |
| TD-2 | Ledger tanpa event replay | Investigasi insiden lambat | 3 minggu | Bayar Q3 | Masuk budget 20% |
| TD-3 | Test coverage dashboard 30% | Risiko regresi visual | 2 minggu | Terima risiko | Terima; revisit saat UI besar |
Kolom keputusan adalah yang membedakan register dari daftar keluhan: setiap baris berakhir di salah satu dari empat opsi — bayar sekarang, bayar nanti (terjadwal), bayar sebagian (mitigasi), atau sengaja tidak dibayar dengan risiko yang dipahami. Semua sah, asalkan sadar.
#Kapan Quality Adalah Fitur
Ada momen ketika "bayar debt" bukan biaya internal melainkan fitur jualan:
- Enterprise buyer mengaudit stabilitas dan riwayat insiden kalian sebelum kontrak — reliability jadi syarat masuk pasar (episode 20).
- API latency p99 yang konsisten adalah argumen penjualan langsung ke developer.
- Compliance (PCI, PDP) menuntut kualitas tertentu yang tidak bisa dinegosiasikan (episode 14, 19).
Dalam situasi itu, framing kalian ke manajemen berganti: bukan "kita perlu refactor", melainkan "kita perlu memenuhi requirement pasar bernilai X". Quality berhenti jadi biaya dan mulai jadi investasi masuk pasar.
#Praktik: Susun Debt Register Payments Core
Wawancarai (atau bayangkan) tim engineering NusaPay, lalu susun register 5-8 item dengan kolom di atas. Untuk tiap item, tentukan bunga aktifnya dengan data — jumlah sprint terbuang, insiden, atau fitur tertunda — dan ajukan usulan budget 15% vs 25% beserta alasannya. Simpan di 05-quality/debt-register.md.
#Anti-Pattern Pengelolaan Debt
Tiga pola yang tampak masuk akal tetapi gagal berulang:
- "Debt week" tahunan: satu pekan pembersihan besar lalu lupa setahun. Bunga debt bekerja harian; perawatannya harus harian juga lewat budget permanen.
- Refactor tanpa metrik bunga: menyetujui refactor besar hanya karena "kode sudah jelek", tanpa data dampak. Hasilnya kapasitas habis dan manajemen kehilangan kepercayaan pada permintaan debt berikutnya.
- Debt disembunyikan dari stakeholder: mencatat semua di backlog engineering saja. Saat insiden datang, tidak ada konteks kenapa risiko itu diterima — dan TPM terlihat lalai padahal sebenarnya hanya diam.
Antidot ketiganya sama: register yang hidup, angka bunga yang jujur, dan keputusan yang ditulis di tempat stakeholder bisa melihatnya.
#Penutup
Inti yang harus dibawa pulang:
- Debt adalah keputusan masa lalu yang hari ini menaikkan biaya perubahan/risiko — ukur bunganya dengan data sprint dan insiden, bukan perasaan.
- Kuadran deliberate-reckless memberi bahasa untuk membedakan trade-off bijak dari ceroboh.
- Tetapkan budget debt permanen (15-20%) dan kalibrasi naik-turunnya per kuartal; 0% adalah pinjaman gelap.
- Debt register mengubah keluhan menjadi keputusan: bayar, jadwal, mitigasi, atau terima risiko.
- Saat quality menjadi syarat pasar (enterprise, compliance), reframing-nya sebagai fitur, bukan biaya.
Di episode 11 selanjutnya kita bahas proyek paling berisiko dalam hidup sebuah platform: Migration & Platform Initiatives — kenapa big bang migration gagal, pola strangler fig, dual-write dan shadow traffic, cutover plan, serta cara menjual migration ke stakeholder sebagai investasi produk. Sampai jumpa!