Resumen

• Empieza a planificar con seis semanas de antelación. Lo que hace o deshace la jornada es el calendario, no la tecnología.
• Elige un tema lo bastante acotado como para que un equipo arranque en cinco minutos, y lo bastante abierto como para admitir diez respuestas distintas.
• Forma equipos equilibrados de tres o cuatro personas a propósito. No dejes que los grupos de amigos se elijan solos.
• Publica la rúbrica de evaluación antes de que nadie escriba una línea de código, y da más peso al "funciona" que al acabado.
• Premia el esfuerzo, el trabajo en equipo y una demostración clara, no solo a quien programa más rápido.

Qué es realmente una hackathon escolar

Una hackathon escolar es un evento corto e intensivo en el que el alumnado forma equipos pequeños, elige un problema y construye un prototipo funcional contrarreloj. Esa es toda la idea: mucho hacer, un plazo fijo y una demostración al final. Puede celebrarse en una sola mañana o repartirse en varias sesiones de club, y funciona desde los últimos cursos de primaria hasta el final de secundaria, siempre que ajustes el alcance a la edad.

La receta es fácil de describir y fácil de estropear. Da al alumnado un tema claro, equipos equilibrados, una rúbrica que puedan ver y el hardware justo para construir algo real. Todo lo que sigue recorre esa receta desde seis semanas antes hasta la entrega de premios.

Elige un formato que encaje con tu centro

Decide la forma del evento antes que ninguna otra cosa, porque condiciona todo el calendario. Una hackathon no tiene por qué ser un maratón. Para la mayoría de los centros la elección honesta está entre tres formatos, y cada uno te da algo a cambio de un coste.

Formato	Bueno para	Ventaja	Ojo con
Sprint de media jornada (unas tres horas)	Principiantes y cursos más jóvenes	Fácil de cubrir con personal, cabe en una mañana, poco en juego	Los equipos apenas terminan, así que el encargo tiene que ser mínimo
Jornada escolar completa	Un curso entero o una muestra del club	Tiempo para una construcción de verdad y demostraciones en condiciones	La energía cae después de comer, así que planifica descansos y comida
Varias sesiones (unas semanas de horario de club)	Proyectos más profundos y ambiciosos	Menos agobio, margen para iterar y probar	Se pierde impulso entre sesiones, y los proyectos a medias necesitan un sitio seguro donde guardarse

Si es tu primer intento, haz el sprint de media jornada. Un evento pequeño que termina bien enseña más que un fin de semana que se derrumba a la sexta hora.

La cuenta atrás de seis semanas

La mayor parte del trabajo es logística, y la logística premia el calendario. Esta es una cuenta atrás pensada para un evento único durante el tercer trimestre, pero las fases se adaptan a cualquier fecha.

De seis a cuatro semanas antes

Cierra la fecha, el aula y el formato. Acuérdalo con quien comparta el espacio y compruébalo frente a exámenes y competiciones deportivas. Redacta ya el tema y la rúbrica, mientras tienes tiempo para pensar, no la noche anterior. Calcula a grandes rasgos cuántos alumnos esperas y cuántos adultos puedes poner en el aula. Apunta a un mentor por cada tres o cuatro equipos para que nadie se quede atascado veinte minutos.

De tres a dos semanas antes

Abre las inscripciones y forma los equipos. Envía a las familias una nota breve sobre horarios, comida y qué llevar. Cuenta el hardware y carga todo al menos una vez para descubrir ahora la batería muerta, y no el día del evento. Recluta al jurado pronto, porque los adultos ocupados necesitan aviso. Imprime o comparte la rúbrica para que el alumnado pueda leerla antes de llegar.

La última semana

Haz un ensayo con exactamente la tecnología que usará el alumnado: iniciar sesión, abrir el editor, conectar una placa, ejecutar un programa. Si falla en tu ordenador, fallará en treinta. Prepara una escaleta sencilla con los horarios y pégala en la pared. Resuelve el tema de los kits de reserva, los cables y los cargadores, y etiqueta una caja para todo ello.

