KARTAL: İŞ ANALİZİNDE İLHAM KAYNAĞI

OKUMA SÜRESİ: 1 dk

Bazı hayvanlar efsanedir. Onların ayırdedici özelliklerini bilmesek de hemen çıkıverir ağzımızdan bir muhabbet esnasında. Aslan, kaplan, kurt, şahin, at gibi. Bunlardan biri de kuşkusuz kartal.

Peki kartalın ayırdedici hangi özellikleri var dersiniz?

1. Güçlü ayakları ve gövdesi:  öyle ki koca bir geyik bile avlayabiliyor.
2. Keskin gözleri: Bilinen en yüksek uçan kuş olmasına rağmen onca yüksekten avını kestirip yakalayabiliyor.
3. Karizması: Bu da bizden olsun :)

Bu blogda ne işi var kartalın o zaman. Sizce hangi özelliği ile blogumuza misafir olmuştur? Araya karizmatik bir kartal fotoğrafı eklendi ki yazının kalan kısmının etkisi olmasın cevabınızda :)

Kartal Analist. 

Gelelim analizimize:

1. özellik olan güç son vuruş ki buna release anı diyelim. Bizcesi en sondaki iletişim ve koordinasyon gücü.

3. özellik ise 1 ve 2 olmayınca havası çabuk sönen çocuklara aldığımız helyum gazlı pepee balonu gibidir. Varlığının tadı kısa süre de olsa tadılır yine de.(çocukların her görüşünde istediği ve 24 saat içerisinde söneceğini bile bile anne ve babaların aldığı yeni nesil balonlar. )

Bizim aradığımız özellik 2'de saklı. İş analisti rolünü üstlenen herkes büyük resmi en yüksek seviyeden görüp tüm detayları taramalı. Gücüne göre hedeflerini seçmeli ve en optimum çözümü müşteriye sunmalı. Detaylarda boğulmadan önce yükseklerden uçmalı. 

Gayet açık olduğundan fazla yazmaya da gerek kalmıyor. 

Kartal ruhlu analistlere sevgiler.

İŞ ANALİSTİNİN GEREKSİZ TEKNİK ADAMLIK HAZZI

OKUMA SÜRESİ: 1dk 30 sn

Bugün uzun zaman aradan sonra third party bir entegratörün sunduğu bir API servisinde ilgili parametreleri girerek test amaçlı birkaç HTTP Request yaptım. 2-3 tool yükledim. Bir iki request, error derken zamanın nasıl geçtiğini anlamadan JSON, Header, key, error code, request ve responseler vs havada uçuştu. Ne bileyim bir hoş oldum aslında. Sanki zaman zaman damarlarımı baskılayan teknik ruh kendini dışarı salıvermiş pervasızca teknolojik hazzın tadını çıkarmaya çalışıyordu.

Hayli saat harcadıktan sonra, API servisinden error olmadan response aldım. Yazılımcılara koşup, "arkadaşlar bu third party ile çalışacağız, siz rahat olun servisleri de gayet güzel çalışıyor, bizzat test ettim, story'leri de çabucak çıkrırım" dedim. 

Ve tabii o deriiiiin! teknolojik bilgimin farkına varmalarını da sağlamış oldum. 

Fakaaat!!! 

Uzun yıllardır iş analistlerinin aslında ne kadar önemli bir yerde durduğunu ıspatlamaya çalışan biri olarak, hemen bu anlamsız hazdan kendime bir ders çıkardım. Kimse bizi, entegrasyonu test etmemiz, SQL yazmamız, kodu debug edip yazılımcının tepesine binmemiz veyahut ta iş birimine sisteme ne kadar hakim olduğumuz göstermemiz için işe almıyor. (Alıyorsa da almasın bundan sonra, bu işleri yapacak hayli yazılımcı, testçi işe alınıyor zaten)

Burada "amaaan be sen de, kod bilmemizin ve ne olup bittiğini anlamamızın ne zararı var. kendin bilmiyon diye bizi de yanlış yola götürme" dediğinizi duyar gibi oldum. 

Bunu demekte haksız değilsiniz. Bazen çok arafta bırakılıyoruz. Bizi işe alanlar bile nereye konumlandıracağını karıştırabiliyor. Fakat şurda hemfikirsek, kodu ancak hobi için yapmamız gerektiğinde de uzlaşırız.

İş analistleri veya product owner olarak biz,

Kaynaklarımızın, stretajilerimizin ve teknolojik kısıt ve varlıklarımızın farkında olarak, sınırsız teknolojik talepleri en çok değer üretebilecek noktaya taşımayla görevlendirildik.

Yani bizim adımıza herşeyin başladığı yer burası. Sonrası ise malumumuz. 

Sonuçta, beynimiz de bir kaynak. Doğru yere odaklanalım. Kendi işimiz için değer üretelim.

Vesselam. 

İŞ ANALİSTİNİN 8 TEMEL DOĞRUSU

Siz bir iş analistisiniz. Sizinle güzel bir sohbete yapan bir arkadaşınız bir ara tam olarak ne yaptığınızı merak ediyor.

-  Senin görevin neydi kurumda?

-  İş analistiyim.

-  Ne yapıyorsun tam olarak?

İşte kritik soru geldi. Cevabı ise muhtemelen geçiştirmelik veririz, yoksa bu hamur çok su götürür.

