IBAN, SEPA, SWIFT, SCA, KYC, AML, Core Banking, API, Open Banking, Backoffice…

İlk bakışta bunların birbirinden bağımsız kavramlar olduğunu düşünebilirsiniz. Aslında değiller. Bir müşterinin mobil uygulamadan yaptığı basit bir para transferini düşünelim.

Kullanıcı açısından süreç oldukça basittir:

IBAN → Tutar → Gönder

Fakat bankanın arka tarafında aynı işlem çok daha farklı görünebilir:

Customer
   ↓
Mobile / Internet Banking
   ↓
Authentication / SCA
   ↓
Payment Service
   ↓
Business Rules
   ↓
Fraud / AML Controls
   ↓
Core Banking
   ↓
Payment Infrastructure
   ↓
Clearing / Settlement
   ↓
Beneficiary Bank

Bir İş Analisti (BA) olarak bu sistemlerin tamamında uzman olmanız beklenmez. Ancak bir talebin (requirement’ın) bir sistemden diğerine nasıl etki edebileceğini anlayabilecek kadar kavrama hâkim olmanız beklenir. Bu nedenle bu yazıda bankacılık projelerinde çalışan bir BA’nın bilmesi gereken temel iş, teknik, ödeme ve regülasyon kavramlarını; bunların birbirleriyle ilişkisini ve requirement analizinde neden önemli olduklarını örneklerle ele alacağım.

1. Bankacılıkta İş Analisti Neden Biraz Farklıdır?

Her sektörde İş Analistinin temel görevi iş ihtiyacını anlayıp bunu geliştirilebilir ve test edilebilir gereksinimlere dönüştürmektir. Ancak bankacılıkta bu süreç biraz daha karmaşıktır. Çünkü bir business requirement aynı anda:

• müşteri deneyimini,
• finansal işlemi,
• güvenliği,
• regülasyonu,
• farklı backend sistemlerini,
• dış kurumları,
• veri modellerini,
• operasyon ekiplerini etkileyebilir.

Örneğin:“Müşteri transfer yapabilmelidir.” çok basit bir istek gibi görünür. Ama BA olarak şu soruların cevaplarını bilmeniz gerekir:

• Hangi müşteri?
• Hangi hesap?
• Hangi transfer türü?
• Hangi para birimi?
• Hangi ülke?
• Limit var mı?
• SCA (Strong Customer Authentication) uygulanacak mı?
• AML/Fraud (Anti-Money Laundering) kontrolü olacak mı?
• Hangi API (Application Programming Interface) çağrılacak?
• Core Banking’de hangi işlem oluşacak?
• İşlem başarısız olursa hangi statüde oluşacak?
• Backoffice bunu nasıl görecek?

İşte bankacılıkta BA olmanın temel farkı burada ortaya çıkar: Bir requirement’ı yalnızca kullanıcı ekranından değil, uçtan uca süreçten değerlendirmek.

2. İş Kavramları: Önce Bankanın Dünyasını Anlamak

Teknik kavramlara geçmeden önce bankacılığın temel iş kavramlarını bilmek gerekir. Çünkü teknik sistemler bu iş kavramlarını yönetmek için vardır.

2.1. Müşteri (Customer)

Bankanın hizmet sunduğu gerçek veya tüzel kişi.

2.2. Hesap (Account)

Müşterinin para ve finansal hareketlerinin tutulduğu hesap.

2.3. Bakiye (Balance)

Hesabın belirli bir andaki bakiyesi.

Bunlar basit görünse de BA açısından önemli sorular ortaya çıkar. Örneğin: “Müşterinin bakiyesi mobil uygulamada gösterilecektir.”. Burada hemen şu soru sorulabilir: Bu balance’ın kaynağı hangi sistem tarafından sağlanıyor?

Örneğin:

Mobile Banking
      ↓
Account API
      ↓
Integration Layer
      ↓
Core Banking
      ↓
Balance

Peki API ile Core Banking’deki değer farklıysa hangisi gösterilecek?

Ya da:

• Available balance mı?
• Current balance mı?
• Blocked amount düşülmüş mü?
• Pending transaction’lar dikkate alınıyor mu?

İşte BA’nın iş kavramlarını bilmesi burada önem kazanıyor.

2.4. IBAN

IBAN, banka hesap numaralarının uluslararası standartlara göre düzenlenmiş halidir.

Açılımı International Bank Account Number (Uluslararası Banka Hesap Numarası) olan bu sistem, para transferlerinin hızlı, hatasız ve düşük maliyetle yapılmasını sağlar. IBAN formatları ülkeye göre farklılık gösterebilir.

BA açısından IBAN’ı yalnızca: “Müşterinin hesap numarası.” olarak düşünmek yeterli değildir. Örneğin: “Alıcı IBAN alanı eklenecektir.” dendiğinde şu sorular ortaya çıkar:

• Hangi ülkeler destekleniyor?
• IBAN format doğrulaması nerede / kim tarafından yapılacak?
• Ülke kodu IBAN’dan otomatik alınacak mı?
• BIC Kodu gerekli mi?
• IBAN ile BIC Kodu arasında doğrulama yapılacak mı?
• Geçersiz IBAN girilirse ne olacak?
• Aynı IBAN’a tekrar alıcı eklenebilir mi?
• IBAN değiştirildiğinde mevcut alıcı bilgileri temizlenecek mi?

Yani: IBAN bir UI alanından çok daha fazlasıdır. Ödeme sürecinde doğrulama, yönlendirme ve iş kurallarını etkileyebilir.

2.5. BIC Kodu

BIC kodu, uluslararası para transferlerinde (SWIFT) paranın gönderileceği bankayı dünya genelinde benzersiz şekilde tanımlayan küresel bir kimlik kodudur.

Açılımı Bank Identifier Code (Banka Tanımlama Kodu) olan bu sistem, finans dünyasında çoğunlukla SWIFT kodu olarak da adlandırılır ve iki terim pratikte tamamen aynı anlama gelir.

BIC kodları genellikle 8 veya 11 haneden oluşur ve şu bilgileri içerir:

• Banka Kodu (4 Karakter): Bankanın adını simgeleyen kısaltmadır (Örn: İş Bankası için ISBK).
• Ülke Kodu (2 Karakter): Bankanın bulunduğu ülkeyi belirtir (Türkiye için TR).
• Konum Kodu (2 Karakter): Bankanın genel merkezinin bulunduğu şehir veya bölge kodudur.
• Şube Kodu (3 Karakter — Opsiyonel): Paranın aktarılacağı spesifik şubeyi tanımlar. Genel merkez için genellikle XXX.

IBAN ile Farkı Nedir?

• BIC Kodu: Paranın dünyadaki hangi bankaya gideceğini gösterir (Mektubun üzerindeki şehir/posta kodu gibidir).
• IBAN: Paranın o bankadaki hangi bireysel hesaba yatacağını gösterir (Mektubun üzerindeki kapı numarası gibidir).

2.6. SEPA

SEPA, Avrupa genelinde Euro cinsinden yapılan banka transferlerinin yurt içi transferler kadar hızlı, güvenli ve düşük maliyetli (genellikle ücretsiz) olmasını sağlayan tek bir ödeme sistemidir.

Açılımı Single Euro Payments Area (Tek Avrupa Ödeme Alanı) olan bu sistem, Avrupa Birliği tarafından Euro cinsinden banka transferlerini basitleştirmek amacıyla kurulmuştur.

Ama BA açısından SEPA’yı yalnızca “Avrupa’ya EUR transfer” olarak düşünmek yetersizdir. SEPA içerisinde farklı payment scheme’leri bulunur.

Örneğin:

• SEPA Credit Transfer (SCT — Standart Transfer): Müşterinin kendi isteğiyle başlatıp başka bir hesaba para gönderdiği geleneksel banka transferi (EFT benzeri) yöntemidir
• SEPA Instant Credit Transfer (SCT Inst) — Anlık Transfer: 7/24 kesintisiz çalışan, paranın saniyeler içinde karşı hesaba geçmesini sağlayan anlık ödeme şemasıdır (Türkiye’deki FAST sisteminin birebir aynısıdır).
• SEPA Direct Debit (SDD) — Doğrudan Tahsilat / Otomatik Ödeme: Alıcının (genellikle bir şirket/kurum), borçlunun (müşterinin) hesabından banka kanalıyla otomatik olarak para çekmesidir (Türkiye’deki Otomatik Fatura Ödeme Talimatı gibidir).

2.7. SWIFT

SWIFT’i genellikle: “Uluslararası para transferi sistemi.” olarak duyarız. Ancak SWIFT’in temel rolü finansal kurumlar arasında güvenli finansal mesajlaşma ve standartların kullanımını desteklemektir. Bu ayrımı bilmek BA açısından önemlidir.

Açılımı Society for Worldwide Interbank Financial Telecommunication (Dünya Bankalar Arası Finansal Telekomünikasyon Birliği) olan bu sistem, aslında kendisi para taşımaz; bankalar arasındaki iletişim protokolünü yönetir.

Bir İş Analisti (BA) Gözüyle SWIFT Gereksinimleri

Projenizde “SWIFT transferi yapılacaktır” requirement’ı varsa, analiz etmeniz gereken kritik business kuralları ve teknik detaylar şunlardır:

1. Masraf Tipi Seçimi: SWIFT işlemlerinde transfer ücretini kimin ödeyeceği ekran tasarımını ve veri tabanını doğrudan etkiler. Kullanıcıya şu 3 seçenekten hangilerini sunacağınızı analiz etmelisiniz:

• OUR: Tüm masrafları (gönderen ve aracı banka ücretleri) gönderici öder. Alıcının hesabına para kesintisiz geçer.
• BEN: Tüm masrafları alıcı (beneficiary) öder. Ücretler gönderilen paradan düşülür, alıcıya eksik tutar ulaşır.
• SHA (Shared): Masraflar paylaşılır. Gönderici kendi bankasının ücretini öder, aracı banka ücretleri ise giden paradan düşülür.

2. Teknik Mesaj Standartları (MT’den MX’e Geçiş): SWIFT dünyası şu an büyük bir teknik dönüşüm içerisindedir. Eski metin tabanlı formatlar yerini XML tabanlı zengin formatlara bırakmaktadır:

• Eski Standart (MT — Message Type): Örneğin, müşteri transferleri için geleneksel olarak MT103 mesaj formatı kullanılırdı.
• Yeni Standart (MX — ISO 20022): Günümüz modern sistemlerinde artık pacs.008 (ISO 20022) XML formatı zorunlu hale gelmiştir. Analist olarak sisteminizin hangi mesaj formatını üreteceğini ve okuyacağını belirlemelisiniz.

3. Muhabir Banka (Correspondent Bank) İlişkileri: Eğer paranın gönderileceği banka ile sizin bankanız arasında doğrudan bir hesap ilişkisi (nostro/vostro) yoksa, para aradaki aracı (muhabir) bankalar üzerinden geçer.

4. AML ve Sanction (Yasal Uyum ve Ambargo) Kontrolleri: SWIFT uluslararası bir ağ olduğu için terörizmin finansmanı ve kara para aklama (AML) kurallarına sıkı sıkıya bağlıdır ve bu kontrollerin detayları, kim tarafından yapılacağı analiz aşamasında kararlaştırılmalıdır.

2.8. Ödeme Yaşam Döngüsü

Bir BA’nın ödeme işleminin yaşam döngüsünü anlaması çok önemlidir.

Örneğin basitleştirilmiş bir ödeme yaşam döngüsü:

Initiated
    ↓
Validated
    ↓
Authenticated
    ↓
Submitted
    ↓
Processing
    ↓
Completed

Ama gerçek sistemlerde:

Initiated
   ↓
Pending
   ↓
Accepted
   ↓
Processing
   ↓
Completed

veya:

Initiated
   ↓
Rejected

gibi farklı akışlar olabilir. Buradaki önemli nokta: statülerin isimlerini değil, işleyişte gerçek anlamlarını bilmek. Örneğin:ACCEPTED ile COMPLETED aynı şey değildir. Bir sistem ödeme isteğini kabul etmiş olabilir ancak ödeme henüz tamamlanmamış olabilir. Bu ayrım UI, API, database ve backoffice requirement’larını doğrudan etkiler.

2.9. Core Bankacılık

Core Banking (Çekirdek Bankacılık), bir bankanın tüm temel finansal işlemlerini (hesap açma, kredi verme, mevduat yönetimi, faiz hesaplama ve muhasebe gibi) arka planda tek bir merkezden yöneten ve işleyen merkezi bankacılık yazılım sistemidir. Bankanın “beyni” veya “kalbi” olarak tanımlanabilir.

2.10. API (Application Programming Interface)

API (Uygulama Programlama Arayüzü), farklı yazılımların birbiriyle veri alışverişi yapmasını ve iletişim kurmasını sağlayan bir kurallar bütünüdür. Bir restoran garsonu gibi çalışır; istemcinin isteğini sunucuya iletir ve cevabı geri getirir.

API Nasıl Çalışır?

• İstek (Request): Bir uygulama, başka bir sisteme veri veya işlem için başvurur.
• İşlem: Sunucu isteği inceler ve veriyi hazırlar.
• Yanıt (Response): İstenen sonuç, talep eden uygulamaya geri gönderilir.

Yaygın Kullanım Alanları

• Ödeme Sistemleri: E-ticaret sitelerinin bankalardan kartla ödeme alması.
• Haritalar ve Konum: Web sitelerine Google Maps gibi haritaların eklenmesi.
• Hava Durumu: Telefon uygulamalarının anlık hava verilerini çekmesi.

Bankacılıkta API Türleri

• Internal (İç) API’ler: Bankanın kendi iç sistemlerinin konuşmasını sağlar. Örneğin, Mobil Bankacılık uygulamasının Core Banking’deki Mevduat Modülüne bağlanıp “Vadesiz hesabın bakiyesini getir” demesi bir iç API çağrısıdır.
• External (Dış) API’ler: Bankanın SEPA, SWIFT, Visa/Mastercard veya Merkez Bankası gibi dış kurumlarla veri alışverişi yapmasını sağlar. Örneğin, SEPA Instant işleminde 10 saniyede karşı bankaya sinyal gönderen mekanizma bir dış API’dir.
• Open Banking (Açık Bankacılık) API’leri: Regülasyonlar gereği, bankanın müşteri izniyle üçüncü parti finansal kurumlara (Fintech’lere) açmak zorunda olduğu API’lerdir (Örn: Hesap hareketleri sorgulama, bakiye görüntüleme).

