Cómo escribir un PRD con IA (con una plantilla gratuita)

Para qué sirve realmente un PRD

Un PRD tiene dos lectores, y conviene escribir para ambos.

El primero es quien construye el producto. Necesita saber qué problema resuelve, para quién es, qué incluye la primera versión y qué deja fuera a propósito. Si tiene que volver a preguntarte algo cada tarde, el documento no está cumpliendo su función.

El segundo lector es quien revisa lo construido después. Puedes ser tú, un cofundador, un revisor o un auditor antes del lanzamiento. Esa persona necesita recorrer el documento línea por línea y decir «sí, esto está hecho» o «no, no lo está». Eso solo es posible si los requisitos están escritos como afirmaciones que pueden ser verdaderas o falsas sobre el producto en funcionamiento.

La mayoría de las plantillas de PRD sirven al primer lector. Muy pocas sirven al segundo, y por eso tantos productos salen con «lo que construimos» en lugar de «lo que acordamos».

Las secciones que importan

Un PRD útil para una primera versión tiene unas diez secciones breves:

1. Resumen. Nombre, responsable, estado y una frase de resumen. Si no puedes decir en dos líneas qué es y para quién, sigue pensando antes de escribir nada más.
2. Problema. El problema tal como lo vive el usuario, qué hace hoy en su lugar y cómo lo sabes. «Entrevistas con seis gerentes de clínica» es evidencia. «Todo el mundo odia esto» no lo es.
3. Usuario objetivo. Un usuario principal, el detonante que le hace buscar algo nuevo y para quién no es esto.
4. Trabajos por hacer. Entre tres y cinco, con las palabras del usuario: cuando pasa esto, quiero hacer aquello, para conseguir este resultado.
5. Alcance del MVP. Qué hace la primera versión, en frases que alguien podría ver funcionar.
6. Requisitos. Afirmaciones numeradas y verificables, con criterios de aceptación y una prioridad.
7. Métricas de éxito. Qué vas a medir, dónde y con qué objetivo, o un espacio en blanco donde todavía no lo tengas.
8. Fuera de alcance. Lo que esta versión no hace a propósito.
9. Preguntas abiertas. Cada una con un responsable y una fecha.
10. Aprobación. Quién dio el visto bueno, cuándo y cómo se proponen los cambios posteriores.

La sección seis es la que lo cambia todo, así que tiene su propio apartado a continuación.

Escribe requisitos que se puedan verificar

Un requisito es una única afirmación que puede ser verdadera o falsa sobre el producto construido. «Autenticación» es un tema. «Los usuarios pueden restablecer su contraseña por correo electrónico» es un requisito.

Cada requisito lleva cuatro cosas:

• Una clave, como REQ-001. Las claves son permanentes. Nunca se renumeran ni se reutilizan, porque las tareas, los commits y las auditorías harán referencia a ellas.
• Criterios de aceptación, que describen cómo alguien lo comprobaría en el sistema en funcionamiento. «Solicitar el restablecimiento, recibir el correo en menos de un minuto, definir una contraseña nueva e iniciar sesión con ella». Si no puedes escribir esto, el requisito no está terminado.
• Una prioridad. Para un equipo pequeño basta con MoSCoW: Must (imprescindible), Should (debería), Could (podría) y Won't (no se hará). Las escalas de cinco puntos invitan a discutir si algo es un 3 o un 4, cuando la única decisión que importa es si la primera versión puede salir sin ello.
• Un tipo: funcional (comportamiento), no funcional (velocidad, disponibilidad, accesibilidad) o restricción (una normativa, una plataforma o un presupuesto).

Dos reglas mantienen honesta la lista. Un compromiso por fila: si una frase contiene dos, divídela. Y un requisito sin criterios de aceptación se marca como incompleto, no se acepta en silencio.

Dónde ayuda la IA y dónde no

Este es el reparto de trabajo que funciona.

Dale al modelo el contexto, no las decisiones. Pega lo que sabes de verdad: el problema con tus palabras, las notas de conversaciones con clientes, las restricciones con las que trabajas y lo que ya has descartado. Un modelo que redacta a partir de una instrucción de una línea rellenará cada hueco con algo plausible, y lo plausible es aquí el enemigo, porque se lee como si estuviera acordado.

Deja que redacte la estructura y el primer borrador. Los modelos son buenos convirtiendo notas desordenadas en las diez secciones anteriores, detectando algo que falta en el apartado de fuera de alcance y reescribiendo «el sistema debe ser rápido» como algo medible. Son rápidos en las partes aburridas.

