Hackathon, design jam o reto de innovación: cuál encaja con el objetivo

Un hackathon es la opción cuando el problema está claro y hace falta un prototipo que funcione, construido por personas que saben programar o fabricar. Una design jam lo es cuando todavía no se sabe cuál es el servicio o la experiencia adecuados y hay que averiguarlo con usuarios reales, rápido. Un reto de innovación encaja cuando la solución probablemente ya existe en algún sitio, en una startup, un laboratorio o un proveedor, y hay que encontrarla, probarla y contratarla.

Dicho de otro modo: un hackathon responde a "¿podemos construirlo?", una design jam a "¿qué deberíamos construir?" y un reto a "¿quién lo tiene ya?". El resto del artículo muestra cómo saber cuál es la pregunta que de verdad se está haciendo. Para la familia completa de formatos, véase todos los tipos de hackathon y jam explicados.

La comparación de un vistazo

Cuándo encaja un hackathon

Un hackathon encaja cuando se cumplen tres condiciones. El problema es lo bastante concreto para enunciarlo en una frase. Los sistemas, los datos o los materiales están disponibles y autorizados. Y hay alguien que recogerá el resultado y financiará la siguiente fase.

Usos típicos acertados: automatizar un paso manual que todo el mundo reconoce como penoso, construir una herramienta interna sobre un conjunto de datos existente, conectar dos sistemas que deberían comunicarse o comprobar si una tecnología nueva soporta una carga de trabajo real. En todos los casos, la incertidumbre es técnica, no humana.

Un hackathon encaja mal cuando nadie ha comprobado si los usuarios quieren aquello. Los equipos construirán respuestas impresionantes a la pregunta equivocada, y el jurado premiará la más impresionante. Si se elige esta vía, conviene seguir cómo organizar un hackathon que produzca algo real.

Cuándo encaja una design jam

Una design jam encaja cuando el problema tiene que ver con cómo vive la gente un servicio y no se sabe dónde se rompe. Su fuerza está en que los equipos salen de la sala. Hacen observación contextual, hablan con la gente, representan el servicio con role play y prueban prototipos en papel esa misma tarde.

El modelo más conocido es la Global Service Jam, puesta en marcha en 2011 por Adam Lawrence y Markus Hormess, y su versión hermana para el sector público, la GovJam: 48 horas, un tema que se revela al inicio y prototipos compartidos abiertamente al final. En una design jam interna, normalmente se prescinde del tema secreto y se plantea en su lugar un problema de servicio real.

Usos típicos acertados: rediseñar un proceso de alta o incorporación, reducir visitas o llamadas repetidas, repensar un servicio para un grupo al que hoy no atiende bien o enseñar a un equipo cómo funciona el diseño de servicios haciéndolo. Además, una jam tiene un coste bajo, porque nadie necesita un entorno de desarrollo.

Una design jam encaja mal cuando la organización espera software al final. Hay que asegurarse de que el patrocinador sabe que el resultado es un concepto probado, a menudo recogido en un service blueprint básico, y que construirlo es un paso aparte. Cómo organizar una jam explica el formato en detalle.

Cuándo encaja un reto de innovación

Un reto de innovación encaja cuando se sospecha que la capacidad existe fuera de la organización y construirla internamente sería más lento o más arriesgado. Se publica un reto, se reciben candidaturas, se preselecciona, se apoya a los finalistas para que adapten su solución al contexto propio y se pilota una o varias.

Usos típicos acertados: encontrar un socio tecnológico para un problema que comparte todo el sector, captar startups para un programa de pilotos o invitar a universidades a aplicar investigación existente a un problema operativo. Es el formato adecuado cuando se necesitan participantes que llevan años con el problema, no un fin de semana.

Encaja mal cuando los procesos de compras, jurídicos o de seguridad informática no pueden asumir un piloto con una empresa pequeña. El reto atraerá a buenos candidatos y luego los perderá en el proceso de alta. Las condiciones del piloto, el acceso a los datos y la propiedad intelectual deben resolverse antes del lanzamiento. Cómo redactar un enunciado de reto que la gente quiera resolver trata el enunciado; trabajar con startups trata la relación.

Combinarlos: la secuencia que funciona

Los tres formatos rinden más en secuencia, porque cada uno genera un tipo distinto de evidencia.

