Teknik Borç Nedir? Türleri, Ölçümü, Önceliklendirme ve Ödeme Rehberi

Yazılım ekibi her yeni isteğe "bunu yapmak eskisinden uzun sürüyor" demeye başladıysa, küçük bir değişiklik beklenmedik yerde hata çıkarıyorsa ya da kimse belirli bir modüle dokunmak istemiyorsa, büyük ihtimalle teknik borçla karşı karşıyasınız. Teknik borç nedir sorusunun kısa cevabı şudur: bugün hızlı çıkmak için seçilen ya da farkında olmadan birikmiş, yarın her değişikliği yavaşlatan yazılım kararlarının toplamı.

Bu rehberde teknik borcun ne olduğunu, bilinçli ve bilinçsiz biçimlerini, türlerini, iş diliyle nasıl ölçüleceğini, neyin önce ödeneceğini, ödemenin geri dönüşünü, yeniden yazma ile iyileştirme arasındaki farkı ve yönetime nasıl anlatılacağını işliyoruz. Örnek rakamlar temsilîdir; bir sektör ortalaması ya da gerçek proje verisi değildir.

Teknik Borç Nedir?

Teknik borç, yazılımda daha kolay ya da hızlı olan çözümün seçilmesi sonucu ileride yapılması gereken ek işin yükünü anlatan bir benzetmedir. Kavram finans diliyle çalışır: ana para, borcu yaratan kısayoldur; faiz, o kısayol yüzünden her değişiklikte ödenen ek zamandır; ödeme ise kısayolu düzgün çözümle değiştirmektir.

Benzetmenin işe yarayan tarafı şudur: borç her zaman kötü değildir. Pazara iki ay erken çıkmak için bilinçli bir kısayol seçmek, faiz hesaplanıp geri ödeme planlandıysa savunulabilir. Sorun, borcun görünmemesi ve faizin hiç hesaplanmamasıdır. Yazılımın genel yapısını ve hangi katmanlardan oluştuğunu özel yazılım nedir rehberimizde anlattık; borç bu katmanların her birinde birikebilir.

Okumanızı öneririz: Özel yazılım hizmetimiz

Bilinçli ve Bilinçsiz Teknik Borç Arasındaki Fark Nedir?

Bilinçli borç bir karardır, bilinçsiz borç ise bir sonuçtur. İkisi de aynı faizi işletir ama yönetimi farklıdır.

• Bilinçli borç: "Bu sürümde testsiz çıkalım, sonraki sprintte ekleyelim" gibi gerekçesi bilinen, sınırı ve ödeme tarihi konuşulan erteleme. Yazılı kaydı varsa borç yönetilebilir.
• Bilinçsiz borç: Gereksinimin yanlış anlaşılması, ekibin deneyimsizliği, kopyala-yapıştır alışkanlığı ya da proje büyürken yapının zorlanması gibi, kimsenin karar vermediği birikim. Genellikle projenin ortasında fark edilir.

Bilinçsiz borcun büyük bölümü, ihtiyaç baştan net yazılmadığı için doğar. Gereksinimin nasıl yazıya dökülüp kapsamın nasıl sabitleneceğini gereksinim analizi rehberimizde anlattık. Ayrıca zamanla ortaya çıkan bir borç türü daha vardır: yazıldığında doğru olan kararın, iş büyüyünce yetersiz kalması. Bu bir hata değildir, ama aynı biçimde faiz işletir.

Teknik Borç Türleri Nelerdir?

Borcu sınıflandırmak, ödeme planı yapmayı kolaylaştırır; çünkü her türün faizi farklı yerde görünür.

Test borcunun nasıl kapatılacağını yazılım testi rehberimiz, mimari borcun bir yüzü olan parçalama kararını ise mikroservis mimarisi yazımız ele alıyor.

Teknik Borç Nasıl Ölçülür?

Teknik borcun tek bir doğru ölçüsü yoktur; işe yarayan yaklaşım, faizi iş diliyle görünür kılan birkaç basit göstergeyi izlemektir. Kod satırı ya da "kalite puanı" tek başına yönetime anlam taşımaz.

• Kapasite payı: Sprint kapasitesinin ne kadarı borcun yarattığı işe gidiyor? Formül: borç kaynaklı iş ÷ toplam kapasite. Örnekte 12 ÷ 40 = %30; yeni işe 28 puan kalıyor.
• Değişiklik süresi: Küçük bir isteğin talepten yayına kadar kaç gün sürdüğü. Örnekte aynı büyüklükteki istek bir yıl önce 2 günde, bugün 6 günde çıkıyor.
• Hatalı yayın oranı: Sorun çıkaran yayınların toplam yayına oranı. Örnekte 30 yayından 6'sı sorun çıkardı: 6 ÷ 30 = %20.
• Kaçınılan işler: Ekibin "dokunmayalım" dediği modül sayısı. Sayılabilir bir göstergedir ve korkunun haritasını çıkarır.

