Problem Keşfi — Problem Discovery

30 sn özet

Problem keşfi, kullanıcının ulaşmak istediği sonucu, önündeki engelleri ve bugün bu engellerle nasıl başa çıktığını araştırmaktır. Müşterinin istediği özellik önemli bir başlangıç bilgisidir; talebin arkasındaki ihtiyacı anlamak için kullanım bağlamı da incelenmelidir. Görüşmeler, çalışma ortamındaki gözlemler ve davranış verileri birlikte değerlendirilir. Amaç, geliştirme başlamadan önce hangi problemin kim için çözülmeye değer olduğunu açıklayabilmektir. İyi bir keşfin çıktısı; açık bir problem tanımı, onu destekleyen kanıtlar ve hâlâ yanıtlanması gereken sorulardır.

Neden önemli?

Bir müşteri “Daha ayrıntılı rapor istiyorum” dediğinde ekip rapor ekranını geliştirmeye başlayabilir. Ancak müşterinin asıl amacı, yöneticisine geciken işleri açıklamak veya hangi siparişe önce müdahale edeceğini belirlemek olabilir. Bu ihtiyaçlar farklı çözümler gerektirir. Talebin doğru uygulanması, temel ihtiyacın karşılandığı anlamına gelmez.

Problem keşfi, yatırımın gerekçesini güçlendirir. Geliştirme süresi, destek kapasitesi ve bütçe sınırlıdır. Bu kaynakların hangi soruna ayrılacağına karar verirken problemin kimleri etkilediği, hangi koşullarda yaşandığı ve çözülmemesinin sonuçları bilinmelidir. Seyrek yaşanan bir sorun ağır bir kayba yol açabilir; sık yaşanan başka bir sorun kullanıcı tarafından kolayca aşılabilir.

Yönetici açısından keşfin değeri, belirsizliği karar verilebilir hâle getirmesidir. Ekip araştırma sonunda problemin düşünüldüğünden farklı olduğunu öğrenebilir. Bu bulgu, pahalı bir geliştirmeye başlamadan yön değiştirme olanağı sağlar. Araştırmanın başarısını yalnızca yapılan görüşme sayısıyla değerlendirmek bu katkıyı gözden kaçırır.

Junior bir iş analisti veya ürün sahibi için keşif, gereksinimlerin dayanağını anlamayı sağlar. Bir talebin hangi kullanıcı davranışına ve iş sonucuna bağlı olduğunu bilen kişi, alternatifleri daha iyi tartışabilir. Gereksinim belgesinde açıkça yazılmamış bir süreç bağımlılığını veya bilgi eksikliğini fark etmesi de kolaylaşır.

Terim nedir?

Problem keşfi; belirli bir kullanıcı grubunun, belirli bir işi yaparken yaşadığı güçlüğü anlamaya yönelik araştırmadır. Kullanıcının amacı, işin başladığı koşullar, izlediği adımlar, karşılaştığı engel ve oluşan sonuç birlikte incelenir.

Örneğin “Kullanıcılar ekranı beğenmiyor” ifadesi karar vermek için fazla geniştir. “Depo sorumluları, teslimatı geciken siparişlerin etkisini karşılaştıramadığı için müdahale sırasını farklı dosyalardan bilgi toplayarak belirliyor” ifadesi daha araştırılabilir bir problem tanımlar. Kullanıcıyı, görevi, engeli ve mevcut davranışı ilişkilendirir. Yine de böyle bir ifade, araştırmayla desteklenene kadar bir kabul olarak ele alınmalıdır.

Keşifte gözlem ile yorum ayrılmalıdır. Kullanıcının aynı bilgiyi iki dosyaya yazması bir gözlemdir. Bunu sistemin güvenilmez olduğu için yaptığı düşüncesi ise yorumdur. Kullanıcı bu davranışı yönetim raporlaması, iş arkadaşının talebi veya alışkanlık nedeniyle sürdürüyor olabilir. Nedeni sormadan çözüm seçmek, araştırmanın erken kapanmasına yol açar.

