Setiap pemilik bisnis tempat saya bekerja pada akhirnya menanyakan pertanyaan yang sama: mengapa fitur yang biasanya memakan waktu dua minggu kini membutuhkan waktu dua bulan. Jawaban jujurnya hampir tidak pernah "para pengembang menjadi lebih buruk". Hutang teknis yang dijelaskan dalam satu kalimat adalah sebagai berikut: ini adalah akumulasi biaya pintasan yang diperlukan perangkat lunak Anda untuk dikirimkan lebih cepat, dan seperti pinjaman apa pun, ia membebankan bunga hingga seseorang membayarnya.

Analogi pinjaman sering digunakan, dan ini merupakan titik awal yang baik, tetapi analogi ini kurang menjual masalahnya. Pinjaman memiliki jadwal tetap dan tingkat bunga yang diketahui. Utang teknis bertambah secara tidak terduga, dan tingkat suku bunga akan naik semakin lama Anda mengabaikannya, karena setiap fitur baru dibangun di atas bagian yang goyah. Anda tidak mendapatkan pernyataan melalui pos yang memberitahukan saldonya. Anda mengetahuinya ketika perubahan "kecil" secara diam-diam menyentuh dua belas file yang tidak diingat oleh siapa pun.

Saya ingin menjelaskan cara membaca gejala di sistem Anda sendiri, karena sebagian besar pemilik hanya memperhatikan utang ketika sudah mahal.

Seperti Apa Sebenarnya Hutang Teknis Sehari-hari

Lupakan metafora sejenak dan lihat perilakunya. Ini adalah petunjuk yang saya cari ketika saya diminta menilai basis kode perusahaan:

  • Setiap perubahan kecil membutuhkan waktu berminggu-minggu. Permintaan yang terdengar seperti "tambahkan saja filter ke laporan ini" berubah menjadi proyek multi-minggu karena logika filter diduplikasi di enam layar tanpa sumber kebenaran yang sama.
  • Satu pengembang tidak tergantikan. Jika tim Anda mengatakan "hanya Budi yang dapat menyentuh modul faktur", itu bukan pujian bagi Budi, itu adalah tanda bahaya. Artinya logika sistem ada di kepala seseorang, bukan di dokumentasi atau struktur yang bersih.
  • Bug muncul kembali setelah diperbaiki. Ini biasanya berarti logika yang sama disalin dan ditempel di beberapa tempat, sehingga perbaikan di satu tempat tidak menjangkau tempat lain.
  • Pegawai baru membutuhkan waktu berbulan-bulan untuk menjadi produktif. Sistem yang bersih dapat dijelaskan dalam satu sore. Sistem yang penuh utang memerlukan pengetahuan suku yang membutuhkan waktu berbulan-bulan untuk diserap.
  • Tidak seorang pun ingin menyentuh file tertentu. Jika teknisi Anda menghindari bagian dari basis kode seperti Anda menghindari kerabat tertentu di pertemuan keluarga, perubahan pada bagian tersebut memerlukan biaya yang besar dan semua orang mengetahuinya.

Jika Anda mengenali lebih dari dua hal ini, Anda tidak melihat adanya ketidaknyamanan kecil. Anda sedang mempertimbangkan pajak untuk setiap fitur masa depan yang ingin Anda buat.

Hutang Sehat vs. Jenis Hutang yang Membunuh Peta Jalan

Tidak semua utang teknis itu buruk, dan memperlakukan semuanya sebagai keadaan darurat adalah kesalahannya sendiri. Ada perbedaan nyata antara utang yang Anda ambil dengan sengaja dan utang yang terakumulasi karena kelalaian.

Utang yang sehat terlihat seperti ini: Anda mengirimkan MVP dengan cepat untuk menguji pasar sebelum merekayasa pasar secara berlebihan, Anda melakukan hardcode pada suatu nilai karena Anda memiliki tiga pelanggan dan perlu belajar dari mereka sebelum membuat konfigurasi untuk ribuan pelanggan, atau Anda melewatkan pengujian otomatis pada fitur yang ingin Anda buang dalam sebulan. Ini adalah hutang dengan rencana. Anda tahu berapa utang Anda dan kapan Anda akan membayarnya.

