Zora Giren veya Yarım Kalan Yazılım Projesi: 10 Erken Uyarı İşareti ve Kurtarma Planı

Kısaca: Zora giren bir yazılım projesinde en pahalı hata, sorunu görmezden gelip “belki düzelir” diye beklemektir. Erken uyarı işaretleri genellikle bellidir: ilerleme gösterilememesi, sürekli kayan teslim tarihleri, kontrolsüz bütçe artışı, iletişimin kopması, test edilemeyen çalışan bir sürüm olmaması, kaynak kod ve hesap erişimine kapalı olunması. Önce panik ve suçlamayı bırakıp durumu ölçün: neyin çalıştığını, neyin eksik olduğunu, ne kadar para ve zaman harcandığını, kodun ve hesapların kimde olduğunu netleştirin. Sonra üç yoldan birini seçin: mevcut firmayla yeniden hizalanıp devam etmek, projeyi başka bir ekibe devretmek ya da (gerçekten gerekiyorsa) yeniden yazmak. Kod kalitesi ve mülkiyet değerlendirilmeden “baştan yazalım” kararı vermek de, “sadece biraz daha bekleyelim” demek de risklidir. Bu yazı genel bilgidir; sözleşme ve hukuki konularda hukuk danışmanınıza başvurun.

Son güncelleme: Ekim 2026

Sorun çoğu zaman aniden değil, yavaş yavaş çıkar

Zora giren projeler genellikle şöyle ilerler: Başlangıçta iyimser bir takvim; ilk aylarda “çalışıyoruz” mesajları; sonra gecikme; kapsam tartışmaları; iletişimde seyreklik; bütçenin yetmediği söylenmesi ve nihayet “sistem yarım, kim neyi bitirecek” sorusu. Her aşamada müdahale edilebilirdi.

Bu bölümde erken işaretleri tanımayı, ardından ne yapmanız gerektiğini sırayla ele alıyoruz. Yeni bir proje başlatmayı düşünüyorsanız, bu sorunların çoğunu önceden önleyen yazılım firması seçimi rehberimizi okuyun.

10 erken uyarı işareti

1. Çalışan bir sürüm görmüyorsunuz

Haftalar, hatta aylar geçmesine rağmen tıklayıp deneyebileceğiniz bir şey gösterilmiyor. “Altyapı hazırlanıyor” sözü bir süre normaldir; ama makul bir sürede somut bir ilerleme görmüyorsanız ciddi bir uyarıdır.

2. Teslim tarihleri sürekli kayıyor

Tek bir gecikme normaldir; tekrarlayan ve gerekçesi belirsiz gecikmeler (“önümüzdeki hafta bitiyor” defalarca) sistemin yönetilmediğine işaret eder.

3. Kapsam sürekli “yeniden tartışılıyor”

“Bu zaten kapsamda değildi”, “bu ek iş” gibi cümleler sıklaşıyor; yazılı kapsam yok ya da yoksayılıyor. Kapsam netliği olmayan projede maliyet ve süre kontrolden çıkar.

4. Bütçe aşılıyor ve sebebi anlatılamıyor

Harcanan para ile gösterilen ilerleme orantısız. Ek bütçe isteniyor ama yapılan işin ayrıntısı, kalan işin tahmini verilmiyor.

5. İletişim kopuyor

Yanıt süreleri uzuyor, toplantılar erteleniyor, muhatap sürekli değişiyor ya da hiç ulaşılamıyor. İletişimin zayıflaması, genellikle diğer sorunların habercisidir.

6. Ekipte sürekli değişim oluyor

Projeye bakan kişiler değişiyor ve her seferinde sıfırdan anlatmanız gerekiyor. Bilgi kaybı hem hızı hem kaliteyi düşürür.

7. Hata sayısı artıyor, yeni özellik ilerlemiyor

Her sürümde eskiden çalışan şeyler bozuluyor; test yapılmıyor ya da ekip yalnızca yangın söndürüyor. Bu, kod kalitesi ve test eksikliğine işaret eder.

8. Kaynak kod, sunucu ve hesap erişimi kapalı

Kodun nerede olduğunu, sunucunun kimin hesabında olduğunu bilmiyorsunuz; erişim istediğinizde kaçamak cevaplar alıyorsunuz. Bu, projeyi başkasına devretmeyi imkânsızlaştıran bir rehin durumudur.

9. “Her şey yolunda” ama kanıt yok

Raporlar var, ama somut çıktı (ekran, test ortamı, kayıt) yok. Sorular cevapsız kalıyor veya hep aynı genel cümlelerle karşılanıyor.

10. Sizin içgüdünüz “bir şey yanlış” diyor

Yazılım bilmeseniz bile, işin gidişatındaki tutarsızlıkları fark edebilirsiniz. İçgüdünüzü ciddiye alın ve somut bir doğrulama isteyin.

İlk 2 haftalık kurtarma planı

Gün 1–2: Sakin kalın, kanıtları toplayın