1. Jam para encontrar el problema. Una design jam de uno o dos días con usuarios identifica dónde falla de verdad el servicio y qué concepto convence a los usuarios.
2. Hackathon para demostrar que se puede construir. Un hackathon centrado, con un encargo acotado a partir del mejor concepto de la jam, comprueba la viabilidad técnica sobre los propios sistemas.
3. Reto para escalar con ayuda externa. Si construirlo internamente no es el camino adecuado, un reto busca socios capaces de entregarlo a escala, con la evidencia de la jam incluida en el enunciado.

No siempre harán falta los tres. Pero hacerlos en el orden equivocado, un hackathon antes de que nadie haya visto a un usuario o un reto antes de conocer el problema, es la razón más común por la que estos eventos decepcionan.

Ejemplo ilustrativo

Ilustrativo. Un servicio nacional de bibliotecas de Canadá quería que más jóvenes adultos usaran sus sedes. Un miembro del consejo propuso un reto de innovación abierta sobre "la biblioteca del futuro". El equipo de innovación se opuso: todavía no sabía por qué los jóvenes adultos no iban.

Organizó primero una design jam de dos días. Los equipos pasaron la primera mañana en tres sedes y en dos cafeterías cercanas, observando y hablando con estudiantes. El hallazgo no tenía que ver con libros ni con tecnología: los jóvenes adultos querían un sitio donde estudiar hasta tarde, y las sedes cerraban a las 18:00. Los equipos prototiparon una tarde de estudio con horario ampliado y personal, y la probaron con un test concierge en una sede la semana siguiente.

Las tardes funcionaron, pero dotarlas de personal costaba demasiado. Así que el equipo organizó un breve hackathon interno sobre una sola pregunta: ¿podían el acceso y la reserva en autoservicio funcionar sobre el sistema de socios existente? Podían, con limitaciones. Solo entonces el servicio lanzó un reto, en busca de un proveedor capaz de ofrecer un acceso en autoservicio seguro en muchas sedes. Cada formato respondió a una pregunta que había planteado el anterior.

Qué hacer y qué evitar

Qué hacer

• Nombrar primero la pregunta: ¿podemos construirlo?, ¿qué deberíamos construir? o ¿quién lo tiene ya?
• Encuadrar el problema con un árbol de problemas y preguntas ¿Cómo podríamos?, sea cual sea el formato elegido.
• Ajustar el responsable al formato: un responsable de producto para un hackathon, uno de servicio para una jam, un responsable de negocio junto con compras para un reto.
• Aplicar la misma lógica de matriz de decisión ponderada en los tres, con criterios ponderados según la evidencia que genera cada formato.

Qué evitar

• Organizar un hackathon para responder a una pregunta sobre lo que necesitan los usuarios.
• Organizar una design jam y prometer software que funcione.
• Lanzar un reto antes de que la organización pueda de verdad contratar al ganador y hacer un piloto con él.
• Elegir el formato por la foto. El hackathon abierto con un gran premio es el más visible y, para muchos problemas, el menos útil.

Preguntas frecuentes

¿Una design jam es lo mismo que un hackathon? No. Comparten el formato breve e intenso, pero un hackathon se evalúa por lo que funciona técnicamente y una design jam por si un concepto de servicio se sostiene con usuarios reales. Las jams no requieren programar y pasan mucho más tiempo fuera de la sala.

¿Es mejor un reto de innovación que un hackathon para las startups? Normalmente, sí. Las startups consolidadas rara vez renuncian a un fin de semana para construir desde cero, pero sí se presentan a un reto que ofrece un piloto real. Los hackathons encajan con quien construye algo nuevo; los retos, con quien ya tiene algo.

¿Se pueden organizar un hackathon y un reto a la vez? Se puede, pero conviene mantenerlos separados. Mezclar a personal interno que construye desde cero con startups que ya tienen un producto crea una competición desigual y confunde la evaluación. Lo mejor es organizarlos como dos líneas con criterios distintos, o uno detrás de otro.

Hacia dónde seguir

Para la vía de la jam, lo primero es la observación contextual y el service blueprint. Para probar lo que produzca cualquier formato, el prototipo en papel y el test concierge. Todas las guías están en el índice de guías.