Product Requirement Document - Seri Dokumentasi Produk

Product Requirement Document

Apa itu Product Requirement Document?

Kebenaran yang canggung adalah bahwa sebagian besar proyek gagal karena kurangnya pengumpulan persyaratan dan dokumentasi persyaratan yang tepat. Tim produk terkadang akhirnya bekerja dalam lingkaran mencoba membangun produk yang tidak pernah dipahami atau dikomunikasikan dengan jelas. Ini tidak hanya menghasilkan produk yang tidak layak tetapi juga membuang-buang waktu dan sumber daya yang dapat disalurkan untuk membangun produk yang menarik.

Masalah inilah yang dikurangi oleh Product Requirement Document. Product Requirement Document menyoroti dan mengomunikasikan detail ide/proyek seperti mengapa, dan apa, dan menginformasikan tim pada konteks yang berbeda di sekitar sebuah ide.

Sementara  pernyataan kerja  atau  rencana proyek  akan menggali secara spesifik  bagaimana  Anda akan membangun sebuah produk, Product Requirement Document lebih fokus pada  apa  yang sedang dibuat.

Menurut Marty Cagan, tujuan dokumen persyaratan produk (Product Requirement Document) adalah untuk mengartikulasikan tujuan, fitur, fungsionalitas, dan perilaku produk dengan jelas dan tidak ambigu.

Baca Juga: Manajer Produk vs Manajer Pemasaran Produk vs Pemilik Produk

Mengapa Anda membutuhkan Product Requirement Document?

Product Requirement Document berfungsi sebagai kompas, memberikan jalur yang jelas menuju tujuan produk sekaligus menciptakan pemahaman bersama di antara tim bisnis dan teknis.

Ini adalah "halaman arahan" untuk apa yang Anda coba bangun karena Anda akan selalu merujuknya untuk mendapatkan konteks di sekitar proyek bahkan selama tahap pengembangan. Memiliki sesuatu yang merupakan lokasi tujuan utama menghemat waktu anggota tim Anda dalam mengakses informasi ini dan memberi mereka pandangan singkat setiap kali mereka membutuhkannya.

Baca Juga: Seberapa pentingkah Menciptakan Inovasi Penemuan Produk?

Apa saja praktik terbaik Product Requirement Document?

• Jaga agar persyaratan tetap ramping:

Perlakukan Product Requirement Document Anda seperti "satu halaman" dalam hal panjangnya. Ini tidak berarti bahwa Anda harus mencoba memasukkannya ke dalam sebuah halaman. Ini mungkin tidak berhasil. Tidak ada eksekutif/pemangku kepentingan yang ingin membaca dokumen panjang lainnya, banyak yang harus mereka tangani. Anda dapat mencapai dokumen persyaratan lean dengan hanya menyertakan informasi penting yang perlu ada di dokumen dan menambahkan add-on lain sebagai tautan, sematan, atau addendum.

Misalnya, ini membantu untuk menautkan (referensi) sumber daya seperti desain antarmuka pengguna Anda dan wawancara pelanggan daripada menampilkannya di dokumen. Inti dari Product Requirement Document adalah untuk dapat membawa audiens Anda dalam perjalanan tentang produk/fitur dan dapat memahaminya. Cobalah untuk mempersingkat perjalanan.

• Jadikan pengumpulan persyaratan sebagai kerja tim

Aspek terpenting dari semua ini adalah melibatkan semua orang. Ini membantu untuk membawa bersama pemangku kepentingan utama seperti Teknik dan Desain yang akan menjadi penting dalam membangun produk. Bagikan halaman dengan tim Anda dan dapatkan umpan balik sebelum menyampaikan ide tersebut kepada pemangku kepentingan lainnya.

Carilah umpan balik, komentar, pertanyaan, dan dorong orang lain untuk berkontribusi. Anda harus berhati-hati dengan ide Anda jika tidak ada yang memberikan umpan balik atau memberikan komentar. Bisa jadi ide Anda kabur dan tidak ada yang mengerti atau mereka menganggapnya biasa-biasa saja.

Pengumpulan persyaratan kolaboratif sangat penting untuk tim terdistribusi yang tidak sering mendapatkan kesempatan untuk mendiskusikan proyek secara langsung.

