Cara melacak permintaan fitur tanpa kehilangannya

Pelacakan permintaan fitur hampir selalu gagal dengan salah satu dari dua cara. Entah permintaan tidak punya tempat tujuan, sehingga hidup di kotak masuk dan thread Slack di mana dilupakan satu per satu, atau punya tempat tujuan yang tak pernah dilihat lagi, sehingga dilupakan bersamaan. Sistem yang berfungsi harus tahan terhadap kedua kegagalan itu: butuh satu tempat di mana setiap permintaan mendarat, dan alasan untuk membuka tempat itu lagi bulan depan.

Dari mana sebenarnya permintaan fitur berasal?

Dari lebih banyak kanal dari yang diperhitungkan kebanyakan sistem pelacakan. Tiket dukungan yang menyertakan “akan bagus kalau”. Komentar di roadmap publik. Panggilan penjualan di mana calon pelanggan menyebutkan satu hal yang menghalangi kesepakatan. Widget di dalam produk. Setiap kanal punya pemiliknya sendiri dan alatnya sendiri, dan justru karena itulah permintaan tersebar: antrean tiket dukungan dan backlog tim produk jarang menjadi sistem yang sama, dan permintaan yang hanya mencapai salah satunya, dalam praktiknya, hanya mencapai satu departemen.

Satu formulir intake untuk setiap kanal tidak berhasil, karena tidak ada yang mengadopsinya. Yang berhasil adalah satu tujuan yang menjadi muara setiap kanal, meskipun perutean pada awalnya lima menit salin-tempel per hari sampai diotomatisasi.

Apa yang sebenarnya merusak pelacakan permintaan fitur?

Hampir selalu dua hal. Pertama, tujuan yang tidak ada: permintaan dijawab di kanal tempat kedatangannya dan tak pernah tercatat secara permanen di mana pun, sehingga permintaan yang sama dari tiga pelanggan berbeda terlihat seperti tiga jawaban terpisah yang tak berhubungan alih-alih satu sinyal. Kedua, lebih sering terjadi, tujuan yang penuh dan berhenti dibaca. Spreadsheet dengan 400 baris tanpa penyaringan bukan lagi sistem pelacakan; itu arsip yang kebetulan bisa ditulis.

Kegagalan kedua lebih berbahaya, karena terlihat seolah pelacakan berfungsi. Permintaan tercatat. Tidak ada yang terlihat rusak sampai seseorang bertanya “berapa banyak orang yang meminta X” dan jawaban jujurnya adalah “kami harus membaca semua 400 baris untuk mengetahuinya”.

Apa yang sebenarnya harus dicatat permintaan fitur?

Cukup untuk menjawab tiga pertanyaan nanti tanpa membaca ulang pesan asli: apa yang diminta, sedapat mungkin dengan kata-kata sendiri dari yang meminta; siapa yang meminta, dan cara menghubunginya jika jawabannya akhirnya “kami sudah membangunnya”; dan apa yang dibutuhkan untuk mengetahui apakah ini permintaan umum atau kasus satu kali. Kutipan langsung lebih berharga daripada parafrasa, karena parafrasa yang ditulis oleh siapa pun yang melakukan triase permintaan sudah membawa pembacaannya sendiri, dan justru pembacaan itulah yang tak bisa diperiksa orang kedua enam bulan kemudian.

Label mana yang layak dipakai?

Dua, dan menjawab pertanyaan berbeda. Label jenis memisahkan permintaan fitur dari laporan bug, karena keduanya butuh pemilik dan lini masa berbeda, dan mencampurnya dalam satu antrean membiarkan keluhan paling keras menggeser permintaan. Label prioritas, dijaga tetap pada set kecil seperti low, medium, dan high, memisahkan “menghalangi seseorang memakai produk” dari “akan bagus”, karena keduanya pantas mendapat waktu respons yang sangat berbeda dan tak satu pun seharusnya mewarisi ritme yang lain. Menerapkan label jenis dengan benar mengasumsikan permintaan itu adalah seperti yang diklaimnya; ketika permintaan fitur sebenarnya adalah laporan bug membahas kasus di mana kata-kata pelanggan sendiri mengarahkan label itu ke arah yang salah.

Triase otomatis bisa menerapkan keduanya saat permintaan tiba. Di changeloop, kiriman widget mendapat label feature-request atau bug dan label priority:low|medium|high dalam langkah yang sama, ditambah tag from-widget sehingga sumbernya terlihat tanpa membuka itemnya. Itu cukup untuk menyaring backlog dalam semenit alih-alih semalam: tunjukkan setiap permintaan fitur berprioritas tinggi dari widget bulan ini.

