Menutup lingkaran umpan balik dari sisi changelog

Lingkaran umpan balik pelanggan tertutup ketika orang yang memberi umpan balik diberi tahu apa yang terjadi padanya. Bukan saat itu dicatat. Bukan saat diprioritaskan. Bahkan bukan saat dirilis. Saat diberi tahu kepadanya. Kebanyakan tim melakukan tiga langkah pertama dengan baik dan langkah terakhir sama sekali tidak, lalu bertanya-tanya mengapa orang yang mengirim umpan balik berhenti mengirimnya.

Artikel ini membahas langkah terakhir itu, dan sebuah klaim konkret: changelog adalah tempat yang tepat untuk menutup lingkaran, karena itu satu-satunya artefak yang sudah ada tepat di saat lingkaran itu bisa ditutup.

Apa itu lingkaran umpan balik pelanggan?

Lingkaran umpan balik pelanggan adalah jalur dari pengguna yang memberi tahu Anda sesuatu hingga pengguna itu mengetahui apa yang Anda lakukan tentang itu. Ada empat langkah: mengumpulkan umpan balik, memutuskan apa yang harus dilakukan dengannya, merilis hasilnya, dan memberi tahu orang yang meminta. Lingkarannya terbuka hingga langkah keempat terjadi. Tim yang mengumpulkan umpan balik dan merilis perbaikan tapi tidak pernah memberi tahu siapa pun punya kotak masuk, bukan lingkaran.

Baris keempat itulah yang dibahas artikel ini. Rusak karena alasan struktural, bukan budaya: pada saat sebuah fitur dirilis, permintaan yang menyebabkannya hidup di sistem yang berbeda dari hal yang dirilis, dan menghubungkan keduanya bukan tugas siapa pun. Lingkaran itu dimulai lebih awal, dengan cara permintaan diajukan sejak awal; cara meminta umpan balik pelanggan membahas kalimat dan waktunya.

Mengapa lingkaran umpan balik tetap terbuka?

Lingkaran umpan balik tetap terbuka karena permintaan dan perubahan yang dirilis hidup di tempat yang berbeda dan tautan di antara keduanya dibuat secara manual, jika dibuat. Permintaan ada di alat umpan balik, kotak dukungan atau spreadsheet. Perubahannya ada di pull request. Pengumumannya ada di changelog atau email. Tiga sistem, tiga pemilik, dan tautan dari yang ketiga kembali ke yang pertama adalah seseorang yang mengingat, berbulan-bulan kemudian, siapa yang meminta.

Ada alasan kedua. Langkah memberi tahu biasanya dibingkai sebagai tugas pemasaran (“mengumumkan fitur”) daripada tugas dukungan (“membalas orangnya”). Pengumuman pergi ke semua orang dan tidak mencapai siapa pun secara khusus. Orang yang meminta fitur pada Maret membaca pengumumannya pada Juni, jika mereka membacanya, sebagai berita, bukan sebagai balasan. Lingkarannya hanya tertutup jika pesannya ditujukan kepada mereka.

Mengapa menutup lingkaran dari sisi changelog?

Karena entri changelog adalah satu-satunya artefak yang ada tepat pada momen yang benar, mengandung kata-kata yang tepat, dan ditulis oleh orang yang tepat. Ada saat perubahan itu live dan tidak sebelumnya. Mengatakan apa yang berubah dalam bahasa pembaca, yang merupakan pesan yang dibutuhkan peminta. Dan ditulis oleh seseorang yang baru saja membaca pull request, yang merupakan satu-satunya momen di mana tautan ke permintaan asli masih terlihat.

Bandingkan alternatifnya. Menutup lingkaran dari alat umpan balik berarti alat umpan balik perlu tahu kapan fitur dirilis, yang berarti seseorang memperbarui status secara manual. Menutupnya dari pull request berarti memberi tahu pelanggan saat merge, sebelum perubahannya live, sebuah janji yang rusak dengan stempel waktu segera setelah deployment tertunda. Menutupnya dari pengumuman pemasaran berarti menunggu satu, dan kebanyakan perubahan yang dirilis tidak pernah mendapatkannya.

