Yazılım Projeleri Neden Başarısız Olur? Sahadan 6 Neden

Yazılım projelerinin başarısızlık oranı, sektörün en çok konuşulan ama en az ders çıkarılan konusudur. Dikkat çekici olan şudur: başarısız projelerin çoğunda kod kötü değildi. Sorun neredeyse her zaman kapsam, iletişim ve karar mekanizmasındaydı. Aşağıda sahada tekrar tekrar görülen altı nedeni ve her biri için uygulanabilir önlemleri ele alıyoruz.

1. Kabul kriterleri yazılı değil

"Personel modülü de olsun" cümlesiyle başlayan bir iş, üç ay sonra "biz bunu böyle istememiştik" cümlesiyle biter. Sözlü mutabakat, herkesin kafasında farklı bir sistem kurmasına izin verir.

Önlem: Her istek için bir cümlelik kabul kriteri yazın: hangi koşulda tamamlanmış sayılır? Bu cümle hem geliştiricinin hem müşterinin aynı şeyi anlamasını sağlar ve teslimde tartışmayı bitirir.

2. Karar verecek muhatap belirsiz

Beş kişinin fikir verdiği ama kimsenin karar vermediği projeler, çelişen taleplerle ilerler. Bir toplantıda onaylanan akış, ertesi hafta başka bir yöneticinin itirazıyla değişir; iki haftalık iş çöpe gider.

Önlem: Proje başında tek bir karar sahibi belirlenmelidir. Diğerleri fikir verir, karar tek yerden çıkar. Bu kişi belirlenmediğinde proje, en son konuşan kişinin isteğine göre yön değiştirir.

3. Kapsam sessizce büyüyor

Kapsam kayması ani olmaz; her toplantıda eklenen "küçük bir şey"lerin toplamıdır. Tek tek bakıldığında hepsi makuldür, toplamı ise projeyi iki katına çıkarır.

Önlem: Her ekleme için üç seçenekten biri seçilmelidir: süreyi uzat, başka bir maddeyi çıkar ya da sonraki sürüme bırak. Üçü de seçilmiyorsa, ekleme kabul edilmemiştir; ertelenmiştir.

4. Kullanıcı süreçten kopuk

Sistemi kullanacak kişiler geliştirme boyunca hiç görmezse, teslimde karşılaşılan tepki neredeyse her zaman olumsuz olur. Üstelik bu tepki haklıdır: gerçek iş akışı, toplantı odasında anlatılandan farklıdır.

Önlem: İlk çalışan ekran çıktığında kullanıcıya gösterin. Yarım bir ekranı görmek, tamamlanmış yanlış bir sistemi görmekten çok daha ucuzdur. İki haftada bir yapılan 20 dakikalık gösterimler, projelerin yönünü koruyan en ucuz araçtır.

5. Tahminler gerçekçi değil

Yazılımda tahmin, kodlama süresini ölçmeye çalışır; oysa gerçek süre analiz, test, düzeltme, geri bildirim bekleme ve entegrasyon sürelerini de içerir. Bu yüzden "iki günlük iş" gerçekte bir hafta sürer.

Önlem: Geçmiş işlerin gerçekleşen sürelerini kaydedin ve yeni tahminleri buna dayandırın. Ayrıca büyük işleri parçalayın: bir haftadan uzun tahmin edilen her iş, aslında tahmin edilemeyecek kadar belirsizdir.

6. Teknik borç görünmez

Baskı altında alınan kısayollar normaldir; sorun bunların kaydedilmemesidir. Bir yıl sonra hiç kimse neden her değişikliğin bu kadar uzun sürdüğünü açıklayamaz.

Önlem: Bilinçli kısayolları görev listesine "borç" olarak yazın ve her sürümde bir miktarını kapatın. Görünür borç yönetilebilir, görünmez borç projeyi yavaşça durdurur.

Erken uyarı işaretleri

Aşağıdaki işaretlerden üçü aynı anda görülüyorsa proje risk altındadır:

• Toplantı notları tutulmuyor, kararlar sözlü kalıyor.
• Test ortamı yok; denemeler canlı sistemde yapılıyor.
• Görev listesi tek kişinin aklında.
• "Şu an göstermeye uygun bir şey yok" cümlesi üst üste üçüncü kez duyuluyor.
• Herkes meşgul ama teslim edilen bir parça yok.

Toplantı değil, yazılı iz bırakmak

Yazılım projelerinde alınan kararların büyük bölümü toplantıda konuşulur ve hiçbir yere yazılmaz. Üç ay sonra "neden böyle yapmıştık" sorusunun cevabı kimsede yoktur; en kötüsü, aynı tartışma baştan yapılır.

Çözüm ağır bir belgelendirme süreci değildir. Her önemli karar için üç satır yeterlidir: karar neydi, hangi seçenekler değerlendirildi, neden bu seçildi. Bu notlar görev takip sisteminde veya depodaki bir dosyada tutulabilir. Uzun vadede en değerli belge, kodun ne yaptığını anlatan değil, neden öyle yapıldığını anlatan belgedir; çünkü kod zaten kendini anlatır, gerekçe ise kaybolur.

Kurtarma: yürüyen bir projeyi düzeltmek

Sorun fark edildiğinde yapılacak ilk iş kapsamı dondurmaktır. Ardından mevcut durumun dürüst envanteri çıkarılır: ne bitti, ne yarım, ne başlamadı? Sonra en küçük çalışan sürüm tanımlanır ve yalnızca ona odaklanılır. Yarım kalmış beş modül yerine bitmiş bir modül, hem moral hem güven açısından dönüm noktasıdır. Konunun klasik kaynağı olarak PMI yayınları süreç çerçevesi sunar; ancak asıl fark, çerçeveden çok disiplinli uygulamada ortaya çıkar.

Sonuç

Projeleri batıran şey nadiren teknolojidir. Yazılı kabul kriteri, tek karar sahibi, kontrollü kapsam, erken kullanıcı geri bildirimi, gerçekçi tahmin ve görünür teknik borç; bu altı madde uygulandığında başarısızlık nedenlerinin çoğu ortadan kalkar. Geriye kalan teknik sorunlar ise zaten çözülebilir sorunlardır.