Destek biletleri vs. özellik talepleri: hangisi?

Bir özellik talebi panosu, kullanıcıların oturup ne istediklerini anlatacak zamanları olduğunda neyi talep ettiklerini yakalar. Bir destek bileti, kullanıcıların şu anda neyde takıldığını yakalar, genellikle sinirli, genellikle altta yatan talebi düzgünce tanımlayacak kelime dağarcığı olmadan. İkisi de gerçek sinyaldir, ve sadece birine bakan ekipler, her kanal sistematik olarak farklı bir kullanıcı türünü ve farklı bir ihtiyaç türünü fazla temsil ettiği için sonunda kendinden emin bir şekilde yanlış sorunu çözer. Özellik taleplerine öncelik vermek zaten panoda olanı sıralamayı ele alır; bu yazı panoya hiç ulaşan ile sadece bir destek bileti olarak ortaya çıkan arasındaki boşlukla ilgilidir.

Aynı altta yatan sorun neden bir kanalda ortaya çıkıp diğerinde çıkmaz?

Çünkü iki kanalın farklı aktivasyon maliyetleri vardır, ve bu maliyetin büyüklüğü kimin onu aşacağını belirler. Bir özellik talebi göndermek inisiyatif gerektirir: bir kullanıcının talebi dile getirmeye değer olduğuna inanması, panoyu bulması, ve tutarlı bir şey yazması gerekir, ki bu zaten ürüne yatırım yapmış ilgili, sabırlı kullanıcıları seçer. Bir destek bileti göndermek buna kıyasla neredeyse hiç inisiyatif gerektirmez, çoğunlukla bir görev ortasında sadece “yardım”a tıklamaktır, ki bu, panoyu asla kullanmayacak olanlar dahil, anlık öfkeli kullanıcıları yakaladığı anlamına gelir. Üründeki gerçek bir boşluk, ona rastlayan kullanıcılar resmi bir talep göndermeye en az eğilimli olanlar olduğu için özellik panosunda görünmez ve destekte gürültülü olabilir.

Eksik bir özellik için bilet hacmi, onun için oy sayısıyla aynı şeyi mi ifade eder?

Hayır, çünkü farklı koşullar altında farklı popülasyonları ölçerler. Yüz oylu bir özellik talebi, mevcut bir talebi bulup destekleyecek zamanı ayırmış yüz kişiyi temsil eder, ki bu kalıcı, düşünülmüş talebin güçlü bir sinyalidir. Aynı dönemde gönderilen aynı altta yatan boşlukla ilgili yüz destek bileti, muhtemelen şu anda bir duvara çarpan kullanıcıları temsil eder, ki bunlardan bazıları acil sürtünme geçtikten sonra bunu tamamen unutabilirdi. İkisini “yüz kişi bunu istiyor” şeklinde eşdeğer bir sinyal olarak ele almak, bilet hacmini fazla ağırlıklandırır, çünkü biletler üretmesi ucuzdur ve oylar değildir.

Bir özelliğin destek bileti olup panoda neredeyse hiç oyu olmaması ne anlama gelir?

Genellikle, talebin var olduğu ama ona rastlayan kullanıcıların panonun var olduğunu bilmediği, oylamanın bir şey değiştireceğine inanmadığı, veya sorunla resmi olarak kaydetmek için kanal değiştirmekle uğraşamayacak kadar nadiren karşılaştığı anlamına gelir. Bu tam olarak bir talep panosunun yapısal olarak kaçırdığı popülasyondur, ve buradaki düşük oy sayısı düşük talebin değil, bir ölçüm boşluğunun kanıtıdır. Eksik bir özellik etrafındaki destek bileti kümesini, biletlere güvensizlik göstermek yerine, kullanıcılar adına kendinizin panoya kaydettiği kendi sinyali olarak ele alın, böylece sadece oy sayılarına göre önceliklendiren kişi için görünmez kalmaz.

Pano düşük öncelik olarak okunur:
"Export to CSV": 6 ayda 4 oy

Destek farklı bir hikaye anlatır:
"Export to CSV": aynı dönemde, her biri farklı bir
hesaptan, her biri "şu anda desteklenmiyor, geri
bildirimi ileteceğiz" ile kapatılan 31 bilet

Destek biletlerindeki bir artış her zaman altta yatan sorunun eksik bir özellik olduğu anlamına mı gelir?