• Tetap Agile saat membuat Product Requirement Document Anda

Ingatlah untuk gesit dalam evolusi persyaratan Anda untuk sebuah proyek. Tidak apa-apa untuk memperbarui cerita pengguna saat tim membangun, mengirim, dan mendapat umpan balik. Selalu pastikan untuk memvalidasi ide Anda melalui penemuan produk dan wawasan pasar dan hanya mengirimkan fitur/produk yang dibutuhkan pengguna Anda meskipun ini berarti mengirimkan lebih sedikit fitur.

Memperlakukan Product Requirement Document sebagai dokumen statis adalah jebakan yang mudah dimasuki oleh banyak PM (termasuk saya sendiri). Karena kebutuhan pengguna Anda akan terus berkembang, produk Anda harus selalu diposisikan ulang untuk memenuhi kebutuhan mereka. Ini juga harus diterjemahkan ke dokumen kebutuhan Anda. Merasa nyaman membuat pembaruan pada Product Requirement Document dan memastikan untuk memperbarui tim Anda tentang perkembangan baru.

Baca Juga: Metrik Penting Dalam Pemasaran Produk

Apa yang harus Anda sertakan dalam Product Requirement Document Anda

Ini bukan daftar yang lengkap dan Anda dapat membuat daftar Anda berdasarkan masalah yang Anda coba pecahkan dan kerumitan yang terlibat. Tapi daftar di bawah ini menunjukkan template umum untuk diikuti.

• Tujuan / Masalah:

Ini pada dasarnya adalah "siapa", "apa", dan "mengapa" dari produk atau fitur yang sedang dibangun. Penting untuk mengartikulasikan ini dengan jelas karena membantu audiens dokumen lainnya melihat apakah ada kebutuhan untuk produk sama sekali dan apakah itu prioritas.

Ingatlah bahwa Product Requirement Document adalah untuk membantu menyampaikan ide Anda kepada anggota tim dan berfungsi sebagai titik referensi selama proses berlangsung. Karena inilah alasannya, maka Anda perlu membuktikan fakta-fakta ini.

• Metrik Sukses

Seperti apa kesuksesan itu - Bagaimana kita tahu bahwa kita telah memecahkan masalah ini? Apakah kita mencapai apa yang ingin kita pecahkan? Bagaimana kami bisa tahu? Jawab pertanyaan-pertanyaan ini dan tuliskan di bagian ini.

Kriteria ini menjadi sangat penting di seluruh proyek karena membantu Anda membuat keputusan dan memprioritaskan. Apakah fitur X meningkatkan peluang untuk mencapai tujuan yang Anda tetapkan? Jika tidak, prioritaskan kembali.

Idealnya, ini harus menjadi metrik khusus, dengan tujuan yang ditentukan, yang dapat dengan mudah diukur. Itu harus langsung terhubung ke KPI tim Anda dan didasarkan pada ukuran peluang, dan nilai yang akan ditambahkan ke pengguna.

• Asumsi

Ini bisa berupa asumsi teknis, bisnis, atau terkait pengguna.

• Fitur Produk

Ini adalah fungsi atau fitur yang akan membentuk produk. Dengan definisi sukses yang tepat, menjadi mudah untuk memprioritaskan fitur dengan prioritas tinggi (yang paling membantu kami mencapai tujuan kami), ke fitur dengan prioritas lebih rendah. Daftar ini juga membantu untuk menyampaikan ide dari perspektif produk kepada para pemangku kepentingan. Idealnya, ini harus didukung dengan desain antarmuka pengguna atau sketsa fitur.

• Kendala / Ketergantungan

Ini adalah dua hal berbeda yang perlu digarisbawahi. Kendala bisa berupa perantara antara aplikasi dan pelanggan (Pikirkan produk pengiriman makanan, ada aplikasi, pengendara, dan pelanggan). Dalam hal ini, kesenangan pengguna sebagian besar terkait dengan layanan pengendara. Hubungan perantara ini menjadi kendala bagi produk tersebut dalam memberikan layanan yang menyenangkan kepada pelanggan.

Ketergantungan dapat datang dalam bentuk lisensi, kepatuhan terhadap peraturan, dan kemitraan. Pada dasarnya, hal-hal yang diperlukan untuk menjalankan bisnis/membangun fitur.

