Yazılım projeleri neden batar?

Yarım kalmış yazılım projelerinin ortak noktası nadiren teknik oluyor. Aşağıdaki altı sebep, devraldığımız projelerde en sık gördüklerimiz.

1. Çözülecek problem hiç tanımlanmadı

Proje "bir CRM lazım" diye başlıyor. Kimse "hangi işi kolaylaştıracak" sorusunu sormuyor. Altı ay sonra ortada bir CRM var ama kimse kullanmıyor, çünkü mevcut yöntem hâlâ daha hızlı.

Önlemi: Projeye başlamadan, çözülecek problemi tek cümleyle yazın. Yazamıyorsanız henüz hazır değilsiniz. "Satış ekibi teklif geçmişini bulmak için ortalama 15 dakika harcıyor" iyi bir cümle. "Dijitalleşmek istiyoruz" değil.

2. Her şey ilk sürüme sıkıştırıldı

Kapsam listesi 60 maddeyle başlıyor, hepsi "olmazsa olmaz". Sekiz ay sonra hiçbiri tam bitmemiş oluyor.

Önlemi: İlk sürümde neyin olmayacağına karar verin. Bu, ne olacağına karar vermekten daha önemli ve daha zor. Kullanıcının ilk gün yapacağı tek işi çalıştırın, gerisi sonra.

3. Kullanacak kişi hiç konuşulmadı

Sistemi yönetici tarif ediyor, sahada başkası kullanıyor. Yayına çıkınca ortaya çıkıyor ki gerçek akış tarif edilenden farklı.

Önlemi: Keşif aşamasında işi fiilen yapan kişiyle konuşun. Yöneticinin anlattığı süreç, çoğu zaman olması gerekeni anlatıyor; sahadaki kişi olanı anlatıyor.

4. Aylarca hiçbir şey görülmedi

Proje başlıyor, dört ay sessizlik, sonra bir demo. Demo'da beklenenden farklı bir şey çıkıyor ve dört ay çöpe gidiyor.

Önlemi: İki haftada bir çalışan bir parça isteyin. Slayt değil, tıklanabilir bir şey. Yanlış yön dört ay değil iki hafta kaybettirsin.

5. Karar verecek kişi belli değil

Üç kişi farklı şey istiyor, hiçbiri son sözü söyleyemiyor. Geliştirme her toplantıda yön değiştiriyor.

Önlemi: Tek bir karar verici belirleyin. Diğerleri görüş bildirir, o karar verir. Bu kişi ayrıca hızlı cevap verebilecek durumda olmalı, çünkü projelerde en çok zamanı bekleyen kararlar yakıyor.

6. Yayın bir bitiş sanıldı

Sistem canlıya alınıyor, ekip dağılıyor. İlk gerçek kullanımda çıkan sorunlara bakacak kimse kalmıyor ve kullanıcılar eski yöntemlerine dönüyor.

Önlemi: Yayından sonraki ilk bir ayı projenin parçası sayın. Gerçek kullanım her zaman yeni şeyler gösteriyor ve o an müdahale edilmezse sistem terk ediliyor.

Erken uyarı işaretleri

Bir proje bir anda batmıyor. Aylar önce sinyal veriyor. Aşağıdakilerden ikisi aynı anda varsa yön değiştirme zamanı gelmiştir.

Toplantılarda aynı konu tekrar açılıyor. Karar alınmış ama yazılmamış demektir. Yazılmayan karar alınmamış sayılıyor.

"Şunu da ekleyelim" cümlesi haftada birden fazla duyuluyor. Kapsam kontrolsüz büyüyor.

Demo tarihleri sürekli erteleniyor. Gösterilecek çalışan bir parça yoksa ilerleme de yoktur.

Kimse sistemi kendi işinde denemiyor. Ekip kendi ürettiği şeyi kullanmıyorsa müşteri de kullanmayacak.

Sorular cevapsız kalıyor. Geliştirici bir hafta boyunca cevap bekliyorsa proje o hafta ilerlemiyor demektir.

Batan projeyi kurtarmak mümkün mü?

Genellikle mümkündür ama yöntem geliştirmeye devam etmek değildir.

İşe yarayan yaklaşım şu sırayla ilerliyor:

1. Durun. Yeni özellik eklemeyi bırakın. Batan projede en pahalı şey, yanlış yöne devam edilen her haftadır.
2. Ne olduğunu yazın. Hangi parçalar çalışıyor, hangileri yarım, hangileri hiç başlamamış? Bu liste çoğu zaman herkesin sandığından farklı çıkıyor.
3. Tek bir işi seçin. Sistemin bir tek işi baştan sona yapmasını sağlayın. Bir tane çalışan akış, on tane yarım akıştan değerlidir.
4. Onu gerçek kullanıcıya verin. Kullanılmayan bir sistem hakkında alınan her karar tahmindir.

Bu dört adımdan sonra genellikle net bir cevap çıkıyor: ya proje kurtarılabilir durumdadır ve devam edilir, ya da devam etmenin maliyeti baştan yazmaktan yüksektir.

İkincisi çıktığında bunu söylemek zor ama doğru olandır. Devraldığımız bazı projelerde verdiğimiz tavsiye "baştan yazmayın" oldu; bazılarında ise "bu kodla devam etmeyin" oldu. İkisi de aynı incelemenin sonucudur.

Devraldığımız projelerde gördüğümüz ortak işaret

Yarım kalmış bir sistemi incelerken ilk baktığımız şey kod değil, kimin ne zaman ne karar verdiğinin yazılı olup olmadığı. Mimari kararların gerekçesi yazılmamışsa, o sistemi devralan herkes aynı tartışmaları baştan yapıyor.

Bu yüzden teslim ettiğimiz her projede kararların gerekçeleri de yazılı olarak gidiyor. Kodu okumak mümkün; neden öyle yazıldığını tahmin etmek mümkün değil.

---

Yarım kalmış bir projeniz varsa durumunu birlikte çıkarabiliriz. Bazen çıkan sonuç "baştan yazmayın" oluyor. Özel yazılım geliştirme sayfasında nasıl çalıştığımızı anlattık.