30 saniyelik özet
Domain Knowledge, yani alan bilgisi, bir işin kavramlarını, kurallarını, para ve veri akışlarını, kararlarını ve istisnalarını anlayabilmektir. Bir sektörde kullanılan kelimeleri bilmek bu anlayışın başlangıcıdır. İş analistinin asıl ihtiyacı, bir değişikliğin sürecin diğer parçalarında neyi etkileyeceğini görebilmektir. Alan bilgisi doğru soruları üretir, eksik gereksinimleri ortaya çıkarır ve teknik olarak çalışan bir çözümün işletmede yanlış sonuç yaratmasını önlemeye yardımcı olur.
Neden önemli?
Bir ekranda “iptal edildi” yazması, siparişin işletme açısından kapanmış olduğunu göstermeyebilir. Ödeme alınmış, stok ayrılmış, satıcı hazırlığa başlamış ve kargo etiketi üretilmiş olabilir. Bu durumların her biri farklı bir geri alma işlemi gerektirebilir. Ekranın davranışı doğru görünürken para veya stok kaydı yanlış kalabilir.
Alan bilgisi eksik olduğunda analist, kullanıcı talebini sistemin bütünü içinde sınamakta zorlanır. “Bu alan zorunlu olsun” isteğinin hangi kontrolü koruduğunu bilmezse kullanıcıya gereksiz yük getirebilir. “Bu onayı kaldıralım” talebinin hangi riski yönettiğini anlamazsa görünürde hızlanan sürecin başka bir noktada sorun üretmesine yol açabilir.
Junior bir iş analisti için bu bilgi, görüşmede anlamlı takip soruları sorabilmenin temelidir. Yönetici için ise yatırımın kapsamını değerlendirmeye yardımcı olur. Bir değişikliğin yalnızca arayüzü mü, operasyonu mu, gelir modelini mi etkilediğini anlamadan maliyet ve fayda değerlendirmesi eksik kalır.
Endüstri mühendisliği açısından burada tanıdık bir mesele vardır: Bir adımı iyileştirmek bütün sistemin performansını iyileştirmeyebilir. Sipariş alma hızlanırken depo kapasitesi değişmiyorsa bekleme başka yere taşınabilir. Alan bilgisi, yerel iyileştirmenin toplam sonuca katkısını sorgulamayı sağlar.
Terim nedir?
Alan bilgisi; belirli bir sektörün, iş modelinin veya operasyonun nasıl çalıştığına ilişkin bilgidir. E-ticarette sipariş ve iade süreçlerini, abonelik işinde kullanım hakkı ve yenileme ilişkisini, danışmanlıkta iş kapsamı ve teslim kabulünü anlamak buna örnektir. Aynı terim farklı işletmelerde farklı kurallarla uygulanabilir.
Bu bilgi birkaç katmanda oluşur. Önce iş modeli anlaşılır: Kime değer sunuluyor, hizmeti kim kullanıyor, bedeli kim ödüyor? Sonra süreç ve kararlar incelenir: İş hangi olayla başlıyor, nerede bekliyor, hangi koşulda tamamlanıyor? Ardından verinin anlamı araştırılır: Bir kaydın hangi duruma geçmesi hangi iş olayını temsil ediyor?
Örneğin “aktif müşteri” tanımı yalnızca hesabı bulunan kişiyi, ödeme yapan işletmeyi veya ürünü belirli koşullarda kullanan hesabı anlatabilir. Raporlarda aynı kelime kullanılırken farklı müşteri grupları sayılıyorsa ekipler aynı tablo üzerinden farklı kararlar verebilir. Alan bilgisinin bir çıktısı, bu kavramları işletme bağlamında ortaklaştırmaktır.
Analist her konuda uzman olmak zorunda değildir. Ancak bildiği kuralın kaynağını, geçerli olduğu koşulları ve doğrulaması gereken boşlukları bilmelidir. Konu uzmanının değerlendirmesini kendi varsayımıyla değiştirmemelidir. Finansal, operasyonel veya güvenlikle ilgili bir kuralın sahibi farklı olabilir; doğru bilgi ilgili rolden ve gerçek süreç kayıtlarından doğrulanır.
Bu nedenle alan bilgisi yalnızca deneyim süresiyle ölçülmez. Bir süreci açıklayabilmek, istisnasını gösterebilmek ve hangi bilginin belirsiz olduğunu söyleyebilmek daha kullanışlı ölçütlerdir. Uzun süredir aynı işi yapmak, işletmenin kurallarının değişmediği anlamına gelmez.
Gerçek vaka: Airbnb’de giriş akışını iş bağlamıyla tasarlamak
Airbnb’nin mühendislik yazısı, kullanıcıların uygulamaya düzensiz aralıklarla dönmesinin seyahat işinin doğal bir özelliği olduğunu anlatıyor. Uzun süre sonra dönen misafirin giriş yapamaması, rezervasyon fırsatını ve ev sahibinin gelirini etkileyebiliyor. Dolayısıyla giriş sorunu, kullanıcı bağlamı ve iş modeliyle birlikte ele alınmış.
Yeni yaklaşımda önce hangi hesaba giriş yapılmak istendiği belirleniyor, ardından kullanıcı ve oturum bilgilerine göre uygun doğrulama yöntemi sunuluyor. Kullanıcının ilk yöntemle ilerleyememesi durumunda alternatif bir yol seçebilmesi de tasarımın temel ilkelerinden biri olmuş. Şirket, mühendislik, ürün, tasarım, içerik ve veri bilimi ekiplerinin birlikte çalıştığını belirtiyor.
Bu vaka alan bilgisinin tasarıma etkisini gösteriyor: Kullanım sıklığı, hesap geçmişi ve kullanıcının koşulları, giriş akışının gereksinimlerini değiştirmiş. Buradan yapılabilecek çıkarım, başka bir ürünün giriş ekranını kopyalamanın aynı ihtiyacı karşılamayabileceğidir. Vaka, bütün seyahat ürünleri için geçerli tek bir doğrulama yöntemi önermez; çözümün kendi iş bağlamından türetildiğini gösterir.
Varsayımsal örnek: Pazaryerinde sipariş iptali
Birden fazla satıcının ürün sunduğu bir pazaryerinde müşterilerin siparişlerini iptal edebileceği bir akış geliştirildiğini düşünelim. İlk talep basit: “Sipariş detayına iptal düğmesi ekleyelim.” İş analisti, düğmenin görünmesinden önce iptalin işletmede ne anlama geldiğini araştırır.
Siparişin birden fazla satıcıdan gelen ürün içerebildiğini varsayalım. Bazı ürünler henüz hazırlanmamış, bazıları kargoya verilmiş olabilir. Bu durumda siparişin tamamını tek durumla temsil etmek yetersiz kalabilir. Analist; sipariş, satıcı teslimatı ve ürün satırı arasındaki ilişkileri anlamadan iptal kuralını yazmamalıdır.
Para akışında da sorular vardır. Ödeme hangi aşamada alınmıştır? İptal edilen ürünün bedeli hangi kayda dayanarak hesaplanacaktır? Kullanılan indirim kalan ürünleri etkiler mi? Satıcıya aktarılacak tutar ne zaman belirlenir? Bu soruların cevabı şirketin sözleşme, finans ve operasyon kurallarından doğrulanmalıdır; benzer bir pazaryerinin uygulaması doğrudan kural kabul edilmemelidir.
Analist, süreç uzmanlarıyla örnek kayıtları inceler ve duruma göre davranışı gösteren bir karar tablosu hazırlar. Karar tablosu, koşullar ile uygulanacak işlemleri birlikte gösterir. Hazırlanmamış ürün, sevk edilmiş ürün ve kısmi iptal için hangi işlemin mümkün olduğu açıkça yazılır. İptal ile iadenin başlangıç koşulları da ayrılır.
Sonra başarısızlık senaryoları ele alınır. Sipariş iptali kaydedilmiş, ancak ödeme geri dönüşü henüz tamamlanmamışsa kullanıcıya hangi durum gösterilecektir? Aynı istek tekrar gelirse işlem yeniden mi yapılacaktır? Stok kaydı güncellenemezse hangi ekip müdahale edecektir? Bu sorular, alan bilgisinin teknik gereksinimlerle birleştiği noktalardır.
Çözüm yalnızca düğmeden oluşmaz. Yetki, işlem durumu, para hesabı, stok davranışı, kullanıcı bilgilendirmesi ve istisna yönetimi birlikte tanımlanır. Başlangıçta kapsam küçük görünse de gerçek iş davranışı anlaşılınca gerekli çalışma ortaya çıkar. Bu açıklık, yatırım kararının daha erken ve daha doğru verilmesine yardımcı olur.
Yaygın üç hata
- Terimleri öğrenip ilişkileri öğrenmemek. “Komisyon”, “sipariş” ve “iade” kelimelerini bilmek, bunların hangi olayla oluştuğunu açıklamaya yetmez. Kavramların birbirini nasıl etkilediği ve hangi koşullarda farklı davrandığı araştırılmalıdır. Bir sözlük, süreç ve iş kurallarıyla birlikte anlam kazanır.
- Önceki şirketin kuralını yeni şirkete taşımak. Aynı sektördeki işletmelerin gelir modelleri, sözleşmeleri ve operasyonları farklı olabilir. Önceki deneyim iyi sorular üretmelidir; doğrulanmamış cevaplar değil. Özellikle para, yetki ve işlem durumlarıyla ilgili varsayımlar açıkça kaydedilmelidir.
- Yalnızca normal akışı incelemek. Sorunsuz tamamlanan işlem, sistemin sınırlarını göstermez. Kısmi işlem, gecikme, tekrar gönderilen talep ve sistemler arası uyuşmazlıklar da incelenmelidir. İstisnaları anlamadan hazırlanan gereksinimler, gerçek kullanım başladığında manuel müdahale ihtiyacını artırabilir.
Mini uygulama: Bir işlemin alan haritası
Bir sonraki analizde ekran seçmek yerine işletmede anlamlı bir işlem seçin. Sipariş iptali, abonelik yenileme veya teklif kabulü olabilir. Aşağıdaki sorularla işlem için kısa bir alan haritası hazırlayın.
- İş amacı
- Bu işlem kimin hangi ihtiyacını karşılıyor?
- Başlangıç olayı
- İşlemi hangi olay başlatıyor?
- Temel kavramlar
- Hangi kayıtlar ve durumlar kullanılıyor?
- Para akışı
- Hangi tutar, hangi aşamada, kime ait?
- Karar yetkisi
- Koşulları ve istisnaları kim onaylıyor?
- Bağımlılıklar
- Başka hangi süreç veya sistem etkileniyor?
- Tamamlanma koşulu
- İşletme açısından ne zaman bitmiş sayılıyor?
- İstisnalar
- Hangi durumda farklı davranış gerekiyor?
- Kanıt
- Kural hangi belge veya örnek kayıtla doğrulandı?
- Belirsizlik
- Hangi soru henüz cevaplanmadı, kim cevaplayacak?
Haritayı ilgili uzmanla gözden geçirin, ardından gerçek bir işlemi baştan sona izleyin. Belgedeki anlatımla uygulamadaki davranış farklıysa farkı kaydedin. Alan haritasının değeri ayrıntı sayısında değil, gereksinim kararını değiştirecek eksikleri görünür kılmasındadır.
İlgili terimler
Business Rule, Business Requirement, Requirements Elicitation, Stakeholder Analysis, As-Is Process, Process Mapping ve BPMN, Data Mapping ve Data Dictionary, Use Case, Functional Requirement, API Specification / API Contract