Hackathons, jams y retos: todos los tipos explicados

Existen alrededor de una docena de tipos de eventos de innovación con tiempo acotado, y se diferencian en tres cosas: quién participa, qué se espera que produzcan y qué pasa después. Un hackathon construye software o hardware que funciona; una jam diseña y prototipa un servicio o una experiencia en torno a un tema; un reto de innovación invita a presentar soluciones a un problema planteado a lo largo de semanas o meses. El tipo se elige por el resultado que hará falta el lunes por la mañana, no por el nombre que suena más emocionante.

Esta guía recorre todos los formatos habituales, explica en qué destaca y en qué falla cada uno, y remite a los artículos más detallados de esta sección.

Las tres preguntas que ordenan todos los formatos

Antes de los nombres, la lógica. Cada evento de esta familia responde de forma distinta a tres preguntas.

1. ¿Quién está en la sala? El propio personal (interno), socios invitados (ecosistema) o cualquiera que se inscriba (abierto).
2. ¿Qué cuenta como terminado? Código que funciona, un objeto físico, un prototipo de servicio probado, un análisis de datos o un concepto bien argumentado.
3. ¿Cuánto dura el reloj? Un solo día, las clásicas 48 horas o un reto que se prolonga durante semanas por fases.

Si se pueden responder esas tres preguntas para la situación concreta, el formato casi se elige solo. Quienes organizan sin hacérselas acaban montando un "hackathon" cuyo objetivo real era el compromiso de los empleados, y luego se preguntan por qué no sale nada adelante. Para una decisión comparada, véase hackathon, design jam o reto de innovación.

Hackathons: construir cosas rápido

La palabra se remonta a junio de 1999, cuando los desarrolladores de OpenBSD y, por separado, Sun Microsystems en su conferencia JavaOne la usaron para eventos intensivos de programación. La idea central no ha cambiado: equipos pequeños, un plazo corto y algo que funcione al final.

Hackathon corporativo (interno). Personas de una misma organización forman equipos mixtos para construir prototipos frente a problemas del negocio. Sirve para descubrir talento interno, romper silos y probar ideas que nunca sobrevivirían a un comité presupuestario como propuesta sobre el papel. Flaquea cuando la dirección no tiene plan, responsable ni presupuesto para lo que gane. Conviene leer por qué la mayoría de los ganadores de un hackathon nunca se lanzan antes de reservar el espacio.

Hackathon cívico y de gobierno. Un organismo público abre sus problemas, y a menudo sus datos, a desarrolladores, diseñadores y ciudadanos. El International Space Apps Challenge de la NASA, que se celebra cada año desde 2012, es el ejemplo global más conocido. Estos eventos generan confianza y atraen capacidades externas a la administración, pero necesitan una vía clara para que un prototipo llegue a un servicio real; si no, se quedan en ejercicios de buena voluntad. Hackathons por el bien común trata las versiones con causa social.

Hackathon abierto (público). Puede inscribirse cualquiera. Se gana diversidad, energía y personas que nunca habían visto el problema. Se pierde control sobre la propiedad intelectual, la confidencialidad y la continuidad, porque la mayoría de los participantes vuelve a casa, a otros trabajos. El equilibrio se explica en hackathon interno o abierto al público.

Hackathon de ecosistema. Varias entidades comparten un reto que ninguna puede resolver por sí sola: un regulador, dos bancos y una comunidad fintech; un ministerio, una universidad y varios hospitales. Los equipos se mezclan deliberadamente entre organizaciones. Lo más difícil no es el fin de semana, sino acordar de antemano quién es dueño del problema y quién financia al ganador. Véase el hackathon de ecosistema.

Jams: diseñar servicios y experiencias

Una jam toma prestado el reloj del hackathon, pero cambia lo que cuenta como terminado. El resultado es un prototipo de un servicio, una experiencia o un juego, probado con personas reales siempre que sea posible, y no código listo para producción.

Service jam. La Global Service Jam la pusieron en marcha en 2011 Adam Lawrence y Markus Hormess, de WorkPlayExperience. Equipos de muchas ciudades trabajan durante 48 horas sobre el mismo tema secreto, que se revela al inicio, y después publican sus prototipos en línea con una licencia abierta. El método es el diseño de servicios con una inclinación por "hacer, no hablar": salir, hablar con la gente, construir una versión tosca, probarla y cambiarla. Es el mejor formato para enseñar a una organización cómo se siente de verdad el diseño de servicios.

