Banyak artikel dan buku tentang pekerjaan manajer produk, pertimbangkan masalah pemikiran strategis dan inovasi. Tentu saja, ini adalah dasarnya. Saya suka memperhatikan tugas rutin sehari-hari. Salah satu pekerjaan tersebut adalah dengan permintaan pengguna dan persyaratan produk.
Aksioma adalah bahwa permintaan untuk fungsionalitas dari pengguna bukan persyaratan produk. Permintaan dapat dengan mudah dibagi menjadi beberapa persyaratan, dan sebaliknya, satu persyaratan terdiri dari beberapa permintaan dari pengguna.
Mari kita lihat contoh sederhana - aplikasi Kalkulator. Anda telah menerima permintaan: tambahkan dukungan untuk sistem angka biner. Itu dapat menimbulkan beberapa persyaratan produk.
- Dukungan untuk operasi aritmatika.
- Dukungan konversi. Ini, kebetulan, akan mempengaruhi sistem desimal yang ada. Minimal diperlukan, untuk membuat tombol di antarmuka.
- Dukungan untuk operasi logis.
Seperti yang Anda lihat, pada awalnya pengguna tidak meminta dukungan, misalnya, hanya operasi logis. Permintaan untuk sistem angka secara keseluruhan, tetapi berisi beberapa persyaratan.
Mungkin ini semua sudah jelas. Tetapi proses bekerja dengan permintaan, jika Anda tidak menganggapnya penting, dapat menambah masalah. Jebakan pertama adalah menyimpan catatan di pelacak.
Jelas, memiliki satu sistem untuk permintaan pengguna dan persyaratan produk lebih baik daripada dua. Yah, setidaknya Anda hanya memiliki satu jendela terbuka. Penting untuk memiliki berbagai jenis objek untuk catatan. Contoh dari pengalaman saya. Saya mendapatkan tempat rata-rata dari dua hingga empat permintaan pengguna setiap hari kerja. Anda bisa bayangkan volumenya. Daftar dalam jaminan produk sangat besar. Memiliki dua jenis entri "persyaratan" dan "permintaan fungsionalitas" memungkinkan Anda untuk mengonfigurasi filter, mengumpulkan jaminan dari versi tertentu dan membuat tautan antara persyaratan dan permintaan untuk melacak riwayat. Selain itu, setelah mempertimbangkan permintaan, itu dapat ditutup dengan catatan "direncanakan untuk rilis" atau "tidak akan dilaksanakan".
Aspek kedua dari pekerjaan ini adalah secara langsung mengumpulkan persyaratan. Salah satu caranya adalah mendapatkannya melalui dukungan teknis. Ini adalah proses yang baik, karena itu Anda mendapatkan permintaan yang difilter yang mengandung esensi. Di sisi lain, itu buram bagi pengguna Anda. Banyak yang mungkin tidak melihat bahwa permintaan semacam itu, dan diakses berulang kali.
Oleh karena itu, vendor, terutama yang membuat solusi cloud, dapat menggunakan portal untuk menerima umpan balik.
Forum umpan balik ZendeskMetode ini meningkatkan visibilitas. Pisahkan permintaan dari persyaratan, karena sistemnya berbeda. Namun, sekarang pekerjaan Anda telah berlipat ganda. Anda perlu melihat posting, komentar, dan menjawab pertanyaan dengan cepat. Diam, terutama dalam komunikasi publik, tidak dapat diterima.
Tetapi hal yang paling sulit adalah sekarang Anda harus melacak dan menandai permintaan dengan cara tertentu untuk menandai permintaan yang direncanakan untuk implementasi, atau sebaliknya. Kembali ke contoh dengan kalkulator. Seperti pada portal, Anda perlu menandai permintaan untuk dukungan biner, jika Anda berencana untuk mengimplementasikan operasi aritmatika dan konversi saja, tanpa operasi logis.
Setiap manajer produk memilih solusinya sendiri. Tidak ada pendekatan universal. Namun, Anda harus selalu ingat bahwa bahkan proses sekecil itu seperti mengumpulkan dan memproses permintaan dari pengguna dapat mengandung banyak topik tersembunyi, dan mudah untuk menggandakan pekerjaan.