Kurumsal Yazılım Projeleri Nerede Aksıyor, Nerede Düzeliyor
Kurumsal yazılım projelerinin çoğu teknik nedenlerle batmaz. Bütçe yerinde, ekip kalabalık, seçilen teknoloji güncel; buna rağmen sistem canlıya alındıktan altı ay sonra kimse eski Excel dosyasından vazgeçmiş olmaz. Aksama noktaları şaşırtıcı biçimde tekrar eder ve neredeyse hepsi projenin ilk birkaç haftasında verilmiş kararlara dayanır.
Teknolojiyi kim seçiyor
Seçim çoğu kurumda satın alma masasıyla BT arasında kapanır. Lisans modeli, entegrasyon vaatleri, referans müşteri listesi. Bunlar yanlış kriterler değil, eksik kriterler.
Peki ya kararı, o ekranı günde kırk kez açacak kişi verseydi? Muhtemelen demo sırasında kimsenin sormadığı şeyi sorardı: aynı kaydı arka arkaya on kere girerken kaç tık gerekiyor. Tedarikçi sunumu bu soruya cevap vermez, çünkü sunum ortalama kullanıcıyı değil ortalama alıcıyı hedefler. Sahadan bir kullanıcıyı seçim toplantısına oturtmanın maliyeti bir öğleden sonradır; yanlış seçimin maliyeti üç yıllık sözleşmedir.
Eski sistem bir enkaz değil, bir kayıt
Yerini alacağınız sistem, yıllar içinde kimsenin yazmadığı iş kurallarını içine gömmüştür. Kod çirkin olabilir, ama o çirkinliğin bir kısmı gerçek bir ihtiyacın izidir.
Bir ERP geçişinde, eski sistemdeki "hatalı" sanılan bir yuvarlama davranışının aslında muhasebenin yıllardır bilerek kullandığı bir kural olduğunu, ancak yeni sistem canlıya çıktıktan sonra öğrendik.
Bu yüzden analiz aşamasında yalnızca şikayetleri toplamak yetmez. Çalışan tarafı da yazılı hale gelmeli: hangi süreç bugün sorunsuz dönüyor, hangi ekran neden değiştirilmemiş, hangi alan neden zorunlu değil. Eski sistemin veritabanı şeması bu konuda görüşme kayıtlarından daha dürüst bir kaynaktır.
Katılım ile sadelik birbirini yer
Bu tür projelerde iki tavsiye neredeyse her listede yan yana durur: tüm paydaşları sürece dahil edin ve gereksiz özelliklerden kaçının. İkisi aynı anda uygulanmaz.
Sürece dahil ettiğiniz her paydaş, masaya kendi departmanının ihtiyaç listesiyle gelir. Katılımcı sayısını artırdıkça talep sayısı artar, çünkü kimse toplantıya "benim bir isteğim yok" demek için gelmez. Reddetme ölçütü tanımlanmadan kurulmuş bir geri bildirim mekanizması, geri bildirim değil özellik talebi kanalıdır.
Çözüm katılımı kısmak değil, katılımın konusunu değiştirmek. Paydaşlar problemi tarif etsin, çözümü değil. "Sipariş onayı iki gün sürüyor" bir problemdir ve ölçülebilir. "Sipariş ekranına toplu onay butonu koyun" bir çözüm önerisidir ve doğruluğu test edilemez, çünkü kimse iki günün nerede geçtiğine bakmamıştır. Talebi problem formuna çeviremiyorsanız o talep sıraya girmez.
Test yükü taşımıyorsa test değildir
Kurumsal sistemler ortalama bir salı gününde çökmez. Ay sonu kapanışında, bordro gününde, kampanya sabahında çöker. Yirmi kişilik bir test grubuyla temiz veri üzerinde yapılan sınama bu anların hiçbirini yakalamaz.
İşe yarayan yaklaşım şu: test ortamına üretim verisinin maskelenmiş bir kopyasını yükleyin ve senaryoları yılın en yoğun gününün hacmiyle çalıştırın. Peki ya o hacmi elde edemiyorsanız? O zaman en azından şunu ölçün: kayıt sayısı on katına çıktığında listeleme sorgusu kaç kat yavaşlıyor. Doğrusal büyüyorsa sorun yok, daha hızlı büyüyorsa canlıda patlayacak yeri şimdiden biliyorsunuz demektir. Bu ölçüm bir öğleden sonra alınır ve pilot dönemdeki sürprizlerin büyük kısmını önden gösterir.
Pilot kullanıcıları da gerçek işlerini yaparken sisteme alın. Ayrı bir "test görevi" verilen kullanıcı, alışkanlıklarını değil verilen talimatı takip eder; ölçtüğünüz şey sistemin kullanılabilirliği değil, talimatın anlaşılırlığı olur.
Kaynaklar