Por qué la mayoría de los ganadores de un hackathon nunca se lanzan, y qué hacer después del hackathon

La mayoría de los ganadores de un hackathon nunca se lanzan porque el evento se diseñó para terminar, no para traspasar. La creencia de fondo es que una idea sólida, una vez que ha ganado en público, encontrará por sí sola patrocinador, presupuesto y equipo. Rara vez ocurre. Lo que funciona es decidir el responsable, el presupuesto y la fecha de decisión antes del evento, y después recorrer de forma deliberada un camino de 90 días del prototipo al piloto.

La creencia, expuesta con justicia

La creencia es esta: "Organizamos el hackathon, gana la mejor idea y la dirección, después de verla, la respaldará de forma natural. Las buenas ideas se venden solas".

No es una creencia absurda. Los hackathons generan energía real y algunos conceptos sólidos. Los altos directivos asisten a las presentaciones finales y a menudo dicen cosas alentadoras. Y hay historias conocidas de productos que nacieron en eventos de este tipo. Así que es razonable que los organizadores supongan que visibilidad más calidad equivale a adopción.

Por qué falla en la práctica

El lunes, el trabajo de nadie había cambiado. El equipo ganador vuelve a sus tareas habituales. Sus mandos no aceptaron liberarlos. El prototipo se queda en un portátil. La visibilidad generó buena voluntad, pero no tiempo, y sin tiempo nada avanza.

Un aplauso no es un presupuesto. Que un alto directivo diga delante de toda la sala "esto es excelente, vamos a llevarlo adelante" es un gesto social, no una decisión de financiación. El presupuesto del año siguiente se fijó hace meses, y en él no figura el nombre del ganador.

El prototipo se construyó sobre arena. Para terminar en 48 horas, los equipos simulan cosas: datos fijados en el código, seguridad omitida, un paso manual oculto tras una pantalla. Es la forma correcta de construir un prototipo, pero significa que la distancia entre la demo y la producción es mucho mayor de lo que cree la sala. Cuando el equipo de TI ve el código, la respuesta honesta es "habría que reconstruirlo", y el entusiasmo se evapora.

El jurado no eran los responsables. Muchos jurados se eligen por rango y visibilidad. Después, quienes tendrían que gestionar la solución, aquellos cuyos sistemas toca y cuyo personal la usaría, la ven por primera vez semanas más tarde, sin ningún interés en ella.

Ganar era la meta. A los equipos se les dijo que el objetivo era ganar. Una vez que han ganado, la historia está completa. Nadie les dijo que ganar era el comienzo de una prueba.

Ninguno de estos es un fallo de la idea. Son fallos de diseño: el evento se construyó para producir una ceremonia, y la produjo.

Lo que funciona

Antes del evento: preparar el aterrizaje

Las decisiones que más importan se toman semanas antes de que nadie escriba una línea de código.

1. Nombrar al responsable y la zona de aterrizaje. Una persona que llevará adelante al ganador, y la partida presupuestaria o el programa que lo absorberá. Cómo organizar un hackathon que produzca algo real lo llama el acuerdo de una página.
2. Acordar de antemano el tiempo liberado. Antes del evento, los mandos de los posibles participantes aceptan que los equipos ganadores dispongan de un tiempo definido, por ejemplo un día a la semana durante seis semanas.
3. Poner a los responsables en el jurado. El jurado incluye a quien gestionará la solución y a quien es responsable de los sistemas que toca. Conviene usar criterios que premien la facilidad de adopción, no solo la ambición; véase criterios de evaluación que eligen al ganador correcto.
4. Hacer un premortem. Se pregunta al equipo organizador: "Han pasado seis meses y nada de este hackathon se ha lanzado. ¿Por qué?". Un premortem suele sacar a la luz los problemas de acceso, presupuesto y liberación de tiempo cuando todavía hay margen para resolverlos.

Los 90 días siguientes

El periodo posterior al evento debe tratarse como un proyecto en sí mismo.

