Métricas de éxito de un hackathon que importan después del demo day

¿Qué significan estos términos aquí?

Un participante único es una persona identificada que realmente construyó algo durante el programa. Un proyecto evaluado es una entrega calificada contra una rúbrica publicada antes del evento. El estatus posterior al programa es dónde está cada equipo treinta días después: sigue construyendo, en pausa o disuelto. Estos tres términos sostienen todo el artículo.

Usted está redactando el RFP. O ya firmó uno, el fin de semana ya pasó, las fotos se ven muy bien y su CFO pregunta qué obtuvo la empresa a cambio del gasto. Si la respuesta del proveedor empieza por cuánta gente asistió, usted no ha aprendido casi nada sobre si el dinero funcionó.

La asistencia es el número más fácil de producir en esta industria y el más difícil de defender. Mide logística, no resultados. La investigación sobre lo que realmente pasa con los proyectos de un hackathon después del demo day es contundente, y cualquier comprador que la lea dejará de tratar una sala llena como evidencia de algo.

Puntos clave

• Alrededor de dos tercios de los proyectos de hackathon no muestran trabajo continuo después de que termina el evento, así que la supervivencia, no la asistencia, es la señal que vale la pena comprar.
• Cinco métricas resisten el escrutinio. Participantes únicos. Proyectos evaluados. Alcance universitario. Calidad del jurado. Estatus posterior al programa a los 30 días.
• Las cifras de asistencia van en el reporte como contexto de apoyo, nunca como el resultado principal.
• Exija un reporte escrito con un formato definido antes de firmar.
• Por ejemplo: imagine que dos proveedores le proponen el mismo fin de semana. Uno promete 500 registros. El otro promete un reporte que nombra a 180 builders y a cada miembro del jurado con su cargo. El segundo número es el que usted puede defender frente a su CFO.

Por qué el conteo de asistentes falla como medida

El trabajo académico más citado sobre la sostenibilidad de los hackathons dio seguimiento a proyectos de hackathons públicos y encontró que alrededor de 65% no mostraba actividad continua después de que terminaba el evento, y que solo cerca de 3.55% seguía activo cinco meses después (Nolte, Chounta y Herbsleb, Proceedings of the ACM on Human-Computer Interaction, CSCW, 2020). Una revisión de literatura sobre los resultados de los hackathons coincide: los resultados son reales pero desiguales, y rara vez se miden después del fin de semana (Medina et al., 2020).

¿Qué significa esto para un comprador? Lea los dos hallazgos juntos. Un recinto lleno le dice que el reclutamiento funcionó. No dice nada sobre si se construyó algo que sobreviva al lunes por la mañana. Cuando la mayor parte de lo producido se apaga por diseño, la asistencia no puede decirle si el programa generó valor. ¿Qué sí puede? Las cinco métricas de abajo.

También hay una brecha de conversión a la entrada. La guía publicada por el propio Devpost sitúa la conversión de registrados a builders activos en algún punto entre 5% y 33% según el evento (la página de producto de Devpost). Mil registros pueden significar trescientos builders o cincuenta. Los registros son intención. Los builders son el recurso que usted pagó por convocar.

Nada de esto significa que los hackathons sean una mala compra. Significa que la medición tiene que especificarse desde el inicio, porque nadie la ofrece por voluntad propia después. La investigación sobre hackathons corporativos señala con claridad que el retorno de la inversión es difícil de establecer y depende por completo de que los objetivos se definan antes de que corra el evento (Roy y Laskowski, 2017).

Las cinco métricas que resisten el escrutinio

1. Participantes únicos, no registros

Pida personas deduplicadas que construyeron algo durante el programa. Una persona que asiste en dos ciudades y se registra dos veces sigue siendo un solo participante. El método de conteo importa tanto como el conteo mismo. Si un proveedor no puede explicar su método de deduplicación, trate sus demás números con sospecha.

Los registros siguen teniendo un uso, pero solo como denominador de una razón. Registros divididos entre builders únicos es una métrica de calidad del reclutamiento. Una sala más pequeña donde la mayoría construyó le gana a una sala enorme donde la mayoría solo miró.

