167 lines
7.5 KiB
Markdown
167 lines
7.5 KiB
Markdown
# Dirección estratégica — InQ ROI
|
||
|
||
> Documento de decisiones estratégicas del director (Marcos) que orientan el desarrollo del producto en sprints futuros. Se actualiza al cerrar cada sprint con reflexiones del director.
|
||
>
|
||
> NO es backlog (ver `BACKLOG.md`) ni deuda técnica (ver `TECH_DEBT.md`). Es **el "por qué" detrás de las decisiones de prioridad**.
|
||
|
||
---
|
||
|
||
## Versión actual: post-Sprint 1.5 (mayo 2026)
|
||
|
||
### Reorientación estratégica detectada al cerrar Sprint 1.5
|
||
|
||
Durante el Sprint 1.5, el director identificó que la inversión de tiempo en el producto estaba desbalanceada:
|
||
|
||
- **7 de 11 etapas del Sprint 1.5 fueron sobre PDF** (Etapas 4, 5, 6, 7, 8 + porción de 1 y 11)
|
||
- **3 de 11 etapas fueron sobre web app** (Etapas 1, 3, 9)
|
||
- **1 etapa fue mixta** (Etapa 2: helper compartido)
|
||
|
||
Esta proporción tuvo justificación válida en Sprint 1.5 porque se establecía identidad visual y sistema de diseño desde cero. Pero **replicar esa proporción en Sprint 2+ sería un error estratégico.**
|
||
|
||
### Decisión: rebalanceo de prioridades
|
||
|
||
**El producto es la herramienta web. El PDF es entregable final del producto.**
|
||
|
||
A partir de Sprint 2:
|
||
|
||
| Componente | Inversión esperada |
|
||
|---|---|
|
||
| Web app (workspace + reporte + features) | 60-70% del tiempo del sprint |
|
||
| PDF (refinamientos, nuevas secciones) | 15-25% |
|
||
| Infraestructura (deuda técnica, build, deploy) | 10-15% |
|
||
| Documentación / metodología | 5-10% |
|
||
|
||
**Razón:** el consultor de InQuality usa el web app **decenas de veces** mientras itera sobre un caso. Exporta el PDF **una vez** al final. Una mejora en el web app tiene 10× más impacto en la productividad del consultor que un refinamiento del PDF.
|
||
|
||
### Implicancia operativa para Sprint 2+
|
||
|
||
- No abrir sprints con foco principal en PDF
|
||
- Si un sprint requiere trabajo de PDF, que sea acotado a una etapa puntual, no transversal
|
||
- Los refinamientos del PDF se acumulan en `TECH_DEBT.md` para resolver en sprints periódicos de "polish", no continuamente
|
||
- Features nuevas del producto se construyen en el web app primero, exporte al PDF segundo
|
||
|
||
---
|
||
|
||
## Decisión: criterio de "wow" como parte del scope de cada feature
|
||
|
||
Detectado durante validación visual del Sprint 1.5 (Etapa 6). Se observó que la implementación "mínima" cumple la funcionalidad pero pierde el efecto de experiencia que diferencia un producto profesional de un funcional.
|
||
|
||
### Política a partir de Sprint 2
|
||
|
||
Cada `ETAPA_PROMPT.md` que defina una feature nueva debe incluir una sección explícita **"Criterio de wow"** con dos versiones del scope:
|
||
|
||
- **Versión mínima:** lo que cumple la funcionalidad
|
||
- **Versión con wow:** mismo objetivo + 1-2 detalles de experiencia que generen impacto positivo en el usuario
|
||
|
||
El director decide en cada feature si se implementa la mínima o la con wow. **Por defecto, la versión con wow es la recomendada** si el costo extra es menor al 40% del tiempo de la versión mínima.
|
||
|
||
### Ejemplo aplicado: feature "Recursos con costo por hora"
|
||
|
||
- **Mínimo:** input numérico, cálculo en backend, número en tabla
|
||
- **Con wow:** input con sugerencias de salario por rol (CEO, Analista, etc.), validación en tiempo real, cálculo actualiza mientras escribís, helper que dice "esta actividad cuesta el equivalente a X días de trabajo de Y persona"
|
||
|
||
Ambas resuelven el problema. La segunda es lo que diferencia InQ ROI de una calculadora Excel.
|
||
|
||
---
|
||
|
||
## Definiciones estables — no se reabren hasta nuevo aviso
|
||
|
||
### Identidad visual (estable hasta Sprint 4+)
|
||
|
||
- Paleta cromática: naranja InQ `#F59845`, magenta `#ED3E8F`, gradiente identidad
|
||
- Tipografía: system-ui stack
|
||
- Sistema de componentes (KPI cards, banners, tablas, botones)
|
||
- Reglas de marca no negociables: "InQ" siempre I-n-Q, "Powered by InQuality" en footer
|
||
- Tono: técnico-pragmático, profesional, sin marketing-speak
|
||
|
||
### Lo que NO está definido pero NO bloquea
|
||
|
||
- Logo SVG de InQuality (es texto por ahora, OK)
|
||
- Ícono ⚡ refinado (es emoji, OK)
|
||
- Color de tipos de recurso (se define cuando aparezca la feature)
|
||
- Manual de marca formal de InQuality (cuando exista, se incorpora)
|
||
|
||
### Cuándo reabrir identidad
|
||
|
||
Solo si InQuality consolida manual de marca formal con assets nuevos, o si feedback de uso real en talleres revela un problema específico.
|
||
|
||
---
|
||
|
||
## Definiciones por consolidar — requieren input externo
|
||
|
||
### Posicionamiento de mercado de InQ ROI
|
||
|
||
**Estado:** indefinido más allá de "herramienta interna de InQuality + consultoras LATAM".
|
||
|
||
**Preguntas abiertas:**
|
||
- ¿InQ ROI se vende a otras consultoras o se mantiene interno?
|
||
- Si se vende, ¿con qué pricing?
|
||
- ¿Qué pasa si una consultora competidora descubre el producto?
|
||
- ¿El nombre "InQ ROI" sobrevive cuando se venda fuera de InQuality?
|
||
|
||
**Decisión pendiente:** post-Sprint 2 con feedback de uso real en InQuality.
|
||
|
||
### Métricas de éxito del producto
|
||
|
||
**Estado:** no definidas formalmente.
|
||
|
||
**Sugerencia para definir:** post-Sprint 2 con datos reales de uso interno. Algunas candidatas:
|
||
- Cantidad de procesos costeados por consultor por semana
|
||
- Tiempo promedio de la primera simulación útil
|
||
- NPS interno del equipo InQuality
|
||
- Cantidad de propuestas pre-venta que incluyen output de InQ ROI
|
||
|
||
---
|
||
|
||
## Filosofía operativa que orienta las decisiones
|
||
|
||
### El equipo es héroe, el director es guía (Donald Miller)
|
||
|
||
El equipo de 5 técnicos de InQuality va a ser el operador del día a día. El director (Marcos) los guía con metodología, pero **no es el operador**. Las decisiones del producto y del método se documentan para que sean transferibles.
|
||
|
||
### Validación humana es ojo, no test
|
||
|
||
Los artefactos visibles requieren validación visual del director (o un miembro del equipo capacitado) antes del cierre de etapa. Tests verdes no equivalen a aprobación final. Este principio se aplicará en todos los sprints futuros.
|
||
|
||
### Iniciativa agéntica con consulta clasificada
|
||
|
||
Los agentes pueden proponer cambios proactivos, pero se clasifican por impacto:
|
||
- Nivel 1 (trivial): ejecutar
|
||
- Nivel 2 (visible reversible): ejecutar y reportar
|
||
- Nivel 3 (marca, arquitectura, datos): consultar antes
|
||
|
||
Esta política aplica indefinidamente. Documentada en `methodology/PRINCIPLES.md`.
|
||
|
||
### Anti-perfeccionismo prematuro
|
||
|
||
Refinamientos visuales finos se acumulan en `TECH_DEBT.md` y se resuelven en sprints periódicos de "polish", no continuamente. Esto evita gastar 3 horas refinando un componente que va a tener que tocarse otra vez al agregar features.
|
||
|
||
---
|
||
|
||
## Decisiones de método aprendidas durante Sprint 1.5
|
||
|
||
Estas son aprendizajes operativos validados con casos reales. Se documentan acá como guía estratégica, no como reglas dogmáticas.
|
||
|
||
### Briefs versionados son innegociables
|
||
|
||
Sin un brief en `sprints/sprint-N/BRIEF.md`, cualquier sesión con Claude Code es improvisación. Esta práctica aplica a todos los sprints futuros.
|
||
|
||
### Mockups son contratos visuales
|
||
|
||
Cuando un cambio es visual, el mockup interactivo aprobado por el director es el ground truth. El agente lo replica, no lo interpreta libremente.
|
||
|
||
### La metodología evoluciona caso por caso
|
||
|
||
Los patrones documentados en `methodology/` se validan en proyectos reales. No se inventan patrones especulativos. Cuando un problema operativo aparece, se registra como observación; cuando aparece dos veces, se promueve a patrón.
|
||
|
||
---
|
||
|
||
## Próxima revisión de este documento
|
||
|
||
**Fecha:** al cerrar Sprint 2.
|
||
|
||
**Qué actualizar:**
|
||
- Confirmar que el rebalanceo web/PDF se respetó en Sprint 2
|
||
- Evaluar si "criterio de wow" funcionó como herramienta operativa
|
||
- Refinar definiciones por consolidar (posicionamiento, métricas) con datos reales
|
||
- Capturar nuevas decisiones estratégicas surgidas durante el sprint |