El día del evento

Empieza con una charla de diez minutos: el tema, las reglas, la rúbrica y cuándo se para el reloj. Y después, apártate. Mantén una cuenta atrás visible, avisa del ecuador y da un aviso firme quince minutos antes del cierre de código. Reserva el último bloque para las demostraciones y la evaluación, para que la jornada no se alargue.

Fija un tema con límites

Un buen tema es una valla, no una jaula. Demasiado vago ("construid algo chulo") y la mitad de los equipos pasan una hora decidiendo qué hacer. Demasiado cerrado ("construid un robot seguidor de línea que gire dos veces a la izquierda") y todos los proyectos serán iguales. Busca un enunciado con un sujeto claro y mucho margen, como "ayudad a alguien de nuestro centro", "haced nuestra aula más segura" o "algo que reaccione a su entorno".

Da a cada equipo un encargo de una página con el tema, las restricciones, el plazo y la rúbrica. Añade dos o tres ejemplos de dirección posible para que los equipos más inseguros tengan un punto de partida, y deja claro que son semillas, no las únicas opciones.

Forma los equipos a propósito

Los equipos de tres o cuatro son el punto óptimo. A las parejas se les acaban las ideas y los papeles; en los grupos de cinco alguien se queda sin hacer nada. Resiste la tentación de dejar que el alumnado elija su grupo, porque los grupos de amigos tienden a separarse entre los seguros de sí mismos y los que quedan fuera. Mezcla niveles de experiencia y pon en cada equipo al menos a un alumno que ya haya programado y a otro que no.

Reparte papeles ligeros para que nadie se esconda: constructor, programador, encargado de notas y quien presenta, rotando si quieres. Los papeles importan sobre todo en la demostración, cuando un equipo callado con un gran proyecto puede perder igualmente porque nadie preparó cómo explicarlo.

Evalúa con una rúbrica que el alumnado pueda ver

La mayor mejora en equidad es enseñar la rúbrica antes de que el alumnado empiece. Convierte la evaluación de un misterio en una diana. Limítala a un puñado de criterios, puntúa cada uno en una banda pequeña, por ejemplo de cero a cinco, y da peso a los que premian el trabajo real.

• ¿Funciona? Algo tosco que funciona gana a algo precioso que no. Dale el mayor peso.
• Ajuste al problema. ¿La construcción responde de verdad al tema, o el equipo se desvió hacia una misión secundaria vistosa?
• Creatividad. Premia un enfoque poco habitual, no simplemente más funciones.
• Trabajo en equipo. ¿Podría cada integrante explicar una parte? Esto desincentiva discretamente que un solo alumno lo haga todo.
• Demostración. Una explicación clara de noventa segundos con una ejecución en directo.

Indica al jurado que haga preguntas en lugar de buscar fallos, y que trate igual a todos los equipos. Dos jueces por equipo, puntuando por separado y comparando después, suavizan al evaluador duro y al blando.

Hardware y logística

El hardware es donde mueren en silencio los buenos planes, así que trátalo como una tarea en sí misma. Calcula qué necesita cada equipo y añade un margen. Un juego de aula de diez kits para ocho equipos deja dos de reserva para cuando —no si— algo se rompa. Carga todo el día antes, etiqueta los cables y ten una caja de reparaciones con cables sueltos, un destornillador y cinta.

Las placas programables mantienen la hackathon en el terreno físico, en vez de encerrarla en una pantalla. Un conjunto homogéneo, como la placa sheenbot∞, significa un único juego de instrucciones y un único proceso de inicio de sesión que enseñar, en lugar de cinco configuraciones distintas que depurar a la vez. Si estás ampliando un juego de aula o sustituyendo cables gastados, los repuestos y kits de la tienda te ahorran las prisas de la semana anterior. Uses lo que uses, estandariza una sola plataforma para que tus mentores no se pasen el día traduciendo entre sistemas.

