30 saniyelik özet
Requirements Elicitation, yani gereksinim ortaya çıkarma, paydaşların ifadelerinden, davranışlarından, süreç kayıtlarından ve iş kurallarından hareketle gerçek ihtiyacı araştırmaktır. Görüşme notlarını özellik listesine dönüştürmek bu çalışmanın tamamı değildir. Analist; ihtiyacın bağlamını, arkasındaki problemi, çelişkileri ve doğrulanması gereken varsayımları belirler. Sonuç, yalnızca istekler listesi değil; kaynağı bilinen, sınırları açıklanmış ve üzerinde karar verilebilecek gereksinim adaylarıdır.
Neden önemli?
Bir müşteri “toplu işlem istiyorum” dediğinde aynı cümle farklı ihtiyaçları anlatabilir. Kullanıcı çok sayıda kaydı düzenlemek, dosyadan veri aktarmak veya benzer kararları birlikte onaylamak istiyor olabilir. Bunları aynı özellik gibi değerlendirmek, doğru görünen bir çözümün gerçek işte yetersiz kalmasına yol açar.
Gereksinimler her zaman hazır biçimde ifade edilmez. İşi yapan kişi bazı kontrolleri alışkanlıkla uyguladığı için anlatmayabilir. Yönetici, prosedürde yazan akışı tarif ederken çalışan farklı bir yöntem kullanıyor olabilir. Müşteri ise yaşadığı sorunu açıklamak yerine başka bir üründe gördüğü çözümü talep edebilir.
İş analistinin katkısı, bu ifadeleri küçümsemeden araştırılabilir sorulara çevirmektir. Kullanıcının önerisi değerlidir; fakat önerinin hangi ihtiyacı karşıladığı anlaşılmadan kapsam kararı verilmemelidir. Bu yaklaşım, junior analistin toplantı notu tutma rolünden karar hazırlama rolüne geçmesini sağlar.
Yönetici açısından gereksinim ortaya çıkarma, yatırımın belirsizliğini azaltır. Yanlış ihtiyaç üzerine geliştirilen bir özellik, teslimat planına uygun tamamlanabilir. Buna rağmen kullanılmayabilir veya operasyonun başka bir bölümünde ek iş yaratabilir. Erken araştırmanın değeri, daha fazla belge üretmesinden çok yanlış kapsamı ve eksik varsayımları görünür kılmasındadır.
Terim nedir?
Elicitation sözcüğü, bilginin ortaya çıkarılmasını anlatır. Türkçede “gereksinim toplama” ifadesi de kullanılır; ancak bu ifade gereksinimlerin paydaşların elinde tamamlanmış belgeler olarak beklediği izlenimini verebilir. Uygulamada ihtiyaçlar çoğu zaman parçalıdır, birbirleriyle çelişir ve süreç incelendikçe netleşir.
Görüşme, gözlem, belge inceleme, veri analizi, çalıştay ve prototip değerlendirmesi kullanılabilecek yöntemlerdir. Çalıştay, ilgili kişilerin belirli bir problemi birlikte ele aldığı yapılandırılmış oturumdur. Prototip ise çözümün tamamını geliştirmeden belirli davranışlarını göstermek veya sınamak için hazırlanan temsildir. Yöntem seçimi, cevaplanacak soruya bağlıdır.
Kullanıcının neden bir işlem yaptığını anlamak için görüşme yararlı olabilir. İşin fiilen nasıl yürüdüğünü görmek için gözlem gerekir. Bir problemin ne kadar yaygın olduğunu değerlendirmek için işlem verileri incelenebilir. Tek bir yöntem bütün soruları cevaplamaz; farklı kaynaklar birbirini tamamlar ve aralarındaki uyuşmazlıklar yeni araştırma soruları üretir.
Analist, duyduğu ifadeyi hemen doğrulanmış gereksinim kabul etmemelidir. “Her kullanıcı sipariş onaylayabilir” cümlesi mevcut davranış, yeni bir talep veya yanlış anlaşılmış bir yetki kuralı olabilir. Önce ifadenin hangi tür bilgi olduğu, kaynağı ve geçerli olduğu koşullar açıklanmalıdır.
Ortaya çıkarma çalışması analiz ve doğrulamayla birlikte ilerler. Bulgular gruplanır, çelişkiler araştırılır, gereksinim adayları yazılır ve ilgili kişilerle kontrol edilir. Bir görüşmenin sonunda bütün soruların kapanması gerekmez. Hangi bilginin eksik olduğunun ve nasıl doğrulanacağının açık olması da değerli bir sonuçtur.
Gerçek vaka: CarMax’te görüşmeden karara geçmek
Product Talk’ta yayımlanan CarMax vakası, ürün yöneticisi, tasarımcı ve teknik liderle yapılan bir görüşmeye dayanıyor. Ekip, müşteri araştırması ve ürün keşfi yapmasına rağmen görüşmelerden çıkan bilgileri bir araya getirmekte zorlandığını anlatıyor. Çok sayıda not oluşması, açık bir çıkarıma ulaşılmasını kendiliğinden sağlamıyormuş.
Teresa Torres ile yürütülen çalışma sırasında ekip, müşteri ihtiyaçlarını ve olası çözümleri hedeflenen sonuçlarla daha düzenli ilişkilendirmiş. Görüşmeler yalnızca hazırlanmış bir çözümü değerlendirmek için yapılmak yerine daha sürekli bir öğrenme pratiğine dönüşmüş. Ekip ayrıca deneyleri, birçok varsayımı birlikte sınayan büyük çalışmalar yerine belirli varsayımları araştıracak şekilde tasarladığını aktarıyor.
Gereksinim ortaya çıkarma açısından çıkarılabilecek ders, bilgi toplamanın tek başına yeterli olmadığıdır: Bulguların karar verebilecek bir yapıya dönüştürülmesi gerekir. Kaynak, ekip üyelerinin değerlendirmelerini sunuyor; bu değişimin finansal etkisini bağımsız bir ölçümle kanıtlamıyor.
Varsayımsal örnek: Toplu sipariş düzenleme talebi
İşletmelere abonelikle sipariş yönetimi yazılımı sunan bir şirkette müşteri temsilcilerinin “Excel yükleyerek toplu işlem yapalım” talebini ilettiğini düşünelim. Ekip doğrudan dosya yükleme ekranını tasarlamak yerine talebin arkasındaki işi araştırıyor.
Analist, kullanıcıdan son yaptığı toplu düzenlemeyi anlatmasını ve mümkünse mevcut araç üzerinde göstermesini ister. Dosyanın nereden geldiğini, hangi alanları değiştirdiğini, hangi kayıtları dışarıda bıraktığını ve işlem sonunda neyi kontrol ettiğini sorar. Gelecekteki tercihler hakkında konuşmak yerine geçmişte yaşanmış olayın ayrıntıları izlenir.
Gözlem sırasında kullanıcının siparişleri önce teslimat durumuna göre ayırdığı ortaya çıkabilir. Sevk edilmiş siparişlerde adres değişikliğinin farklı bir süreçten geçmesi gerekebilir. Kullanıcı bu kontrolü kendi çalışma dosyasında yaptığı için ilk talepte belirtmemiş olabilir. Dosya yükleme ihtiyacının altında işlem uygunluğunu değerlendiren bir iş kuralı bulunmaktadır.
Analist bu bulguyu operasyon ekibiyle doğrular. Ardından destek kayıtlarında toplu düzenlemeyle ilgili sorunları inceler ve işlem verilerinden hangi değişikliklerin tekrarlandığını araştırır. Destek kaydı şikâyetin niteliğini, işlem verisi kullanım örüntüsünü gösterebilir. Kaynaklardan birinin tek başına bütün kullanıcıları temsil ettiği varsayılmaz.
Yeni sorular ortaya çıkar: Hatalı satırlar bulunduğunda uygun kayıtlar işlenebilir mi? Kullanıcı işlemden önce değişecek alanları görebilmeli mi? Aynı dosyanın yeniden yüklenmesi neye yol açmalı? Tamamlanan işlemin kim tarafından yapıldığı nasıl izlenmeli? Gereksinim adayları bu soruların cevaplarıyla şekillenir.
Ortaya çıkan çalışma yalnızca “dosya yükleme” değildir. İşlem yetkisi, uygunluk kontrolü, değişiklik önizlemesi, hata bildirimi ve işlem kaydı gibi ihtiyaçlar tanımlanabilir. Hangilerinin kapsamda olacağı, iş hedefi ve risklerle birlikte kararlaştırılır. Araştırmada görülen her davranış otomatik olarak yeni özellik yapılmaz.
Yaygın üç hata
- Kullanıcıya çözümü onaylatan sorular sormak. “Toplu yükleme ekranı işinizi kolaylaştırır mı?” sorusu önerilen çözümü merkeze alır. “Son toplu düzenlemede nasıl ilerlediniz, nerede zorlandınız?” sorusu ise gerçek davranışı araştırır. Çözüm değerlendirmesi yapılabilir; ancak ihtiyaç araştırmasının yerine geçmemelidir.
- Söylenenle yapılanı aynı kabul etmek. Bir paydaşın anlatımı önemli bir bilgi kaynağıdır; süreç gözlemi ve kayıtlarla birlikte değerlendirilmelidir. Fark bulunduğunda kişiyi hatalı anlatmakla suçlamak yerine bağlam araştırılır. İstisnai işlemler, farklı roller veya güncelliğini kaybetmiş prosedürler farkı açıklayabilir.
- Görüşme notunu gereksinim sanmak. Not, söylenen ifadenin kaydıdır. Gereksinim adayı ise ihtiyaç, koşul ve beklenen davranış açısından düzenlenmiş bilgidir. Notu doğrudan geliştirme planına taşımak; yetki, istisna ve çelişkileri atlamaya yol açabilir. Kaynak ile yorum birbirinden ayırt edilebilmelidir.
Mini uygulama: Talebi gereksinim adayına dönüştürmek
Bir sonraki müşteri talebinde aşağıdaki kartı kullanın. İlk görüşmede cevaplanamayan alanları açık bırakın ve nasıl araştırılacaklarını yazın.
- İlk ifade
- Paydaş tam olarak ne istedi?
- Bağlam
- Hangi işi, hangi koşulda yapıyor?
- Somut olay
- En son ne zaman benzer durum yaşandı?
- Mevcut yöntem
- İşi bugün nasıl tamamlıyor?
- Engel ve etki
- Nerede zorlanıyor, hangi sonuç etkileniyor?
- Kaynak
- Görüşme, gözlem, belge veya hangi kayıt?
- İş kuralı
- Hangi koşul davranışı değiştiriyor?
- Gereksinim adayı
- Hangi ihtiyacın karşılanması gerekiyor?
- Belirsizlik
- Hangi bilgi henüz doğrulanmadı?
- Sonraki adım
- Kiminle, hangi yöntemle kontrol edilecek?
Kartı doldurduktan sonra ilk taleple gereksinim adayını karşılaştırın. İkisi aynı olabilir; ancak bu sonuca hangi kanıtla ulaştığınız anlaşılmalıdır. Aynı ihtiyacın farklı çözümlerle karşılanıp karşılanamayacağını da değerlendirin. Çalışmanın başarısı, görüşme sayısıyla değil, kapsam kararının dayanağının ve kalan belirsizliğin açıklığıyla değerlendirilmelidir.
İlgili terimler
Problem Statement, Business Objective, Stakeholder Analysis, Domain Knowledge, Customer Interview, Customer Discovery, As-Is Process, Business Requirement, Business Rule, Functional Requirement, Prototype, Acceptance Criteria