Yarım Kalan Yazılım Projesi Nasıl Kurtarılır? Kurtarma Rehberi

Yarım kalan yazılım projesi, yalnızca tamamlanmamış koddan ibaret değildir. Belirsiz gereksinimler, eksik dokümantasyon, kontrolsüz teknik borç, kaybolan erişimler ve güvenini yitirmiş paydaşlar aynı anda yönetilmelidir. Projeyi aceleyle başka bir ekibe devretmek veya her şeyi baştan yazmaya karar vermek ise mevcut kaybı büyütebilir.

Doğru yaklaşım; önce projenin gerçek durumunu görünür hâle getirmek, iş hedefini yeniden doğrulamak ve ardından devam etme, kısmi modernizasyon ya da yeniden geliştirme seçeneklerinden birini kanıta dayalı olarak seçmektir. Bu rehber, sorunlu bir yazılım projesini kontrollü biçimde yeniden ayağa kaldırmak için uygulanabilir bir yol haritası sunar.

Yarım Kalan Yazılım Projesi Neden Kurtarma Planına İhtiyaç Duyar?

Bir proje takvimden saptığında ilk tepki genellikle daha fazla geliştirici eklemek veya kalan özellikleri hızla tamamlamaktır. Ancak sorun kodlama kapasitesinden değil; yanlış kapsamdan, teknik kararların kayıt altına alınmamasından veya teslimat sürecinin çalışmamasından kaynaklanıyorsa ekip büyütmek çözüm sağlamaz.

Kurtarma çalışmasının amacı geçmişte kimin hata yaptığını bulmak değildir. Amaç, mevcut yatırımın hangi bölümünün korunabileceğini ve ürünün en düşük riskle nasıl iş değeri üretmeye başlayacağını belirlemektir. Bu nedenle ilk çıktı yeni bir teslim tarihi değil, doğrulanabilir bir teknik ve yönetsel durum raporu olmalıdır.

Bir Yazılım Projesinin Riskte Olduğunu Gösteren İşaretler

Proje tamamen durmadan önce görülebilen bazı ortak sinyaller vardır:

• Teslim tarihi sürekli değişiyor ancak kapsam aynı kalıyorsa,
• Hangi özelliklerin tamamlandığı paydaşlara göre farklılık gösteriyorsa,
• Uygulama yalnızca belirli bir geliştiricinin bilgisayarında çalışıyorsa,
• Canlıya çıkış manuel ve tekrarlanamaz adımlara bağlıysa,
• Kritik servis, alan adı, kaynak kod ve bulut hesaplarının sahipliği belirsizse,
• Test ortamı, otomatik testler veya güncel veritabanı yedeği bulunmuyorsa,
• Her yeni değişiklik beklenmeyen başka bir alanı bozuyorsa,
• İş birimleri ürünü kullanmaya başlamadan alternatif araçlara dönüyorsa

bu proje yalnızca gecikmiş değildir; teknik süreklilik ve yatırım geri dönüşü açısından risk altındadır.

İlk Adım: Kodu Değil, Kontrolü Devralın

Yeni ekip geliştirmeye başlamadan önce dijital varlıkların kontrolünü güvence altına almalıdır. Kaynak kod deposu tek başına yeterli değildir. Aşağıdaki envanter çıkarılmalı ve sahiplik doğrulanmalıdır:

• Git depoları, dallar, sürüm etiketleri ve CI/CD süreçleri,
• Canlı, test ve geliştirme ortamları,
• Bulut hesapları, sunucular, alan adları ve DNS kayıtları,
• Veritabanları, yedekler, dosya depoları ve veri taşıma betikleri,
• Üçüncü taraf servisler, lisanslar ve ödeme hesapları,
• API anahtarları, sertifikalar ve diğer gizli bilgiler,
• Tasarım dosyaları, gereksinimler, sözleşmeler ve kabul kriterleri.

Eski ekip üyelerinin erişimleri gözden geçirilmeli, gerekli parolalar ve anahtarlar güvenli biçimde yenilenmelidir. Bu adım tamamlanmadan yapılacak teknik geliştirme, kontrolü sizde olmayan bir sistem üzerinde yeni yatırım yapmak anlamına gelir.

Teknik Durum Tespiti Nasıl Yapılır?

Teknik inceleme yalnızca kod kalitesine puan vermemelidir. Uygulamanın çalıştırılabilir, test edilebilir, güvenli ve sürdürülebilir olup olmadığını ortaya koymalıdır.

1. Uygulama Tekrarlanabilir Biçimde Çalışıyor mu?

Temiz bir ortamda kurulum yapılmalı; bağımlılıklar yüklenmeli, veritabanı hazırlanmalı ve uygulama dokümante edilmiş komutlarla ayağa kaldırılmalıdır. Kurulum yalnızca kişisel bilgiye veya kayıp yapılandırma dosyalarına bağlıysa bu durum öncelikli risk olarak kaydedilmelidir.

