Cara Menulis Dokumen Keperluan Produk (PRD) dengan AI (Templat Percuma)

Dokumen keperluan produk (PRD) ialah penerangan ringkas dan dalam bahasa mudah tentang apa yang anda bina, untuk siapa, apa yang mesti dilakukannya, dan bagaimana anda tahu ia berfungsi. AI menjadikan penulisannya jauh lebih pantas: anda beri nota kasar dan ia menukarkannya kepada bahagian berstruktur, kisah pengguna dan kes tepi. Tugas anda ialah membekalkan keputusan yang AI tidak boleh buat — matlamat, skop dan perkara yang ditinggalkan — dan menyemak apa yang ditambahnya.

Panduan ini merangkumi apa yang sepatutnya ada dalam PRD, cara langkah demi langkah untuk mendraf satu dengan mana-mana pembantu AI, prompt untuk setiap bahagian, dan templat isi-isi yang boleh anda salin.

Untuk apa PRD (dan apa yang bukan)

PRD menjawab empat soalan:

1. Mengapa kita membina ini? Masalah apa, untuk siapa?
2. Apa yang mesti dilakukannya dalam versi pertama?
3. Apa yang tidak akan dilakukannya lagi?
4. Bagaimana kita tahu ia berjaya?

PRD bukan reka bentuk teknikal. Ia tidak menyatakan pangkalan data atau rangka kerja mana yang perlu digunakan — itu tergolong dalam spesifikasi teknikal berasingan, jika anda memerlukannya. Ia juga bukan ringkasan pemasaran atau pelan perniagaan. Dengan mengekalkan PRD pada gelagat produk, dokumen ini berguna kepada semua yang membacanya: pereka, pembangun, pihak berkepentingan yang meluluskan, atau pembina aplikasi AI yang menukarkannya menjadi kod.

Siapa yang memerlukannya

• Pengasas solo yang mahu menghentikan pertambahan skop sebelum ia bermula.
• Pasukan kecil yang memerlukan satu tempat untuk "apa yang telah dipersetujui".
• Sesiapa yang mengupah pekerja bebas atau agensi, kerana PRD yang jelas menghasilkan sebut harga yang lebih jelas. Lihat upah pembangun atau bina dengan AI.
• Sesiapa yang membina dengan AI, kerana senarai kisah pengguna dan senarai data dalam PRD menjadikan prompt yang lebih baik daripada senarai impian yang tidak berstruktur.

Apa yang AI pandai buat — dan apa yang tidak

Kegagalan paling biasa ialah baris kedua dari bawah yang terbalik: AI dengan yakin mengisi jurang dengan tekaan munasabah tentang pengguna anda. Anggap apa sahaja yang ditulisnya tentang pengguna, saiz pasaran atau gelagat sebagai soalan untuk disahkan, bukan fakta.

Langkah 1: Kumpulkan semua yang anda tahu

Sebelum anda beri sebarang prompt, tulis nota kasar. Poin peluru juga boleh. Liputi:

• Masalahnya, dalam satu atau dua ayat, dari sudut pandang pengguna.
• Siapa yang menghadapinya. Jadilah spesifik: "juru kira bebas dengan 10–40 pelanggan", bukan "perniagaan kecil".
• Apa yang mereka lakukan hari ini sebagai gantinya (hamparan, e-mel, alat yang mereka tidak suka).
• Satu hasil yang akan menjadikan versi pertama satu kejayaan.
• Apa-apa yang anda sudah tahu anda tidak akan buat.
• Kekangan keras: tarikh akhir, bajet, mesti berfungsi di telefon, mesti bersambung dengan alat yang anda sudah guna.

Jika anda belum bercakap dengan sesiapa yang menghadapi masalah itu, lakukan itu dahulu. Cara mengesahkan idea aplikasi menerangkan cara praktikal untuk melakukannya. PRD yang dibina atas tekaan ialah tekaan yang diformatkan dengan kemas.

Langkah 2: Minta AI untuk draf pertama

Tampal nota anda dan minta draf dalam struktur tetap. Prompt yang berkesan:

