---
title: El método
route: /es/method
lang: es
part_of: Onirion
version: "4.0"
date: 2026-09-22
author: Alexis Boyer
license: Todos los derechos reservados
one_line: "Un Product Builder lleva un producto desde una carpeta de documentos dispersos hasta algo que funciona en producción, front y back; Design, Frontend, Backend y API, Data, los accesos, la entrega y la revisión son los servicios compartidos que lo hacen posible."
layers:
  summary: /es/method
  complete_text: /es/complete.md
  markdown: /es/method.md
---

# El método

Un Product Builder lleva un producto desde una carpeta de documentos dispersos hasta algo que funciona en producción, front y back; Design, Frontend, Backend y API, Data, los accesos, la entrega y la revisión son los servicios compartidos que lo hacen posible.

Ser responsable del resultado no significa hacer todos los trabajos de especialista ni dirigir a todos los colaboradores. Los servicios horizontales son socios en la entrega, no una cola de tickets inconexos.

## El principio

*Figura — imagen, 3:2: Un responsable de capacidad entrega un patrón revisado, entre dos personas — lo horizontal al servicio de lo vertical, en un solo intercambio.*

### Las dos dimensiones

*Figure — lo vertical, un resultado de producto que un solo Product Builder lleva desde una carpeta de documentos hasta producción, cruza cinco servicios compartidos; cada uno devuelve algo utilizable, y juntos forman un producto que funciona en producción.*

**Vertical · Un resultado de producto.** Un Product Builder responsable de un producto, front y back, desde la primera carpeta de documentos hasta producción.

| Horizontal · servicio compartido | Lo que devuelve, utilizable |
| --- | --- |
| Design Ops | Un design system en el que se apoyan tanto el prototipo como el front: los componentes y sus estados, los tokens, las reglas de uso, lo que se puede extender y quién lo mantiene. |
| Frontend Ops | Un repositorio starter aprobado, en una versión identificada, con su arquitectura, sus convenciones de enrutamiento y de componentes, el patrón de cliente de API, los controles exigidos en una rama desplegable y una versión que un agente pueda releer antes de cada cambio. |
| Backend y API Ops | Un catálogo de API con ejemplos reales, las reglas de autenticación y de permisos, la forma de las peticiones, las respuestas y los errores, un entorno de pruebas con identidades seguras, una forma escrita de pedir una API que todavía no existe, y convenciones de backend escritas como criterios con los que se puede verificar un cambio, que empiezan por la receta para los cambios más comunes, en una versión que un agente pueda releer antes de cada cambio, con un revisor designado. |
| Data Ops | Dónde viven los datos de referencia, el significado de negocio de los campos clave y de los valores de estado, un conjunto de datos de prueba que se puede usar sin riesgo, y las reglas sobre qué se puede exportar, quién puede hacerlo y hacia dónde. |
| Accesos, entrega y revisión | Un circuito de solicitud con un aprobador y un plazo de respuesta, un camino del entorno local al repositorio, a staging y a producción, una forma de ver qué versión está en producción, y desarrolladores que leen el código generado. |

Un producto que funciona en producción.

- *Vertical · Product Builder* — **Hazte cargo de un resultado, front y back.** Lleva el problema, las decisiones, el diseño que se aceptó, las restricciones y la verificación, desde el discovery hasta producción. Te apoyas en los servicios compartidos y el resultado sigue siendo tuyo.
- *Horizontal · Servicios compartidos* — **Hacer reutilizable el conocimiento experto.** Aportar un responsable designado, un patrón o contrato aprobado y sus límites, un circuito de respuesta, y evidencia de que la contribución funciona en el producto en marcha — para ti y para todos los que hacen el mismo trabajo.

### Un contrato en los dos sentidos

**El Product Builder aporta**

- El resultado, los usuarios y el contexto
- La contribución que necesita
- Las restricciones dentro de las que tiene que encajar
- Un criterio de aceptación
- Una fecha límite para decidir

**El responsable de Ops devuelve**

- Un responsable designado
- Un patrón o contrato aprobado, y sus límites
- Un plazo de respuesta o de entrega
- Un circuito de revisión
- Evidencia de que funciona en el producto en marcha