2.11. SCA — Strong Customer Authentication

SCA (Güçlü Müşteri Kimlik Doğrulaması), özellikle Avrupa genelinde (ve Türkiye’de de benzer regülasyonlarla) dijital ödemelerin güvenliğini artırmak ve dolandırıcılığı önlemek amacıyla getirilen yasal bir zorunluluktur. Özetle SCA, dijital bankacılık kapısındaki “Çift Aşamalı Güvenlik” (2FA) korumasıdır.

Avrupa Birliği’nin PSD2 (Ödeme Hizmetleri Direktifi 2) mevzuatının en kritik bacaklarından biridir. Az önce konuştuğumuz SEPA, SWIFT veya API üzerinden dönen ödeme akışlarında, paranın hesaptan çıkmasından hemen önce devreye giren o “güvenlik/onay” katmanıdır.

Regülasyon der ki: Müşteri sisteme girerken veya para transferi (SEPA/SWIFT) yaparken, kimliğini kanıtlamak için şu 3 şeyden en az 2 tanesini sunmak zorundadır:

1. Bildiği bir şey: Şifre veya PIN kodu.
2. Sahip olduğu bir şey: Doğrulama kodu gelen cep telefonu (SMS veya Push Bildirim).
3. Kendisi olan bir şey (Biyometri): Parmak izi (TouchID) veya yüz tanıma (FaceID).

2.12. SMS OTP ve Soft OTP

Bir İş Analisti (BA) olarak SCA (Güvenlik) katmanını tasarlarken, kullanıcının “Sahip olduğu bir şey” (Something you have) kategorisini doğrulamak için seçeceğiniz en yaygın iki araç SMS OTP ve Soft OTP’dir.

1. SMS OTP (One-Time Password) nedir?: Geleneksel yöntemdir. Bankanın, müşterinin GSM numarasına operatörler (Turkcell, Vodafone vb.) üzerinden tek kullanımlık bir şifre içeren kısa mesaj göndermesidir.

• İş Akışı (Flow): Kullanıcı “Gönder” der -> Sistem arka planda SMS sağlayıcı API’sine istek atar -> Kullanıcıya SMS gelir -> Kullanıcı kodu ekrana yazar.

Dezavantajları (Neden vazgeçiliyor?):

• Maliyet: Banka gönderdiği her SMS için operatörlere ücret öder. Uluslararası projelerde (yurt dışına SMS) bu maliyet devasa boyutlara ulaşır.
• Hız ve Bağımlılık: Operatör hatlarında gecikme yaşanabilir. Kullanıcı şifre gelmediği için işlemi iptal edebilir (Churm/Drop-off oranı artar).
• Güvenlik: SIM kopyalama (SIM Swapping) veya araya girme (phishing) saldırılarına karşı zayıftır.

2. Soft OTP (Yazılımsal OTP / Authenticator) nedir?: Herhangi bir GSM operatörüne veya internet bağlantısına ihtiyaç duymadan, mobil bankacılık uygulamasının kendi içinde anlık ve süreli (genellikle 30–60 saniye geçerli) şifreler üretmesidir.

• İş Akışı (Flow): Kullanıcı web şubesinden işlem yaparken mobil uygulamayı açar, uygulama interneti olmasa bile o saniyeye özel bir kod üretir, kullanıcı bu kodu yazar.
• Modern Akış (Push Notification): Günümüzde Soft OTP genellikle “Push Bildirimi” olarak evrilmiştir. Webde transfer yaparken telefona bildirim gelir, uygulamayı parmak iziyle açıp “Onayla” dersiniz. Arka planda gizli bir Soft OTP kodu doğrulanır.

Avantajları:

• Maliyet Sıfırdır: Operatörlere SMS ücreti ödenmez.
• Çok Güvenlidir: Kod cihazın içindeki güvenli alanda (Secure Enclave) üretilir, havadan (GSM ağından) uçarak gelmediği için çalınamaz.
• Çevrimdışı (Offline) Çalışır: Müşteri uçakta veya yurt dışında hattı çekmiyorken bile kod üretip işlem yapabilir.

2.13. KYC

KYC, bankaların veya finansal kuruluşların “Müşterini Tanı” anlamına gelen güvenlik ve yasal uyum sürecidir. Açılımı Know Your Customer olan bu kavramı en basit haliyle şöyle düşünebilirsiniz: Bankanın kapısından giren (veya mobil uygulamayı indiren) kişinin gerçekten söylediği kişi olup olmadığını resmî belgelerle kanıtlama sürecidir. Dijital onboarding projelerinde KYC ile sık karşılaşılır.

KYC Neden Yapılır?: Banka, platformunu kötü niyetli kişilerin kullanmasını engellemek zorundadır. KYC’nin 3 temel amacı vardır:

1. Kimlik Hırsızlığını Önlemek: Başkasının adına gizlice hesap açılmasını engellemek.
2. Kara Para Aklamayı Durdurmak (AML): Yasa dışı paraların bankacılık sistemine girmesini önlemek.
3. Dolandırıcılığı Engellemek: Sahte kimlik veya belgelerle kredi çekilmesinin önüne geçmek.

Geleneksel olarak şubede yapılan bu süreç, artık mobil uygulamalarda Dijital KYC (e-KYC) olarak saniyeler içinde yapılır:

• Adım 1 (Beyan): Kullanıcı adını, soyadını ve T.C. Kimlik / Pasaport numarasını girer.
• Adım 2 (Belgeleme): Telefonun kamerasıyla kimliğin ön ve arka yüzünün fotoğrafını çeker. (Modern sistemlerde kimlikteki çip telefona okutulur — NFC).
• Adım 3 (Canlılık Testi): Telefonun ön kamerasına bakarak kafasını sağa sola sallar veya gülümser. Sistem, o an ekrandaki kişinin canlı bir insan mı yoksa sadece bir fotoğraf mı olduğunu doğrular.

2.14. AML

AML, yasa dışı yollardan (uyuşturucu, kaçakçılık, yolsuzluk vb.) elde edilen “kirli” paranın, bankacılık sistemi kullanılarak yasal bir kazanç gibi gösterilmesini engellemeye çalışan yasal kurallar, teknolojiler ve denetimler bütünüdür. Açılımı Anti-Money Laundering (Kara Para Aklamayı Önleme) olan bu kavram, finans dünyasının en katı regülasyonudur. Özetle; bankacılıkta kara para aklama risklerinin tespit edilmesi ve önlenmesine yönelik süreç ve kontrolleri ifade eder.

2.15. PEP ve Sanctions Screening

PEP ve Sanctions Screening (SCA), finansal kuruluşların AML mevzuatlarına uyum sağlamak ve yasal cezalarla karşılaşmamak için hesap açılışlarında (KYC) ve her para transferinde (SEPA/SWIFT) yapmak zorunda olduğu küresel bir tarama (filtreleme) sürecidir.

1. PEP Screening (Siyaseten Nüfuzlu Kişi Taraması): PEP (Politically Exposed Person); devlet başkanları, bakanlar, milletvekilleri, yüksek mahkeme hakimleri, merkez bankası başkanları, üst düzey askeri yetkililer ve bunların birinci derece yakınları ile iş ortaklarıdır.

• İş Mantığı: Bu kişiler, sahip oldukları güç ve bütçe yetkileri nedeniyle rüşvet, yolsuzluk ve kara para aklama konusunda “Yüksek Riskli” kabul edilirler.
• BA İçin Kural: Bir kişinin PEP çıkması, onunla çalışılmayacağı anlamına gelmez. Sadece o müşterinin işlemlerinin EDD (Enhanced Due Diligence — Artırılmış Azami Özen) prosedürlerine tabi tutulmasını ve hesap açılış onayının şube yöneticisi değil, doğrudan Uyum Direktörü veya Genel Müdürlük tarafından verilmesini gerektirir.

2. Sanctions Screening (Yaptırım / Kara Liste Taraması): Dünya genelindeki yasal otoritelerin (Birleşmiş Milletler, OFAC, AB, Birleşik Krallık vb.) yayımladığı; terörizm, uyuşturucu ticareti veya nükleer silahlanma gibi suçlara karışmış kişi, şirket, gemi veya ülkelerin yer aldığı kara listelerdir.

• İş Mantığı: Yaptırım listesindeki bir kişi veya kuruma finansal hizmet sağlamak, para transferi yapmak kesinlikle yasaktır.
• BA İçin Kural: Eğer tarama sonucunda bir kişi veya alıcı şirket yaptırım listesiyle eşleşirse, sistem o işlemi anında bloke etmek (freeze) ve finansal ilişkiyi derhal durdurmak zorundadır. Aksi takdirde banka milyarlarca dolarlık lisans iptaline varan cezalar alabilir.

2.16. Open Banking (Açık Bankacılık) ve TPP (Third Party Provider)

Açık Bankacılık, bankaların müşterilerine ait finansal verileri ve işlem yeteneklerini, müşterinin açık rızası (onayı) doğrultusunda, güvenli API’ler aracılığıyla üçüncü parti kuruluşlara açmasını sağlayan yasal ve teknik finansal modeldir.

Bu ekosistemdeki en kritik aktör ise TPP (Third Party Provider — Üçüncü Parti Sağlayıcı) olarak adlandırılan lisanslı kurumlardır.

Avrupa’da PSD2/PSD3, Türkiye’de ise Merkez Bankası (TCMB) ve BKM (GEÇİT) regülasyonları ile yönetilen bu dünyayı bir İş Analisti (BA) gözüyle inceleyelim.

TPP (Third Party Provider) Nedir ve Türleri Nelerdir?

TPP, bankaların açtığı Open Banking API’lerini tüketen, Merkez Bankası veya BDDK gibi otoritelerden lisans almış Fintech veya teknoloji şirketleridir. Bir BA olarak tasarlayacağınız sistemde TPP’leri iki ana rol üzerinden analiz edersiniz:

1. AISP (Account Information Service Provider — Hesap Bilgisi Hizmeti Sağlayıcı): Kullanıcının farklı bankalardaki hesap hareketlerini, bakiyelerini ve finansal geçmişini tek bir ekranda toplama yetkisine sahip TPP’dir.

2. PISP (Payment Initiation Service Provider — Ödeme Başlatma Hizmeti Sağlayıcı): Kullanıcının banka uygulamasına veya internet şubesine giriş yapmasına gerek kalmadan, TPP’nin kendi arayüzü üzerinden kullanıcının banka hesabından para transferi (Havale, EFT, FAST veya SEPA) başlatmasını sağlayan TPP’dir.

2.17. Backoffice

Backoffice (Arka Ofis), bir bankanın veya finansal kuruluşun müşteriler tarafından doğrudan görülmeyen; ancak işlemlerin yasalara uygun, hatasız ve güvenli bir şekilde yürümesini sağlayan operasyon, yönetim ve kontrol merkezidir. Müşterinin kullandığı mobil uygulama veya web şubesi Front-office (Ön Yüz) iken; arkada dönen tüm idari, teknik ve finansal çarklar Backoffice’tir.

Müşteri: “Transferim gerçekleşmedi.” dediğinde iş bitmez. Operasyon ekibinin; işlemi bulması, statüsünü görmesi, hata nedenini incelemesi, gerekirse işlem üzerinde aksiyon alması gerekebilir.

2.18. Audit Trail

Audit Trail (Denetim İzi / Denetim Günlüğü), bir finansal sistemde, veritabanında veya uygulamada gerçekleşen her türlü değişikliğin ve işlemin geçmişini kronolojik olarak kaydeden güvenli bir günlük (log) mekanizmasıdır.

Bankacılıkta “kim ne yaptı?” sorusunun cevabı çoğu zaman önemlidir. Örneğin bir operasyon kullanıcısı payment’ı iptal etti:

Action: CANCEL
User: operator123
Date: 2026-08-11 10:35
Previous Status: PENDING
New Status: CANCELLED
Reason: Customer Request

Burada yalnızca: Status = CANCELLED tutulması yeterli olmayabilir. BA olarak:

• Kim?
• Ne yaptı?
• Ne zaman?
• Hangi kayıt üzerinde?
• Önceki durum neydi?
• Yeni durum ne?
• Neden yaptı? sorularını düşünmek gerekir.

Sonuç: İyi Bankacılık BA’i Kavramları Değil, Bağlantıları Görür

Bankacılık sektöründe İş Analisti olmak, uzun bir kavram listesini ezberlemekten ibaret değil. Asıl önemli olan kavramların birbirleriyle nasıl bağlandığını görmek.

Örneğin:

Customer
   ↓
Account
   ↓
Payment
   ↓
SEPA
   ↓
SCA
   ↓
API
   ↓
Core Banking
   ↓
Backoffice
   ↓
Audit

Bu zincirdeki her kavram farklı bir uzmanlık alanına ait olabilir. Ama BA’nın görevi bu uzmanlık alanlarını birbirine bağlamaktır. Çünkü bankacılık projelerinde bir requirement hiçbir zaman sadece bir requirement değildir.

Bu nedenle bankacılık sektöründe çalışan bir BA için bence en değerli soru: “Bu kavram ne?” değil. Şudur: “Bu kavram benim analiz ettiğim süreci nasıl etkiliyor?” Çünkü iyi bir bankacılık BA’sı her şeyi bilen kişi değildir. Doğru bağlantıları kurabilen kişidir.

Log okumak genellikle teknik ekiplerin işi gibi görülür. Oysa iyi bir İş Analisti, yalnızca gereksinim yazan değil; sistem davranışını anlayabilen, problemi doğru yere konumlandırabilen ve teknik ekip ile iş birimleri arasında güçlü bir köprü kurabilen kişidir. Bu yazıda, teknik geçmişi sınırlı olsa bile her İş Analistinin log okuma konusunda sahip olması gereken temel bilgileri sade ve uygulamaya dönük şekilde ele alacağım.

1. Log Nedir? Neden Önemlidir?

