Yazılım projeleri neden yarıda kalır?

Yarım kalan yazılım projelerinin çoğunda insanlar teknik bir sebep arar. “Yanlış teknoloji seçilmiş”, “yazılımcı yetersizmiş”, “kod kötüymüş.”

Bu teşhis neredeyse her zaman yanlıştır. Projeleri batıran şey teknik değil, yönetimseldir. Ve altı başlıkta toplanır.

1. Kapsam yazılı olarak sabitlenmemiştir

En büyük sebep budur.

Proje sözlü mutabakatla başlar. Herkesin kafasında farklı bir sistem vardır ama kimse bunu fark etmez, çünkü hiç kimse tek bir belgeye bakıp “evet, tam olarak bu” demek zorunda kalmamıştır.

Geliştirme ilerledikçe fark ortaya çıkar. Müşteri “bu da olacaktı” der, tedarikçi “bu kapsamda yoktu” der. İkisi de haklıdır, çünkü kapsam hiç yazılmamıştır.

Önlemi: Kapsam belgesinde olması gerekenler listesinden çok, olmayacaklar listesi önemlidir. İlk sürümde neyin kapsam dışı olduğunu yazılı hale getirmek, projeyi kurtaran tek satırdır.

2. Karar verecek tek bir kişi yoktur

Beş kişilik bir komite kurulur. Her toplantıda farklı biri farklı bir yön söyler. Tedarikçi kime uyacağını bilemez, iki hafta bekler, sonra kendi kararını verir ve o karar kimseyi memnun etmez.

Önlemi: Kurum tarafında tek bir karar sahibi olmalı. Bu kişi her şeyi bilmek zorunda değil; sadece “evet, böyle yapıyoruz” diyebilme yetkisine sahip olmalı.

3. Sahadaki kullanıcıyla hiç konuşulmamıştır

Sistem yönetimin anlattığı sürece göre yazılır. Devreye alındığında sahadaki kişi bakar ve “biz böyle çalışmıyoruz ki” der.

Yöneticinin anlattığı süreçle sahada işleyen süreç neredeyse hiçbir zaman aynı değildir. Aradaki fark kötü niyet değil, görünürlük eksikliğidir, yönetim istisnaları görmez, saha ise sadece istisnalarla uğraşır.

Önlemi: Kapsam çıkarılırken sahaya inilmeli. Puantajı tutan şefle, kasadaki kasiyerle, depodaki sayım görevlisiyle konuşulmalı.

4. İlk sürüm çok büyük tutulmuştur

Sekiz aylık bir plan yapılır. Sekiz ay boyunca kimse çalışan bir şey görmez. Sekizinci ayda ortaya çıkan sistem, sekiz ay önceki varsayımlara göre yazılmıştır, ve o varsayımların bir kısmı artık geçerli değildir.

Önlemi: İlk sürüm dar olmalı ve gerçekten devreye alınmalı. Tek bir süreci baştan sona çalışır hale getirip kullandırmak, on süreci yarım bırakmaktan kıyaslanamayacak kadar değerlidir.

5. Çalışan kanıt hiç görülmemiştir

Bu, en pahalı hatadır. Bütçenin tamamı, sistemin işe yarayıp yaramayacağı hiç test edilmeden harcanır.

Danışmanlık verdiğim işlerde ısrar ettiğim tek şey budur: büyük parayı harcamadan önce, gerçek verinizle çalışan bir prototip görün. Bütçenin küçük bir kısmı harcanmışken kararınızın doğru olup olmadığını anlarsınız.

Yarım kalan projelerin neredeyse tamamında bu adım hiç yaşanmamıştır.

6. Sistem tek kişiye bağımlıdır

Projeyi bir kişi yazmıştır. Dokümantasyon yoktur. O kişi ayrılır ve sistem bir anda kimsenin dokunamadığı bir kutuya dönüşür.

Bu, teknik değil kurumsal süreklilik meselesidir. Kaynak kodun sizde olması, sunucuların sizin hesabınızda olması ve sistemin nasıl çalıştığının yazılı olması pazarlık konusu değildir.

Önlemi: Sözleşmeye üç madde: kaynak kod mülkiyeti, sunucu ve erişim sahipliği, devir dokümantasyonu.

Proje zaten tıkandıysa

Suçlu aramadan önce durumu ölçün. Bağımsız bir teknik durum tespiti şunlara bakar:

• Veri: tutarlı mı, yedek alınıyor mu, geri dönüş denenmiş mi?
• Kod: başka biri okuyup değiştirebilir mi?
• Erişimler: sunucu, alan adı, mağaza hesapları kimde?
• Güvenlik: açıkta duran şifreler, güncellenmemiş bağımlılıklar
• Sözleşme: mülkiyet ve devir maddeleri var mı?

Sonuç üç karardan biri olur: kurtar, devral ve düzelt, ya da kademeli olarak yeniden yaz.

Buradaki en önemli uyarı şu: “kodu beğenmedim, baştan yazalım” en kolay ve genellikle en pahalı cevaptır. O kodun içinde yıllarca birikmiş, hiçbir yere yazılmamış iş kuralları vardır. Sıfırdan yazma kararı, onları da çöpe atma kararıdır.

Özet

• Kapsamı yazın; özellikle kapsam dışını yazın.
• Kurum tarafında tek karar sahibi belirleyin.
• Sahadaki kullanıcıyla konuşun.
• İlk sürümü küçük tutun ve gerçekten devreye alın.
• Büyük bütçeyi harcamadan önce çalışan kanıt görün.
• Kaynak kod, sunucular ve dokümantasyon sizde olsun.

Elinizde tıkanmış bir proje varsa, önce ne durumda olduğunu net bilmeniz gerekir. Durum tespiti tipik olarak 3-5 iş günü sürer ve sonunda yönetime sunulabilir bir raporla biter.