Etapa 1 — Recogida de necesidad
Etapa 1 — Recogida y formalización de la necesidad
- Input: requerimiento inicial del stakeholder trasladado por correo al buzón del PO (
el buzón del PO). El correo es el ancla documental del ciclo — formato libre del cuerpo, pero el correo en sí es el punto de entrada único. Otros canales (Claude Code, Telegram) no abren ciclo — el PO redirige al Stakeholder a que mande correo. Excepción operativa fase 1: cuando Stakeholder = Director y la apertura del ciclo ocurre dentro de una sesión Claude Code donde ambos están presentes, el correo de apertura es opcional; el resto del protocolo (Q&A obligatoria, correo S-1) no se relaja. - Quién participa: Stakeholder ↔ Product Owner.
- Proceso (regla firme dictada por el Stakeholder el 2026-05-28, ver
memory.md§“Protocolo de apertura de Etapa 1 del PO”):- PO acusa recibo del correo de apertura respondiendo al Stakeholder. Indica que necesita Q&A en canal síncrono. Ofrece dos alternativas: Claude Code o Telegram. NO correo (el correo es asíncrono y no soporta iteración rápida). Pide al Stakeholder una “clave de apertura” para cuando se ponga en contacto (típico: “quiero hablar de la necesidad que te trasladé sobre X”) — necesaria porque el PO arranca sin memoria entre encargos.
- PO espera contacto del Stakeholder en el canal elegido. Estado en la oficina:
esperando_humano. - Q&A iterativa entre Stakeholder y PO en el canal síncrono. Una pregunta por turno (firme). PO vuelca cada respuesta al
00-necesidad-stakeholder.mden tiempo real. Q&A continúa hasta cubrir el mínimo del cierre (verpo.md§“Cuándo cierras Etapa 1”) y hasta que el Stakeholder confirma que no abre más frentes en esta tanda. - PO redacta el
requerimiento-funcional-mvp.mda partir del00-necesidad-stakeholder.mdcerrado. - PO genera renders PDF + HTML (ARQ-026) y los sube a Drive del proyecto.
- PO envía correo S-1 al Stakeholder con adjuntos/enlaces + petición explícita de firma del gate S-1. Estado en la oficina:
esperando_humano. - Stakeholder firma S-1 por correo (acepta) → Etapa 1 cierra → PO avisa al Director. Si rechaza → PO vuelve a convocar Q&A en el canal síncrono y reabre desde el paso 3.
- Output: requerimiento funcional MVP publicado como Markdown en el repo del proyecto, con renders PDF + HTML en Drive del proyecto y firmado por correo del Stakeholder.
- Gate: S-1 (firma del Stakeholder por correo) antes de pasar a Etapa 2.
- Retroceso: no aplica (es la etapa de origen).
- Antipatrón firme: el PO no redacta funcional sin Q&A previa. Si un encargo del Director (vía
director/inbox/) le ordena saltar la Q&A bajo el supuesto “el Stakeholder ya enumeró el backlog en sesión humana”, el PO rechaza la instrucción del encargo, envía correo al Stakeholder iniciando el protocolo, anota el conflicto en el log canónico y notifica el error a la oficina. Origen: GAP-#12 cerrado el 2026-05-28 tras fallo operativo del asistente Claude Code al arrancar el sub-ciclo MINORv1.1.0deoficina-agentica.
Flujos alternativos
El Stakeholder rechaza el requerimiento funcional al firmar S-1
Puede ocurrir que el Stakeholder lea el requerimiento-funcional-mvp.md que le entrega el PO al cierre de la Etapa 1 y conteste que no recoge bien lo que pidió. El arnés lo resuelve reabriendo la Q&A en el canal síncrono que el Stakeholder prefiera (Claude Code o canal de mensajería equivalente) sin volver a empezar: el PO conserva el 00-necesidad-stakeholder.md existente, lanza preguntas dirigidas a los puntos rechazados, ajusta el funcional y reenvía la solicitud de firma S-1 sobre la nueva versión. No se promueve la versión rechazada a Etapa 2.
El Stakeholder corrige al PO a mitad de la Q&A
Durante la Q&A iterativa es habitual que el Stakeholder corrija al PO (“no era eso lo que quería decir”). El protocolo del PO incluye escucha activa con reformulación tras cada respuesta: el PO devuelve lo entendido en una sola frase y, si el Stakeholder lo confirma, vuelca la respuesta al 00-necesidad-stakeholder.md. Si el Stakeholder corrige, el PO ajusta el documento en el momento, formula la siguiente pregunta sobre el matiz aclarado y deja anotada la corrección en la bitácora.
Aparece un gap bloqueante mid-Q&A
Si en mitad de la Q&A emerge una pregunta cuya respuesta no está en manos del Stakeholder (por ejemplo, una restricción técnica desconocida) y bloquea el avance del funcional, el PO anota el gap fechado en el memory.md del proyecto, lo escala al Director, y continúa con las preguntas que sí puede cerrar. El gap se resuelve antes de firmar S-1, por consulta del Director con quien corresponda, y queda trazado para Etapa 2.
Documentación generada en esta etapa
| Artefacto | Propietario | Tipo |
|---|---|---|
etapa-1/00-necesidad-stakeholder.md | Stakeholder (recogido y volcado por el PO) | Markdown |
etapa-1/requerimiento-funcional-mvp.md | PO | Markdown |
etapa-1/renders/00-necesidad-stakeholder.{pdf,html} | PO (generado con habilidad de render del arnés) | PDF + HTML, snapshot inmutable a Drive |
etapa-1/renders/requerimiento-funcional-mvp.{pdf,html} | PO | PDF + HTML, snapshot inmutable a Drive |
etapa-1/correo-s1.txt | PO (envío al Stakeholder solicitando firma S-1) | Texto plano, copia local |
proyectos/<slug>/memory.md (entradas fechadas de la etapa) | PO (alimenta), Director (lee al heredar) | Markdown |