2. Mimari İş İhtiyacını Destekliyor mu?

Modüllerin sorumlulukları, veri akışları, dış servis bağımlılıkları ve kritik darboğazlar haritalanmalıdır. Buradaki amaç her mimari tercihi değiştirmek değil; ürünün yakın dönem hedeflerini engelleyen kararları belirlemektir.

3. Veri Güvenilir ve Taşınabilir mi?

Şema, migration geçmişi, veri bütünlüğü, yedekleme ve geri yükleme prosedürleri incelenmelidir. Özellikle gerçek kullanıcı verisi bulunan projelerde kurtarma kararı verilmeden önce doğrulanmış bir yedek alınmalı ve geri yükleme testi yapılmalıdır.

4. Güvenlik Açıkları Kontrol Edildi mi?

Kaynak kodda gömülü sırlar, güncel olmayan bağımlılıklar, yetkilendirme hataları, hassas veri işleme biçimi ve loglarda veri sızıntısı riski değerlendirilmelidir. OWASP SAMM, yazılım güvenliğini yönetişimden doğrulamaya kadar ölçülebilir uygulamalarla ele alan teknoloji bağımsız bir çerçeve sunar.

5. Teslimat Süreci Ölçülebiliyor mu?

Bir ekibin yalnızca ne kadar kod yazdığına bakmak yanıltıcıdır. DORA; değişikliklerin teslim süresi, dağıtım sıklığı, başarısız değişiklik oranı ve başarısız dağıtımdan sonra toparlanma süresi gibi teslimat ölçümlerini birlikte değerlendirmeyi önerir. Kurtarma başlangıcında bu verilerin kusursuz olması beklenmez; ölçülebilir hâle gelmesi gerekir.

İş Hedefini ve Kapsamı Yeniden Tanımlayın

Teknik olarak tamamlanabilir her özellik ticari olarak gerekli değildir. Projenin ilk gereksinim listesi aylar önce hazırlanmış olabilir ve bugünkü müşteri ihtiyacını yansıtmayabilir. Bu yüzden şu sorular yeniden cevaplanmalıdır:

1. Ürün hangi kullanıcı problemini çözüyor?
2. İlk kullanılabilir sürümde hangi akışlar kesinlikle çalışmalı?
3. Hangi özellikler gelir, maliyet tasarrufu veya operasyonel risk üzerinde doğrudan etki yaratıyor?
4. Hangi özellikler daha sonraki sürümlere ertelenebilir?
5. Başarı hangi ölçütlerle ve kim tarafından kabul edilecek?

Her gereksinim için açık kabul kriteri yazılmalı ve tek bir önceliklendirilmiş ürün birikim listesi oluşturulmalıdır. Böylece “yüzde 90 tamamlandı” gibi doğrulanamayan ifadelerin yerini, test edilip kabul edilebilen çıktılar alır.

Devam Etmek mi, Modernize Etmek mi, Baştan Yazmak mı?

Proje kurtarmada en kritik karar mevcut kodun ne kadarının korunacağıdır. Bu karar kişisel teknoloji tercihleriyle değil, risk ve iş değeriyle verilmelidir.

Seçenek	Ne Zaman Uygun?	Temel Risk
Mevcut kodla devam	Temel akışlar çalışıyor, mimari geliştirilebilir ve kritik güvenlik sorunu yoksa	Görünmeyen teknik borcun teslimatı yavaşlatması
Kademeli modernizasyon	İşleyen bölümler korunabilir ancak bazı modüller değişimi engelliyorsa	Eski ve yeni yapının geçiş döneminde birlikte yönetilmesi
Baştan geliştirme	Mevcut yapı güvenli değilse, çalıştırılamıyorsa veya hedef ürünle temel olarak uyuşmuyorsa	Mevcut davranışların ve iş kurallarının kaybedilmesi

Martin Fowler, büyük sistemleri tek seferde değiştirmeye çalışmak yerine sonuçları netleştirip sistemi küçük parçalara ayıran kademeli modernizasyon yaklaşımını önerir. Bu yöntem, çalışan bölümlerin değer üretmeye devam etmesini ve yatırımın aşamalı yapılmasını sağlar. Ancak veri modeli temelden hatalıysa, güvenlik kabul edilemez düzeydeyse veya kod çalıştırılamıyorsa kontrollü bir yeniden geliştirme daha doğru olabilir.

Yazılım Projesi İçin İlk 30 Günlük Kurtarma Planı

1-5. Gün: Kontrol ve Envanter