Log, bir sistemin çalışırken ürettiği olay kayıtlarıdır.

Bir kullanıcının giriş yapması, bir servisin hata vermesi, bir entegrasyonun zaman aşımına uğraması… Bunların hepsi loglara yazılır.

Loglar sayesinde şunları anlayabiliriz:

• Bir hatanın gerçekten oluşup oluşmadığını
• Hatanın hangi adımda gerçekleştiğini
• Hatanın kullanıcıdan mı, sistemden mi, entegrasyondan mı kaynaklandığını
• Sorunun tekrarlı mı yoksa tekil mi olduğunu

İş Analisti için log, varsayımı gerçeğe dönüştüren en güçlü kaynaktır.

2. Bir Log Satırını Okumak

Örnek bir log satırı şöyle olabilir:

2026-02-20 14:32:11 ERROR PaymentService - Timeout while calling AccountAPI - userId=45821 - correlationId=abc123

Bunu parçalayalım:

• Tarih/Saat → Olayın gerçekleştiği an
• Log Seviyesi (ERROR) → Olayın ciddiyeti
• Servis Adı (PaymentService) → Hangi uygulama bileşeni
• Mesaj → Ne oldu?
• Ek Parametreler (userId, correlationId) → İz sürmek için kritik bilgiler

Bir BA için en önemli sorular:

• Bu hata iş sürecinin hangi adımına karşılık geliyor?
• Kullanıcı hangi aksiyonu almış olabilir?
• Bu hata iş kuralı mı, teknik hata mı?

3. Log Seviyelerini Bilmek Hayat Kurtarır

Çoğu sistem şu log seviyelerini kullanır:

• INFO → Bilgilendirici
• WARN → Potansiyel risk
• ERROR → İş akışını bozan hata
• DEBUG → Detaylı teknik bilgi

Bir BA olarak her WARN mesajını kriz olarak yorumlamak doğru değildir. Ancak ERROR seviyesindeki loglar genellikle iş sürecini etkiler.

Örneğin:

• INFO: “User login successful” → Sorun yok
• WARN: “Retrying connection to service” → Sistem toparlamış olabilir
• ERROR: “Order creation failed” → İş kaybı riski var

4. İş Analistinin Log Okuma Senaryosu

Senaryo: “Ödeme alınamadı” şikayeti

İş birimi şöyle der: “Müşteri ödeme yapamıyor, sistem hata veriyor.”

Yapılması gerekenler:

1. Zaman aralığını belirleme

• Saat kaçta olmuş?

2. Kullanıcı bilgisi alma

• userId, müşteri numarası

3. Hatanın katmanını tespit etme

• Frontend mi?
• Backend mi?
• Entegrasyon mu?

Eğer logda şöyle bir kayıt varsa:

ERROR PaymentService - Insufficient balance

Bu teknik değil, iş kuralı hatasıdır.

Ama şöyleyse:

ERROR PaymentService - Connection refused to BankAPI

Bu entegrasyon kaynaklıdır.

5. Log Okurken Sorulması Gereken 7 Kritik Soru

1. Bu hata tekrarlı mı?
2. Aynı zaman aralığında başka servisler de etkilenmiş mi?
3. Bu hata deploy sonrası mı başladı?
4. Hata tüm kullanıcıları mı etkiliyor yoksa belirli bir segmenti mi?
5. Timeout mu, validation mı?
6. Bu bir data problemi mi?
7. İş kuralı dokümanında bu durum tanımlı mı?

6. Teknik Ekiple Daha Güçlü İletişim İçin

Log okuyabilen bir BA şunları yapabilir:

• “Sistem çalışmıyor.” demez.
• “14:32’de PaymentService, AccountAPI çağrısında timeout almış.” der.

Bu fark:

• Toplantı süresini kısaltır
• Gereksiz tartışmaları önler
• Güvenilirliğinizi artırır

7. API ve Loglara Test Sırasında Nasıl Bakılır?

1- Web Uygulamasında F12 / Developer Tools

• Web tarayıcında F12 tuşu ile açılan Developer Tools en hızlı ve basit yöntemdir.
• Network sekmesi altında yapılan tüm API çağrılarını görülebilir:
  - Endpoint URL: Hangi servise istek gönderildi
  - HTTP method: GET, POST gibi çağrı türü
  - Request body ve headers: Gönderilen veriler ve yetkilendirme bilgisi
  - Response body ve status code: Servisten gelen cevap ve hata kodları (200, 400, 500…)

Örnek:
Müşteri “Hesap Hareketleri” butonuna tıkladı → Network’te /accounts/transactions API’si çalıştı → Response 500 ise backend’de bir hata var demektir.

2- Backend / Test Ortamı Logları

• Bankalarda loglar genellikle sunucuda değil, test ortamı için hazırlanmış log yönetim araçları üzerinden incelenir:
• Splunk, Kibana, Graylog gibi log analiz platformları
• QA Dashboard / Admin Panel
• API Gateway Logları (test kullanıcıları için)

8. Sonuç

Log okuma becerisi, iş analistlerinin yazılım hatalarını hızlıca tespit etmesine, test senaryolarını iyileştirmesine ve teknik ekiplerle daha verimli çalışmasına yardımcı olur. Düzenli olarak log analizleri yapmak ve doğru araçları kullanmak, bu süreci daha verimli hale getirecektir.

Peki bir iş analisti olarak Figma ile nasıl prototip hazırlanır? Gereksinim, nasıl dokunulabilir bir deneyime dönüştürülür? İşte adım adım bir yolculuk…

1- Neden Prototip İş Analistinin İşini Kolaylaştırır?

Klasik gereksinim dökümanlarının “statik” yapısı, ekipler arasında yanlış anlama riskini artırabilir. Prototipler ise:

✔ Gereksinimleri görsel hale getirir
✔ “Şunu demek istedim” tartışmalarının önüne geçer
✔ UI/UX ekibiyle etkileşimi hızlandırır
✔ Yazılımcıların iş yükünü netleştirir
✔ Stakeholder onay sürecini hızlandırır
✔ Kullanıcı testlerine zemin oluşturur

Özetle: Bir prototip, konuşmayı gereksinimlerden deneyime taşır.

2- İş Analistleri İçin Neden Figma?

Figma’nın analistler için cazip hale gelmesinin nedenleri şunlardır:

Bu nedenle, Figma sadece tasarımcıların değil, iş analistlerinin de “konfor alanı” haline geldi.

3- Gereksinim → Wireframe → Prototip Süreç Zinciri

Bu geçişte önemli olan, ekrana ne geleceğini anlamak değil, ekranın kullanıcı için hangi sorunu çözdüğünü belirlemektir.

4- Figma’da Temel Yapı Taşları

5- Figma’da Prototip Nasıl Hazırlanır?

Bir tasarımın gerçek değerini ortaya çıkaran şey, onun çalışır hâlini gösterebilmektir. Statik ekranlar bir fikri anlatır; prototip ise deneyimi yaşatır.

Bu yazıda, Figma üzerinden bir mobil uygulama prototipini adım adım nasıl oluşturabileceğinizi anlatıyorum.

1. Önce Tasarım Ekranlarını Oluşturun

Prototip aşamasına geçmeden önce tüm ekranlarınızı ayrı Frame’ler olarak oluşturun.

Örneğin bir mobil bankacılık uygulaması için:

• Welcome ekranı
• Login ekranı
• Account ekranı
• Payment ekranı
• Transaction ekranı

Her ekranı ayrı bir iPhone frame’i olarak tasarlayın. Prototip bağlantıları bu frame’ler arasında kurulacaktır.

2. Prototype Sekmesine Geçin

Sağ panelde yer alan: “Design | Prototype” sekmesinden Prototype alanını seçin.

Bu sekmeye geçtiğinizde:

• Interaction ayarları görünür
• Flow listesi aktif olur
• Bağlantı kurabileceğiniz mavi noktalar ortaya çıkar

Artık ekranlarınızı birbirine bağlamaya hazırsınız.

3. Başlangıç Ekranını Belirleyin

Prototipiniz açıldığında hangi ekranın görüneceğini belirlemeniz gerekir.

Bunun için:

1. Başlangıç yapmak istediğiniz ekranı seçin (örneğin Welcome).
2. Sağ panelde “Set as starting point” seçeneğine tıklayın.
3. Flow adını belirleyin (örneğin: Main Flow).

Bu ekran artık prototipin başlangıç noktası olacaktır.

4. Ekranlar Arası Bağlantı Oluşturun

Şimdi etkileşimleri tanımlayın.

1. Bir butonu seçin (örneğin “Login”).
2. Butonun yanında çıkan mavi noktayı sürükleyin.
3. Gitmek istediğiniz ekranın üzerine bırakın.

Bu işlem iki ekran arasında bir bağlantı oluşturur.

5. Interaction Ayarlarını Yapılandırın

Bağlantıyı oluşturduktan sonra sağ panelde şu ayarları yapılandırın:

• Trigger: On Click
• Action: Navigate To
• Destination: Hedef ekran
• Animation: Instant / Smart Animate / Slide

Daha akıcı ve gerçekçi bir deneyim için mümkün olduğunca Smart Animate kullanın.

6. Farklı Akışlar Oluşturun

Aynı projede birden fazla Flow oluşturabilirsiniz.

Örneğin:

• Ana kullanıcı akışı
• QR ödeme akışı
• Kart ekleme akışı

Her biri için ayrı başlangıç noktası belirleyerek farklı senaryoları test edebilirsiniz.

7. Cihaz Ayarlarını Yapın

Sağ paneldeki Prototype Settings bölümünden cihaz seçin.

Örneğin:

• iPhone 15 Pro
• iPhone 14
• Custom

Bu seçim, önizleme sırasında tasarımınızın gerçek cihaz çerçevesinde görünmesini sağlar.

8. Prototipi Test Edin

Sağ üstteki “▶️” (Play) butonuna tıklayarak prototipi çalıştırın.

Şunları kontrol edin:

• Tüm butonlar doğru ekrana gidiyor mu?
• Geri dönüş akışları çalışıyor mu?
• Animasyonlar doğal mı?
• Eksik bağlantı var mı?

Test etmeden teslim etmeyin.

9. Bağlantıları Düzenleyin veya Silin

Yanlış oluşturulmuş bir bağlantıyı silmek için:

• Mavi bağlantı çizgisini seçin.
• Ucundan sürükleyerek boş alana bırakın.

Bağlantı kaldırılacaktır.

6- Kaynak Referansı

Daha teknik detaylara inmek isteyenler için Figma’nın resmi “Guide to Prototyping in Figma” dokümantasyonu, bağlantı türleri, animasyon yapılandırmaları ve akış optimizasyonu konularında kapsamlı bir rehber niteliğindedir.

7- Sonuç

Figma, iş analistlerinin sadece “anlatan” değil, “gösteren” profesyonellere dönüşmesini sağlar. Doğru kullanıldığında hem ekipler arası iletişimi optimize eder hem de gereksinimleri kullanıcı deneyimiyle birleştirerek daha güçlü bir ürün vizyonu oluşturur.

Prototipler, artık bir “ekstra” değil; analistin olmazsa olmaz araçlarından biridir. Figma ile bu dilde uzmanlaşmak, geleceğin iş analistleri için stratejik bir adımdır.

1. SQL Nedir ve Neden Önemlidir?

SQL (yapılandırılmış sorgu dili), ilişkisel veri tabanlarıyla etkileşim kurmak için tasarlanmış bir programlama dilidir.

İş analistlerinin SQL öğrenmesi neden önemlidir?

• Veri Bağımsızlığı: IT departmanına bağımlı kalmadan verilere erişebilirsiniz
• Derinlemesine Analiz: Karmaşık veri ilişkilerini ortaya çıkarabilirsiniz
• Raporlama Esnekliği: İhtiyaca göre özelleştirilmiş raporlar hazırlayabilirsiniz
• Zaman Tasarrufu: Tekrarlayan analizleri otomatize edebilirsiniz
• Kariyer Gelişimi: Veri bilimi ve analitik alanlarına geçiş için temel oluşturur

2. Veri Tabanı Temel Kavramları

SQL’e geçmeden önce, bazı temel veri tabanı kavramlarını anlamak önemlidir:

• Tablo: Satır ve sütunlardan oluşan, verilerin saklandığı yapıdır
• Satır (Row/Record): Tablodaki her bir veri girdisidir
• Sütun (Column/Field): Belirli bir veri türünü temsil eder (örn. isim, tarih, sayı)
• Birincil Anahtar (Primary Key): Her kaydı benzersiz şekilde tanımlayan değerdir
• Yabancı Anahtar (Foreign Key): Başka bir tablodaki birincil anahtara referans veren alandır
• İndeks (Index): Veri arama hızını artıran veri yapısıdır
• İlişki (Relationship): Tablolar arasındaki bağlantılardır (one-to-one, one-to-many, many-to-many)

3. SQL Temel Sözdizimi ve Komutları

SQL komutları genellikle dört kategoriye ayrılır:

1- Veri Sorgulama Dili (DQL — Data Query Language)

• SELECT: Veri okuma ve sorgulama

2- Veri Manipülasyon Dili (DML — Data Manipulation Language)

• INSERT: Yeni veri ekleme
• UPDATE: Mevcut veriyi güncelleme
• DELETE: Veri silme

3- Veri Tanımlama Dili (DDL — Data Definition Language)

• CREATE: Yeni tablo veya veritabanı oluşturma
• ALTER: Tablo yapısını değiştirme
• DROP: Tablo veya veritabanını silme

4- Veri Kontrol Dili (DCL — Data Control Language)

• GRANT: Kullanıcı izinleri verme
• REVOKE: Kullanıcı izinlerini geri alma

2. SQL’in Temelleri

SQL, ilişkisel veritabanlarını yönetmek için kullanılan bir sorgu dilidir. İş analistleri için önemli bazı temel komutlar şunlardır:

SELECT * FROM musteriler;
SELECT isim, soyisim FROM musteriler WHERE sehir = 'Istanbul';

• SELECT: Veriyi sorgulamak için kullanılır.
• FROM: Hangi tablodan veri çekileceğini belirtir.
• WHERE: Belirli koşullara göre veriyi filtreler.
• ORDER BY: Sonuçları sıralamak için kullanılır.
• LIMIT: Belirli sayıda sonuç almak için kullanılır.