• Mevcut sözleşme, teklif, kapsam dökümanı, ödeme kayıtları ve yazışmaları bir klasörde toplayın.
• Şu ana kadar ne kadar ödendiğini ve neyin teslim edildiğini yazın.
• Suçlama ve ani fesih kararlarından kaçının; önce durumu anlayın. Sözleşmeyi bozacak adımları atmadan önce hukuk danışmanıyla konuşun.

Gün 3–4: Mülkiyet ve erişimi netleştirin

Şu soruların cevabını yazılı alın:

• Kaynak kod nerede (hangi depo)? Hangi hesapta? Size erişim verilebilir mi?
• Alan adı, sunucu, veritabanı, üçüncü taraf hesapları (ödeme, e-posta, harita) kimin adına?
• Test/geliştirme ortamı var mı, çalışan bir sürüm nerede görülebilir?
• Kullanılan teknolojiler ve sürümler neler?

Bu bilgiler olmadan hangi yolu seçerseniz seçin ilerlemek zordur. Mümkünse kodun bir kopyasını ve veritabanı yedeğini (sözleşme izin veriyorsa) güvenli bir yerde saklayın.

Gün 5–7: Hızlı bir bağımsız değerlendirme yaptırın

Tarafsız bir uzmandan kısa bir teknik değerlendirme (audit) isteyin:

• Çalışan ve eksik özellikler neler? Kapsamın yüzde kaçı gerçekten bitmiş?
• Kod kalitesi: Okunabilir, test edilmiş ve yaygın teknolojilerle mi yazılmış?
• Güvenlik ve veri korumasında kritik eksikler var mı? (Güvenlik rehberimizdeki temel maddelere göre kontrol edilebilir.)
• Tahmini kalan iş ve süre nedir?
• Mimari büyümeye uygun mu?

Değerlendirme, “devam mı, devir mi, yeniden yazım mı?” kararını duyguya değil veriye dayandırmanızı sağlar.

Gün 8–10: Mevcut firmayla yüzleşin ve yeniden hizalanın

Firma ile yazılı, somut bir görüşme yapın:

• Gerçek durum raporu isteyin: yapılanlar, kalanlar, riskler.
• Yeni, gerçekçi bir takvim ve kalan iş listesi isteyin; kilometre taşlarını ödemelere bağlayın.
• Çalışan sürümü her hafta/iki haftada bir görmek istediğinizi belirtin.
• Kod ve hesap erişimini talep edin.

Firma bu adımları reddediyorsa, bu başlı başına bir bilgidir.

Gün 11–14: Karar verin

Elinizdeki veriyle üç yoldan birine karar verin (aşağıda ayrıntılı).

Üç yol: Devam, devir, yeniden yazım

“Yeniden yazalım” kararını verirken

Yeniden yazım sezgisel olarak cazip gelir, ama sıklıkla küçümsenen bir iştir. Şunları kontrol edin:

• Eski sistemde çalışan ve değerli kısımlar (iş kuralları, veri modeli, tasarım) yeniden kullanılabilir mi?
• Yeniden yazım, gerçekten kalan işi bitirmekten daha ucuz ve hızlı mı? (Bağımsız değerlendirmede bunu isteyin.)
• Yeni sürümü küçük bir çekirdekle (MVP mantığıyla) yayına almak mümkün mü? MVP yol haritası yazımıza bakın.
• Mevcut verileriniz yeni sisteme nasıl taşınacak?

Genel kural: Tüm sistemi yeniden yazmak yerine, ilk iş değer üreten çekirdeği sağlamlaştırıp aşamalı ilerlemek çoğu zaman daha düşük risklidir.

Yeni ekibi seçerken ekstra dikkat

Zora girmiş bir projeyi devralacak ekip, sıfırdan başlayan bir ekipten farklı bir iş yapar:

• Kodu ve belgeleri inceleyip kapsam, süre ve risk konusunda dürüst bir değerlendirme yapabilmeli.
• “Her şeyi biz hallederiz” demek yerine önce kısa bir keşif/değerlendirme aşaması önermeli.
• Mülkiyet ve erişimi baştan sizde tutan bir çalışma modeli sunmalı.
• Geçmişte benzer devralınan projeleri anlatabilmeli.

Teklifleri nasıl karşılaştıracağınız için fiyatlandırma modelleri rehberimiz işe yarar: Böyle bir durumda kısa, sabit fiyatlı bir değerlendirme aşaması ve ardından aşama aşama onaylanan geliştirme genellikle en güvenli yoldur.

Bir sonraki projede önleyici adımlar

Aynı sorunu yeniden yaşamamak için:

1. Kapsamı yazılı ve “kapsam dışı” maddeleriyle birlikte belgeleyin.
2. Ödemeleri kilometre taşlarına bağlayın; çalışan sürümü görmeden sonraki ödemeye geçmeyin.
3. Kaynak kod, alan adı, sunucu ve hesapları baştan kendi adınıza açtırın.
4. Düzenli demo (1–2 haftada bir) isteyin.
5. Aşamalı ilerleyin: MVP, sonra genişleme.
6. Test ve güvenlik işini kapsama yazın.
7. Bakım ve destek planını yayın öncesinde netleştirin. Bakım ve SLA rehberimize bakın.
8. Sözleşmede fesih ve devir teslim koşullarını belirleyin.