**Antes de construir**

### Utilizable, no solo documentado.

Un documento por sí solo no es un servicio utilizable. Antes de construir, comprueba cuáles funcionan de verdad: un responsable designado, un circuito de respuesta, accesos aprobados, un entorno que funciona y una forma de verificar lo que vuelve. Cuando el starter, las convenciones o la API que necesitas no existen, detente en lugar de inventarlos — una convención inventada sobre la marcha es lo que un revisor deshará más tarde — y pide al responsable de Ops el artefacto, nombrándolo, y di qué respuesta esperas.

Mientras tanto, registra el sustituto en el diario, con fecha: lo que seguiste en su lugar, quién dio su acuerdo y qué reemplaza. En un equipo pequeño, una misma persona puede ocupar varios de estos roles; aun así, las responsabilidades tienen que ser visibles.

**Ejemplo**

En un flujo para compartir, el Product Builder es responsable de los permisos que el producto pretende dar y del comportamiento que aceptaron las personas implicadas. Design Ops aporta el patrón revisado y sus estados, Backend y API Ops el contrato de autorización, Frontend Ops el starter dentro del cual se escribe el front, Data Ops los eventos que muestran cómo se usa. El Product Builder recorre el flujo de principio a fin, con sus estados vacíos, de error y de permiso denegado, y lo verifica como un solo producto.

## El recorrido

Desde una carpeta de documentos dispersos hasta algo que funciona en producción, en solitario, con agentes de código y de diseño que hacen el trabajo que les encargas: siete hitos en un único orden, y tres cosas que los atraviesan a todos.

### Por qué importa el orden

- Una carpeta de documentos no es un discovery.
- Un discovery no es un PRD.
- Un PRD no es un prototipo en el que las personas implicadas reconocen su herramienta.
- Un front en el que puedes hacer clic no es un producto cuyos flujos se sostienen en profundidad.

**La pregunta.** ¿Cuál de esas cosas tienes de verdad en la mano? Empieza donde la respuesta deja de ser sí, y no dejes que una sesión pase un hito que no has cerrado: pídele, en cada hito, que diga en qué hito está, qué tiene, qué falta y qué tienes que decidir antes de que lo pase. Una sesión que no sabe responder ha salido del método.

> “La línea que cierra un hito es lo que deberías tener en la mano antes de seguir adelante.”
>
> — Alexis Boyer

*Figura — imagen, 21:9: Siete marcadores en fila sobre una misma superficie: la secuencia como objeto físico, leída de izquierda a derecha.*

### Los siete hitos

Siete hitos, numerados del 0 al 6. Nada por encima de ellos, y ninguna subfase. Cada uno dice qué haces, qué tienes en la mano cuando se cierra, y los prompts y las plantillas que usa.

