Standish Group’un Chaos raporuna göre projelerin sadece %29’u başarılı kabul edilmektedir. Proje başarısızlıklıkları, öngörülen zaman ve bütçede bitirilen projelerde bile karşımıza çıkabilmektedir. Çünkü esas kök sorun, bütçe ve zamanın ötesinde, kullanıcıların (paydaşların) gereksinimlerinin doğru anlaşılmamasından kaynaklanmaktadır.
Özünde bu sorunu aşabilmek için iş analistlerinin odaklanması gereken iki temel konu vardır:
1- Paydaş Analizi
2- Gereksinim Yönetimi
Peki iş analistleri paydaş ve gereksinimleri yönetirken ne gibi sorunlarla karşılaşabilir ve bunların üstesinden nasıl gelebilirler?
1.Kapsam Kayması
Kapsam kayması projelerde en çok karşılaştığımız sorundur. İş birimlerinden gelen gereksinim değişiklik talepleri veya yeni gereksinimler, genellikle başta kulağa çok hoş gelen ‘nice to have’ gereksinimler olmaktadır. Ancak iş analisti olarak bu gereksinimleri doğru yönetemediğiniz takdirde ilerleyen safhalarda projenin, amacı karşılamayan farklı bir yere ulaştığını görürsünüz.
Kapsam kayması nasıl engellenir?
- Baştan proje hedeflerinin net bir şekilde belirlenerek yeni gereksinimlerin veya gereksinim kaynaklı değişiklik taleplerinin bu doğrultuda ele alınması, proje hedefleriyle uyuşmayan taleplerin geri döndürülmesi.
- Sadece kapsam dahilinde olan maddelerin değil (in-scope) aynı zamanda kapsam dışında olan (out of scope) maddelerinde baştan belirlenerek iş birimleri ve çözüm ekipleri arasındaki beklentilerin netleştirilmesi, sınırların çizilmesi.
2. Gereksinimlerin Anlaşılır Olmaması
İş analistleri çoğu zaman kapsamı net bir şekilde belirlediklerini düşünseler bile çözüm ekipleri tam olarak neyi kodlayacağını bilemeyebiliyorlar.
Gereksinimler nasıl daha anlaşılır hale getirilir?
- Gereksinimleri iş (business requirement), kullanıcı (user requirement), fonksiyonel (functional requirement), fonksiyonel olmayan (non-functional requirement) ve sistem (system requirement) gereksinimleri olarak farklı kategorilere ayırmak.
- Akış diyagramları ile süreçleri anlaşılır kılmak ve ekran tasarımları ile gereksinimleri görselleştirmek.
- Çözüm ekipleriyle analiz dokümanını paylaştıktan sonra ayrıca ekiple birlikte analiz dokümanlarının üzerinden geçerek net olmayan yerlerin iş analistleri tarafından anlatılması.
3. Kullanıcıların (Paydaşların) Sürece Yeterince Dahil Olmaması
Genelde sorun projenin başında paydaş analizi yapılırken bu analizin eksik yapılmasından veya belirlenen paydaşlar yerine aracılarla konuşulmasından kaynaklanmaktadır. Örneğin; bir banka BT projesinde bankanın bireysel müşterileri yerine müşteri ilişkileri yöneticilerinin veya çağrı merkezi çalışanlarının sürece dahil edilmesi gibi. Bu tür durumlarda gereksinimler kulaktan kulağa aktarılırken farklılaşmakta ve esas ihtiyaçtan uzaklaşmaktadır. Çözüm olarak farklı kullanıcı gruplarının, personaların olabileceğinin farkına varmak, tüm paydaşları dinleyerek farklı seviyede gereksinim toplama tekniklerini kullanmak (örneğin beyin fırtınası, odak grup, mülakat, gereksinim çalıştayı vb.) ve kullanıcı kabul testinden önce paydaşları ürün ile prototiplerle karşılaştırmak.
4. Belirsiz, Muğlak Gereksinimler
‘İşlem hızlı gerçekleşmeli’ şeklinde tanımlanan bir gereksinimden kastımız nedir? Size göre 5 saniye hızlı olabilirken kullanıcıya göre 2 saniye yavaş gelebilir. Ya da ‘Ekranlar kullanıcı dostu olacak’ şeklinde bir gereksinim tanımlıyorsak tam olarak neyi kastediyoruz? Kime göre kullanıcı dostu olacak, çocuklara göre mi, yaşlılara göre mi? Kullanıcı dostu olması ne demek, bununla ilgili check list paylaşıyor olmamız gereksinimi daha somut ve test edilebilir şekilde tanımlamamıza yardımcı olur.
Referans: BA-WORKS Inspiring Series: Bilgi Teknolojileri Projelerinin Başarısı İçin Yazılım Testi, İş Analizi ve Kullanılabilirlik