Label ketiga layak dipakai begitu ada roadmap publik: status yang bisa dicek sendiri oleh yang meminta. Roadmap publik membahas status planned, building, dan shipped secara lengkap; singkatnya, label itu mengubah antrean privat menjadi sesuatu yang bisa dicek yang meminta tanpa bertanya lagi.

Bagaimana memutuskan apa yang dibangun selanjutnya?

Kelompokkan sebelum menghitung. Sepuluh permintaan yang diformulasikan berbeda untuk kapabilitas mendasar yang sama terbaca sebagai sepuluh baris tersebar di spreadsheet, dan sebagai sinyal kuat begitu dikelompokkan, dan pengelompokan itu biasanya langkah yang hilang, bukan penghitungannya. Hitungan mentah tanpa pengelompokan cenderung menghargai fitur dengan nama paling menarik, bukan yang punya permintaan nyata terbanyak di baliknya.

Timbang berdasarkan siapa yang meminta, bukan hanya berapa banyak yang meminta. Permintaan dari akun yang mendekati perpanjangan membawa urgensi berbeda dari permintaan yang sama dari pendaftaran uji coba, dan sistem pelacakan yang membuang konteks itu demi hitungan telanjang mengoptimalkan angka yang paling mudah dihitung, bukan yang paling berguna.

Setiap keputusan di sini juga menghasilkan permintaan yang kalah, dan itu juga pantas mendapat balasan; cara menolak permintaan fitur membahas apa yang harus dikatakan pada yang permintaannya tidak lolos. Mengelompokkan dan menimbang hanya separuh dari “apa yang dibangun selanjutnya”; memprioritaskan permintaan fitur membahas kerangka sesungguhnya, RICE, penimbangan pendapatan, dan hitungan mentah, serta di mana masing-masing gagal.

Bagaimana menutup lingkaran setelah sesuatu dirilis?

Ini langkah yang paling sering dilewatkan sistem pelacakan, dan yang benar-benar disadari yang meminta. Menutup lingkaran umpan balik dengan pelanggan membahas mekanismenya secara lengkap; yang relevan di sini adalah menutup lingkaran hanya berfungsi jika permintaan asli tetap terhubung dengan yang memintanya. Templat permintaan fitur yang dibangun dari issue GitHub, dengan identitas yang meminta melekat pada issue alih-alih terkubur dalam komentar, adalah yang membuat notifikasi “dirilis” otomatis mungkin terjadi alih-alih yang harus diingat seseorang untuk dikirim. Templat permintaan fitur menunjukkan templat konkretnya dan untuk apa setiap kolom.

FAQ

Alat apa yang harus saya pakai untuk melacak permintaan fitur? Apa yang sudah dicek tim setiap hari mengalahkan alat khusus apa pun yang tak dibuka siapa pun. Pelacak issue GitHub bekerja baik jika engineering sudah hidup di sana; papan ringan bekerja baik jika produk hidup di sana. Alatnya kurang penting dibanding apakah dibuka lagi.

Bagaimana mencegah permintaan fitur terduplikasi? Kelompokkan berdasarkan kapabilitas mendasar sebelum melakukan triase berdasarkan kata-kata. Pencarian di antara permintaan yang ada sebelum membuat yang baru menangkap sebagian besar duplikat; sesi pengelompokan bulanan menangkap sisanya. Menggabung duplikat tanpa kehilangan suara asli membahas apa yang harus dilakukan dengan kata-kata itu begitu pengelompokan sendiri selesai, sehingga penggabungan tidak diam-diam mempersempit permintaan ke pengiriman mana pun yang tiba lebih dulu.

Haruskah setiap permintaan fitur mendapat balasan? Setiap permintaan harus mendapat konfirmasi, walau singkat, tapi tidak setiap permintaan butuh keputusan segera. Status yang terlihat, seperti label roadmap yang bisa dicek sendiri oleh yang meminta, menggantikan sebagian besar balasan individu yang seharusnya menjadi kewajiban tim.

Apa bedanya pelacakan permintaan dengan roadmap publik? Pelacakan adalah catatan internal dari setiap permintaan, termasuk yang tak akan pernah dirilis. Roadmap publik adalah subset yang secara publik dikomitmenkan tim, dengan status yang bisa dilihat yang meminta tanpa bertanya lagi.

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, Perbandingan alat changelog