• Tüm teknik hesapların ve varlıkların sahipliğini doğrulayın.
• Kaynak kodu, veritabanını ve dosyaları yedekleyin.
• Kritik erişimleri ve gizli bilgileri yenileyin.
• Karar vericileri, ürün sahibini ve teknik sorumluyu netleştirin.

6-10. Gün: Teknik ve Ürün Analizi

• Uygulamayı temiz ortamda çalıştırın.
• Kritik kullanıcı akışlarını uçtan uca test edin.
• Mimari, veri, güvenlik ve bağımlılık risklerini sınıflandırın.
• Mevcut gereksinimleri kullanıcı ve iş hedefleriyle karşılaştırın.

11-15. Gün: Kurtarma Kararı

• Korunacak, düzeltilecek ve kaldırılacak bileşenleri belirleyin.
• Devam, kademeli modernizasyon ve yeniden geliştirme seçeneklerini maliyet ile risk açısından karşılaştırın.
• İlk kullanılabilir sürümün kapsamını ve kabul kriterlerini onaylayın.

16-20. Gün: Teslimat Altyapısı

• Tekrarlanabilir geliştirme ve test ortamı kurun.
• Otomatik derleme, test ve dağıtım sürecinin temelini oluşturun.
• Kritik akışlara regresyon testleri ekleyin.
• Hata izleme, loglama ve temel performans gözlemlerini devreye alın.

21-30. Gün: Kontrollü İlk Teslimat

• Küçük fakat iş değeri görünür bir kapsam seçin.
• Test ortamında paydaş kabulünü tamamlayın.
• Geri dönüş planıyla birlikte sınırlı bir canlı dağıtım yapın.
• Sonuçları ölçüp sonraki teslimat planını güncelleyin.

İlk 30 günün başarısı çok sayıda özellik tamamlamakla değil, projenin tekrar öngörülebilir ve güvenli biçimde teslimat yapabildiğini göstermekle ölçülmelidir.

Kurtarma Sürecinde Kaçınılması Gereken Hatalar

• Analiz yapmadan tarih vermek: Bilinmeyen riskler açığa çıktıkça yeni takvim de güven kaybeder.
• Her şeyi baştan yazmak: Çalışan iş kuralları ve kullanıcı davranışları fark edilmeden kaybedilebilir.
• Yalnızca kod kalitesine odaklanmak: Yanlış ürün kapsamını daha temiz kodla geliştirmek projeyi kurtarmaz.
• Kapsamı sabit tutup süreyi kısaltmak: Kalite, güvenlik ve sürdürülebilirlik görünmez biçimde feda edilir.
• Eski ekibi tamamen dışlamak: Kritik iş bilgisi ve geçmiş kararların gerekçesi kaybolabilir.
• Tek büyük teslimatı beklemek: Risklerin geç fark edilmesine ve geri bildirim döngüsünün uzamasına yol açar.

Doğru Yazılım Danışmanlığı Ortağı Nasıl Seçilir?

Proje kurtarma deneyimi, yalnızca belirli bir teknoloji yığınına hâkim olmaktan daha fazlasını gerektirir. Değerlendireceğiniz ekipten doğrudan yeni geliştirme teklifi istemeden önce şu çıktıları talep edin:

• Kanıta dayalı teknik durum ve risk raporu,
• İş hedefleriyle ilişkilendirilmiş kapsam önerisi,
• Korunacak ve değiştirilecek bileşenlerin gerekçesi,
• Aşamalı teslimat, test ve geri dönüş planı,
• Maliyet varsayımları ile karar noktalarının açık listesi.

İyi bir kurtarma ortağı, inceleme yapmadan kesin süre ve bütçe sözü vermez. Önce belirsizliği azaltır, ardından her aşamada ölçülebilir çıktı üreten bir plan kurar.

Yarım Kalan Proje Her Zaman Kaybedilmiş Yatırım Değildir

Yarım kalan bir yazılım projesi doğru analiz edilirse kod, veri modeli, tasarım, kullanıcı geri bildirimi ve alan bilgisi gibi önemli varlıklar korunabilir. Kritik nokta, geçmiş yatırımı ne pahasına olursa olsun sürdürmek değil; bugün hâlâ değer taşıyan parçaları nesnel biçimde ayırabilmektir.

Kompanse, mevcut yazılım projelerinde teknik durum analizi, mimari değerlendirme, kapsam yeniden planlama ve kontrollü geliştirme desteği sunar. Projenizin hangi noktada olduğunu ve en düşük riskli kurtarma yolunu belirlemek için yazılım danışmanlık hizmetimizi inceleyebilir veya projeniz için teknik değerlendirme talep edebilirsiniz.

---

Kaynaklar: Martin Fowler, Strangler Fig; DORA yazılım teslimat performansı ölçümleri; OWASP Software Assurance Maturity Model.