Yazılım Projeleri Neden Başarısız Olur? Beş Gerçek Sebep

Teknoloji nadiren sorundur

Başarısız projelerin çoğunda kod çalışıyordu. Sorun, çalışan kodun ihtiyacı karşılamamasıydı.

Bu yüzden risk yönetimi teknik değil, yönetsel bir konudur.

Sebep bir: kapsam yazılı değil

"Bir CRM yapalım" cümlesi kapsam değildir. Kimin hangi ekranı hangi amaçla kullanacağı yazılmamışsa, teslimde herkes farklı bir şey bekler.

Çözüm, ilk sürümün kapsamını ekran ve akış düzeyinde yazılı hale getirmektir. Bu belge sözleşmenin parçası olmalıdır.

Kapsam dışı olanları da yazmak, kapsam içi olanları yazmak kadar önemlidir.

Sebep iki: karar verecek kişi belli değil

Projede her toplantıya farklı kişiler katılıyor ve her biri farklı yön veriyorsa, ekip sürekli geri dönüş yapar.

Tek bir karar merci tanımlanmalıdır. Bu kişi, departmanlar arası çelişkileri çözme yetkisine sahip olmalıdır.

Karar gecikmesi, en sık görülen gecikme sebebidir ve genellikle geliştirici tarafına fatura edilir.

Sebep üç: veri göçü küçümsenir

Eski sistemdeki veri, yeni sisteme taşınmak zorundadır ve bu iş neredeyse her zaman tahmin edilenden uzun sürer.

Eski veride tutarsızlıklar, eksik alanlar ve belgelenmemiş kurallar bulunur. Bunları keşfetmek zaman alır.

Kendi göç projelerimizde en çok vakit alan kısım veriyi taşımak değil, eski sistemin gerçekte ne anlattığını çözmek oldu. Alan adları ile içerikleri her zaman uyuşmuyor.

Göç için ayrı bir takvim kalemi açın ve gerçek veriyle en az iki deneme yapın.

Sebep dört: kullanıcı benimsemiyor

Teknik olarak kusursuz bir sistem, sahada kullanılmıyorsa başarısızdır.

En sık sebep, sistemin kullanıcının işini kolaylaştırmak yerine ek bir kayıt yükü getirmesidir.

Çözüm, kullanıcıyı tasarım aşamasında sürece dahil etmek ve ilk sürümde onun en çok acı çektiği işi çözmektir.

Eğitim ve geçiş desteği, proje bütçesinin gerçek bir kalemidir.

Sebep beş: her şeyi aynı anda yapmak

Tüm departmanları kapsayan, on sekiz ayda teslim edilecek projeler risklidir. Teslim gününe kadar hiçbir fayda üretilmez ve ihtiyaçlar o sürede değişir.

Doğru yaklaşım, en kritik süreci önce canlıya almak ve üzerine eklemektir. Erken canlıya çıkan sistem, gerçek geri bildirim üretir.

Erken uyarı işaretleri

Toplantılarda aynı konular tekrar açılıyorsa kapsam netleşmemiştir.

Test ortamına kimse bakmıyorsa benimsenme sorunu geliyordur.

Veri göçü sürekli erteleniyorsa, projenin sonunda büyük bir sürpriz vardır.

Haftalık ritim kurun

Belirsizliğin en iyi panzehiri düzenli ve kısa toplantılardır.

Haftada bir, otuz dakikalık bir toplantıda üç şey konuşulur: ne bitti, sırada ne var, neyi bekliyoruz.

Bekleyen kararlar listesi görünür tutulmalıdır. Karar gecikmeleri, gecikmenin en büyük tek sebebidir ve genellikle kayıt altına alınmaz.

Her toplantının çıktısı yazılı olmalıdır; sözlü mutabakatlar üç hafta sonra farklı hatırlanır.

Erken canlıya çıkmanın değeri

Küçük bir kapsamla erken canlıya çıkmak, projenin en değerli risk azaltıcısıdır.

Gerçek kullanıcı, gerçek veriyle çalıştığında varsayımların hangisinin yanlış olduğu birkaç günde ortaya çıkar.

On sekiz ay sonunda teslim edilen sistemlerde bu öğrenme hiç yaşanmaz ve tüm hatalar aynı anda görünür.

Erken sürüm eksik olacaktır; bu bir kusur değil, tasarımın parçasıdır. Önemli olan, o eksikliğin bilinçli seçilmiş olmasıdır.