Bir özellik talebi gerçekte bir hata raporu olduğunda

“Export limitini artırmak için bir ayar ekleyebilir misiniz?” bir özellik talebi gibi okunur, ve çoğu triyaj sistemi onu anında öyle etiketler. Bazen öyledir. Bazen export, dokümante edilmiş limitten daha düşük bir sayıda bir hata yüzünden başarısız olur, ve kodu göremeyen müşteri tanımlayabildiği en makul çözümü uydurmuştur: bana daha büyük bir sayı verin, belki çalışır. Hangi etiketler işe yarar bir backlog’u özellik talepleri ve hatalara bölen tür etiketini ele alır; burası bir müşterinin kendi sözlerinin etiketi yanlış yöne işaret ettiği durumdur, ve yanlış anlamanın bedeli, altına bakıldığında kimsenin gerçekten istemediği taleplerle dolu bir backlog’a yavaş bir sürüklenmedir.

Gerçekte bir hata raporu olan bir özellik talebi neye benzer?

Sorunu değil, bir workaround’u adlandırır. Gerçek bir özellik talebi genellikle ürünün hiç desteklemediği bir sonucu tanımlar: “bunu daha sonraya planlayabileyim”, “koyu mod ekleyin”. Yanlış sınıflandırılmış bir hata raporu, eksik bir ayar gibi görünen ama gerçekte bir belirti olan belirli bir sayı, eşik veya davranış tanımlar: “timeout’u artırın”, “bir yeniden deneme seçeneği ekleyin”, “aynı anda daha fazla satır export etmeme izin verin”. Belirti, isteyen kişinin bir hedef tanımlamak yerine bir uygulama, bir ayar, bir anahtar, bir geçersiz kılma önermesidir, çünkü özelliği dokümante edildiği gibi zaten denemiştir ve dokümantasyonun yapması gerektiğini söylediği şeyi yapmamıştır.

Bu neden göründüğünden daha önemli?

Çünkü iki kuyruğun farklı sahipleri, zaman çizelgeleri ve başarı kriterleri vardır, ve özellik talebi olarak dosyalanmış bir hata, özellik taleplerine karşı önceliklendirilir, bir hatanın hak ettiği zaman çizelgesinde düzeltilmek yerine gerçek ürün eksiklikleriyle dikkat için rekabet eder. Özellik taleplerini takip etme hataları ve özellikleri tek bir kuyrukta karıştırmanın en yüksek sesli şikayetlerin gerçek talepleri geçmesine nasıl izin verdiğini ele alır; gizlice bir hata olan bir özellik talebi tersi zararı verir, ürün backlog’unda kalır ve temel hata düzeltilir düzeltilmez ortadan kalkacak bir “özellik” için oy toplar, ki bu o backlog’u okuyan herkes için önceliklendirme sinyalini boşa harcar.

Müşterinin kendi sözleri yanlış yöne işaret ettiğinde fark nasıl anlaşılır?

Ne eklemenizi istediğini değil, ne olmasını beklediğini sorun. “Export 500 satırda tıkandı ve 2.000’e ihtiyacım var, limiti artırabilir misiniz” takip sorusu, “500 dokümante edilmiş limit mi”, dokümante edilmiş sayının 5.000 olduğunu ve export’un erken başarısız olduğunu ortaya çıkarana kadar bir limit artırma özellik talebi gibi görünür. Sadece bu tek soru, ne beklediği ile ne olduğu, sınıflandırma işinin çoğunu yapar, çünkü gerçek bir özellik talebinin altında kaldığı dokümante edilmiş bir davranış yoktur; beklenecek bir şey yoktur çünkü yetenek henüz mevcut değildir.

Destek görevlileri mi yoksa mühendisler mi bu kararı vermeli?

Destek görevlileri ilk geçişi yapar, çünkü bileti önce onlar görür, ama etiket kolayca değiştirilebilir ve yanlış yapması ucuz olmalı, öğeyi sonsuza dek yanlış kuyrukta sabitleyen tek seferlik bir karar değil. Hafif bir ikinci kontrol, gizli bir hata gibi kokan her şey için haftada bir yeni “özellik talebi” etiketlerini tarayan bir mühendis, kod tabanı bağlamı olmayan bir destek görevlisinin fark edemeyeceği olanları yakalar. Bunun resmi olması gerekmez; bir inceleme sürecinden çok beş dakikalık bir bakıştır.

Gerçek hata bulunduğunda döngüyü kapatmak değişir mi?

Evet, ve gönderebileceğiniz mesajı iyileştirir. Müşteri geri bildirim döngüsünü kapatma bir şey gönderildiğinde isteyen kişiye söylemeyi ele alır; yeniden sınıflandırılmış bir hata bu mesajın daha iyi bir versiyonunu alır, çünkü “bunun arkasındaki hatayı bulduk ve düzelttik” yeterlilik gibi geliyorken, “istediğiniz özelliği oluşturduk” sadece kazara doğru olurdu, çünkü gerçek özellik talebi, gerçekten daha yüksek bir export limiti, hata gittikten ve orijinal 5.000 satır limit yeterli olduktan sonra hiç oluşturulmayabilir.

Yanlış sınıflandırma hiç fark edilmezse ne olur?

Backlog gerçek talep gibi görünen ama olmayan taleplerle dolar, ve o backlog’a karşı alınan önceliklendirme kararları çarpıklığı miras alır. Kırk oylu bir “özellik” gerçekte aynı hataya denk gelen kırk kişi olabilir, ve harfi harfine isteği inşa etmek, gerçekte hiç kısıtlama olmamış bir limiti artırmak için bir ayar, hiçbir şeyi düzeltmeyen karmaşıklık teslim eder, temel hata ise bu konuyu henüz bulmamış müşterilerden yeni “özellik talepleri” üretmeye devam eder.

FAQ

Her özellik talebini bilinen hatalara karşı kontrol etmek için resmi bir adım eklemeye değer mi? Resmi bir adım değil, bir alışkanlık: yeni bir özellik talebini triyaj eden kişi etiketi uygulamadan önce “dokümante edilmiş davranış bunu zaten yaptığını iddia ediyor mu” diye sormalı, çünkü sadece bu soru süreç yükü eklemeden yanlış sınıflandırmaların çoğunu yakalar.

Ya hata bulunduktan sonra bile müşteri bunun bir özellik talebi olduğunda ısrar ederse? Ne bulduğunuzu ve hata düzeldikten sonra önerdiği ayara neden artık ihtiyaç olmayacağını açıklayın. Çoğu müşteri bir workaround ister çünkü gerçek düzeltmenin mevcut olmadığını varsaymıştır, o ayarı özellikle istediği için değil.

Yeniden sınıflandırılmış bir öğe özellik talebi olarak topladığı oyları veya yorumları kaybeder mi? Görünür şekilde saklamalı, çünkü o oylar hatayı bulmaya götüren kanıttır, ve o izi gizlemek aynı yanlış sınıflandırmanın bir sonraki seferde, farklı bir bilette, fark edilmesini zorlaştırır.

Bu tersine de olabilir mi, gerçekte özellik talebi olan bir hata raporu? Daha az sıklıkta, ama evet: “bu bozuk” bazen “bu, yapacağını varsaydığım şeyi yapmıyor” anlamına gelir, ki bu bir kusur değil, eksik bir yetenektir. Aynı soru, ne beklediği ile ne dokümante edildiği, bu yönde de sınıflandırır.

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ı