Discovery Aşaması: Ne İşe Yarar, Nerede Boşa Gider

Discovery, tasarıma başlamadan önce problemi çerçeveleme evresi. Savunması kolay bir fikir, çünkü yanlış soruya verilen doğru cevabın kimseye faydası yok. Zor olan kısmı, bu evrenin ne kadar sürdüğünü ve neyi garanti ettiğini dürüstçe söyleyebilmek.

Discovery aslında ne çözüyor

Discovery'nin çıktısı çözüm değil, sınır. Problem alanının nerede başlayıp nerede bittiğini, hangi kullanıcı grubunun kapsam dışı kaldığını, hangi kısıtın pazarlık konusu olmadığını söyler. Ekibin sonraki üç ayda tartışacağı şeyleri değil, tartışmayacağı şeyleri belirler.

Bu yüzden discovery'nin başarısını üretilen fikir sayısıyla ölçmek yanıltıcı. İyi bir discovery genellikle masadaki seçenekleri azaltarak biter. Otuz post-it'le çıkılan bir atölye, katılımcılar kendini iyi hissetsin diye yapılmış olabilir; üç cümlelik net bir problem tanımıyla çıkılan görüşme serisi ise projenin geri kalanını taşır.

Discovery'ye genelde ürünün kendi verisiyle başlarım: arama kutusuna yazılıp sonuçsuz kalan sorgular, yarıda bırakılan form adımları, destek ekibine en çok gelen üç soru. Bunlar kimseyi ikna etmeye çalışmayan, zaten orada duran kayıtlar; kullanıcı görüşmelerine hangi soruyla gideceğinizi de onlar belirler.

Başarı istatistiklerindeki sorun

Discovery yapan projelerin daha başarılı olduğunu gösteren anketler dolaşıyor. Aradaki fark genelde büyük gösteriliyor ve sunumlarda doğrudan nedensellik gibi okunuyor.

Burada bir seçim yanlılığı var. Discovery yapabilen ekip, üç haftayı araştırmaya ayırabilecek takvime, bunu onaylayan bir yöneticiye ve araştırmayı yürütecek kişiye sahip ekiptir. Aynı ekip, discovery yapmasa da diğerinden daha iyi durumda olurdu. Ölçtüğünüz şey yöntemin etkisi değil, o yöntemi uygulayabilen organizasyonun sağlığı olabilir.

Bu, discovery'yi değersizleştirmiyor. Ama "yapan projelerin şu kadarı başarılı" cümlesini, discovery'si olmayan bir ekibe pazarlama argümanı olarak taşımak işe yaramıyor. O ekipte eksik olan araştırma evresi değil, araştırmayı mümkün kılan koşullar.

İki hafta gerçekte ne kadar zaman

Discovery süreleri çoğunlukla iki hafta ya da altında tutuluyor, ekip de tipik olarak dört kişi oluyor. Kâğıt üzerinde 4 kişi x 10 iş günü, yani 40 kişi-gün. Kulağa bol geliyor.

Bu dört kişinin hiçbiri discovery'ye tam zamanlı ayrılmıyor. Ürün yöneticisi mevcut sürümün sorularını yanıtlıyor, geliştirici zaten devam eden bir işin içinde. Gerçekte günün yarısı bu işe gidiyorsa elinizde 20 kişi-gün kalıyor.

Şimdi tek bir kullanıcı görüşmesinin maliyetine bakın: katılımcıyı bulma ve takvime oturtma, görüşmenin kendisi, notların çıkarılması, diğer görüşmelerle birlikte sentezlenmesi. Kırk beş dakikalık bir görüşme toplamda üç dört saati yiyor, yani yarım günü. Sekiz görüşme yapmak istiyorsanız bu tek başına 4 kişi-gün. Üstüne paydaş görüşmeleri, rakip incelemesi, atölye hazırlığı ve bulguları sunulabilir hale getirme geliyor; sunum ve raporlama tek başına iki üç gün tutuyor.

Yirmi kişi-günün içine bu listenin tamamı sığmıyor. Sığdığını varsayan planlar, görüşme sayısını üçe indirerek ya da sentez adımını atlayarak sığdırıyor; ikisi de discovery'nin işe yaradığı kısmı kesiyor. Takvim baştan dürüst kurulmadığında, kesilen yer her zaman en sonda duran adım oluyor.

Kapsam daralmak zorundaysa

Süre kısaldığında yöntemleri eşit oranda küçültmek yaygın tepki. Herkesten biraz kesiliyor: beş görüşme yerine üç, iki atölye yerine bir, rakip analizi yüzeysel. Sonuçta hiçbir yöntem karar verecek kadar veri üretmiyor.

Daha iyisi, tek bir yönteme yatırım yapıp gerisini bilinçli olarak bırakmak. Kullanıcıya erişebiliyorsanız görüşmeleri koruyun, rakip analizini sonraya atın. Erişemiyorsanız (B2B projelerde bu gerçek bir kısıt), ürünün kendi kullanım verisine ve destek kayıtlarına yüklenin, kullanıcıyı temsil ettiğini iddia eden ikinci el görüşlere değil.

Paydaş görüşmeleri bu sırada genelde en yüksek getiriyi veriyor, çünkü ucuzlar ve projeyi baştan raydan çıkaracak kısıtlar oradan çıkar. Bütçenin nerede bittiğini, hangi eski sistemle konuşmak zorunda olduğunuzu, hukukun neye izin vermediğini kullanıcı görüşmesinde öğrenemezsiniz.

Ekipte kim olmalı

Dört kişilik bir discovery ekibinde tasarımcı, araştırmacı ve ürün tarafı doğal olarak bulunuyor. Tartışmalı olan dördüncü koltuk.

Oraya bir geliştirici koymak, projenin çerçevesi daralmadan maliyet bilgisini masaya getiriyor. "Bu ekranda geçmiş siparişleri de gösterelim" cümlesinin iki saatlik mi yoksa iki haftalık mı bir iş olduğu, discovery sırasında öğrenilirse problem tanımını şekillendirir; tasarım onaylandıktan sonra öğrenilirse yalnızca hayal kırıklığı üretir. Geliştiricinin erken katılımına itiraz edenlerin gerekçesi, çözüm konuşmasının erken başlaması. Haklı bir endişe, ama çaresi kişiyi dışarıda tutmak değil, ona soruyu doğru sormak: bunu nasıl yaparız değil, bu veriye zaten sahip miyiz.

Discovery'yi atlamak her zaman hata mı

Hayır. Aynı problemi üçüncü kez çözüyorsanız, kullanıcı grubu ve iş kuralları değişmediyse, yeni bir araştırma evresi çoğunlukla bildiğiniz şeyi tekrar doğrular. Buradaki risk discovery'yi atlamak değil, atladığınızı fark etmemek.

Ayrım şu soruda: problemi mi bilmiyorsunuz, çözümü mü? Çözümden emin değilseniz prototip yapıp test edin, araştırma evresine girmenize gerek yok. Problemin kendisi bulanıksa, yani kimin hangi durumda ne yapmaya çalıştığını cümleye dökemiyorsanız, tasarıma başlamak sadece bulanıklığı ekrana taşır. Discovery'nin gerçek işlevi o cümleyi kurdurmak; onun dışındaki her şey süreç dekorasyonu.