Yazılım Ürün Keşfi: Discovery Çalışmasından Ne Çıkmalı?

Keşfin konusu çözüm değil, problem olsun

Bir işletme “müşteri portalı istiyorum” dediğinde henüz problem tarif edilmiş olmayabilir. Müşteriler sipariş durumunu öğrenemiyor, teklif revizyonu uzuyor veya destek ekibi aynı belgeyi tekrar gönderiyor olabilir. Bunlar farklı çözümler gerektirir. Görüşmenin ilk çıktısı, mevcut davranışı ve etkisini anlatan kısa bir problem cümlesi olmalıdır.

GOV.UK keşif rehberi; kullanıcıların kim olduğunu, bugün ne yaptığını ve nerede güçlük yaşadığını araştırmayı tasarımdan önce konumlandırır. Bu yaklaşım burada bir kamu hizmeti standardı olarak değil, araştırmanın sırasını açıklayan yöntem kaynağı olarak kullanılıyor. [1]

Birbirinden farklı üç kanıt toplayın

İlk kanıt operasyon gözlemidir: talep hangi kanaldan geliyor, kaç kişiye aktarılıyor ve nerede bekliyor? İkincisi kullanıcı anlatısıdır: kişi son yaşadığı örneği nasıl tarif ediyor? Üçüncüsü mevcut sistem kaydıdır: tekrar açılan işler veya eksik başvurular hangi aşamada birikiyor? Üçü çelişirse ortalamasını almak yerine çelişkinin nedenini araştırın.

Örneğin ekip “müşteriler form kullanmıyor” diyebilir. Kayıtlar formun kullanıldığını, fakat ek dosyanın kaybolması nedeniyle herkesin ayrıca e-posta gönderdiğini gösterebilir. Bu durumda yeni portal yaptırmak yerine dosya akışını düzeltmek öncelik kazanır. Keşif, başlangıç fikrini doğrulamak zorunda değildir.

Varsayımsal bir bayi portalı incelemesi

Bir üreticinin bayilerinden her gün teslim tarihi sorusu aldığını düşünün. İlk hipotez, bayilerin güncel bilgiyi görememesidir. Ancak depo tarihi düzenli güncellemiyorsa portal yalnızca eski bilgiyi daha güzel gösterir. Veri sahibini, güncelleme olayını ve müşteriye gösterilebilecek kesinlik düzeyini birlikte belirleyin.

Bu senaryoda prototipte “kesin teslim” yazmak yerine “planlanan sevk” ve “son güncelleme” alanları denenebilir. Bayinin hangi bilgiye dayanarak müşterisine söz verdiği gözlenir. Prototipteki tarihlerin temsili olduğu açıkça belirtilir; çalışan depo entegrasyonu varmış gibi davranılmaz.

Keşif dosyasını karar belgesine dönüştürün

Tablo örnek bir çalışma aracıdır; beş sorgu tüm kullanıcıları temsil eden istatistiksel örneklem değildir. Çalışma sonunda hangi varsayımın desteklendiğini, hangisinin açık kaldığını ve hangi önerinin değiştiğini yazın. Her açık konu için sorumlu ve sonraki doğrulama adımı belirleyin.

Teslimde slayt sayısını değil açıklığı ölçün

İyi bir keşif tesliminde problem özeti, gözlem notları, kritik akış, seçenekler ve önerilen ilk kapsam birbirine bağlanır. Görüşülen kişilerin isimlerini paylaşmak yerine gerekli anonim bağlamı tutun. Araştırmaya katılım ve kayıt izni ayrıca yönetilsin. Bulgu ile ekibin yorumunu aynı renkte veya aynı etiketle göstermeyin.

Bir de durdurma kararı tanımlayın: veri kaynağı yoksa, sorumlu ekip belli değilse veya kullanıcı ihtiyacı doğrulanmıyorsa geliştirmeye geçilmez. Keşif sonunda “şimdilik yapmayalım” demek başarısızlık değildir. Gereksiz bir projenin başlamaması da kararın değerli bir sonucu olabilir; bunu varsayımsal tasarruf rakamlarıyla süslemeye gerek yoktur.

Sık sorulan sorular

Discovery için çalışan prototip şart mı?

Hayır. Risk, kullanıcı ihtiyacındaysa görüşme ve gözlem daha yararlı olabilir. Risk etkileşimdeyse tıklanabilir bir prototip seçilebilir. Araç, cevaplanacak soruya göre belirlenmelidir.

Keşif teklifi nasıl karşılaştırılır?

Görüşme adedi kadar araştırılacak kararları, kapsam dışını ve teslim kanıtlarını karşılaştırın. Yalnızca “analiz dokümanı” yazan bir kalemin hangi belirsizliği gidereceğini sorun.