Berikut ialah nota saya tentang sebuah produk. Tukarkannya kepada dokumen keperluan produk menggunakan bahagian tepat ini: Ringkasan, Masalah, Pengguna, Matlamat dan metrik kejayaan, Skop (dalam / luar), Kisah pengguna dengan kriteria penerimaan, Data, Kebenaran, Kes tepi, Soalan terbuka. Pastikan di bawah dua halaman. Jangan reka fakta tentang pengguna atau pasaran — jika nota saya tidak menyatakannya, tulis soalan itu di bawah Soalan terbuka.

Arahan terakhir itu penting. Memberitahu AI supaya meletakkan perkara yang tidak diketahui dalam "Soalan terbuka" dan bukannya mengisinya menghasilkan draf yang jauh lebih jujur.

Langkah 3: Kemaskan setiap bahagian

Semak draf bahagian demi bahagian. Prompt susulan ini membantu:

Masalah dan pengguna

Tulis semula pernyataan masalah dalam satu atau dua ayat dari sudut pandang pengguna. Tiada perkataan penyelesaian.

Jika pernyataan masalah menyebut produk anda, ia sedang menerangkan penyelesaian, bukan masalah.

Matlamat dan metrik kejayaan

Cadangkan tiga metrik kejayaan untuk versi pertama yang boleh saya ukur dalam bulan pertama dengan bilangan pengguna yang kecil. Untuk setiap satu, nyatakan bagaimana saya akan mengukurnya.

Pilih satu atau dua. "Dua puluh juru kira menggunakannya setiap minggu selama sebulan" boleh diukur. "Tingkatkan produktiviti" tidak boleh.

Skop

Senaraikan semua yang ada dalam PRD ini yang boleh dipindahkan ke versi kemudian tanpa merosakkan aliran teras.

Alat AI cenderung menambah ciri. Prompt ini memaksanya melakukan sebaliknya. Bersikap tegas: kebanyakan PRD versi pertama terlalu besar. Apa itu MVP menerangkan mengapa versi pertama yang kecil mengajar anda lebih banyak.

Kisah pengguna dan kriteria penerimaan

Tulis setiap keperluan sebagai kisah pengguna ("Sebagai [pengguna], saya mahu [tindakan] supaya [hasil]") dengan dua hingga empat kriteria penerimaan dalam bentuk Given / When / Then.

Kriteria penerimaan ialah senarai semak yang akan anda uji nanti. "Diberi slot yang telah ditempah, apabila pelanggan lain melihat kalendar, maka slot itu tidak dipaparkan" boleh diuji. "Tempahan berfungsi dengan baik" tidak boleh.

Kes tepi dan kebenaran

Untuk setiap kisah pengguna, senaraikan apa yang berlaku dengan data kosong, input tidak sah, permintaan rangkaian yang perlahan atau gagal, dan pengguna yang tidak sepatutnya mempunyai akses.

Di sinilah AI benar-benar berguna. Ia pantas mengesan keadaan kosong dan jurang kebenaran yang sering terlepas pandang.

Langkah 4: Semak seperti orang yang skeptikal

Baca seluruh dokumen sekali lagi dan semak:

• Setiap dakwaan tentang pengguna datang daripada anda atau penyelidikan, bukan daripada AI.
• Skop "luar" sekurang-kurangnya sepanjang skop "dalam".
• Setiap kisah pengguna mempunyai kriteria penerimaan yang boleh diuji oleh seseorang tanpa bertanya kepada anda.
• Bahagian data menyenaraikan setiap jenis rekod yang disimpan aplikasi dan siapa yang boleh melihatnya.
• Soalan terbuka mempunyai pemilik dan tarikh.
• Tiada perkara teknikal yang menyelinap masuk kecuali ia kekangan sebenar ("mesti berfungsi secara luar talian" ialah keperluan; "guna Redis" bukan).

Kemudian kongsikan dengan satu orang yang akan menggunakan atau membina produk itu dan tanya apa yang tidak jelas. Soalan mereka ialah jurang yang perlu diisi.

Templat PRD isi-isi

Salin ini ke dalam dokumen dan gantikan kurungan. Padam mana-mana bahagian yang memang tidak berkenaan.

Nama produk: [nama] Pemilik: [orang yang bertanggungjawab untuk keputusan] Status: [draf / dalam semakan / dipersetujui] — Kemas kini terakhir: [tarikh]

1. Ringkasan

