İş Analisti Kime Denir? - İşAnalisti.Net
Murat May 21, 2012 İş Analisti Kime Denir?2017-10-20T13:18:48+00:00 CBAP & BABOK
İş analisti: Görev tanımı, iş ünvanı veya organizasyonel rolüne bakmaksızın, herhangi bir işin analiz aktivitesini yapan kişiye iş analisti denir.
Sadece görev ünvanı iş analisti olan kişiler değil aynı zamanda da BABOK Guide’da belirtilen görevleri(Tasks) yerine getiren herhangi bir kişide iş analisti olarak nitelendirilebilir.
Örneğin sistem analistleri, İhtiyaç Mühendisleri (Requirements Engineers), süreç analistleri, ürün yöneticileri, kurumsal analistler(Enterprise Analysts), İş mimarı (Business Architects), yöneticiler, danışmanlar ve proje yönetimi, yazılım geliştirme, kalite güvence ve etkileşim tasarımı gibi ilişkili diğer disiplinler üzerine çalışan kişiler.
BABOK Guide Tasks:
Genel kabul gören tarifi ise şu şekildedir:
Görev tanımı, iş unvanı veya organizasyonel rolüne bakmaksızın birincil önceliği, proje paydaşlarının gerçek ihtiyaçları meydana çıkarmak (Elicite), analiz etmek(Analyze), tasdik etmek(Validate), belirlemek(Specify), doğrulamak(Verify) ve yönetmek olan kişilere iş analisti denilebilir. İş Analisti aynı zamanda, İhtiyaç Mühendisleri (Requirements Engineers), sistem analisti veya sadece analist olarak da bilinir. İş analisti müşteriler ile yazılım geliştirme ekibi arasında bir köprü olarak hizmet verir.
İş analisti, yazılımın geliştirme yaşam döngü içinde farklı görevlerde yer alabilir. Ancak gereksinimlerin belirlenmesi ve diğer görevleri içinde, asıl odaklandığı konu gereksinimleri net bir şekilde adreslenmesi ve doğru bir şekilde gereksinimlerin yerine getirildiğinden emin olmasıdır.
İş analistliği proje içindeki bir roldür, bu role sahip olan kişinin unvanının iş analisti olması gerekmez. Sadece bu rol için atanmış bir iş analisti olabileceği gibi proje üyeleri içinden asıl görevleri proje yöneticiliği, ürün yöneticiliği veya yazılımcı olan kişiler de iş analistliği rolü ile analiz kısmını gerçekleştirebilir. İş analistinin projede içindeki rolü yapılması gereken görevleri gereği gibi yapılmış olduğundan emin olmaktır.
Karşılıklı Görüşme (Interview): Birey ve gruplar ile gereksinimleri hakkında konuşup doğru soruları sorarak önemli bilgilerini gün ışığına çıkarabilmek.
Dinleme: İnsanların ne dediğini, ne demek istediğini anlamak ve söylemekten çekindiği şeyleri tespit etmek.
Analitik Düşünme: Birçok kaynaktan alınan bilgileri eleştirel olarak değerlendirebilmek. Çatışmaları uzlaştırabilmek. Üst düzey bilgileri detaylı küçük parçacıklara ayrıştırabilmek. Düşük seviyeli veya teknik konuları daha anlaşılır bir seviyeye getirebilmek. Kullanıcıların belirttiği gereksinimler ile işin altında yatan gerçek gereksinimleri ayırt ederek gereksinimlerden çözüm önerileri sunabilmek.
Kolaylaştırma (Facilitation ): Gereksinimlerin ortaya çıkarılması için yapılan çalışmaların yönetimini yapabilmek (requirements elicitation workshop).
Gözlemsel Beceriler: Diğer teknikler ile elde edilen verilerin tasdik edilmesi ve elicitation aktivitesi için yeni alanlar ortaya çıkarabilmek.
Yazılı iletişim: Müşteriler, yöneticiler , teknik ekip ve proje üyeleri ile bilgileri efektif bir şekilde paylaşabilmek.
Organizasyonel beceriler: Ortaya çıkarma (Elicitation) ve analiz sırasında toplanan geniş kapsamlı bilgiler ile çalışabilmek ve hızla değişen bilgi ile başa çıkabilmek.
Bireyler arası iletişim: Öncelikleri müzakere edebilmek ve proje paydaşları( müşteriler, ürün yöneticileri ve mühendisler) arasında çatışmaları çözebilmek.
Modelleme Becerisi: gereksinimler ile ilgili bilgileri organizasyon içinde önceden belirlenmiş modelleme dili ile grafik formlar, şablonlar ve tasarımlar olarak sunabilmek.
Ürün müdürü veya proje sponsoru ile ürün vizyonu ve proje kapsamı ile ilgili çalışmak.
Proje paydaşlarının ve kullanıcı sınıflarının belirlemek.
Kullanıcı sınıflarının karakteristik özelliklerini belirlemek. Her bir kullanıcı sınıfı için uygun temsilcileri belirlemek ve sorumlulukları ile müzakerelerde bulunmak.
Gereksinimleri doküman analizi, requirements workshop, storyboards, anket, site visit,benchmark, use cases, senaryolar ve event lists gibi teknikler kullanarak ortaya çıkarmak .
Standart şablonlara göre basit, açık, kesin ve özlü bir dil ile gereksinim dokümanı oluşturmak (Business Requirement Document or Requirements Specifications Document)
Üst seviyede belirtilmiş iş ve kullanıcı gereksinimlerini kullanıcılar tarafından anlaşılabilen uygun seviyeli bir şekilde işlevsel gereksinimler halinde küçük parçacıklara ayrıştırmak.
Kalite bileşenlerini, kısıtları, harici ara birimleri ve diğer işlevsel olmayan gereksinimleri tanımlamak
business architects, enterprise analysts, include business systems analysts, İş Analisti, management consultants, process analysts, product managers, product owners, requirements engineers, systems analysts
« MosCow Method