Müşteri geri bildirimini yapay zekâyla ürün geliştirme kararına çevirmek.

Altı şikâyet, altı ayrı müşteri ihtiyacı olmayabilir

Ürün toplantısında ‘dışa aktarma hakkında çok şikâyet var, yeni bir rapor ekranı yapalım’ önerisi geliyor. Yapay zekâ destek kayıtlarını hızlıca gruplamış, ancak aynı kişinin tekrar başvurusunu, yetki sorununu ve gerçekten eksik olan bilgiyi aynı başlıkta toplamış olabilir. Yeni özellik geliştirme kararı vermeden önce hangi işin yapılamadığını, kimlerin etkilendiğini ve önerilen çözümün o işe nasıl yardımcı olacağını ayırmanız gerekir.

Sentetik Pera iş takip ürününde altı destek kaydı, üç görüşme notu ve iki kullanım özeti var. Bunlar gerçek müşteri verisi veya ürün araştırması sonucu değildir. Uygulamanın amacı temaları yeniden saymak değil, tema özetinden sonra hangi ürün kararının henüz verilemeyeceğini görmek. Sonunda ‘rapor ekranı yap’ talebi yerine kanıtı, karşıt bulgusu ve sınanacak varsayımı belli bir problem kartı hazırlayacağız. Mevcut tema analizi yazısı ilk gruplama aşamasının ayrıntısını sunar.

Her kaydı geldiği bağlamla birlikte tutun

Altı destek satırı beş kuruma aittir. Sorun olarak ‘eksik sorumlu alanı’ seçildiğinde doğrudan destek kanıtı S1 ve S5'tir; S2 yeni bağımsız kurum sayılmaz. G1 ve G2 bu iki kurumun kullanım nedenini açıklayarak kanıtı derinleştirir, müşteri sayısını dörde çıkarmaz. G3 ise aynı değişikliğin herkese gerekli olmayabileceğini gösterir. Kaynak sayısı ile bağımsız kullanıcı sayısını birbirine karıştırmamak ürün kararının ölçeğini daha dürüst tutar.

Çözüm adını ihtiyaç cümlesine yerleştirmeyin

GOV.UK Service Manual, ihtiyaçların araştırma kanıtına dayanmasını ve belirli bir çözüm yerine kullanıcının yapmak istediği işe odaklanmasını önerir. Burada bu ilkeyi kurumsal ürün çalışmasına uyarlıyoruz. Rehber Pera verilerini veya aşağıdaki örneklem büyüklüğünü doğrulamaz.Kaynak: GOV.UK Service Manual — Learning about users and their needs

Kullanıcı: haftalık açık iş listesini ekip toplantısına götüren yetkili koordinatör. İş: her açık işi mevcut sorumlusuyla paylaşmak. Gözlenen engel: K1 ve K4'ün dışa aktarılan dosyasında sorumlu alanı bulunmadığı için elle düzenleme gerekiyor. Kanıt: S1, S5, G1, G2, U2. Karşıt bulgu: K6 mevcut dosyayı yeterli buluyor. Bilinmeyen: etkilenen kurumların toplam içindeki payı ve elle düzenleme süresi. Çözüm hipotezi: isteğe bağlı sorumlu sütunu bu işi kolaylaştırabilir.

‘Yeni rapor ekranına ihtiyaç var’ ifadesi daha baştan çözümü seçer. Oysa aynı ihtiyaç dosyaya isteğe bağlı bir sütun eklemekle, mevcut alana erişimi düzeltmekle veya paylaşım biçimini değiştirmekle karşılanabilir. Bu seçeneklerin maliyeti ve kullanım etkisi farklıdır. AI'dan ilk turda çözüm listesi istemek yerine problem kartının hangi kısmının kaynağa, hangisinin varsayıma dayandığını işaretlemesini isteyin. Çözüm seçenekleri bundan sonra tartışılabilir.