Zira yaptığımız işi tanımlamak o kadar da kolay değildir. Doğrudur! Kolay tanımlanamayanı yapmak da kolay değildir. Hele bunun en doğrusuna ulaşmak gerçek bir sanattır.

İşte bu soruya arkadaşımızın da merakını kolayca gidermek için kalıplaşmış aspirin bir cevap verir ve böylece konuyu değiştiririz.

-  Kurumumuzda yazılımsal bir değişiklik talep eden birimler ile yazılımcılar arasında köprü görevi görüyorum

-  Hmmmm! Gayet güzel.

Bu cevabın doğruluğunu ve arkadaşınızın anlamış gibi gözüken yüz ifadesini bir kenara bırakalım.

Şimdi, gelelim, biz iş analistleri olarak kendimizi nasıl tanımlamalıyız ve nereye konumlandırmalıyız sorusunun cevabına. Az sonra ifade edilecek olan maddeler agile, waterfall, lean tekniklerinden bağımsız olarak iş analisti şapkasını takan product owner, çözüm mimarı, sistem analisti gibi tüm roller için genellemelerdir.

TANIYIN: Çalıştığınız kurumun kültürünü, kısa-orta-uzun vadeli hedeflerini, hedefe taşıyan stratejilerini, kar getiren ürünlerinin ne olduğunu, gider merkezlerini, rakiplerini, kurumda güç merkezlerineki kişi ve birimlerin kim/nerede olduğunu ve karar verme sürecinin nasıl işlediğini öğrenin. Analiz yaparken bu bilgileri üst çatı olarak referans alın. Küçük işler için büyük hedefleri kurban etmeyin.

UNUTMAYIN: Yazılımcı, test mühendisi, database uzmanı veya donanımcı olmadığınızı unutmayın. Onların ne iş yaptığını ve nerede konumlandıklarını çok iyi bilin ama onların işini çok iyi bilmeniz değil sizin işinizi bilmeniz gerektiğini unutmayın. Onlar adına konuşmayın. Onlardan danışmanlık alın. C#, Java, Mongo, test otomasyonu konularını bilmiyorum dediğinizde sizden bir şey eksilmez unutmayın. ,Bu araç ve yöntemleri ana hatlarıyla bilmeniz yeterlidir.

ANLAYIN: Kapınızı analiz için çalan herkesi önce anlayın. Büyük-küçük iştir demeden dinleyin, sorun, içselleştirin, teyit edin. Bu döngüyü doğru olanı tam anlayıncaya alana kadar tekrarlayın.

DEĞER KATIN : İhtiyacı anladıysanız , hemen analiz yapmaya çalışmayın, birlikte beyin jimnastiği yapın, değer katmaya çalışın (kaynak kısıtını unutmadan). Talep içinize sinmediyse karşı tarafı düşündürün. Gerekirse daha sonra tekrar bir araya gelmek üzere akıllara soru işaretleri atıp biraz ara verin.

ÖNERİN: İşin ihtiyaç olduğu kesinleşip başlama aşamasına gelince, ihtiyacı karşılayabilecek çözüm önerileri sunun. Her zaman, combobox, checkbox, ekran, menü diye kısıtlamayın kendinizi. Ufkunuzu geniş tutun. Manuel bir çözüm bile olabilir. Yeter ki değer katın. Değer katmak RoI maksimizasyonudur. Açık kaynak ürünler, mobil veya bulut bilişim gibi güncel teknolojiler konusunda daha fazla çözüm önerileri geliştirin. Öneri yaparken her önerinin, fayda/maliyet kriterlerini sunmayı ihmal etmeyin. Böylece güvenilir bir danışman özelliğiniz oluşacaktır.

TAKİP EDİN: İş, analiz edilip yazılım sürecine girdikten sonra, işin tüm aşamalarından haberdar olun, takip edin, kontrol edin. Yazılım ve proje takım üyeleri ile sık sık konuşup hangi aşamada olduklarını, işi doğru anlayıp anlamadıklarını ve ilk çıktılarını kontrol edin. (Agile bu konuda Desk Check önerir)

DOĞUM SONRASI :) İşimizin en güzel yeri. Ürün doğdu. Ama o da ne? Doğum sonrası adaptasyon problemleri, hastalıklar, ihtiyaçlar... Her ortaya çıkan ürünün, yeni ürün ihtiyacı doğuracağı kesindir. Bu yüzden, yeni ihtiyaçlar eklenmesine müsait modeller geliştirmeye özen gösterin. Esnek çözümler üretin. Bu konuda gerekirse yazılım ekiplerini de ikna edin. Hatta kurumun hedefleri arasında teknolojiyi satmak varsa oldukça esnek ve satılabilir bir ürün hedefleyin. Ürün ortaya çıktıktan sonra ürünün performans verilerini sürekli takip edin.

GÜNCEL KALIN: Bu kısım sadece bizim rolümüzün bir parçası değil fakat iş analizi pratiklerle hem kendi doğrularını hem de kendi yanlışlarını büyütebilir. Bu yüzden yaptığımız yanlışları daha fazla beslememek adına, konferanslar, bloglar, kitaplar ve eğitimler ile kendimizi yenilemeliyiz. Bunların yanında yönetici, yazılım ve iş birimlerinden her zaman geri bildirim alın. Vermezlerse zorlayın.

Bu açıklamalardan sonra yapılacak en güzel tanım ne olabilir siz karar verin.

Köprü olmadığı açık. Varsa bir öneriniz yorumlarınızı bekliyoruz.