GovJam. El mismo modelo orientado al sector público. La GovJam la impulsaron en 2012 el Gobierno de Australia junto con WorkPlayExperience y Protopartners, y la Global GovJam se celebra en ciudades de todo el mundo desde 2013. Funcionarios, diseñadores y ciudadanos trabajan codo con codo durante 48 horas sobre un tema secreto compartido. Un evento hermano, la Global Sustainability Jam, aplica el mismo enfoque a la sostenibilidad.

Design jam. La versión genérica y organizada localmente: uno o dos días sobre un problema de diseño, a menudo de experiencia de usuario o de un servicio concreto, con una persona facilitadora que guía la investigación, la ideación y el prototipado. Es más ligera de organizar que un hackathon porque nadie necesita un entorno de desarrollo, y está abierta a quien no programa.

Game jam. Los equipos crean un juego jugable en torno a un tema. La Global Game Jam, fundada por Susan Gold, Ian Schreiber, Gorm Lai y Foaad Khosmood e inspirada en la Nordic Game Jam, se celebró por primera vez en enero de 2009 en 53 sedes. Dura 48 horas, normalmente a finales de enero, y el tema se da al inicio. Las organizaciones usan las game jams menos por los juegos que por lo que entrenan: acotar con rigor y entregar algo completo y jugable en dos días.

Cómo organizar una de estas, con tema incluido, se explica en cómo organizar una jam.

Las variantes "-tón": el mismo reloj, otro resultado

Ideatón (ideathon). Los equipos desarrollan conceptos, no construcciones. El resultado es un planteamiento del problema, un concepto de solución, un storyboard básico y un pitch. Es útil al principio, cuando aún no se sabe qué problema importa, o cuando los participantes no tienen perfil técnico. El riesgo es confundir un pitch pulido con evidencia. Conviene exigir al menos una conversación con un usuario real por equipo.

Datatón (datathon). Un hackathon centrado en analizar y combinar conjuntos de datos en lugar de construir software. El resultado es un hallazgo, un modelo o una visualización que responde a una pregunta. Solo funciona si los datos están listos, limpios y autorizados para su uso antes del día; la mayoría de los datatones fallidos mueren en las tres primeras horas por problemas de permisos.

Makeatón (makeathon). Prototipado físico: hardware, electrónica, maquetas de producto, a menudo en un fab lab o un espacio maker. Hacen falta herramientas, materiales, instrucciones de seguridad y técnicos, y el reloj suele ser más largo porque los objetos tardan en fabricarse y en romperse.

Retos de innovación: el formato largo

Un reto de innovación (a veces llamado convocatoria abierta o concurso con premio) publica un problema e invita a presentar soluciones durante semanas o meses, normalmente por fases: presentación, preselección, desarrollo con apoyo y selección final. Encaja con problemas que no se resuelven en 48 horas, con participantes que ya trabajan en ese problema (startups, grupos de investigación, proveedores) y con organizaciones que quieren una cartera de pilotos y no un fin de semana de energía.

Un reto vive o muere por su enunciado. Demasiado amplio, y llega un montón de apps genéricas; demasiado estrecho, y lo que se ha escrito es un pliego de contratación. Cómo redactar un enunciado de reto que la gente quiera resolver lo trata en profundidad, y criterios de evaluación que eligen al ganador correcto cubre las fases de selección.

Un mapa rápido de todos los formatos

Cómo elegir, en cinco pasos

1. Escribir la frase del lunes por la mañana. "Después de este evento tendremos ___ y ___ se hará cargo de ello". Si el hueco es "un prototipo que funciona y que nuestro equipo de TI llevará adelante", lo que se busca es un hackathon. Si es "tres conceptos de servicio probados que el equipo de experiencia de cliente pilotará", una jam. Si es "dos startups contratadas para un piloto", un reto.
2. Comprobar que el problema está listo. Se encuadra con un árbol de problemas y el núcleo se convierte en unas cuantas preguntas ¿Cómo podríamos?. Si no se puede, conviene hacer antes un ideatón o una fase de descubrimiento.
3. Ajustar las capacidades al resultado. El código que funciona necesita desarrolladores en la mayoría de los equipos. Los prototipos de servicio necesitan personas dispuestas a hablar con desconocidos. Los eventos de datos necesitan datos limpios y autorizados.
4. Decidir el después antes que el durante. Hay que nombrar al responsable, la partida presupuestaria y la fecha de decisión para los ganadores. Cómo organizar un hackathon que produzca algo real lo integra en el plan.
5. Elegir jurado y mentores por el resultado, no por la foto. Jurados que vayan a hacerse cargo del resultado; mentores que conozcan el problema. Véase mentores en un hackathon.

