Com escriure un document de requisits de producte amb IA (plantilla gratuïta)

Un document de requisits de producte (PRD) és una descripció breu i en llenguatge clar de què estàs construint, per a qui és, què ha de fer i com sabràs que funciona. La IA fa que escriure'n un sigui molt més ràpid: li dones notes en brut i les converteix en apartats estructurats, històries d'usuari i casos límit. La teva feina és aportar les decisions que la IA no pot prendre —l'objectiu, l'abast i què es deixa fora— i revisar el que afegeix.

Aquesta guia explica què ha d'incloure un PRD, una manera pas a pas de redactar-ne un amb qualsevol assistent d'IA, prompts per a cada apartat i una plantilla per omplir que pots copiar.

Per a què serveix un PRD (i per a què no)

Un PRD respon quatre preguntes:

1. Per què construïm això? Quin problema, per a qui?
2. Què ha de fer en la primera versió?
3. Què no farà encara?
4. Com sabrem que ha funcionat?

No és un disseny tècnic. No diu quina base de dades o quin framework s'han d'utilitzar: això correspon a una especificació tècnica separada, si en calen. Tampoc és un resum de màrqueting ni un pla de negoci. Limitar el PRD al comportament del producte és el que el fa útil per a tothom que el llegeix: un dissenyador, un desenvolupador, una part interessada que el signa, o un creador d'apps amb IA que el converteix en codi.

Qui en necessita un

• Fundadors en solitari que volen evitar que l'abast creixi sense control.
• Equips petits que necessiten un únic lloc on hi hagi "el que hem acordat".
• Qui contracta un freelance o una agència, perquè un PRD clar rep pressupostos més clars. Consulta contractar un desenvolupador o construir amb IA.
• Qui construeix amb IA, perquè les històries d'usuari i la llista de dades d'un PRD fan millors prompts que una llista de desitjos sense estructura.

Què fa bé la IA i què no

El fracàs més habitual és el contrari de la penúltima fila: la IA omple amb confiança els buits amb suposicions plausibles sobre els teus usuaris. Tracta tot el que escriu sobre usuaris, la mida del mercat o el comportament com una pregunta per verificar, no com un fet.

Pas 1: aboca el que saps

Abans de fer cap prompt, escriu notes en brut. Els punts de llista estan bé. Cobreix:

• El problema, en una o dues frases, des del punt de vista de l'usuari.
• Qui el té. Sigues concret: "comptables freelance amb 10 a 40 clients", no "petites empreses".
• Què fan avui en lloc d'això (un full de càlcul, el correu, una eina que no els agrada).
• L'únic resultat que faria que la primera versió fos un èxit.
• Qualsevol cosa que ja saps que no faràs.
• Restriccions fermes: termini, pressupost, ha de funcionar en mòbils, ha d'integrar-se amb una eina que ja fas servir.

Si no has parlat amb ningú que tingui el problema, fes-ho primer. Com validar una idea d'app té una manera pràctica de fer-ho. Un PRD basat en suposicions és una suposició ben formatada.

Pas 2: demana a la IA un primer esborrany

Enganxa les teves notes i demana un esborrany amb una estructura fixa. Un prompt que funciona bé:

Aquestes són les meves notes sobre un producte. Converteix-les en un document de requisits de producte fent servir exactament aquests apartats: Resum, Problema, Usuaris, Objectius i mètriques d'èxit, Abast (dins / fora), Històries d'usuari amb criteris d'acceptació, Dades, Permisos, Casos límit, Preguntes obertes. Mantén-lo per sota de dues pàgines. No inventis fets sobre usuaris ni sobre el mercat: quan les meves notes no ho diguin, escriu la pregunta a Preguntes obertes.

L'última instrucció és important. Dir-li a la IA que enviï els desconeguts a "Preguntes obertes" en lloc d'omplir-los produeix un esborrany molt més honest.

Pas 3: ajusta cada apartat

Revisa l'esborrany apartat per apartat. Aquests prompts de seguiment ajuden:

Problema i usuaris

Reescriu l'enunciat del problema en una o dues frases des del punt de vista de l'usuari. Sense paraules de solució.

Si l'enunciat del problema menciona el teu producte, està descrivint una solució, no un problema.

Objectius i mètriques d'èxit

Suggereix tres mètriques d'èxit per a la primera versió que pugui mesurar el primer mes amb un nombre reduït d'usuaris. Per a cadascuna, digues com la mesuraria.

Tria-n'una o dues. "Vint comptables l'utilitzen cada setmana durant un mes" és mesurable. "Millorar la productivitat" no ho és.

Abast

Enumera tot el que hi ha en aquest PRD que es podria traslladar a una versió posterior sense trencar el flux principal.

Les eines d'IA tendeixen a afegir funcionalitats. Aquest prompt les fa fer el contrari. Sigues implacable: la majoria de PRD de primera versió són massa grans. Què és un MVP explica per què les primeres versions petites t'ensenyen més.

Històries d'usuari i criteris d'acceptació

Escriu cada requisit com una història d'usuari ("Com a [usuari], vull [acció] perquè [resultat]") amb dos a quatre criteris d'acceptació en format Donat / Quan / Llavors.

