Analitik Olmayan Analistler Neye Mal Olur?

Karşı karşıya olduğu iş bilgisini, analitik olarak irdeleyemeyen analistler, ne sağlıklı bir iş bilgisine sahip olabilirler, ne müşterilerinin ihtiyaçlarını anlayıp uygun çözümler bulabilirler, ne verimli toplantılar yapabilirler ne de işe yarar dokümantasyon yazabilirler.

Sıklıkla karşılaşıyorum ciddi tecrübeye sahip analistlerle. Sık sık danışmanlıklarda ve eğitimlerde, bazen de iş görüşmelerinde. Mesela iş görüşmesinde karşılaşıyorum örneğin finans sektöründe 10 senedir analist olarak çalışan adayla ve şunu soruyorum: “İş analizi ile yazılım ihtiyaç analizi arasında herhangi bir fark görüyor musunuz?” Pek fazla bir şey çıkmıyor. Peki diyorum, “yazılım ihtiyaçlarını kategorilere ayırmak istersek ne gibi farklı tipler aklınıza gelir?” Yine pek hikmetli bir cevap gelmiyor. Yaptığı işi ise genel olarak “müşteriyle görüşürüm, isteklerini bir dokümana yazarım, sonra ekran tasarımını yaparım, …” diye özetliyor. “Ekran tasarımı” işinin bir tasarım-design olduğunu ve bir “analiz” faaliyetinde nasıl yer aldığını sorunca bazen önce cümlemi tekrar etmemi istiyor ve “evet haklısınız” diye devam ediyor, bazen bu kadar da ilerliyemiyoruz. Gerçi ben isminde hem “ihtiyaç” hem de “tasarım” kelimeleri bulunan ihtiyaç analizi dokümanları çok sık gördüğümden alışkınım ama yine de sormadan duramıyorum 🙂

“Yazdığınız dokümana gelelim” diyorum ve “dokümanda ne gibi başlıklarınız var?” diye soruyorum. Amacım hiç olmazsa pratik olarak yaptıklarına bakarak iş ve ihtiyaç analizi ile ilgili ne kadar “analitik” olduğunu anlamak. “İhtiyaçlar” diyor dokümandaki ilk başlık içın. Tabi diyorum, sonuçta “İhtiyaç Analizi” dokümanında ihtiyaçlar olur 🙂 İhtiyaçlar başlığı altında ne gibi alt başlıklar olduğunu sorunca da, olmadığını, ihtiyaçları alt alta sıraladığını söyluyor adayımız. “Müşteri anlatır ihtiyacını, ben de yazarım” diyor. Buna da şükür, çünkü daha kötüsü var: Müşteri kısa bir emaille, bir telefon konuşmasıyla ya da bir araç yardımıyla iki satırla gönderebilir ihtiyacını. Ama müşterinin ihtiyacını anlatıp, analistin de hiç bir analitik süreçten geçirmeden anlatılanı yakalayıp yazılım geliştirenlere ilettiği bir süreçte analiste “postacı” demek daha uygun olmaz mı? “Sonra niye programcılar bizden memnun değiller?” diye sormanın ne alemi var ki?

Demeye çalıştığım şey şu: İşini yapışı açısından, pozisyonun ya da rolün isminde var olan “analitik” olma ile yakından uzaktan ilgisi olmayan kişilerin, iş bilgisini ve yazılım ihtiyaçlarını analitik olarak ele almaları mümkün değil. Bu durumda tonlarca iş bilgisi, bir şekilde bir araya getirilmiş cümlelerden ibaret olacak, yani “malumat” olarak kalacak. Analitik olarak ele alınmadığı için, içinde herhangi bir soyutlama da içermeyecek. Gittikçe büyüyen ve karmaşıklaşan iş bilgisini ve yazılım ihtiyaçlarını, bölük-pörçük malumat öbekleri olarak ele almak sanırım bir BT kurumu içın yapılabilecek en büyük hatadır.