Puanı parayla ifade etmek için bir dönüşüm gerekir. Temsilî ekip beş kişidir ve sprint iki haftadır: 5 × 10 iş günü = 50 kişi-gün, kapasite 40 puan. Yani 1 puan = 50 ÷ 40 = 1,25 kişi-gün. 12 puan = 15 kişi-gün; günlük ₺9.000 ile faiz her sprintte 15 × ₺9.000 = ₺135.000 eder.

Hangi Teknik Borç Önce Ödenir?

Önce, en çok faiz işleten borç ödenir; büyüklüğüne ya da kodun çirkinliğine göre değil. Pratik bir ölçü, etkiyi sıklıkla çarpmaktır. Etki ve sıklık 1 (düşük) ile 3 (yüksek) arasında puanlanır.

Eşikler de temsilîdir: 6 ve üzeri hemen planlanır, 3–5 planlı bir sprintte ele alınır, 2 ve altı izlenir. Güvenlik açığı gibi etkisi aniden yükselen kalemler bu tablonun dışında, öncelikli ele alınır. Etki puanı verirken bayi portalı gibi iş açısından kritik akışlara dokunan kalemleri yüksek tutun.

Teknik Borcu Ödemenin Geri Dönüşü Nasıl Hesaplanır?

Geri dönüş, ödemenin maliyetini her sprintte kurtarılan faize bölerek bulunur. Önce ödemenin maliyetini, sonra ödeme sonrası azalan faizi tahmin edin.

Örnekte fiyat hesabını tek yerde toplayıp teste bağlamak 12 kişi-gün sürüyor: 12 × ₺9.000 = ₺108.000. Bu iş borç kaynaklı yükü 12 puandan 9 puana indiriyor; yani sprint başına 3 puan kurtuluyor: 3 × 1,25 = 3,75 kişi-gün × ₺9.000 = ₺33.750.

• Geri dönüş süresi: ₺108.000 ÷ ₺33.750 = 3,2 sprint, yani yaklaşık 4 sprint (8 hafta).
• Altı ayda (13 sprint): 13 × ₺33.750 = ₺438.750 kurtarılır; ödeme maliyeti çıkınca net kazanç ₺438.750 − ₺108.000 = ₺330.750.
• Kapasite etkisi: Borç payı 9 ÷ 40 = %22,5'e iner; yeni işe giden kapasite 28 puandan 31 puana çıkar. 3 ÷ 28 ≈ %10,7 artış.

Bu hesap bir yazılım projesinin maliyetini kurgulama biçimine benzer; efor, belirsizlik payı ve günlük ücret mantığını yazılım projesi maliyeti rehberimizde ayrıntılı anlattık. Kendi hesabınızda ölçülmüş kapasiteyi ve gerçek günlük ücreti kullanın; kurtarılacak puanı iyimser tahmin etme riski vardır, bu yüzden ilk ödemeden sonra gerçek değeri ölçün.

Teknik Borç Nasıl Ödenir?

En güvenli yol, borcu sürekli ve küçük parçalarla ödemektir. Her sprintte kapasitenin %15–20'sini planlı borç ödemeye ayırmak yaygın bir uygulamadır; bu oran tavsiye edilen bir başlangıç noktasıdır, evrensel bir kural değildir. Kapasite 40 puan ise %20 = 8 puan eder. Yukarıdaki 12 kişi-günlük iş 12 ÷ 1,25 = 9,6 puandır; yani 8 puanlık payla 1,2 sprintte, pratikte iki sprintte biter.

Sürekli ödemenin avantajı, işin yeni özelliklerle birlikte yürümesi ve her adımda faizin düştüğünün görülmesidir. Büyük bir "borç temizliği" sprinti ya da yeniden yazma projesi ise yeni işi durdurur ve kendi riskini taşır.

1. Kaydet: Borcu tek bir listede tutun: ne, nerede, neden oluştu, hangi faizi işletiyor.
2. Ölç: Kapasite payı, değişiklik süresi ve hatalı yayın oranını izleyin.
3. Önceliklendir: Etki × sıklık puanıyla sıralayın.
4. Planla: Seçilen kalemi sprinte, yeni işle birlikte kapasite payı içinde koyun.
5. Öde: Küçük adımlarla yapın; her adımda sistem çalışır durumda kalsın.
6. Doğrula: Faizin gerçekten düştüğünü aynı göstergelerle kontrol edin.

Yeni Teknik Borç Birikmesi Nasıl Önlenir?

Borcu sıfırlamak mümkün değildir, ama kontrolsüz birikmesi önlenebilir. Üç alışkanlık en çok işe yarar.

