Yazılım projeleri neden yarıda kalır, nasıl önlenir?
Yarıda kalan projelerde sebep neredeyse hiçbir zaman teknik değildir. Altı sebep öne çıkar: kapsamın yazılı olmaması, karar verecek kişinin belirsizliği, veri hazırlığının hiç başlamaması, beklenti farkı, projenin tek kişiye bağlı kalması ve çıktının çok geç gösterilmesi. Altısının da panzehiri aynıdır: küçük parçalar halinde, erken ve çalışan biçimde teslim etmek.
Altı sebep
Aşağıdaki liste, hem bizim yürüttüğümüz hem de devraldığımız yarım projelerden çıkardığımız ortak sebepler.
| Sebep | Belirtisi | Önlemi |
|---|---|---|
| Kapsam belirsizliği | Her toplantıda yeni istek | Kapsam ve kapsam dışı yazılı, değişiklik ayrı onaylı |
| Karar boşluğu | Konular haftalarca askıda | Karar verebilen tek bir sahip |
| Veri hazırlığı | Test için gerçek veri yok | Temizlik projeden önce başlar |
| Beklenti farkı | “Biz böyle anlamamıştık” | Ekran üzerinden erken gösterim |
| Tek kişiye bağlılık | O kişi ayrılınca proje durur | En az iki kişi bilsin, belgeler teslim edilsin |
| Geç teslim | Aylarca görünür çıktı yok | İki-üç haftada bir çalışan parça |
En kritik önlem: erken ve çalışan teslim
Bir yıl süren ve sonunda tek seferde teslim edilen projelerde yanlış anlaşılma ancak sonda ortaya çıkar. O noktada geri dönmek hem pahalı hem moral bozucu olur.
İki-üç haftada bir çalışan bir parça teslim edildiğinde ise yanlış anlaşılma ilk aylarda görülür ve ucuza düzeltilir. Ayrıca proje bir sebeple dursa bile, o ana kadar teslim edilenler kullanılabilir durumda kalır.
Devralınan yarım projeler
Yarıda kalmış bir projeyi devralmak mümkündür ama önce dürüst bir değerlendirme gerekir: yapılanın ne kadarı kullanılabilir durumda, belgeler var mı, veri yapısı sağlam mı?
Bazı durumlarda mevcut işin üzerine devam etmek doğrudur; bazılarında ise yeniden başlamak daha ucuzdur. Bu kararı duygusal değil, teknik bakarak vermek gerekir — “bu kadar para harcadık” argümanı gelecekteki maliyeti azaltmıyor.
Projeyi kurtarmak için ilk üç adım
Duran bir proje yeniden başlatılacaksa yapılacak ilk üç iş şu:
- Mevcut durumu yazıya dökün: ne çalışıyor, ne çalışmıyor, ne eksik
- Kapsamı yeniden ve küçülterek tanımlayın — ilk hedef, dört hafta içinde canlıda çalışan tek bir parça olsun
- Karar verecek kişiyi netleştirin ve haftalık kısa toplantıyı başlatın
Peki vRobot bunu nasıl yapıyor?
Kapsamı ve kapsam dışında kalanları baştan yazarız. Küçük parçalar halinde teslim eder, her iki haftada bir ekranda gösteririz.
Yapamayacağımız bir şey varsa baştan söyleriz. Müşteriye verilen her söz, tutulabilir olduğu için verilir; sonradan çıkması herkes için pahalıdır.
Sık sorulanlar
Yarım kalan projemizi devralır mısınız?
Değerlendiririz. Önce mevcut durumu inceleyip ne kadarının kullanılabilir olduğunu yazılı söyleriz. Devam mı yeniden başlama mı gerektiğini de açıkça belirtiriz.
Proje sırasında firma değiştirmek doğru mu?
Son çare olmalı ama bazen kaçınılmaz. Değiştirmeden önce belgeleri, kaynak kodu ve veriyi teslim aldığınızdan emin olun; bunlar olmadan devir çok pahalıya mal olur.
Sabit fiyat mı, zaman bazlı mı çalışmalı?
Kapsam net ise sabit fiyat riski azaltır. Kapsam keşifle netleşecekse, önce kısa bir keşif aşaması sabit fiyatla yapılır, sonrası netleşen kapsama göre fiyatlanır.
Bunu okuyanlar şunu da sordu
Bu soruyu sizin işiniz üzerinden konuşalım
Keşif görüşmesi ücretsizdir, bir şey satın almanızı gerektirmez. Mevcut durumunuzu dinler, yapılabileni ve yapılamayanı açıkça söyleriz.