| Hito | Qué haces | Qué tienes en la mano | Recursos |
| --- | --- | --- | --- |
| 0 · Preparar la carpeta del proyecto | Reúne todos los documentos que necesita el proyecto en una sola carpeta creada para él, y abre la sesión sobre esa carpeta. Crea la memoria y el diario antes de que se ejecute cualquier otra cosa, y el canal del proyecto con todas las personas implicadas dentro. El primer prompt convierte e indexa; no interpreta nada. | todo en una sola carpeta, convertido, inventariado | [Inventariar y convertir →](/es/resources/prompt-inventory) · [Entrada de memoria →](/es/resources/memory-entry) · [Entrada de diario →](/es/resources/journal-entry) |
| 1 · Reunir el discovery | Haz inventario de aquello de lo que partes, sea lo que sea, y recorre las fuentes en busca de contradicciones, de responsabilidades sin asignar y del mismo nombre usado para superficies distintas, no de un resumen. Pon a un agente a leer lo que nadie tiene tiempo de leer; lo que vuelve es materia prima, nunca una decisión. | lo que se sabe, lo que falta, lo que se contradice | [Leer los canales →](/es/resources/prompt-channel-reading) |
| 2 · Escribir el PRD | Ejecuta el prompt de análisis sobre la carpeta, haz que separe lo establecido de lo que se contradice y de lo que falta, y responde tú a sus preguntas de alineación. Después afina el PRD y alinéalo con la gente de negocio, incluidas las partes técnicas. | lo que entra y lo que no, acordado con el negocio | [Escribir el PRD →](/es/resources/prompt-prd) · [Plantilla de PRD →](/es/resources/prd-template) |
| 3 · Prototipar los flujos de principio a fin | En este paso, el agente de código asume el rol de PM: escribe el prompt para la herramienta de diseño y exige flujos de principio a fin, no solo las pantallas principales. Itera en la herramienta de diseño, muestra el resultado a las personas que lo van a usar y sigue hasta que digan que es su herramienta. | un prototipo en el que las personas implicadas reconocen su herramienta | [Especificación de diseño →](/es/resources/prompt-design-specification) · [Instrucción de diseño →](/es/resources/prompt-design-instruction) · [Refinamiento →](/es/resources/prompt-refinement) |
| 4 · Llevar el prototipo al código | Parte del starter de frontend aprobado por la organización y de sus convenciones de backend, nunca de una carpeta vacía ni de la exportación de la herramienta de diseño. Después vienen las idas y vueltas: el front en marcha junto al diseño, tú señalas lo que no encaja, el agente lo corrige, vuelves a mirar. | un front que funciona, en el que puedes hacer clic | [Llevar el prototipo al código →](/es/resources/prompt-port) · [Sin convenciones de backend escritas →](/es/resources/prompt-observed-conventions) · [Anticipar las necesidades de backend →](/es/resources/prompt-backend-requests) |
| 5 · Conectar el backend | Sustituye los servicios simulados por los reales, flujo a flujo, y profundiza en cada uno antes de pasar al siguiente: el estado vacío, el error, la respuesta lenta, el permiso que dice que no. Los roles y la privacidad se aplican en el modelo de lectura, no en el componente que muestra los datos. Cada cambio se contrasta con las convenciones de backend, punto por punto, antes de pasar a revisión. | los flujos se sostienen en profundidad | [Conectar el backend →](/es/resources/prompt-connect) |
| 6 · Probar y después lanzar | Crea cuentas para las personas que deben probar mientras el trabajo de conexión sigue en marcha, comparte la vida del producto en el canal y corrige lo que llega a medida que llega. Después obtén la luz verde de los leads de las disciplinas implicadas, y lanza el producto. | cuentas en manos reales, y después producción | [Preparar una puesta en producción →](/es/resources/prompt-release) |

### Lo que dejan los hitos

| Lo que deja el recorrido | Qué responde | Qué contiene | Hitos |
| --- | --- | --- | --- |
| Memoria y diario del proyecto | ¿Por qué el producto avanzó en esta dirección, y qué pasó y cuándo? | Dos archivos creados antes que nada: la memoria guarda la posición actual, las decisiones y sus contrapartidas; el diario guarda el registro fechado, nunca reescrito, incluido lo que resultó ser un error. | 0 |
| Notas de discovery | ¿Qué decían realmente las fuentes, y en qué discrepan? | La lista de fuentes, las ambigüedades, las preguntas para los stakeholders y una primera hipótesis sobre los límites del producto, escritas en la carpeta para que el hito siguiente pueda abrirlas por su nombre. | 1 |
| El PRD | ¿Qué se construye, y qué no? | Un documento cuya primera sección es el planteamiento estratégico, con cada supuesto marcado como supuesto, junto a la fuente en la que se apoya o la persona que tiene que decidirlo. | 2 |
| El prototipo que la gente aceptó | ¿Es la herramienta que necesitan las personas implicadas? | Los flujos de principio a fin, con sus estados y sus fallos, iterados en la herramienta de diseño y mostrados a usuarios reales hasta que dicen que es suya. | 3 |
| El front en marcha | ¿Puedes recorrer los flujos y hacer clic en ellos? | Un front construido dentro del starter de la organización, recorrido flujo a flujo junto al diseño, con lo que se adaptó y lo que se dejó distinto a propósito, por escrito. | 4 |
| Los flujos conectados | ¿Los flujos se sostienen en profundidad, o solo en la superficie? | Cada flujo contra el backend real, con sus estados vacíos, de error, de respuesta lenta y de permiso denegado, los roles aplicados donde se leen los datos, y cada cambio contrastado con las convenciones de backend, punto por punto. | 5 |
| El registro de la puesta en producción | ¿Qué salió, cómo se verificó y quién dio la luz verde? | Qué incluye la puesta en producción, flujo a flujo, qué se probó y con qué cuentas, qué se sabe que está roto, y qué revisión no se hizo, si alguna no pudo hacerse. | 6 |

