Yarım Kalmış Yazılım Projesi: Kurtar mı, Sıfırdan mı? (2026)

Yarım Kalmış Yazılım Projesini Kurtarmak mı, Sıfırdan Yazmak mı? 2026 Karar Rehberi

Önce Bir Şey Net Olsun

Yarım kalmış proje "kötü vendor seçtiniz" hikayesi değil her zaman. Çoğu vakada üç sebebin biri veya birkaçı var:

Discovery yapılmamış, kapsam yarı yolda büyümüş
Vendor seçimi sırasında doğru sorular sorulmamış
İç ekip ile vendor arasında iletişim koparmış
Teknik kararlar (mimari, stack) yanlış başlamış
Kurum içi öncelik değişmiş, proje yetim kalmış

Hangi sebep olursa olsun, gelinen nokta aynı. Kod var, dokümantasyon eksik, ekip dağılmış, üretim ortamına çıkamamışsınız.

5 Erken Batma Sinyali

Aşağıdaki sinyallerin 3 veya daha fazlası gözlenmişse proje muhtemelen yarım kalma noktasındadır.

Sinyal 1: Sprint demolarında "çalışan kod" yerine slayt görüyorsunuz. Sprint sonunda canlı bir özellik göremiyorsanız, vendor muhtemelen kapsamı tamamlayamıyor.

Sinyal 2: Aynı bug 3 sprint üst üste düzeltildi. Bug fix sonra kırılıyor, demek ki kod tabanı kırılgan, regression testi yok.

Sinyal 3: Vendor takımı 3 ayda en az 2 kişi değiştirdi. Mühendis turnover'ı yüksekse, bilgi transferi yapılmıyor demektir.

Sinyal 4: Dokümantasyon yok ya da güncel değil. README dosyası, mimari diyagramı, API spec yoksa proje "kara kutu" haline gelmiş.

Sinyal 5: Discovery yapılmamış, scope sürekli büyüyor. Her hafta yeni gereksinim, her toplantı yeni bütçe.

Bu sinyallerin biri de gözlenmemiş gibi yapılan projeler 6-12 ay içinde kurtarılamaz noktaya geliyor.

Kurtarma vs Sıfırdan Yazma — 4 Karar Boyutu

Kararı 4 boyutta verirsiniz.

Boyut 1: Mevcut Kod Kalitesi

Kodun ne kadarı kullanılabilir? Bunu görmek için forensic kod denetimi şart. İyi senaryoda %30-50 kullanılabilir, kötü senaryoda %5-10.

Boyut 2: Mevcut Sistemin Yaşı ve Stack'i

2-3 yıllık kod genelde kurtarılabilir. 7+ yıllık legacy (eski PHP, jQuery, .NET Framework 4) tamamen yeniden yazılması daha verimli.

Boyut 3: Yeniden Yazma Maliyeti vs Kurtarma Maliyeti

Eğer yeniden yazma maliyeti kurtarma maliyetinin %150'sinden azsa, sıfırdan yazmak daha mantıklı. %150'den fazlaysa kurtarma denenebilir.

Boyut 4: Zaman Baskısı

Pazar fırsatı 6 ay sonra geçecekse kurtarma. Yeniden yazmak 12-18 ay. Zaman varsa sıfırdan yazmak daha temiz bir başlangıç.

Kurtarma Süreci (6-8 Hafta)

Kurtarma denenirse aşağıdaki yapı uygulanmalı. Bunu Internative'de Software Graveyard adında ayrı bir hizmet hattı olarak yapılandırdık.

Hafta 1-2: Forensic Audit (Adli Denetim)

Kod arkeolojisi: ne inşa edilmiş, ne çalışıyor, ne yarım kalmış
Bağımlılık haritalama: hangi parça projenin %80 değerini taşıyor
Risk sınıflandırması: kritik, düzeltilebilir, terk edilebilir

Hafta 3-4: Triage ve Stabilize

Kanama durdurulur (kritik bug, güvenlik açığı, veri bütünlüğü)
Kullanılabilir kod dokümantasyonu yapılır
Atılacak kod ile yeniden yazılacak kod ayrılır