3. Veri Filtreleme

SQL’de filtreleme işlemleri büyük önem taşır. Örneğin:

SELECT * FROM siparisler WHERE tutar > 1000;
SELECT * FROM musteriler WHERE dogum_tarihi BETWEEN '1990-01-01' AND '2000-12-31';

• BETWEEN: Belirli bir aralıktaki değerleri filtreler.
• IN: Belirli bir liste içindeki değerleri getirir.
• LIKE: Metinsel eşleşmeler için kullanılır (% ve _ wildcard karakterleri ile).

4. Veri Analizi İçin SQL

İş analistleri, veri analizini daha iyi yapmak için aşağıdaki fonksiyonları kullanabilir:

SELECT sehir, COUNT(*) AS musteri_sayisi FROM musteriler GROUP BY sehir;
SELECT kategori, AVG(fiyat) FROM urunler GROUP BY kategori;

• GROUP BY: Verileri belirli bir sütuna göre gruplar.
• HAVING: Gruplanmış verilere filtre uygular.
• COUNT, SUM, AVG, MIN, MAX: Sayısal veriler üzerinde analiz yapar.

5. Birden Fazla Tablo ile Çalışma

Gerçek dünyada veriler genellikle birden fazla tabloda bulunur. JOIN komutları, bu tabloları birleştirmek için kullanılır.

SELECT siparisler.siparis_id, musteriler.isim
FROM siparisler
INNER JOIN musteriler ON siparisler.musteri_id = musteriler.musteri_id;

• INNER JOIN: Her iki tabloda eşleşen verileri döndürür.
• LEFT JOIN: Sol tablodaki tüm verileri ve sağ tablodan eşleşenleri getirir.
• RIGHT JOIN: Sağ tablodaki tüm verileri ve sol tablodan eşleşenleri getirir.

6. Alt Sorgular ve İleri SQL Teknikleri

Bazı analizlerde iç içe sorgular kullanmak gerekebilir:

SELECT isim, soyisim FROM musteriler WHERE musteri_id IN (SELECT musteri_id FROM siparisler WHERE tutar > 5000);

• EXISTS ve NOT EXISTS: Belirli bir koşula uyan kayıtların varlığını kontrol eder.
• CASE WHEN: Koşullu veri manipülasyonu sağlar.

7. Örnek Temel SQL Sorguları & Gerçek Hayattan Kullanım Örnekleri

SELECT Komutu

-- Temel sorgu yapısı
SELECT sütun1, sütun2 FROM tablo_adı;

-- Tüm sütunları seçmek için
SELECT * FROM müşteriler;

-- Belirli sütunları seçmek için
SELECT müşteri_id, ad, soyad FROM müşteriler;

WHERE Komutu ile Filtreleme

-- Temel filtreleme
SELECT * FROM siparişler WHERE sipariş_tarihi > '2023-01-01';

-- Çoklu koşul
SELECT * FROM ürünler WHERE kategori = 'Elektronik' AND fiyat < 1000;

-- IN operatörü ile çoklu değer
SELECT * FROM çalışanlar WHERE departman IN ('Satış', 'Pazarlama');

-- LIKE operatörü ile metin araması
SELECT * FROM müşteriler WHERE email LIKE '%gmail.com';

ORDER BY ile Sıralama

-- Artan sıralama (default)
SELECT * FROM ürünler ORDER BY fiyat;

-- Azalan sıralama
SELECT * FROM siparişler ORDER BY sipariş_tarihi DESC;

-- Çoklu sütuna göre sıralama
SELECT * FROM çalışanlar ORDER BY departman, maaş DESC;

LIMIT ile Sonuç Sayısını Sınırlama

-- İlk 10 kaydı getir
SELECT * FROM log_kayıtları ORDER BY tarih DESC LIMIT 10

GROUP BY ve Toplama Fonksiyonları

-- Departmanlara göre ortalama maaş
SELECT departman, AVG(maaş) as ortalama_maaş 
FROM çalışanlar 
GROUP BY departman;

-- Yıllara ve aylara göre toplam satış
SELECT 
    YEAR(sipariş_tarihi) as yıl, 
    MONTH(sipariş_tarihi) as ay, 
    SUM(tutar) as toplam_satış
FROM siparişler
GROUP BY YEAR(sipariş_tarihi), MONTH(sipariş_tarihi)
ORDER BY yıl, ay;

Yaygın Toplama Fonksiyonları

-- Müşteri sayısı
SELECT COUNT(*) as müşteri_sayısı FROM müşteriler;

-- En yüksek, en düşük ve ortalama sipariş tutarı
SELECT 
    MAX(tutar) as en_yüksek_sipariş, 
    MIN(tutar) as en_düşük_sipariş, 
    AVG(tutar) as ortalama_sipariş
FROM siparişler;

HAVING ile Grup Filtreleme

-- 10'dan fazla siparişi olan müşteriler
SELECT müşteri_id, COUNT(*) as sipariş_sayısı
FROM siparişler
GROUP BY müşteri_id
HAVING COUNT(*) > 10;

-- Toplam satışı 100.000 TL'den fazla olan departmanlar
SELECT departman, SUM(satış_tutarı) as toplam_satış
FROM satışlar
GROUP BY departman
HAVING SUM(satış_tutarı) > 100000

Tablolar Arası İlişkiler ve JOIN İşlemleri

-- Müşteri bilgileri ile siparişleri birleştirme (INNER JOIN)
SELECT m.müşteri_id, m.ad, m.soyad, s.sipariş_id, s.tutar, s.sipariş_tarihi
FROM müşteriler m
INNER JOIN siparişler s ON m.müşteri_id = s.müşteri_id;

-- Hiç sipariş vermemiş müşterileri de listele (LEFT JOIN)
SELECT m.müşteri_id, m.ad, m.soyad, s.sipariş_id
FROM müşteriler m
LEFT JOIN siparişler s ON m.müşteri_id = s.müşteri_id
WHERE s.sipariş_id IS NULL;

-- Ürün, kategori ve tedarikçi bilgilerini birleştirme (çoklu JOIN)
SELECT ü.ürün_adı, k.kategori_adı, t.tedarikçi_adı, ü.fiyat
FROM ürünler ü
INNER JOIN kategoriler k ON ü.kategori_id = k.kategori_id
INNER JOIN tedarikçiler t ON ü.tedarikçi_id = t.tedarikçi_id
WHERE ü.stok_miktarı > 0;

Alt Sorgular (Subqueries)

-- Ortalama maaştan yüksek maaş alan çalışanlar
SELECT ad, soyad, maaş
FROM çalışanlar
WHERE maaş > (SELECT AVG(maaş) FROM çalışanlar);

-- Her departmandaki en yüksek maaşı alan çalışanlar
SELECT d.departman_adı, ç.ad, ç.soyad, ç.maaş
FROM çalışanlar ç
INNER JOIN departmanlar d ON ç.departman_id = d.departman_id
WHERE (ç.departman_id, ç.maaş) IN (
    SELECT departman_id, MAX(maaş)
    FROM çalışanlar
    GROUP BY departman_id
)

Satış Analizi ve Raporlama

-- Ürün kategorilerine göre aylık satış trendi
WITH AylıkSatışlar AS (
    SELECT 
        k.kategori_adı,
        DATE_FORMAT(s.sipariş_tarihi, '%Y-%m') as ay,
        SUM(sd.miktar * sd.birim_fiyat) as satış_tutarı
    FROM sipariş_detayları sd
    JOIN siparişler s ON sd.sipariş_id = s.sipariş_id
    JOIN ürünler ü ON sd.ürün_id = ü.ürün_id
    JOIN kategoriler k ON ü.kategori_id = k.kategori_id
    WHERE s.sipariş_tarihi >= DATE_SUB(CURRENT_DATE(), INTERVAL 12 MONTH)
    GROUP BY k.kategori_adı, DATE_FORMAT(s.sipariş_tarihi, '%Y-%m')
)
SELECT 
    kategori_adı,
    ay,
    satış_tutarı,
    LAG(satış_tutarı) OVER (PARTITION BY kategori_adı ORDER BY ay) as önceki_ay_satış,
    (satış_tutarı - LAG(satış_tutarı) OVER (PARTITION BY kategori_adı ORDER BY ay)) / 
    LAG(satış_tutarı) OVER (PARTITION BY kategori_adı ORDER BY ay) * 100 as aylık_büyüme_yüzde
FROM AylıkSatışlar
ORDER BY kategori_adı, ay;

Müşteri Segmentasyonu ve RFM Analizi

RFM (Recency-Frequency-Monetary) analizi, müşterileri satın alma davranışlarına göre segmentlere ayırmak için kullanılır.

-- RFM Analizi
WITH RFM_Data AS (
    SELECT 
        m.müşteri_id,
        m.ad,
        m.soyad,
        MAX(s.sipariş_tarihi) as son_sipariş_tarihi,
        DATEDIFF(CURRENT_DATE(), MAX(s.sipariş_tarihi)) as recency,
        COUNT(DISTINCT s.sipariş_id) as frequency,
        SUM(s.tutar) as monetary
    FROM müşteriler m
    JOIN siparişler s ON m.müşteri_id = s.müşteri_id
    WHERE s.sipariş_tarihi >= DATE_SUB(CURRENT_DATE(), INTERVAL 2 YEAR)
    GROUP BY m.müşteri_id, m.ad, m.soyad
),
RFM_Scores AS (
    SELECT 
        *,
        NTILE(5) OVER (ORDER BY recency DESC) as r_score,
        NTILE(5) OVER (ORDER BY frequency) as f_score,
        NTILE(5) OVER (ORDER BY monetary) as m_score
    FROM RFM_Data
)
SELECT 
    *,
    CONCAT(r_score, f_score, m_score) as rfm_score,
    CASE 
        WHEN r_score >= 4 AND f_score >= 4 AND m_score >= 4 THEN 'VIP'
        WHEN r_score >= 3 AND f_score >= 3 AND m_score >= 3 THEN 'Sadık Müşteri'
        WHEN r_score >= 3 AND f_score >= 1 AND m_score >= 2 THEN 'Potansiyel Sadık'
        WHEN r_score >= 4 AND f_score <= 2 AND m_score <= 2 THEN 'Yeni Müşteri'
        WHEN r_score <= 2 AND f_score >= 3 AND m_score >= 3 THEN 'Risk Altında'
        WHEN r_score <= 2 AND f_score <= 2 AND m_score <= 2 THEN 'Kaybedilmiş'
        ELSE 'Düşük Potansiyel'
    END as segment
FROM RFM_Scores

Envanter ve Stok Yönetimi

-- Stok rotasyonu ve tükenmek üzere olan ürünler
SELECT 
    ü.ürün_id,
    ü.ürün_adı,
    k.kategori_adı,
    ü.stok_miktarı,
    ü.güvenlik_stoğu,
    SUM(sd.miktar) as son_30_gün_satış,
    CASE 
        WHEN ü.stok_miktarı = 0 THEN 'Stokta Yok'
        WHEN ü.stok_miktarı <= ü.güvenlik_stoğu THEN 'Kritik Seviye'
        WHEN ü.stok_miktarı <= SUM(sd.miktar) THEN 'Risk Altında'
        ELSE 'Yeterli Stok'
    END as stok_durumu,
    CASE 
        WHEN ü.stok_miktarı > 0 THEN SUM(sd.miktar) / ü.stok_miktarı
        ELSE NULL 
    END as stok_rotasyon_oranı
FROM ürünler ü
JOIN kategoriler k ON ü.kategori_id = k.kategori_id
LEFT JOIN sipariş_detayları sd ON ü.ürün_id = sd.ürün_id
LEFT JOIN siparişler s ON sd.sipariş_id = s.sipariş_id AND s.sipariş_tarihi >= DATE_SUB(CURRENT_DATE(), INTERVAL 30 DAY)
GROUP BY ü.ürün_id, ü.ürün_adı, k.kategori_adı, ü.stok_miktarı, ü.güvenlik_stoğu
ORDER BY stok_rotasyon_oranı DESC

Çalışan Performans Analizi

-- Satış temsilcisi performans karşılaştırması
SELECT 
    ç.çalışan_id,
    ç.ad,
    ç.soyad,
    COUNT(s.sipariş_id) as toplam_sipariş,
    SUM(s.tutar) as toplam_satış,
    AVG(s.tutar) as ortalama_sipariş_değeri,
    COUNT(DISTINCT s.müşteri_id) as müşteri_sayısı,
    SUM(s.tutar) / COUNT(DISTINCT s.müşteri_id) as müşteri_başına_satış,
    RANK() OVER (ORDER BY SUM(s.tutar) DESC) as satış_sıralaması
FROM çalışanlar ç
JOIN siparişler s ON ç.çalışan_id = s.satış_temsilcisi_id
WHERE ç.departman_id = 3 -- Satış departmanı ID'si
AND s.sipariş_tarihi >= DATE_SUB(CURRENT_DATE(), INTERVAL 3 MONTH)
GROUP BY ç.çalışan_id, ç.ad, ç.soyad;

Bankacılık Sektöründe İşlem Hacmi Analizi

SELECT musteri_id, SUM(tutar) AS toplam_tutar FROM islemler GROUP BY musteri_id HAVING toplam_tutar > 10000;

E-Ticaret Sitelerinde Müşteri Segmentasyonu

SELECT musteri_id, COUNT(siparis_id) AS siparis_sayisi FROM siparisler GROUP BY musteri_id ORDER BY siparis_sayisi DESC;

Kullanıcı Davranış Analizi

SELECT urun_id, COUNT(*) AS goruntulenme_sayisi FROM urun_goruntulemeler GROUP BY urun_id ORDER BY goruntulenme_sayisi DESC;

8. Sonuç ve Kaynaklar

İş analistleri için SQL öğrenmek, veri tabanlarını anlamak ve veriye dayalı kararlar almak açısından kritik bir beceridir. SQL öğrenme sürecinde takip edebileceğiniz kaynaklar:

• Kitaplar: “İlişkisel Veritabanı Tasarlama ve SQL ile Geliştirme” — Dr. Selçuk KIRAN
• Uygulama Siteleri: SQLZoo, LeetCode SQL

