Mengelola Utang Teknis dengan DX dan AI

Setiap perusahaan, besar dan kecil, khawatir tentang utang teknis. Gartner memperkirakan bahwa sekitar 40% sistem infrastruktur memiliki masalah ini. Dalam survei CIO oleh McKinsey, hampir sepertiga merasa bahwa lebih dari 20% dari anggaran produk baru mereka digunakan untuk menyelesaikan masalah terkait utang teknis. Namun, tidak seperti yang banyak orang percaya, ini bukan hanya masalah pengkodean; ini juga masalah pengalaman pengembang (DX). Karena ketika pengembang harus bekerja dengan arsitektur yang tidak memadai, tooling yang ketinggalan, dan alur kerja pengembangan yang tidak memadai, produktivitas, kinerja, dan moral mereka menderita.

Memprioritaskan utang teknis dengan mempertimbangkan pengembang, fokus pada bagaimana mereka mendekati pekerjaan, alat apa yang mereka gunakan, dan kemajuan karir yang mereka dapatkan, membantu tim fokus dan mengirimkan lebih cepat. Ini adalah alasan mengapa cara perusahaan mengelola utang teknis berubah, didorong oleh DX dan fokus yang meningkat pada tooling yang ditenagai AI.

Mendukung DX

Cara pengembang sering kali diintegrasikan ke dalam tim meninggalkan banyak hal yang diinginkan. Mungkin membutuhkan beberapa minggu bagi seseorang untuk mulai berkontribusi pada proyek. Setelah mereka akhirnya dapat menambahkan fitur kecil atau patch, tidak jarang melihat layanan integrasi terus-menerus (CI) gagal karena sesuatu yang tidak terkait dengan perubahan yang mereka kerjakan. Ini pada dasarnya adalah kesalahan suite tes karena masalah kualitas yang buruk, dan pengembang tidak mengirimkan perubahan untuk membuat suite tes gagal. Ini adalah tes yang tidak stabil, tidak ditulis dengan baik, dan hanya berfungsi 90% dari waktu. Tim yang ada mungkin sudah terbiasa dengan itu – itu hanya memperlambat proses – tetapi tooling mungkin sudah ketinggalan dan merugikan bagi siapa pun di luar organisasi.

Ini adalah salah satu contoh dari banyak hal yang menghambat DX yang tepat. Salah satu cara untuk mencegah ini adalah dengan memiliki seorang juara yang ditunjuk di tim pengembangan dan rekayasa perangkat lunak. Banyak organisasi kecil tidak memiliki pemimpin DX, tetapi organisasi besar dan sukses memiliki. Mereka memantau hal-hal seperti berapa lama waktu yang dibutuhkan pengembang baru untuk mengatur lingkungan. Dan jika dua minggu terlalu lama, mereka mencari cara untuk memotong waktu itu menjadi setengahnya.

Ada tooling di luar sana untuk membantu, seperti CircleCI, dengan fitur bawaan yang akan melacak ketidakstabilan suite tes. Yang dibutuhkan adalah seseorang yang mengambil kepemimpinan dan berhenti setelah setiap sprint untuk mengatasi beberapa perubahan yang akan membuat kode lebih mudah dipertahankan dan bekerja di masa depan. Ini semua tentang memiliki pemimpin yang tertarik untuk membuat DX lebih baik. Untuk membuat itu terjadi, cari insinyur senior, didampingi oleh staf baru yang dapat memberikan umpan balik tentang kemungkinan celah.

Juga, IDC memperkirakan bahwa pasar otomatisasi pengujian perangkat lunak yang ditenagai AI akan terus tumbuh dengan CAGR 31,2% hingga 2027, jadi pastikan Anda menggunakan teknologi ini secara maksimal.

Metriks dan Tanda Peringatan

Ada banyak metriks yang dapat Anda lacak ketika mengevaluasi bagaimana utang teknis mempengaruhi tim Anda. Beberapa metriks dasar adalah “waktu untuk memperbaiki” atau “waktu untuk fitur.” Misalnya, Anda melihat bug dan tahu cara memperbaikinya. Beberapa alat dapat melacak waktu yang dihabiskan dari penulisan kode hingga produksi. Misalnya, Anda akan dapat melihat patch kecil yang membutuhkan dua hari bisnis untuk diperbaiki dan dikirim, ketika tim Anda perlu dapat melakukannya dalam beberapa jam. Anda juga dapat melacak rasio, seperti jumlah perbaikan bug versus fitur yang selesai.

Ada juga cara untuk mengidentifikasi ketika masalah moral mempengaruhi kinerja tim Anda. Pemimpin DX dapat menjalankan survei triwulanan untuk menentukan seberapa bahagia pengembang bekerja pada proyek atau bagian dari proyek. Mereka dapat mendalami dan bertanya tentang area spesifik seperti proses CI. Dan Anda selalu dapat melacak churn atau pergantian di tim Anda. Jika Anda melihat bahwa orang-orang terus meninggalkan, mereka mungkin merasa bahwa kekhawatiran mereka tidak didengar.

Tooling dengan AI