Changelog berada di tengah: setelah merge, pada saat rilis, dengan formulasi sudah siap.

Bagaimana lingkarannya tertutup, langkah demi langkah

Ini mekanisme yang kami jalankan. Digambarkan di sini sebagai spesifikasi alih-alih tur produk, karena setiap langkah bisa dilakukan secara manual atau dengan alat lain; yang penting adalah urutannya.

1. Umpan balik menjadi issue di repositori yang akan memperbaikinya. Pengiriman widget dicatat sebagai issue GitHub berlabel (feature-request atau bug, satu prioritas, dan from-widget), dengan alamat email pengirim tidak dimasukkan ke badan issue. Issue-nya hidup di sebelah kode, sehingga langkah tiga bisa menemukannya. Issue yang dibuat manual, misalnya dari template permintaan fitur, berada di luar jalur ini: langkah lima tidak mengomentarinya, jadi tutup lingkaran itu sendiri.
2. Perbaikannya merujuk ke issue. Pull request mengatakan Fixes #142, kata kunci penutupan milik GitHub sendiri. Tidak ada yang baru untuk dipelajari, dan itu kalimat yang sama yang sudah ditulis developer.
3. Entri changelog disusun dari pull request yang di-merge dan membawa tautannya. Saat merge, draf dibuat dan #142 dibaca dari badan PR dan dilampirkan ke draf. Tautannya dibuat selagi masih murah, oleh mesin, dari data yang sudah ada di sana.
4. Seseorang meninjau entrinya. Formulasi, audiens, apakah itu perlu diterbitkan sama sekali. Draf yang dibuang tidak menutup apa-apa, yang benar: refactor internal yang kebetulan merujuk issue bukanlah berita.
5. Saat disetujui, peminta diberi tahu. Komentar diterbitkan di issue yang berasal dari umpan baliknya, “Shipped —” diikuti judul entri dan tautan ke entri yang diterbitkan, dan widget menampilkan entri rilis yang sama kepada pengirimnya. Sekali, tidak pernah dua kali, dan hanya setelah seseorang menerbitkan entrinya. Entri yang sama keluar melalui feed dan widget ke semua orang yang tidak meminta.

Urutan di langkah lima itulah seluruh desainnya. Memberi tahu peminta saat merge akan lebih awal dan lebih mudah, dan akan salah sekitar sesering deployment tertunda. Feature flag merusak bahkan urutan ini, karena disetujui dan dipublikasikan bisa terjadi sementara fitur itu masih tidak terlihat bagi akun peminta; feature flag dan permintaan fitur membahas pemeriksaan tambahan yang dibutuhkan langkah ini begitu ada flag terlibat.

Seperti apa lingkaran tertutup bagi pelanggan?

Terlihat seperti balasan. Pelanggan mengirim permintaan melalui widget, dan suatu hari widget menampilkannya sebagai sudah dirilis, dengan tautan ke entri yang menjelaskannya dalam bahasa mereka; di GitHub, issue-nya menerima kabar yang sama sebagai komentar. Mereka tidak berlangganan newsletter, tidak memeriksa roadmap, tidak mencari di changelog. Mereka diberi tahu.

Itulah pengalaman yang membuat potongan umpan balik berikutnya terjadi. Orang mengirim umpan balik ke produk yang membalas. Halaman contoh changelog menyertakan entri dari tim yang penggunanya terlihat terus kembali dengan permintaan, dan benang merahnya bukan alatnya; itu karena entrinya terbaca seperti balasan.

Bagaimana cara mengukur lingkaran umpan balik?

Ukur fraksi perubahan yang dirilis yang memberi tahu setidaknya satu peminta, dan waktu dari rilis hingga pemberitahuan. Dua angka, keduanya mudah begitu tautannya ada dan mustahil sebelumnya.