Deja las decisiones de alcance a una persona. Qué entra en la primera versión, qué queda fuera y qué significa «terminado» son decisiones de negocio. Un modelo inventará encantado un requisito porque suena sensato o estándar. Ese es justo el alcance que nadie acordó, y suele aparecer semanas después como trabajo que nadie pidió.

No dejes nunca que invente cifras. Si no conoces un objetivo, un precio o una fecha, déjalo en blanco. Una métrica de éxito inventada en un PRD acaba tratándose como un compromiso.

Revisa lo que extrajo frente a lo que leyó. Si usas un modelo para convertir un documento en prosa en una tabla de requisitos, pídele que cite la frase de la que sale cada requisito. Así puedes revisar cuarenta filas sin releer todo el documento, y cualquier fila sin frase de origen es un invento.

Un flujo de trabajo que puedes aplicar hoy

Si trabajas a mano con un asistente de uso general:

1. Copia la plantilla de PRD en tu editor.
2. Escribe tú mismo las secciones de problema y usuario objetivo. Son breves, y son lo que peor hace un modelo, porque solo tú sabes con quién has hablado.
3. Pega tus notas y pide al modelo que redacte los trabajos por hacer, el alcance del MVP y lo que queda fuera de alcance, usando solo lo que dicen las notas.
4. Pídele que proponga los requisitos en una tabla con clave, enunciado, criterios de aceptación, prioridad y tipo, citando la frase de origen de cada uno.
5. Borra todo lo que no tenga origen. Completa los criterios de aceptación que falten. Decide tú las prioridades.
6. Consigue la aprobación y congela esa versión. A partir de ahí, los cambios se proponen y se registran, no se editan en silencio.

Cómo hacerlo dentro de Atrix AI

Atrix AI ejecuta este mismo flujo dentro de tu espacio de trabajo, con las salvaguardas ya integradas.

En modo Develop, el agente lee lo que ya contiene tu proyecto: su resumen, su pitch y su cliente objetivo (incluidas las notas de una idea que hayas convertido en ese proyecto) y los documentos que tiene. Escribe el PRD como un documento dentro del proyecto, con problema, usuario objetivo, trabajos por hacer, alcance del MVP, métricas de éxito y fuera de alcance. Si se lo vuelves a pedir, actualiza ese mismo documento y guarda el texto anterior como una versión, en lugar de crear una copia nueva.

Después, Atrix puede extraer los requisitos del PRD como filas con clave, criterios de aceptación, una prioridad MoSCoW y un tipo, y cada una cita la frase de la que proviene. Si la cita de una fila no se encuentra en el documento, esa fila se descarta. Todo lo demás queda como propuesto, y nada cuenta hasta que una persona lo acepta. Cualquier requisito sin criterios de aceptación, salvo un Won't, se señala, y los requisitos no se pueden congelar hasta que todos los tengan y no quede ninguno pendiente de aceptar.

Los requisitos aceptados se pueden dividir en tareas del backlog, cada una con la clave del requisito al que responde, de modo que tu gestión de proyectos siga vinculada a lo acordado. Cuando pasas el desarrollo a un agente de programación, el paquete de traspaso incluye los documentos y las claves de los requisitos, y pide que las claves se citen en los commits.

Eso es lo que hace posible el último paso. Puedes congelar los requisitos aceptados como línea base, y la auditoría de requisitos muestra, para cada uno, si existe trabajo, si está en curso o si está terminado, y qué requisitos cambiaron o se descartaron después de la aprobación. El informe se calcula a partir de tus registros, no de la opinión de un modelo. No lee tu código; te dice si el trabajo registrado contra cada requisito acordado está terminado.

Extraer los requisitos y dividirlos en tareas consume una ejecución de IA cada uno, así que las cinco ejecuciones al mes del plan gratuito cubren de sobra un primer PRD.

Una lista de comprobación breve antes de dar el PRD por terminado

• ¿Podría alguien ajeno al equipo construir la primera versión a partir de él sin preguntarte?
• ¿Tiene criterios de aceptación cada requisito Must?
• ¿Es cada requisito una única afirmación que puede ser verdadera o falsa?
• ¿Está por escrito lo que queda fuera de alcance?
• ¿Tiene cada pregunta abierta un responsable y una fecha?
• ¿Lo ha aprobado alguien y está guardada esa versión?

Si la respuesta a las seis es sí, tienes un PRD que sirve a sus dos lectores. Empieza con la plantilla gratuita, o deja que el agente lo redacte y dedica tu tiempo a las decisiones.