Bir iş analistinin çalışma süreci, tıpkı bir ressamın bir başyapıt yaratma yolculuğuna benzer. Bir ressamın hayalindeki tabloyu gerçeğe dönüştürmek için geçtiği aşamalar gibi, iş analistinin de müşteri beklentilerini şekillendirmek ve bir yazılım projesine dönüştürmek için üç temel aşamadan geçtiğini söyleyebiliriz. Gelin bu aşamaları birlikte inceleyelim.

1. Eskiz Hali: Hayalin Şekillenmesi
   
   Her şey bir hayal ile başlar. Bu ilk aşama, müşterinin beklentilerini anlattığı ve bizim zihnimizde üç boyutlu bir taslak oluşturduğu bir hayal etme sürecidir. Tıpkı bir ressamın, gördüğü manzarayı önce karakalemle kağıda aktarması gibi, bu aşama da mükemmel olmaktan uzaktır. Ancak burada önemli olan, sınırları belirlemek ve müşterinin “done” tanımını, yani kabul kriterlerini anlamaktır.
   
   Bu aşama, müşteri beklentilerinin genel hatlarıyla çizildiği bir ön çalışma alanıdır. Henüz detaylar üzerinde durulmaz, yalnızca temel çerçeve belirlenir. İş analisti için bu süreç, müşterinin ihtiyaçlarını anlamaya çalışırken zihinlerinde bir model oluşturma fırsatıdır. Hayal edilen bu model, bir sonraki aşamaya geçiş için bir basamaktır.
2. Fonksiyonel Tasarım: Detayların Renklendirilmesi
   
   Bir ressam eskizini tamamladıktan sonra, ihtiyaç duyduğu renkleri ve malzemeleri belirler. İş analistinin ikinci aşaması da tam olarak budur: Fonksiyonel tasarım. Bu aşamada, müşterinin beklentileri ve ihtiyaçları, yazılımın yapılabilirliği açısından değerlendirilir.
   
   Fonksiyonel tasarım süreci, müşteriyle tekrar tekrar hizalanmayı gerektirir. İhtiyacın teknolojik olarak uygulanabilirliği test edilir, mümkün değilse alternatif yollar aranır. Bu süreçte birçok revizyon gerekebilir. Örneğin, Agile yöntemlerinde bu aşama genellikle “refinement” oturumlarında ele alınır. Burada, geliştirici ekibiyle fikirler çatışabilir, yeniden şekillenir ve netleştirilir.
   
   Bu aşama tamamlandığında, ihtiyaçların net bir şekilde tanımlandığından emin olunmalıdır. Eksik veya belirsiz noktalar varsa, bir önceki aşamaya geri dönülerek bu eksiklikler giderilir. Netleşmeyen bir tasarım, sonraki aşamada büyük sorunlara yol açabilir.
3. Teknik Analiz: Detayların İnşası
   
   Artık eskiz tamamlanmış, renkler belirlenmiştir. Şimdi sıra, teknik detaylara inmeye gelir. Bu aşama, her şeyin net olduğu, yapılacak işlerin adım adım tanımlandığı, işin tüm teknik bileşenlerinin belirlendiği aşamadır.
   
   Teknik analiz sürecinde, kullanılacak tablolar, yazılacak kodlar, beklenen çıktılar ve entegrasyon durumunda servis sözleşmeleri gibi detaylar belirlenir. Tıpkı bir ressamın tuvali, fırçaları, boyaları ve diğer tüm malzemelerini hazırladığı an gibi, burada da yazılımı üretmek için gerekli tüm araçlar hazır hale getirilir.
   
   Artık yazılım geliştirme süreci başlayabilir. Ancak bu aşamada şu soru akla gelebilir: Yazılım geliştirme sırasında hiç aksilik çıkmayacak mı? Elbette çıkabilir. Belki de analiz sırasında gözden kaçırılan noktalar vardır. Bu durumda ne yapılır? İşte bu noktada, önceki aşamalara geri dönmek ve yeniden değerlendirme yapmak gerekebilir. Tıpkı ressamın, eserini tamamladıktan sonra yaptığı son dokunuşlar gibi, yazılım geliştirme sürecinde de sürekli bir iyileştirme ve revizyon döngüsü vardır.

