Yarım Kalmış Bir Projeyi Kurtarmadan Önce Bakmanız Gereken 5 İşaret ve Vermeniz Gereken 4 Karar
Geçen yıl, yeniden geliştirilmesi istendiği için önümüze gelen 17 yazılım projesini inceledik.
İlk bakışta bu projelerin tamamı “baştan yazılmalı” gibi görünüyordu. Ancak detaylı inceleme sonunda yalnızca 4’ünün gerçekten sıfırdan geliştirilmesi gerektiğini gördük.
Kalan 13 proje ise doğru ekip, doğru analiz ve 8–12 haftalık odaklı bir çalışma ile kurtarılabilecek durumdaydı.
Aradaki fark çoğu zaman teknik değildi.
Asıl fark, projenin doğru teşhis edilip edilmemesiydi.
Bu yazı; elinizde yarım kalmış, takılmış, sürekli ertelenen ya da “iki hafta daha verirsek toparlanır” denilen bir yazılım projesi varsa, yeniden geliştirme kararı vermeden önce kullanabileceğiniz bir değerlendirme çerçevesi sunuyor.
Yazılım Mezarlığı Nedir?
“Yazılım Mezarlığı”, Internative olarak sektörde sık gördüğümüz ama adı pek konmayan bir problemi tarif etmek için kullandığımız bir kavramdır:
Yarım kalmış, takılmış, devredilememiş ya da ekip değişiklikleri sonrasında sahipsiz kalmış yazılım projeleri.
Neredeyse her kurumsal şirketin geçmişinde böyle bir proje vardır.
Bazen eski bir müşteri portalıdır.
Bazen yarım kalmış bir mobil uygulamadır.
Bazen iç operasyonları hızlandırması beklenen ama hiç tam çalışmayan bir yönetim panelidir.
Bazen de “biraz daha zaman verirsek olur” denerek aylarca taşınan stratejik bir üründür.
Bu projeler çoğu zaman teknik ekiplerin üzerinde sessiz bir yük olarak kalır.
CTO ya da IT yöneticisi projeyi kapatmak istemez. Çünkü ciddi bütçe harcanmıştır.
Baştan yazdırmak istemez. Çünkü yeni bir bütçe ve zaman riski doğar.
Mevcut haliyle canlıya almak istemez. Çünkü güven vermez.
Sonuçta proje arada kalır.
Ne tamamen ölür, ne de gerçekten çalışır.
Sektördeki yaygın yanlış inanış şudur:
> “Yarım kalan proje büyük ihtimalle mimari olarak bozuktur. Bu yüzden baştan yazılmalıdır.”
Bizim sahada gördüğümüz gerçek ise daha farklı:
> Yarım kalmış projelerin önemli bir bölümü teknik olarak kurtarılabilir durumdadır. Eksik olan çoğu zaman mimari değil; doğru ekip, doğru süreç ve sağlıklı bilgi devridir.
Projeniz Yazılım Mezarlığına Gidiyor Olabilir mi? 5 İşaret
Aşağıdaki işaretlerden birkaçını aynı anda görüyorsanız, projeniz teknik olarak hâlâ kurtarılabilir olsa bile yönetimsel olarak riskli bölgeye girmiş olabilir.
1. Haftalarca canlıya yeni sürüm çıkılamıyor
Bu yalnızca süreç sorunu değildir. Çoğu zaman bir güven sorunudur.
Ekip canlı ortama kod göndermekten çekinmeye başlamıştır. Çünkü her yeni yayın yeni bir hata çıkarır. Her hata yeni bir gece mesaisi, yeni bir kriz ve yeni bir güven kaybı demektir.
Bu korku biriktikçe yayın aralıkları uzar.
Yayın aralıkları uzadıkça, her canlıya çıkışta değişen kod miktarı büyür.
Değişen kod miktarı büyüdükçe, risk daha da artar.
Bir süre sonra ekip küçük ve düzenli geliştirmeler yapmak yerine, büyük ve riskli paketlerle canlıya çıkmaya çalışır.
Bu da projeyi daha kırılgan hale getirir.
Sağlıklı projelerde canlıya çıkış düzenlidir, ölçülebilirdir ve ekip için panik sebebi değildir.
2. Kod incelemeleri yapılmıyor, sadece onaylanıyor
Kod inceleme süreci kağıt üzerinde var olabilir. Ama gerçekten çalışıyor mu?
Eğer büyük değişiklikler kimse tarafından ciddi biçimde okunmadan onaylanıyorsa, ekip aslında teknik borç biriktiriyor demektir.
Örneğin 800 satırlık bir değişiklik birkaç dakika içinde onaylanıyorsa, burada gerçek bir inceleme yapıldığını söylemek zordur.
Kod incelemenin amacı yalnızca “hata var mı?” diye bakmak değildir.
Aynı zamanda şu soruların cevaplanması gerekir:
* Bu değişiklik doğru yerde mi yapıldı?
* Mevcut mimariyle uyumlu mu?
* İleride başka modülleri bozma riski var mı?
* Test edilebilir mi?
* Başka bir geliştirici 3 ay sonra bu kodu anlayabilir mi?
Sağlıklı ekiplerde değişiklikler daha küçük parçalara bölünür.
Büyük geliştirmeler kontrollü biçimde yönetilir.
Kod inceleme, sadece onay süreci değil, kalite güvence mekanizmasıdır.
3. Aynı hatalar tekrar tekrar geri dönüyor
Bir hata düzeltiliyor ama birkaç hafta sonra benzer şekilde yeniden ortaya çıkıyorsa, sorun yalnızca o hatada değildir.
Bu genellikle test eksikliğine, zayıf kalite kontrol sürecine veya kodun yeterince anlaşılmamasına işaret eder.
Burada iki farklı durum olabilir:
Hiç test altyapısı kurulmamıştır
Bu durumda çözüm daha nettir.
Öncelikli modüller belirlenir, kritik iş akışları için test altyapısı kurulur ve proje kademeli olarak güvenli hale getirilir.
Doğru yaklaşımla 4–6 hafta içinde kritik alanlarda anlamlı bir test kapsamı oluşturmak mümkündür.
Testler vardır ama kullanılmaz hale gelmiştir
Bu daha derin bir sorundur.
Çünkü ekip bir noktada “testler bize yardımcı olmuyor” noktasına gelmiştir.
Bu durumda sadece teknik bir iyileştirme yetmez. Testlerin neden bozulduğu, neden güncellenmediği ve neden ekibin günlük çalışma düzeninin parçası olmaktan çıktığı anlaşılmalıdır.
Aynı hataların geri dönmesi, projenin kontrolünün zayıfladığını gösteren en net işaretlerden biridir.
4. Ekip sürekli “yeni teknolojiye geçelim” demeye başlıyor
“Bunu başka bir teknolojiyle yeniden yazalım.”
“Mevcut yapıyı bırakıp daha modern bir altyapıya geçelim.”
“Bu sistemden olmaz, baştan kuralım.”
Bu cümleler bazen haklıdır. Gerçekten eski, sürdürülemez veya yanlış kurulmuş bir mimari olabilir.
Ama her zaman böyle değildir.
Çoğu zaman “yeni teknolojiye geçelim” önerisi, mevcut kodun artık ekip tarafından anlaşılamadığını gösterir.
Yani sorun teknoloji değil, bilgi kaybıdır.
Bir projeyi React’tan Vue’ya, Django’dan FastAPI’ye, .NET’ten Node.js’e taşımak kulağa teknik bir çözüm gibi gelebilir. Fakat asıl problem iş kurallarının, kenar senaryoların ve sistem davranışlarının bilinmemesi ise, yeni teknoloji aynı belirsizliği sadece başka bir yere taşır.
Baştan yazmak her zaman çözüm değildir.
Bazen yalnızca bilgi devri başarısızlığını gizleyen pahalı bir yoldur.
5. “İki hafta daha” cümlesi sürekli tekrarlanıyor
Bir projede “iki hafta daha” ifadesi bir kez duyulabilir.
İkinci kez duyulduğunda dikkat etmek gerekir.
Üçüncü ve dördüncü kez söylendiğinde artık sorun tahminleme değil, kontrol kaybıdır.
Bu durum genellikle ekibin projenin gerçek durumunu net göremediğini gösterir.
Kodun karmaşıklığı, eksik kalan işler, bağımlılıklar, test edilmemiş alanlar ve teknik riskler artık yönetilebilir olmaktan çıkmıştır.
Bu işaret en tehlikeli olanlardan biridir.
Çünkü proje dışarıdan hâlâ ilerliyor gibi görünebilir. Toplantılar yapılır, görevler taşınır, küçük düzeltmeler tamamlanır.
Ama içeride kimse projenin gerçekten ne zaman biteceğini güvenle söyleyemez.
Bu noktada ihtiyaç duyulan şey daha fazla zaman değil, bağımsız ve net bir teşhistir.
Karar Matrisi: Yeniden Yazmak mı, Kurtarmak mı, İyileştirmek mi, Kapatmak mı?
Yarım kalmış bir proje için tek seçenek “baştan yazmak” değildir.
Genellikle önünüzde dört farklı karar vardır:
1. Mevcut projeyi iyileştirmek
2. Projeyi odaklı bir kurtarma süreciyle ayağa kaldırmak
3. Projeyi sıfırdan yeniden geliştirmek
4. Projeyi kapatmak
Doğru karar, iki şeye bağlıdır:
* Yukarıdaki 5 işaretten kaçını görüyorsunuz?
* Projenin şirket için stratejik değeri hâlâ yüksek mi?
1. Mevcut projeyi iyileştirmek
Eğer projede 1–2 risk işareti varsa ve mevcut ekip hâlâ sistemi anlayabiliyorsa, sıfırdan geliştirmeye gerek olmayabilir.
Bu durumda hedef, mevcut yapıyı daha sağlıklı hale getirmektir.
Neler yapılabilir?
* Kod kalitesi iyileştirilir
* Kritik testler yazılır
* Yayına alma süreci düzenlenir
* Büyük işler daha küçük parçalara bölünür
* Dokümantasyon güçlendirilir
* Teknik borç planlı şekilde azaltılır
Bu yol genellikle 2–4 aylık kontrollü bir iyileştirme süreci gerektirir.
2. Projeyi kurtarma sürecine almak
Eğer 3 veya daha fazla risk işareti varsa ama proje şirket için hâlâ stratejik öneme sahipse, en doğru karar çoğu zaman kurtarma sürecidir.
Bu, mevcut kodun çöpe atılmadan önce profesyonelce incelenmesi anlamına gelir.
Amaç şudur:
> Mevcut kodun ne kadarı kurtarılabilir, ne kadarı yeniden yazılmalı ve ürün ne kadar sürede güvenli biçimde çalışır hale getirilebilir?
Kurtarma süreci genellikle 8–12 haftalık odaklı bir çalışma gerektirir.
Bu süreçte deneyimli bir ekip projeyi inceler, kritik riskleri belirler, canlıya çıkışı engelleyen sorunları çözer ve sistemi devredilebilir hale getirir.
Bizim deneyimimizde birçok yarım kalmış projede kodun %60–70’i doğru müdahaleyle kullanılabilir durumda kalabiliyor.
3. Projeyi sıfırdan yeniden geliştirmek
Bazı projeler gerçekten kurtarılamaz.
Aşağıdaki durumlarda sıfırdan geliştirme daha doğru olabilir:
* Mimari temel baştan yanlış kurulmuştur
* Kod kalitesi sürdürülemeyecek kadar düşüktür
* İş kuralları hatalı modellenmiştir
* Güvenlik açıkları yapısal düzeydedir
* Mevcut kodu anlamak, yeniden yazmaktan daha maliyetlidir
* Ürün stratejisi tamamen değişmiştir
Ancak sıfırdan geliştirme kararı aceleyle verilmemelidir.
Çünkü bu karar genellikle 6–12 ay yeni süre, ciddi ek bütçe ve yeni riskler anlamına gelir.
“Mevcut sistem kötü” demek yeterli değildir.
Doğru soru şudur:
> “Mevcut sistemi kurtarmanın maliyeti ve riski, sıfırdan geliştirmenin maliyet ve riskinden gerçekten daha mı yüksek?”
Bu sorunun cevabı ölçülmeden verilen yeniden geliştirme kararları, ikinci bir yazılım mezarlığı yaratabilir.
4. Projeyi kapatmak
Bazen en doğru karar projeyi kurtarmak ya da yeniden yazmak değil, kapatmaktır.
Eğer projenin stratejik değeri kalmadıysa, iş ihtiyacı değiştiyse veya beklenen fayda artık yatırım maliyetini karşılamıyorsa, projeyi taşımaya devam etmek sadece görünmeyen maliyet üretir.
Kapatma kararı başarısızlık değildir.
Aksine, şirketin kaynaklarını daha değerli alanlara yönlendirmesini sağlayan sağlıklı bir yönetim kararı olabilir.
Önemli olan, kapatmadan önce şu soruları yanıtlamaktır:
* Bu projeden hangi bilgiler öğrenildi?
* Kullanılabilir kod, veri veya modül var mı?
* Müşteri, kullanıcı ya da operasyon tarafında etkisi olacak mı?
* Yerine geçecek çözüm nedir?
* Bu hatanın tekrar etmemesi için süreçte ne değişmeli?
Her proje kurtarılmak zorunda değildir.
Ama her proje doğru teşhis edilmelidir.
Yazılım Projesi İncelemesi Nasıl Yapılır?
Internative’in Yazılım Mezarlığı yaklaşımında, yarım kalmış bir proje dört aşamada incelenir.
Amaç, duygusal ya da panik bir karar yerine, ölçülebilir bir karar vermektir.
1. Kod ve mimari inceleme
İlk aşamada projenin teknik gerçekliği analiz edilir.
Bu aşamada şu sorulara cevap aranır:
* Kod deposunda toplam yapı nasıl?
* Hangi modüller tamamlanmış, hangileri yarım?
* Bağımlılıklar güncel mi?
* Güvenlik riski taşıyan alanlar var mı?
* Kullanılmayan veya ölü kod var mı?
* Test kapsamı ne seviyede?
* Gerçek mimari nasıl çalışıyor?
* Dokümandaki mimari ile kodun gerçek yapısı aynı mı?
Burada amaç kusur aramak değildir.
Amaç, projenin gerçekten hangi durumda olduğunu net biçimde görmektir.
2. Bilgi ve ekip geçmişi analizi
Yarım kalan projelerde sorun çoğu zaman koddan çok bilgi kaybıdır.
Bu yüzden ikinci aşamada şu sorulara bakılır:
* Projede kim hangi bölümü geliştirdi?
* Kritik kararları kim aldı?
* Bu kararlar dokümante edildi mi?
* Hangi bilgiler sadece eski ekibin hafızasında kaldı?
* Hangi geliştiricilere hâlâ ulaşılabiliyor?
* Projenin iş kuralları nerede tutuluyor?
* Kullanıcı senaryoları yazılı mı?
Bir projeyi devralmanın en zor kısmı kodu açmak değil, karar geçmişini anlamaktır.
Bu aşama, projenin kurtarılabilir olup olmadığını anlamak için kritiktir.
3. Karar matrisi
Teknik ve bilgi analizi tamamlandıktan sonra proje dört seçenek üzerinden değerlendirilir:
* Mevcut projeyi iyileştirmek
* Kurtarma sürecine almak
* Sıfırdan yeniden geliştirmek
* Kapatmak
Her seçenek için ayrı ayrı şu başlıklar çıkarılır:
* Tahmini süre
* Tahmini maliyet
* Teknik risk
* İş riski
* Ekip ihtiyacı
* Başarı olasılığı
Bu aşamanın sonunda amaç “ne yapalım?” sorusuna net cevap verebilmektir.
4. Yol haritası
Karar verildikten sonra seçilen yol için uygulanabilir bir plan hazırlanır.
Bu plan genellikle şu başlıkları içerir:
* İlk 2 haftada yapılacak kritik işler
* Canlıya çıkışı engelleyen problemler
* Düzeltilmesi gereken mimari alanlar
* Yazılması gereken testler
* Devredilmesi gereken bilgiler
* Gerekli ekip yapısı
* Riskler ve önlemler
* 8–12 haftalık uygulama planı
İyi bir inceleme süreci sadece “proje kötü” ya da “proje iyi” demez.
Ne yapılması gerektiğini, hangi sırayla yapılacağını ve bunun neye mal olacağını gösterir.
Gerçek Bir Vaka: 200.000 Dolarlık Yarım Projeyi 48.000 Dolara Kurtarmak
Geçtiğimiz dönemde bir müşterimiz bizimle iletişime geçti:
> “6 ay önce 200.000 dolar ödedik. Uygulama çalışmıyor. Önceki ekip ortadan kayboldu. Ne yapmalıyız?”
İlk varsayım şuydu:
> “Bu proje muhtemelen baştan yazılmalı.”
Ancak inceleme sonucunda farklı bir tablo gördük.
Bulgular
Kod kalitesi beklenenden iyiydi.
Önceki ekip teknik olarak zayıf değildi; sadece proje yorgunluğu ve bilgi devri problemi vardı.
Mimari genel olarak sağlamdı.
Mikroservis yapısı projeye uygundu.
Ana sorun, son iki modülün hiç canlıya alınmamış olmasıydı.
Ayrıca önceki ekip ayrılırken yeterli bilgi devri yapılmamıştı.
Karar
Bu proje sıfırdan yazılmamalıydı.
Doğru karar, kurtarma sürecine almaktı.
Sonuç
8 haftalık çalışma yapıldı.
2 deneyimli yazılım mühendisi projeye dahil oldu.
Mevcut kodun %72’si kullanılabilir durumda kaldı.
Eksik kalan iki modül yeniden geliştirildi.
Toplam maliyet 48.000 dolar oldu.
Uygulama canlıya alındı ve çalışır hale geldi.
Eğer ilk varsayımla hareket edilseydi, müşteri muhtemelen başka bir firmaya projeyi sıfırdan yazdıracaktı.
Bu da yaklaşık 300.000 dolar ek bütçe, 8–12 ay yeni süre ve ciddi bir başarı riski anlamına gelecekti.
Bu nedenle yarım kalmış projelerde ilk soru “baştan mı yazalım?” olmamalıdır.
İlk soru şu olmalıdır:
> “Bu projenin ne kadarı gerçekten kurtarılabilir?”
Software Autopsy: Ücretsiz 30 Dakikalık Audit
Elinizde yarım kalmış, takılmış ya da güven vermeyen bir yazılım projesi varsa, panikle yeniden geliştirme kararı vermeden önce projeyi birlikte değerlendirebiliriz.
30 dakikalık ücretsiz ön inceleme görüşmesinde amacımız satış yapmak değil, doğru kararı vermenize yardımcı olmaktır.
Görüşme öncesinde hazırlamanız gerekenler
Mümkünse aşağıdaki bilgileri paylaşmanız yeterlidir:
* Kod deposu bağlantısı veya örnek kod parçaları
* Projeyi özetleyen 5–6 cümlelik kısa açıklama
* Mevcut ekip durumu
* Projede şu an takıldığınız ana problem
* Canlıya çıkış, müşteri kullanımı veya iç operasyon açısından kritik tarih varsa bu bilgi
Gerekirse gizlilik sözleşmesi imzalayabiliriz.
Görüşmede ne yapıyoruz?
30 dakika içinde şu başlıkları birlikte değerlendiriyoruz:
* Projenizde yukarıdaki 5 işaretten hangileri var?
* Proje iyileştirilmeli mi, kurtarılmalı mı, baştan mı geliştirilmeli, yoksa kapatılmalı mı?
* Her seçenek için yaklaşık süre ve maliyet aralığı ne olabilir?
* İlk adım olarak ne yapılmalı?
* Internative bu proje için doğru ekip mi?
Eğer sizin için doğru çözüm bizsek, bir sonraki adımı netleştiririz.
Eğer biz uygun ekip değilsek, hangi tür firma ya da çalışma modelinin daha doğru olabileceğini açıkça paylaşırız.
Çünkü yarım kalmış bir yazılım projesinde en pahalı karar, çoğu zaman panikle verilen ilk karardır.
30 dakikalık ücretsiz yazılım projesi ön inceleme görüşmesi planlayın.
Kurumsal Yazılım Geliştirme Şirketi Seçerken Sormanız Gereken 12 Soru