Yazılım projesinde kapsam neden yazılı olmalı?
En sık görülen sebep budur. Proje “şirketin ihtiyaçlarını karşılayacak bir sistem” tanımıyla başlar. Bu tanım, sonradan gelen her talebi kapsam içi gösterir ve hiçbir teslimi tamamlanmış saymaz.
Sonuç şudur: geliştirme durmaz ama proje de bitmez. Ekip çalışır, fatura kesilir, kimse kötü niyetli değildir; yine de sistem canlıya çıkmaz. Çünkü “bitti” demenin bir ölçütü yoktur.
Çözüm basittir ve nadiren uygulanır: neyin dahil olduğu kadar neyin dahil olmadığı da yazılır, teslim fazlara bölünür ve her fazın kabul kriteri baştan belirlenir.
Teknik sahiplik nedir, projede kim üstlenir?
Şirket tarafında kararı verecek bir teknik muhatap yoksa, kararlar toplantıya ve toplantıdaki en yüksek sese kalır. Birim yöneticileri kendi işlerini savunur, tedarikçi en az itiraz gelen yolu seçer ve ortaya kimsenin sahiplenmediği bir sistem çıkar.
Bu boşluk çoğunlukla farkedilmez, çünkü herkes toplantıdadır. Ama karar alınmıyordur; ertelenmektedir.
Bunun karşılığı bir kadro değil, tanımlı bir roldür: kapsamı kesen, çelişen talepler arasında seçim yapan ve teknik borcu görünür tutan bir sahip. Bu rol şirket içinden çıkabilir; çıkmıyorsa dışarıdan üstlenilmesi gerekir.
Yeni sisteme geçiş neden tek seferde yapılmaz?
Eski sistemden yeni sisteme belirli bir günde topluca geçme planı, yarıda kalan projelerin ortak özelliğidir. O gün geldiğinde ya veri hazır değildir, ya kullanıcı hazır değildir, ya da her ikisi.
Bir kez ertelenen geçiş, ikinci kez daha kolay ertelenir. Üçüncüden sonra proje fiilen durmuştur; kimse resmen iptal etmez.
Çalışan kurgu şudur: sistem birim birim ya da süreç süreç devreye alınır, bir süre eski yapıyla birlikte çalışır ve geri dönüş yolu her fazda açık tutulur. Yavaş görünür; tek seferlik geçişten daha hızlı biter.
Teknik borç nedir, nasıl ölçülür?
Aceleyle alınan her teknik karar, ilerideki bir maliyettir. Sorun kararın kendisi değil, kaydedilmemesidir. Kayıt yoksa borç birikir ve bir gün “basit bir değişiklik” haftalar sürmeye başlar.
O noktada ekip yavaş görünür, oysa yavaşlayan ekip değil sistemdir. Yönetim ekibi değiştirir ve borç yerinde kalır; yeni ekip aynı duvara çarpar.
Borcun yazılı ve görünür tutulması, ekibin performansı ile sistemin durumunu ayırt edilebilir kılar. Bu ayrım yapılmadan verilen her yönetim kararı yanlış hedefe atılır.
Yarıda kalmış yazılım projesi nasıl kurtarılır?
İlk yapılacak şey geliştirmeye devam etmek değildir. Önce durumun ölçülmesi gerekir: kod tabanının hangi bölümü kurtarılabilir, veri modeli kullanılabilir mi, hangi entegrasyon çalışıyor, hangi süreç gerçekten sistemde.
Bu ölçüm bitmeden verilen her tahmin uydurmadır ve genelde ikinci bir yarıda kalmış proje üretir. Ölçüm sonunda üç cevaptan biri çıkar: devam edilebilir, kısmen kurtarılır, ya da baştan yazmak daha ucuzdur. Üçüncüsü de meşru bir cevaptır ve dürüstçe söylenmesi gerekir.
Devraldığımız işlerde bu sırayı bozmuyoruz: önce yazılı durum raporu, sonra karar, sonra geliştirme.