Hafta 5-6: Roadmap ve Devir Teslim

12 aylık net kurtarma planı (fazlar net)
İç ekibe bilgi transferi (veya managed services modeli ile devam)
Karar: uzun süreli partnership mi, kısa süreli devir mi

Tipik Sonuçlar

"Tamamen terk" denilen kodun %30-50'si aslında kurtarılabilir
Yeniden yazma maliyetinden %60-80 tasarruf
Kurtarma 3-6 ayda tamamlanıyor, yeniden yazma 12-18 ay sürerdi

Sıfırdan Yazma Süreci (12-18 Ay)

Kurtarılamayan durumlarda sıfırdan yazma süreci aşağıdaki yapıda olmalı.

Hafta 1-4: Discovery ve Tasarım

Eski sistemin neyi yanlış yaptığı belgelenir
Yeni gereksinimler discovery ile tanımlanır
Mimari kararlar yeniden alınır (önceki sefer hangi mimari hata yapıldı, neden)
KPI çerçevesi tanımlanır

Ay 2-6: MVP Geliştirme

Çekirdek özellikler önce
Eski sistemden migration planı paralel
Eski sistem hala üretimde çalışıyor olabilir, ona dokunulmaz

Ay 7-12: Geçiş

Yeni sistem üretim ortamına alınır
Kullanıcılar fazlandırılarak yeni sisteme geçirilir
Eski sistem rollback için hazır tutulur

Ay 13-18: Olgunlaşma

Eski sistem kapatılır
Yeni sistem üzerine geliştirme devam eder

Tipik Sonuçlar

Yeniden yazma maliyeti orijinal projenin %120-180'i
Süre 12-18 ay
Başarısızlık ihtimali yeniden yazma kararı doğru verilirse %15-25'e düşüyor (kurtarmada bu %45-60)

Karar Matrisi

Kod yaşı 2-3 yıl, modern stack: ✓ İlk tercih

Kod yaşı 7+ yıl, legacy stack: İkincil

Kullanılabilir kod %30+: ✓ İlk tercih

Kullanılabilir kod %10 altı: İkincil

Zaman baskısı (6 ay altı): ✓ İlk tercih

Zaman baskısı yok: İkincil

İç ekip kapasitesi yetersiz: ✓ İlk tercih (managed services dahil)

Mevcut vendor zaten ayrılmış: İkincil

Yeniden yazma maliyeti kurtarmanın %150'sinin altında: İkincil

Yeniden yazma maliyeti kurtarmanın %200'ünün üzerinde: ✓ İlk tercih

Eğer kararsızsanız 6-8 haftalık bir kurtarma audit'i yapmak kararı kesinleştiriyor. Audit sonrası yapılan sıfırdan yazma kararı, audit yapılmadan verilen karara göre %60 daha düşük başarısızlık oranıyla sonuçlanıyor.

Karar Vermeden Önce 5 Soru

Mevcut kod tabanını forensic audit yapmadan karar vermeyin. Hangi durumda olduğunu bilmeden hangi yolun ucuza geleceğini bilemezsiniz.
Kim sahiplenecek? Kurtarma ya da yeniden yazma, sahibi olan birinin sürekli orada olması gerek. Yetim projeler nadiren tamamlanır.
İç ekip kapasitesi var mı, yoksa managed services mi gerekli? Bu karar sürece dahil.
Önceki başarısızlıktan ne öğrendiniz? Aynı yöntemle yeniden başlarsanız aynı yere gelirsiniz.
Discovery yapılmadan başlamamak. Sıfırdan yazsanız bile yapılmadıysa aynı tuzağa düşersiniz.

İlgili Çerçeveler

Sonraki Adım

Yarım kalmış bir yazılım projesi gündeminizdeyse, 30 dakikalık ücretsiz bir görüşmede projenin mevcut durumunu konuşup ön değerlendirme yapabiliriz. Forensic audit hizmetimiz (6-8 hafta) kurtarma veya sıfırdan yazma kararını sistematik olarak veriyor.

Software Graveyard sürecimiz için internative.net üzerinden veya team@internative.net adresinden ulaşabilirsiniz. İlk audit görüşmesi ücretsiz.