Teknik borç, "bugün hızlı olsun" diye verilen kararların yarın ödediğiniz faizidir. Kötü kod demek değildir; zamanında doğru olan ama artık ihtiyacı karşılamayan çözüm demektir. KOBİ'de sorun borcun varlığı değil, kimsenin defterini tutmamasıdır.
Borç her zaman kötü değildir
Sezona yetişmek için ödeme sayfasını kestirmeden yazmak makul bir ticari karardır. Ürün tutmazsa o kodu hiç düzeltmezsiniz ve tasarruf gerçektir. Sorun, kararın bilinçli mi bilinçsiz mi alındığıdır.
- Bilinçli borç: "Şimdi hızlı çözüyoruz, mart ayında düzelteceğiz." Kayda geçer, tarihi vardır.
- Bilinçsiz borç: Kimse fark etmeden birikir; üç yıl sonra "bu modüle dokunmayalım, bozulur" cümlesiyle kendini gösterir.
- Çürüme borcu: Siz hiçbir şey yapmasanız da dünya değişir: PHP sürümü, tarayıcı davranışı, ödeme sağlayıcısının API'si, mevzuat.
Teknik borcun faizi para değil zamandır: aynı işi her seferinde biraz daha uzun sürede yaparsınız.
KOBİ yazılımında tipik borç kalemleri
| Kalem | Belirti | Ertelemenin bedeli | İlk adım |
|---|---|---|---|
| Eski PHP/kütüphane sürümü | Hosting yükseltince site hata veriyor | Plansız kesinti, güvenlik açığı | Sürüm envanteri çıkarın |
| Kopyalanmış iş mantığı | Aynı fiyat hesabı üç dosyada | Bir yerde düzeltilen hata diğerinde kalıyor | Tek fonksiyona toplayın |
| Test edilmemiş yedek | Yedek alınıyor ama hiç açılmadı | Kriz anında toplam veri kaybı | Bu ay bir geri yükleme provası |
| Kod içine gömülü ayarlar | Fiyat/oran değişimi için geliştirici gerekiyor | Her küçük değişiklik ücretli iş | Ayarları panele taşıyın |
| Ortak yönetici hesabı | Herkes aynı şifreyle giriyor | Kim ne yaptı belli değil, KVKK riski | Kişi bazlı hesap + rol |
| Belgesiz özel geliştirme | Yapanı ayrılmış, kimse bilmiyor | Tedarikçi değiştirme maliyeti katlanıyor | Tek sayfalık mimari notu |
Borç envanteri nasıl çıkarılır?
Teknik bilgi gerekmez: son üç ayda yaşadığınız aksaklıkları listeleyin ve her birine "neden oldu" diye iki kez sorun. Ortaya çıkan kök nedenlerin çoğu bir borç kalemidir.
- Bir e-tablo açın; sütunlar: kalem, belirti, ne sıklıkta yaşanıyor, olursa etkisi, tahmini çözüm süresi.
- Sıklığı "haftalık / aylık / yılda birkaç kez" olarak işaretleyin. Kesin sayı gerekmez, sıralama yeterlidir.
- Etkiyi üç kademede yazın: para kaybı, itibar kaybı, sadece rahatsızlık.
- Çözüm süresini yarım gün, birkaç gün, hafta olarak kabaca tahmin edin.
- Sıklık ve etkinin yüksek, çözüm süresinin düşük olduğu satırları en üste alın. Listenin ilk beş satırı önümüzdeki çeyreğin işidir.
Önce ödenmesi gerekenler
- Güvenlik ve kişisel veriyi ilgilendiren her şey. Sızıntı riski tartışmaya açık değildir.
- Para akışına dokunan kod: ödeme, iade, fatura, kupon. Buradaki hata doğrudan zarardır.
- Her hafta insan zamanı yiyen elle işler. Haftada 2 saat süren manuel aktarım yılda 104 saat, yani yaklaşık 13 iş günü eder.
- Yedek ve geri yükleme. Bu kalemi ertelemek, diğer tüm kalemleri geri alınamaz hale getirir.
Nasıl bütçelenir?
KOBİ'de "üç ay durup her şeyi yeniden yazalım" gerçekçi değildir ve genelde yarıda kalır. İşleyen model, kapasitenin sabit bir dilimini borca ayırmaktır. Sahada işimize yarayan pratik kural yaklaşık beşte birdir: ayda 10 gün geliştirme yaptırıyorsanız 2 günü borç ödemesine gider. Bu iş de tıpkı yeni özellik gibi listeye yazılır, tarihlenir, kapatılır. Oran kutsal değildir; kendi ölçümünüzle aşağı yukarı oynatın.
İkinci teknik "gezerken temizlik"tir: bir modülde iş yapılırken o dosyadaki küçük borç aynı iş kalemi içinde kapatılır. Yeni özellik ekliyorsanız yanındaki kopyalanmış üç fonksiyonu birleştirmek, ayrı bir proje açmaktan ucuzdur.
Ne zaman ödemeyin
- Altı ay içinde tamamen değişecek veya kaldırılacak modülde. Çöpe gidecek koda yatırım yapmayın.
- Nadiren kullanılan, hata çıkarmayan ve kimseyi yavaşlatmayan yerlerde. Çirkin olması tek başına gerekçe değildir.
- Sezonun en yoğun haftasında. Riskli iş, sakin dönemde yapılır.
Borç yeniden birikmesin diye
- Her hızlı çözümün yanına tarih yazın: "geçici, en geç mart". Tarihsiz geçici çözüm kalıcıdır.
- Yeni iş taleplerinde "bu, hangi mevcut kalemi zorlaştırıyor" sorusunu sorun.
- Her özel geliştirmenin tek sayfalık notu olsun: ne yapar, hangi dosyalar, hangi dış servise bağlı.
- Tedarikçiyle çalışıyorsanız teslimatın parçası olarak kaynak kodu, veritabanı şemasını ve kurulum adımlarını isteyin.
- Sürüm ve değişiklik kaydı tutun; kimin ne zaman ne değiştirdiğini bilmek borcun yarısını görünür kılar.
Ölçün: üç basit gösterge
Karmaşık metrik gerekmez. Ayda bir bakacağınız üç sayı yeterlidir: (1) canlıya çıkan bir değişikliğin fikirden yayına kaç gün sürdüğü, (2) yayın sonrası kaç düzeltme gerektiği, (3) tekrarlayan manuel işlere harcanan saat. Bu üç sayı kötüleşiyorsa borç faizi yükseliyor demektir; iyileşiyorsa ayırdığınız bütçe işini yapıyordur.
Sık yapılan hatalar
- Borcu yalnızca geliştiricinin sorunu saymak. Bütçe ve öncelik kararı işletmenindir.
- "Sıfırdan yazalım" refleksi. Yeniden yazım, mevcut sistemin tüm görünmez kurallarını da yeniden keşfetmeyi gerektirir; çoğu KOBİ projesinde parça parça iyileştirme daha hızlı sonuç verir.
- Listeyi çıkarıp bir daha açmamak. Envanter, çeyrekte bir gözden geçirilmezse ölür.
- Yalnızca kodu düşünmek. Belgesizlik, tek kişiye bağımlılık ve elle yapılan işler de borçtur.
- Tüm borcu aynı anda kapatmaya çalışıp normal işleri durdurmak.
Uygulanabilir özet
- Bu hafta bir e-tabloda borç envanterini çıkarın; on satır yeterli, mükemmel olması gerekmiyor.
- Güvenlik, para akışı ve yedek kalemlerini listenin başına alın.
- Geliştirme kapasitenizin yaklaşık beşte birini kalıcı olarak borç ödemesine ayırın.
- Her hızlı çözüme tarih yazın ve o tarihte gerçekten bakın.
- Üç göstergeyi (yayın süresi, düzeltme sayısı, manuel iş saati) ayda bir ölçün; yön doğruysa devam edin.
