Destek talepleri ürün geliştirme için değerli bir kaynaktır, fakat doğrudan özellik listesine çevrilmemelidir. Bir müşteri yaşadığı soruna kendi çözümünü önerebilir; aynı sorun başka bir kullanıcıda farklı bir istek olarak ifade edilebilir. Ürün ekibine taşınması gereken şey, önce görev ve engeldir.
Buradaki öneri, destek kaydından ürün kararına uzanan küçük bir kanıt akışı kurmaktır. Gerçek müşteri verileri yayınlanmaz ve herhangi bir projede uygulanmış sonuç iddiası kurulmaz. Örnekler süreç tasarımı içindir.
Destek kaydını araştırma notuna dönüştürmek
Kişisel bilgileri çıkarılmış notta kullanıcının ne yapmaya çalıştığı, nerede takıldığı, hangi koşulların bulunduğu ve nasıl ilerlediği yazılır. “Dışa aktarma ekleyin” talebinin arkasında muhasebe kontrolü, ekip içi paylaşım veya veri kaybı korkusu olabilir. Bunların her biri farklı ürün kararı gerektirebilir.
Destek temsilcisinin yorumu ile müşterinin söylediği şey ayrı tutulmalıdır. Bir ekran görüntüsü veya olay kaydı varsa erişimi sınırlandırılır; bütün destek geçmişi ürün ekibine gereksiz yere kopyalanmaz. İnceleme için gereken asgari bağlam korunur.
Tekrarları konu adına göre değil işe göre birleştirmek
| Alan | Örnek kayıt |
|---|---|
| Kullanıcı işi | Haftalık siparişleri karşılaştırmak |
| Engel | Tarih aralığı değiştirilince seçimin kaybolması |
| Sonuç | İşlemin yeniden yapılması |
| Mevcut çözüm | Sonucu ayrı bir dosyaya kaydetmek |
| Kanıt | Aynı akışta tekrarlanan destek kayıtları |
| Belirsizlik | Sorunun hangi kullanıcı grubunda yaygın olduğu |
Bu yapı, farklı ifadelerle gelen aynı problemi birleştirmeyi kolaylaştırır. Yine de bütün “rapor” taleplerini tek başlıkta toplamak doğru değildir. Görev, sıklık ve iş etkisi farklıysa ayrı problem kayıtları korunmalıdır.
Sıklığı doğru payda ile değerlendirmek
On destek kaydı, yüz aktif kullanıcı için başka, çok büyük bir kullanıcı tabanı için başka anlam taşır. Destek kanalına ulaşmayan kullanıcılar da olabilir. Bu nedenle kayıt sayısını bütün ürün kitlesinin görüşü gibi sunmam.
Sorunu yaşayanların hangi özellikleri kullandığına, görevi ne sıklıkta yaptığına ve alternatif yolun maliyetine bakarım. Az sayıda kişiyi etkileyen ama temel işi tamamen durduran hata, çok sayıda küçük kozmetik talepten önce gelebilir. Öncelik yalnız talep adediyle verilmez.
Ürün ekibine bir karar sorusu göndermek
Aktarım “müşteri bunu istedi” şeklinde bitmemeli. “Bu görevin tamamlanmasını engelleyen seçim kaybını nasıl azaltabiliriz?” gibi bir soru, farklı çözüm seçeneklerine alan açar. Mevcut açıklamayı iyileştirmek, akışı düzeltmek veya yeni bir özellik yapmak ayrı seçeneklerdir.
Özellik talebinin arkasındaki problem bu ayrımı ayrıntılandırıyor. Backlog sadeleştirme ise ham taleplerin hazır geliştirme işiyle karışmasını önlemek için kullanılabilir.
Destek döngüsünü kapatmak
Karar verildiğinde destek ekibi nedenini ve müşteriye söylenebilecek doğru açıklamayı öğrenmelidir. Yapılmayacak bir özellik için belirsiz tarih vaadi verilmez. Araştırma, planlama ve geliştirme durumları birbirinden ayrılır.
Değişiklik yayımlandığında yalnız “özellik tamamlandı” denmez; ilk problem yeniden sınanır. Aynı görev hâlâ destek gerektiriyor mu? Yeni çözüm başka bir engel oluşturmuş mu? Kayıt sayısının düşmesi, ilgili kullanımın da düşmesinden kaynaklanıyor olabilir; bu nedenle davranış ve bağlam birlikte incelenir. Böylece destek, yalnız şikâyet taşıyan bir kanal olmaktan çıkar ve ürün kararlarının doğrulanmasına katkı veren bir süreç haline gelir.