Yazılım projeleri neden gecikir? Sekiz yılda öğrendiklerimiz
Geciken projelerin ortak özelliği, geliştirme hızının düşük olması değildir. Geriye dönüp baktığımızda kaybedilen zamanın büyük bölümü beklemede geçmiş oluyor: bir karar, bir erişim, bir içerik, bir onay. Kod yazma süresi çoğu projede tahminlere yakın çıkar; onu çevreleyen her şey çıkmaz.
1. Karar bekleme süresi
“Bu ekranda hangi alanlar zorunlu olacak?” sorusu bir haftada cevaplanırsa, o bir hafta doğrudan takvime eklenir. Çözüm, karar verecek kişiyi projenin başında netleştirmek ve karar için son tarih koymaktır. Karar gelmezse varsayılan bir seçenekle ilerlenip sonradan değiştirilebileceğini yazılı olarak belirlemek, beklemeden çok daha ucuza gelir.
2. Kapsamın sessizce büyümesi
Kapsam nadiren büyük taleplerle büyür; “bir de şunu ekleyelim, yarım saatlik iş” cümleleriyle büyür. Bu eklemelerin her biri gerçekten küçüktür; toplamı değildir. İşe yarayan tek yöntem, her eklemeyi anında görünür kılmaktır: eklendi, şu kadar süre getirdi, teslim tarihi şu oldu. Kapsam değişimini yasaklamak gerçekçi değildir; görünmez kalmasını engellemek gerçekçidir.
3. Entegrasyon sürprizleri
Dış sistem entegrasyonları neredeyse her zaman tahminden uzun sürer. Nedeni teknik zorluk değil, erişim ve dokümantasyon eksikliğidir: test ortamı yoktur, yetkili kişi tatildedir, doküman güncel değildir. Bu yüzden entegrasyonu projenin sonuna bırakmak en pahalı karardır. İlk hafta içinde tek bir uçtan uca çağrı yapıp çalıştığını görmek, ilerideki sürprizlerin çoğunu erken açığa çıkarır.
4. Veri göçünün küçümsenmesi
Eski sistemden gelen veri asla beklendiği kadar temiz değildir. Göç işi çoğu projede tek satırlık bir madde olarak planlanır ve sonra haftalar alır. Doğru yaklaşım, gerçek veriyle deneme göçünü projenin ortasında yapmaktır — sonunda değil.
5. Test için ayrılmayan süre
Takvimlerde test genelde son iki güne sıkışır ve o iki gün her zaman yetmez. Kabul kriterlerini işin başında yazmak, testi sona bırakmanın önüne geçer: neyin “bitti” sayılacağı baştan belliyse, test bir aşama değil sürekli bir kontrol haline gelir.
Ne yapıyoruz?
Bu beş kalemi projelerin başında yazılı hale getiriyoruz: kararı kim verecek, kapsam değişikliği nasıl kaydedilecek, entegrasyon ilk hafta ne zaman denenecek, deneme göçü hangi tarihte yapılacak ve kabul kriteri ne. Bu liste sihirli değil; ama gecikmeyi sürprizden bilinen riske çeviriyor. Bilinen risk yönetilebilir, sürpriz yönetilemez.