Burak Kasap · Bella Binary ·
Geciken bir yazılım projesinde ilk suçlanan genellikle geliştirme ekibidir. Oysa takvimi bozan şey çoğu zaman kodun kendisi değil, proje başlarken cevabı verilmemiş sorulardır. Aşağıdaki yedi konu, sahada en sık gördüğümüz gecikme nedenleridir. Hepsinin ortak özelliği, sözleşme imzalanmadan önce kapatılabilir olmalarıdır.
1. Kapsam yazıya dökülmemiş
“Stok takibi olsun” bir kapsam değildir. Hangi depolar, hangi hareket türleri, hangi raporlar, kim hangi ekranı görecek? Bu sorular cevaplanmadan verilen süre tahmindir. Kapsam belgesinde ekran listesi, kullanıcı rolleri ve kapsam dışı bırakılan işler ayrı ayrı yazılmalıdır. Kapsam dışı listesi en az kapsam kadar önemlidir, çünkü proje ortasındaki “bunu zaten konuşmuştuk” tartışmasını o keser.
2. Tek bir karar verici yok
Muhasebe bir şey ister, üretim başka bir şey, genel müdür üçüncüsünü. Yazılım ekibi üç ayrı görüşü uzlaştırmaya çalışırken haftalar geçer. Müşteri tarafında son sözü söyleyen tek bir kişi belirlenmelidir. Bu kişi her konunun uzmanı olmak zorunda değildir; görevi görüşleri toplayıp kararı zamanında vermektir.
3. Veri ve erişimler geç geliyor
Örnek veriler, mevcut Excel dosyaları, ERP test kullanıcısı, sunucu erişimi, uzaktan bağlantı izni. Bunların her biri küçük görünür ama gelmediği her gün ekip bekler. Başlangıç toplantısında bir “müşteriden beklenenler” listesi çıkarılmalı, her kalemin sorumlusu ve tarihi yazılmalıdır.
4. Entegrasyon hafife alınmış
“ERP’ye de bağlanacak” cümlesi tek satırdır, arkasındaki iş bazen projenin yarısıdır. Karşı sistemin arayüzü var mı, belgesi güncel mi, test ortamı açılabiliyor mu? Üçüncü taraf firmanın dönüş süresi sizin kontrolünüzde değildir. Entegrasyonlar ayrı bir iş kalemi olarak planlanmalı ve mümkünse projenin başında denenmelidir. API’si olmayan sistemler için seçenekleri ayrı bir yazıda anlattık.
5. Test sona bırakılmış
Kullanıcılar yazılımı ilk kez teslim gününde görürse, geri bildirimin tamamı o gün gelir. Çalışan ara sürümler düzenli aralıklarla gösterilmeli, asıl kullanıcılar ekranlara erken dokunmalıdır. Erken gelen düzeltme ucuzdur; son hafta gelen düzeltme takvimi kaydırır.
6. Veri aktarımı planlanmamış
Yeni sistem boş açılmaz. Eski cari kartlar, stok kodları, açık siparişler taşınacaktır. Eski verinin temizlenmesi çoğu zaman tahmin edilenden uzun sürer: mükerrer kayıtlar, boş alanlar, farklı yazılmış aynı firma adları. Aktarım bir kez değil, en az bir deneme ve bir gerçek geçiş olarak planlanmalıdır.
7. Kabul ölçütü tanımsız
“Bitti” ne demek? Bu soru cevapsızsa proje hiç bitmez, yalnızca yorulur. Her iş kalemi için kabul ölçütü baştan yazılmalıdır: hangi senaryo çalışınca o kalem kapanmış sayılır? Ölçüt yazılıysa teslim bir tartışma değil, bir kontrol listesidir.
Başlamadan önce kısa kontrol listesi
| Konu | Kapandı sayılması için |
|---|---|
| Kapsam | Ekran listesi, roller ve kapsam dışı işler yazılı |
| Karar verici | Müşteri tarafında tek isim belirli |
| Veri ve erişim | Beklenenler listesi, sorumlu ve tarihle birlikte hazır |
| Entegrasyon | Karşı sistemin arayüzü ve test ortamı doğrulanmış |
| Test | Ara sürüm gösterim tarihleri takvimde |
| Veri aktarımı | Deneme aktarımı planda |
| Kabul | Her kalemin kabul senaryosu yazılı |
Sonuç
Gecikmenin büyük bölümü öngörülebilir. Yukarıdaki yedi konu açıkken verilen her tarih iyi niyetli bir tahmindir. Bu yüzden biz kod yazmadan önce işi anlamaya zaman ayırıyoruz; nasıl ilerlediğimizi çalışma sürecimiz sayfasında adım adım anlattık. Teklif aşamasındaysanız, teklifleri karşılaştırma yazımız da işinize yarayabilir.
Sizin projenizde bu yedi konudan hangisi hâlâ açık? Birkaç cümleyle yazın, birlikte bakalım.