Görüşmelerde geçmişte yaşanmış somut olaylara odaklanmak yararlıdır. “Böyle bir özellik olsa kullanır mıydınız?” sorusu geleceğe ilişkin bir tahmin üretir. “Son gecikmede ne yaptınız, hangi bilgiyi nereden aldınız?” sorusu ise gerçekleşmiş davranışı anlamaya yardımcı olur. Kullanıcının kullandığı belgeyi veya yaptığı işlemi göstermesi anlatımı daha somut kılar.

Davranış verileri araştırmayı tamamlar. İşlemden vazgeçme, destek talebi veya tekrar eden hata belirli bir güçlüğe işaret edebilir. Fakat veriler nedenin tamamını açıklamayabilir. Görüşme, gözlem ve kayıtlar birlikte değerlendirildiğinde daha sağlam bir açıklama kurulabilir.

Problem keşfi bütün belirsizlikleri ortadan kaldırmaz. Araştırılan kullanıcıların özellikleri, ulaşılabilen veriler ve gözlem koşulları bulguların sınırlarını belirler. Ekip, hangi bilgiden emin olduğunu ve hangi sorunun açık kaldığını karar veren kişilerle paylaşmalıdır.

Gerçek vaka: Intuit’in Follow-Me-Home yöntemi

Intuit, “Building Deep Customer Empathy to Solve Any Problem” yazısında müşteri ihtiyaçlarını anlamak için kullandığı yaklaşımı anlatır. Design for Delight, yani müşteriyi memnun edecek ürünler geliştirmeye yönelik çalışma yaklaşımı içinde doğrudan müşteri gözlemine yer verir.

Follow-Me-Home yönteminde ekip, müşterinin problem yaşadığı ortama giderek davranışını inceler. Kaynak, bu çalışmanın yalnızca görüşmeye dönüşmemesini; kullanıcının gerçekten ne yaptığının görülmesini vurgular. Gözlem sonrasında ekip, fark ettiği güçlükleri ve beklenmedik bulguları birlikte değerlendirir.

Intuit ayrıca çözüm geliştirmeden önce müşteri probleminin ekipçe açık biçimde tanımlanmasını önerir. Bu tanım, araştırmadan öğrenilenlerle güncellenebilir. Böylece müşterinin söylediği talep, gözlenen davranış ve ekibin çözmek istediği problem arasında bağlantı kurulur.

Kaynakta QuickBooks Online’ın fatura gönderme deneyimi üzerinden verilen anlatım, yöntemi açıklayan örnek bir senaryodur. Burada bunu sonuçları ölçülmüş ayrı bir proje olarak sunmuyoruz. Doğrulanabilen kurumsal uygulama, Intuit’in müşteri gözlemini ve problem tanımını çalışma yaklaşımına yerleştirmiş olmasıdır.

Bu uygulamadan çıkarılabilecek ders, problem hakkındaki yorumları doğrudan kullanım deneyimiyle sınamaktır. Kullanıcının yaptığı işi görmek, başlangıçtaki talebin nedenini yeniden değerlendirmeye yardımcı olabilir.

Kaynak: Intuit Blog, “Building Deep Customer Empathy to Solve Any Problem”, güncelleme tarihi 13 Mart 2025.

Varsayımsal örnek: Daha büyük rapor ekranı talebi

Stok yönetimi yazılımı kullanan bir işletmenin depo sorumluları daha ayrıntılı bir rapor ekranı istiyor olsun. Ürün ekibi önce son yaşanan tedarik gecikmesini araştırır. Kullanıcıdan o gün izlediği adımları ve karar verirken kullandığı bilgileri göstermesini ister.

Gözlemde sorumlunun tedarikçileri telefonla aradığı, sipariş bilgilerini dosyalardan topladığı ve müşteri teslimatlarına etkisini elle karşılaştırdığı görülsün. İlk problem tanımı şöyle kurulabilir: “Depo sorumlusu, geciken tedariklerin hangi müşteri teslimatını daha fazla etkilediğini mevcut bilgilerle kolayca belirleyemiyor.”

