Teknik Borç Kaydı (Technical Debt Register): Bakım Sprint’lerine Nasıl Entegre Edilir?

Teknik borç, “kötü yazılmış kod”la sınırlı değildir. Bazen hızlı çıkmak için alınan kısa yol, bazen güncellenmeyen bağımlılık, bazen de kırılgan bir modülün “dokunmaya korkulan” hale gelmesidir. Doğru tanım; borcun gelecekteki iş maliyetini artıran ve risk üreten bir birikim olmasıdır. Bu yüzden teknik borç önceliklendirme, modern web bakımının planlanabilir bir parçası olarak ele alınmalıdır.

Teknik borcun tipik kategorileri

• •Kod/ mimari borç: kırılgan modüller, karmaşık bağımlılıklar, kötü sınırlar
• •Dependency borcu: eski kütüphaneler, güvenlik yamaları gecikmiş paketler
• •UI/UX borcu: eski komponentler, responsive sorunlar, tasarım tutarsızlıkları
• •Operasyon borcu: yetersiz izleme, eksik runbook, manuel deploy adımları
• •SEO/performans borcu: CWV düşüklüğü, teknik SEO açıkları, ağır medya yükü

Ne değildir?

• •“Beğenmedim” türü kişisel tercih listesi
• •İş hedefiyle ilgisi olmayan “mükemmeliyetçilik”
• •Kapsamı belirsiz, ölçülemez “yeniden yazalım” önerileri

Soru : Teknik borç nedir, nasıl tespit edilir?

Cevap: Teknik borç; ilerideki değişiklik maliyetini artıran ve riski yükselten birikimdir. Tespit için; tekrar eden bug’lar, yavaş release döngüsü, kırılgan modüller, eski bağımlılıklar, performans/SEO regresyonları ve yüksek incident oranları gibi sinyaller izlenir. Özellikle refactoring stratejisi ve teknik borcun teknik SEO etkisi birlikte düşünülmelidir.

Debt register; borcun envanteridir. Her kalem; açıklama, etki, efor, öncelik, durum ve sahiplik ile tanımlanır. Buradaki amaç Excel/Notion tartışması değil; “tek doğru kaynak” oluşturup karar aldırmaktır.

Minimum alan seti (register)

• •Debt item (kısa başlık)
• •Açıklama + kanıt (hata örnekleri, ölçüm, incident linki)
• •Etki (Impact) — 1–5
• •Efor (Effort) — 1–5
• •Öncelik (Impact×Effort veya ağırlıklı skor)
• •Durum (backlog / planned / in progress / done)
• •Sahip (owner) + hedef sprint/ tarih
• •Risk etiketi (security / revenue / UX / SEO)

Debt kalemini “iyi yazma” kuralı

• •1 cümle: ne?
• •1 cümle: neden problem? (etki)
• •1 cümle: önerilen çözüm yönü
• •1 satır: kanıt/ölçüm

Teknik borç tartışmalarını bitiren şey; ortak bir puanlama dilidir. Etki×efor matrisi, “çok önemli” gibi soyut ifadeleri karar seviyesine indirir.

Impact (1–5) nasıl verilir?

• •5: gelir/rezervasyon/ödeme akışını etkiliyor veya güvenlik riski yüksek
• •3: ekip verimini düşürüyor, tekrar eden bug üretimi var
• •1: kozmetik veya nadir senaryo

Effort (1–5) nasıl verilir?

• •5: büyük refactor, çok modül etkisi, yüksek test yükü
• •3: orta büyüklükte düzenleme, sınırlı alan
• •1: küçük düzeltme, düşük risk

Öncelik hesabı

Basit model: Impact ÷ Effort veya Impact×(risk katsayısı) gibi uyarlanabilir. Ama kural net olmalı: “yüksek etki / düşük efor” hızlı kazanımdır.

Soru : Borçları nasıl önceliklendirip bakım sprint’lerine dahil ederim?

Cevap: Debt register’daki her kalemi impact ve effort ile puanlayın; yüksek etki-düşük efor kalemlerini önceleyin. Sonra her sprint’te sabit bir kapasiteyi (ör. %10–20) borç azaltmaya ayırıp kalemleri sprint planına alın ve kapanış kriteriyle kapatın.

Debt register tek başına yetmez; sprint kapasitesi ve roadmap ile bağlanmadıkça “dilek listesi” olur. Özellikle bakım sprintlerinde teknik borca yer açmak yaklaşımı netleşmeden borç kalemleri hep ertelenir. Burada iki ana kural iş görür:

1. Her sprint’te borca sabit kapasite
2. Büyük borç kalemleri için roadmap slotu

Sprint kapasite kuralı: “X% borca”

Örnek kural: Her sprint kapasitesinin %10–25 arası borç kalemlerine ayrılır. Oran; ürün hızına, incident yoğunluğuna ve ekip büyüklüğüne göre değişir.

Bakım sprint tasarımı (pratik)

• •Sprint başı: quick win borç kalemleri (1–3 iş)
• •Sprint ortası: bir orta ölçek borç kalemi
• •Sprint sonu: ölçüm/raporlama + register güncelleme

Roadmap entegrasyonu: borç = “görünmeyen özellik”

Özellikle major borçlar (eski framework, büyük mimari kırılganlık) roadmap’te görünür olmalı; aksi halde sürekli ertelenir.

Key Statistics / Data Point (yumuşatılmış): Teknik borcu kayıt altına alıp planlı şekilde eriten ekiplerde, yeni özellik geliştirme hızının orta vadede artması genelde daha olasıdır; çünkü kırılganlık ve tekrar iş azalır. Bu trendi görünür kılmak için teknik borç KPI’ları ile debt backlog ve sprint kapasitesi birlikte izlenmelidir.

Teknik borç kalemleri sektör/ürün tipine göre değişir. Özellikle legacy projelerde teknik borç envanteri doğru çıkarılmazsa, otelde rezervasyon/arama akışı ve entegrasyonlar; B2B’de API/raporlama ve portal performansı etrafındaki kritik borçlar görünmez kalır.

Otel örnekleri (rezervasyon/arama borçları)

• •Arama/filtre modülünde kırılgan kod (yoğun sezonda hata riski)
• •Rezervasyon motoru parametre yönetimi dağınık (UTM/cross-domain)
• •PMS/OTA entegrasyon time-out yönetimi zayıf
• •Kampanya sayfalarında ağır medya ve kötü CWV (SEO/perf borcu)

B2B örnekleri (raporlama/API borçları)

• •API endpoint’lerinde eski auth/permission yapısı
• •Raporlama pipeline gecikmesi ve kırılgan jobs
• •Portal UI komponentleri eski, responsive sorunlar
• •Ödeme akışında yetersiz retry/circuit breaker (ops borcu)

Türkiye’de teknik borç konuşuluyor ama çoğu kurumda borç kalemleri kayıt altında değil; bu da kararları soyutlaştırıyor. Bu rehberin farkı; register alan seti + impact/effort puanlama + sprint kapasite kuralı ile borcu operasyonel bir modele indirgemesidir. Böylece “borç var” tartışması “şu 3 kalem bu çeyrekte kapanıyor” seviyesine iner. Özellikle teknik borcun otel dijital performansına etkisi net anlatıldığında, debt backlog artık yalnız teknik değil ticari bir öncelik olarak da görünür. Süreci sistematik kurmak için Bakım ve Destek hizmetiyle debt backlog yönetimini planlı hâle getirin ve uygulama detayları için Bakım ve Destek hakkında sık sorulan sorular sayfasına geçin.