9 errores que los organizadores de hackathons siguen repitiendo

La mayoría de los hackathons que decepcionan fracasan por el mismo puñado de motivos, y casi ninguno ocurre durante el evento. Se deciden semanas antes, cuando se redacta el reto, se elige al jurado y nadie queda designado como responsable de lo que salga. Estos son los nueve errores que aparecen una y otra vez, y qué hacer en su lugar.

Los nueve errores

1. Organizar un hackathon porque alguien quiere un hackathon. Se reserva el evento antes de que nadie haya preguntado para qué sirve. Llegan una fecha, un espacio y un hashtag; el propósito, no. Sin propósito no se puede redactar un reto, elegir un jurado ni decidir qué es un buen resultado, así que cada decisión posterior es una conjetura. En su lugar: antes que nada, escribe una frase: «Después de este evento queremos tener ___, y ___ actuará en consecuencia». Si no puedes rellenar los dos huecos, quizá necesites otro formato. La comparación entre hackathon, design jam o reto de innovación ayuda a comprobarlo.

2. Un tema en lugar de un reto. «Ciudades inteligentes», «el futuro de la banca», «sostenibilidad». Los temas parecen generosos porque dejan margen, pero los equipos pasan las primeras seis horas discutiendo en qué trabajar y acaban construyendo lo que ya sabían construir. En su lugar: plantea a los equipos un problema real, con un responsable real y una restricción real. Un buen reto dice a quién afecta, qué está fallando y qué queda fuera de la mesa. Explicamos el oficio en cómo redactar un reto que la gente quiera resolver. Un árbol de problemas elaborado de antemano con el responsable del reto es la forma más rápida de encontrar el nivel adecuado.

3. Nadie responsable de lo que salga. Este es el error que explica por qué tantos ganadores nunca llegan a lanzarse. Un equipo gana, recibe un trofeo, se dan la mano y el domingo por la mañana no hay partida presupuestaria, ni patrocinador, ni siguiente reunión. En su lugar: antes del evento, nombra a la persona que recibirá el trabajo ganador y acuerda qué está dispuesta a hacer con él: un piloto, un desarrollo de 90 días, una prueba financiada. Incluye ese compromiso en el briefing para que los equipos sepan por qué compiten. El seguimiento completo está en qué hacer después del hackathon.

4. Criterios de evaluación anunciados en el pitch. Cuando los equipos solo conocen los criterios en la presentación final, optimizan para lo que suponen que le gusta al jurado, normalmente diapositivas y acabado. Después el jurado discrepa porque cada miembro aplica en silencio sus propios criterios. En su lugar: publica los criterios junto con el reto, explica en palabras sencillas qué significa cada uno y repásalos con el jurado el día anterior. Pondéralos según el propósito que escribiste en el error 1. Nuestro artículo sobre criterios de evaluación que eligen al ganador correcto entra en hojas de puntuación y calibración; una matriz de decisión ponderada es la estructura más sencilla para empezar.

5. Mentores que solo aparecen para la foto. Una lista de nombres impresionantes no es un programa de mentoría. Los perfiles senior que pasan veinte minutos, dan tres opiniones contradictorias y se van hacen más mal que bien, porque los equipos cambian de rumbo para complacerlos. En su lugar: recluta menos mentores, da a cada uno un papel claro (dominio, técnico, usuario, pitch), organiza su tiempo en franjas y diles que su trabajo es hacer preguntas, no rediseñar la idea. Más en mentores en un hackathon: cómo es hacerlo bien.

6. Sin acceso a las personas ni a los datos de los que trata el reto. Se pide a los equipos que mejoren un servicio para pacientes, ciudadanos o clientes que no están en el edificio, con datos de muestra que no se parecen en nada a los reales. Terminan resolviendo un problema imaginado. En su lugar: ten usuarios reales disponibles durante el primer día (con tres o cuatro basta) y prepara con tiempo un conjunto de datos realista y depurado. Si hacen falta revisiones legales o de privacidad, empiézalas la semana en que fijas la fecha, no la semana del evento.

7. Premiar el mejor pitch en lugar del mejor trabajo. La última hora es teatro. Ganan los equipos con un presentador seguro y una presentación vistosa, mientras que un equipo que probó su idea con cinco usuarios y cambió de rumbo dos veces pierde porque sus diapositivas eran sobrias. En su lugar: pide a cada equipo evidencias: qué probaron, con quién, qué cambió. Da al jurado tiempo con el prototipo de cada equipo antes de los pitches. Limita las diapositivas. Buscas la idea que más merece la pena desarrollar, no al mejor intérprete.

