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ı: 1511
Taygun Kekeç
31 Ağustos 2014 @ 13:15
Gerçekleri yansıtan bir yazı olmuş, tebrik ediyorum. Yazılım geliştirme dalında tespit ettiğiniz “analitik olmama” probleminin türlü türlü farklı disiplinlerde yaygın olarak görülmekte olan daha geniş bir problemin alt kümesi olduğunu düşünüyorum. Bana kalırsa burada asıl sorulması gereken bu geliştiricilerin neden analitik düşünemediği, akabinde yapılan işi sadece ham bilgiden ibaret görüp, modelleme ve sürecin ne olduğuna dair bir bilgisinin yahut inancının olmamasının arkasındaki sebebin ne olduğudur.
Sizin alanınızdan konuşacak olursak, bu analistlerin kifayetsiz kalmasının sebebi nedir? Tanıdığım analistlerin geçmişlerine baktığımda çoğunun iyi üniversitelerin iyi bölümlerinden mezun olduğunu görüyorum. Analistlerin hayatlarının bir anında tasarım modellerine dair bir ders aldıklarını veya bir programcıyla münasabetinde böyle birşeyin varlığından haberdar olduklarını varsayıyorum. Buna rağmen bu kişilerin bir plan dahilinde çalışmaması ve hareket etmemesinin ardındaki sebebi düşünüyorum. Gördüğüm tablo beni hep aynı noktada itiyor: somut nesnelerin insan aklını esir alıp, asıl insanın zihnini özgürleştiren soyut düşünme kabiliyetinden uzaklaştırması. Bilgiyi görmek kolaydır, müşteriniz size iletir, önünüzdedir. Fakat hangi tasarım modelini kullanmanız gerektiğini bilmeniz öncelikle:
1. Tasarım modellerini bilmeniz
2. O an edindiğiniz bilgiyi bu modellere bağlayıp, uygunluğunu düşünmeniz
3. Yaptığınız çıkarımları müşterinin anlayacağı şekilde iletmeniz
adımlarını içerir. Elinize hemen verilen müşteri isteğinden daha soyuttur ve görülmesi zordur çünkü bir düşünce sürecini gerektirir. Bir sorgu çalıştırmanız gerekir burada bilgi tabanınızdan.
İnsan soyut düşünce kabiliyetinden kitaplarla bağlantısını keserek uzaklaşır. Alanınıza uzağım fakat mutlaka baş ucu referans kitaplarınız vardır. İnsan yüksek miktarda bilgiyi kendi üretemez, kendinden önce gelen bilgileri öğrenir ve bunları uygular. Bahsettiğiniz tarz analistlere yapılması gereken, yöneticilerin veya deneyimli analistlerin onları bu kaynaklara yaklaştırması, okumayı teşvik etmesi ve karşılaştıkları her saha deneyiminde gördüklerini ve duyduklarını bu kaynaklarla filtreleyerek hareket etmelerini tavsiye etmeleridir. Onların karşılaştıkları istek ve problemlerin aslında birbirine benzediğini, belirli modeller çerçevesinde düşünüldüğünde aynı olduklarını farketmelerini sağlayın. Öğrenmek 4 sene üniversite okuyup daha sonrasında biten, discrete, bir zihni mahkumiyet süreci değildir. Öğrenmek beşikte başlayan mezarda biten zevkli, eğlenceli continuous bir deneyimdir. Eminimki analistler işlerini bu düzlemde görseler belki ilk anlarda öğrenerek yorulacaklar fakat sonrasında yaptıkları işten çok daha fazla zevk alacaklardır.
Fakir milletlerin fakir olması kaderden değil, bireylerin çaba göstermemesinden , bilgisizliğinden ve cehaletinden kaynaklanır. İşini düzgün yapmayan analistin şirketini, ardı ardına aldığı kararlar sonucunda binlerce TL zarara uğrattığını farketmesi gerekir. Yapılan işe sadece kendine etkileri değil, diğer insan ve şirketlere olan ikinci üçüncü seviye etkilerini düşünmesi gerekir. Kendinden büyük bir realitenin içinde olduğunu anlaması elzemdir.
Akin
01 Eylül 2014 @ 10:26
Ilginiz ve uzun yorumunuz icin tesekkur ederim. Soyut dusunme yeteneklerimiz, malesef toplumca cok gelismis degil. Size katiliyorum, bu toplumsal bir sorunumuz. “BU matematik ne isimize yarayacak” diye soru sorulan ve hocalarin da ikna edici cevap veremedigi bir ulkede yasiyoruz. Bu durum da malesef her yerimize etkiyor. O yuzden gorunenen odaklaniyoruz. Acikcasi o iyi egitim dedigimiz yerler bizi bu tur ezbercilige ve kolayciliga alistiriyor.
Hoscakalin.
Muhammed Şahin
01 Eylül 2014 @ 13:19
Yaşadıklarıma tercüman bir yazı, beğenerek okudum.
hakan
01 Eylül 2014 @ 13:46
Öncelikle Akın Bey sizi tebrik etmek istiyorum.. Çok uzun bir süredir durumu bu kadar açık, gerçekçi ve derinlemesine ortaya koyan bir yazıya, görüşe rastlamamıştım. Ben bu süreçleri yaşarken çalıştığım analistlere müşteri ile programcı arasında elçi demiştim siz de postacı demişsiniz. Zaten hepsi de aynı kapıya çıkar..
İkinci olarak Sayın Taygun Kekeç’e bu konuda düşüncemi aktarmak isterim. Bu durumun arkasında yatan nedenleri zaman içinde düşündüm ve gözlemlemeye gayret ettim. Tespit edebildiğim nedenleri şöyle açıklayabilirim. İlk olarak, başarılı gençler sırf yüksek puanlı diye veya bazen de ana, babaları tarafından zorlanarak özel üniversitelere gönderilerek bilgisayar mühendisleri yapıldıklarını, bu arkadaşların kod yazmayı zor bir süreç olarak gördüklerini, sevmediklerini ve bu meslekten para kazanmanın en zahmetsiz yolunun “postacı” analist olmaktan geçtiğini mezun olur olmaz keşfettiklerini gözlemledim. İkinci olarak günümüzde gerçek manada yazılım geliştirmenin temellerini öğrenemeden hatta sql’de basit select cümlelerini bile yazamadan bazı okullardan(genelde özel üni.ler idi rastladıklarım) bilgisayar mühendisi lisans diplomaları alınabildiğine hayretle şahit oldum. Üçüncü ve bence en önemlisi olarak günümüz yöneticilerinin bu gibi arkadaşları çok ciddi projelere hatta bazen tek sorumlu olarak atayabildiklerini yine hayretle izledim. Bu son belirttiğim durumda bir proje takvimi işlemeye başlıyor, analist en kritik süreçlerde tek başına müşteri ile çalışıyor. Bazı dokümanlar ortaya çıkıp koda geçeceğiniz zaman bakıyorsuniz ki bu analizle gidilirse iş patlayacak ancak süreç de geçmiş oluyor. Yöneticinize durumu anlatma şansınız olsa bile(bazen de olmuyor) geriye döndürme şansınız neredeyse hiç olamıyor. Dördüncü bir neden de sadece analist değil iş tarafında çalışanların da aslında ne yaptıklarını çok da bilmediklerini, çelişkili konuştuklarını veya bildikleri kadarını da ifade edemediklerini görüyorsunuz (yine bu da bence en başta işini sevmeden, heyecan duymadan yapmaktan ve eğitim sorunlarından kaynaklanıyor). Bütün bu nedenlerden sonra işin bence en kötü tarafını söyleyeyim. Ortaya çıkan üründe oluşan her sorun programcıya/developera soruluyor…
Akin
01 Eylül 2014 @ 13:57
Tesekkur ederim ama uzuldum
Akin
01 Eylül 2014 @ 14:00
Dediklerinizin hepsi dogru Hakan bey. Iyi ozetlemissiniz. Ben burada sydiginiz her konu ile ilgili bir seyler yazdim burada. Her zeki cocogun muhendis ya da doktor olamsi gibi konualr da dahil. Btun bu sorunalrin sonucta programcinin ensesinde boza pisirilmesi anlamina geliyor. Belki bu konuda ozel bir yazi yazmak lazim
Tesekkurler.
hakan
09 Eylül 2014 @ 09:34
Akın Bey, bu yazınızı çok beğendiğim için bir kez daha okudum Bir daha okuyunca aklıma şöyle bir soru geldi. Şöyle ki, bir programcı ne kadar kötü de yazsa sonuçta kendisine verilen algoritmayı çalıştıran bir kod yazmak zorunda. Yazamıyorsa bu işi hiç bilmiyor demektir ve çalışabilmesi mümkün olmaz. Yani temelde de olsa bir nevi yeterlilik ispatlamak zorunda(Tabi ki kodu çalıştırmak yetmez uzman olmak için çok daha fazlası gerekli). Peki günümüz yazılım projelerinde boy gösteren çeşit çeşit analist ve yöneticilerin yeterliliklerini ölçen ama gerçekten her projede uygulanan en basit bir kriter bile yok mu, olamaz mı
Akin
09 Eylül 2014 @ 11:49
Tesekkur ederim Hakan beycigim.
Sorunuz aslinda bu dunyadaki en temel sorunlardan birisi. BT dunaysindaki rolelrin yetkinliklerini olcebilmek henuz yeterli seviyede basarabildigimiz bir sey degil. Developerlar icin hem bilgi hem beceri seviyesinde bunu olcmek dediginiz gibi analistelre gore cok daha kolay. Analistelr icin malesef yaygin bir yol pek yok. Benden bu konuda yardim isteyenler zaman zaman oluyor. Ben de bazi degerlendime kriterleri gelistiriyorum. Bilgi ve beceri bazli bu kriterleri kullanabildiginizde ciddi bir seviye atlamasi ve standardizasyon saglanabiliyor. Ama genel olarak bu anlayistan uzaktayiz.
Hoscakalin.