CAVA Soft- Header (10-second read)
- Result-oriented title, not the event's name.
- Anchor metric: a single number, with timeframe and caveat.
- Role in one line (the detail lives in My responsibility).
- Capabilities demonstrated: 3-4 maximum, taken from the shared taxonomy, never adjectives invented per case.
- Context line: organization, period, scale.
- Context (2-3 lines): starting situation, scale, and constraints.
- Problem: what was broken and why it was systemic, not just operational.
- My responsibility: two explicit lists, "I was responsible for..." and "I was not responsible for...". Delimiting scope reduces the evaluator's uncertainty more than any other section.
- System built: decisions and system design, in first person, active verbs, short sentences. System includes programs, governance, processes, and partnerships, not just software or automation.
- Architecture (optional subsection): only when there's an actual technical design to show.
- Trade-offs (optional): why this path and not another. 1-2 decisions maximum per case. Example: Voice AI → WhatsApp in SOFI.
- Results: 2-4 metrics, each with timeframe, caveat, and type label (business or operations). No rigid subsections: if a case has no business metric, none is forced.
- Evidence block (✔/✖): table with claim, status, and artifact (link, dashboard, diagram, or testimonial). If there's no artifact, explicit ✖; the row is never omitted.
- Autopsy (depth): what failed or what I'd do differently. The headline is the lesson, with no "autopsy" label. Closes with a transferability line: what part of this is repeatable in another organization.
- Archive: links to the original edition entries (Archive layer). History is preserved, not shown in the main read.
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.
