Teknik Borç Yönetimi: Envanterden Önceliklendirmeye

Teknik borç yönetimi ne demektir?

Teknik borç, bugün hızlı çıkmak için seçilen ya da zamanla birikmiş yazılım ve altyapı eksikliklerinin, ileride değişikliği yavaşlatan ve riskli kılan maliyetidir. Metafor finansal borçtan gelir: bilinçli alınan borç hızlı teslimat sağlar, ama faiz öder. Faiz; yavaşlayan geliştirme, artan hata, zor devreye alma ve bilgiyi yalnızca birkaç kişinin taşıması olarak ödenir.

Teknik borç yönetimi, bu borcu ortadan kaldırmaya çalışmak değil, görünür kılmak, etkisini ölçmek ve hangi borcun ne zaman ödeneceğine bilinçli karar vermektir. Hiç borcu olmayan yazılım nadirdir. Sorun, borcun görünmez birikmesi ve kararların sezgiyle, en yüksek sesle konuşana göre verilmesidir. Yönetimin hedefi, ekibin teslimat hızını sürdürürken borcun kontrol altında kalmasını sağlamaktır.

Borç türlerini ayırt edin

Her eksik aynı borç değildir. Ayrım, doğru müdahaleyi seçmenizi sağlar. • Kod borcu: karmaşık, tekrarlı, test edilmemiş ya da okunması zor kod • Mimari borç: değişimi zorlaştıran sıkı bağlı yapılar, uygun olmayan sınırlar • Altyapı ve araç borcu: eski sürümler, manuel dağıtım, kırılgan ortamlar, güncellenmemiş bağımlılıklar • Test ve otomasyon borcu: yetersiz otomatik test, kararsız hatlar • Dokümantasyon ve bilgi borcu: yazılı olmayan kararlar, bir kişide kalan bilgi • Güvenlik borcu: yamalanmamış bileşenler, zayıf erişim denetimi

Bir de niyete göre ayrım yapılabilir: bilinçli ve gerekçeli alınan borç ("önce çıkalım, sonra düzeltiriz") ile bilinçsizce birikenler (ihmal, bilgi eksikliği, aceleyle yazılmış kod). Bilinçli borcun mutlaka ödeme planı olmalıdır; plansız bilinçli borç kısa sürede bilinçsiz borca dönüşür.

Envanter: borcu görünür kılmak

Önceliklendirmenin ilk adımı, borcun listelenmesidir. Envanter; geliştiricilerin yaşadığı sürtünmeden, kod gözden geçirmelerden, olay incelemelerinden ve statik analiz araçlarının bulgularından beslenir. Ekipte basit bir kayıt alışkanlığı kurmak işe yarar: bir geliştirici bir alanda yavaşladığında ya da kısa yol seçtiğinde bunu borç kaydı olarak ekler.

Her kayıtta şunlar bulunmalıdır: • Borcun kısa tanımı ve konumu (modül, servis, bileşen) • Neden oluştuğu ve ne tür olduğu • Günlük işi nasıl etkilediği • Ödenmezse ne olacağı • Tahmini düzeltme eforu ve bağımlılıkları

Envanteri bir kerelik temizlik listesi değil, sürekli güncellenen bir iş kalemi havuzu olarak düşünün. Borcun ekip içindeki ortak kaydı ürün iş listesinin yanında durmalı, ayrı bir gizli listede kalmamalıdır.

Etki ölçümü: faizi nasıl görürsünüz?

Borcun maliyetini kanıtlayamazsanız önceliklendiremez ve savunamazsınız. Etkiyi ölçmek için doğrudan ve dolaylı göstergeler kullanılır: • Değişim sıklığı: sık değişen bir alanda borç, daha çok faiz öder • Teslimat süresi: bu alandaki bir değişikliğin fikirden canlıya ne kadar sürdüğü • Hata ve olay geçmişi: hataların ve kesintilerin hangi bölgelerde yoğunlaştığı • Geliştirici deneyimi: kurulum süresi, yeni üyenin ilk katkıya ulaşma süresi, ekip anketlerindeki şikâyetler • Risk: güvenlik açığı, destek dışı kalan bileşen, kişiye bağımlılık

