Cómo organizar una jam: 48 horas, un tema secreto y servicios reales

Una jam es un evento de 48 horas en el que equipos pequeños y mixtos diseñan un servicio nuevo desde cero en torno a un tema que nadie conoce hasta la tarde de apertura. Para organizarla bien hacen falta cuatro cosas: un tema que se mantenga secreto de verdad, personas reales fuera de la sala con las que investigar y probar, un plazo firme para tener un prototipo funcional y un plan para lo que pasa el lunes. Programar es opcional; salir a hablar con la gente, no.

El formato tiene una genealogía clara. La Global Service Jam la pusieron en marcha en 2011 Adam Lawrence y Markus Hormess, de WorkPlayExperience, tomando la estructura de las game jams como la Global Game Jam (celebrada por primera vez en 2009). Después llegaron formatos hermanos: la Global Sustainability Jam y la GovJam, que aplica el mismo enfoque a los servicios públicos. En las ediciones globales, el tema se revela en vídeo el viernes por la tarde, hora local, y los equipos publican la documentación de su prototipo el domingo por la tarde, compartida abiertamente con licencia Creative Commons. No hace falta sumarse a una jam global para usar el formato, pero su ritmo es un buen punto de partida.

Este artículo trata específicamente de cómo organizar una jam. Para ver cómo se sitúan las jams frente a los hackathons y los retos, consulta hackathon, design jam o reto de innovación; para el mapa completo de formatos, hackathons, jams y retos: todos los tipos explicados.

Qué diferencia una jam de un hackathon

Un hackathon suele partir de un reto definido y terminar con un pitch ante un jurado. Una jam parte de un tema deliberadamente vago («tesoros ocultos», «esperar», «confianza»), pide a los equipos que encuentren dentro una necesidad humana real y termina con un prototipo que la gente puede experimentar. De ahí se derivan tres consecuencias:

• Nadie puede llegar con una solución. El tema secreto impide que la gente traiga un proyecto propio y lo disfrace.
• La investigación ocurre durante el evento. Los equipos salen del edificio, observan, entrevistan a desconocidos y vuelven con evidencias.
• El resultado es un servicio, no una app. Un mostrador de recepción representado, un formulario en papel, un storyboard de un recorrido nuevo: todo cuenta. Muchos buenos prototipos de jam no llevan ni una línea de software.

Las jams globales no son, en el fondo, competiciones. Si tu patrocinador quiere un ganador, pregúntate si un premio no hará simplemente que los equipos pulan el pitch en lugar de probar.

Cómo organizar una jam, paso a paso

1. Decide para qué haces la jam (entre seis y ocho semanas antes). Escribe una frase: ¿qué debería existir el lunes que hoy no existe? Respuestas típicas: cuarenta personas de la plantilla que han hecho investigación de campo real al menos una vez; tres conceptos de servicio en un área que la organización ha evitado; una comunidad de profesionales de distintos departamentos. Si la respuesta es «una solución al problema X», probablemente lo que quieres es un hackathon o un reto.

2. Elige un tema amplio, humano y secreto. Los buenos temas son una palabra, una imagen o un sonido breve que admite muchas lecturas. Los malos son briefings disfrazados («onboarding digital para pymes»). Solo deberían conocerlo dos o tres personas. Prepara la revelación: un vídeo corto o una sola diapositiva, mostrada a una hora fija la primera tarde.

3. Recluta por mezcla, no por jerarquía. Busca equipos de cuatro a seis personas con perfiles distintos: personal de primera línea, diseñadores, desarrolladores, gente de políticas públicas, algunos externos. Invita a las personas a título individual, no como delegaciones de departamento. Pide a todo el mundo que se comprometa con las 48 horas completas; quien participa a medias lastra al equipo.

4. Prepara el mundo exterior con antelación. Es el paso que más organizadores se saltan. Antes del evento, identifica lugares que los equipos puedan visitar (una sucursal, la sala de espera de una clínica, una ventanilla de atención, una calle comercial) y, cuando haga falta, consigue permiso. Avisa al personal de primera línea de que puede que lleguen participantes a hacer preguntas. Prepara un breve guion de consentimiento para entrevistas y fotos. Sin esto, los equipos acaban «investigándose» entre ellos.

5. Prepara el espacio y los materiales. Una sala grande con mesas por equipo, paredes libres, cartón, cinta, rotuladores, una impresora, atrezo para el role play y buena comida a horas razonables.

6. El viernes por la tarde: revelar, reaccionar, formar equipos. Reúne a la gente con un breve calentamiento. Revela el tema. Da diez minutos de reacción individual y en silencio (qué te sugiere esta palabra, quién te viene a la cabeza). Pide a cada persona que proponga en una frase una necesidad humana o una pregunta, no una solución. Deja que los equipos se formen en torno a las preguntas que más interesan. Cierra la tarde con cada equipo escribiendo una pregunta ¿Cómo podríamos? que investigará.

7. El sábado: fuera del edificio y, después, a construir. La mañana es para investigar. Los equipos salen, observan y hablan con personas reales, con un service safari ligero o breves entrevistas a partes interesadas. A la hora de comer deberían haber escuchado al menos a cinco personas que no participan en la jam. La tarde es para sintetizar y hacer los primeros prototipos: storyboards, role plays, versiones en papel. Antes de cenar, cada equipo prueba algo tosco con alguien de fuera del equipo.

