Cómo organizar un hackathon que produzca algo real

Para organizar un hackathon que produzca algo real, lo primero que hay que decidir, antes que cualquier otra cosa, es qué pasará con los ganadores: quién se hará cargo de ellos, de qué presupuesto saldrán y cuándo se tomará la decisión. Después se preparan el problema, los datos y las personas, para que los equipos dediquen el evento a construir y no a esperar. El evento en sí es la parte fácil; la mayor parte del trabajo está en las seis semanas anteriores y en las doce posteriores.

Los pasos siguientes parten de un hackathon interno o de ecosistema de uno a tres días. Si todavía se está eligiendo entre formatos, conviene empezar por todos los tipos de hackathon y jam explicados.

Antes de empezar: el acuerdo de una página

Se redacta una sola página y se consigue la aprobación del patrocinador sénior. Contiene cinco líneas:

• El problema, en una frase, y por qué importa ahora.
• El responsable que llevará adelante el prototipo ganador, con nombre y apellidos.
• La zona de aterrizaje: la partida presupuestaria, el equipo o el programa que absorberá al ganador.
• La fecha de decisión: cuándo, después del evento, el responsable decide seguir, adaptar o parar.
• Qué significa "real": un piloto con 50 usuarios, una prueba de integración, una solicitud de compra. Hay que ser concreto.

Si no se puede rellenar esta página, no se está preparado para organizar un hackathon. Quizá sí para un ideatón o una fase de descubrimiento.

Paso a paso

1. Encuadrar el problema seis semanas antes

Hay que entrevistar a quienes conviven con el problema: personal de primera línea, clientes, responsables de los sistemas. De cinco a ocho entrevistas a partes interesadas bastan para no plantear el problema equivocado. Las causas y los efectos se ordenan con un árbol de problemas y, a partir de ahí, se redactan de dos a cuatro preguntas ¿Cómo podríamos? como líneas del reto. Cada línea debe ser lo bastante acotada para que un equipo de cinco personas construya algo con sentido en 48 horas, y lo bastante amplia para que dos equipos no construyan lo mismo. La redacción del enunciado se explica en cómo redactar un enunciado de reto que la gente quiera resolver.

2. Resolver los accesos cuatro semanas antes

Aquí es donde fracasan en silencio la mayoría de los hackathons corporativos. Los equipos llegan y descubren que no pueden acceder a la API, que los datos no están autorizados o que el entorno de pruebas no existe. Cuatro semanas antes, hay que listar todo lo que un equipo necesitará tocar y conseguir la aprobación por escrito de TI, protección de datos y seguridad. Se prepara un entorno de pruebas (sandbox) con datos de prueba realistas. Si los datos reales no pueden salir de su sistema, se crea un conjunto sintético con la misma estructura.

3. Reclutar para formar equipos mixtos

Las inscripciones se abren entre tres y cuatro semanas antes, y se pregunta a la gente por sus capacidades, no por su cargo. Un buen equipo de cuatro a seis personas tiene al menos a alguien que construye, a alguien que conoce el ámbito y a alguien dispuesto a hablar con usuarios. Hay que dejar margen para que la gente se apunte a título individual y se la asigne a un equipo. Conviene evitar que departamentos enteros se inscriban como un solo equipo: se pierde el valor transversal que justifica el evento.

4. Preparar al jurado y a los mentores dos semanas antes

El jurado debe incluir al responsable del acuerdo de una página, a alguien que controle el presupuesto y a alguien que represente al usuario. Los criterios se acuerdan con ellos antes del evento y se publican para los participantes. Un conjunto sensato: solidez de la evidencia de que el problema es real, encaje con la zona de aterrizaje, viabilidad dentro de los sistemas existentes y calidad del prototipo. Se ponderan en una matriz de decisión ponderada. Hay más detalle en criterios de evaluación que eligen al ganador correcto.

Los mentores no son jurado. Cada mentor recibe una línea del reto, un calendario de revisiones y unas instrucciones: hacer preguntas, desbloquear accesos, no tomar el control. Véase mentores en un hackathon.

5. Organizar el evento en torno a tres puntos de control

Un plan de 48 horas que funciona:

• Apertura (primeras dos horas). El patrocinador explica en persona el problema y la zona de aterrizaje. Después, son los responsables del problema, no los organizadores, quienes responden a las preguntas. Se forman los equipos y cada uno elige una línea.
• Primer punto de control (hacia la hora seis). Cada equipo expone su usuario, su supuesto y lo que va a construir. Conviene empujar a los equipos a listar sus creencias más arriesgadas con un mapa de supuestos. Los duplicados se eliminan pronto.
• Segundo punto de control (hacia la hora 24). Cada equipo enseña algo que funcione, aunque sea feo, y presenta una prueba con un usuario real o con un sistema real. Un prototipo en papel vale para las interfaces que aún no se han construido.
• Tercer punto de control (última mañana). Se congelan las funcionalidades. Lo que queda es probar, corregir y preparar una demostración breve.