• Tingkat penutupan: dari entri changelog yang diterbitkan bulan ini, berapa banyak yang menautkan setidaknya satu permintaan, dan dari itu, berapa banyak yang memberi tahu peminta. Jika angka kedua jauh lebih rendah dari yang pertama, notifikasi gagal; jika yang pertama rendah, permintaan tidak dirujuk dari pull request, dan perbaikannya adalah satu kalimat di template PR.
• Waktu dari rilis hingga pemberitahuan: berapa lama antara entrinya menjadi live dan pemberitahuan ke peminta. Dengan mekanisme di atas itu detik. Secara manual biasanya minggu, atau tidak pernah, dan “tidak pernah” adalah angka yang penting.

Jangan mengukur lingkaran berdasarkan volume umpan balik yang dikumpulkan. Mengumpulkan adalah langkah mudah, dan tim yang mengukurnya akan mengoptimalkannya, yang menghasilkan lebih banyak lingkaran terbuka.

Di mana roadmap cocok?

Roadmap publik adalah cara menutup lingkaran lebih awal: memberi tahu peminta bahwa permintaan mereka didengar, sebelum dirilis. Ini berguna, dan tidak menggantikan langkah terakhir. “Direncanakan” adalah janji tentang masa depan; “Dirilis” adalah fakta tentang masa kini. Jalankan roadmap publik dari issue yang sama, dengan satu label per kolom, sehingga permintaan yang sama bergerak dari direncanakan ke dirilis tanpa dimasukkan ulang di mana pun. Perpindahan ke dirilis adalah perubahan label (roadmap:shipped) yang tidak dilakukan siapa pun untuk Anda saat entri disetujui, jadi lakukan di tinjauan yang sama.

FAQ

Apa saja empat langkah lingkaran umpan balik pelanggan? Mengumpulkan, memutuskan, merilis, memberi tahu. Lingkarannya terbuka hingga langkah keempat terjadi. Kebanyakan kerangka kerja menambahkan langkah analisis dan prioritisasi di tengah; itu adalah penyempurnaan dari “memutuskan”, dan tidak ada satu pun yang menutup apa pun.

Haruskah pelanggan diberi tahu ketika permintaan ditolak? Ya, dan itu pesan yang paling diabaikan dalam lingkaran. “Kami tidak akan melakukan ini, dan ini alasannya” yang jelas mengakhiri penantian. Kesunyian membiarkan lingkaran terbuka selamanya dan pelanggan terus memeriksa.

Bagaimana menutup lingkaran berbeda dari mengumumkan fitur? Pengumuman pergi ke semua orang. Menutup lingkaran adalah balasan kepada orang-orang yang meminta, di kanal tempat mereka meminta. Lakukan keduanya; ini pesan yang berbeda untuk pembaca yang berbeda.

Bagaimana jika peminta tidak ada di GitHub? Kebanyakan memang tidak, dan itu tidak masalah. Widget terus menampilkan status dari apa yang mereka kirim, termasuk entri yang dirilis dan tautannya, jadi mereka tidak butuh apa pun selain halaman tempat mereka menulis. Komentar di issue ditujukan untuk orang yang bisa melihat repositori.

Apakah loop ini bekerja di GitLab atau Bitbucket, bukan GitHub? Widget dan changelog bekerja; komentar otomatis di langkah lima belum, untuk saat ini. Tim di GitLab atau Bitbucket tetap mendapat setiap pengiriman, tetap mencatatnya sebagai issue, dan tetap menampilkan status ke peminta di widget, tapi menutup loop spesifik itu kembali ke issue itu sendiri adalah langkah yang Anda lakukan secara manual sampai integrasi itu ada.

Klaim teknis dalam artikel ini belum ditinjau secara independen. Jika ada yang keliru, beri tahu kami dan kami akan memperbaikinya.

Terkait di changeloop: Dokumentasi developer, Contoh changelog