Bu göstergeler mutlak sayı gerektirmez; ekibin kendi geçmişiyle karşılaştırması ve eğilim izlemesi yeterlidir. Bir hata kaydı yığınının hep aynı modülden gelmesi ya da bir bileşene dokunan her işin tahminden uzun sürmesi, borcun faizinin somut kanıtıdır.

Önceliklendirme: nelere önce dokunulur?

Her borcu ödemek ne mümkündür ne de doğrudur. Önceliklendirmede şu ölçütleri birlikte değerlendirin: ödenmezse yaratacağı etki (faiz) ve düzeltmenin maliyeti. Etkisi yüksek, maliyeti düşük borçlar hemen ödenir. Etkisi yüksek ama pahalı olanlar bir yol haritası ve dilimlere bölünmüş plan gerektirir. Etkisi düşük ve pahalı olanlar bilinçli olarak ertelenir, hatta hiç ödenmez.

Ek ölçütler: iş hedefleriyle hizalanma (yakında yeni özellik geliştirilecek alandaki borç önceliklidir), güvenlik ve uyumluluk riski, hatanın çarpan etkisi ve başka işleri bloke edip etmediği. "Dokunduğunuz yerde iyileştirin" ilkesi küçük borçlar için etkilidir: bir alanda iş yaparken çevresini bir miktar temizlemek ayrı iş açmaz. Büyük mimari borçlar ise bağımsız bir iş olarak planlanmalı ve kademeli ilerlemelidir; "her şeyi baştan yazalım" önerileri çoğunlukla riskli ve pahalıdır.

Kapasite modelleri ve müzakere

Borç ödemek için zaman ayrılmazsa liste yalnızca uzar. Yaygın modeller: her iterasyonda kapasitenin belirli bir bölümünü borca ayırmak, belirli dönemleri iyileştirmeye adamak ya da borç işlerini özellik işleriyle aynı iş listesinde sıralamak. Hangisinin uygun olduğu ekibin ve ürünün durumuna göre değişir; önemli olan, ayrılan payın korunması ve acil işlere sürekli feda edilmemesidir.

Yönetime anlatırken teknik terimleri iş diline çevirin. "Kod kirli" yerine "bu modüldeki her yeni özellik daha uzun sürüyor ve canlıya çıkarken olay riski yüksek" deyin. Seçenekleri maliyetleriyle sunun: borcu şimdi ödemek, kademeli ödemek ya da ertelemek ne anlama gelir? Erteleme meşru bir seçimdir, yeter ki sonuçları bilinsin ve kayıt altına alınsın. Anlaşılan kapasite ve hedefler yazılı olursa sonraki dönemde yeniden pazarlık gerekmez.

İzleme ve sık hatalar

Borç yönetimi bir defalık bir proje değil sürekli bir alışkanlıktır. Envanteri düzenli gözden geçirin, ödenen borçların etkisini ölçerek faydayı kanıtlayın ve yeni borcun nasıl oluştuğunu inceleyin. Kod gözden geçirme ölçütleri, otomatik test ve statik analiz kuralları, yeni borcun girişini azaltan önlemlerdir.

Sık hatalar: • Borcu görünür kılmadan şikâyet etmek • Her şeyi aynı önemde saymak ya da tümünü ödemeyi hedeflemek • Etkiyi ölçmeden önceliklendirmek • Yönetimle teknik dilde konuşmak • Borç ödemeyi "boş zamanlara" bırakmak; boş zaman gelmez • Büyük yeniden yazım projelerine girişmek ve iş değeri üretmeden aylarca ilerlemek • Ödenen borcun etkisini raporlamamak, böylece bir sonraki talep için dayanak oluşturmamak

Mindset programlarında teknik borç

Mindset'in Teknik Borç ve Altyapı Yatırımlarının Önceliklendirilmesi eğitimi şu modüllerden oluşur: teknik borcun doğası, envanter ve etki ölçümü, önceliklendirme ve kapasite modelleri, müzakere ve izleme.

Modül sırası, bu konudaki doğal iş akışını izler: önce borcu tanımak, sonra görünür kılıp ölçmek, ardından sırayla ele alıp yönetimle uzlaşmak.