El hackathon de ecosistema: un reto, varias entidades

Un hackathon de ecosistema es un hackathon del que son responsables varias organizaciones a la vez porque el problema no pertenece a ninguna de ellas por separado: el recorrido de un paciente que atraviesa un ministerio, hospitales y aseguradoras, o un proceso comercial que toca aduanas, puertos y empresas logísticas. Funciona cuando los responsables acuerdan cuatro cosas antes de que nadie escriba una línea de código: el único reto compartido, qué datos abrirá cada uno, de quién es lo que salga y quién llevará adelante las ideas ganadoras. La mayor parte del trabajo se hace en las ocho semanas previas al evento, no durante el evento.

Este artículo trata solo de la versión con varios responsables. Para la mecánica general del evento, consulta cómo organizar un hackathon que produzca algo real. Para el panorama más amplio de entidades que trabajan sobre problemas compartidos, consulta innovación en ecosistema.

Por qué son distintos los hackathons de ecosistema

Un hackathon con un solo responsable tiene un patrocinador, un conjunto de sistemas y una persona que decide. Un hackathon de ecosistema tiene varios de cada, y la fricción aparece en lugares previsibles:

• El reto se desdibuja. Cada socio empuja su propia prioridad y el briefing se convierte en una lista de cinco problemas.
• Los datos llegan tarde o no llegan. Los equipos jurídicos de cada organización revisan por separado, a su propio ritmo.
• La evaluación se politiza. Cada socio espera en silencio que gane «su» equipo.
• Nadie se hace cargo del lunes. Una solución que exige cambios en tres organizaciones no suele tener un hogar único.

La ventaja es real: los participantes ven el recorrido completo, no la parte de una sola organización, y los socios conocen por primera vez a las personas de los demás que trabajan en el mismo problema. Muchos hackathons de ecosistema importan menos por sus ganadores que por las relaciones de trabajo que crean.

Cómo organizarlo, paso a paso

1. Mapea el ecosistema antes de elegir socios. Dibuja un mapa de ecosistema del recorrido que te importa: quién está en contacto con el usuario, quién tiene los datos, quién fija las reglas, quién paga. Después decide quién debe ser corresponsable y quién puede ser colaborador. Entre tres y cinco corresponsables es manejable; con más, las decisiones se ralentizan hasta paralizarse.

2. Acordad un único reto, redactado desde el lado del usuario. Organiza una sesión de media jornada con una persona con capacidad de decisión de cada corresponsable. Usa un árbol de problemas sobre el recorrido compartido y después redacta un único enunciado de reto que nombre al usuario y el momento en que las cosas se rompen entre organizaciones. Si la prioridad de un socio no encaja, va a un evento posterior, no a este briefing. Consulta cómo redactar un reto que la gente quiera resolver.

3. Firmad un memorando breve antes de anunciar nada. Con dos páginas basta. Debe cubrir: el reto; la aportación de cada socio (dinero, datos, mentores, espacio); la propiedad intelectual (lo habitual es que los equipos conserven su propiedad intelectual y los socios tengan derecho preferente a negociar, pero eso lo deciden vuestros abogados); las condiciones de los datos; cómo se elige al jurado; y quién lidera cada fase. Acordarlo después del anuncio es la forma en que los eventos se retrasan meses.

4. Preparad los datos pronto, y preparadlos juntos. Decidid qué conjuntos de datos abrirá cada socio, en qué forma (reales, anonimizados, sintéticos o de muestra) y en qué condiciones. Reunidlos en un solo lugar con un único formato de descripción. Dad a los equipos jurídicos y de protección de datos un plazo de al menos cuatro semanas antes del evento. Si un socio no puede abrir sus datos a tiempo, un conjunto sintético realista con la misma estructura es mejor que nada.

5. Designad un líder y un reparto de roles claro. Ser corresponsables no significa codirigir cada tarea. Nombrad una organización líder para la logística y la comunicación, y usad una matriz RACI para el resto: quién aprueba el briefing, quién recluta, quién aporta mentores, quién valida a los ganadores, quién financia la continuación.

6. Recluta participantes de todo el ecosistema. Los equipos mixtos son la clave. Reserva plazas para personal de cada socio y busca equipos que combinen al menos dos organizaciones más desarrolladores, diseñadores o estudiantes externos. Pide a cada socio que envíe mentores que conozcan su parte del recorrido y puedan responder a «¿cómo funciona esto realmente en vuestro lado?».

7. Formad un jurado conjunto con criterios publicados. Cada corresponsable propone a un miembro del jurado; añadid al menos uno independiente. Publicad los criterios antes del evento y ponderadlos (una matriz de decisión ponderada sirve). Incluid un criterio que premie las soluciones que funcionan entre organizaciones, no dentro de una sola. Consulta criterios de evaluación que eligen al ganador correcto.