Kartta iki ayrı eksik bilgi bırakıyoruz. U2 elle düzenleme yapıldığını söylüyor, ama kaç dakika sürdüğünü söylemiyor. Bu yüzden saat veya tasarruf tutarı yazamayız. Benzer biçimde beş destek kurumu tüm kullanıcı tabanını temsil etmeyebilir; sessiz kullanıcıların deneyimi bilinmiyor. Bu sınırlamalar problem araştırmasını durdurmaz. Bir sonraki görüşmenin kimlerle yapılacağını ve hangi ölçümün toplanacağını belirler; ticari getiri hesabına hazır olduğumuzu göstermez.

Geliştirme kararından önce küçük ve gözlenebilir bir iş seçin

Bu üç kişilik çalışma benimsenme oranı veya pazar büyüklüğü tahmini değildir. Amacı, belirli görevin önerilen taslakla nasıl yürüdüğünü ve öngörülmemiş bir engel çıkıp çıkmadığını anlamaktır. Sütun eklenmiş bir örnek dosya bu amaç için yeterli olabilir; tam ekran geliştirmek şart değildir. Katılımcılara hangi yanıtın beklendiğini söylemek yerine aynı görev ve aynı başlangıç girdileri verilir. Yardım verildiyse gözlem kaydına eklenir.

Araştırma dosyasının tamamlanmış çıktısı bir deney tasarımıdır; deneyin gerçekten çalıştırıldığı iddia edilmez. Örneğin ‘üç kullanıcı da başarılı oldu’ cümlesini elde veri yokken rapora eklemeyin. Gerçek gözlemler geldiğinde her sonucu görev ve kayıt kimliğiyle ilişkilendirin. Olumlu bir izlenim ile görevi yardım almadan doğru tamamlamak farklı kanıtlardır. Ürün yöneticisi daha sonra geliştirme kararı verirken hangi kanıta ağırlık verdiğini açıklayabilmelidir.

AI taslağını karşıt kanıtla sınayın

Verilen S1–S6, G1–G3 ve U1–U2 kayıtlarını kullan. Aynı kurumun tekrar başvurusunu bağımsız müşteri sayma. Kullanıcının yapmak istediği işi, engeli, kaynak kimliklerini, karşıt bulguyu ve bilinmeyenleri içeren tek problem kartı yaz. Çözüm önerisini hipotez olarak ayrı göster. Ardından sekiz açık iş içeren örnek görev için gözlem planı oluştur. Süre, tasarruf, yaygınlık veya gerçekleşmemiş test sonucu uydurma.

1. Her ihtiyaç cümlesi en az bir kayıt kimliğiyle izlenebiliyor mu?
2. S2'nin tekrar olduğu ve G3'ün karşıt bulgusu korunmuş mu?
3. Yetki sorunu ile eksik alan sorunu ayrı mı?
4. Doğrulama görevi önerilen çözümü övmeyi değil kullanıcının işini gözlemlemeyi sağlıyor mu?

Küçük alıştırma: S3'teki yetki eksikliği giderildikten sonra K2 dosyayı kullanabildiğini söylesin. Bu sonuç sorumlu sütunu hipotezini doğrular mı? Cevap anahtarı: Hayır. K2'nin engeli dışa aktarma yetkisiydi. İsteğe bağlı sütunun K1 ve K4'ün elle eşleştirme işini kolaylaştırdığına dair yeni gözlem oluşmadı. K2 kaydı yetki iyileştirmesinin sonucuna eklenir; farklı bir ürün değişikliğinin başarı hanesine yazılmaz.

Kendi yorum listenizi bu yaklaşımla ele alırken bütün temaları aynı anda ürün kararına çevirmeyin. Kaynağı bulunabilen tek bir problemi seçin ve hangi bilgiyle kararınızı değiştireceğinizi yazın. Böylece araştırma, önerilmiş çözümü destekleyen alıntıları aramaya dönüşmez. AI gruplama ve taslak işini hızlandırabilir; üründe neyin değişeceğini belirleyen şey, kullanıcının işini ve karşıt kanıtları birlikte açıklayan dosyadır.