Utang yang mematikan peta jalan terlihat berbeda: tidak ada yang memutuskan untuk mengambil jalan pintas, hal ini terjadi karena tidak ada tekanan waktu untuk memikirkannya, atau tenggat waktu memaksa peretasan yang tidak dapat diperbaiki oleh siapa pun. Tidak ada yang mencatat kejadiannya, jadi tidak ada yang melacak saldonya. Dan hal ini semakin bertambah, artinya setiap fitur baru yang ditambahkan sejak itu telah membuat lebih banyak kode di atas bagian yang goyah, membuatnya lebih mahal untuk diperbaiki setiap kuartal yang Anda tunggu.Tes yang saya gunakan dengan klien: dapatkah CTO atau teknisi utama Anda memberi tahu Anda, dalam bahasa sederhana, pintasan apa yang ada dan berapa biaya untuk memperbaikinya? Jika ya, Anda memiliki tanggung jawab terkelola. Jika jawabannya adalah mengangkat bahu, Anda mempunyai api yang belum disadari. Ini adalah perbedaan yang sama yang saya bahas lebih mendalam di [Penjelasan Utang Teknis untuk Pemilik Bisnis] (/blog/technical-debt-explained-for-owners) dari sudut desain sistem, jika Anda menginginkan kerangka teknis yang lebih dalam.

Pertanyaan untuk Ditanyakan kepada Tim Anda Kuartal Ini

Anda tidak perlu membaca kode untuk mengelola ini. Anda perlu mengajukan pertanyaan yang tepat dan memperhatikan ketika jawabannya menjadi tidak jelas.

  1. "Jika saya menanyakan [fitur tertentu yang masuk akal], berapa lama waktu yang dibutuhkan, dan mengapa?" Jawaban yang meyakinkan dan spesifik dengan alasan yang jelas adalah hal yang sehat. Jeda panjang yang diikuti dengan "tergantung" tidaklah tepat.
  2. "Bagian sistem mana yang takut untuk kita sentuh?" Setiap tim teknik mempunyai jawaban yang jujur ​​jika Anda bertanya langsung daripada bertanya "apakah semuanya baik-baik saja".
  3. "Apa yang terjadi jika [pengembang utama] mengambil cuti sebulan?" Ini menunjukkan seberapa terkonsentrasi risiko Anda.
  4. "Kapan terakhir kali kita sengaja membayar utang?" Jika jawabannya "tidak pernah", Anda mengumpulkan bunga tanpa rencana pembayaran nol.
  5. "Berapa kerugian yang harus ditanggung, dalam beberapa minggu, dari tiga jalan pintas terburuk dalam sistem ini?" Tim yang tidak pernah menghitung hal ini belum memprioritaskannya, yang berarti hal ini akan terus berkembang tanpa terlihat.

Berapa Biayanya Secara Nyata

Untuk jaringan ritel skala menengah tempat saya bekerja di Tangerang, polanya seperti yang biasa terjadi: sistem tempat penjualan yang dibangun dengan cepat lima tahun sebelumnya telah menduplikasi logika penetapan harga di seluruh admin web, aplikasi seluler, dan skrip pelaporan. Kampanye promo yang seharusnya memakan waktu seminggu untuk diluncurkan membutuhkan waktu enam minggu, karena aturan penetapan harga harus diperbarui di tiga tempat oleh tiga orang berbeda, dan pengujian harus mencakup ketiganya secara terpisah. Perbaikannya bukanlah penulisan ulang. Itu mengkonsolidasikan logika penetapan harga ke dalam satu layanan yang disebut oleh ketiga sistem. Proyek ini memakan waktu sekitar enam minggu dan terbayar dalam dua siklus kampanye karena setiap promo di masa depan dikurangi menjadi beberapa hari, bukan berminggu-minggu.

Itulah dampak sebenarnya dari hutang yang tidak dikelola: ini bukan tagihan tunggal, ini adalah pajak permanen atas kecepatan Anda. Dan kecepatan biasanya menjadi hal yang membedakan Anda dari pesaing yang mengirim lebih cepat. Jika Anda ingin melihat bagaimana kesenjangan kompetitif tersebut terjadi secara nyata, [Bisnis Tradisional Kalah dari Saingan Digital Pertama] (/blog/traditional-business-losing-digital-competitors) membahasnya secara langsung.

Kesimpulan: Kelola Saldo, Jangan Hanya Takut

Hutang teknis bukanlah kegagalan moral dan bukan sesuatu yang dapat Anda hilangkan seluruhnya, bisnis mana pun pasti mengalaminya. Apa yang membedakan perusahaan yang bertahan cepat dengan perusahaan yang terhenti adalah apakah seseorang secara aktif melacak saldo dan membayarnya dengan sengaja. Ajukan lima pertanyaan di atas pada kuartal ini kepada tim Anda. Jika jawabannya tidak jelas, ketidakjelasan tersebut adalah masalah sebenarnya, lebih dari sekedar kode tertentu. Dapatkan opini kedua jika Anda membutuhkannya; pembacaan teknis dari luar mengenai beban utang nyata sistem Anda adalah jenis percakapan yang layak dilakukan sebelum peluncuran fitur besar berikutnya, dan jenis keterlibatan seperti itulah yang saya lakukan melalui ervandra.com/partner.