• Bitti tanımı: "Bitti" yalnızca "çalışıyor" demek olmasın; test yazıldı, gözden geçirildi ve gerekli belge güncellendi maddelerini içersin.
• Kod gözden geçirme: Her değişiklik, yazan dışında biri tarafından okunur. Kopya kod ve açıklanmamış kısayollar burada yakalanır.
• Otomatik testler: Değişiklik başına otomatik çalışan testler, hatalı yayın oranını düşürür ve ekibe cesaret verir.
• Borç kaydı: Bilinçli bir kısayol seçildiğinde, ödeme tarihiyle birlikte yazılır. Kayıtsız kısayol, bilinçsiz borca dönüşür.

Bu alışkanlıkların hangi aşamada devreye girdiğini yazılım geliştirme süreci rehberimiz aşama aşama anlatıyor.

Yeniden Yazmak mı, İyileştirmek mi Gerekir?

Çoğu durumda parça parça iyileştirmek (refactoring) daha güvenlidir; yeniden yazma ancak mevcut yapı gerçekten sürdürülemez olduğunda düşünülür. Karar için şu karşılaştırma işe yarar.

Temsilî bir karşılaştırma: beş modüllü bir uygulamada her modülün iyileştirilmesi 12 kişi-gün ise toplam 5 × 12 = 60 kişi-gün = ₺540.000 eder. Aynı uygulamanın baştan yazılması 150 kişi-gün olarak tahmin ediliyorsa 150 × ₺9.000 = ₺1.350.000'dir. Yeniden yazmada eski sistemin gizli kuralları tahmini büyütebilir; bu yüzden karar öncesinde yapıyı gerçekten sürdürülemez kılan nedenin yazılı olması gerekir. Kararı kod beğenisi değil, ölçülen faiz vermelidir.

Teknik Borç Yönetime Nasıl Anlatılır?

Yönetime "kodu temizlemek istiyoruz" demek yerine, faizi para ve zaman olarak anlatın. İşe yarayan anlatım üç cümledir: ne kadar kaybediyoruz, ödemek ne kadar sürüyor, ne zaman geri dönüyor.

• Kayıp: "Kapasitemizin %30'u, sprint başına yaklaşık ₺135.000, düzeltme ve geçici çözüme gidiyor."
• Maliyet: "Fiyat hesabını tek yerde toplamak 12 kişi-gün, yani ₺108.000."
• Geri dönüş: "Yaklaşık 8 haftada kendini öder; altıncı ayda net ₺330.000'in üzerinde kazanç sağlar."

Bu rakamlar temsilîdir; sizin sunumunuzda ölçülmüş değerler kullanılmalıdır. Ayrıca sürekli bir bakım düzeni kurmak da borcun biriktiği hızı düşürür; kapsam ve hizmet süreleri için bakım ve destek sözleşmesi rehberimize bakabilirsiniz.

Teknik Borçta Sık Yapılan Hatalar Nelerdir?

• Borcu hiç kaydetmemek: Görünmeyen borç öncelik alamaz ve yönetime anlatılamaz.
• Büyüklüğe göre öncelik vermek: En büyük ya da en çirkin kalem değil, en çok faiz işleten kalem önce ödenir.
• Tek seferde temizlemeye çalışmak: Yeni işi durdurup büyük temizlik yapmak çoğunlukla ertelenir ya da yarım kalır.
• Ödemeyi ölçmemek: Ödeme sonrası göstergeler değişmediyse, doğru kalem ödenmemiş olabilir.
• Her kısayolu suçlamak: Bilinçli, kayıtlı ve geri ödeme planı olan kısayol meşrudur.
• Yeniden yazmayı ilk çözüm saymak: Yapı çalışıyorsa parça parça iyileştirme çoğu zaman daha az risklidir.

Okumanızı öneririz: MVP nedir? Minimum uygulanabilir ürün nasıl belirlenir, kapsam nasıl puanlanır?

İnovabil ile Sürdürülebilir Özel Yazılım

İnovabil olarak ağırlığımız sıfırdan, firmaya özel yazılım geliştirmektir: özel yazılım, ERP, CRM, e-ticaret, web, mobil ve entegrasyon. Süreç sayfamızda kayıtlı adımlarımız analiz, tasarım, geliştirme, test, yayın, bakım ve destektir; borcun biriktiği yer çoğu zaman bu adımların atlandığı ya da sıkıştırıldığı noktadır. Mevcut bir yazılımınızın bakımı zorlaştıysa, önce hangi kalemin ne kadar faiz işlettiğini birlikte ölçmeyi öneririz.

Avcılar İnşaat için CRM, satın alma ve mobil; İZBAN için satın alma sistemi; Karyak için lojistik ve sevkiyat planlama ile toptan sipariş yönetimi; Sleepy için depo yönetimi ile şikâyet ve destek yönetim sistemi geliştirdik. Yazılımınızın durumunu kısaca anlatan bir özet gönderin; değişiklik süresi ve kapasite payı üzerinden yazılı bir değerlendirme çıkaralım.

Okumanızı öneririz: Yazılım geliştirme sürecimiz: analizden yayına adım adım

Sık Sorulan Sorular