• Desain UI

Ini tidak harus berupa desain dengan ketelitian tinggi. Bahkan, yang terbaik adalah sketsa. Hal ini untuk menghindari investasi terlalu banyak upaya dalam merancang produk yang Anda belum divalidasi atau mendapat persetujuan dari pemangku kepentingan Anda. Dalam desain, pastikan untuk menunjukkan fitur dan bagaimana memadukannya dengan produk yang ada (untuk produk yang sudah ada). Cara yang baik untuk mendukung desain Anda adalah dengan menyertakan alur pengguna - seperti apa perjalanan pengguna nantinya.

• Pertanyaan-pertanyaan terbuka

Di bagian ini, buat daftar pertanyaan yang belum Anda temukan jawabannya. Hal ini membantu untuk mendorong keterlibatan dan pertimbangan pada ide saat melemparnya. Ini juga menunjukkan bahwa Anda dapat memikirkan trade-off tentang produk. Tidak apa-apa untuk tidak memiliki semua jawaban tetapi pastikan untuk bersandar pada pemangku kepentingan yang merupakan pakar domain untuk membantu Anda.

• Keluar dari ruang lingkup

Ini dapat mencakup fitur yang bukan ide Anda dan ide masa depan yang dapat dikembangkan lebih lanjut ke dalamnya.

Baca Juga: Pengalaman Pengguna Gamified - Membuat pengguna Anda meminta lebih banyak

Contoh Product Requirement Document.

Untuk pendekatan yang lebih praktis, kami akan menggunakan startup pengiriman makanan sebut saja, Byke (Ingat Byke dari artikel sebelumnya Cara Membuat Strategi Produk?) untuk membuat dokumen persyaratan untuk dasbor pedagang.

Byke berencana untuk memperluas layanannya dan telah menugaskan tim Produk untuk melakukan penemuan produk dan pelanggan serta menyarankan layanan lain yang dapat mereka jelajahi.

Tim Produk dalam penelitian mereka menemukan hal berikut (dalam urutan prioritas):

• Restoran berjuang dengan memenuhi pesanan.
• Mengelola persediaan adalah rasa sakit.
• Restoran tidak dapat melacak penjualan dan akhirnya kehilangan uang dalam prosesnya.
• Menskalakan bisnis restoran sama sulitnya dengan menjalankan startup.

Berdasarkan hasil penelitian mereka, tim mengusulkan agar Byke membangun solusi sistem operasi restoran (pikirkan Roti panggang ,) di samping layanan yang ada untuk membantu pemilik restoran menjalankan bisnis yang lancar.

Product Requirement Document yang disematkan di bawah ini menunjukkan upaya pertama tim Produk dalam mempresentasikan ide tersebut kepada pemangku kepentingan.

Di akhir sesi tinjauan ini, setiap tim mendapat informasi yang baik tentang produk, dan masalah yang akan dipecahkannya. Tim masing-masing juga dapat memberikan konteks pada pertanyaan terbuka yang dimiliki tim Produk dan menghapus beberapa ketidakpastian yang dihadapi dalam pelingkupan produk dan brainstorming.

Dalam skenario di mana ada umpan balik yang memerlukan implementasi lebih lanjut, tim Produk harus memprioritaskannya dan memastikan bahwa penyelarasan dan persetujuan yang tepat diperoleh saat ini masih menjadi prioritas bagi semua orang.

Baca Juga: Seri Dokumentasi Produk - Visi Produk - Strategi Produk - Roadmap Produk

Menutup Pemikiran

Meskipun akan selalu ada masalah pengguna untuk dipecahkan, Product Requirement Document ada untuk memastikan bahwa Anda dapat dengan jelas mengkomunikasikan solusi kepada audiens Anda dan berada dalam posisi yang lebih baik untuk memecahkan masalah pengguna Anda.

Benar-benar tidak ada metode pasti untuk membuat Dokumen Persyaratan Produk yang menarik tetapi memahami kebutuhan pengguna Anda, mengumpulkan tim Anda di sekitarnya akan sangat membantu dalam mengajukan, mempertahankan Product Requirement Document Anda dengan sukses, dan menyelaraskan pemangku kepentingan dengannya. https://www.haris.eu.org/