8. Demasiado corto para construir, demasiado largo para mantener la lucidez. Algunos organizadores meten un hackathon en una tarde; otros lo alargan durante tres días agotadores sin estructura. Lo primero produce bocetos; lo segundo, gente cansada que deja de pensar con claridad la segunda noche. En su lugar: ajusta la duración a lo que esperas al final. Un concepto probado necesita aproximadamente día y medio de trabajo efectivo. Un prototipo funcional con datos reales necesita más, y necesita puntos de control para que los equipos no se desvíen. Construye la agenda hacia atrás desde la demo final.

9. Ningún registro de quién hizo qué. Cuando termina el evento, la única huella es la foto de los ganadores. Los participantes que hicieron un trabajo serio, incluidos los de equipos que no ganaron, se van sin nada que mostrar, y la organización pierde la pista de a quién debería volver a invitar o implicar en el piloto. En su lugar: documenta el planteamiento del problema de cada equipo, qué probaron, qué construyeron y quién aportó qué. Envíalo a los participantes y a sus responsables. Es la forma más barata de conseguir que la gente quiera volver.

Qué hacer y qué no

Qué hacer

• Escribe el propósito y el compromiso posterior al evento antes de reservar nada.
• Haz un premortem con el equipo organizador: «Han pasado tres meses y el hackathon no ha conseguido nada. ¿Por qué?».
• Publica a la vez el reto, los criterios y los premios.
• Reserva en la agenda del responsable receptor la semana siguiente al evento.
• Usa una lista de verificación de despliegue para la logística, de modo que la energía del equipo organizador vaya al reto y no al catering.

Qué no hacer

• No dejes que el patrocinador redacte el reto en solitario; debe darle forma quien convive con el problema.
• No invites a miembros del jurado que no hayan leído el reto.
• No prometas una implantación que no puedes financiar.
• No uses el número de participantes como medida del éxito.

Ejemplo ilustrativo

Ilustrativo. Una autoridad regional de transporte público de una ciudad europea mediana organizó su primer hackathon sobre «mejor movilidad». Acudieron ochenta personas, doce equipos presentaron y el equipo ganador construyó una app de planificación de rutas muy parecida a tres que ya estaban en el mercado. Nadie quedó encargado de llevarla adelante.

Para el segundo evento, los organizadores empezaron de otra manera. Primero escribieron el propósito: encontrar una forma de reducir el número de pasajeros que se quedan tirados de noche cuando pierden el último enlace, algo que el director de operaciones aceptó pilotar en dos líneas. Celebraron una sesión de árbol de problemas con conductores y personal del centro de control, y después redactaron el reto como una pregunta ¿Cómo podríamos? con las restricciones explícitas: sin vehículos nuevos, sin app nueva. Los criterios se publicaron con el briefing. Tres conductores del turno de noche estuvieron disponibles durante el primer día. El concepto ganador, una regla sencilla de espera y aviso entre conductores y centro de control, entró en piloto al mes siguiente con el director de operaciones como responsable.

El segundo evento fue más pequeño. También fue el primero que cambió algo.

Preguntas frecuentes

¿Cuál es el motivo más habitual por el que fracasan los hackathons? Que nadie es responsable del resultado. Las ideas sin alguien dispuesto a financiarlas o pilotarlas se detienen en cuanto termina el evento, por buenas que sean. Resuelve esto antes que cualquier otra cosa.

¿Cuántos miembros necesita el jurado de un hackathon? Normalmente bastan entre tres y cinco. Más ralentiza la deliberación y diluye la responsabilidad. Lo importante es que al menos uno de ellos sea la persona que se hará cargo después de la idea ganadora.

¿Un hackathon debe tener un reto o varios? En un evento interno, uno o dos retos bien redactados suelen funcionar mejor que cinco difusos. Varios retos tienen sentido cuando cada uno cuenta con su propio responsable y sus propios recursos listos para actuar después.

Por dónde seguir

Empieza por el mapa completo de formatos en hackathons, jams y retos: todos los tipos explicados, y después el paso a paso de cómo organizar un hackathon que produzca algo real. Para la preparación, las guías de árbol de problemas, ¿Cómo podríamos? y premortem cubren casi todo lo que sale mal, y la matriz de decisión ponderada da al jurado una estructura justa.