Fakat artık bu araçları üretme şeklimiz değişiyor: Yapay zekâ ile diyagram hazırlama, hem hız hem de doğruluk açısından süreçleri oldukça hızlandırıyor.

Bu yazıda, bir iş analisti olarak AI’ın diyagram hazırlama sürecini nasıl dönüştürdüğünü, hangi yaklaşımların daha etkili olduğunu ve kendi projelerimde uyguladığım yöntemleri paylaşacağım.

1. Flowchart Nedir?

Flowchart, bir sürecin başlangıcından sonuna kadar olan tüm adımları kutular ve yön gösteren oklar ile anlatan diyagram türüdür, akış diyagramıdır.

Genellikle:

• Süreç adımlarını,
• Karar noktalarını (yes/no, doğru/yanlış),
• Hata akışlarını

görsel olarak anlatır.

Flowchart’ın amacı: “Bu süreç nasıl işliyor?” sorusunu hızla yanıtlamaktır.

2. Sequence Diagram Nedir?

Sequence diagram, bir süreçte yer alan farklı bileşenlerin (actor, mobile app, API, servisler vb.) zaman içerisindeki mesajlaşmalarını gösterir.

Yani “Süreçte hangi aktör hangi servise hangi sırayla çağrı yapıyor?” sorusunun cevaplanmasını sağlamaktadır. Özellikle backend ekipleri için çok faydalıdır.

3. Neden AI ile Diyagram Oluşturuyoruz?

a. 30 Dakikalık Çizimi 30 Saniyeye İndiriyor

Bir akışın kutularını sürükle–bırak ile tek tek oluşturmak yerine; sadece süreci açıklıyoruz ve AI otomatik olarak diyagramın kodlarını oluşturuyor.

b. Eksik Adımları Tespit Ediyor

AI, süreçleri analiz ederken eksik adımları tespit edebiliyor. Bu sayede hata riskini de en aza indiriyor.
Örneğin:
“Bu adımda kullanıcı onayı gerekiyor mu?”
“Burada bir hata akışı tanımlamadın, eklememi ister misin?” gibi geri bildirimlerle süreci zenginleştiriyor.

c. Diyagramlar Teknik Ekiplerle İletişimi Güçlendiriyor

Sequence diagram’lar özellikle backend ekipleri için oldukça faydalı. AI ile hazırlanan diyagramlar, standart UML yapısında çıktığı için ekipler arasında yanlış anlaşılmayı azaltıyor. Diyagramlar, analizde açıklanan gereksinimlerin daha kolay anlaşılmasını sağlıyor.

4. Hangi Araçlar Kullanılabilir?

a. ChatGPT / Claude + Mermaid / PlantUML

İlk olarak süreci bir AI aracına (ChatGPT / Claude / Gemini vs.) metin olarak tanımlamanız gerekiyor. Burada hazırladığınız prompt çok önemli. Ne kadar detaylı bir prompt hazırlarsanız, diyagram için gerekli kodunuz o kadar doğru olur.

Daha sonra ChatGPT / Claude bunu otomatik olarak Mermaid veya PlantUML koduna dönüştürüyor.

Örnek Prompt:

“Mobil Bankacılık Digital Onboarding akışı için Mermaid / PlantUML formatında flowchart / sequence diagram oluştur.”

Örnek Çıktı:

Mermaid — Flowchart:

flowchart TD

A([Başlangıç]) --> B[Kayıt Ol]
B --> C[Telefon Numarası Girişi]
C --> D[OTP Gönder]
D --> E{OTP Doğru mu?}
E -->|Hayır| C
E -->|Evet| F[KVKK & Açık Rıza]

F --> G[Temel Bilgi Girişi]
G --> H{Mernis Doğrulama}
H -->|Başarısız| G
H -->|Başarılı| I[Kimlik Doğrulama Yöntemi]

I --> J1[NFC ile Kimlik]
I --> J2[Kimlik Fotoğrafı]
I --> J3[Pasaport]

%% NFC Akışı
J1 --> K1[NFC Bilgi Okuma]
K1 --> L1{Doğrulandı mı?}
L1 -->|Hayır| J1
L1 -->|Evet| M[Selfie / Liveness]

%% Fotoğraf Akışı
J2 --> K2[Kimlik Fotoğrafı Çek]
K2 --> L2{OCR Doğru mu?}
L2 -->|Hayır| J2
L2 -->|Evet| M

%% Pasaport Akışı
J3 --> K3[MRZ Okuma]
K3 --> L3{MRZ Doğru mu?}
L3 -->|Hayır| J3
L3 -->|Evet| M

%% Ortak Selfie
M --> N{Face Match Başarılı mı?}
N -->|Hayır| M
N -->|Evet| O[Adres Bilgisi]

O --> P[Fraud & Risk Kontrolü]
P --> Q{Risk Uygun mu?}
Q -->|Hayır| R([Red → Süreç Sonu])
Q -->|Evet| S[Sözleşmeler]

S --> T[Elektronik İmza]
T --> U[Hesap Açılışı]
U --> V([Hoş Geldiniz])

PlantUML — Sequence Diagram:

@startuml
title Digital Onboarding – Sequence Diagram

actor User
participant "Mobile App" as App
participant "Backend API" as API
participant "KYC Service" as KYC
participant "Mernis" as Mernis
participant "OCR/NFC Service" as IDService
participant "Face Match Service" as Face
participant "Risk Engine" as Risk

User -> App: Uygulamayı açar
User -> App: Kayıt Ol tıklar

User -> App: Telefon numarası girer
App -> API: OTP oluştur
API -> App: OTP gönderilir
User -> App: OTP girer
App -> API: OTP doğrulama isteği
API --> App: OTP doğrulandı

User -> App: KVKK / Açık Rıza onayı
App -> API: Rıza kaydı

User -> App: Temel bilgiler (Ad, Soyad, TCKN)
App -> API: Bilgi gönder
API -> Mernis: Kimlik doğrulama
Mernis --> API: Başarılı

User -> App: Kimlik doğrulama yöntemi seçer
App -> IDService: NFC/OCR/MRZ kimlik doğrulama talebi
IDService --> App: Kimlik bilgisi başarılı

User -> App: Selfie / Liveness testi
App -> Face: FaceMatch isteği
Face --> App: Eşleşme başarılı

User -> App: Adres bilgisi girer
App -> API: Adres verisi gönder

App -> Risk: Fraud & Risk skoru isteği
Risk --> App: Risk uygun

App -> API: Sözleşme onayı + e-imza
API --> App: Hesap açılışı tamamlandı

App -> User: Hoş geldiniz ekranı
@enduml

Daha sonra bu çıktıları Mermaid veya PlantUML’e yapıştırmanız gerekiyor ve saniyeler içinde diyagramımız hazır oluyor :)

Mermaid:

PlantUML:

5. AI Kullanırken Edindiğim 3 Öğrenim:

a. Süreci Önce Basitleştir, Sonra AI’a Ver

Uzun ve karmaşık metinler AI’ı kararsızlaştırabiliyor. Ben genelde şu sırayı izliyorum:

• Senaryoyu 5–10 maddelik yalın adımlara bölüyorum
• Önce flowchart için gerekli kodu ürettiriyorum
• Daha sonra teknik detayları ekleyip flowchart / sequence diagram’a dönüştürüyorum

Bu sıra hem netlik sağlıyor hem de çıktıların tutarlı olmasını garanti ediyor.

b. “Hata Akışları” AI’ın En Çok Unuttuğu Kısım

AI genelde happy path’e odaklanıyor. Bu nedenle diyagram çıktıktan sonra mutlaka şu soruyu soruyorum:“Bu süreçte olası tüm hata ve istisna akışlarını diyagrama ekle.”

Bu sayede eksik hiçbir şey kalmıyor.

c. AI’dan Alınan Diyagram Son Hal Değil, İlk Taslak

Genel bir yanılgı var, AI diyagramı hızlandırıyor ama analistin düşünme kasını devre dışı bırakmıyor. Aldığımız çıktı birinci versiyon, geliştirdiğimiz / detayları eklediğimiz kısım analistin uzmanlığı oluyor.

6. AI ile Diyagram Üretirken En Verimli Prompt Şablonu

Aşağıdaki şablon örnek prompt olarak kullanılabilir:

“Proje: [Kısa proje açıklaması].
Amaç: [Flowchart mı, sequence diagram mı?]
Kapsam adımları:

…

…

…

…

Diyagramı UML/standart formatta üret. Eksik gördüğün yerleri sor. Tüm hata akışlarını dahil et.”

Bu yapı net olduğu için AI hem daha doğru hem daha kapsamlı diyagram üretiyor.

7. Sonuç: AI, Analistin Yerini Almıyor Üretkenliğini Artırıyor

İş analisti olarak diyagram bizim için çok önemli. AI ise bunu daha hızlı, daha net ve daha az insan hatasıyla hazırlamamızı sağlıyor.

Yapay zekâ sayesinde:

• Analiz dokümanları daha tutarlı
• Süreç akışları daha eksiksiz
• Teknik ekiplerle iletişim daha güçlü hale geliyor.

Geleceğe dair net bir gerçek var: AI kullanan analistler, kullanmayanlara göre daha hızlı, daha görünür ve daha stratejik bir konumda olacaktır. Bu dönüşümün merkezinde olmak ise tamamen bizim elimizde :)

Her ne kadar geliştiriciler tarafından sıklıkla kullanılsa da, iş analistleri, test uzmanları, SEO uzmanları ve tasarımcılar F12 araçlarını verimli bir şekilde kullanabilir. Bu yazıda, Google Developer Tools’un sunduğu çeşitli işlevleri ve bunların nasıl kullanılabileceğini detaylı bir şekilde ele alacağız.

Klavyenizde yer alan “F12” tuşuna tıklayarak yukarıdaki gibi developer tools’un açılmasını sağlayabilirsiniz.

Developer Tools’ta Yer Alan Alanlar

1. HTML, CSS ve JavaScript İnceleme

F12 araçları sayesinde, bir web sayfasının HTML, CSS ve JavaScript kodlarını anlık olarak inceleyebilir ve düzenleyebilirsiniz.

Nasıl Kullanılır:

• Elements Paneli: HTML yapısını incelemenizi sağlar. Sayfa üzerindeki herhangi bir öğeye tıklayarak, bu öğenin HTML yapısına ve stil özelliklerine ulaşabilirsiniz. Ayrıca, öğeleri düzenleyerek sayfa üzerindeki anlık değişiklikleri görebilirsiniz.
• Styles Paneli: Seçilen öğenin CSS stilini görmenize olanak tanır. Buradan öğelerin stilini değiştirebilir, renkler, fontlar gibi özellikleri hızlıca test edebilirsiniz.

Kullanım Örneği:

Bir e-ticaret sitesindeki ürün sayfasının fiyat stilini değiştirmek istiyorsanız, fiyatın bulunduğu öğeyi tıklayarak ilgili CSS kodunu bulabilir ve değiştirebilirsiniz. Böylece sayfanın anlık görünümünü değiştirebilir ve görsel tasarımı test edebilirsiniz.

2. Ağ Trafiği Takibi (Network Monitoring)

Network sekmesi, web sayfanızın ağ trafiğini takip etmenizi sağlar. Sayfaya yüklenen her dosya, görsel, script ve stil sayfası burada listelenir.

Nasıl Kullanılır:

• Network Paneli: Sayfa yüklendikçe, yüklenen her bir dosyanın ne zaman ve nasıl yüklendiğini görebilirsiniz. Sayfa üzerinde gerçekleşen her ağ isteği (API çağrıları, JSON verileri vs.) buradan takip edilebilir. Bu paneli, sayfanın hızını ölçmek için de kullanabilirsiniz.
• Resource Yükleme Süresi: Sayfa yüklenme süresi, ağ gecikmeleri, dosya boyutları ve yükleme sıralaması burada görülür. Ayrıca sayfanın her bir bileşeninin ne kadar süreyle yüklendiğini izleyebilirsiniz.

Kullanım Örneği:

Bir web sitesinin yavaş yüklenmesi durumunda, Network panelini kullanarak hangi dosyaların uzun süre yüklendiğini ve sayfa yükleme süresini analiz edebilirsiniz. Bu, sayfanın hızını artırmak için hangi unsurların optimize edilmesi gerektiğini belirlemenize yardımcı olur.

3. JavaScript Konsolu (Console)

JavaScript hatalarını ve loglarını izlemek için Console Paneli oldukça faydalıdır. Web sayfasındaki hataları, uyarıları ve log mesajlarını burada görüntüleyebilirsiniz.

Nasıl Kullanılır:

• Console Paneli: JavaScript hataları, uyarılar ve log mesajları burada görüntülenir. Geliştiriciler bu paneli, sayfa üzerinde çalışan JavaScript kodlarını incelemek ve hatalarını ayıklamak için kullanır. Ayrıca burada kullanıcı etkileşimlerini test edebilir ve konsola manuel komutlar girerek sayfa üzerinde anlık işlemler gerçekleştirebilirsiniz.

Kullanım Örneği:

Bir kullanıcı formu gönderildiğinde bir hata mesajı alıyorsanız, Console panelini açarak JavaScript hatalarını kontrol edebilir ve hatanın kaynağını öğrenebilirsiniz. Bu, sayfa üzerindeki etkileşimlerdeki olası hataları hızla tespit etmenizi sağlar.

4. Web Sayfası Performans Analizi (Performance)

Web sayfasının performansını analiz etmek için Performance Paneli kullanılabilir. Bu araç, sayfanın ne kadar sürede yüklendiğini, hangi kaynakların ne kadar zaman aldığını ve hangi fonksiyonların yavaş çalıştığını gösterir.

Nasıl Kullanılır:

• Performance Paneli: Sayfanın yüklenme süresi ve her bir işlemin detaylı zaman çizelgesini görüntüler. Sayfanın performansını etkileyen unsurları bulmak için bu paneli kullanabilirsiniz. Bu, sayfa optimizasyonu ve hız iyileştirmeleri yapmak için çok önemlidir.

Kullanım Örneği:

