Teknik Borc Azaltma Plani: SaaS Ekipleri Icin

Teknik borç, "yarın düzeltiriz" kararlarının faiziyle büyüyen bir sermaye yükümlülüğüdür. SaaS ekiplerinde bu borç yönetilemez hale gelmeden önce görünür kılınmalı ve sprint ritmine entegre edilmelidir. Bu yazıda teknik borcu ölçülebilir hale getirip azaltmanın pratik çerçevesini paylaşıyorum.

Borç Envanteri: Görünmeyen Düşmanı Listelemek

Teknik borcu yönetmenin ilk şartı onu görmektir. Çoğu SaaS ekibinde borç kafalarda, onboarding sırasında "bu dosyaya dokunma" şeklinde sözlü olarak aktarılır. Bu tehlikeli ve sürdürülemez. İlk adım yapılandırılmış bir borç envanteri:

• Eski framework/lib: Desteği kesilmiş sürümler (örn. Node 14, Flutter 2.x)
• Mimari uyumsuzluklar: Aynı işi yapan 3 farklı pattern bir kod tabanında
• Test eksikliği: Kritik akışlarda sıfır test coverage
• Performance leak'leri: N+1 query, memory leak, render kill
• Güvenlik borçları: Eski dependency CVE'leri, secret manager dışında environment variable'lar

Her kalem için üç bilgi: etki (kritik/yüksek/orta/düşük), tahmini effort (saat), ve kimin tarafından eklendiği değil neden eklendiği. Neden önemli çünkü o koşul hala geçerli mi sorgulamak gerekiyor.

Önceliklendirme: Etki × Maliyet Matrisi

Borç envanterini yaptıktan sonra herkesi en çok rahatsız edeni seçmek doğru değildir. Etki × maliyet matrisi daha iyi bir filtredir:

• Yüksek etki, düşük maliyet: Hemen yap. "Quick wins"
• Yüksek etki, yüksek maliyet: Planlı refactor pencereleri
• Düşük etki, düşük maliyet: Developer boş zamanında veya yeni feature ile birlikte
• Düşük etki, yüksek maliyet: Yapmayın. Kabul edin ve not edin

"Düşük etki, yüksek maliyet" kategorisi özellikle önemli — bazı borçları ödememek stratejik doğru karardır. Her zayıflık çözülmek zorunda değil.

Refactor Pencereleri: Sprint İçine Nasıl Sığar?

Teknik borç azaltmanın başarısızlık sebebi neredeyse hep aynı: "önce feature, sonra refactor" mantığı. Uygulanan pratikler:

1. Boy Scout Rule: Her PR, dokunduğu kodu biraz daha temiz bırakır. Küçük ama sürekli.

2. %20 allocation: Sprint kapasitesinin %20'si teknik borç işlerine ayrılır. Bir takım 40 story point'lik sprint yapıyorsa 8 point borç işi. Bu, kurucuyla anlaşma olarak sözleşmelenmelidir.

3. Çeyreklik refactor haftası: Her 3 ayda bir, 1 hafta "feature freeze" teknik borç odaklı. Bu haftada yeni özellik yok, sadece büyük refactor'lar. Ekip için hem dinlendirici hem motive edici.

4. Feature ile birlikte: Yeni bir feature eklerken, ona en yakın olan borcu birlikte kapatın. Auth flow'u değiştiriyorsanız, auth modülündeki test eksikliğini o sprint içinde kapatın.

KPI Takibi: Azalmayı Ölçmek

Teknik borç azaltma programının başarılı olup olmadığını ölçemiyorsanız, muhtemelen başarılı değildir. Takip edilebilir metrikler:

• Code coverage: Toplam ve kritik path'ler için ayrı. Yön hedef: kritik path'te %80+
• Dependency yaş: Kütüphanelerin kaç major versiyon geride olduğu. Hedef: en fazla 1 major
• Incident MTTR: Üretimde bir sorun olduğunda çözüme ulaşma süresi. Teknik borç düşerse bu süre düşer
• Developer happiness: Çeyreklik anket. "1-10 arası kod tabanımızla çalışmak ne kadar keyifli?"
• Ciklo zamanı: Bir PR'ın açılmasından merge'e kadar geçen süre

Dashboard'u ekip odasında veya Slack'te haftalık gösterin. Görünürlük, disiplinin tek sürdürülebilir mekanizmasıdır.

Gerçek Senaryo: 18 Aylık Azaltma Programı

Bir SaaS ekibinde uyguladığım program. Başlangıç durumu: 34 kalem envanterde, %18 code coverage, dependency'ler ortalama 2.3 major geride, MTTR 4.5 saat.

• Q1: Boy Scout rule + envanter ve prioritization. %20 allocation Jira'da etiketlendi
• Q2: İlk refactor haftası — state management standartlaştırıldı (3 pattern'dan Riverpod'a). Coverage %34'e
• Q3: Dependency güncelleme dalgası, security fix'ler. Dependency yaşı ortalama 0.8 major'a
• Q4: Test pyramid: kritik path testleri yazıldı. Coverage %58, MTTR 1.8 saat

18 ay sonundaki sonuç: 34 kalemden 22'si kapandı, 9'u kabul edildi ve dokümante edildi, 3'ü daha kritik hale geldi ama bilinçli kabul edilip plana alındı.