Discovery Mindset: Çözümden Değil Problemden Başlamak

Ürün ekiplerinin çoğu elinde bir çözüm fikriyle işe başlar ve araştırmayı o fikrin etrafında kurar. Discovery mindset bunun tersini yapar: hangi problemin çözülmeye değdiğini, çözümü seçmeden önce öğrenir. Aradaki fark üslup değil, toplantıda hangi soruların sorulduğudur.

Çözümden başlamanın bedeli

“Bu sohbet robotunu nasıl daha iyi yaparız” sorusu masum görünür. Oysa araştırmanın sınırlarını ilk toplantıda çizer: robot artık verilidir. Kullanıcı görüşmelerindeki sorular onun etrafında döner, çıkan bulgular da robotu iyileştirmenin yollarına indirgenir. Kullanıcının derdi destek kanalının kendisi değil, siparişinin nerede olduğunu kimseye sormadan göremiyor olması olabilir; bu ihtimal o soruyla hiç gündeme gelmez.

İki bilinen mekanizma bu daralmayı hızlandırır:

• Çapalanma: İlk duyulan çözüm referans noktası olur, sonraki bütün fikirler ona göre iyi ya da kötü sayılır.
• Doğrulama yanlılığı: Araştırma, çözümü haklı çıkaracak veriyi bulmaya çalışır. Aksini gösteren bulgu “uç kullanıcı” diye kenara konur.

Hedefi problem cümlesine çevir

Çerçeveyi değiştirmek pahalı bir iş değil, bir cümleyi yeniden yazmaktır. “Sohbet robotunu iyileştirelim” yerine “kullanıcı sipariş durumunu kimseye sormadan göremiyor” yazdığınızda araştırma alanı aniden genişler. Çözüm kümesine bildirim, kargo entegrasyonu, hesap sayfasında tek satırlık bir durum alanı da girer. Üçü de robot yazmaktan ucuzdur.

Bu cümleyi yazarken çözüm adı geçmemesine dikkat edin. Problem tanımında bir arayüz bileşeni varsa, çerçeveleme değil kılık değiştirmiş bir çözüm kararı yapmış olursunuz.

Bilinmeyen envanteri

Projenin ilk haftasında üç kolon yazın: bildiklerimiz, bilmediklerimiz, varsaydıklarımız. Değerli olan üçüncüsüdür, çünkü ekibin tartışmasız kabul ettiği şeyler oraya düşer. “Kullanıcılar mobilde bakıyor”, “sipariş numarasını biliyorlar”, “bu ekranı günde birden fazla açıyorlar” gibi cümleler yazıya geçince hangisinin ölçülmüş, hangisinin tahmin olduğu ortaya çıkar.

Bu listeyi ayrı bir dokümanda tutmayın, iş takip sisteminize varsayım etiketiyle kayıt olarak girin. Ayrı doküman iki hafta içinde kimsenin açmadığı bir dosyaya döner; etiketli kayıtlar ise planlama toplantısında önünüze çıkar ve biri “bu doğrulandı mı” diye sormak zorunda kalır.

Bilinmeyen bilinmeyenler bu envanterden çıkmaz. Adını koyamadığınız şeyi araştırma planına yazamazsınız. Onlar ancak kullanıcıyı kendi ortamında izlerken, görüşme senaryosunun dışına çıkıldığında görünür hale gelir. Bu yüzden saha gözlemi, listeyi iyi tutmanın alternatifi değil zorunlu eşlikçisidir.

Buzluk, dikkatli kullanılmazsa çapanın kendisi olur

Yaygın tavsiye şudur: çözüm fikirlerini atmayın, yazıp buzluğa kaldırın, araştırma bitince geri dönün. Tavsiyenin zayıf noktası görmezden gelinir. Yazıya geçmiş bir çözüm, kafada kalmış bir çözümden daha güçlü bir çapadır; listede durduğu için hatırlanır, hatırlandığı için de tartışmanın başlangıç noktası olur.

Sıra bunu kurtarır. Buzluğu araştırma bitince değil, bulgular yazıya dökülüp paylaşıldıktan sonra açın. Aksi halde toplantı, bulgulardan ne çıktığını konuşmak yerine listedeki fikirlerden hangisinin bulgulara uyduğunu konuşur. İkisi aynı şey değildir: birinci durumda çözüm bulgudan türer, ikincisinde bulgu çözümü onaylamak için kullanılır.

İkinci önlem fikrin yazılma biçimidir. “Sohbet robotu ekleyelim” değil, “kullanıcılar durum sorusunu yazarak sormayı tercih ediyorsa sohbet robotu işe yarar” diye yazın. Böylece buzluktan çıkan şey bir karar değil, test edilebilir bir koşul olur.

Keşif her projeye gerekmez

Discovery bir erdem gösterisi değil, risk yönetimidir. Problem tanımı netse ve risk uygulamanın kendisindeyse, iki haftalık keşif çalışması gecikmeden başka bir şey üretmez. Keşfin karşılığını verdiği yer, yanlış problemi çözmenin maliyetinin yazılım maliyetini aştığı yerdir. Üç gün sürecek bir değişiklikte bu eşik aşılmaz. Altı aylık bir modülde fazlasıyla aşılır, ve o modüle başlamadan sorulmayan soru, canlıya çıktıktan sonra kullanıcı yorumlarıyla sorulur.