Bir kullanıcı sayfayı ziyaret ettiğinde sayfanın çok yavaş yüklendiğini fark ettiyseniz, Performance panelini açarak hangi işlemlerin sayfa yükleme süresini uzattığını analiz edebilirsiniz. Örneğin, ağır görseller veya JavaScript işlemleri sayfanın yavaş yüklenmesine neden olabilir.

5. Mobil Cihaz Görünümü Testi (Device Emulation)

Device Mode, sayfanın farklı mobil cihazlarda nasıl göründüğünü test etmenizi sağlar. Bu, responsive (duyarlı) tasarım testleri yapmak için mükemmel bir araçtır.

Nasıl Kullanılır:

• Device Mode: F12 aracında Device Toolbar ikonuna tıklayarak, farklı mobil cihazların ekran boyutlarında web sayfasını görüntüleyebilirsiniz. Bu özellik, mobil uyumluluk testi yapmanızı sağlar ve sayfanın farklı cihazlarda nasıl göründüğünü kontrol etmenize yardımcı olur.

Kullanım Örneği:

Bir e-ticaret sitesinin mobil sürümünde ürün resimlerinin çok büyük göründüğünü fark ettiğinizde, Device Mode’u kullanarak bu durumu farklı mobil cihazlarda test edebilir ve tasarımı iyileştirebilirsiniz.

6. Depolama (Storage) ve Çerezler (Cookies) İzleme

Web sayfası üzerinde kullanılan çerezleri ve yerel depolama alanlarını izlemek için Application Paneli kullanılır.

Nasıl Kullanılır:

• Cookies: Web sayfası tarafından kullanılan tüm çerezleri buradan görüntüleyebilirsiniz. Ayrıca çerezlerin değerlerini değiştirebilir ve silebilirsiniz.
• Local Storage ve Session Storage: Web sayfası, verileri tarayıcıda depolamak için yerel depolama kullanıyorsa, bu verilere erişebilirsiniz.

Kullanım Örneği:

Bir e-ticaret sitesinin sepete eklenen ürünlerin çerezlerde tutulduğunu fark ettiğinizde, bu çerezleri izleyerek hangi ürünlerin ekli olduğunu ve doğru şekilde kaydedilip edilmediğini kontrol edebilirsiniz.

7. SEO Denetimi

F12 araçları, SEO (arama motoru optimizasyonu) açısından da faydalıdır. Lighthouse aracı, sayfanın SEO uyumluluğunu kontrol etmenizi sağlar.

Nasıl Kullanılır:

• Lighthouse Paneli: SEO, erişilebilirlik, performans ve en iyi uygulamalar hakkında raporlar alabilirsiniz. Bu araç, sayfanın SEO performansını test etmenize ve iyileştirme önerileri almanıza yardımcı olur.

Kullanım Örneği:

Bir web sayfasının SEO performansını değerlendirmek için Lighthouse aracını kullanarak sayfanın meta verileri, başlık etiketleri, alt etiketleri ve mobil uyumluluğunu test edebilirsiniz. Bu, SEO stratejinizi geliştirmek için çok önemlidir.

8. Yapay Zeka Desteği (AI Assistance)

AI Assistance, Chrome DevTools içinde deneysel olarak sunulan ve Google’ın Gemini modeliyle desteklenen bir yapay zeka asistanıdır. Bu özellik, üzerinde çalıştığınız web sayfasının teknik detaylarına dayalı olarak, stil, ağ trafiği, kaynaklar ve performans gibi konularda anlık bilgi ve çözüm önerileri sağlar.

AI Assistance sayesinde:

Stil Sorunları: Seçili DOM elemanlarının neden belirli şekilde göründüğünü, hangi CSS özelliklerinin etkili olduğunu ve olası stil hatalarının nasıl düzeltileceğini öğrenebilirsiniz.

Ağ Sorunları: API hataları, CORS problemleri veya yavaş yanıt süreleri gibi durumların nedenlerini hızlıca anlayabilir ve çözüm önerileri alabilirsiniz.

Performans İyileştirmeleri: Sayfa performans profilinizi analiz ederek, darboğazları ve yavaş kaynakları tespit edip, iyileştirme yollarını öğrenebilirsiniz.

DevTools’un AI Assistance paneli, özellikle karmaşık projelerde, hem geliştiricilere hem de iş analistlerine zaman kazandırarak daha verimli çalışma imkanı sunmaktadır.

Kullanım Örneği:

Örneğin, bir e-ticaret sitesinde ürün sayfasının yavaş yüklenme sorununu tespit etmek için Network veya Performance panelinden ilgili isteğe sağ tıklayarak AI’dan nedenini ve çözüm önerisini öğrenebilirsiniz.

Sonuç

F12 Google Tools, yalnızca geliştiriciler için değil, iş analistleri, test uzmanları, SEO uzmanları ve tasarımcılar için güçlü bir araçtır. Web sayfalarını analiz etmek, hata ayıklamak, performans testleri yapmak ve sayfa tasarımlarını iyileştirmek için kullanabileceğiniz bu araç, web sitesinin sağlıklı çalışmasını sağlamanıza yardımcı olur. Developer Tools ile sayfanın iç yapısına hâkim olabilir, anlık değişiklikler yapabilir ve daha verimli bir çalışma ortamı oluşturabilirsiniz.

Bu yazıda, yazılım test mühendisliğinin ne olduğunu ve bu alana yeni başlayanların bilmesi gereken temel kavramları ele alacağız.

1. Yazılım Testi Nedir? Neden Önemlidir?

Yazılım testi, bir sistemin veya uygulamanın beklenen gereksinimleri karşılayıp karşılamadığını, hataları tespit ederek doğrulama sürecidir.

ISTQB’ye göre:

“Testing is the process consisting of all lifecycle activities, both static and dynamic, concerned with planning, preparation and evaluation of software products to determine that they satisfy specified requirements.”

Yani test, yazılımın doğru çalıştığından emin olmak için hem statik (kod inceleme, doküman analizi) hem de dinamik (çalışan yazılımın test edilmesi) yöntemleri içerir.

2. Testin Temel Amaçları:

• Müşteri / Kullanıcı memnuniyetini sağlamak.
• Hataları erken tespit etmek ve bu sayede maliyeti azaltmak.
• Yazılım kalitesini artırmak.
• Kullanıcı memnuniyetini sağlamak.
• Güvenlik ve performans açıklarını önlemek.

3. Yazılım Testi Yaşam Döngüsü (STLC)

Yazılım testleri belirli bir döngü içinde gerçekleştirilir. Bu döngü, Software Testing Life Cycle (STLC) olarak bilinir ve aşağıdaki adımlardan oluşur:

1. Gereksinim Analizi: Test edilecek fonksiyonların ve sistemin beklentilerinin belirlenmesidir.
2. Test Planlaması: Test stratejisinin oluşturulması ve kaynakların planlanmasıdır.
3. Test Tasarımı: Test senaryolarının oluşturulmasıdır.
4. Test Ortamının Kurulumu: Yazılımın test edileceği ortamın hazırlanmasıdır.
5. Test Çalıştırma: Testlerin uygulanması (koşulması) ve sonuçların kaydedilmesidir.
6. Test Sonuçlarının Değerlendirilmesi: Hata raporlarının oluşturulması ve iyileştirme sürecidir.

4. Temel Test Terimleri ve Kavramlar

Yazılım testinde sıkça karşılaşacağınız temel terimler şunlardır:

• Test Case (Test Vakası): Belirli bir fonksiyonu/yazılımı test etmek için kullanılan adımların, girdilerin ve beklenen çıktının tanımlandığı adımdır.
• Test Suite (Test Paketi): Birbiriyle ilişkili test senaryolarının (test case’lerinin) bir araya getirildiği pakettir.
• Defect/Bug (Hata): Yazılımın beklenen davranışı ile gerçekleşen davranışı arasındaki uyuşmazlıktır.
• Error (Hata/Kusur): Geliştirme aşamasında yapılan ve yazılımın hatalı çalışmasına sebep olabilecek insan kaynaklı yanlışlıklardır.
• Failure (Başarısızlık): Bir hata (bug) nedeniyle yazılımın beklenen şekilde çalışmamasıdır.
• Verification (Doğrulama): “Doğru mu yapıyoruz?” sorusuna odaklanır. Yazılım geliştirme sürecinde dokümanların ve kodun incelenerek hataların erken aşamada tespit edilmesini sağlar (Statik test).
• Validation (Geçerleme): “Doğru olanı mı yapıyoruz?” sorusunu yanıtlar. Yazılımın son kullanıcı beklentilerini ve gereksinimlerini karşılayıp karşılamadığını değerlendirir (Dinamik test).
• Test Environment (Test Ortamı): Yazılımın test edildiği ortamdır (DEV, SIT, UAT, PRE-PROD, PROD).
• Test Execution (Test Çalıştırma): Hazırlanan test senaryolarının uygulanarak sonuçlarının analiz edilmesi sürecidir.

5. Yazılım Test Teknikleri: Black Box, White Box ve Gray Box

a) Black-Box Test (Siyah Kutu Testi)

Yazılımın iç yapısı bilinmeden, sadece girdiler ve çıktılar analiz edilerek yapılan test yöntemidir. Kullanıcı perspektifinden yazılımın nasıl çalıştığını anlamaya odaklanır.

b) White-Box Test (Beyaz Kutu Testi)

Kodun iç yapısına ve mantığına odaklanan test yöntemidir. Genellikle yazılım geliştiriciler tarafından yapılır. Kodlar, döngüler ve koşullar test edilir.

c) Gray-Box Test (Gri Kutu Testi)

Hem kod yapısı hem de fonksiyonellik dikkate alınarak yapılan test yöntemidir. Test mühendisi, sistem hakkında bazı bilgilere sahiptir, ancak tüm detayları bilmez. Özetle; hem Black Box hem de White Box tekniklerinin kombinasyonudur.

6. Test Seviyeleri

a) Birim Testi (Unit Test): Yazılımın en küçük yapı taşları (fonksiyonlar, metotlar, sınıflar veya modüller) ayrı ayrı test edilir. Genelde bu testi yazılım geliştirme ekibi yapar. (Örneğin; Bir hesap makinesi uygulamasında, topla(a, b) fonksiyonunun doğru çalıştığını test etmek.)

b) Entegrasyon Testi: Birden fazla modülün bir araya geldiğinde, modüller birbirleriyle doğru çalışıp çalışmadığı kontrol edilir. API testleri, veritabanı bağlantıları veya harici sistemlerle entegrasyonlar burada test edilir.

c) Sistem Testi: Tüm yazılım sistemi bir bütün olarak test edilir. Hem fonksiyonel hem de performans, güvenlik gibi sistemsel testler bu aşamada yapılır. (Örneğin; Bir bankacılık uygulamasında, para transferi sürecinin baştan sona doğru çalıştığını kontrol etmek.)

d) Kabul Testi (UAT — User Acceptance Testing): Yazılımın son kullanıcı tarafından test edildiği aşamadır. Kullanıcı gereksinimlerinin karşılandığını doğrulamak için yapılır. Genellikle iş birimleri veya müşteriler tarafından gerçekleştirilir.

7. Test Türleri

a) Regresyon Testi: Yeni kod değişikliklerinin mevcut fonksiyonları bozup bozmadığını kontrol eden test türüdür. Yazılım güncellemeleri sonrasında yapılır.

b) Smoke Test: Sistemin temel fonksiyonlarının çalıştığını doğrulamak için yapılan hızlı bir testtir. Yazılımın temel bileşenleri test edilerek derinlemesine testlere devam edilip edilmeyeceğine karar verilir. (Örneğin: Kullanıcı girişi, ana sayfa yükleniyor mu?)

c) Monkey Test: Sistemin beklenmedik kullanıcı davranışlarına tepkisinin testidir. Rastgele girdiler verilerek sistemin dayanıklılığı test edilir. (Örneğin: Rastgele tıklamalar, hızlı tuş kombinasyonları)

8. Özel Test Türleri

a) Mobil Testler

• Cihaz Uyumluluğu Testi: Mobil uygulamaların farklı cihazlarda (iOS/Android) ve ekran boyutlarında sorunsuz çalışmasını sağlamak için yapılır. İşletim sistemi versiyonları, ekran çözünürlükleri, donanım farklılıkları test edilir. (Örnek Test Senaryosu: Uygulama, Samsung Galaxy S23 (Android 13) ve iPhone 14 Pro (iOS 16) üzerinde aynı şekilde mi görünüyor?)
• Performans Testi: Uygulamanın kaynak tüketimi ve kullanıcı deneyimini optimize etmek için yapılır. (Bellek Kullanımı (RAM), Pil Tüketimi, CPU Kullanımı) (Örnek Test Senaryosu: X uygulaması 1 saat boyunca kullanıldığında %15'ten fazla pil tüketiyor mu?)
• Touch Gesture Testi: Kullanıcıların dokunmatik ekran ile etkileşimlerini test etmek için yapılır (Temel Dokunma, Kaydırma, Çoklu Dokunmatik, Uzun Basma). (Örnek Test Senaryosu: Google Maps’te iki parmakla yakınlaştırma yapıldığında harita düzgün zoom oluyor mu?)
• Fonksiyonel Testler: Uygulamanın özelliklerinin beklendiği gibi çalışıp çalışmadığı test edilir.

b) Web Testleri

• Cross-browser Test (Tarayıcılar Arası Uyumluluk Testi): Web sitelerinin farklı tarayıcılarda (Chrome, Firefox, Safari, Edge) doğru görüntülenip çalıştığını kontrol etmek için yapılır. (Örnek Test Senaryosu: Web sitesi, Safari’de bir butonun üzerine gelindiğinde “hover efekti” (renk değişimi, gölge) doğru gösteriyor mu?)
• Responsive Test: Web sitelerinin mobil, tablet ve masaüstü cihazlarda doğru görüntülendiğinden emin olmak için yapılır. (Örnek Test Senaryosu: Web sitesi, iPhone SE gibi küçük ekranlarda kaydırılabilir mi yoksa içerik kesiliyor mu?)
• Yük Testi (Load Testing): Web sitesinin yoğun trafik altında nasıl performans gösterdiğini ölçmek için yapılır. (Örnek Test Senaryosu: E-ticaret web sitesi Black Friday’de 10.000 kullanıcıyı kaldırabilir mi?)

