Memprioritaskan permintaan fitur yang menumpuk

Melacak permintaan fitur menyelesaikan soal di mana mereka hidup. Itu tidak menyelesaikan mana yang jalan lebih dulu, dan pertanyaan kedua itulah yang benar-benar membuat tim tersendat. Backlog tiga ratus permintaan, yang sudah dikelompokkan dan dilabeli, tetap butuh aturan keputusan, karena “bangun yang paling banyak diminta” hanya berhasil sampai dua permintaan berdekatan dan yang ketiga punya pendukung yang paling ribut, yang terjadi hampir setiap minggu. Kerangka di bawah ini bukan jawaban yang saling bersaing untuk pertanyaan yang sama. Masing-masing cocok untuk jenis permintaan berbeda, dan memakai satu saja untuk semuanya biasanya adalah kesalahan sebenarnya.

Apa yang membuat memprioritaskan permintaan fitur berbeda dari memprioritaskan roadmap?

Keputusan roadmap dimulai dari strategi dan bertanya apa yang harus dibangun. Keputusan permintaan fitur dimulai dari permintaan yang sudah ada dan bertanya apakah perlu ditindaklanjuti, dan keduanya cukup sering menarik ke arah berbeda sehingga sebuah permintaan bisa punya permintaan tinggi dan tetap salah untuk dibangun, atau punya permintaan rendah dan tetap layak karena membuka akun strategis. Memperlakukan setiap permintaan sebagai suara roadmap melewatkan pemeriksaan itu.

Apa itu RICE, dan apakah berhasil untuk permintaan fitur?

RICE menilai sebuah ide berdasarkan jangkauan, dampak, keyakinan, dan upaya, lalu membagi tiga yang pertama dengan yang keempat untuk mendapatkan angka yang bisa dibandingkan. Ini dibuat untuk ide roadmap yang sudah dipercaya tim, di mana bagian sulitnya adalah membandingkan taruhan yang berbeda satu sama lain. Permintaan fitur sudah datang dengan angka jangkauan, hitungan orang yang meminta, yang lebih konkret daripada jangkauan yang biasanya dimiliki ide roadmap yang baru. Di mana RICE menjadi tegang dengan sebuah permintaan adalah keyakinan dan dampak: tim bisa yakin sebuah permintaan itu nyata dan tetap tidak punya dasar seberapa besar itu akan menggerakkan metrik, karena “dampak” untuk permintaan yang sudah punya nama dan jejak pengguna nyata adalah jenis estimasi yang berbeda dari dampak untuk ide yang belum pernah dilihat siapa pun di luar ruangan.

Gunakan RICE untuk permintaan yang benar-benar dipertimbangkan dan belum diputuskan. Jangan terapkan pada setiap permintaan yang masuk; upaya penilaian hanya sepadan untuk yang cukup dekat sehingga butuh pemecah seri.

Haruskah ditimbang berdasarkan pendapatan, atau berdasarkan siapa yang meminta?

Berdasarkan siapa yang meminta, tapi tidak hanya pendapatan. Akun yang mendekati perpanjangan, akun yang sudah pernah eskalasi, dan akun yang permintaannya membuka kesepakatan yang sedang berjalan membawa urgensi yang tidak ditangkap angka pendapatan datar saja, dan permintaan dari pendaftaran uji coba tetap bisa penting jika itu memblokir keputusan yang segera menjadi pendapatan. Penimbangan pendapatan adalah yang paling mudah dihitung dari semua ini, dan justru karena itu paling mudah dipercaya berlebihan: ia dengan tepat menghilangkan bising dari akun tanpa taruhan nyata, dan dengan mudah pula bisa menurunkan peringkat permintaan yang akan membawa akun jauh lebih besar yang masih ada di pipeline.

Peran apa yang sebenarnya dimainkan suara?