Els criteris d'acceptació són la llista de comprovació contra la qual provaràs més endavant. "Donada una franja reservada, quan un altre client veu el calendari, llavors la franja no es mostra" és comprovable. "La reserva funciona bé" no ho és.

Casos límit i permisos

Per a cada història d'usuari, enumera què passa amb dades buides, entrada no vàlida, una petició de xarxa lenta o fallida, i un usuari que no hauria de tenir accés.

Aquí és on la IA es guanya el sou. És ràpida detectant els estats buits i els forats de permisos que la gent sol oblidar.

Pas 4: revisa-ho com un escèptic

Llegeix tot una vegada més i comprova:

• Cada afirmació sobre usuaris ve de tu o de la recerca, no de la IA.
• L'apartat "fora" de l'abast és almenys tan llarg com el de "dins".
• Cada història d'usuari té criteris d'acceptació que algú pugui comprovar sense preguntar-te.
• L'apartat de dades enumera cada tipus de registre que guarda l'app i qui el pot veure.
• Les preguntes obertes tenen un responsable i una data.
• Res de tècnic s'ha colat, tret que sigui una restricció real ("ha de funcionar sense connexió" és un requisit; "utilitza Redis" no ho és).

Despràs, comparteix-lo amb una persona que farà servir o construirà el producte i pregunta-li què no queda clar. Les seves preguntes són els forats.

Plantilla de PRD per omplir

Copia això en un document i substitueix els claudàtors. Elimina els apartats que realment no s'apliquin.

Nom del producte: [nom] Responsable: [persona que pren les decisions] Estat: [esborrany / en revisió / acordat] — Última actualització: [data]

1. Resum

[Dues o tres frases: què és, per a qui i el resultat principal.]

2. Problema

[El problema des del punt de vista de l'usuari. Què fan avui i per què els fa mal.]

3. Usuaris

4. Objectius i mètriques d'èxit

• Objectiu: [el resultat que ha d'aconseguir la primera versió]
• Mètrica: [com ho mesuraràs i l'objectiu]
• No objectiu: [una cosa que la gent podria suposar, que aquesta versió no pretén fer]

5. Abast

A la primera versió:

• [funcionalitat]
• [funcionalitat]

No a la primera versió:

• [funcionalitat, i per què pot esperar]
• [funcionalitat, i per què pot esperar]

6. Històries d'usuari

Història 1: Com a [usuari], vull [acció] perquè [resultat].

• Donat [context], quan [acció], llavors [resultat].
• Donat [context], quan [acció], llavors [resultat].

Història 2: Com a [usuari], vull [acció] perquè [resultat].

• Donat [context], quan [acció], llavors [resultat].

7. Dades

8. Permisos

[Qui pot iniciar sessió, quins rols existeixen i què pot veure i canviar cada rol.]

9. Casos límit

• [Estat buit: què es mostra quan encara no hi ha dades]
• [Entrada no vàlida: què passa amb un correu incorrecte o un camp que falta]
• [Accés: què passa quan algú obre una pàgina a la qual no hauria d'accedir]

10. Integracions i restriccions

[Pagaments, correu, eines existents, terminis, pressupost, dispositius on ha de funcionar.]

11. Preguntes obertes

De PRD a prompts

Un bon PRD es converteix gairebé directament en prompts per a un creador d'apps amb IA:

• El resum, els usuaris i la taula de dades esdevenen el teu primer prompt.
• Cada història d'usuari esdevé un prompt de seguiment.
• Cada criteri d'acceptació esdevé una cosa que proves a la vista prèvia.
• La llista de "no a la primera versió" és el que encara no demanes.

Construir una història cada vegada i comprovar els seus criteris d'acceptació abans de passar a la següent és molt més fiable que enganxar tot el PRD i demanar-ho tot. Com escriure prompts per a creadors d'apps amb IA explica amb més detall la part dels prompts.

Errors habituals

• Escriure la solució com si fos el problema. "Els usuaris necessiten un tauler" és una solució. "Els propietaris no poden veure quines factures estan vençudes sense obrir-les una a una" és un problema.
• No tenir un apartat "fora de l'abast". Sense ell, cada conversa torna a obrir l'abast.
• Deixar que la IA inventi usuaris. Els perfils que la IA s'inventa semblen reals i no ho són.
• Mètriques que no pots mesurar. Si no tens manera de comptar-ho, no és una mètrica.
• No actualitzar-lo mai. Un PRD que ja no coincideix amb el que construeixes és pitjor que no tenir-ne cap. Mantén una data d'"última actualització" i canvia-la quan canviïn les decisions.

Usar un PRD amb Mythex

Si construeixes a Mythex, pots enganxar el teu PRD directament al xat. Començar en mode Plan encaixa bé amb un PRD: l'agent el llegeix, proposa un enfocament i una llista de passos que pots revisar en una pestanya de pla, i només comença a canviar fitxers quan prems Build. També pots desar les parts que sempre han d'aplicar-se —públic, marca, regles— com a coneixement del projecte perquè no les hagis de repetir a cada xat. Els documents del xat expliquen els modes Build, Plan i Ask, i les plantilles són una manera ràpida de veure com podria ser una primera versió abans de redactar el document complet.

Preguntes