Mevcut firmayla iletişimi kopmadan konuşmak için örnek metin

Aşağıdaki tarz bir yazılı mesaj, durumu sakin ve net biçimde ele alır:

Merhaba [İsim],

Projenin gidişatı konusunda bir değerlendirme yapmak istiyoruz. [Tarih] itibarıyla kapsamın hangi bölümlerinin tamamlandığını, kalan işleri ve gerçekçi bir bitiş tarihini içeren yazılı bir durum raporunu [tarih]'e kadar bekliyoruz.

Ayrıca şu konularda yazılı bilgi rica ediyoruz: (1) kaynak kodun bulunduğu depo ve bize erişim, (2) alan adı/sunucu/üçüncü taraf hesaplarının sahipleri, (3) çalışan test sürümüne erişim.

Önümüzdeki hafta bir görüşme planlayabilir miyiz?

Bu mesajı göndermeden önce, sözleşmenizin ilgili maddelerini ve gerekirse hukuk danışmanınızı kontrol edin.

Aktaş Digital ile proje devralma ve toparlama

Yarım kalmış veya zora girmiş yazılım projelerini devralıyoruz. Süreç şöyle işliyor: önce kod, mimari, güvenlik ve eksik kapsamı inceleyen kısa bir değerlendirme yapıyoruz; ardından devam, kısmi yeniden düzenleme veya yeniden yazım seçeneklerini gerekçeleriyle ve kapsam-maliyet dökümüyle sunuyoruz. Çalışmayı aşamalara bölüyor, düzenli çalışan sürüm gösteriyor ve kaynak kod ile hesap erişimini sizde tutuyoruz. İlgili alanlarımız: web uygulamaları, SaaS platform geliştirme, e-ticaret çözümleri ve kurumsal yazılımlar.

Mevcut projenizin durumunu anlatmak için teklif formumuzu kullanabilir veya iletişim sayfamızdan bize ulaşabilirsiniz; gizlilik için NDA seçeneğimiz mevcut.

Sık Sorulan Sorular

Projeyi başka firmaya devretmek için eski firmanın izni gerekir mi?

Bu, sözleşmenize ve kaynak kod/fikri mülkiyet maddelerine bağlıdır. Ödemeleriniz tamamlandıysa ve sözleşmede kod devri varsa genellikle sorun olmaz; ancak ihtilaf varsa hukuk danışmanınızla ilerleyin. Bu yüzden mülkiyet maddelerini baştan netleştirmek önemlidir.

Ödediğim parayı geri alabilir miyim?

Bu hukuki bir sorudur ve sözleşmeye, teslim edilen işe ve ihtilafın niteliğine bağlıdır. Delilleri (yazışma, ödeme, kapsam belgesi) toplayın ve bir avukata danışın. Teknik değerlendirme raporu bu süreçte de faydalı olabilir.

Kod kalitesini bilmeden değerlendirmeyi kim yapmalı?

Projede çalışmamış, tarafsız bir yazılım uzmanı veya ekip. Değerlendirme; kod yapısını, testleri, güvenliği, belgelendirmeyi ve kalan işi inceler. Kısa, sabit fiyatlı bir çalışma olarak istemek yaygındır.

Her şeyi yeniden yazmak daha mı iyi?

Çoğu zaman hayır. Yeniden yazım pahalı ve uzun sürebilir; çalışan kısımları korumak ve ilk değer üreten çekirdeği önceliklendirmek genellikle daha güvenlidir. Kod kalitesi ve mimari gerçekten yetersizse yeniden yazım gerekebilir; bunu bağımsız değerlendirmeyle karara bağlayın.

Firma ile ilişkim bozulduysa verilerime ne olur?

Veritabanı ve dosyalarınızın bir kopyasını alabildiğinizden emin olun; üretim sunucusu ve hesapların sahipliğini netleştirin. İlişki bozulmadan önce de, yedeklerin sizde olması iyi bir uygulamadır.

Böyle bir durumda proje ne kadar sürede toparlanır?

Değerlendirme birkaç gün–iki hafta sürebilir; toparlama süresi kodun durumuna, kalan işe ve seçilen yola bağlıdır. Net bir süre için önce değerlendirme gerekir.

Sonuç

Zora giren bir projede kazanç, erken fark etmek, soğukkanlı ölçmek ve veriye dayalı karar vermektir. Uyarı işaretlerini ciddiye alın, kanıt ve mülkiyeti güvence altına alın, bağımsız bir değerlendirme yaptırın ve devam, devir ya da yeniden yazım kararını bu veriyle verin. Bugün yapabileceğiniz ilk iş: projenizin kaynak kodunun, alan adının ve sunucu hesaplarının kimin adına olduğunu yazıp, çalışan bir sürüme erişiminiz olup olmadığını kontrol etmek.