Geri bildirim döngüsünü changelog tarafından kapatmak

Bir müşteri geri bildirim döngüsü, geri bildirimi veren kişiye ona ne olduğu söylendiğinde kapanır. Dosyalandığında değil. Önceliklendirildiğinde değil. Gönderildiğinde bile değil. Ona söylendiğinde. Çoğu ekip ilk üç adımı iyi yapar ve sonuncusunu hiç yapmaz, sonra geri bildirim gönderen insanların neden göndermeyi bıraktığını merak eder.

Bu makale o son adım hakkındadır, ve somut bir iddia hakkındadır: changelog, döngüyü kapatmak için doğru yerdir, çünkü döngünün kapatılabileceği anda zaten var olan tek artefakt odur.

Bir müşteri geri bildirim döngüsü nedir?

Bir müşteri geri bildirim döngüsü, bir kullanıcının size bir şey söylemesinden o kullanıcının ne yaptığınızı öğrenmesine giden yoldur. Dört adımı vardır: geri bildirimi toplamak, onunla ne yapılacağına karar vermek, sonucu göndermek, ve isteyen kişiye söylemek. Dördüncü adım gerçekleşene kadar döngü açıktır. Geri bildirim toplayan ve düzeltmeleri gönderen ama hiç kimseye söylemeyen bir ekibin bir gelen kutusu vardır, döngüsü yoktur.

Dördüncü satır bu makalenin konusudur. Kültürel değil yapısal bir nedenle bozulur: bir özellik gönderilene kadar, ona neden olan istek, gönderilen şeyden farklı bir sistemde yaşar, ve onları bağlamak kimsenin işi değildir. Döngü daha önce, isteğin en başta nasıl istendiğiyle başlar; müşteriden geri bildirim nasıl istenir ifadeyi ve zamanlamayı ele alır.

Geri bildirim döngüleri neden açık kalır?

Geri bildirim döngüleri açık kalır çünkü istek ve gönderilen değişiklik farklı yerlerde yaşar ve aralarındaki bağlantı, varsa, elle yapılır. İstek bir geri bildirim aracında, bir destek gelen kutusunda veya bir e-tablodadır. Değişiklik bir pull request’tedir. Duyuru bir changelog’da veya bir e-postadadır. Üç sistem, üç sahip, ve üçüncüden birinciye geri bağlantı, aylar sonra kimin sorduğunu hatırlayan bir kişidir.

İkinci bir neden var. Söyleme adımı genellikle bir destek görevi (“kişiye cevap vermek”) yerine bir pazarlama görevi (“özelliği duyurmak”) olarak çerçevelenir. Duyurular herkese gider ve özellikle kimseye ulaşmaz. Mart ayında özelliği isteyen kişi, Haziran duyurusunu, okursa, bir cevap olarak değil bir haber olarak okur. Döngü ancak mesaj ona yönlendirilmişse kapanır.

Döngü neden changelog’dan kapatılmalı?

Çünkü changelog girdisi, tam olarak doğru anda var olan, tam olarak doğru kelimeleri içeren, ve tam olarak doğru kişi tarafından yazılan tek artefakttır. Değişiklik canlı olduğunda var olur, öncesinde değil. Neyin değiştiğini okuyucunun terimleriyle söyler, ki bu isteyen kişinin ihtiyaç duyduğu mesajdır. Ve tam olarak pull request’i okumuş biri tarafından yazılır, ki bu orijinal isteğe olan bağlantının hâlâ görünür olduğu tek andır.

Alternatifleri karşılaştırın. Döngüyü geri bildirim aracından kapatmak, geri bildirim aracının özelliğin ne zaman gönderildiğini bilmesi gerektiği anlamına gelir, ki bu birinin elle bir durumu güncellediği anlamına gelir. Onu pull request’ten kapatmak, değişiklik canlı olmadan önce merge’de müşteriye söylemek anlamına gelir, dağıtım geciktiğinde zaman damgalı kırık bir söz. Onu pazarlama duyurusundan kapatmak, biri için beklemek anlamına gelir, ve gönderilen değişikliklerin çoğu asla bir tane almaz.