Ekip bu açıklamayı hemen kesinleştirmez. Başka kullanıcıları ve farklı çalışma koşullarını inceler. Sorunun bilgiye erişimden mi, kayıtların güncelliğinden mi, yoksa karar ölçütünün belirsizliğinden mi kaynaklandığını araştırır. Her neden farklı bir müdahale gerektirebilir.

Bulgular karar sırasını belirlemekte zorlanıldığını desteklerse, riskli siparişleri karşılaştıran bir çalışma listesi çözüm adayı olabilir. Bu aday henüz doğrulanmış çözüm değildir. Kullanıcının gerçek bir durumda doğru müdahaleyi seçmesine yardımcı olup olmadığı ayrıca sınanır.

Problemin önemini değerlendirmek için bilgi toplama süresi, müdahalenin gecikmesi ve teslimat üzerindeki etkiler incelenebilir. Önce mevcut durum ölçülür. Bu varsayımsal örnekte herhangi bir iyileşme oranı veya ticari sonuç kabul edilmez.

Yaygın 3 hata

Görüşmeyi çözüm onaylatmaya çevirmek

Özelliği anlattıktan sonra beğenilip beğenilmediğini sormak, temel ihtiyacı anlamayı zorlaştırabilir. Önce son yaşanan olayı, kullanılan alternatifleri ve karşılaşılan engelleri araştırın.

Tek müşterinin deneyimini bütün pazara genellemek

Önemli bir müşterinin talebi ticari açıdan etkili olabilir. Yine de diğer kullanıcıların aynı problemi yaşadığı ayrıca araştırılmalıdır. Bulguların hangi müşteri grubuna ait olduğunu açıkça belirtin.

Gözlemi nedensellik kanıtı saymak

Bir kullanıcı işlemi yarıda bırakmış olabilir; bunun nedeni doğrudan ekran tasarımı olmayabilir. Kesintiyi, kullanım koşullarını ve diğer açıklamaları inceleyin. İlk yorumu doğrulamaya çalışırken tersini gösteren kanıtları da değerlendirin.

Mini uygulama/şablon

Araştırmadan önce şu alanları yazın:

Karar: Araştırma hangi yatırım kararını aydınlatacak?
Kullanıcı grubu: Kimin hangi çalışma koşulunu inceleyeceğiz?
Başlangıç kabulü: Hangi problemin önemli olduğunu düşünüyoruz?
Olay sorusu: Kullanıcıdan hangi son deneyimini anlatmasını isteyeceğiz?
Gözlem odağı: Hangi adımları, belgeleri ve geçici çözümleri inceleyeceğiz?

Araştırmadan sonra şu alanları tamamlayın:

Gözlenen davranış: Kullanıcı gerçekten ne yaptı?
Olası açıklamalar: Bu davranışın farklı nedenleri neler olabilir?
Problem tanımı: Kim, hangi durumda, hangi engel nedeniyle neyi başaramıyor?
Kanıtın sınırı: Bulgular hangi kullanıcıları ve koşulları kapsıyor?
Sonraki adım: Hangi bilinmeyen araştırılmalı veya hangi çözüm adayı sınanmalı?

Bu kayıtları ekipçe inceleyin. Birbirinden farklı problemleri tek cümlede birleştirmek yerine ayrı değerlendirin. Karar için yeterli bilgi oluştuğunda araştırmadan öğrenilenleri yatırım önerisine bağlayın.

İlgili terimler

Problem Tanımı, Ürün Keşfi, Gereksinimlerin Ortaya Çıkarılması, Müşterinin Sesi, Kullanıcı Personası, Jobs to Be Done, Kök Neden Analizi, Mevcut Süreç, Varsayım Haritalama, Kullanılabilirlik Testi