Teknik borç çoğu ekipte iki hatalı uç arasında yaşar. Birinci uçta borç sürekli şikâyet edilir ama iş planına giremez. İkinci uçta ise her kalite problemi “önce bunu temizleyelim” diyerek teslim takvimini felç eder. Kıdemli mühendislik pratiğinde değer üreten yaklaşım, teknik borcu duygusal bir yakınma alanı olmaktan çıkarıp pazarlık edilebilir bir mühendislik konusu hâline getirmektir.
Teknik borç neden pazarlık konusu olmak zorunda?
Çünkü kurumsal ekiplerde kaynaklar sınırlıdır ve her iş aynı anda yapılamaz. Teknik borcun gerçek etkisi çoğu zaman şu başlıklardan birine dokunur:
- Teslim hızını yavaşlatır
- Incident ihtimalini artırır
- Değişiklik riskini yükseltir
- Onboarding süresini uzatır
- Platform maliyetini görünmez biçimde büyütür
Fakat bu etkiler soyut cümlelerle anlatıldığında iş kararına dönüşmez. “Bu kod kötü” demek yerine “bu servis her değişiklikte iki ekip bağımlılığı yaratıyor” demek daha güçlüdür. Pazarlık çerçevesi tam burada başlar.
Borcu konuşurken hangi dili kullanmak gerekir?
Ben üç dilli bir modelin faydalı olduğunu düşünüyorum:
- Risk dili
- Akış dili
- Maliyet dili
Risk dili, olası kesinti veya güvenlik etkisini anlatır. Akış dili, teslim süresini ve ekip bekleme noktalarını görünür kılar. Maliyet dili ise fazla altyapı, operasyon yükü veya yeniden işleme bedelini masaya getirir. Kıdemli mühendis, aynı problemi bu üç dilden uygun olanla anlatabildiğinde karar vericilerle ortak zemin kurar.
Örneğin “monolitik deployment pipeline karmaşık” cümlesi zayıftır. Bunun yerine “rollback süremiz kırk dakikaya çıktığı için değişiklik pencereleri daralıyor” cümlesi karar üretir.
Her teknik borç aynı önemde değildir
En sık hata, bütün borçları eşit öncelikli göstermek. Bu yaklaşım kısa sürede güven kaybettirir. Daha sağlam model, borcu şu kümelere ayırmaktır:
- Kesinti borcu: Incident olasılığını veya etki alanını büyüten borç
- Akış borcu: Ekiplerin iş teslim hızını düşüren borç
- Uyum borcu: Denetim, güvenlik veya regülasyon riski doğuran borç
- Platform borcu: Tekrarlı manuel iş ve işletim yükü yaratan borç
Bu sınıflandırma sayesinde aynı backlog içinde hangi kalemin neden öne çıktığı daha şeffaf olur.
Pazarlık masasına neyle gidilir?
Yalnızca sezgiyle değil, küçük ama ikna edici kanıtlarla. Benim faydalı bulduğum giriş seti şunlar:
- Son üç değişiklikte görülen aynı hata deseni
- Ortalama lead time veya rollback süresi
- Runbook bağımlılığı veya tek kişiye bağlı operasyon adımı
- Alert hacmi ile gerçek kök neden arasındaki kopukluk
- Yeni ekip üyelerinin öğrenme eğrisi
Bu veriler mükemmel olmak zorunda değildir. Ama pazarlığı “hissediyoruz” seviyesinden “desen görüyoruz” seviyesine taşır.
Teknik borç için ne zaman tam çözüm, ne zaman ara katman?
Kıdemli mühendisliğin fark yarattığı yerlerden biri de budur. Her problem tam yeniden yazım gerektirmez. Bazen en doğru hareket geçici ama kontrollü bir ara katman kurmaktır:
- Kırılgan entegrasyon için idempotent retry katmanı
- Dağınık log yapısı için ortak şema zenginleştirme katmanı
- Zayıf erişim modeli için kısa ömürlü yetki koridoru
- Kaotik release süreci için daraltılmış değişiklik kontratı
Bu ara çözümler, borcu inkâr etmek için değil, büyük dönüşüm için güvenli zaman kazanmak için kullanılmalıdır.
Mentorluk boyutu neden önemli?
Çünkü genç mühendisler çoğu zaman teknik borcu ya tamamen görmez ya da görünce her şeyi acil kabul eder. Kıdemli mühendis burada örnek olur. Borcu nasıl tarif ettiğiniz, neyi ölçtüğünüz ve neyi şimdilik kabul ettiğiniz ekipte standart oluşturur.
Mentorluk şu davranışlarla görünür:
- Borç başlığını iş etkisiyle birlikte yazmak
- Tasarım görüşmelerinde “gelecekteki operasyon maliyeti” sorusunu sormak
- Refactor önerisini teslim planından koparmadan anlatmak
- “Şimdi düzeltmiyoruz” kararını da gerekçeli almak
Bu disiplin, teknik olgunluğu bireysel sezgiden ekip pratiğine taşır.
Sonuç
Kıdemli mühendisler için teknik borç pazarlığı çerçevesi, daha yüksek sesle şikâyet etmek değil; daha isabetli karar zemini kurmaktır. Teknik borcu risk, akış ve maliyet diliyle görünür kıldığınızda; ürün, platform ve yönetim katmanlarıyla daha gerçekçi anlaşmalar yapabilirsiniz. İyi kıdemli mühendislik biraz da budur: her teknik gerçeği doğru teknik olmayan dile çevirebilmek.