Hayalin Gerçeğe Dönüşmesi

Bir ressamın eserini tamamladıktan sonra, kuruması için bir kenara koyması gerekir. Ancak bu süreçte bile, sevimli dostlarımızın esere ufak “katkılar” yapma ihtimali vardır. Bu yüzden, iş analistleri için her aşama öncesinde bir eylem planı yapmak kritik önem taşır.

İş analizi süreci bir ressamın eser yaratma yolculuğu gibidir:

1. Hayal Etmek
2. Detaylandırmak
3. İnşa Etmek

Her aşama, bir sonrakinin temelini oluşturur ve tüm bu aşamalar, müşterinin hayalini gerçeğe dönüştürmek için birlikte çalışır.

O zaman “Think, Draw, Implement” diyoruz. Bir sonraki yazıya kadar bana aşağıdaki adresten ulaşabilirsiniz.

• LinkedIn

<span class="bsf-rt-reading-time"><span class="bsf-rt-display-label" prefix="Okuma Süresi"></span> <span class="bsf-rt-display-time" reading_time="2"></span> <span class="bsf-rt-display-postfix" postfix="dk"></span></span>Think, Draw, Implement: İş Analizinin 3 Boyutu yazısı ilk önce Ofistekiler üzerinde ortaya çıktı.

Küme Düşme Tehlikesine Karşı İlk Adımlar

Futbol Sahasında Product Owner Olmak

Bir futbol takımını küme düşme hattından çekip çıkarmak, yalnızca taktikler veya transferlerle başarılamaz. Aynı zamanda, bir ürün geliştirme sürecindeki gibi doğru bir sistem kurmak ve bu sistemi sürekli iyileştirmek gerekir. Süper Lig’de küme düşme riskiyle karşı karşıya olan bir takımın Product Owner’ı olarak sahaya indiğimde, futbolu bir organizasyonel proje olarak ele alıyorum.

1. Durum Analizi: “Takımın Röntgenini Çekmek”

Her şeyden önce elimde bir gerçeklik haritası olması gerekiyor. Takımı ayağa kaldırmak için nerede olduğumuzu bilmeliyim. Bu yüzden:

• Performans ve Rakip Analizi: Oyuncuların fiziksel ve zihinsel durumlarını, takım dinamiklerini ve rakiplerin güçlü/zayıf yönlerini anlamak için veriye dayalı bir analiz yaparım.
• Sorunların Net Tanımı: Neredeyiz ve nereye gitmek istiyoruz? Bu sorunun cevabını almak için takım içi anketler, birebir görüşmeler ve hatta taraftar geri bildirimlerini bir araya getiririm.

2. Backlog Oluşturma: Problemleri Görünür Kılmak

Bir Product Owner’ın en önemli araçlarından biri backlog’dur. Futbol sahasında da bu böyle. Her problemi ve hedefi bir backlog maddesi gibi ele alıyorum.

• Backlog’un temelleri: Kondisyon eksiklikleri, düşük motivasyon veya takım içi iletişim problemleri.
  • Oyuncu bazlı sorunlar: Kondisyon eksiklikleri, motivasyon problemleri.
  • Teknik ekip ihtiyaçları: Strateji geliştirme, veri analizi, taktik hazırlık.
  • Taraftar hedefleri: Maç günü atmosferi, sosyal medya etkileşimi.
• Önceliklendirme (Prioritization): En yüksek puan getirme potansiyeline sahip alanlara odaklanıyorum. Örneğin, savunmadaki açıkları kapatmak, hücum organizasyonundan önce gelebilir. Backlog, yalnızca benim rehberim değil, takımın tüm üyelerinin de görebileceği bir yol haritası olacak.