Munculnya tooling AI seharusnya membuat pengembang dan insinyur lebih produktif dan produk dikirim lebih cepat, tetapi utang teknis memperlambatkan ini. Misalnya, Anda menggunakan alat seperti GitHub atau Copilot untuk membantu dengan perubahan kode, kemudian mengirimkan permintaan tarik, dan CI membutuhkan beberapa jam untuk kembali kepada Anda. Sementara itu, apakah pengembang bekerja pada sesuatu yang lain? Periksa email? Ini adalah perubahan konteks dan pembunuh produktivitas.

Pengembang ingin bekerja pada produk di mana mereka dapat hanya fokus pada kode. Tooling ada untuk membantu mereka mendapatkan kode ke produksi, bukan menjadi penghalang konstan. AI dapat menyelamatkan waktu, tetapi itu tergantung pada tim rekayasa untuk menentukan standar mereka sendiri untuk kompleksitas yang dapat diterima. Untuk melakukan ini, pastikan terlebih dahulu bahwa setiap kode yang ditambahkan ke cabang utama memiliki tingkat utang teknis yang dapat diterima. Sebelum itu, lakukan diskusi terbuka dan dapatkan persetujuan dari tim rekayasa tentang ambang batas utang teknis dan kualitas kode yang dapat diterima. Pastikan bahwa semua orang tahu bahwa melebihi tanda itu memerlukan perbaikan segera. Setelah Anda menentukan standar tersebut, AI mulai berperan.

Ada kasus untuk agen AI dengan insinyur yang bertindak sebagai konduktor. Survei Capgemini dari 1.100 eksekutif di perusahaan besar telah menunjukkan bahwa 82% berencana untuk mengintegrasikan agen AI dalam tiga tahun ke depan, dan mereka sudah mempengaruhi masa depan pekerjaan. Anda mungkin melihat laporan bug dan melihat bahwa itu cukup kecil untuk ditangani oleh agen AI dari awal hingga tinjauan kode, menyelamatkan waktu tim Anda dan membebaskan mereka untuk menangani pekerjaan yang lebih kompleks. Namun, terkadang ketika kita mengikuti alat ini secara buta, ada trade-off yang AI kesulitan pertimbangkan.

Itu saatnya opini manusia menjadi faktor penentu.

Mengatur Utang Teknis dengan Tujuan

Bagaimana Anda mengatur pengurangan utang teknis dengan tujuan yang Anda coba capai atau hasil yang dapat diukur? Ini kembali ke utang teknis yang dapat diterima, dan terkadang dalam bisnis, Anda harus mengirimkan dengan cepat. Anda dapat melakukannya dengan mengetahui bahwa produk tidak skalabel, dan mungkin ada masalah kinerja seiring waktu. Seringkali, pengembang akan membuat catatan untuk kembali ke masalah ini nanti, ketika ada waktu untuk menanganinya, tetapi itu jarang terjadi. Dan ketika budaya yang buruk ini mengambil alih, di mana Anda harus terus mengirimkan besok, dampak utang menjadi sangat jelas.

Ini dapat dimengerti untuk sebuah startup, tetapi tidak untuk bisnis yang telah berjalan selama satu dekade. Anda perlu mulai mengubah budaya Anda lebih awal dan secara aktif untuk mengelola utang teknis; jika tidak, Anda akan menghabiskan banyak uang untuk memperbaiki bug produksi atau khawatir tentang keamanan dan kepatuhan.

Akhirnya, ada metriks untuk membantu mengkomunikasikan nilai refactoring atau membayar utang teknis kepada pemangku kepentingan. Waktu bisa menjadi salah satu, dari awal hingga produksi, atau dari membuka permintaan tarik hingga menggabungkan dan mengirimkannya ke produksi. Yang lain adalah waktu rata-rata untuk memperbaiki (MTTR). Dalam hal ini, Anda mungkin telah menemukan bug atau build yang rusak, dan Anda mengukur berapa lama waktu yang dibutuhkan tim Anda untuk memperbaikinya. Anda bisa melacak jumlah bug yang ada di produksi juga. Jika Anda melihat bahwa jumlah itu meningkat, mungkin ada masalah terkait utang teknis.

Utang Teknis dengan Bunga

Setiap organisasi dapat menghabiskan beberapa jam setiap minggu untuk meningkatkan DX mereka untuk membantu mengurangi utang teknis. Jika tidak, Anda mungkin akan membayarnya nanti, kemungkinan dengan kinerja yang lambat, penurunan kecepatan pengembangan yang signifikan, atau masalah keamanan. Misalnya, tim insinyur dan pengembang Anda mungkin telah menunda upgrade ke Ruby on Rails selama satu dekade. Tiba-tiba, biaya proyek meningkat setengah juta dolar karena versi Ruby yang empat generasi di belakang, meninggalkan Anda dengan sejumlah besar kode dan ketergantungan yang ketinggalan.

Jika Anda telah mengupgrade secara bertahap, Anda tidak akan berada dalam situasi ini. Jadi, dukung tim pengembangan perangkat lunak Anda dan bayar saat Anda pergi. Jika tidak, utang teknis itu akan kembali menimpa Anda, dengan bunga.