Notas de facilitación¶

Cuatro principios que sostienen el curso —valen igual para el formato recomendado de 2 clases de 4 h y para el compacto de 2×105 min; donde abajo se dice «Sesión 1/2» o «Talleres 1 y 2», léase también «Clase 1/2» y el Taller 3 en el formato de 4 h—. Léelos antes de impartir y tenlos presentes sobre todo en los talleres.

1. Ritmos dispares: la mayor fuente de fricción¶

En un grupo de directivos, la distancia entre el más rápido y el más lento es enorme, y en las sesiones prácticas se nota. Prepara las dos puntas:

Para quien termina rápido: ten lista una extensión concreta.
Taller 1: mapear un segundo proceso, o añadir al mapa el punto exacto donde exigiría validación humana.
Taller 2: una tercera iteración (añadir una función nueva, no solo estética) o probar el prototipo en el móvil.
Para quien se atasca: un facilitador de apoyo que circule por la sala. Si impartes en solitario, identifica en el bloque de prompting a 1–2 participantes ágiles y pídeles discretamente que hagan de «vecino que ayuda» en los talleres.
Señales de atasco típicas en el Taller 2: no pasar del inicio de sesión (contraseñas olvidadas, cuenta equivocada), quedarse mirando la pantalla sin escribir el prompt fundador, o una espiral de errores con la herramienta. En los tres casos: intervenir antes del minuto 3, no esperar a que pidan ayuda.

2. El trabajo en parejas no es relleno¶

En andragogía corporativa, verbalizar y negociar con un par consolida el aprendizaje y simula la conversación real que estos directivos tendrán con sus equipos de operaciones. Por eso:

La micro-práctica de prompting (Sesión 1, bloque 2) y el intercambio del Taller 1 se hacen siempre en parejas, aunque vayas mal de tiempo.
Empareja perfiles y departamentos distintos: la fricción de explicar tu proceso a alguien que no lo conoce es exactamente el ejercicio.
Da un guion mínimo a la pareja que escucha («¿qué parte requiere tu juicio?», «¿qué pasa si la IA se equivoca aquí?») para que la conversación no derive en anécdota.

3. Energía y fatiga¶

Vigila la curva de energía: los bloques más exigentes (Taller 1 y, sobre todo, Taller 2) necesitan al grupo despierto. Introduce un energizante breve antes si notas la sala plana.
Prefiere el formato de dos días siempre que puedas negociarlo: separa las sesiones (mejor retención por espaciamiento) y evita que construir software en vivo caiga tras más de tres horas de curso.
En formato intensivo: energizante de 5 minutos obligatorio tras la pausa, y protege el margen de los talleres frente a cualquier desborde teórico.
Tras la comida o a última hora, acorta tus monólogos: pasa antes a la práctica.

4. Menos es más¶

En contenido teórico, es mejor enseñar pocas técnicas bien practicadas que muchas escuchadas una sola vez. Por eso la Sesión 1 enseña una sola fórmula de prompting y la practica de inmediato, y deja el «contexto seguro con etiquetas» en el kit (se menciona, no se enseña).
Resiste la tentación de añadir herramientas, casos o trucos sobre la marcha: cada minuto de teoría extra sale del taller, que es donde ocurre el aprendizaje.
Si un participante pregunta por un tema avanzado (APIs, agentes complejos, modelos locales), respuesta corta + «lo vemos al final si queda tiempo» + apuntarlo en un parking visible.

Recordatorios rápidos¶

El mapa del Taller 1 se guarda: es la base del reto de 30 días. Dilo explícitamente al cerrar el taller.
En la demo, si algo se atasca más de 2 minutos: plan B (proyecto pre-construido o grabación). El objetivo es mostrar el ciclo, no terminar el producto.
El resultado del Taller 2 puede ser modesto: encuádralo desde el principio (relato honesto de Pastor, TrendFeed como excepción) para que nadie salga frustrado.