Changelog ortadadır: merge’den sonra, yayın anında, ifade hazır.

Döngü adım adım nasıl kapanır

İşte çalıştırdığımız mekanizma. Burada bir ürün turu yerine bir spesifikasyon olarak tanımlanmıştır, çünkü her adım elle veya başka araçlarla yapılabilir; önemli olan sıradır.

1. Geri bildirim, onu düzeltecek repository’de bir issue olur. Bir widget gönderimi, gönderenin e-posta adresi issue gövdesine girmeden etiketli bir GitHub issue’su (feature-request veya bug, bir öncelik, ve from-widget) olarak dosyalanır. Issue kodun yanında yaşar, böylece üçüncü adım onu bulabilir. Elle açılan bir issue, örneğin bir feature-request-şablonu ile, bu yolun dışındadır: beşinci adım ona yorum yapmaz, bu yüzden o döngüyü kendiniz kapatın.
2. Düzeltme issue’ya referans verir. Pull request Fixes #142 der, GitHub’ın kendi kapatma anahtar kelimesi. Öğrenilecek yeni bir şey yok, ve geliştiricilerin zaten yazdığı aynı cümle.
3. Changelog girdisi, merge edilen pull request’ten hazırlanır ve bağlantıyı taşır. Merge’de, taslak oluşturulur ve #142, PR gövdesinden okunup taslağa eklenir. Bağlantı, hâlâ ucuzken, bir makine tarafından, zaten orada olan verilerden yapılır.
4. Bir insan girdiyi gözden geçirir. İfade, hedef kitle, hiç yayımlanıp yayımlanmayacağı. Atılmış bir taslak hiçbir şeyi kapatmaz, ki bu doğrudur: bir issue’ya rastgele referans veren dahili bir refactor haber değildir.
5. Onaylandığında, isteyen kişiye söylenir. Geri bildiriminin dönüştüğü issue’da bir yorum yayımlanır, “Shipped —” ardından girdinin başlığı ve yayımlanan girdiye bir bağlantı, ve widget gönderene aynı gönderilen girdiyi gösterir. Bir kez, asla iki kez değil, ve sadece bir insan girdiyi yayımladıktan sonra. Aynı girdi feed ve widget aracılığıyla sormamış olan herkese gider.

Beşinci adımdaki sıra tüm tasarımdır. İsteyen kişiye merge’de söylemek daha erken ve daha kolay olurdu, ve dağıtımların geciktiği kadar sık yanlış olurdu. Bir feature flag bu sırayı bile bozar, çünkü onaylanmak ve yayınlanmak, özellik isteyen kişinin hesabı için hâlâ görünmezken gerçekleşebilir; feature flag’ler ve özellik talepleri bir flag işin içine girdiğinde bu adımın ihtiyaç duyduğu ek kontrolü ele alır.

Kapalı bir döngü müşteriye nasıl görünür?

Bir cevap gibi görünür. Müşteri bir widget aracılığıyla bir istek gönderdi, ve bir gün widget onu, kendi terimleriyle tanımlayan bir girdiye bağlantıyla birlikte gönderildi olarak gösterir; GitHub’da issue aynı haberi bir yorum olarak alır. Bir bültene abone olmadı, bir roadmap kontrol etmedi, changelog’da aramadı. Ona söylendi.

Bu, bir sonraki geri bildirim parçasının gerçekleşmesini sağlayan deneyimdir. İnsanlar cevap veren ürünlere geri bildirim gönderir. Changelog örnekleri sayfası, kullanıcıları görünür şekilde isteklerle geri gelmeye devam eden ekiplerin girdilerini içerir, ve ortak nokta araç değildir; girdilerin cevap gibi okunmasıdır.

Bir geri bildirim döngüsü nasıl ölçülür?