Las presentaciones se limitan a cinco minutos más preguntas, y se exige una demostración en directo. Unas diapositivas sobre lo que haría el producto no son un prototipo.

6. Evaluar pensando en la adopción, no en el aplauso

La evaluación se organiza como un panel de contraste: cada miembro del jurado puntúa en privado según los criterios publicados antes de cualquier debate; después, el panel compara las puntuaciones y solo discute las diferencias. No basta con anunciar al ganador, hay que anunciar el siguiente paso: "El responsable se reunirá con este equipo el martes para planificar un piloto de cuatro semanas". Si se anuncia un premio pero ningún siguiente paso, la gente entenderá exactamente qué era el evento.

7. Hacer el traspaso en diez días laborables

En los diez días laborables posteriores al evento, el responsable se reúne con cada equipo seleccionado, acuerda quién hace qué con una matriz RACI y reserva por escrito, con sus superiores directos, el tiempo que necesita el equipo. Los primeros pasos del piloto se siguen con una lista de verificación de despliegue. En la fecha de decisión, el responsable decide seguir, adaptar o parar, y lo comunica públicamente. Por qué la mayoría de los ganadores de un hackathon nunca se lanzan profundiza en esta fase.

Ejemplo ilustrativo

Ilustrativo. Una aseguradora regional del sur de Europa quería acortar el tiempo que pasa desde que un cliente declara un siniestro leve de automóvil hasta que recibe el pago. Su responsable de innovación redactó primero el acuerdo de una página: el director de siniestros se hacía cargo del resultado, el programa digital de siniestros lo absorbería y la decisión se tomaría seis semanas después del evento.

Cuatro semanas antes, TI montó un entorno de pruebas con expedientes de siniestros anonimizados y una copia del servicio de subida de documentos. Los equipos, de cinco personas, mezclaban peritos, desarrolladores y un agente del centro de atención telefónica. En el segundo punto de control, un equipo había descubierto, llamando a tres clientes con siniestros recientes, que el retraso no estaba en la peritación, sino en que los clientes enviaban las fotografías equivocadas. Construyó un flujo guiado de fotos y lo probó con personal del centro de atención haciendo de clientes. Ganó por la evidencia y el encaje, no por el acabado. El director de siniestros se reunió con el equipo el martes siguiente, y se hizo un piloto de cuatro semanas en una oficina.

Qué hacer y qué evitar

Qué hacer

• Conseguir la firma del acuerdo de una página antes de anunciar la fecha.
• Que sea el responsable del problema, y no el organizador, quien presente el reto a los equipos.
• Publicar los criterios de evaluación al abrir las inscripciones.
• Alimentar bien a la gente y dejarla dormir. Un equipo que ha dormido construye mejor el segundo día.
• Registrar lo que aprendió cada equipo, también los que no ganaron; sus hallazgos a menudo evitan que el ganador repita errores.

Qué evitar

• Empezar por el espacio, la imagen o el premio.
• Dejar que los equipos descubran esa misma mañana que no pueden acceder a los sistemas.
• Aceptar una presentación de diapositivas en lugar de una demostración.
• Elegir un jurado que no volverá a ver el proyecto.
• Celebrar el viernes y desaparecer el domingo. 9 errores que los organizadores de hackathons siguen repitiendo recoge el resto.

Preguntas frecuentes

¿Cuánto debe durar un hackathon corporativo? Dos días es el mínimo práctico para obtener algo que funcione; 24 horas solo sirven para problemas muy acotados. Con más de tres días, lo que se organiza es un sprint, lo cual está bien, pero hay que planificarlo como tal.

¿Cuántas personas hacen falta para organizar un hackathon? Para 50 a 80 participantes, conviene prever una persona que lidere la organización, un responsable técnico para accesos y entornos, un mentor por línea, un jurado de tres a cinco personas y alguien dedicado a la logística. El responsable técnico es el rol que falta con más frecuencia.

¿Hay que pagar a los participantes o darles tiempo libre? Los hackathons internos deben celebrarse en horario laboral o compensarse, y los mandos deben aceptarlo de antemano. Si la gente tiene que renunciar a un fin de semana sin compensación, solo participará quien pueda permitírselo, y se la perderá en la fase de piloto.

Hacia dónde seguir

Las guías que hacen la mayor parte del trabajo aquí son el árbol de problemas, el mapa de supuestos, la matriz de decisión ponderada y la lista de verificación de despliegue. Cada una se aplica con un equipo en menos de una hora.