Ejemplo ilustrativo

Ilustrativo. Una autoridad de transporte de una ciudad mediana del norte de Europa quería reducir los transbordos perdidos de los pasajeros mayores. Su primer impulso fue un hackathon abierto con un premio a la mejor app. Durante la planificación, el equipo escribió su frase del lunes por la mañana y descubrió que no quería una app en absoluto: quería saber qué parte del trayecto fallaba y qué cambios en el servicio podía hacer el personal con el presupuesto actual.

En su lugar, organizó una service jam de dos días con conductores, personal de estación, algunos pasajeros mayores y dos diseñadores. Los equipos pasaron la primera mañana recorriendo líneas y entrevistando a pasajeros, construyeron storyboards y prototipos en papel de avisos, señalización y una figura de "acompañante de transbordo", y los probaron en un intercambiador real. Un panel de contraste formado por el director de operaciones y dos jefes de estación eligió dos conceptos para pilotar. El hackathon llegó seis meses después, con un encargo acotado: construir la alerta de transbordo en tiempo real que la jam había demostrado que los pasajeros querían de verdad.

Qué hacer y qué evitar

Qué hacer

• Elegir el formato según el resultado que se necesita y quién se hará cargo de él.
• Publicar el problema, los criterios de evaluación y lo que reciben los ganadores antes de abrir las inscripciones.
• Mezclar los equipos a propósito: expertos del ámbito con quienes construyen, perfiles júnior con sénior, gente de dentro con gente de fuera.
• Planificar los 90 días posteriores al evento con el mismo cuidado que sus 48 horas. Una lista de verificación de despliegue ayuda.
• En los eventos de ecosistema, dibujar un mapa de ecosistema y acordar la titularidad antes de invitar a nadie.

Qué evitar

• Llamar hackathon a un evento de compromiso interno y luego prometer implantación.
• Hacer un datatón antes de que los datos estén autorizados, o un hackathon sin acceso a los sistemas con los que debe interactuar el prototipo.
• Dejar que el pitch lo decida todo. La evidencia y la viabilidad se puntúan con una matriz de decisión ponderada, no con aplausos.
• Copiar la mecánica del tema secreto de una jam global en un evento interno en el que ya se conoce el problema. Los temas secretos encajan en eventos de aprendizaje, no en la resolución de problemas concretos.
• Repetir los errores clásicos recogidos en 9 errores que los organizadores de hackathons siguen repitiendo.

Preguntas frecuentes

¿Qué diferencia hay entre un hackathon y una jam? Un hackathon se evalúa por lo que funciona: código, hardware, un prototipo en marcha. Una jam se evalúa por un servicio o una experiencia diseñados y probados, y normalmente no requiere programar. Ambos suelen durar 48 horas, pero una jam dedica mucho más de ese tiempo a usuarios reales.

¿Qué diferencia hay entre un hackathon y un ideatón? Un ideatón termina con conceptos y pitches; un hackathon termina con algo construido. El ideatón conviene cuando el problema aún es difuso o los participantes no tienen perfil técnico, y el hackathon cuando el problema está claro y hay gente que sabe construir.

¿Un reto de innovación es lo mismo que un hackathon? No. Un reto se desarrolla a lo largo de semanas o meses por fases y atrae a participantes que ya tienen capacidad, como startups y equipos de investigación. Un hackathon lo comprime todo en unos pocos días y la mayoría de los equipos parten de cero.

Hacia dónde seguir

Lo primero son las guías que dan forma al problema antes de cualquier evento: el árbol de problemas y las preguntas ¿Cómo podríamos?. Para la fase de construir y probar, el prototipo en papel y el storyboard, y para la selección, un panel de contraste. Todas las guías de método están en el índice de guías.