En az bir isteyen kişiyi bilgilendiren gönderilen değişikliklerin oranını, ve gönderme ile bilgilendirme arasındaki zamanı ölçün. Bağlantı var olduğunda kolay, öncesinde imkansız olan iki sayı.

• Kapatma oranı: bu ay yayımlanan changelog girdilerinden kaçı en az bir isteğe bağlantı verdi, ve bunlardan kaçı isteyen kişiyi bilgilendirdi. İkinci sayı birinciden çok daha düşükse, bildirimler başarısız oluyor demektir; birincisi düşükse, istekler pull request’lerden referans alınmıyor demektir, ve düzeltme PR şablonundaki bir cümledir.
• Gönderme-bilgilendirme süresi: girdinin canlıya çıkması ile isteyen kişinin bilgilendirilmesi arasında ne kadar geçiyor. Yukarıdaki mekanizma ile saniyeler. Elle tipik olarak haftalar, veya hiç, ve “hiç” önemli olan sayıdır.

Döngüyü toplanan geri bildirim hacmine göre ölçmeyin. Toplamak kolay adımdır, ve onu ölçen bir ekip onu optimize edecektir, ki bu daha fazla açık döngü üretir.

Roadmap nereye uyuyor?

Genel bir roadmap, döngüyü erken kapatmanın bir yoludur: isteyen kişilere, gönderilmeden önce isteklerinin duyulduğunu söyler. Faydalıdır, ve son adımın yerine geçmez. “Planlandı” gelecek hakkında bir sözdür; “Gönderildi” şimdiki zaman hakkında bir gerçektir. Genel roadmap’i aynı issue’lardan, sütun başına bir etiketle çalıştırın, böylece aynı istek herhangi bir yerde yeniden girilmeden planlanandan gönderilene taşınır. Gönderilene taşıma bir etiket değişikliğidir (roadmap:shipped) ve girdi onaylandığında bunu sizin yerinize hiçbir şey yapmaz, bu yüzden aynı incelemede yapın.

FAQ

Bir müşteri geri bildirim döngüsünün dört adımı nedir? Toplamak, karar vermek, göndermek, söylemek. Döngü, dördüncü adım gerçekleşene kadar açıktır. Çoğu çerçeve ortaya analiz ve önceliklendirme adımları ekler; bunlar “karar vermek”in inceltmeleridir, ve hiçbiri hiçbir şeyi kapatmaz.

Bir istek reddedildiğinde müşterilere söylenmeli mi? Evet, ve bu döngünün en ihmal edilen mesajıdır. Net bir “bunu yapmayacağız, ve işte nedeni” bekleyişi bitirir. Sessizlik, döngüyü sonsuza kadar açık ve müşteriyi kontrol ediyor bırakır.

Döngüyü kapatmak bir özelliği duyurmaktan nasıl farklıdır? Bir duyuru herkese gider. Döngüyü kapatmak, isteyen insanlara, istedikleri kanaldan bir cevaptır. İkisini de yapın; farklı okuyucular için farklı mesajlardır.

Ya isteyen kişi GitHub’da değilse? Çoğu değildir, ve bu sorun değil. Widget, gönderdikleri şeyin durumunu, gönderilen girdi ve bağlantısı dahil, onlara göstermeye devam eder, bu yüzden yazdıkları sayfanın ötesinde hiçbir şeye ihtiyaçları yoktur. Issue üzerindeki yorum, repository’yi görebilen kişiler içindir.

Bu döngü GitHub yerine GitLab veya Bitbucket’ta çalışır mı? Widget ve changelog çalışır; beşinci adımdaki otomatik yorum bugün için çalışmaz. GitLab veya Bitbucket’taki bir ekip yine de her gönderimi alır, yine de bunu bir issue olarak kaydeder ve yine de talep edene widget’ta bir durum gösterir, ama bu döngüyü tam olarak issue’nun kendisine kapatmak, o entegrasyon var olana kadar elle yaptığınız bir adımdı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 örnekleri