2. Proyectos entregados contra una rúbrica publicada

Un proyecto que no fue evaluado contra criterios publicados antes del evento es un demo, no un resultado. La rúbrica es lo que hace defendible el conteo. Marcos públicos como la guía de evaluación de Major League Hacking y rúbricas publicadas por universidades, como la de Claremont Graduate University, le dan a los patrocinadores un punto de referencia externo, de modo que la vara quedó fijada antes de que alguien escribiera una línea de código.

Pida tres números aquí: proyectos entregados, proyectos evaluados como completos contra la rúbrica y proyectos que superaron el umbral de calidad que ustedes acordaron. El tercer número es el que predice si algo continúa.

3. Alcance universitario, contado con honestidad

¿Qué cuenta como alcance? Instituciones con nombre entre los builders reales. No volantes. No contactos de clubes estudiantiles. En México esto importa más que en la mayoría de los mercados. Las comunidades de campus son el lugar donde muchos desarrolladores en activo tocan por primera vez el stack de una empresa. El Octoverse de GitHub situó a los desarrolladores registrados en México en alrededor de 1.9 millones, con un crecimiento de cerca de 21% año con año (GitHub Octoverse 2024). Un programa que puede nombrar quince instituciones de las que atrajo builders ha producido un mapa de reclutamiento. Un programa que no puede nombrar cinco ha producido una lista de correos.

4. Calidad del jurado

La calidad del jurado es un indicador indirecto de lo que significan las calificaciones. Una rúbrica aplicada por ingenieros senior de la empresa patrocinadora produce señal: listas de entrevistas, retos de seguimiento. Una rúbrica aplicada por quien estuviera disponible produce ruido. Pida la lista del jurado con sus cargos y pregunte si las entregas se anonimizaron. Ambas preguntas toman treinta segundos.

5. Estatus posterior al programa a los 30 días

Casi nadie reporta esta métrica, y ataca directamente el problema del 65%. Treinta días después del demo day, cada equipo responde una sola pregunta: ¿siguen construyendo? Las respuestas se ordenan en sigue construyendo, en pausa y disuelto. Cada equipo que sigue en marcha se convierte en un candidato concreto de seguimiento para contratación, fondos o un piloto. Frente a la línea base de la investigación, incluso una continuidad modesta destaca.

Métrica	Qué pedir	Qué sustituye
Participantes únicos	Builders deduplicados, con el método de conteo declarado	Totales de registros
Proyectos evaluados	Entregas calificadas contra una rúbrica publicada de antemano	Conteos de fotos del demo day
Alcance universitario	Instituciones con nombre representadas entre los builders	Volantes y contactos de clubes
Calidad del jurado	Lista con cargos, calificación anonimizada sí o no	"evaluaron expertos de la industria"
Estatus posterior al programa	Estatus por equipo a los 30 días	Nada. Normalmente está ausente por completo

Dónde pertenece la asistencia

Para ser claros, la asistencia no carece de valor. Es evidencia de una sola cosa: si el reclutamiento funcionó. Los totales de check-in, las tasas de ocupación por sesión y las tasas de inasistencia le dicen si sus canales de reclutamiento llegaron a personas reales. En nuestros propios programas, los check-ins acumulados a lo largo de las sesiones han cumplido exactamente ese papel, como una fila de apoyo en la sección de operaciones de un reporte y no como su titular. La misma disciplina aplica a las menciones en prensa: prueban que la historia viajó, no que se construyó algo.

La prueba es simple. Quite de un reporte cualquier cifra del tipo asistencia. Si no queda nada importante, el reporte medía logística. Si las cinco métricas de arriba permanecen, el reporte medía resultados.

El formato de reporte que debe exigir en el RFP

Especifique el entregable antes de firmar. Un reporte posterior al programa que se pueda defender tiene seis secciones:

