CAVA Soft- Encabezado (lectura de 10 segundos)
- Título orientado a resultado, no al nombre del evento.
- Métrica ancla: un solo número, con timeframe y caveat.
- Rol en una línea (el detalle vive en Mi responsabilidad).
- Capacidades demostradas: máximo 3-4, tomadas de la taxonomía compartida, nunca adjetivos inventados por caso.
- Línea de contexto: organización, periodo, escala.
- Contexto (2-3 líneas): situación inicial, escala y restricciones.
- Problema: qué estaba roto y por qué era sistémico, no solo operativo.
- Mi responsabilidad: dos listas explícitas, "Era responsable de..." y "No era responsable de...". Delimitar el alcance reduce la incertidumbre del evaluador más que cualquier otra sección.
- Sistema construido: decisiones y diseño del sistema, en primera persona, verbos activos, frases cortas. Sistema incluye programas, gobernanza, procesos y alianzas, no solo software o automatización.
- Arquitectura (subsección opcional): solo cuando exista un diseño técnico que mostrar.
- Trade-offs (opcional): por qué este camino y no otro. Máximo 1-2 decisiones por caso. Ejemplo: Voice AI → WhatsApp en SOFI.
- Resultados: 2-4 métricas, cada una con timeframe, caveat y etiqueta de tipo (negocio u operación). Sin subsecciones rígidas: si un caso no tiene métrica de negocio, no se fuerza.
- Bloque de evidencia (✔/✖): tabla con afirmación, estado y artefacto (enlace, dashboard, diagrama o testimonio). Si no hay artefacto, ✖ explícito; nunca se omite la fila.
- Autopsia (profundidad): qué falló o qué haría distinto. El titular es la lección, sin etiqueta "autopsia". Cierra con una línea de transferibilidad: qué de esto es repetible en otra organización.
- Archivo: enlaces a las fichas de edición originales (capa Archivo). Se conserva el historial, no se muestra en la lectura principal.
Lo que aprendí construyendo esta app trasciende la herramienta: 1. No necesitas ser experto en código, pero sí en contexto: mi verdadero stack fue la experiencia en metodologías ágiles, UX básico y liderazgo de proyectos tecnológicos. 2. Lo más difícil no fue la tecnología, fue priorizar: decidir qué no construir también es construir. 3. El pensamiento computacional es esencial aunque no haya código: flujos, condicionales y estructuras de bases de datos. 4. El no-code no reemplaza a los desarrolladores; habilita más ideas y abre una etapa más democrática y exploratoria del desarrollo de productos. Transferibilidad: el método aplicado (brief y centro de control en Notion, flujo antes que herramienta, MVP e iteración con usuarios reales) es replicable en cualquier organización que quiera validar soluciones digitales sin invertir en desarrollo tradicional.
