İŞ ANALİSTLERİ NE YAPAR

Geliştirme ekibi içinde görev alan İş Analistlerinin, Geliştirme Ekibi içerisinde görevlerinin nerede başlayıp nerede biteceği tartışma konusudur.

Bundan yıllar önce konu bazlı uzmanlık söz konusu değildi. Bir İş Analisti, hem iş analizi, hem proje yönetimi hem de test yapabiliyordu. Günümüzde ise, Yazılım Mühendislik Süreçleri içerisinde artık her biri ayrı ayrı süreçler olarak değerlendiriliyor ve görevler ayrılığı prensibi ile çalışan, ayrı ayrı dallar olarak faaliyetleri sürdürülüyor.

Geliştirme ekibinde yetkinlik alanında konu bazlı uzmanlaşmış, kendi rol tanımında belirtilen faaliyetleri gerçekleştiren çalışanların geliştirdiği yazılım da daha nitelikli oluyor, bana göre..

Ama bir analistin, sadece analist rol tanımındaki görevleri yerine getirirken, diğer süreçlerin faaliyet alanlarında gerçekleştirilen işlerden bihaber olması da doğru değil.

Waterfall metodla geliştirilen projelerde, İş Analistlerinin hazırladığı analiz çıktıları Teknik Çözüm Ekibine input olur. Analist hazırladığı çıktının, Teknik Çözüm tarafında ne şekilde kullanılmasının beklendiğini bilmeli ki, Teknik Çözüm Ekibinin kullanabileceği bir çıktı olsun.. Çünkü biz analistlerin görevi; müşteri ihtiyaçlarını gereksinim haline getirerek, geliştirmenin yapılacağı sistemde ne şekilde handle edileceğini belirtmektir.

Bir analistin kod yazması beklenmez ama database’e erişip, tabloların niteliklerini, aralarındaki ilişkileri bilmesi; çok daha şık, çok daha sistemle tutarlı, çok daha zaman tasarrufu sağlayıcı bir etki yaratır.

Keza test ekibine de input olan analiz çıktıları için de durum aynıdır. Test Ekibi, Analiz Ekibinin hazırladığı analiz çıktılarına göre, senaryo yazacağından; analist arkadaşların analiz çıktılarının, senaryo yazabilecek nitelikte olması gerekir.
Her ne kadar analiz çalışmaları sırasında Teknik Çözüm Ekiplerine yapılan bilgi aktarımları ile interaktif bir çalışma sürdürülse de, Teknik Çözüm Ekiplerinden bağımsız bir analiz geliştirilmese de; yine de tasarım aşamasında, analizden farklı tasarımlar ortaya çıkabilmektedir. Bunun en temel nedeni ise, analiz dokümanlarının okunmaması ya da kolay anlaşılır olmamasıdır.

Peki analistler, çıktılarının daha kolay okunur, anlaşılır olması için neler yapabilirler?

1.Kodu yazılabilir nitelikte, analiz çıktıları hazırlamalılar.

2.Uzun uzun sayfalarca doküman yazmak yerine, resmin bütününü görmeyi kolaylaştırıcı UML (Unified Modeling Language) modelleme diyagramlarından uygun olanını kullanabilirler.

3.Varlık –ilişki (ER- Entity Relationship Diagram) diyagramını kullanabilirler.



Böylelikle,

1.Analiz Ekibi ile Teknik Çözüm Ekibi arasında ortak bir dil yaratılmış olacaktır.

2.Analizler daha anlaşılır olduğundan, konunun bir bütün olarak anlaşılması kolaylaşacaktır.

3.Geliştirilecek iş ürünü ile ilgili varlıkların, varlıkların niteliklerinin ve birbirleri arasında ilişkilerin belirtilmesiyle, “kavramsal” olarak veri modeli analizi yapılması, teknik çözüm aşamasında “fiziksel” olarak veri modeli tasarlanmasını kolaylaştıracaktır.

4.Analiz uyumsuz kod geliştirilmesi riski minimize ederek, maliyetleri düşürücü yönde etki edecektir.

İletişimde olduğu gibi, Yazılım Mühendislik Süreçlerinde de, her bir süreçte görev alan arkadaşların "Empati" kurabilme yeteneğine sahip olmaları gerekir.Ön yargılarımızı bir kenara bırakıp; anlama ve anlaşılma isteğiyle çalışmalarımızı gerçekleştirirsek; hem kendi analiz çıktılarımızın nitelikli olması açısından, hem de çalışmamızdan faydalanacak diğer süreç sahibi ekip arkadaşlarımızın daha efektif yararlanması açısından çok daha verimli işler ortaya çıkacaktır.