Destek Taleplerini Gerçekten Tekrarlayana Göre Önceliklendir
4 dk okuma
Çoğu önceliklendirme, bir ürün yöneticisinin yakın zamanda okuduğu taleplerle ya da yüksek sesle üst makama taşınanlarla başlar. Bu, gerçekte neyin en yaygın olduğunu bilmekle aynı şey değildir ve sessiz ama sık bir sorunun her seferinde nadir ama gürültülü olana yenilebileceği anlamına gelir. Pazartesi sabahı destek kuyruğunu açan bir ürün yöneticisi, otuz başka kullanıcının geçen ay aynı altta yatan sürtünmenin daha küçük bir sürümünü sessizce bildirdiği gerçeğinden çok, hafta sonu bir hesap yöneticisinin üst makama taşıdığı talep üzerinde harekete geçmeye çok daha yatkındır.
Dikkat
Hatırladığın bir talep ile yinelenen bir talep farklı sinyallerdir. Hatırladığın, yalnızca üst makama taşınan olabilir; en çok kullanıcıyı etkileyen değil.
Hatırladığın talep her zaman ilk düzeltmeye değer olan değildir. Sürekli tekrarlayan öyledir.
Talepleri sırayla okumak gerçek sıklığı neden ortaya çıkarmaz
Bir destek kuyruğunu okumak sana izlenimler verir, sayımlar değil. On beş farklı kullanıcının on beş farklı biçimde bildirdiği bir sorun, talepleri tek tek okurken bir örüntü gibi görünmez; on beş ayrı şikâyet gibi görünür. Her biri farklı ifade edilmiş onlarca talep boyunca akan bir sayımı akılda tutmanın zihinsel çabası, insan bir gözden geçirenin kötü olduğu ve olduğundan azımsamaya yatkın olduğu türden bir sayma işidir.
Bir kullanıcının, bir kurumsal hesabın, kurulumdaki kafa karıştırıcı bir adımı yüksek sesle üst makama taşıdığı bir işe alıştırma akışının destek kuyruğunu düşün. O talep hızla ilgi görür. Bu arada aynı hafta, otuz ücretsiz plan kullanıcısı aynı adım hakkında sessizce, otuz farklı ifadeyle talep açar; hiçbiri üst makama taşınmamış, hiçbiri tek başına alarm verici değildir. Geliş sırasıyla okunduğunda, gürültülü kurumsal talep yöneticinin neyin bozuk olduğuna dair zihinsel modeline hâkim olur; çok daha fazla kullanıcıyı etkileyen gerçek en yüksek sıklıktaki sorun ise otuz ayrı talep arasında bir örüntü olarak tanınmadan kalır.
Önce: son talepleri göz gezdir, en acil hissettirenleri ya da üst makama taşınanları önceliklendir, devam et.
Sonra: bir grup talebi Claude'a yapıştır, her birine kaç talebin düştüğüne göre sıralanmış temalara gruplamasını iste ve gerçek sıklığa göre önceliklendir.
Talepleri sıralı temalara dönüştürmek için bir süreç
- 1
Bir avuç değil, gerçek bir grup topla
Gelen kutunda ne varsa onu değil, tanımlı bir zaman aralığından, tam bir haftadan ya da aydan talepleri çek. Kısmi bir örneklem, en son geleni öne çıkarmaya kayar.
- 2
Özet değil, sıklığa göre gruplanmış temalar iste
Özet söyleneni sıkıştırır. Özellikle, her gruba kaç talebin düştüğünün sayımıyla yinelenen temalara gruplanmış talepler iste.
- 3
Tema başına temsil edici bir talep iste
Gerçek bir örnek her temayı somut bir şeye bağlar ve sonradan bir önceliği yalnızca bir sayımla değil gerçek bir vakayla gerekçelendirmen gerektiğinde işe yarar.
- 4
Sayıya göre önceliklendir, sonra ciddiyetle sınamak için kontrol et
Sıklık sana neyin yaygın olduğunu söyler, mutlaka neyin en maliyetli olduğunu değil. Sıralı listeye sahip olduğunda, daha az sık bir temanın ciddiyeti nedeniyle yine de yukarı taşınmaya değip değmediğini kontrol et.
İşte işe alıştırma akışımız hakkında 30 destek talebi. Bunları en yaygın üç şikâyete grupla ve her gruba kaç talebin düştüğünü söyle.
”Temalar sıralandıktan sonra, önceki bir döneme göre büyüyüp küçülmediklerini kontrol etmeye değer; çünkü haftadan haftaya hızla artan bir tema, aylardır sabit, düşük düzeyli bir uğultu olandan farklı türde bir aciliyettir.
İşte geçen ayın aynı tema dökümü. İkisini karşılaştır ve yalnızca bu ay en yüksek ham sayıya sahip olanları değil, toplam taleplerin payı olarak hangi temaların büyüdüğünü söyle.
”
Claude Tutorial içinde
Yenilik yerine gerçek sıklığa göre sıralamak aktarılabilir bir beceridir.
Dağınık bildirimleri, en son gördüğünü önceliklendirmek yerine sayılmış temalara gruplamak, destek taleplerinin çok ötesinde geçerlidir. Uygulamada bu konuda, harekete geçmen gereken her geri bildirime taşınan alıştırmalarla tam bir ders var.
Sıklık ve ciddiyet farklı yönlere işaret ettiğinde
Bazen en yaygın tema en zararlı olan değildir. Sık bildirilen küçük bir sıkıntı ile hesabı engelleyen nadir bir hata, ikisi de listede yer hak eder; yalnızca mutlaka sıklık sırasında değil. Sıklığı tek girdi saymak, etkilenen kullanıcılar bir talep açacak kadar ürünün içine giremedikleri için çok talep üretmeyen nadir ama ciddi sorunları sistematik olarak düşük önceliklendirme riski taşır.
İpucu
Claude'dan hangi temaların kullanıcıları tamamen engellediğini, hangilerinin yalnızca rahatsız ettiğini işaretlemesini iste. Daha az bildirimli engelleyici bir sorun, yine de daha büyük ama düşük ciddiyetli bir temayı geçebilir.
Bulduğun üç temadan hangileri kullanıcıları işe alıştırmayı bitirmekten tamamen alıkoyuyor, hangileri yalnızca sürtünmeden rahatsız ediyor? Önceliği kesinleştirmeden önce ciddiyeti sıklıkla birlikte tartmak istiyorum.
”Düşük sıklıkta, yüksek ciddiyette bir temanın tam da ciddi olduğu için eksik bildirilip bildirilmediğini kontrol etmeye de değer; çünkü işe alıştırmanın başında sert bir engele takılan bir kullanıcı, talep açmak için zaman ayırmak yerine ürünü tamamen terk edebilir.
Bu engelleyici sorun yalnızca 3 talep üretti; bu kadar ciddi bir şey için az görünüyor. Böyle engelleyici bir sorunun, kullanıcıların devam etmesine izin veren daha hafif birine göre eksik bildirilmesinin bir nedeni var mı?
”Okumaya devam et
- Ödünleşimleri Açıklayan Bir Yol Haritası Belgesi Yazmak: sıralı bir tema listesini paydaşların takip edebileceği bir yol haritası kararına dönüştürmek.
- Tek Satırlık Bir Özellik İsteğinden PRD Yazmak: bir tema belirtmeye değer bir özelliği ortaya çıkardığında ne yapılacağı.
- Bir PRD'yi İncelemeye Göndermeden Önce Keskinleştirmek: bunun gibi bir temanın işaret edebileceği uç durumları incelemeden önce yakalamak.