docs: cierre formal de Sprint 1.5
- OBSERVATIONS.md reseteado para Sprint 2 - STRATEGIC_DIRECTION.md con reflexiones del sprint - TECH_DEBT.md curado: items resueltos archivados - methodology/CASE_STUDIES/inq-roi-sprint-1-5.md generado Sprint 1.5 cerrado: - 11 etapas + 1 fix pre-Etapa 11 - 526 unit tests + 38 E2E al cierre - Producto con identidad InQ aplicada en web + 3 PDFs - Metodología documentada con casos reales (2 de mala clasificación de iniciativa, originaron AP.8 + refinamiento C.6) - Material para transmisión al equipo de 5 técnicos
This commit is contained in:
471
sprints/sprint-1-5/ETAPA_11_PROMPT.md
Normal file
471
sprints/sprint-1-5/ETAPA_11_PROMPT.md
Normal file
@@ -0,0 +1,471 @@
|
||||
# Sprint 1.5 — Etapa 11: Polish final + cierre formal del sprint
|
||||
|
||||
> **Objetivo:** completar los refinamientos visuales diferidos de Etapa 6 sobre la página 1 del PDF ROI (KPI Hero, banner narrativo, grid 2x2, Top 3). Ejecutar el cierre formal del Sprint 1.5: curaduría de OBSERVATIONS.md, migración de items DEFERRED, actualización de STRATEGIC_DIRECTION.md, generación de case study en methodology/, y tag del sprint.
|
||||
>
|
||||
> **Pre-requisitos:** Etapas 1-10 cerradas. CI 100% verde. 3 PDFs baseline en `tests/e2e/__output__/sprint-1-5-final/`. Docs `COVERAGE_STATE.md` y `QA_CHECKLIST.md` creados.
|
||||
>
|
||||
> **Etapa siguiente:** apertura de Sprint 2 (etapa por planificar, no parte de este sprint).
|
||||
|
||||
---
|
||||
|
||||
## 1. Esta etapa tiene dos partes diferenciadas
|
||||
|
||||
**Parte A — Polish visual** (mitad de la etapa): refinamientos del PDF ROI página 1.
|
||||
**Parte B — Cierre formal** (otra mitad): curaduría de archivos del sprint.
|
||||
|
||||
Hacé las dos partes EN ORDEN. La parte A primero. Cuando esté validada por el director, ejecutar parte B.
|
||||
|
||||
---
|
||||
|
||||
## 2. Parte A — Polish visual de página 1 PDF ROI
|
||||
|
||||
### 2.1 Alcance estricto de Parte A
|
||||
|
||||
Recoger los 4 refinamientos diferidos documentados en `TECH_DEBT.md` sección "Refinamientos visuales del PDF":
|
||||
|
||||
#### Refinamiento 1 — KPI Hero (gradiente naranja → magenta)
|
||||
|
||||
**Hallazgos del director en Etapa 6:**
|
||||
- Cifra demasiado pegada al label "AHORRO PROYECTADO A 3 AÑOS"
|
||||
- Tamaño de la cifra (USD 8.020.000,00) podría reducirse ligeramente
|
||||
- Esquinas cuadradas — pasa, pero si se logra redondear, mejor
|
||||
|
||||
**Cambios propuestos:**
|
||||
```
|
||||
Label "AHORRO PROYECTADO A N AÑOS":
|
||||
- Tamaño: 10pt (sin cambios)
|
||||
- Margin-bottom: aumentar de 6mm a 9mm (más respiro hacia la cifra)
|
||||
- Letter-spacing: 1.2pt (sin cambios)
|
||||
|
||||
Cifra principal (USD N.NNN.NNN):
|
||||
- Tamaño: bajar de 30pt a 26pt (más balanceada)
|
||||
- Tracking: -0.8pt (un poco menos cerrado)
|
||||
- Margin-bottom: 5mm (sin cambios significativos)
|
||||
|
||||
Esquinas redondeadas (intento opcional):
|
||||
- Si jsPDF permite recortar la imagen del gradiente con border-radius,
|
||||
aplicar 6mm de radius
|
||||
- Si requiere implementación compleja (cuatro triángulos blancos en
|
||||
esquinas, máscara SVG, etc.), DEJAR esquinas cuadradas y reportar
|
||||
- Tiempo máximo invertido: 30 minutos. Si no sale, pasar.
|
||||
```
|
||||
|
||||
#### Refinamiento 2 — Banner narrativo
|
||||
|
||||
**Hallazgo del director:**
|
||||
- "Texto corrido", no destaca cifras ni palabras clave
|
||||
- Podría tener tratamiento más visual
|
||||
|
||||
**Cambios propuestos:**
|
||||
```
|
||||
Estructura del banner:
|
||||
- Mantener fondo #FFF8ED + border-left 3px #F59845
|
||||
- Mantener tamaño general del texto (11pt)
|
||||
|
||||
Tratamiento tipográfico del contenido:
|
||||
- Las CIFRAS dentro del texto en peso 600 + color #B45309 (naranja oscuro):
|
||||
- "5.000 ejecuciones"
|
||||
- "3 años"
|
||||
- "USD 80.000,00"
|
||||
- "USD 540,00"
|
||||
- "90,0%"
|
||||
- "0.4 meses" (o equivalente del payback)
|
||||
|
||||
- El RESULTADO ("Resultado: ahorro de...") en peso 500
|
||||
|
||||
- El resto del texto en peso 400 (sin cambios)
|
||||
|
||||
Implementación técnica:
|
||||
- jsPDF requiere usar doc.text() con setFont() para cada segmento
|
||||
- Construir el banner como secuencia de fragmentos en lugar de párrafo
|
||||
monolítico
|
||||
- Alternativa: usar doc.text() con array de strings y posicionar
|
||||
manualmente
|
||||
```
|
||||
|
||||
#### Refinamiento 3 — Grid 2x2 KPIs secundarios
|
||||
|
||||
**Hallazgo del director:**
|
||||
- "No tienen consistencia en el uso de tipografía"
|
||||
- Verificar que los 4 cards sigan el mismo patrón visual
|
||||
|
||||
**Cambios propuestos:**
|
||||
|
||||
Auditar visualmente los 4 cards y unificar:
|
||||
```
|
||||
Card label superior (las 4 cards):
|
||||
- Tamaño: 9pt (fijo, no variar)
|
||||
- Peso: 500
|
||||
- Color: #92400E
|
||||
- Letter-spacing: 1pt
|
||||
- Uppercase
|
||||
- Margin-bottom: 5mm (fijo)
|
||||
|
||||
Card cifra principal (las 4 cards):
|
||||
- Tamaño: 18pt (fijo, no variar entre cards)
|
||||
- Peso: 700 (bold)
|
||||
- Color: #0F172A
|
||||
- Font-family: mono (alineación de números consistente)
|
||||
- Margin-bottom: 3mm
|
||||
|
||||
Card delta/contexto (las 4 cards):
|
||||
- Tamaño: 9pt (fijo)
|
||||
- Peso: 500
|
||||
- Color: #B45309
|
||||
- Margin-top: 0 (después del 3mm de margin-bottom de la cifra)
|
||||
```
|
||||
|
||||
**Específicamente verificar:**
|
||||
- Card "AHORRO POR EJECUCIÓN": la línea "-90,0% vs. actual" debe tener mismo tamaño/peso/color que las deltas de los otros cards
|
||||
- Card "PAYBACK": la línea "Dentro del horizonte" debe tener mismo tratamiento
|
||||
- Card "AHORRO ANUAL": "× 3 años" debe tener mismo tratamiento
|
||||
- Card "ROI ANUAL": "retorno anual" debe tener mismo tratamiento
|
||||
|
||||
#### Refinamiento 4 — Top 3 actividades
|
||||
|
||||
**Hallazgos del director:**
|
||||
- Título "TOP 3 ACTIVIDADES POR AHORRO" se ve pequeño
|
||||
- Las barras no tienen fondo para contraste
|
||||
|
||||
**Cambios propuestos:**
|
||||
```
|
||||
Título de la sección:
|
||||
- Texto: "TOP 3 ACTIVIDADES POR AHORRO"
|
||||
- Tamaño: aumentar de 9pt a 11pt
|
||||
- Peso: 600 (más bold)
|
||||
- Color: #92400E (naranja oscuro, en vez de gris)
|
||||
- Letter-spacing: 1.2pt
|
||||
- Margin-bottom: 8mm (más respiro hacia las barras)
|
||||
|
||||
Barras horizontales:
|
||||
- Track (fondo): mantener #FED7AA (inq-orange-100)
|
||||
- Fill: mantener #F59845 (inq-orange)
|
||||
- Aumentar visibilidad del track: agregar border 0.3pt #F59845 en track
|
||||
para definir el área completa
|
||||
- Border-radius: 1mm en track y fill
|
||||
|
||||
Layout fila:
|
||||
- Mantener grid 3 columnas (nombre 40% / barra 40% / cifra 20%)
|
||||
- Gap entre filas: 5mm (un poco más que antes)
|
||||
```
|
||||
|
||||
### 2.2 Validación visual obligatoria de Parte A
|
||||
|
||||
Cuando Claude Code termine los 4 refinamientos, **NO HACER PARTE B AÚN**. Generar el PDF ROI actualizado:
|
||||
|
||||
```
|
||||
tests/e2e/__output__/etapa-11-roi.pdf
|
||||
```
|
||||
|
||||
Y presentarlo para validación del director. El director va a:
|
||||
|
||||
1. Comparar la página 1 con el PDF de Etapa 6 (donde se identificaron los problemas)
|
||||
2. Decidir si los 4 refinamientos resuelven sus observaciones
|
||||
3. O pedir ajustes específicos
|
||||
|
||||
**Solo después del OK explícito del director sobre Parte A, ejecutar Parte B.**
|
||||
|
||||
### 2.3 Iteración esperada
|
||||
|
||||
Es probable que la primera pasada no satisfaga al 100%. El director va a dar feedback específico tipo:
|
||||
|
||||
- "La cifra del KPI Hero todavía está muy grande, bajá a 24pt"
|
||||
- "El banner no destaca lo suficiente, los números deberían ser color naranja oscuro más fuerte"
|
||||
- "Las barras del Top 3 ahora tienen border, pero el border es muy delgado"
|
||||
|
||||
**Mentalidad correcta:** la primera pasada es punto de partida. La conversación visual con el director afina hasta llegar al resultado. Esperá 1-3 iteraciones.
|
||||
|
||||
---
|
||||
|
||||
## 3. Parte B — Cierre formal del sprint
|
||||
|
||||
**Ejecutar SOLO después del OK explícito del director sobre Parte A.**
|
||||
|
||||
### 3.1 Curaduría de OBSERVATIONS.md
|
||||
|
||||
Acciones específicas:
|
||||
|
||||
1. **Items con etiqueta `[RESOLVED]`**:
|
||||
- Verificar que todos están realmente resueltos
|
||||
- Trasladar a una sección final del archivo "Historial de Sprint 1.5" o eliminarlos según preferencia del director
|
||||
|
||||
2. **Items con etiqueta `[DEFERRED-TECH-DEBT]`**:
|
||||
- Verificar que ya están migrados a `TECH_DEBT.md`
|
||||
- Si NO están migrados, migrarlos ahora
|
||||
- Eliminar de `OBSERVATIONS.md`
|
||||
|
||||
3. **Items con etiqueta `[DEFERRED-BACKLOG]`**:
|
||||
- Verificar que ya están migrados a `BACKLOG.md`
|
||||
- Si NO están migrados, migrarlos ahora
|
||||
- Eliminar de `OBSERVATIONS.md`
|
||||
|
||||
4. **Items con etiqueta `[CURRENT-SPRINT]`**:
|
||||
- Si están resueltos por Parte A (polish final), marcarlos `[RESOLVED]`
|
||||
- Si NO están resueltos, **PARAR Y CONSULTAR**: ¿se difieren a Sprint 2 o se cierran como deuda asumida?
|
||||
|
||||
5. **Vaciar el archivo dejando estructura para Sprint 2**:
|
||||
```markdown
|
||||
# OBSERVATIONS — Sprint 2
|
||||
|
||||
> Hallazgos descubiertos durante validación visual del sprint actual.
|
||||
> Este archivo se vacía al cerrar el sprint.
|
||||
|
||||
(Sin hallazgos activos. Sprint 2 inicia.)
|
||||
|
||||
## Convención de etiquetas
|
||||
|
||||
[mantener la convención de etiquetas como referencia]
|
||||
```
|
||||
|
||||
### 3.2 Actualización de STRATEGIC_DIRECTION.md
|
||||
|
||||
Agregar al final del archivo una nueva sección con reflexiones del Sprint 1.5:
|
||||
|
||||
```markdown
|
||||
## Reflexiones del cierre de Sprint 1.5
|
||||
|
||||
### Lo que funcionó
|
||||
|
||||
- [Capturar 3-5 cosas que el director identificó como aprendizajes positivos]
|
||||
- Ejemplo esperable: "Política de iniciativa proactiva con consulta clasificada
|
||||
redujo errores de scope después de Etapa 8"
|
||||
|
||||
### Lo que costó más de lo esperado
|
||||
|
||||
- [Capturar 2-3 dificultades específicas]
|
||||
- Ejemplo esperable: "El gradiente del KPI Hero requirió varias iteraciones"
|
||||
|
||||
### Decisiones arquitectónicas tomadas durante el sprint
|
||||
|
||||
- ASCII puro en fórmulas matemáticas (en lugar de Σ Unicode)
|
||||
- Layout híbrido portrait/landscape para PDFs
|
||||
- Jerarquía visual: KPI Hero exclusivo del PDF ROI
|
||||
- Badge ⚡ con posición basada en `left` (no `right`)
|
||||
- Permisos de Claude Code versionados en .claude/
|
||||
|
||||
### Estado de las definiciones del producto
|
||||
|
||||
- Identidad visual: estable hasta Sprint 4+
|
||||
- Posicionamiento de mercado: pendiente de consolidar con feedback real
|
||||
- Métricas de éxito: pendientes de definir con datos de uso
|
||||
|
||||
### Anticipación para Sprint 2
|
||||
|
||||
[Espacio para que el director complete cuando arranque Sprint 2]
|
||||
```
|
||||
|
||||
### 3.3 Generación de case study
|
||||
|
||||
Crear `methodology/CASE_STUDIES/inq-roi-sprint-1-5.md` con resumen del sprint para uso futuro del director con su equipo.
|
||||
|
||||
Estructura:
|
||||
|
||||
```markdown
|
||||
# Case Study — InQ ROI Sprint 1.5: Rediseño visual con identidad InQ
|
||||
|
||||
## Contexto inicial
|
||||
|
||||
- Producto: InQ ROI, herramienta interna de InQuality
|
||||
- Director: Marcos (CEO/fundador InQuality)
|
||||
- Equipo de ejecución: Claude Code (un solo agente) + Claude Sonnet (asesor)
|
||||
- Duración planeada: 11 etapas
|
||||
- Duración real: 11 etapas + 1 fix puntual entre Etapas 10 y 11
|
||||
|
||||
## Alcance del sprint
|
||||
|
||||
[Lista de qué se construyó: identidad visual, sistema de design,
|
||||
3 PDFs rediseñados, badge en web, metodología documentada]
|
||||
|
||||
## Aplicación del método
|
||||
|
||||
### Patrones aplicados con casos concretos
|
||||
|
||||
[Mencionar cada patrón usado durante el sprint con el caso específico
|
||||
donde se aplicó:]
|
||||
|
||||
- A.1 Brief versionado: BRIEF.md de 852 líneas, base del sprint completo
|
||||
- A.2 Mockup como contrato: mockups iterados pre-implementación
|
||||
- B.4 Reglas no negociables en CLAUDE.md: marca "InQ", política de
|
||||
iniciativa proactiva
|
||||
- C.1 Validación visual mandatoria: cazó truncamiento de notas en Etapa 5
|
||||
- C.3 Auditoría adversarial: detectó decisión proactiva no autorizada
|
||||
en Etapa 3
|
||||
- C.6 Iniciativa agéntica con consulta clasificada: refinada en Etapas 5 y 8
|
||||
- D.4 Permisos versionados en .claude/: aplicado mid-sprint
|
||||
|
||||
### Anti-patrones detectados con casos concretos
|
||||
|
||||
- AP.3 Racionalización de output anómalo: detectado en validación
|
||||
visual de Etapa 5 (compactación de páginas)
|
||||
- AP.8 Adelanto silencioso de deuda técnica: detectado en Etapa 7-8
|
||||
(reescritura de fórmulas Σ → ASCII)
|
||||
|
||||
### Cosechas del método originadas en este sprint
|
||||
|
||||
- Refinamiento del Patrón C.6 con criterios explícitos de clasificación
|
||||
- Nuevo Anti-Patrón AP.7: Bypass total de permisos en desarrollo local
|
||||
- Nuevo Anti-Patrón AP.8: Adelanto silencioso de deuda técnica
|
||||
- Nuevo Patrón D.4: Permisos del agente versionados en .claude/
|
||||
- Extensión del Principio 3: "El auditor también debe ser auditado"
|
||||
|
||||
## Lecciones aprendidas
|
||||
|
||||
[3-5 lecciones operativas que el director identificó como transferibles
|
||||
al equipo]
|
||||
|
||||
## Métricas
|
||||
|
||||
- Etapas: 11 (+ 1 fix puntual)
|
||||
- Tests: 526 unit + 38 E2E al cierre
|
||||
- Archivos modificados/creados: [contar de los commits]
|
||||
- Decisiones de iniciativa: total y desglose por nivel
|
||||
- Casos de mala clasificación de iniciativa: 2 (Etapas 5 y 7-8)
|
||||
|
||||
## Material para transmisión al equipo
|
||||
|
||||
[Sugerencias de qué partes de este case study usar en las 4 sesiones
|
||||
× 1h de transmisión del método al equipo de 5 técnicos de InQuality]
|
||||
```
|
||||
|
||||
### 3.4 Tag final del sprint
|
||||
|
||||
```bash
|
||||
git tag sprint-1-5-cerrado
|
||||
git push --tags
|
||||
```
|
||||
|
||||
### 3.5 Validación final del cierre
|
||||
|
||||
Antes de declarar Etapa 11 (y Sprint 1.5) cerrados:
|
||||
|
||||
- [ ] OBSERVATIONS.md vaciado o resetado para Sprint 2
|
||||
- [ ] STRATEGIC_DIRECTION.md actualizado con reflexiones del sprint
|
||||
- [ ] CASE_STUDIES/inq-roi-sprint-1-5.md creado
|
||||
- [ ] Tag git `sprint-1-5-cerrado` creado
|
||||
- [ ] Suite completa de tests sigue 100% verde
|
||||
- [ ] CI limpio
|
||||
|
||||
---
|
||||
|
||||
## 4. Validaciones automatizadas
|
||||
|
||||
```
|
||||
Parte A — Polish visual:
|
||||
1. PDF ROI etapa-11-roi.pdf generado, 5 páginas
|
||||
2. Página 1: cifra del KPI Hero ≤ 26pt
|
||||
3. Página 1: banner narrativo con cifras destacadas (verificar fragmentos
|
||||
de texto con setFont en peso 600)
|
||||
4. Página 1: grid 2x2 con tamaños consistentes en los 4 cards
|
||||
5. Página 1: título "TOP 3 ACTIVIDADES POR AHORRO" en color naranja
|
||||
oscuro (#92400E)
|
||||
6. PDFs Actual y Automatizado: SIN CAMBIOS respecto a Etapa 8
|
||||
7. Tests previos siguen verdes (526 unit + 38 E2E)
|
||||
|
||||
Parte B — Cierre formal:
|
||||
8. OBSERVATIONS.md tiene estructura limpia para Sprint 2
|
||||
9. STRATEGIC_DIRECTION.md tiene nueva sección de reflexiones
|
||||
10. methodology/CASE_STUDIES/inq-roi-sprint-1-5.md existe y tiene
|
||||
estructura mínima esperada
|
||||
11. Tag git sprint-1-5-cerrado existe en local (push pendiente del director)
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 5. Entregables (Definition of Done)
|
||||
|
||||
```
|
||||
PARTE A:
|
||||
[ ] 4 refinamientos del PDF ROI página 1 aplicados según especificación
|
||||
[ ] PDF ROI etapa-11-roi.pdf generado para validación visual
|
||||
[ ] PDFs Actual y Automatizado NO modificados
|
||||
[ ] Tests previos verdes
|
||||
[ ] OK explícito del director sobre Parte A antes de avanzar
|
||||
|
||||
PARTE B:
|
||||
[ ] OBSERVATIONS.md curado y reseteado para Sprint 2
|
||||
[ ] STRATEGIC_DIRECTION.md actualizado con reflexiones
|
||||
[ ] methodology/CASE_STUDIES/inq-roi-sprint-1-5.md creado
|
||||
[ ] Tag git sprint-1-5-cerrado local
|
||||
[ ] CI 100% verde
|
||||
[ ] Reporte final entregado
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 6. Reporte final a entregar
|
||||
|
||||
1. **Tabla de archivos modificados/creados** (parte A + parte B separadas)
|
||||
2. **PDF ROI etapa-11-roi.pdf presentado** con path absoluto
|
||||
3. **Validaciones automatizadas confirmadas** (11 puntos)
|
||||
4. **Resumen de cambios en cada refinamiento**: qué se modificó exactamente
|
||||
5. **Decisiones tomadas durante refinamientos** (especialmente sobre
|
||||
esquinas redondeadas del KPI Hero — sí/no se logró)
|
||||
6. **Resumen de curaduría**: cuántos items procesados de cada estado
|
||||
([RESOLVED], [DEFERRED-*], [CURRENT-SPRINT])
|
||||
7. **Confirmación de tag git** y estado final del sprint
|
||||
8. **Decisiones de iniciativa proactiva** según política CLAUDE.md
|
||||
|
||||
---
|
||||
|
||||
## 7. Reglas operativas
|
||||
|
||||
1. **PARTE A ANTES DE PARTE B.** No mezclar. Cuando Parte A está validada
|
||||
por el director, recién entonces ejecutar Parte B.
|
||||
|
||||
2. **ITERACIÓN EN PARTE A.** Los refinamientos visuales pueden requerir
|
||||
2-3 pasadas. Eso es normal. Mantener iteraciones acotadas a feedback
|
||||
específico del director, sin re-rediseñar de cero.
|
||||
|
||||
3. **NO TOCAR PDFs Actual y Automatizado.** Cerrados en Etapa 8.
|
||||
|
||||
4. **NO MODIFICAR código no relacionado con los 4 refinamientos** durante
|
||||
Parte A. Es polish, no refactor.
|
||||
|
||||
5. **EN PARTE B, las decisiones de curaduría son del director.** Si un
|
||||
item DEFERRED no está claro a dónde migrar, consultar. Si un item
|
||||
CURRENT-SPRINT no se resolvió en el sprint, consultar antes de
|
||||
diferirlo automáticamente.
|
||||
|
||||
6. **Política de iniciativa refinada (post-Etapa 8):**
|
||||
- Cambios en código fuera de los 4 refinamientos: Nivel 3 — consultar
|
||||
- Cambios en archivos de documentación dentro del scope de Parte B:
|
||||
Nivel 2 — reportar
|
||||
- Eliminar items de OBSERVATIONS.md: SIEMPRE Nivel 2 (reportar lo
|
||||
que se eliminó/movió)
|
||||
|
||||
7. **Si encontrás contradicción** entre prompt y código: PARÁ y consultá.
|
||||
|
||||
8. **Si la iteración de Parte A se extiende mucho**, evaluar con el
|
||||
director si vale la pena cerrar Etapa 11 con el polish "razonable"
|
||||
y diferir refinamientos finos a una etapa de mantenimiento en Sprint 2.
|
||||
|
||||
---
|
||||
|
||||
## 8. Por qué esta etapa importa
|
||||
|
||||
Etapa 11 es **el cierre del primer sprint donde se construyó el método mientras se construía el producto**. Lo que decidas acá determina:
|
||||
|
||||
1. La calidad final del entregable visual que va a clientes
|
||||
2. La calidad del registro del sprint (case study + reflexiones)
|
||||
3. La capacidad de transmitir el método a tu equipo con material concreto
|
||||
|
||||
**No te apures con esta etapa.** Si Parte A requiere 3 iteraciones, está bien. Si Parte B requiere 1 hora de curaduría con decisiones por item, está bien.
|
||||
|
||||
El éxito de Etapa 11 NO se mide en velocidad. Se mide en:
|
||||
- Página 1 del PDF ROI alcanza el nivel que vos pretendías al inicio del sprint
|
||||
- Sprint 1.5 cierra con artefactos transferibles (case study + docs actualizados)
|
||||
- Tu equipo puede ver Sprint 1.5 como ejemplo concreto del método en acción
|
||||
|
||||
---
|
||||
|
||||
## 9. Después de Etapa 11
|
||||
|
||||
Cuando esta etapa cierre:
|
||||
|
||||
- Sprint 1.5 queda completamente cerrado
|
||||
- Tu siguiente trabajo es planificar Sprint 2 con la dirección estratégica documentada (rebalanceo web/PDF, criterio de wow obligatorio)
|
||||
- Las 4 sesiones × 1h de transmisión metodológica al equipo pueden arrancar usando el case study como material
|
||||
|
||||
Es el momento de inflexión. Sprint 1.5 fue donde construiste vocabulario, patrones y método. Sprint 2 va a ser donde vos aplicás eso para producir features de valor, y donde tu equipo eventualmente toma el método y lo usa.
|
||||
|
||||
Esta es la última etapa donde estamos todos enfocados solo en InQ ROI. Después, el método cobra vida propia.
|
||||
Reference in New Issue
Block a user