Sinyal murah dan berkelanjutan untuk permintaan yang sudah ada, dan cara yang buruk untuk menemukan permintaan mana yang seharusnya ada sejak awal. Hitungan suara hanya menjangkau pengguna yang sudah menemukan permintaan itu dan menganggapnya layak diklik, yang berarti total suara roadmap publik mencerminkan visibilitas sama besarnya dengan permintaan: permintaan lama di dekat puncak daftar terus mengumpulkan suara sebagian karena mudah ditemukan, dan permintaan yang lebih baru dan sama nyatanya mulai dari nol. Artikel roadmap publik berpendapat sebaiknya suara sama sekali tidak ditampilkan di roadmap. Perlakukan suara sebagai sinyal yang perlu dikelompokkan dan ditimbang berdasarkan kebaruan, bukan sebagai peringkat yang dibangun berurutan. Tiket dukungan vs. permintaan fitur membahas titik buta lain dalam jumlah suara: kesenjangan nyata bisa menghasilkan hampir tidak ada suara jika pengguna yang mengalaminya tidak pernah menemukan papannya, sementara tetap muncul dengan ribut di dukungan.

Kapan pelanggan paling ribut menang, dan apakah itu masalah?

Kadang-kadang, dan itu masalah hanya kalau tidak ada yang menyadarinya. Pelanggan yang sering eskalasi, menulis tiket rinci, atau punya jalur langsung ke seseorang di tim akan melihat permintaannya diperiksa lebih cepat daripada pelanggan yang lebih pendiam dengan permintaan yang sama validnya, dan proses prioritisasi yang tidak pernah memeriksanya akan secara sistematis mengutamakan yang paling gigih, bukan yang punya kasus paling kuat. Pelanggan yang ribut bukan masalah yang harus diperbaiki; permintaan mereka sering kali benar-benar penting. Perbaikannya adalah kebiasaan: tinjau backlog berdasarkan sumber secara berkala dan periksa apakah segelintir akun yang sama menjelaskan sebagian besar yang baru dirilis, dan tanyakan apakah itu sesuai dengan di mana permintaan nyata sebenarnya berada.

Bagaimana keputusan prioritisasi berubah menjadi balasan?

Setiap keputusan di sini menghasilkan pemenang dan pecundang, dan keduanya pantas mendapat balasan yang menyebutkan alasan sebenarnya, bukan sekadar perubahan status tanpa penjelasan. Cara menolak permintaan fitur membahas apa yang harus dikatakan pada permintaan yang kalah, dengan cara yang menjaga hubungan tetap utuh alih-alih terdengar seperti penolakan generik. Kerja pengelompokan dan pelabelan yang membuat semua ini mungkin dibahas di melacak permintaan fitur; prioritisasi hanya berhasil pada permintaan yang sudah tercatat dan dikelompokkan cukup baik untuk dibandingkan.

FAQ

Apa kerangka terbaik untuk memprioritaskan permintaan fitur? Tidak ada yang berdiri sendiri. Gunakan hitungan mentah untuk menemukan sinyal paling ribut, RICE untuk membandingkan daftar pendek kandidat serius, dan pemeriksaan pendapatan atau akun untuk menangkap kasus di mana permintaan diam dari akun strategis lebih berat daripada kelompok yang lebih ribut tapi kurang penting.

Haruskah permintaan fitur diprioritaskan sama seperti ide roadmap? Tidak. Ide roadmap dimulai dari strategi; permintaan fitur dimulai dari permintaan yang sudah ada. Menilai keduanya bersamaan membuat taruhan strategis yang beralasan baik tapi punya sedikit permintaan yang ada terus-menerus kalah melawan permintaan yang sekadar punya lebih banyak orang yang memintanya.

Apakah suara pada roadmap publik mencerminkan permintaan secara akurat? Hanya di antara orang yang sudah menemukan permintaan itu. Permintaan yang lebih lama dan lebih terlihat mengumpulkan suara lebih cepat, terlepas dari seberapa besar permintaan nyata di balik yang lebih baru, jadi perlakukan total suara sebagai sinyal, dikelompokkan dan ditimbang berdasarkan kebaruan, bukan sebagai peringkat yang dibangun berurutan.

Seberapa sering prioritas permintaan fitur harus dievaluasi ulang? Dalam siklus tetap, bukan hanya saat seseorang eskalasi. Peninjauan bulanan atau triwulanan yang mengelompokkan ulang permintaan dan memeriksa ulang penimbangan menangkap pergeseran, seperti segelintir akun yang mendominasi apa yang dirilis, yang tidak pernah muncul sendiri dari proses yang murni reaktif.

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