8. Celebra el evento con el recorrido compartido en la pared. Durante el hackathon, mantén visible el recorrido completo del usuario, con la parte de cada organización marcada. Cuando la idea de un equipo requiera un cambio por parte de un socio, el equipo debe poder ver de quién se trata y preguntar al mentor de ese socio en la sala.

9. Decidid la continuación antes del último día. Acordad en el memorando qué obtienen los ganadores: un piloto con socios concretos, un periodo fijo de apoyo, acceso a sistemas reales. Nombrad un responsable por cada concepto ganador y una fecha para la primera reunión de seguimiento. Un plan de comunicación con partes interesadas mantiene informados a todos los socios después del evento, cuando la atención decae.

Ejemplo ilustrativo

Ilustrativo. En una ciudad portuaria europea, la autoridad portuaria, la agencia de aduanas, una asociación de transportistas y el departamento de movilidad de la ciudad compartían una misma frustración: camiones haciendo cola durante horas en las calles de la ciudad a la espera del despacho y de su franja horaria. Cada uno había probado soluciones por su cuenta.

Dedicaron siete semanas a la preparación. Una sesión de mapa de ecosistema reveló que el retraso estaba entre tres sistemas que nunca intercambiaban estimaciones de llegada. El reto único decía: «¿Cómo podríamos dar al conductor de un camión que llega al puerto una hora fiable a la que presentarse, antes de que entre en la ciudad?». El memorando dejaba a los equipos la propiedad de su código, daba a los cuatro socios derecho preferente a pilotar y comprometía a cada socio con un mentor durante todo el evento. Aduanas no pudo liberar datos en tiempo real a tiempo, así que el equipo de datos de la autoridad portuaria creó un conjunto sintético con la misma estructura.

Participaron quince equipos, cada uno con al menos un miembro de una organización socia. El jurado tenía cuatro miembros de los socios y una presidencia independiente. El concepto ganador fue una ventana de llegada compartida que se alimentaba de los tres sistemas. Como el memorando ya designaba a la autoridad portuaria como responsable de la continuación, un piloto de doce semanas arrancó el mes siguiente al evento.

Qué hacer y qué no

Qué hacer

• Acordad un único reto. Un problema claro es mejor que cinco parciales.
• Firmad el memorando antes del anuncio, incluidas las condiciones de propiedad intelectual y de datos.
• Nombrad una organización líder para la logística y dad a todos los demás un rol claro.
• Premiad en los criterios las soluciones entre organizaciones.
• Fijad el responsable y la fecha de la continuación antes de anunciar a los ganadores.

Qué no hacer

• No invites como corresponsable a todo posible socio. Los colaboradores pueden ayudar sin votar en todo.
• No dejes el acceso a los datos como una cuestión de última hora. Es la causa de retraso más habitual.
• No dejes que los socios evalúen a los equipos de su propio personal sin una voz independiente en el jurado.
• No presentes el evento con la marca de un solo socio. Los problemas compartidos necesitan una visibilidad compartida.
• No termines con una foto de grupo y una nota de prensa. Sin un camino hacia el piloto, el evento confirma que la cooperación es de cara a la galería.

Preguntas frecuentes

¿A quién debe pertenecer la propiedad intelectual en un hackathon entre varias organizaciones? No hay una única respuesta correcta, y deben decidirlo vuestros equipos jurídicos. Un acuerdo habitual es que los equipos conserven su propiedad intelectual y que los socios tengan derecho preferente a negociar un piloto o una licencia. Lo más importante es que esté por escrito y publicado antes de que la gente se inscriba.

¿Cuántas organizaciones pueden coorganizar un hackathon? Entre tres y cinco corresponsables es manejable. A partir de ahí, incorpora organizaciones como colaboradoras (mentores, datos, espacio) sin dar a cada una voto en todas las decisiones.

¿Qué pasa si un socio no puede compartir sus datos? Usa un conjunto de datos sintético o de muestra con la misma estructura, descríbelo con honestidad a los participantes y planifica que los datos reales se usen en la fase de piloto con un acuerdo adecuado.

Métodos para la preparación

Empieza con un mapa de ecosistema y un mapa de expectativas de las partes interesadas para ver qué quiere cada socio. Acordad el reto con un árbol de problemas y después repartid el trabajo con una matriz RACI. Para toda la gama de formatos, consulta la guía de hackathons, jams y retos, y para convocar a todo un sector más allá de un evento, cómo ministerios y reguladores reúnen a un sector en torno a un reto.