Ketika permintaan fitur sebenarnya adalah laporan bug

“Bisakah Anda menambahkan pengaturan untuk menaikkan batas ekspor?” terbaca seperti permintaan fitur, dan kebanyakan sistem triase melabelinya begitu di tempat. Kadang memang begitu. Kadang ekspor gagal pada angka di bawah batas yang didokumentasikan karena sebuah bug, dan pelanggan, yang tidak bisa melihat kode, sudah mengarang solusi paling masuk akal yang bisa dia jelaskan: beri saya angka lebih besar dan mungkin akan berfungsi. Label mana yang layak dipakai membahas label jenis yang membagi backlog menjadi permintaan fitur dan bug; ini adalah kasus di mana kata-kata pelanggan sendiri mengarahkan label ke arah yang salah, dan biaya kesalahannya adalah pergeseran lambat menuju backlog penuh permintaan yang tak benar-benar diinginkan siapa pun begitu dilihat lebih dalam.

Seperti apa permintaan fitur yang sebenarnya adalah bug?

Menyebutkan cara mengakali alih-alih masalahnya. Permintaan fitur yang sungguhan biasanya menjelaskan hasil yang sama sekali tidak didukung produk: “biarkan saya menjadwalkan ini untuk nanti”, “tambahkan mode gelap”. Bug yang salah diklasifikasikan menjelaskan angka, ambang batas, atau perilaku spesifik yang terdengar seperti pengaturan yang hilang tapi sebenarnya adalah gejala: “naikkan timeout”, “tambahkan opsi retry”, “biarkan saya mengekspor lebih banyak baris sekaligus”. Tandanya adalah peminta mengusulkan implementasi, pengaturan, sakelar, override, alih-alih menjelaskan tujuan, karena dia sudah mencoba fitur seperti yang didokumentasikan dan itu tidak melakukan apa yang dikatakan dokumentasi seharusnya dilakukan.

Mengapa ini lebih penting dari kedengarannya?

Karena kedua antrean punya pemilik, lini masa, dan kriteria sukses berbeda, dan bug yang diarsipkan sebagai permintaan fitur diprioritaskan melawan permintaan fitur, bersaing untuk perhatian dengan celah produk sungguhan alih-alih diperbaiki sesuai lini masa yang layak diterima bug. Cara melacak permintaan fitur membahas mengapa mencampur bug dan fitur dalam satu antrean membiarkan keluhan paling keras menggeser permintaan sungguhan; permintaan fitur yang diam-diam adalah bug melakukan kerusakan sebaliknya, tetap di backlog produk mengumpulkan suara untuk “fitur” yang akan hilang begitu bug yang mendasarinya diperbaiki, yang membuang sinyal prioritas untuk siapa pun yang membaca backlog itu.

Bagaimana membedakannya ketika kata-kata pelanggan sendiri mengarah ke arah yang salah?

Tanyakan apa yang dia harapkan terjadi, bukan apa yang dia ingin Anda tambahkan. “Ekspornya terhenti di 500 baris dan saya butuh 2.000, bisakah Anda menaikkan batasnya” terdengar seperti permintaan fitur kenaikan batas sampai pertanyaan lanjutan, “apakah 500 batas yang didokumentasikan,” mengungkap bahwa angka yang didokumentasikan adalah 5.000 dan ekspor gagal lebih awal. Satu pertanyaan itu saja, apa yang diharapkan versus apa yang terjadi, melakukan sebagian besar pekerjaan penyortiran, karena permintaan fitur sungguhan tidak punya perilaku terdokumentasi yang tidak dipenuhinya; tidak ada yang bisa diharapkan karena kemampuannya belum ada.

Haruskah agen dukungan atau engineer yang memutuskan ini?

Agen dukungan melakukan pemeriksaan pertama, karena mereka melihat tiket lebih dulu, tapi labelnya seharusnya mudah diubah dan murah untuk salah, bukan keputusan sekali jadi yang mengunci item itu di antrean salah selamanya. Pemeriksaan kedua yang ringan, seorang engineer yang menyisir label “permintaan fitur” baru setiap minggu untuk apa pun yang berbau bug tersamar, menangkap yang tidak bisa dikenali agen dukungan tanpa konteks basis kode. Ini tidak perlu formal; lebih seperti pandangan lima menit daripada proses peninjauan.

Apakah menutup lingkaran berubah setelah bug sungguhan ditemukan?

Ya, dan itu memperbaiki pesan yang bisa Anda kirim. Menutup lingkaran umpan balik pelanggan membahas memberi tahu peminta saat permintaannya dirilis; bug yang diklasifikasikan ulang mendapat versi lebih baik dari pesan itu, karena “kami menemukan dan memperbaiki bug di balik ini” terdengar seperti kompetensi, sementara “kami membangun fitur yang Anda minta” hanya akan benar secara kebetulan, karena permintaan fitur sungguhan, batas ekspor yang benar-benar lebih tinggi, mungkin tidak pernah dibangun begitu bug hilang dan batas asli 5.000 baris sudah cukup.

Apa yang terjadi jika kesalahan klasifikasi tidak pernah tertangkap?

Backlog terisi permintaan yang terlihat seperti permintaan sungguhan tapi bukan, dan keputusan prioritas yang diambil melawan backlog itu mewarisi distorsinya. “Fitur” dengan empat puluh suara bisa jadi sebenarnya empat puluh orang yang mengalami bug yang sama, dan membangun permintaan literalnya, pengaturan untuk menaikkan batas yang sebenarnya tak pernah jadi kendalanya, memberikan kompleksitas yang tidak memperbaiki apa pun, sementara bug yang mendasari terus menghasilkan “permintaan fitur” baru dari pelanggan yang belum menemukan thread ini.

FAQ

Apakah layak menambahkan langkah formal untuk memeriksa setiap permintaan fitur terhadap bug yang diketahui? Bukan langkah formal, lebih ke kebiasaan: siapa pun yang mentriase permintaan fitur baru seharusnya bertanya “apakah perilaku terdokumentasi sudah mengklaim melakukan ini” sebelum menerapkan label, karena satu pertanyaan itu saja menangkap sebagian besar kesalahan klasifikasi tanpa menambah beban proses.

Bagaimana jika pelanggan tetap bersikeras itu permintaan fitur bahkan setelah bug ditemukan? Jelaskan apa yang Anda temukan dan mengapa pengaturan yang diusulkannya tidak akan diperlukan lagi begitu bug diperbaiki. Kebanyakan pelanggan meminta cara mengakali karena mereka berasumsi perbaikan sungguhan tidak tersedia, bukan karena mereka secara khusus menginginkan pengaturan itu.

Apakah item yang diklasifikasikan ulang kehilangan suara atau komentar yang dikumpulkannya sebagai permintaan fitur? Seharusnya tetap disimpan, terlihat, karena suara itu adalah bukti yang membawa penemuan bug sejak awal, dan menyembunyikan jejak itu membuat kesalahan klasifikasi yang sama lebih sulit tertangkap lain kali, pada tiket berbeda.

Bisakah ini terjadi sebaliknya, laporan bug yang sebenarnya adalah permintaan fitur? Lebih jarang, tapi bisa: “ini rusak” kadang berarti “ini tidak melakukan apa yang saya asumsikan akan dilakukannya,” yang merupakan kemampuan yang hilang, bukan cacat. Pertanyaan yang sama, apa yang diharapkan versus apa yang didokumentasikan, juga menyortir ke arah ini.

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