Bu backlog, sadece benim yol haritam değil, tüm takımın gözünün önünde duran bir rehber olacak. Her hafta güncellenecek ve hangi soruna odaklanmamız gerektiği netleşecek.

3. Scrum Takımını Güçlendirme: “Takım Ruhu ile Verimliliği Artırmak”

Futbol dünyasında başarı, bireysel performanstan çok takım oyunu ile gelir. Scrum takımını bu ruha uygun hale getirmek için birkaç önemli adım atarım:

• Daily Stand-up: Her antrenman öncesi mini toplantılar düzenleyerek takımın o günkü hedeflerini belirlerim. Oyuncular bu toplantılarda kendi hedeflerini ve ihtiyaçlarını paylaşır.
• Sprint Retrospective: Maçlardan sonra, “Neyi iyi yaptık? Neyi geliştirebiliriz?” sorularını sorarız. Bu retrospektifler, sadece sahada değil, soyunma odasında da dönüşüm yaratır.
• Scrum Master ve takım içi liderlik: Teknik ekip içinden bir Scrum Master seçerek (örneğin yardımcı antrenör), tüm süreçlerin tıkır tıkır işlemesini sağlarım.

4. Küçük Zaferler için Sprint Planlaması: “Adım Adım Yükselmek”

Başarı, küçük adımlarla inşa edilir. Her maçı bir sprint olarak ele alır ve hedefleri bu doğrultuda belirlerim.

• Hedefler: Bir sonraki 3 maçta kaç puan alacağımıza, hangi oyuncuların performansına odaklanacağımıza karar veririz.
• Ölçülebilir Sonuçlar (KPI’lar): Gol atma yüzdesi, pas isabet oranı, koşu mesafesi gibi ölçülebilir hedeflerle her sprintin sonucunu değerlendirebilirim.

5. Taraftarı Oyuna Dahil Etmek: “12. Adamın Gücü”

Bir ürünün kullanıcıları ne kadar bağlıysa, başarı o kadar hızlı gelir. Aynı şekilde taraftarın enerjisini takıma yansıtmak çok önemli:

• Sosyal medya üzerinden doğrudan iletişim kurarak takım ruhunu güçlendiririm.
• Taraftarların maçlarda etkili olabilmesi için özel etkinlikler ve motivasyon kampanyaları düzenlerim.

6. Sürekli İyileştirme: “Agile ve Kaizen Yaklaşımı”

Her hafta, her maç bir öğrenme fırsatı. Geri bildirim kültürü ile her sprintten sonra iyileştirme önerilerini backlog’a eklerim. Bu döngü, takımın gelişimini sürdürülebilir hale getirir.

Bu noktada futbol artık sadece bir oyun değil, takımın bir “ürün” gibi ele alındığı, kullanıcıların yani taraftarların memnuniyetinin artırıldığı bir dönüşüm sürecidir. Backlog’umuz, Scrum prensiplerimiz ve sürekli iyileştirme odağımızla hedefe adım adım ilerleriz. Çünkü her problem bir backlog maddesi, her maç ise yeni bir sprint. Sezon sonu geldiğinde, sadece ligde kalmış değil, büyümek için sağlam bir sistem kurmuş bir takım olmayı hedefliyoruz.

Ne dersin, takımın ritmini yakalayabilir miyiz? 😊

Futbol Sahasında Product Owner Olmak
Futbol Sahasında Product Owner Olmak

<span class="bsf-rt-reading-time"><span class="bsf-rt-display-label" prefix="Okuma Süresi"></span> <span class="bsf-rt-display-time" reading_time="3"></span> <span class="bsf-rt-display-postfix" postfix="dk"></span></span>Futbol Sahasında Product Owner Olmak yazısı ilk önce Ofistekiler üzerinde ortaya çıktı.