Özellik taleplerini kaybetmeden takip etmek

Özellik talebi takibi neredeyse her zaman iki şekilden birinde başarısız olur. Ya taleplerin gidecek hiçbir yeri yoktur, bu yüzden gelen kutularında ve Slack konularında yaşarlar ve tek tek unutulurlar, ya da kimsenin bir daha bakmadığı bir yerleri vardır ve topluca unutulurlar. İşe yarayan bir sistem her iki başarısızlığa da dayanmalıdır: her talebin düştüğü tek bir yere ve o yeri gelecek ay tekrar açmak için bir nedene ihtiyaç vardır.

Özellik talepleri gerçekte nereden gelir?

Çoğu takip sisteminin hesaba kattığından daha fazla kanaldan. “Şöyle olsa iyi olur” içeren bir destek bileti. Herkese açık bir yol haritasındaki bir yorum. Bir potansiyel müşterinin anlaşmayı engelleyen tek şeyi adlandırdığı bir satış görüşmesi. Ürün içindeki bir widget. Her kanalın kendi sahibi ve kendi araçları vardır, ve talepler tam da bu yüzden dağılır: destek bilet kuyruğu ile ürün ekibinin backlog’u nadiren aynı sistemdir, ve sadece ikisinden birine ulaşan bir talep, pratikte sadece tek bir departmana ulaşmıştır.

Her kanal için tek bir alım formu işe yaramaz, çünkü kimse onu benimsemez. İşe yarayan şey, yönlendirme başta otomatikleşene kadar günde beş dakikalık kopyala yapıştır olsa bile, her kanalın aktığı tek bir hedeftir.

Özellik talebi takibini gerçekte ne bozar?

Neredeyse her zaman iki şey. Birincisi, eksik bir hedef: talepler geldikleri kanalda yanıtlanır ve hiçbir yerde kalıcı olarak kaydedilmez, bu yüzden üç farklı müşteriden gelen aynı talep, bir sinyal yerine üç ilgisiz tekil yanıt gibi görünür. İkincisi, daha yaygın olanı, dolup okunmayı durduran bir hedeftir. Filtrelenmemiş 400 satırlık bir e-tablo artık bir takip sistemi değildir; tesadüfen yazılabilir olan bir arşivdir.

İkinci başarısızlık daha tehlikelidir, çünkü takibin çalışıyormuş gibi görünmesini sağlar. Talepler kaydedilir. Biri “kaç kişi X’i istedi” diye sorana kadar hiçbir şey bozuk görünmez, ve dürüst yanıt “bunu bilmek için 400 satırın hepsini okumamız gerekir” olur.

Bir özellik talebi gerçekte neyi kaydetmeli?

Orijinal mesajı yeniden okumadan sonradan üç soruyu yanıtlayacak kadar: ne istendiği, mümkünse talep edenin kendi kelimeleriyle; kimin istediği, ve yanıt “onu inşa ettik” olursa ona nasıl ulaşılacağı; ve bunun yaygın bir istek mi yoksa tek seferlik bir vaka mı olduğunu bilmek için ne gerektiği. Doğrudan bir alıntı bir parafrazdan daha değerlidir, çünkü talebi kim triyaj ettiyse onun yazdığı parafraz zaten kendi okumasını taşır, ve altı ay sonra ikinci bir kişinin doğrulayamayacağı da tam olarak o okumadır.

Hangi etiketler işe yarar?

İki tane, ve farklı soruları yanıtlarlar. Bir tür etiketi, bir özellik talebini bir hata raporundan ayırır, çünkü ikisi de farklı sahiplere ve zaman çizelgelerine ihtiyaç duyar, ve ikisini tek bir kuyrukta karıştırmak en yüksek sesli şikayetlerin talepleri geçmesine izin verir. Low, medium ve high gibi küçük bir kümeyle sınırlı bir öncelik etiketi, “birinin ürünü kullanmasını engelliyor” ile “güzel olurdu”yu ayırır, çünkü ikisi de çok farklı yanıt süreleri hak eder ve hiçbiri diğerinin temposunu devralmamalıdır. Tür etiketini doğru koymak, talebin iddia ettiği şey olduğunu varsayar; bir özellik talebi gerçekte bir hata raporu olduğunda bir müşterinin kendi sözlerinin bu etiketi yanlış yöne işaret ettiği durumu ele alır.

Otomatik triyaj, talep geldiği anda ikisini de uygulayabilir. changeloop’ta, bir widget gönderimi aynı geçişte feature-request veya bug etiketini ve bir priority:low|medium|high etiketini alır, artı öğeyi açmadan kaynağın görünür olması için bir from-widget etiketi. Bu, backlog’u bir öğleden sonra yerine bir dakikada filtrelenebilir kılmaya yeter: bu ay widget’tan gelen her yüksek öncelikli özellik talebini bana göster.