Hayır, ve iki kanalın ters yönde yanıltabileceği yer burasıdır. Bir bilet artışı, zaten var olan bir özellik etrafındaki kafa karıştırıcı bir arayüzden, bir hatadan, veya yeterli açıklama olmadan çıkan bir değişiklikten eşit derecede sık kaynaklanır, ve bunların hiçbiri yeni bir şey inşa ederek çözülmez. Her bilet artışını “kullanıcılar sahip olmadığımız bir özelliği istiyor” olarak okumak, aslında dokümantasyon boşlukları veya kılık değiştirmiş kullanılabilirlik sorunları olan şeylerle dolu bir roadmap üretir. Destek bileti size sürtünmenin nerede olduğunu söyler; çözümün yeni bir özellik mi, bir arayüz değişikliği mi, yoksa daha iyi bir yardım makalesi mi olduğunu tek başına söylemez, ve bunu karıştırmak mühendislik zamanını yanlış çözüme harcar.

Ne inşa edileceğine karar verirken iki sinyal gerçekte nasıl birleştirilmeli?

Sürtünmenin nerede olduğunu bulmak için biletleri kullanın, ve gerçekten istenen sonucun neye benzediğini doğrulamak için, pano zayıf olduğunda doğrudan iletişim ile birlikte talep panosunu kullanın. Bir bilet kümesi gerçek, hissedilen bir sorunu tanımlar; çözümü üzerine inşa edecek kadar kesin bir şekilde nadiren belirtir, çünkü bir destek konuşmasındaki öfkeli bir kullanıcı belirtileri tanımlar, spesifikasyonları değil. Talep panosu, aynı altta yatan sorun üzerinde yeterli oy olduğunda, “bu gerçekte neyi tatmin ederdi” detayının daha fazlasını taşıma eğilimindedir, çünkü bir talep yazmak zaten neyin yanlış olduğunu bildirmek değil, ne istendiğini belirtme eylemidir.

Destek temsilcileri biletleri kendileri özellik talebi olarak kaydetmeli mi?

Evet, ve bu iki kanal arasındaki boşluk için en yüksek kaldıraçlı tek düzeltmedir. Bir bileti gizli bir özellik talebi olarak tanıyan bir temsilci, sadece çözüp devam etmek yerine, onu müşteri adına panoya kaydedebilir, ki bu, müşterinin ikinci bir kanalı keşfedip kullanmasını gerektirmek yerine ölçüm boşluğunu doğrudan kapatır. Bu sadece kaydetmenin temsilci için dakikalar değil saniyeler sürmesi durumunda işe yarar, böylece bunu yapmanın sürtünmesi biletle basitçe ilgilenip bir sonrakine geçmenin sürtünmesinden daha az olur.

FAQ

Özellik talebi oyları hepsi tek bir hesaptan veya ekipten geliyorsa hiç indirime tabi tutulmalı mı? Evet, ham oy sayısı yerine farklı hesaplara veya organizasyonlara göre ağırlıklandırın, çünkü aynı şirketteki beş kişiden gelen beş oy, bir müşterinin önceliklerini temsil eder, beş bağımsız talep onayını değil.

Biletlerde çokça görünen ama neredeyse hiç oyu olmayan bir özelliği inşa etmeye değer mi? Genellikle evet, bilet hacmi gerçekten farklı hesaplardan geliyorsa ve altta yatan ihtiyaç varsayılmak yerine doğrulanmışsa; düşük oy sayısını panonun aktivasyon maliyetinin bir ölçüm artefaktı olarak ele alın, talebin gerçek olmadığının kanıtı olarak değil.

Bir arayüz kafa karışıklığı biletini bir bakışta gerçek bir eksik özellik biletinden nasıl ayırt edersiniz? Çözümün mevcut bir yeteneği açıklamak mı yoksa eksik biri için özür dilemek mi olduğuna bakın. “Aa, aslında tam orada” çözümlerinin bir deseni bir arayüz veya keşfedilebilirlik sorununa işaret eder; “bunu henüz desteklemiyoruz” deseni gerçek bir boşluğa işaret eder.

Bu ayrım çok küçük bir destek hacminde de aynı derecede önemli mi? Mekanik olarak daha az, çünkü bir avuç bilet toplu analiz gerektirmeden tek tek okunması kolaydır, ama altta yatan önyargı, biletlerin öfkeli kullanıcıları fazla temsil edip sabırlı olanları az temsil etmesi, her ölçekte mevcuttur ve her bileti kendiniz okurken bile akılda tutmaya değer.

Bu yazıdaki teknik iddialar bağımsız olarak kontrol edilmedi. Yanlış bir şey varsa bize söyle, düzeltelim.

changeloop'ta ilgili sayfalar: Geliştirici dokümantasyonu, Changelog araçları karşılaştırması