İş bigisini ve yazılım ihtiyaçlarını analitik ya da çözümleyici olarak ele almaktan kastımız şu: Öncelikle bir ihtiyaç kategorizasyonu olmalı. Örneğin fonksiyonel olan ve olmayan ihtiyaçlar olarak ayırım. Sonrasında iş ihtiyaçları, kullanıcı ihtiyaçları ve fonksiyonel ihtiyaçlar şeklinde farklı soyutlama seviyelerinde ihtiyaç hiyerarşisinin kurulması gerekli. Ayrıca kullanıcı ihtiyaçlarının, kullanıcı süreçleri olarak “süreç” tabanlı ifade edilmesi çok önemlidir. Yani içinde insan olan farklı roldeki kullanıcılarla birlikte haberleşilen farklı yazılım ve donanım sistemlerinin de olduğu ki bunların tümüne birden biz aktörler diyoruz, kullanıcı iş akışlarının ortaya konması. İş akışlarındaki alternatif ve sıra dışı durumların belirlenmesi, yani olumlu sonuçlanan senaryolar dışında olumsuz ve alternatif senaryoların da ortaya konması, süreç analizi için olmazsa olmazdır. Kurum seviyesindeki iş süreçleri öncelikle kurum çapında çizilip detaylandırılabilir. Kullanıcıların iş sureçleri ise örneğin use-case (kullanım şekli) olarak yakalanabilir ve UML’in aktivite diyagramlarıyla daha görsel ve analitik hale getirilebilir.

İş süreçlerindeki farklı tipteki iş kurallarının ayrı bir başlık altında toplanması da çok önemlidir, çünkü iş süreçleri pek çok hesaplama, kısıtlayıcı ya da tetikleyici cinsten kurallar içerir. İş süreçleri ve kurallarından sonra süreçlerdeki atomik olan fonksiyonel ihtiyaçların ayrıca tek tek yakalanması ve bunların süreçlerle ilişkilendirilmesi en detaylı fonksiyonel ihtiyaçları ortaya çıkarır. İnsan aktörlerin dahil olduğu süreçlerde, aktörün sistemle etkileşiminin detaylandırılması amacıyla kullanıcı arayüz analizinin (tasarımı degil!) yapılması da unutulmaması gereken analiz çalışmalarındandır.

Ayrıca iş süreçlerindeki kısıtların, kalite ve uyum standartlarının ortaya konması, entegrasyon detaylarının belirlenmesi, sistem ihtiyaçlarının çıkarılması ve mimari ihtiyaçlar olarak fonksiyonel olmayan ihtiyaçların hem süreç hem de sistem tabanında ortaya konması, analitik ve tam bir ihtiyaç analizi çalışmasının olmazsa olmazlarındandır. Tüm bunlar, aslında “malumat” seviyesindeki iş bilgisi ve yazılım ihtiyaçlarının “bilgi” seviyesine çıkarılması faaliyetlerindendir. Bir konunun öğlerini analitik olarak kategorilere ayıramazsanız, hiyerarşiler kurgulayamazsanız, o konu hakkında da düşünemezsiniz, dolayısıyla aklınızdaki sadece ezber olur, malumat ya da information olur ama bilgi ya da knowledge olmaz. Ayrıca farklı iş ve yazılım ihtiyaçları arasında öncelik-sonralık, sebep-sonuç ilişkilerinin belirlenmesi, benzer şekilde yazılım ihtiyaçlarının maliyetlerinin, karmaşıklıklarının ve risklerinin ortaya konması, yine analitik olmanın parçalarındandır. Dikkat ederseniz bu paragrafta saydığımız maddeleri bilebilmek için önceki paragraflarda bahsettiğimiz “analitik-çözümleyici” çalışmaların yapılmış olması şarttır. Örneğin, malumat seviyesinde kalmış, kategorize edilip, alt parçalarına ayrılmamış ihtiyaçların maliyetini nasıl hesaplarsınız ki? Tecrübeliyseniz biraz destekli atış yapabilirsiniz ancak.