c) OS (Operating System) Testi

İşletim sistemi testi, bir işletim sisteminin fonksiyonel doğruluğunu, performansını, güvenliğini ve uyumluluğunu kontrol etmek için yapılan yazılım test sürecidir. Windows, Linux, macOS, Android ve iOS gibi işletim sistemlerinin stabilitesini ve kullanılabilirliğini kontrol etmek için önemli bir testtir.

d) Erişilebilirlik Testi

Erişilebilirlik testi, yazılımın özel gereksinimli kullanıcılar tarafından ne kadar kolay kullanılabildiğini test eder. Bu testin amacı, görme, işitme, motor veya bilişsel engellere sahip kullanıcıların yazılımı etkili bir şekilde kullanabilmesini sağlamaktır.

Erişilebilirlik testleri belirli yasal düzenlemelere ve standartlara uygun olarak gerçekleştirilir:

• WCAG (Web Content Accessibility Guidelines): Web içeriğinin erişilebilir olması için belirlenen uluslararası standarttır.

WCAG’e göre 3 Yasal Uyumluluk Seviyesi bulunmaktadır:

• A Seviyesi (Minimum): Temel erişilebilirlik, minimum uyumluluk seviyesidir.
• AA Seviyesi (İdeal): Çoğu durumda yeterli, genel yasal uyumluluk seviyesidir.
• AAA Seviyesi (Üstün): Özel durumlar için, en katı düzeydir.

Erişilebilirlik Testinde Kullanılan Araçlar

• Screen Reader (Ekran Okuyucular): NVDA, Talkback, JAWS, VoiceOver
• Renk Kontrast Kontrolü: Axe DevTools, WAVE, Colour Contrast Analyzer
• Klavyeyle Gezinme Testleri: Klavye kısayollarıyla yazılımın kullanılabilirliği test edilir.
• Otomatik Erişilebilirlik Test Araçları: Lighthouse (Chrome DevTools), TAW

Erişilebilirlik Testinde Kontrol Edilen Kriterler

• Sayfa ve bileşenlerin ekran okuyucularla uyumlu olması
• Tüm fonksiyonların fare kullanılmadan klavyeyle erişilebilir olması
• Renk körlüğü dostu tasarım (Yeterli kontrast ve renk kullanımına dikkat edilir)
• Alternatif metinler (Görsel içeriklerin sesli açıklamaları)
• Odak sırası ve gezinme kolaylığı
• Sesli komutlarla kullanım kolaylığı

Erişilebilirlik testi, yazılımın geniş bir kullanıcı kitlesi tarafından sorunsuz bir şekilde kullanılmasını sağlayarak kullanıcı deneyimini iyileştirir.

9. ISTQB Sertifikasyonu

ISTQB, yazılım testi alanında dünya çapında kabul gören bir sertifikasyon programı sunar. ISTQB sertifikasyonları şunlardır:

- Foundation Level (CTFL): Temel yazılım testi bilgilerini kapsar.

- Advanced Level (CTAL): Test yönetimi, test analizi ve teknik test analizini içerir.

- Expert Level: Yazılım testinde uzmanlaşmak isteyenler için sunulan en ileri düzey sertifikasyondur.

ISTQB sertifikasyonu sayesinde test mühendisleri, uluslararası standartlara uygun bilgi birikimine sahip olabilir ve kariyerlerinde avantaj sağlayabilirler.

10. Sonuç

Yazılım testi, yazılım geliştirme sürecinin kritik bir parçasıdır ve kaliteyi artırmak için doğru stratejilerle uygulanmalıdır. Yazılım testine başlayan herkesin temel kavramları ve ISTQB gibi sertifikasyonları bilmesi, kariyerlerinde büyük bir avantaj sağlayacaktır.

Ek olarak; aşağıdaki kaynakları da mutlaka okumanızı tavsiye ederim :)

• https://www.turkishtestingboard.org/files/ISTQB_CTFL_Syllabus-v40-TR.pdf
• https://www.turkishtestingboard.org/files/ISTQB-Yazilim-Testi-Terimler-Sozlugu.pdf

Son yıllarda yapılan bilimsel araştırmalar, yapay zekânın performansının özellikle iyi tasarlanmış girdilere bağlı olarak %30 ila %50 oranında artabileceğini göstermiştir.

1. Prompt Mühendisliği Nedir?

Prompt mühendisliği, yapay zeka modellerine verilen girdileri (promptları) optimize ederek daha iyi, doğru ve verimli çıktılar elde etme sürecidir. İstenen çıktı için basit bir soru sormak yerine, daha açık, yönlendirici bir biçimde komut oluşturmak, modelin daha doğru ve istenilen sonuca uygun çıktılar üretmesini sağlar.

Yeni nesil mesleklerden olan “prompt mühendisliği” AI dil modelleriyle doğru bir iletişim kurmayı ve bu yönde de çıktılar almayı amaçlayan bir doğal dil işleme (NLP) alt dalıdır.

Örneğin:

• Kötü Prompt: “Bana yapay zeka hakkında bilgi ver.”
• İyi Prompt: “Yapay zekanın tarihçesi ve günümüzde kullanım alanları hakkında akademik bir dille 500 kelimelik bir makale yaz.”

Görüldüğü gibi, ikinci prompt net, belirgin bir format içeriyor ve modelin ne yapması gerektiğini daha iyi anlatıyor.

2. Neden Önemlidir?

Etkili bir prompt oluşturmak, şu avantajları sağlar:

• Belirsiz ifadeler yerine net komutlar vermek, modelin daha doğru yanıtlar üretmesini sağlar.
• Yanlış veya eksik sonuçlar almak yerine, doğrudan ihtiyacınıza uygun çıktılar alabilirsiniz.
• Doğru yönlendirilmiş bir yapay zeka, içerik üretimi ve problem çözme süreçlerinde daha yaratıcı çözümler sunabilir.

3. Etkili Prompt Nasıl Yazılır?

• Açık ve net olunmalıdır.
• İstenen format belirtilmelidir (Liste, tablo, flowchart vb.).
• Rol tanımlanmalıdır.
• Adım adım yönlendirme içermelidir.

Etkili Kullanım Örnekleri:

1- Küresel ısınmanın nedenleri, sonuçları ve çözüm yollarını ele alan, bilimsel kaynaklara dayalı 1000 kelimelik bir makale yaz.

2- Bir banka müşterisinin internet bankacılığı üzerinden fatura ödeme sürecini içeren bir kullanıcı hikayesi yaz. Format: [Kullanıcı Hikayesi, Kabul Kriterleri, Ön Koşullar].

3- Banka müşterilerinin kredi kartı başvurusu yaptığı sürecin adımlarını listeleyerek, her adımın zaman tahminiyle birlikte bir süreç haritası oluştur.

4- Bir bankanın mobil uygulamasında para transferi işlemi için 5 adet pozitif ve 5 adet negatif test senaryosu oluştur.

5- Aşağıdaki müşteri geri bildirimlerini analiz et ve en sık tekrar eden 3 ana şikayet konusunu belirleyerek bir rapor hazırla. Yanıtını tablo formatında hazırla.

6- Bir bankacılık mobil uygulaması için yeni bir kredi başvuru modülü geliştiriyoruz. Kullanıcıların temel adımları takip ederek kredi başvurusu yapmasını sağlayacak bir iş gereksinimi dokümanı hazırla.

7- Bir bankanın FAST ödeme sürecinin işleyişini anlatan bir süreç akış şeması oluştur. Süreç adımlarını detaylı olarak listele.

8- Türkiye’deki açık bankacılık regülasyonlarını özetleyerek, bir bankanın bu regülasyonlara nasıl uyum sağlayabileceğine dair bir rapor hazırla.

4. Prompt Mühendisliğinin Temel Teknikleri

• Few-shot Learning: Modele birkaç örnek vererek yönlendirme yapılmasıdır. (Örnek Kullanım: Şu formatta yanıt ver: Soru: … Cevap: …”)
• Chain-of-Thought Prompting: Mantıksal adımlarla, kademeli sorular sorularak yanıt istenmesidir. (Örnek Kullanım: Adım adım açıkla: … )
• Zero-shot Prompting: Modele tek seferde cevap vermesini isteme yöntemidir. (Örnek Kullanım: Ay neden parlak görünür?)
• Self-Consistency Decoding: Birden fazla cevap üretip en iyisini seçmesini istenmelidir. (Örnek Kullanım: Aynı soruya 5 farklı yanıt üret ve en tutarlısını seç.)
• In-Context Learning: Bu teknikte, modele birkaç örnek sunularak belirli bir görevi nasıl yerine getirmesi gerektiği öğretilir. (Örnek Kullanım: Modelden bir çeviri yapması isteniyorsa, ona birkaç çeviri örneği verilerek istenilen dil çiftinde çeviri yapması sağlanır.)

5. Etkili Prompt Mühendisliği Kullanılabilecek Alanlar

Etkili prompt mühendisliği, aşağıdaki alanlarda kullanılabilir:

1- İş Analizi & Yazılım Testi → Gereksinim analizi, akış diyagramı, test senaryosu yazımı
2- Kod Yazımı & Yazılım → Programlama dili desteği, hata ayıklama, algoritma üretimi
3- Eğitim → Ders notları, özetler, açıklamalar, makaleler
4- Pazarlama & SEO → Reklam metinleri, ürün açıklamaları, anahtar kelime analizi

6. Gelecekte Prompt Mühendisliği

Prompt mühendisliği, yapay zeka teknolojileri geliştikçe daha da önem kazanacak bir alan haline gelecektir. Özellikle, büyük dil modellerinin daha yaygın kullanılmaya başlamasıyla birlikte, bu modelleri etkili bir şekilde yönlendirme ihtiyacı artacaktır.

Gelecekte, prompt mühendisliği alanında otomatik prompt optimizasyon araçları, prompt tasarımı için yapay zeka destekli sistemler ve daha gelişmiş prompt test yöntemleri ortaya çıkabilir.

Sonuç

Prompt mühendisliği, yapay zeka modellerinin potansiyelini tam anlamıyla ortaya çıkarmak için kritik bir rol oynar. Doğru şekilde tasarlanmış promptlar, modelin daha doğru, tutarlı ve kullanışlı sonuçlar üretmesini sağlar. Bu alanda yapılacak çalışmalar, yapay zeka teknolojilerinin daha geniş kitleler tarafından etkili bir şekilde kullanılmasına yardımcı olacaktır.

Özetlemek gerekirse;
✔ Açık, net ve spesifik promptlar oluşturun.
✔ Modele rol verin ve format belirleyin.
✔ Kademeli sorular sorun ve gerektiğinde örnekler verin.
✔ Chain-of-Thought ve Few-shot gibi teknikleri kullanarak daha güçlü sonuçlar elde edin.

Bu teknikleri kullanarak yapay zekayı maksimum verimle kullanabilir ve daha doğru sonuçlar alabilirsiniz.

Agile ve Scrum Nedir?

Agile (Çevik), yazılım geliştirme ve proje yönetimi süreçlerinde kullanılan bir yaklaşımdır. Temelinde, müşteri memnuniyetini artırmak, değişen gereksinimlere hızlıca uyum sağlamak ve sürekli iyileştirme prensibiyle çalışmak vardır. Agile, uzun ve detaylı planlamalar yerine, kısa iterasyonlar (sprintler) halinde çalışarak projeleri daha yönetilebilir hale getirir.

2001 yılında yayımlanan Agile Manifesto, bu yaklaşımın temel ilkelerini ortaya koyar. Büyük projelerin küçük, yönetilebilir parçalara (iterasyonlara) ayrılması, sürekli geri bildirim ve gelişim odaklı çalışmayı öne çıkarır.

Scrum, Agile metodolojisinin en popüler uygulama çerçevelerinden biridir. Scrum, küçük ve kendi kendini yönetebilen ekiplerin, belirli bir zaman dilimi içinde (genellikle 2–4 hafta) hedeflenen işleri tamamlamasına odaklanır. Scrum’ın temel bileşenleri şunlardır:

• Product Owner (Ürün Sahibi): Ürünün vizyonunu belirleyen ve gereksinimleri önceliklendiren kişidir.
• Scrum Master: Scrum süreçlerinin doğru bir şekilde uygulanmasını sağlayan kişidir.
• Development Team (Geliştirme Ekibi): Ürünü geliştiren ve teslim eden ekip üyeleridir.

Agile ve Scrum’ın İş Analizinde Rolü

1. Agile dünyasında iş analistleri, klasik uzun dokümantasyon yerine, kullanıcı hikayeleri (user stories) yazarak gereksinimleri tanımlar.

2. İş analistleri, Ürün Sahibi (Product Owner) ve geliştirme ekibiyle sürekli iletişim halinde olur.

3. Sprint Planlama, Günlük Scrum Toplantıları (Daily) ve Geri Bildirim Döngüleri (Retrospectives) gibi süreçlerde aktif rol alır.

Agile ve Scrum’ın Avantajları

• Değişen müşteri gereksinimlerine hızlı yanıt verir.
• Küçük teslimatlar sayesinde hatalar erken tespit edilir.
• Şeffaflık ve sık geri bildirim ile daha motive ekipler oluşturur.
• Kullanıcı geri bildirimleriyle ürün daha iyi şekillendirilir.

Agile ve Scrum’ın Dezavantajları

• Agile, değişen gereksinimlere açık bir metodolojidir. Ancak bu, proje boyunca sürekli değişikliklerin olabileceği anlamına gelir. Bu durum, özellikle büyük ve karmaşık projelerde belirsizliğe neden olabilir.
• Geleneksel metodolojilere kıyasla daha az dokümantasyon, özellikle yeni katılan ekip üyeleri veya dış paydaşlar için bilgi eksikliği oluşturabilir.
• Agile ekiplerin sürekli iletişim ve koordinasyon içinde olması gerekir; disiplin eksikliği durumunda, süreç karmaşaya dönüşebilir.
• Scrum, ekip üyelerinin kendi kendini yönetebilmesini ve yüksek düzeyde iş birliği içinde çalışmasını gerektirir. Ekip içinde iletişim sorunları veya yetkinlik eksikliği varsa, Scrum süreçleri verimli bir şekilde işlemeyebilir.
• Scrum’ın kısa iterasyonlara odaklanması, uzun vadeli stratejik planlamanın gözden kaçmasına neden olabilir. Bu, özellikle büyük ölçekli projelerde risk oluşturabilir.