8. El domingo: probar, iterar, documentar. Por la mañana, una o dos rondas más de prueba y cambio. A mediodía, congelar el prototipo y documentarlo para que un desconocido pueda entenderlo (qué necesidad, qué aprendieron, en qué consiste el servicio, qué probaron y qué pasó). Por la tarde, cada equipo muestra su prototipo, idealmente dejando que el público lo experimente en lugar de presentar diapositivas.

9. Planifica el lunes antes del viernes. Decide de antemano quién recibe los resultados, cómo pueden los equipos pedir tiempo para continuar y qué hará un patrocinador en las dos semanas siguientes. Una jam que termina con aplausos y nada más enseña a la gente que la innovación es teatro. Consulta qué hacer después del hackathon; aquí se aplica la misma lógica.

Los roles que necesitas

• Anfitrión. Responsable de todo el evento, controla los tiempos y protege las reglas. Una sola persona.
• Facilitadores o coaches. Uno por cada dos o tres equipos. Su trabajo es empujar a los equipos a salir, preguntar «¿con quién lo habéis probado?» y cortar los debates interminables. No diseñan por los equipos.
• Apoyos de dominio. Dos o tres personas que conocen el servicio real (normativa, sistemas, realidad de primera línea) y están disponibles cuando se las llama. Responden preguntas; no juzgan ideas.
• Documentalista. Alguien que fotografía, recoge los materiales y se asegura de que el trabajo de cada equipo sobreviva al fin de semana.
• Patrocinador. Una persona senior que abre el evento, vuelve el domingo para experimentar los prototipos y es responsable del plan del lunes.

Ejemplo ilustrativo

Ilustrativo. La autoridad de transporte de una ciudad europea mediana quería que el personal de operaciones, atención al cliente y TI trabajara junto por primera vez. Organizó una jam de jueves por la tarde a sábado, para que la plantilla no perdiera un fin de semana. El tema, revelado la primera tarde, fue la grabación de un aviso por megafonía en una estación que se iba apagando. Los equipos lo interpretaron como «quedarse sin información», «el último tren» y «viajar solo de noche».

Antes del evento, el anfitrión había conseguido acceso a dos estaciones y a unas cocheras de autobuses nocturnos, y había avisado al personal. La segunda mañana, un equipo pasó tres horas en una parada nocturna y habló con once pasajeros y dos conductores. Su prototipo no era una app: era una tarjeta impresa de «si pierdes tu enlace», un aviso guionizado para el conductor y una llamada representada a una línea de ayuda nocturna. Lo probaron esa misma noche con seis pasajeros en la misma parada y cambiaron el texto dos veces.

La última tarde, el director de operaciones experimentó en persona todos los prototipos. Dos conceptos obtuvieron una prueba de cuatro semanas, cada uno con un responsable designado y un pequeño equipo de participantes.

Qué hacer y qué no

Qué hacer

• Mantén el tema secreto de verdad. Si la gente lo sabe el miércoles, la mitad llegará con una solución.
• Gestiona el acceso al terreno antes del evento. La investigación es el corazón de una jam, y requiere permisos y un guion de consentimiento.
• Haz de «enseñar, no contar» la regla de la sesión final. Deja que la gente experimente el servicio.
• Da bien de comer y manda a la gente a casa por la noche. Los equipos cansados hacen prototipos peores, no más valientes.
• Comparte la documentación abiertamente. Genera confianza para la próxima jam.

Qué no hacer

• No conviertas el tema en un briefing. «Esperar» es un tema; «reducir las colas en la sucursal 12» es un proyecto.
• No dejes que los equipos pasen la mañana del sábado en la sala. Si a la hora de comer nadie ha hablado con un desconocido, interviene.
• No llenes los equipos con un solo departamento o un solo nivel jerárquico. Un director en un equipo de perfiles junior acabará tomando, sin decirlo, todas las decisiones.
• No evalúes la calidad del pitch. Si tienes que premiar algo, premia la evidencia de las pruebas.
• No prometas una implantación que no puedes cumplir. Promete una conversación real con un responsable real en una fecha fija.

Preguntas frecuentes

¿Cuánto debe durar una jam? ¿Se puede hacer en un día? Cuarenta y ocho horas repartidas en tres días es la estructura clásica, porque permite una noche de reflexión y dos rondas de pruebas. Una versión de un día funciona como introducción, pero se pierde la mayor parte de la investigación de campo y de la iteración.

¿Los participantes tienen que ser diseñadores? No. Los equipos mixtos funcionan mejor, y el personal de primera línea suele aportar la visión más aguda. Lo que importa es contar con algunos facilitadores que conozcan los métodos.

¿Qué debe entregar un equipo al final de la jam? Un registro breve y sencillo: la necesidad que encontró, con quién habló, qué construyó, cómo lo probó y qué cambió. Las fotos del prototipo en uso valen más que las diapositivas. Una sencilla matriz de captura de retroalimentación por equipo lo facilita.

Métodos para usar durante la jam

El viernes, plantea preguntas con ¿Cómo podríamos?. El sábado, sal con un service safari y después construye con un storyboard o un role play. Los equipos que quieran mostrar cómo funcionaría de verdad su servicio pueden terminar con un service blueprint aproximado. Para el panorama general de formatos, empieza por la guía de hackathons, jams y retos.