Yukarıdaki gibi yazılım ihtiyaçlarına analitik olarak yaklaşmayan analistlerin gerek müşterilerle gerek ise geliştiricilerle toplantılarının verimli olmasını beklemek de nafiledir. Onlarca insan, saatlerce konşurlar ama yine de ortaya doğru düzgün bir şey çikmaz. Bir toplantının başarısı öncelikle o toplantının ne kadar odaklı olduğuyla ilgilidir. Son derece genel, odaklı olmayan konuları ele alma niyetiyle yapılan toplantılar çok sık görülen cinstendir. Odaklı olmadığı için de önüne gelen ya çağırılmıştır ya da duyup gelmiştir. Başarılı analiz toplantıları ekranlar üzerinden yapılmaz örneğin! Başarılı analiz toplantılarının önceden belirlenmiş, hangi konularda nasıl kararlar alınacağı listelenmiş, bunlar dışındakiler gündeme geldiğinde unutmamak için ve bir sonraki toplantıda ele alınmak üzere not alıp devam edilen, az ama özü tartışan ve olabilidiğince 1,5-2 saati geçmeyen, maximum 6-7 kişinin bir araya gelişleri olması gerekir. Bir analiz sürecindeki bir toplantı iki saati geçiyorsa, katılımcı sayısı 10’dan fazla ise, zaman zaman bazı katılımcılar makinalarında Facebook vs. ortamlarda vakit geçiriyorlarsa, bilin ki orada hata analisttedir, çünkü toplantıyı düzgün organize edememiştir. Bunun da sebebi aslında organizasyonsuzluk değildir, aksine analistin kafasında herhangi bir analitik yaklaşım olmaması, dolayısıyla “şu sürecin şu akışı ya da akıştaki şu iş kuralları” şeklinde odaklı bir toplantı organize edememesidir. Bu şekilde çalışmayan analistlerin çoğunlukla ya var olan ekranlar ya da yaptığı ekran tasarımları üzerinden toplantı yaptıklarına çok defa şahit olmuşumdur.

İş bilgisine ve yazılım ihtiyaçlarına bu şekilde yaklaşan analistlerin, ne malumat dolu konuşmalarının yazılımcıları tatmin ettiğini ne de aynı yapıdaki dokümanlarının yazılımcılar tarafından okunduğunu söylemek mumkündür. Bunun sonucunda da yazılımcı, programı yazarken karşılaştığı boşluklar, çelişen noktalar vb. konularda çok sık bir şekilde analiste döner.  Analist haliyle zaten cevap veremeyeceği bu tür noktalar içın çok sıklıkla müşteriye döner. Çünkü programcı, gerçekliğe analistten daha yakındır bu yüzden analistin analitik bir süreç işletmemesinin getirdiği sıkıntılarla hemen yüzyüze gelir. Hem müşteri hem de programcı tarafında “patinaj” olarak algılanan bu kifayetsizlik, sonuçta analistin devre dışı bırakılıp, müşterinin doğrudan programcıyla görüşerek ilerlemelerine sebep olur. “Ne vereyim abime/ablama” sendromu olarak isimlendirdiğim bu durum olabilecek en kötü haldir ve sebebi ise kesinlikle “postacılık”tan öteye gidemeyen analist ve onu doğru bir şekilde eğitip yönlendirmeyen yöneticisidir.

Analitik bir süreçten geçmeyen ihtiyaçlar üzerine ne doğru düzgün bir mimari bina edebilirsiniz ne de fonksiyonel bir tasarım ortaya koyabilirsiniz. Yapacagınız tek şey, programlama olabilir. Ama bunun da gideceği yer aşırı refactoring, bol copy-paste ve nihayetinde daha ilk baştan yamalı bohça görünümlü, kalitesiz koddur. Böyle geliştirilmiş yazılımların bakım maliyetleri çok ama çok yüksektir.

Benzer şekilde analitik bir süreçten geçmeyen ihtiyaçlar üzerine sağlıklı bir proje planlaması yapılamaz, efor tahminleri çok afaki olur. Analitik olarak bileşenlerine ayrılmamış müşteri ihtiyaçlarını test etmeniz de çoğu zaman ya çok meşekkatlidir ya da hepten imkansızdır. Olan biten şey, gerçek testin ancak canlı kullanımda, operasyonel kullanıcılar tarafından yapılmasıdır. Ama problem şu ki, hatalar hem müşteride memnuniyetsizlik yaratır hem de bu hataları düzeltmek için çok geç bir zamana gelinmiştir, maliyet çok artmıştır.

Yazılım projelerinde, en analitik olması gereken rol, sanılanın aksine programcılar değil, analistlerdir. Ama gerçekte analistlerin yaptığı ya postacılıktır ya da malumat biriktirme ve aktarmadır. İlki çoğunlukla analistleri ortadan kaldırmaya ikincisi ise son derece maliyetli bir yazılım geliştirme sürecine sebep olur. Analitik bir süreç izlemeyen analistlerin bulunduğu kurumların sadece bugünleri vardır, yarınları yoktur.

Analitik analistlerle çalışmanın keyfi bambaşkadır…

Toplam görüntülenme sayısı: 1509