Aydınlatma metni yükleniyor…
Müşteri görüşmeleri, dijital ürün projelerinin en değerli bilgi kaynaklarından biridir. Ancak toplantıda duyulan her talebi doğrudan özellik listesine eklemek doğru değildir. “Mobil uygulama olsun”, “ERP ile konuşsun” veya “onay mekanizması ekleyelim” gibi ifadeler çözüm önerir; kullanıcının hangi sorunu, hangi koşulda ve neden yaşadığını tek başına açıklamaz.
Sağlam bir ürün kapsamı çıkarmak için görüşme notlarının problem, kullanıcı, bağlam, mevcut süreç, iş kuralı, veri, istisna ve beklenen sonuç katmanlarına ayrılması gerekir. Ardından bu bulgular ölçülebilir kabul kriterleri ve gerekçeli önceliklerle doğrulanmalıdır. Böylece ürün yöneticileri, iş birimleri, operasyon, BT, tasarım, yazılım ve test ekipleri aynı kapsam üzerinde çalışabilir.
Görüşmeye özellik listesiyle değil araştırma hedefiyle başlayın
Görüşmenin amacı müşterinin aklına gelen bütün özellikleri toplamak değil, karar vermek için gereken belirsizlikleri azaltmaktır. Önce ürünün destekleyeceği iş sonucunu tanımlayın: Sipariş süresi mi kısalacak, manuel veri girişi mi azalacak, bayi talepleri mi izlenecek, yoksa saha ekibi çevrimdışıyken işlem yapabilecek mi?
Her görüşme turu için birkaç araştırma sorusu belirleyin. “Sipariş bugün nasıl açılıyor?”, “Hangi durumda yönetici onayı gerekiyor?”, “Hata oluştuğunda kim fark ediyor?” ve “Kullanıcı görevin tamamlandığını nasıl anlıyor?” gibi sorular süreci görünür kılar. GOV.UK’nin derinlemesine görüşme rehberi de açık ve tarafsız sorularla gerçek örneklere odaklanmayı, genellemelerin peşinden ayrıntı soruları sormayı önerir.
Katılımcı seçimi de kapsamı etkiler. Yalnızca yöneticilerle konuşmak politika ve hedefleri; yalnızca son kullanıcılarla konuşmak günlük güçlükleri gösterir. B2B e-ticaret veya müşteri portalı projesinde bayi, satış temsilcisi, operasyon uzmanı, finans, depo, müşteri hizmetleri ve sistem yöneticisi gibi farklı roller temsil edilmelidir. Aynı süreçte farklı yetki ve sorumluluklara sahip kişilerin anlatımları karşılaştırılmalıdır.
Görüşmede talebin arkasındaki gerçek ihtiyacı bulun
Katılımcının önerdiği çözümü reddetmeyin; fakat çözümün arkasına ilerleyin. “Excel yükleme istiyoruz” diyen kullanıcıya bugün kaç satır girdiğini, veriyi nereden aldığını, hangi hataların oluştuğunu ve hatalı satırla karşılaşınca ne yaptığını sorun. Böylece talep, “Excel yükleme özelliği” olmaktan çıkar ve “bayinin yüksek hacimli siparişi tekrar veri girmeden, hatalı satırları düzelterek tamamlaması” ihtiyacına dönüşür.
Geçmişte yaşanmış somut bir olayı anlattırın
“İdeal sistem nasıl olmalı?” sorusu varsayımsal cevap üretir. Bunun yerine katılımcıdan son siparişi, son iadeyi veya son onay sorununu adım adım anlatmasını isteyin. Kullandığı ekranları, e-postaları, formları ve geçici Excel dosyalarını mümkünse gözlemleyin. Söylenen süreç ile uygulanan süreç arasındaki farklar çoğu zaman kritik gereksinimleri ortaya çıkarır.
Bağlamı, tetikleyiciyi ve beklenen sonucu kaydedin
Her önemli bulgu için şu soruların yanıtını arayın: İşlemi kim başlatıyor, ne tetikliyor, hangi bilgi hazır bulunuyor, hangi karar veriliyor, kimden onay alınıyor ve başarı nasıl anlaşılıyor? Örneğin “müşteri siparişi iptal edebilmeli” ifadesi; yalnızca sevkiyat başlamadıysa, belirli roldeki kullanıcı tarafından, iptal nedeni seçilerek ve ERP’ye bildirim gönderilerek yapılabilecek bir işlem olabilir.
İstisnaları özellikle sorun
Ana akış genellikle kolay anlatılır; yazılım kapsamını büyüten ayrıntılar istisnalarda saklıdır. Stok yetersizse, fiyat bulunamazsa, onaylayan kişi izindeyse, ERP yanıt vermiyorsa veya aynı kayıt iki kez gönderilirse ne olacağını sorun. Bu yanıtlar hata mesajlarını, vekâlet kurallarını, tekrar deneme davranışını ve manuel müdahale sorumluluğunu belirler.
Görüşme notlarını gereksinime dönüştüren altı adım
Ham not ile geliştirmeye hazır gereksinim arasında izlenebilir bir dönüşüm zinciri kurulmalıdır. Bu zincir, yorumların erken aşamada kesin özelliklere dönüşmesini engeller ve her kararın hangi kanıta dayandığını gösterir.
1. Gözlem ile yorumu ayırın
“Katılımcı fiyatı görmek için iki ekran ve bir Excel dosyası kullandı” bir gözlemdir. “Kullanıcı sade panel istiyor” ise yorumdur. Notları tek bir davranış, ifade veya olay içerecek şekilde parçalayın; katılımcı rolü ve görüşme koduyla etiketleyin. Kişisel verileri gereksiz yere kaydetmeyin ve kayıt için açık onay alın.
2. Bulguları problem ve süreç temalarında gruplayın
Benzer notları sipariş, fiyat, yetki, belge, bildirim veya entegrasyon gibi temalarda birleştirin. Bir bulgunun kaç görüşmede tekrarlandığını kaydedin; ancak sıklığı tek karar ölçütü yapmayın. Seyrek görülen bir güvenlik veya finans istisnası, sık yaşanan küçük bir kullanılabilirlik sorunundan daha kritik olabilir. GOV.UK’nin araştırma oturumu analiz yaklaşımı, gözlemlerin ekipçe ayrıştırılıp benzer temalarda kümelenmesini ve bulguların kanıttan türetilmesini önerir.
3. Kullanıcı ihtiyacını çözümden bağımsız yazın
İhtiyacı “Kim, hangi bağlamda, neyi, neden yapabilmeli?” yapısıyla ifade edin. Örneğin: “Bayi operasyon sorumlusu, yoğun sipariş döneminde yüzlerce ürün satırını yeniden yazmadan sisteme aktarabilmeli; böylece giriş süresi ve kodlama hataları azalmalı.” Bu tanım henüz Excel, API veya başka bir arayüzü zorunlu kılmaz; tasarım alternatiflerine alan bırakır.
4. İş kurallarını ve veriyi açığa çıkarın
Gereksinim kartına rol ve yetkiyi, zorunlu alanları, hesaplama kurallarını, durum geçişlerini ve istisnaları ekleyin. Verinin kaynağını, sahibini, güncellenme sıklığını ve hedef sistemini belirtin. ERP, CRM, ödeme veya lojistik sistemi bağlantılarında yalnızca “entegrasyon yapılacak” demek yeterli değildir. Alan eşleştirme, benzersiz kayıt anahtarı, hata davranışı, tekrar deneme ve mutabakat gereksinimleri tanımlanmalıdır. Ayrıntılı kapsam için web yazılım entegrasyonları planlama rehberi kullanılabilir.
5. Kabul kriterlerini ölçülebilir hâle getirin
Kabul kriteri, gereksinimin doğru uygulanıp uygulanmadığını gözlenebilir biçimde açıklar. “Sistem hızlı olmalı” yerine “Yetkili kullanıcı, geçerli 500 satırlık dosyanın ön kontrol sonucunu belirlenen performans hedefi içinde görebilmeli” gibi doğrulanabilir bir ifade yazın. Başarılı akışın yanında yetkisiz erişim, eksik veri, mükerrer gönderim ve entegrasyon kesintisi gibi olumsuz senaryoları da kapsayın.
6. Gereksinimi kullanıcı ve teknik ekiple doğrulayın
Hazırlanan kartları katılımcılara geri okuyun: Problem doğru mu, kural eksik mi, istisna gerçek mi, kabul ölçütü iş sonucunu gösteriyor mu? Ardından tasarım, yazılım ve test ekipleriyle uygulanabilirlik kontrolü yapın. ISO/IEC/IEEE 29148 standardı gereksinim mühendisliğini keşfetme, analiz etme, doğrulama, iletişim, dokümantasyon ve yaşam döngüsü boyunca yönetme faaliyetleriyle ele alır; standardın kapsamı IEEE gereksinim mühendisliği sayfasında açıklanır.
Her gereksinim kartında hangi alanlar bulunmalı?
Tek tip gereksinim kartı, görüşme bulgusunu tasarım ve teste bağlar. Kartın ayrıntı düzeyi projenin riskine göre değişebilir; ancak aşağıdaki alanlar web yazılımı, mobil uygulama, B2B e-ticaret ve portal projelerinin çoğunda ortak bir dil sağlar.
Kaynak ve kanıt: Görüşme kodu, gözlenen olay, destek kaydı veya süreç belgesi.
Kullanıcı ve bağlam: Rol, yetki, cihaz, kanal ve işlemi başlatan koşul.
Problem ve amaç: Bugünkü engel ile ulaşılmak istenen iş veya kullanıcı sonucu.
İş kuralı: Koşullar, limitler, hesaplamalar, onaylar ve durum geçişleri.
Veri ve entegrasyon: Girdi, çıktı, kaynak sistem, veri sahibi, hata ve mutabakat davranışı.
İstisnalar: Eksik veri, yetkisizlik, bağlantı kesintisi, mükerrer işlem ve geri alma senaryoları.
Kabul kriterleri: İşlevsel, ölçülebilir ve test edilebilir başarı koşulları.
Öncelik ve bağımlılık: İş değeri, risk, öğrenme ihtiyacı, teknik bağımlılık ve sürüm kararı.
Bu kartlar daha geniş proje özeti ve izlenebilirlik tablosuyla birlikte kullanılabilir. Uygulanabilir bir yapı kurmak için web yazılım ihtiyaç dokümanı şablonu, bulguların tek bir kapsam altında toplanmasına yardımcı olur.
| Katman | Yanıtlanan soru | Beklenen çıktı |
|---|---|---|
| Kullanıcı ihtiyacı | Kim, neyi, neden yapıyor? | Rol, bağlam ve amaç |
| İş kuralı | Hangi koşul ve sınırlar geçerli? | Yetki, limit ve istisna |
| Veri ve entegrasyon | Bilgi nereden gelip nereye gider? | Kaynak, eşleme ve hata davranışı |
| Kabul kriteri | Tamamlandığı nasıl kanıtlanır? | Ölçülebilir test senaryosu |
Gereksinimleri nasıl önceliklendirmelisiniz?
Bir talebin çok istenmesi, ilk sürüme alınması için tek başına yeterli değildir. Önceliklendirmede kullanıcı etkisi, iş hedefi, risk, yasal veya operasyonel zorunluluk, veri hazırlığı ve teknik bağımlılıklar birlikte değerlendirilmelidir. “Olmazsa süreç çalışmaz” ile “kullanımı iyileştirir” arasındaki fark açıkça yazılmalıdır.
Her gereksinim için hangi kullanıcı grubunu etkilediğini, problemin ne sıklıkta yaşandığını, etkisinin büyüklüğünü ve mevcut geçici çözümün maliyetini kaydedin. Entegrasyon altyapısı, kimlik doğrulama veya temel veri modeli gibi görünmeyen gereksinimler de kullanıcı özelliklerinin ön koşulu olabilir. İlk sürüm ile sonraki fazları ayırırken MVP kapsamı karar tablosundan yararlanılabilir.
Öncelik kararının sahibi ve tarihi bulunmalıdır. “Yüksek” etiketi tek başına yeterli değildir; gerekçesi, bağımlılığı ve hangi yeni kanıtla değişebileceği yazılmalıdır. Böylece kapsam görüş ayrılığına göre değil, görünür ölçütlere göre yönetilir.
Sık yapılan gereksinim çıkarma hataları
Talebi doğrudan özelliğe çevirmek: Sorun doğrulanmadan belirli bir ekran veya teknolojiye bağlanmak yanlış çözümü hızla üretir.
Yalnızca karar vericilerle görüşmek: Yönetim hedefleri öğrenilir; günlük süreç, istisna ve geçici çözümler görünmez kalır.
Geleceğe yönelik genel sorular sormak: Katılımcı gerçek davranış yerine ideal veya sosyal açıdan kabul gören cevabı verebilir.
Notları kanıtsız birleştirmek: Farklı rollerin çelişen ihtiyaçları tek ve yanıltıcı bir talep gibi görünebilir.
Entegrasyonu tek satırla tanımlamak: Veri sahipliği, hata, güvenlik ve işletim sorumlulukları geliştirme sırasında belirsiz kalır.
Kabul kriterini sona bırakmak: Tasarım, geliştirme ve test ekipleri “tamamlandı” kavramını farklı yorumlar.
Görüşme çıktısından ortak ürün kapsamına
İyi gereksinim çalışması, uzun bir özellik listesi üretmekten çok belirsizliği azaltır. Her gereksinim kullanıcıya, probleme ve kanıta bağlanır; iş kuralları, veri akışları, entegrasyonlar, istisnalar ve kabul ölçütleri görünür hâle gelir. Sonuçta teklif, tasarım, yazılım, test ve işletim ekiplerinin farklı varsayımlarla ilerleme riski azalır.
Kumsal Ajans; kullanıcı deneyimi ve dijital ürün planlamasını iş süreçleri, kullanıcı rolleri, veri ve entegrasyon gereksinimleriyle birlikte ele alır. Projeye özel web yazılım çözümleri, React Native ile hibrit mobil uygulamalar, B2B e-ticaret ve müşteri ya da bayi portalları için doğrulanabilir bir kapsam oluşturur.
Müşteri görüşmelerinden doğrulanabilir ürün gereksinimleri çıkarmak ve projenizin kapsamını birlikte planlamak için Kumsal Ajans ile iletişime geçin.