- PRD (Product Requirements Document): Es el documento que define el qué y el porqué. Describe el problema que estás resolviendo, las funcionalidades que el usuario necesita y cómo se medirá el éxito. Es el mapa del producto.
- ADR (Architecture Decision Record): Es el documento que define el cómo. Captura una decisión de diseño técnica importante, el contexto en el que se tomó, las alternativas consideradas y las consecuencias de esa elección. Es el diario de bitácora técnico.
| Característica | PRD (Product Requirements Document) | ADR (Architecture Decision Record) |
|---|---|---|
| Enfoque | Funcionalidad y valor de negocio. | Implementación técnica y arquitectura. |
| Audiencia | Product Managers, Stakeholders, Diseñadores y Devs. | Arquitectos de software y Desarrolladores. |
| Responde a | ¿Qué vamos a construir? ¿Para quién es? | ¿Por qué elegimos esta tecnología o patrón? |
| Ciclo de Vida | Evoluciona hasta que la funcionalidad se lanza. | Es inmutable; si la decisión cambia, se crea un nuevo ADR que "supera" al anterior. |
| Ejemplo | "El sistema debe permitir pagos con tarjeta y PayPal". | "Usaremos Stripe sobre PayPal debido a su API de suscripciones y soporte en Go". |
Se escribe antes de que comience el desarrollo pesado. Siguiendo tus propias instrucciones para generar PRDs, este debe incluir:
- User Stories: ¿Qué quiere lograr el usuario?
- Requerimientos Funcionales: La lista de "debe hacer".
- Métricas de éxito: ¿Cómo sabemos si funcionó?
Se escribe cuando el equipo de ingeniería llega a una encrucijada técnica. Por ejemplo:
- ¿Usamos Microservicios o Monolito?
- ¿Elegimos PostgreSQL o MongoDB para el LegalTech en el que estás trabajando?
- ¿Por qué decidimos usar tRPC en lugar de REST?
Imagina que estás construyendo tu aplicación de LegalTech para Perú:
- El PRD dirá: "El sistema debe permitir que los abogados carguen expedientes pesados y los busquen por palabras clave".
- El ADR dirá: "Usaremos MinIO para el almacenamiento de archivos (S3 compatible) y Elasticsearch para la indexación, porque necesitamos búsquedas full-text rápidas en español".
En resumen: El PRD guía la visión del producto, mientras que el ADR documenta la sabiduría técnica y las razones detrás de la estructura de tu código para que, en dos años, el "tú del futuro" (o un junior) entienda por qué tomaste esas decisiones.