--- type: PLAN asset_id: PLAN-EL-WORX-Posta-LabCasosJuan-v01 version: v01 status: Active · Para ejecutar mañana owner: Victor Heredia sherpa_owner: Jay fecha_creacion: 2026-05-26 fecha_sesion: 2026-05-27 intellbank: IB-EL-EmpowerLabs subbank: PB-EL-Project-Bank sub-subbank: PB-WORX-Worx proposito: Diseño de los casos demo del Mini-Lab basado en la llamada de 10 min con Juan · convierte sus dolores específicos en demos en vivo ejecutables origen: Llamada Victor-Juan · 2026-05-26 · 10 min · Juan listó casos específicos documentos_relacionados: - PLAN-EL-WORX-Posta-Bloque5-MiniLab-v01 - TP-EL-WORX-Posta-ScriptMaestro-v01 tags: [posta, demo, mini-lab, juan-insights, casos-validados] --- # 🎯 Los Casos Demo del Mini-Lab · Validados por Juan > Documento de **acción inmediata para mañana**. Convierte los 3 dolores que Juan articuló en 3 casos demo ejecutables. --- ## 🔍 Lo que Juan dijo en la llamada (síntesis) Juan, en 10 minutos, validó **3 dolores específicos** y dio ejemplos concretos. Estos NO son hipótesis — son los problemas reales que él (y por extensión el equipo de TI) viven todos los días. ### Dolor 1 — Reportes de avance en tiempo real **Cita textual de Juan:** > *"Yo poder reflejar el status del proyecto en tiempo real me ayudaría... que pudiéramos saber en tiempo real cómo está el proyecto, no andar tocando puertas y que te digan 'es que no está actualizado'..."* **Lo que duele específicamente:** - Él hace **reportes ejecutivos** — necesita status real, no maquillado. - *"Todo el mundo tiene que reportar"* → cuello de botella estructural. - Si alguien está de vacaciones, no puede tomar decisiones sin él. - *"Tomar decisiones en tiempo real, según pero concentrada, que refleje la verdad absoluta y no depender de las personas"* **La frase ancla de Juan:** > *"Nos daría más calidad de vida a todos."* --- ### Dolor 2 — Inventario y trazabilidad de casos de prueba (QA / testing) **Cita textual de Juan:** > *"Inventario de casos de pruebas unitarias en el equipo... varios tratando, ponen en un lugar cuáles son los casos de prueba que han corrido relacionados a las distintas User Stories... es un tema muy manual porque hay que entrar a Excel por Excel y revisarlo y a veces es un poco complicado..."* **Lo que duele específicamente:** - Equipos entregan código con **errores de producción**. - Validar si **cubrieron todos los casos de prueba** es manual, lento, propenso a error. - Casos están dispersos: Excel por Excel, gente por gente. - Conecta con **Jira** ("Yira") pero no hay engine para trazabilidad. **Ejemplo concreto que Juan dio (User Story de login):** > *"User Story: usuario del sistema, quiero poder iniciar sesión, introduzco usuario y password, el sistema me debe permitir entrar si es válido, si no debe mostrar mensaje de error."* **Lo que necesita:** - Un engine para arrastrar trazabilidad. - Asegurar cobertura suficiente de casos de prueba. - Feedback asertivo cuando algo se les fue. --- ### Dolor 3 — Revisión / auditoría de sistemas **Cita textual de Juan (respondiendo al caso MasterPlaybooks):** > *"En una hora me sacó todo... me hizo toda la revisión, me sacó todas las pruebas, me hizo un diagnóstico de qué mejoras había, cuestiones críticas, intermedias y medianas, me hizo un plan de trabajo y asignó trabajo..."* **Lo que duele específicamente:** - **Cientos de funcionalidades** sin listado actualizado. - Detectar **bugs y vulnerabilidades** es manual. - Mantener al día especificaciones de un sistema vivo es imposible humanamente. **Reacción de Juan al caso MasterPlaybooks:** > *"Ay güey... me encanta. Quería casos como estos para que mañana lo veamos."* --- ## 🏆 La frase de oro de Juan (que captura todo) > ***"Pues no se diga más. Si nos ponemos a dar cursos de IA y eso nos volvemos locos, porque ni trabajamos ni avanzamos ni desarrollamos nada."*** Esto es **la validación más fuerte que podríamos haber tenido** del frame "Identidad vs Herramienta + Lab de Innovación". Juan, sin saber, articuló exactamente nuestra tesis: la IA como herramienta de cursos NO funciona — necesitas un mecanismo que opere sobre tu trabajo real. --- ## 🎬 Los 3 Casos Demo Diseñados Estos son los 3 casos que ejecutamos mañana en el Mini-Lab. **No esperamos a que la audiencia los proponga — los presentamos como los casos que ya sabemos que les duelen.** --- ### 🟢 CASO A — "Status real en tiempo real" **Ataca el Dolor 1.** #### Setup pre-demo (preparar ANTES de la sesión) - [ ] Tener listo un proyecto "ficticio pero plausible" — por ejemplo un proyecto de TI tipo *"Migración de sistema de tickets a nueva plataforma"* - [ ] Tener el XDoc-prototipo abierto con cabecera lista (Owner, Sponsor, Runner, Dependencias semipobladas) - [ ] Pre-cargar a Jay con contexto sobre cómo se ve un status report ejecutivo #### Choreografía de ejecución (~10 min) **Paso 1 — Frame del caso (1 min)** > Victor: *"Juan me mencionó algo el otro día que me parece el caso perfecto para empezar. ¿Cuántos de ustedes hacen reportes ejecutivos cada semana? ¿Cuánto tiempo les toma? ¿Y qué tan cierto es el reporte cuando lo terminan?"* (Esperar respuesta breve de la sala — momento de complicidad.) **Paso 2 — Mostrar el XDoc vivo (3 min)** > Victor: *"Esto es lo que llamamos un 'documento operativo de proyecto'. Lo abro y ustedes ven el estado actual."* Abre XDoc · navega secciones: - Cabecera: Owner, Sponsor, Runner — *"Está claro quién es responsable de qué."* - Estado: salud 🟡, hito activo, **dependencias visibles** *(input pendiente de proveedor, aprobación legal, decisión de pricing del sponsor)* - NEXTs con responsable y deadline > Victor: *"Fíjense en lo importante: esta información se actualiza mientras la gente trabaja, no en una reunión de status. La dependencia que dice 'esperando aprobación legal' la puso el Runner cuando se atoró — no en un Excel paralelo que nadie consulta."* **Paso 3 — El reporte ejecutivo en vivo (4 min)** > Victor a Jay: *"Jay, con base en el XDoc del proyecto X, genérame un reporte ejecutivo de una página. Tono para el comité de dirección. Sin jerga técnica. Que incluya salud del proyecto, riesgos visibles, y la decisión pendiente que necesitamos del comité."* Jay devuelve el reporte. **Victor lo lee en voz alta.** > Victor: *"Lo que tomé en cinco segundos sería normalmente una hora de mi semana. Y la diferencia importante: no es 'parecido' al reporte que haría yo. Es **mejor** que el reporte que haría yo, porque incluye información que se me hubiera olvidado mencionar — las dependencias críticas, la decisión pendiente, los próximos hitos."* **Paso 4 — La consecuencia organizacional (2 min)** > Victor: *"Y aquí está la pieza que cambia todo. Si esto existe para cada proyecto vivo del equipo, el cuello de botella desaparece. Tú [Juan] dejas de ser el embudo. Cualquier persona de la dirección puede consultar el status real cuando lo necesite. Y cuando alguien está de vacaciones, los proyectos siguen visibles."* #### Output esperado del Caso A - 1 XDoc estructurado del proyecto - 1 reporte ejecutivo de 1 página - Mensaje implícito aterrizado: **"el cuello de botella del status se elimina por diseño"** #### Frase ancla del caso > *"Status real, sin tocar puertas."* --- ### 🟡 CASO B — "Cobertura de testing · El caso del login" **Ataca el Dolor 2.** #### Setup pre-demo (preparar ANTES de la sesión) - [ ] Tener el User Story de login (exacto el que Juan mencionó) en formato texto listo para pegar - [ ] Pre-cargar a Jay con la noción de matriz de cobertura de testing - [ ] *(Opcional/avanzado)* Tener un mock de export de Jira con algunos User Stories y casos de prueba dispersos #### Choreografía de ejecución (~12 min) **Paso 1 — Frame del caso usando el ejemplo de Juan (2 min)** > Victor: *"Juan me dio un ejemplo perfecto el otro día. Voy a usar el suyo: un User Story de login. Algo que parece trivial — pero que esconde un problema gigante de QA."* Victor dicta a Jay el User Story textual: > *"Jay, tengo un User Story: 'Como usuario del sistema, quiero poder iniciar sesión introduciendo usuario y contraseña, para acceder a mis datos. Si las credenciales son válidas, debe permitirme entrar. Si no son válidas, debe mostrar mensaje de error.'"* **Paso 2 — La matriz de casos de prueba requeridos (3 min)** > Victor: *"Jay, antes de revisar lo que el equipo probó, dime cuál es el conjunto MÍNIMO de casos de prueba que este User Story requiere para considerarse bien cubierto. Sé exhaustivo — incluye casos felices, casos de error, casos de borde, y casos de seguridad."* Jay devuelve algo así (lo que Jay debe producir): | # | Caso | Tipo | Esperado | |---|---|---|---| | 1 | Credenciales válidas | Happy path | Entra al sistema | | 2 | Usuario vacío | Validación | Error: campo requerido | | 3 | Password vacío | Validación | Error: campo requerido | | 4 | Ambos vacíos | Validación | Error: campos requeridos | | 5 | Usuario válido + password incorrecto | Error de credenciales | Error: credenciales inválidas | | 6 | Usuario inexistente | Error de credenciales | Error: credenciales inválidas (no exponer cuál fue el problema) | | 7 | Inyección SQL en usuario | Seguridad | Bloquea ataque, registra intento | | 8 | Brute force (N intentos en M minutos) | Seguridad | Bloquea cuenta temporalmente | | 9 | Usuario con espacios al final | Sanitización | Trim aplicado o error claro | | 10 | Login después de timeout de sesión | Estado de sesión | Forzar re-login | **Paso 3 — El cruce con Jira (4 min)** *(Si tienen Jira accesible en vivo, conectar. Si no, simular con un export.)* > Victor a Jay: *"Jay, ahora vamos a cruzar esta matriz con lo que el equipo realmente probó. Aquí está el export de Jira con los casos de prueba documentados para esta User Story."* (Si está conectado en vivo: Jay consulta Jira directamente.) (Si es simulación: Victor pega un export de muestra.) Jay devuelve el análisis de cobertura: > *"De los 10 casos requeridos, el equipo cubrió 6. Faltan: caso #7 (SQL injection), caso #8 (brute force), caso #9 (sanitización de espacios), caso #10 (timeout de sesión). De los faltantes, los #7 y #8 son críticos de seguridad."* **Paso 4 — El plan de acción generado en vivo (2 min)** > Victor: *"Jay, genera un plan de acción con los casos faltantes ordenados por criticidad, con sugerencia de quién en el equipo de QA puede tomar cada uno y deadline razonable."* Jay produce el plan. **Paso 5 — Aterrizar el insight (1 min)** > Victor: *"Lo que acabamos de hacer en 10 minutos sería, en su modelo actual: revisar Excel por Excel, preguntarle a cada miembro del equipo qué probó, armar la matriz a mano, identificar gaps. Probablemente 2-3 horas por User Story. Multiplicado por la cantidad de User Stories que tienen vivos, son días enteros."* #### Output esperado del Caso B - 1 matriz de casos de prueba requeridos - 1 reporte de cobertura actual vs requerida - 1 plan de acción con gaps priorizados - Mensaje implícito: **"la trazabilidad de QA deja de ser manual"** #### Frase ancla del caso > *"Cobertura de pruebas, sin Excel por Excel."* --- ### 🔴 CASO C — "Auditoría de sistema · El caso MasterPlaybooks" **Ataca el Dolor 3.** #### Modalidad Este caso lo presentamos como **caso real ya ejecutado**, no como demo en vivo. Lo contamos con el output que generamos previamente. **Por qué así:** la auditoría completa de un sistema toma tiempo de configuración previa. Pero **mostrar el resultado de la auditoría real que hicimos a MasterPlaybooks** es igual de impactante — y le ahorra a Victor el riesgo de hacerlo en vivo. #### Setup pre-demo (preparar ANTES de la sesión) - [ ] Localizar el output real de la auditoría que hicimos a MasterPlaybooks (Victor lo mencionó) - [ ] Tenerlo abierto/preparado para mostrar - [ ] Identificar 3-4 hallazgos específicos que vamos a citar (uno crítico, uno intermedio, uno menor) #### Choreografía de ejecución (~8 min) **Paso 1 — Frame del caso (1 min)** > Victor: *"Hace unos meses hicimos algo que les va a resonar. Tenemos una plataforma que se llama MasterPlaybooks — yo la conozco bien, es parte de lo que opero. Y como cualquier sistema vivo con cientos de funcionalidades, llega un momento en que pierdes la traza de qué hace exactamente y qué tan bien lo hace."* **Paso 2 — El problema del inventario (1 min)** > Victor: *"El problema no era falta de conocimiento — era que la gente que sabe tiene cosas más urgentes que documentar. El resultado: cientos de funcionalidades, ningún listado al día, ningún diagnóstico actualizado de bugs o vulnerabilidades."* **Paso 3 — La auditoría en una hora (4 min)** Aquí Victor muestra el output real. Idealmente abre el documento de auditoría que generamos. > Victor: *"Le pedí a Jay que hiciera una auditoría completa del sistema. En una hora —literal— me devolvió esto:"* Mostrar elementos del output: - **Listado completo de funcionalidades** detectadas - **Diagnóstico clasificado**: críticas / intermedias / medianas - **Plan de trabajo** con priorización - **Asignación de responsabilidades** propuesta > Victor: *"Cuestiones que me señaló: [3-4 ejemplos específicos]. De las críticas, dos eran de seguridad. De las intermedias, una era de performance. Las menores eran sobre todo UX."* **Paso 4 — Lo que esto significa para ustedes (1 min)** > Victor: *"Imagínense esto sobre sus propios sistemas. La plataforma X, la plataforma Y, el sistema interno Z. Cada uno con cientos de componentes. Cada uno con su propia deuda técnica acumulada. La auditoría que hoy les tomaría meses con consultores externos — y que probablemente no harían — está disponible en horas."* **Paso 5 — La invitación implícita (1 min)** > Victor: *"Y este es uno de los casos que podríamos ejecutar durante el piloto del Lab. Eligen un sistema, lo auditamos, generamos el plan de remediación. Como entregable concreto del Lab."* #### Output esperado del Caso C - Mostrar el documento real de auditoría MasterPlaybooks - Mensaje implícito aterrizado: **"lo que les tomaría meses, lo entregamos en horas"** #### Frase ancla del caso > *"Sistemas auditados, sin consultores externos."* --- ## 🎬 Cómo se integran al Mini-Lab del script maestro ### Cambio estructural respecto al diseño original **Antes (Bloque 5 original):** - 3 arquetipos abstractos (proyecto en limbo / junta improductiva / SOP no seguido) - Guided choice → la sala elige uno - Co-construcción del XDoc → cascada de entregables **Ahora (con los casos validados de Juan):** - 3 casos concretos que ya sabemos que les duelen - Anuncio directo: *"Estos tres casos los validé con Juan ayer..."* - Selección de uno o dos para profundizar - Co-construcción + cascada en el caso elegido ### Nueva sección 5.2 propuesta ``` 5.2 · Presentación de los 3 casos validados (3 min) Script: "Antes de la sesión platiqué con Juan unos minutos para que me ayudara a calibrar exactamente qué les serviría más. Me dio tres casos. Voy a presentarles los tres y elegimos uno o dos sobre los que vamos a trabajar en vivo: A — Status real de proyectos en tiempo real. El problema del cuello de botella en los reportes ejecutivos. B — Cobertura de testing. El problema de no saber si el equipo probó todo lo que el sistema requiere antes de soltar a producción. C — Auditoría de sistemas. El problema de no tener al día qué hace exactamente cada plataforma y qué bugs vive cargando. ¿Cuál les late más para trabajar en vivo ahora?" ``` ### Recomendación de orden de ejecución Si alcanza el tiempo, ejecutar **Caso A primero** (más fácil, más universal, más rápido) → **Caso B segundo** (más profundo, más técnico) → **Caso C como referencia** al cierre. Si no alcanza el tiempo, **Caso A solo + mencionar B y C** como otros casos disponibles en el piloto. --- ## ⚠️ Riesgos y contingencias ### Riesgo 1 — El Caso B requiere acceso a Jira en vivo **Mitigación:** Tener listo un export de muestra de Jira (anonimizado o simulado) que pueda usarse si no hay conectividad. El export puede tener 5-8 User Stories con casos de prueba parciales. ### Riesgo 2 — El Caso C requiere tener el output real de MasterPlaybooks **Mitigación:** Localizar/preparar el documento ANTES de la sesión. Si no se encuentra el original, regenerar una versión mostrable usando Jay. ### Riesgo 3 — La sala podría querer un caso de ellos, no de Juan **Mitigación:** Decir explícitamente *"Estos son los casos que Juan me ayudó a calibrar — si alguno de ustedes tiene un caso propio que les parezca más urgente, lo trabajamos. Lo importante es que sea real y suyo."* Esto convierte la pre-validación en flexibilidad. ### Riesgo 4 — Juan no está en la sala mañana **Mitigación:** Aún así referenciarlo como *"alguien del equipo me ayudó a calibrar los casos"* sin nombrarlo si no aplica. La fuerza del caso viene de la especificidad, no de la atribución. ### Riesgo 5 — El tiempo aprieta **Mitigación:** Caso A solo, en 10 min, completo. Caso B y C se vuelven "tenemos también casos sobre testing y auditoría — los pueden ver en el piloto". --- ## 📋 Pre-flight para Victor · 1 hora de prep Si Victor solo tiene 1 hora antes de la sesión, así se distribuye: ### 0-20 min — Preparación de assets - [ ] Localizar/regenerar el output de auditoría MasterPlaybooks (Caso C) - [ ] Crear/abrir el XDoc-prototipo de proyecto ficticio plausible (Caso A) - [ ] Tener el User Story de login listo en texto (Caso B) - [ ] Si hay tiempo: preparar export de Jira de muestra ### 20-40 min — Pre-carga de Jay - [ ] Test del prompt del Caso A — pedirle a Jay que genere el reporte ejecutivo y verificar calidad - [ ] Test del prompt del Caso B — pedirle la matriz de casos de prueba y verificar que cubra los 10 puntos - [ ] Verificar que Jay tiene contexto sobre cómo manejar el caso MasterPlaybooks ### 40-55 min — Ensayo rápido - [ ] Cronometrar Caso A end-to-end (target: 10 min) - [ ] Cronometrar Caso B end-to-end (target: 12 min) - [ ] Practicar las frases ancla de cada caso ### 55-60 min — Pre-flight técnico - [ ] Cerrar ventanas innecesarias - [ ] Confirmar conectividad - [ ] Confirmar Jay responde rápido - [ ] Confirmar archivos visibles no exponen "Posta" --- ## 🔥 La pieza estratégica importante Lo que Juan te dio **no es solo un guion de demos**. Es **prueba viva del valor del SherpaX antes de la sesión**. Considera mencionarlo así al inicio del Bloque 5: > *"Antes de empezar el Mini-Lab quiero contarles algo. Ayer tuve 10 minutos con Juan para que me ayudara a calibrar esta sesión. Le pedí que me diera ejemplos concretos de lo que les serviría más ver demostrado.* > > *De esa conversación de 10 minutos saqué tres casos específicos que vamos a trabajar. Y la razón por la que se los cuento: **esto que acaban de escuchar — los 10 minutos con Juan convertidos en una sesión calibrada en vivo — es exactamente lo que el sistema permite que pase cada día en una organización**. Conversaciones cortas que se vuelven trabajo estructurado. Lo que les voy a mostrar ahora es ese mismo principio, aplicado a casos suyos."* Esto convierte la llamada con Juan en **micro-caso de éxito** que justifica el resto de la sesión. --- ## 🎯 La cita más poderosa de Juan (para usar como cierre) Si en algún momento del Bloque 7 (cierre) Victor necesita un argumento final, Juan ya lo dio: > ***"Pues no se diga más. Si nos ponemos a dar cursos de IA, nos volvemos locos, porque ni trabajamos ni avanzamos ni desarrollamos nada."*** Esta cita es **interna del equipo** — viene de uno de los suyos. Validó nuestro frame entero antes de la sesión. Usarla con cuidado y respeto (atribuyéndola sin exponer): *"Alguien del equipo me dijo algo el otro día que captura esto perfectamente: 'si nos ponemos a dar cursos de IA, nos volvemos locos. Porque ni trabajamos ni avanzamos ni desarrollamos'."* --- ## 🔄 NEXTs → NEXT[@Victor]: Confirmar si Juan estará físicamente en la sesión de mañana → NEXT[@Victor]: Localizar el output real de la auditoría MasterPlaybooks o decidir regenerar versión mostrable → NEXT[@Victor]: Decidir si arrancamos con Caso A (más fácil) o con Caso B (más técnico, más impresionante para audiencia TI) → NEXT[@Jay]: Pre-cargar contexto sobre los 3 casos antes de la sesión → NEXT[@Jay]: Documentar este patrón — *"calibrar demos con audiencia objetivo antes de presentarlas"* — como caso LabPraxis post-sesión → NEXT[@Victor]: Considerar si vale la pena mencionar a Juan explícitamente o mantenerlo anónimo durante la sesión --- ## 📚 Material relacionado - `PLAN-EL-WORX-Posta-Bloque5-MiniLab-v01.md` — diseño original del Mini-Lab (este documento lo recalibra) - `TP-EL-WORX-Posta-ScriptMaestro-v01.md` — script maestro (Bloque 5 a actualizar con los 3 casos) - `TP-EL-WORX-Posta-JuanInsights-v01.md` — insights previos de Juan (de abril) --- ## 💬 Nota final Esta llamada de 10 minutos con Juan vale más que 10 horas de preparación. Te dio: 1. **Validación de la tesis "Identidad vs Herramienta"** (su frase sobre cursos) 2. **3 casos específicos con dolor articulado** (no hipótesis) 3. **Lenguaje exacto que usa la audiencia** (User Stories, Jira, Excel por Excel) 4. **Un campeón interno** que ya entendió y está en tu equipo de mañana **Mañana no es una sesión más. Es una sesión calibrada por la audiencia misma.** --- *PLAN-EL-WORX-Posta-LabCasosJuan-v01 · Jay (SherpaX) · 2026-05-26* *Sesión: 2026-05-27 · T-1*