Una nota sobre la electricidad para las aulas sudafricanas. Cuenta con los cortes programados de luz: conoce tu franja horaria, carga con antelación y ten preparada una tarea de reserva sin enchufes para que un corte de dos horas no hunda el evento.

Premios que importan

Los premios marcan el tono, así que ten cuidado con lo que recompensas. Si el único trofeo va al montaje más pulido, enseñas a todos los demás que perdieron el día. Reparte el reconocimiento entre varias categorías para que más equipos se vayan sintiéndose vistos: mejor solución al tema, idea más creativa, mejor trabajo en equipo, mejor demostración y un premio del jurado para el equipo que se sobrepuso a un desastre.

Mantén los premios en sí modestos. Diplomas, un pequeño componente de kit o el derecho a hacer la demostración en el acto de todo el centro funcionan igual de bien. Lo que el alumnado recuerda de verdad es que le llamen y le nombren su trabajo, no el valor del objeto.

Modos de fallo habituales

• Alcance desbordado. Los equipos planean una catedral y terminan un marco de puerta. Insiste en que todos definan una "versión mínima que funcione" en la primera media hora.
• El polizón silencioso. Los papeles y el criterio de trabajo en equipo lo detectan, pero un mentor también debería fijarse en el alumno que se ha quedado callado y traerlo de vuelta.
• Tecnología que falla al arrancar. Noventa minutos perdidos en inicios de sesión es el clásico. El ensayo de la última semana existe precisamente para evitarlo.
• Una evaluación que parece aleatoria. Una rúbrica visible y dos jueces por equipo arreglan casi todas las quejas.
• Sin tiempo para presentar. Si los equipos construyen hasta que suena el timbre, las demostraciones desaparecen y el aprendizaje con ellas. Protege el último bloque sin contemplaciones.

Conclusión

Una hackathon escolar es sobre todo gestión de proyectos con un reloj en cuenta atrás. Empieza seis semanas antes, elige un formato que puedas cubrir con personal, fija un tema con límites, forma los equipos a propósito y evalúa con una rúbrica que todo el mundo haya visto. Acierta en eso y la tecnología casi se cuida sola. Si prefieres ver el ritmo antes de organizar la tuya, nuestros talleres de vacaciones siguen la misma estructura de construir y demostrar a menor escala, y puedes leer más notas para organizadores en la sala de prensa.

Preguntas frecuentes

¿Cuánto debería durar una primera hackathon escolar?

Media jornada. Unas tres horas concentradas bastan para que los equipos más jóvenes construyan algo y lo presenten sin quemarse, y es lo bastante corta como para poder cubrirla con personal y recuperarte si la tecnología se porta mal. Pasa a una jornada completa solo cuando ya hayas organizado una y conozcas tus cuellos de botella.

¿El alumnado necesita saber programar antes?

No todo el mundo. Los equipos mixtos funcionan mejor, con al menos un alumno que ya haya programado para desatascar al resto. Si la mayoría son novatos, haz una sesión corta de calentamiento con las mismas herramientas una semana antes, para que la hackathon vaya de ideas y no de aprender a iniciar sesión. Una clase de prueba es una forma poco comprometida de medir el nivel de un grupo antes de planificar el evento.

¿Cuántos mentores necesito?

Aproximadamente un adulto por cada tres o cuatro equipos. Con menos, el alumnado se queda atascado; los mentores están para preguntar y empujar, no para construir. El alumnado mayor y un par de madres o padres voluntarios también cuentan.

¿Y si se va la luz a mitad del evento?

Da por hecho que pasará y planifica en consecuencia. Carga placas y portátiles el día antes, conoce tu franja de corte programado y ten lista una tarea sin electricidad, como esbozar el diseño o preparar la demostración, para que un corte sea una pausa y no el final de la jornada.

¿Debería haber un único ganador?

Mejor varias categorías que un gran premio único. Mejor ajuste al tema, más creativo, mejor trabajo en equipo y mejor demostración permiten que más equipos se lleven algo, y premian las conductas que realmente quieres. Un único ganador le dice a todos los demás equipos que el día fue una pérdida de tiempo.