• Semanas 1–2: traspaso. El responsable se reúne con cada equipo seleccionado. Se acuerdan los roles con una matriz RACI, se confirma por escrito el tiempo liberado y se lista lo que se simuló en el prototipo.
• Semanas 2–4: identificar las creencias arriesgadas. Con un mapa de supuestos se ordena lo que el prototipo da por hecho sobre usuarios, sistemas y costes. Se eligen los dos más peligrosos.
• Semanas 4–8: ponerlas a prueba. Cada una se formula como una prueba de hipótesis con un umbral de aprobación fijado de antemano, y se prueba a pequeña escala con usuarios reales o datos reales.
• Semanas 8–12: decidir. Pasar a piloto con una lista de verificación de despliegue, adaptar y volver a probar, o parar. Los tres son buenos resultados si son deliberados.

Durante todo el proceso, hay que mantener informados a participantes y patrocinadores con un plan de comunicación con partes interesadas sencillo. El silencio después de un hackathon se interpreta, con razón, como abandono, y condiciona que la gente se apunte la próxima vez.

Hacer que parar sea respetable

Algunos ganadores no deberían lanzarse. Una prueba en la sexta semana puede mostrar que los usuarios no lo quieren o que el coste es demasiado alto. Es un buen resultado, obtenido a bajo coste. Hay que decirlo públicamente, reconocer al equipo lo que aprendió y dejarlo registrado. Cuando parar se trata como un fracaso, los responsables evitan la decisión y los proyectos se arrastran medio vivos, lo cual es peor que cualquiera de los dos desenlaces. Cómo detener bien un proyecto lo trata en detalle.

Ejemplo ilustrativo

Ilustrativo. Un grupo hospitalario universitario de los Países Bajos organizó un hackathon interno para reducir las citas de consultas externas perdidas. El equipo ganador, dos enfermeras, una persona de programación de citas y un desarrollador, construyó un flujo de recordatorios que permitía a los pacientes cambiar la cita con una sola respuesta. El director de operaciones lo elogió desde el escenario. Tres meses después, no había pasado nada: el desarrollador se había ido a otro proyecto y nadie era responsable del sistema de mensajería a pacientes.

Al año siguiente, el grupo cambió el diseño, no el evento. La jefa de consultas externas fue nombrada responsable antes de abrir las inscripciones. Los mandos aceptaron un día a la semana durante ocho semanas para los ganadores. El responsable del sistema de mensajería formó parte del jurado. Después del evento, el equipo ganador hizo una retrospectiva del prototipo, mapeó sus supuestos y puso a prueba el más arriesgado, si los pacientes mayores responderían a un SMS, en una consulta. Respondieron, en su mayoría. En la semana doce, el piloto se amplió a tres consultas.

Errores comunes

• Anunciar un ganador sin anunciar un siguiente paso. Siempre hay que decir qué pasará y en qué fecha.
• Tratar el premio como la recompensa. Para la mayoría de los equipos, la recompensa real es ver su trabajo en uso. Un premio en metálico sin un camino les dice que su trabajo no importaba.
• Dejar que el prototipo se convierta en el producto. Una vez probado el concepto, hay que reconstruirlo bien; no estirar el código del hackathon hasta producción.
• Olvidarse de los equipos que no ganaron. Sus hallazgos suelen contener la mejor evidencia del evento. Hay que recogerlos.
• Organizar el siguiente hackathon antes de que los ganadores del anterior tengan una decisión. La gente se da cuenta. 9 errores que los organizadores de hackathons siguen repitiendo amplía la lista.

Preguntas frecuentes

¿Qué debe pasar después de un hackathon? En un plazo de dos semanas, el responsable designado debe reunirse con los equipos seleccionados, acordar roles y tiempo, y listar lo que el prototipo simulaba. Después, se ponen a prueba los supuestos más arriesgados durante los dos meses siguientes y se toma una decisión clara: pilotar, adaptar o parar.

¿Por qué fracasan los proyectos de un hackathon después del evento? Normalmente porque nadie es responsable de ellos, no tienen presupuesto asignado y el equipo no tiene tiempo liberado de su trabajo habitual. La idea rara vez es el problema; lo es la falta de traspaso.

¿Cómo se mantiene el impulso después de un hackathon? Reservando la primera reunión de seguimiento antes de que termine el evento, comunicando los avances a los participantes cada pocas semanas y publicando la decisión sobre cada ganador, también cuando se para. El impulso nace de decisiones visibles, no del entusiasmo.

Hacia dónde seguir

Las guías que llevan un prototipo más allá del evento son el premortem, el mapa de supuestos, la prueba de hipótesis y la lista de verificación de despliegue. Para el mapa completo de formatos, véase todos los tipos de hackathon y jam explicados.