[Dua atau tiga ayat: apa ini, untuk siapa, dan hasil utama.]

2. Masalah

[Masalah dari sudut pandang pengguna. Apa yang mereka lakukan hari ini dan mengapa ia menyusahkan.]

3. Pengguna

4. Matlamat dan metrik kejayaan

• Matlamat: [hasil yang mesti dicapai oleh versi pertama]
• Metrik: [cara anda akan mengukurnya, dan sasarannya]
• Bukan matlamat: [sesuatu yang orang mungkin andaikan, yang versi ini tidak cuba lakukan]

5. Skop

Dalam versi pertama:

• [ciri]
• [ciri]

Tidak dalam versi pertama:

• [ciri, dan sebab ia boleh ditangguhkan]
• [ciri, dan sebab ia boleh ditangguhkan]

6. Kisah pengguna

Kisah 1: Sebagai [pengguna], saya mahu [tindakan] supaya [hasil].

• Diberi [konteks], apabila [tindakan], maka [hasil].
• Diberi [konteks], apabila [tindakan], maka [hasil].

Kisah 2: Sebagai [pengguna], saya mahu [tindakan] supaya [hasil].

• Diberi [konteks], apabila [tindakan], maka [hasil].

7. Data

8. Kebenaran

[Siapa boleh log masuk, peranan apa yang wujud, dan apa yang boleh dilihat dan diubah oleh setiap peranan.]

9. Kes tepi

• [Keadaan kosong: apa yang dipaparkan apabila belum ada data]
• [Input tidak sah: apa yang berlaku dengan e-mel salah atau medan yang hilang]
• [Akses: apa yang berlaku apabila seseorang membuka halaman yang tidak sepatutnya]

10. Integrasi dan kekangan

[Pembayaran, e-mel, alat sedia ada, tarikh akhir, bajet, peranti yang mesti berfungsi.]

11. Soalan terbuka

Daripada PRD kepada prompt

PRD yang baik hampir terus boleh ditukar kepada prompt untuk pembina aplikasi AI:

• Ringkasan, pengguna dan jadual data menjadi prompt pertama anda.
• Setiap kisah pengguna menjadi satu prompt susulan.
• Setiap kriteria penerimaan menjadi sesuatu yang anda uji dalam pratonton.
• Senarai "tidak dalam versi pertama" ialah apa yang anda belum minta.

Membina satu kisah pada satu masa dan menyemak kriteria penerimaannya sebelum meneruskan adalah jauh lebih boleh dipercayai daripada menampal keseluruhan PRD dan meminta semuanya. Cara menulis prompt untuk pembina aplikasi AI membincangkan bahagian prompt dengan lebih terperinci.

Kesilapan biasa

• Menulis penyelesaian sebagai masalah. "Pengguna perlukan papan pemuka" ialah penyelesaian. "Pemilik tidak dapat melihat invois yang tertunggak tanpa membuka setiap satu" ialah masalah.
• Tiada bahagian "luar skop". Tanpanya, setiap perbualan membuka semula skop.
• Membiarkan AI mereka-reka pengguna. Persona yang dicipta AI kelihatan nyata tetapi tidak wujud.
• Metrik yang anda tidak boleh ukur. Jika anda tiada cara untuk mengiranya, ia bukan metrik.
• Tidak pernah dikemas kini. PRD yang tidak lagi sepadan dengan apa yang anda bina lebih teruk daripada tiada langsung. Simpan tarikh "kemas kini terakhir" dan tukarkannya apabila keputusan berubah.

Menggunakan PRD dengan Mythex

Jika anda membina dalam Mythex, anda boleh tampal PRD anda terus ke dalam chat. Bermula dalam mod Plan sesuai untuk PRD: ejen membacanya, mencadangkan pendekatan dan senarai langkah yang boleh anda semak dalam tab rancangan, dan hanya mula menukar fail apabila anda tekan Build. Anda juga boleh menyimpan bahagian yang sepatutnya sentiasa terpakai — khalayak, jenama, peraturan — sebagai pengetahuan projek supaya anda tidak mengulanginya dalam setiap chat. Dokumentasi chat menerangkan mod Build, Plan dan Ask, dan templat ialah cara pantas untuk melihat rupa versi pertama sebelum anda menulis dokumen penuh.

Soalan lazim