1. Datos del programa. Fechas, ciudades, sedes, presupuesto contra plan y cualquier sobrecosto explicado.
2. Participantes. Builders únicos con método de conteo, razón de registros a builders y los desgloses demográficos que ustedes acordaron.
3. Proyectos. Conteos de entregados, evaluados como completos y por encima del umbral, con la rúbrica adjunta.
4. Alcance. Universidades, instituciones y comunidades con nombre representadas entre los builders reales.
5. Jurado y mentores. Lista con afiliaciones.
6. Seguimiento a los 30 días. Estatus por equipo, con siguientes pasos para los equipos que siguen construyendo.

¿Cómo detecta rápido a un buen proveedor? Los proveedores que operan así envían un reporte de muestra esa misma semana. Los proveedores que se resisten ya le dijeron algo útil.

Formas comunes en que la medición sale mal

• Registros reportados como participantes. Pida el método de deduplicación cada vez.
• Conteos de proyectos sin rúbrica. Los demos sin evaluar se inflan con facilidad y no predicen nada.
• Satisfacción de encuesta citada sin el número de respuestas. Una calificación promedio dice poco hasta que sabe si respondieron cuarenta personas o cuatrocientas.
• Menciones en prensa presentadas como resultados. Son un resultado de comunicación, no de construcción.
• Seguimiento prometido pero nunca entregado. Ponga la fecha del reporte a 30 días en el contrato, no en la presentación de la propuesta.

Una lista de verificación breve para el comprador

¿Qué pregunta primero? Participantes únicos, no registros. Después proyectos evaluados, no conteos de fotos. Después alcance universitario entre los builders reales. Después la lista del jurado. Después el estatus a los 30 días.

¿Qué ignora? Registros en bruto. Conteos de prensa usados como prueba de que se construyó algo. Calificaciones de encuestas sin número de respuestas. Promesas de embudos de conversión armados después de los hechos.

¿Por qué este orden? Porque cada punto es barato de verificar y difícil de falsear. Un proveedor que puede responder los cinco ya opera un programa real. Un proveedor que no puede está vendiendo un fin de semana.

Preguntas frecuentes

¿Cómo se mide el éxito de un hackathon?

Con participantes únicos, proyectos evaluados contra una rúbrica publicada de antemano, alcance universitario entre los builders reales, calidad del jurado y estatus por equipo treinta días después del evento. La asistencia y la prensa acompañan a estas métricas como contexto de apoyo, nunca como titular.

¿Se puede medir el ROI de un hackathon?

Parcialmente, y solo si los objetivos se definieron antes del evento. El trabajo académico muestra que la mayoría de los proyectos se apagan rápido, así que un ROI honesto se parece a conteos de continuidad, conversaciones de contratación abiertas y un reporte escrito que sobrevive una auditoría interna, no a un embudo de conversión inventado después de los hechos.

¿Qué debe incluir el reporte de un patrocinador después de un hackathon?

Datos del programa, incluida la variación del presupuesto, conteo de participantes únicos con su método, conteos de proyectos evaluados, alcance institucional con nombres, lista del jurado y el seguimiento del estatus de los equipos a los 30 días. Exija el formato antes de firmar.

Trabaje con nosotros

Mobil3 diseña y opera hackathons y retos de innovación en México y América Latina, y reporta cada programa contra el formato descrito arriba: participantes únicos, proyectos evaluados, alcance universitario y estatus posterior al programa. Si está incluyendo un hackathon en un RFP, pida nuestra estructura de reporte de muestra. Agende una conversación en calendly.com/mobil3/meeting o escriba a hello@mobil3.xyz.

Sobre esta guía

Esta guía fue escrita y verificada por el Equipo Editorial de Mobil3 a partir de la operación directa de programas en México. Para preguntas sobre este artículo o sobre nuestro proceso editorial, escríbanos a hello@mobil3.xyz o lea más sobre nosotros. Para el lado operativo de estos programas, lea cómo organizar un hackathon para desarrolladores. Relacionado: la adopción de desarrolladores como programa y cómo trabajar con universidades en México.