Herkese açık bir yol haritası olduğu anda üçüncü bir etiket işe yarar: talep edenin kendi başına kontrol edebileceği bir durum. Herkese açık yol haritası, planned, building ve shipped durumlarını baştan sona ele alır; kısacası bu etiket, özel bir kuyruğu, talep edenin tekrar sormadan kontrol edebileceği bir şeye dönüştürür.

Sırada ne inşa edileceğine nasıl karar verilir?

Saymadan önce grupla. Aynı temel yeteneği farklı şekillerde ifade eden on talep, bir e-tabloda dağınık on satır gibi görünür, gruplandığında ise güçlü bir sinyal gibi görünür, ve bu gruplama genelde eksik olan adımdır, sayma değil. Gruplama olmadan ham bir sayı, arkasında gerçek talebi en çok olanı değil, en akılda kalıcı isme sahip özelliği ödüllendirme eğilimindedir.

Kaç kişinin istediğine göre değil, kimin istediğine göre ağırlıklandır. Yenilemeye yakın bir hesaptan gelen bir talep, bir deneme kaydından gelen aynı talepten farklı bir aciliyet taşır, ve bu bağlamı çıplak bir sayı lehine atan bir takip sistemi, en yararlı sayı yerine hesaplanması en kolay sayı için optimize eder.

Buradaki her karar aynı zamanda kaybeden talepler de üretir, ve onlar da bir yanıtı hak eder; bir özellik talebi nasıl reddedilir isteği kabul edilmeyenlere ne söyleneceğini ele alır. Gruplama ve ağırlıklandırma, “sırada ne inşa edilecek” sorusunun sadece yarısıdır; özellik taleplerine öncelik vermek gerçek çerçeveleri, RICE’ı, gelire göre ağırlıklandırmayı ve ham sayıları, ve her birinin nerede kırıldığını ele alır.

Bir şey gönderildiğinde döngü nasıl kapatılır?

Bu, takip sistemlerinin en sık atladığı adımdır, ve talep edenlerin gerçekten fark ettiği adımdır. Müşteriyle geri bildirim döngüsünü kapatmak mekaniği baştan sona ele alır; buraya ait olan kısım, döngüyü kapatmanın sadece orijinal talep talep edene bağlı kaldığında işe yaramasıdır. Bir GitHub issue’sundan inşa edilmiş, talep edenin kimliği bir yoruma gömülü olmak yerine issue’ya bağlı olan bir özellik talebi şablonu, birinin göndermeyi hatırlaması gereken bir bildirim yerine otomatik bir “gönderildi” bildirimini mümkün kılan şeydir. Özellik talebi şablonu somut şablonu ve her alanın ne için olduğunu gösterir.

FAQ

Özellik talebi takibi için hangi aracı kullanmalıyım? Ekibin zaten her gün kontrol ettiği şey, kimsenin açmadığı özel bir aracı geçer. Mühendislik zaten orada yaşıyorsa bir GitHub issue tracker’ı iyi çalışır; ürün orada yaşıyorsa hafif bir pano iyi çalışır. Araç, tekrar açılıp açılmadığından daha az önemlidir.

Özellik taleplerinin kopyalanmasını nasıl önlerim? İfadeye göre triyaj etmeden önce temel yeteneğe göre grupla. Yeni bir tane oluşturmadan önce mevcut taleplerde arama yapmak çoğu kopyayı yakalar; aylık bir gruplama geçişi geri kalanını yakalar. Yinelenenleri orijinal sesi kaybetmeden birleştirmek, gruplamanın kendisi bittikten sonra ifadeyle ne yapılacağını ele alır, böylece birleştirme talebi sessizce hangi gönderim önce geldiyse ona daraltmaz.

Her özellik talebi bir yanıt almalı mı? Her biri, kısa bile olsa, bir alındı bildirimi almalıdır, ama her birinin hemen bir karara ihtiyacı yoktur. Talep edenin kendi başına kontrol edebileceği bir yol haritası etiketi gibi görünür bir durum, bir ekibin aksi halde borçlu olacağı bireysel yanıtların çoğunun yerini alır.

Özellik talebi takibi ile herkese açık bir yol haritası arasındaki fark nedir? Takip, asla gönderilmeyecek olanlar da dahil, her isteğin dahili kaydıdır. Herkese açık bir yol haritası, bir ekibin herkese açık olarak taahhüt ettiği alt kümedir, talep edenin tekrar sormadan görebileceği bir durumla birlikte.

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ı