Un hito se cierra cuando tienes en la mano lo que nombra su línea de salida. Si no, no está cerrado, y la sesión dice qué falta y qué tienes que decidir.

**Lo que hace falta.** De una carpeta con el material de discovery reunido a un front en el que puedes hacer clic: de tres a cuatro horas en el mejor de los casos y veinticuatro en el peor, cuando el discovery ya está en parte reunido. Alrededor de un mes para conectar el backend de modo que los flujos se sostengan en profundidad, según el tamaño de la aplicación. Y el código pasa igualmente por la revisión de los desarrolladores, y la supera, porque el agente trabaja dentro del starter y de las convenciones de la organización. Estas cifras salen de la práctica del propio autor, no de un estudio.

La IA construye rápido, así que las verificaciones que importan son humanas. Las personas implicadas aceptan el prototipo en el hito 3, y convencer tiene aquí un solo significado: que digan que es la herramienta que necesitan. El código pasa por la revisión de los desarrolladores antes de producción, y los leads de las disciplinas implicadas dan la luz verde. Ninguna de las dos verificaciones es una etapa añadida al final.

**Tres cosas atraviesan los hitos** en lugar de quedarse dentro de uno. La sesión de control es una segunda sesión cuyo único trabajo es cuestionar a la primera: lee, verifica y cuestiona, no cambia código ni decide el alcance, y devuelve hallazgos con su evidencia para que tú decidas. La salvaguarda permanente devuelve al agente al starter de frontend y a las convenciones de backend de la organización antes de cada cambio en el código — no una vez al principio, sino cada vez. El aprendizaje continuo no se detiene cuando empieza la construcción: sigues aprendiendo sobre el negocio, los usuarios y lo que necesitan, y cuando ese aprendizaje dice que el producto debería cambiar, lo cambias, en el hito en el que estés. Afina lo que ya existe en lugar de acumular, y sigue siendo ligero. [Sesión de control →](/es/resources/prompt-control-session) · [Restricción permanente →](/es/resources/prompt-standing-constraint) · [Leer los canales →](/es/resources/prompt-channel-reading)

**Continuidad.** La construcción no se detiene en el hito 6. El front se puede seguir mostrando en demos y sigue evolucionando: vuelves a los flujos, profundizas en ellos, conectas lo que quedó pendiente y lo vuelves a mostrar en el canal. Hay una sola cosa congelada a propósito, y solo una: un MVP que tiene que salir a producción, donde lo que entra en la puesta en producción deja de moverse hasta que sale.

La versión en inglés para un asistente presenta los mismos hitos uno por uno: [/method.md](/method.md).

### Empieza en el hito en el que está tu trabajo

No todo el mundo empieza en el hito 0. Empiezas en el hito donde de verdad comienza tu trabajo, y los hitos que te saltas son aquellos cuyo resultado ya tienes.

- *Una funcionalidad en un producto que ya existe · empieza en el PRD* — **El producto ya funciona.** El PRD está escrito y el diseño ya está definido. No rehaces la carpeta ni el discovery: empiezas en la sección del PRD a la que afecta esa funcionalidad, y después el prototipo, el paso a código, el backend, las pruebas.
- *Un producto que todavía no existe · empieza en el hito 0* — **La secuencia completa.** Una carpeta con todo dentro, el discovery reunido y sus contradicciones nombradas, un PRD acordado con el negocio, un prototipo que las personas implicadas llaman su herramienta, y después el paso a código, el backend flujo a flujo, y cuentas en manos reales antes de producción.

Lo que no te saltas es un hito cuyo resultado no tienes. ¿No hay inventario? ¿No hay PRD? Entonces toca hacer ese hito.

Estos dos ejemplos muestran qué parte del recorrido sigue realmente un trabajo concreto. No describen el proyecto de ningún cliente.