Büyük Ölçekli Agile: SAFe ve Spotify Modeli

Agile ve Scrum, küçük ekipler ve projeler için oldukça etkili olsa da, büyük ölçekli organizasyonlarda uygulanması daha karmaşık hale gelebilir. Bu noktada, “SAFe (Scaled Agile Framework)” ve “Spotify Modeli” gibi çerçeveler devreye girer. Bu çerçeveler, Agile prensiplerini büyük ölçekli organizasyonlara uyarlamak için tasarlanmıştır.

SAFe (Scaled Agile Framework) Modeli Nedir?

SAFe, büyük ölçekli organizasyonlarda Agile prensiplerini uygulamak için kullanılan yapılandırılmış bir çerçevedir. Özellikle birden fazla ekip, departman veya projenin bir arada çalıştığı karmaşık yapılarda Agile’ın ölçeklendirilmesini sağlar. SAFe, yazılım geliştirme süreçlerinin yanı sıra ürün yönetimi, mühendislik ve iş stratejilerini de kapsar. SAFe, klasik Scrum ve Kanban gibi yöntemleri genişletir ve büyük ekiplerin senkronize çalışmasını sağlar.

SAFe’in Temel Özellikleri:

• Büyük şirketlerde farklı Agile ekiplerin koordinasyonunu sağlar.
• Çeyreklik planlama döngüleri ile uzun vadeli hedefler belirlenir.
• Çeşitli ekiplerin birlikte çalışmasını sağlayan yapılar oluşturulur.

Kimler Kullanır?

• Bankalar, sigorta şirketleri, büyük kurumsal firmalar
• 1000+ çalışanı olan organizasyonlar
• Karmaşık projelerde çalışan büyük ölçekli ekipler

Spotify Modeli Nedir?

Spotify Modeli, müzik platformu Spotify’ın Agile ekiplerini yönetmek için geliştirdiği bir organizasyonel yapıdır. Bu model, SAFe gibi katı bir çerçeve sunmaz; daha çok bir “yaklaşım” veya “kültür” olarak tanımlanır. Spotify Modeli, özellikle bağımsız ekipler ve esnek yapılar üzerine odaklanır.

• Kendi kendini yöneten küçük ekipler oluşturulur. (Squads)
• Benzer görevlerde çalışan birkaç squad’ın birleşimi sağlanır. (Tribes)
• Farklı takımların bilgi paylaşımını sağlayan yapılar kurulur. (Chapters & Guilds)

Başarılı Agile Örneği: ING Bank

ING Bank, 2015 yılında tüm organizasyonu Agile prensipleriyle dönüştürdü. ING Bank bunu nasıl başarmış olabilir?

• CEO ve üst yönetim Agile dönüşümüne öncülük etti.
• Spotify Modeli’nden ilham alarak küçük, çapraz fonksiyonlu ekipler (squads) oluşturuldu.
• Çalışanlar ve müşterilerden düzenli geri bildirim alındı.
• Dijital bankacılığa büyük yatırımlar yapıldı.

Sonuç olarak, ING Bank daha hızlı inovasyon yapabilen, müşteri odaklı bir organizasyon haline geldi ve müşteri memnuniyetinde büyük bir artış sağladı.

Başarısız Agile Örneği: Nokia

Nokia, 2000’lerin başında dünyanın en büyük mobil telefon üreticisiydi. 2005 yılında, şirketin bazı bölümlerinde Agile süreçleri uygulanmaya başlandı. Ancak başarısız oldu. Nokia neden başarısız olmuş olabilir?

• Üst yönetim, Agile kültürünü benimsemekte başarısız oldu.
• Ekipler, Agile prensiplerine uygun hareket etmedi ve eski hiyerarşik yapıyı sürdürdü.
• Gerçek bir değişim süreci yaşanmadı, ekipler eski yöntemlerini Agile gibi göstermeye çalıştı.

Sonuç olarak, Nokia pazarda rekabet avantajını kaybetti ve mobil telefon sektöründeki liderliğini yitirdi.

Başarısız Olan Şirketler Neden Başarısız Olur?

Agile ve Scrum prensiplerini benimseyen ancak beklenen başarıyı elde edemeyen şirketlerde sıkça rastlanan bazı sebepler şunlardır:

• Agile ve Scrum, hiyerarşik olmayan, esnek ve iş birliğine dayalı bir kültür gerektirir. Geleneksel hiyerarşik yapıya sahip şirketlerde, bu kültürel değişim sağlanamadığında Agile uygulamaları başarısız olabilir.
• Agile ve Scrum, doğru bir şekilde uygulanabilmesi için ekip üyelerinin bu metodolojiler hakkında yeterli bilgiye sahip olmasını gerektirir. Eğitim eksikliği, süreçlerin yanlış uygulanmasına ve başarısızlığa neden olabilir.
• Geleneksel çalışma yöntemlerine alışkın ekiplerin, değişime uyum sağlayamaması.
• Agile, müşteri geri bildirimlerine dayalı bir metodolojidir. Müşterinin sürece aktif olarak katılmaması veya geri bildirimlerin zamanında alınmaması, ürünün beklentileri karşılamamasına neden olabilir.
• Scrum’ın kısa iterasyonlara odaklanması, ekip üyeleri üzerinde aşırı iş yükü oluşturabilir. Bu durum, ekip motivasyonunun düşmesine ve verimliliğin azalmasına neden olabilir.
• Bazı şirketler, Agile ve Scrum’ı sadece bir “trend” olarak görüp, temel prensiplerini anlamadan uygulamaya çalışır. Bu durum, süreçlerin yanlış uygulanmasına ve başarısızlığa neden olur.

Sonuç

Agile ve Scrum, yazılım geliştirme süreçlerinde sürekli değişimi destekleyen ve müşteri odaklı çalışmayı teşvik eden güçlü proje yönetim metodolojileridir. Ancak, her şirket için uygun olmayabilir. Bu metodolojiler, yalnızca süreç değişikliği değil, kapsamlı bir organizasyonel dönüşüm gerektirir. Bu dönüşümün başarısı, kurumun kültürel yapısına, ekiplerin yetkinliğine ve yönetimin desteğine bağlıdır.

Nokia gibi firmalar, Agile’ı yüzeysel uygulayarak başarısız olurken, ING Bank gibi şirketler doğru stratejilerle büyük başarılar elde edebilmiştir. Bu süreçte, iş analistleri hem teknik hem de iletişim becerilerini kullanarak projelerin başarısına doğrudan katkı sağlamalıdır.

Bu yazıda, Agile ve Scrum’ın avantajları, dezavantajları, organizasyonel zorlukları ve destekleyici unsurlarını ele aldım. Umarım bu kapsamlı bakış açısı, Agile dönüşüm sürecinde karşılaşılabilecek zorlukları aşmada ve başarıya ulaşmada yol gösterici olur.

Tasarım Odaklı Düşünme Nedir?

Tasarım Odaklı Düşünme, kullanıcı ihtiyaçlarını merkeze alarak yaratıcı problem çözmeyi amaçlayan bir yöntemdir. Bu yaklaşım, insan odaklı bir bakış açısıyla çözüm üretmeyi teşvik eder ve genellikle beş aşamadan oluşur:

1. Empati Kurma: Kullanıcıların ihtiyaçlarını, zorluklarını ve duygularını anlamak.
2. Tanımlama: Problemi net ve kullanıcı odaklı bir şekilde tanımlamak.
3. Fikir Üretme: Çeşitli yaratıcı çözümler üretmek.
4. Prototip Oluşturma: Çözümleri görselleştirerek prototipler oluşturmak.
5. Test Etme: Prototipleri kullanıcılarla test edip geri bildirim almak.

Bu süreç, iş analistlerinin kullanıcıların gerçek problemlerini daha iyi anlamalarına ve daha etkili çözümler sunmalarına yardımcı olur.

İş Analistleri Neden Tasarım Odaklı Düşünmeye İhtiyaç Duyar?

İş analistlerinin temel görevi, projelerdeki gereksinimleri belirlemek ve bu gereksinimlerin en doğru şekilde karşılanmasını sağlamaktır. Ancak, geleneksel gereksinim toplama süreçleri bazen kullanıcıların gerçek ihtiyaçlarını gözden kaçırabilir. Tasarım Odaklı Düşünme yaklaşımı, iş analistlerinin şunları yapmasını sağlar:

• Kullanıcı Odaklı Gereksinim Toplama: Kullanıcılarla empati kurarak onların gizli ihtiyaçlarını ortaya çıkarabilir.
• Yaratıcı Çözümler Üretme: Problemleri farklı açılardan ele alarak yenilikçi çözümler geliştirebilir.
• Geri Bildirime Dayalı Süreçler: Prototip testleri sayesinde erken aşamalarda geri bildirim alarak projeyi daha doğru bir yöne yönlendirebilir.

Tasarım Odaklı Düşünme adımlarını aşağıdaki gibi detaylandırabiliriz:

1. Empati: Empati kurmak için Empati Haritaları kullanılabilir.

Empati Haritası Nedir? Nasıl Yapılır?

Empati Haritası, bir kullanıcıyla ilgili duyguları, düşünceleri, acıları ve kazanımları anlamaya yönelik bir araçtır. İş analistleri, empati haritası kullanarak kullanıcıların bakış açılarını daha iyi kavrayabilirler. Empati haritası genellikle altı ana bölüme ayrılır:

1- Hears (Duydukları): Kullanıcıların çevrelerinden duydukları şeyler. Örneğin, arkadaşları, aileleri veya iş arkadaşlarından gelen yorumlar, sosyal medya etkileri veya reklamlar.

2- Sees (Gördükleri): Kullanıcının gözlemleri, çevresindeki dünya, etkileşimde bulunduğu platformlar veya karşılaştığı diğer ürünler. Görsel ve çevresel faktörler kullanıcı deneyimini etkileyebilir.

3- Says & Does (Söyledikleri ve Yaptıkları): Kullanıcının açıkça ifade ettikleri veya günlük yaşamda gerçekleştirdikleri davranışlar. Bu, kullanıcının diğer insanlarla veya bir ürünle nasıl etkileşime girdiğini içerir.

4- Think & Feels (Düşünceleri ve Hissettikleri): Kullanıcının içsel düşünceleri, duyguları ve değerleri. Bu kısım, kullanıcının dışa vurmadığı, ancak derinlemesine düşünülmesi gereken faktörleri ifade eder.

5- Pain (Zorluklar): Kullanıcıların karşılaştığı zorluklar, engeller, rahatsızlıklar ve hayal kırıklıkları. Kullanıcıların problem çözmede yaşadıkları sıkıntılar bu bölümde yer alır.

6- Gain (Kazanç): Kullanıcıların elde etmek istedikleri sonuçlar veya kazançlar. Bu, kullanıcıların hedeflerine, arzularına veya isteklerine ulaşırken deneyimledikleri olumlu sonuçları ifade eder.

Empati haritası oluştururken, gerçek kullanıcı geri bildirimlerini ve gözlemleri baz alarak her bölümde somut veriler toplanmalıdır. Bu harita, kullanıcının perspektifinden çözüm geliştirmeyi kolaylaştırır ve tasarım süreçlerinde rehberlik eder.

2. Problemi Tanımlama

Empati aşamasında elde edilen veriler analiz edilerek ana problem tanımlanır. İş analistleri, bu aşamada net ve kullanıcı odaklı problem ifadeleri oluşturmalıdır. Örneğin, “Kullanıcılar, mobil bankacılık uygulamasında para transferi işlemini karmaşık buluyor.”

3. Fikir Üretme

Bu aşamada iş analistleri, farklı çözümler üzerine beyin fırtınası yapar. Tasarım ekibiyle iş birliği yaparak prototip fikirleri geliştirilebilir.

4. Prototip Oluşturma

İş analistleri, Balsamiq veya Figma gibi araçlarla düşük maliyetli prototipler oluşturabilir. Bu prototipler, geliştirici ekiplere daha net gereksinimler sunmak için kullanılabilir.

5. Test Etme

Prototipler, kullanıcılarla test edilerek geri bildirim toplanır. İş analistleri, bu geri bildirimleri analiz ederek çözümün kullanıcı ihtiyaçlarına uygun olup olmadığını değerlendirebilir.

Tasarım Odaklı Düşünme Araçları

İş analistlerinin Tasarım Odaklı Düşünme süreçlerini daha etkili hale getirmek için kullanabileceği bazı araçlar şunlardır:

• Persona Oluşturma: Persona, hedef kullanıcıları temsil eden, belirli özelliklere ve davranışlara sahip hayali karakterlerdir. İş analistleri, persona oluşturma aracılığıyla kullanıcıların ihtiyaçlarını, hedeflerini ve motivasyonlarını daha iyi anlayabilir.
• Empati Haritası: Kullanıcıların hislerini, düşüncelerini ve davranışlarını anlamak için kullanılır.
• Prototip Araçları: Tasarımların somut hale gelmesini sağlar ve fikirlerin görselleştirilmesine yardımcı olur. Popüler prototip hazırlama araçları arasında; Balsamiq, Figma, Adobe XD gibi araçlar yer alır.
• Kullanıcı Test Araçları: Prototiplerin ve tasarımların gerçek kullanıcılar üzerinde test edilmesini sağlar. Bu araçlar, kullanıcı geri bildirimlerini toplamak ve tasarımların doğruluğunu değerlendirmek için kullanılır. Popüler kullanıcı test araçları arasında; Maze, UsabilityHub gibi kullanıcı test araçları yer alır.

Sonuç olarak; Tasarım Odaklı Düşünme, iş analistlerinin projelere değer katmasını ve daha kullanıcı odaklı çözümler geliştirmesini sağlar. Bu da iş analistlerinin hem kullanıcı memnuniyetini artırmasını hem de projelerin başarısını olumlu yönde etkilemesini sağlar.

#TasarımOdaklıDüşünme #İşAnalizi #KullanıcıDeneyimi #EmpatiHaritası #DesignThinking #BusinessAnalysis #EmpathyMap