En la
parte anterior de la trilogía, examiné varias razones para participar en hackatones. La motivación para aprender mucho y ganar valiosos premios atrae a muchos, pero a menudo debido a los errores de los organizadores o las empresas patrocinadoras, el evento termina sin éxito y los participantes se van insatisfechos. Para que tales casos desagradables ocurran con menos frecuencia, escribí esta publicación. La segunda parte de la trilogía está dedicada a los errores de los organizadores.
La publicación está organizada de la siguiente manera: al principio hablo sobre el evento, explico qué salió mal y a qué condujo (o puede conducir a largo plazo). Luego doy mi evaluación de lo que está sucediendo y cómo actuaría en lugar de los organizadores. Como actué como participante en todos los eventos, solo puedo asumir la verdadera motivación de los organizadores. Como resultado de esto, mi evaluación puede ser unilateral. No excluyo que algunos de los puntos que considero erróneos fueron concebidos.
En algún momento, puede parecerle al lector que el autor decidió agitar los puños después de la pelea. Pero les puedo asegurar que esto no es así. En algunos de los hackatones enumerados, logré tomar un premio, lo que, sin embargo, no me impide decir que el evento estuvo mal organizado.
Debido al respeto por los organizadores y participantes, la publicación no indicará compañías específicas. Sin embargo, un lector atento puede adivinar (o googlear) de quién está hablando.
Hackathon No. 1. Marco estricto
Hace seis meses, una gran empresa de telecomunicaciones organizó un hackathon de análisis de datos. Por el fondo del premio lucharon 20 equipos. En el evento, se proporcionó un conjunto de datos para el análisis, que contenía información sobre llamadas al servicio de soporte de la compañía, actividad en redes sociales e información codificada sobre usuarios (género, edad, etc.). La parte más interesante del conjunto de datos (mensajes de usuario y respuesta del operador (datos de texto)) era bastante "ruidosa", era necesario limpiarla para seguir trabajando.
Los organizadores establecieron la tarea: hacer algo interesante con los datos proporcionados, y estaba prohibido usar conjuntos de datos abiertos adicionales de la red o analizar los datos usted mismo. También estaba prohibido ofrecer ideas no relacionadas con el conjunto de datos. Desafortunadamente, los datos proporcionados eran bastante "pobres": era difícil obtener productos interesantes de ellos y, al comunicarse con los mentores, quedó claro que muchas de las ideas propuestas ya se estaban implementando (o se implementarían en el futuro cercano) en la empresa.
Como resultado, la gran mayoría de los equipos (15 de 20) hicieron bots de chat. Durante las actuaciones, la decisión de un equipo no fue muy diferente de la anterior. Insoportable, uno de los miembros del jurado le preguntó al siguiente equipo en el escenario: "¿Qué, chicos, también tienen un bot de chat?" Como resultado, de los tres premios, el primer y segundo lugar fueron para equipos que no hicieron bots de chat.
A modo de comparación, tome el hackathon, organizado por una empresa de consultoría internacional, para la firma Zvezdochka hace dos años. Dado que los detalles de la empresa Zvezdochka no eran familiares para muchos participantes del hackathon, al comienzo del evento, los organizadores hablaron sobre las métricas que se utilizan en la empresa. Después de eso, se proporcionaron seis conjuntos de datos de varias orientaciones: texto, tablas, posiciones geográficas; había margen de maniobra para todos los participantes. Los organizadores no prohibieron el uso de conjuntos de datos adicionales e incluso apoyaron tales compromisos. En la final de la competencia, diez equipos con diferentes decisiones lucharon por el premio principal, y todos los equipos utilizaron los datos proporcionados por la empresa (a pesar de la ausencia de prohibiciones), lo que indicaba un buen potencial para obtener productos de calidad.
Moraleja
No limite el flujo creativo de los participantes. Como organizador, debe proporcionar materiales y confiar en sus puntos de vista y profesionalismo. Si es miembro de un hackathon, cualquier restricción o prohibición debería alertarlo. Por lo general, esto es evidencia de una organización pobre (un ejemplo de la vida real es un deseo constante de pegar una valla en algún lugar). Si aún encuentra restricciones, prepárese para el hecho de que tiene que crear un proyecto en el grupo con gran competencia. En este caso, debe tomar riesgos: hacer algo fundamentalmente nuevo u ofrecer una "característica asesina" inusual para sobresalir del flujo de proyectos monótonos.
Hackathon número 2. Tareas imposibles
El hackathon en Amadore prometió ser interesante. La empresa patrocinadora, un importante fabricante de teléfonos, comenzó los preparativos 4 meses antes de la fecha del evento. Se realizó un evento social en las redes sociales, los posibles participantes tuvieron que pasar una prueba técnica y escribir sobre sus proyectos anteriores para ser seleccionados para este evento. El pozo de premios era agradablemente grande. Unos días antes del hackathon, los mentores realizaron una sesión técnica para que los participantes tuvieran tiempo de penetrar los detalles de la industria.
En el evento, los organizadores proporcionaron un conjunto de datos de equipos de 8 Gb con una clasificación binaria de averías. Hablaron sobre los criterios para evaluar proyectos: la calidad de la clasificación, la creatividad para crear características, la capacidad de trabajar en equipo, etc. Eso es solo mala suerte: para 8 GB de "características", solo había 20 ejemplos en el tren y 5 en la prueba. El último clavo en la tapa del ataúd del hackathon anotó una cara en los datos: los registros de equipos recibidos el miércoles contenían un error en la operación del equipo, y los creados el jueves no contenían (por cierto, solo dos equipos sabían al respecto, y ambos eran de Rusia, la patria de los expertos en datos experimentados ) Aunque incluso conocer las verdaderas etiquetas de la prueba no ayudó a adaptar la respuesta, la tarea no tenía solución. Los organizadores no obtuvieron el resultado deseado, los participantes pasaron mucho tiempo resolviendo una tarea mal compuesta. El hackathon fue un fracaso.
Moraleja
Realice exámenes técnicos de las tareas y verifique que sus tareas sean adecuadas. Es mejor pagar de más por un examen preliminar (en este caso, cualquier centro de datos indicaría de inmediato que es imposible resolver este problema) que lamentarlo más tarde.
En este caso, además del tiempo y dinero gastado, la compañía perdió un préstamo fiduciario de posibles candidatos y es posible escribir sobre los resultados. Por cierto, no solo los participantes, sino también la empresa deben escribir sobre resultados exitosos, realizando al máximo el hackathon desde el punto de vista de relaciones públicas. Desafortunadamente, no todas las empresas hacen esto, limitándose solo a un anuncio posterior y un par de fotos del evento en Twitter.
Hackathon número 3. Tómalo o déjalo
Más recientemente, nuestro equipo participó en un hackathon en Amsterdam. Como soy ingeniero eléctrico de formación (en el campo de las fuentes de energía renovables), el tema era solo para nosotros: la energía. El hackathon se realizó en un formato en línea: nos dieron una descripción de la tarea y un mes para completarla. Los organizadores querían ver un proyecto terminado que ayudará a aumentar la eficiencia energética de las casas de Amsterdam.
Hicimos un proyecto en el que se predice el consumo de electricidad (antes de eso participé en una competencia sobre este tema donde obtuve una solución cercana a la sota, que se puede leer
aquí ) y la generación por un panel solar. Según estas predicciones, el rendimiento de la batería está optimizado (esta idea fue tomada parcialmente de mi diploma de maestría). Nuestro proyecto estuvo en buen acuerdo tanto con la tarea de los organizadores (como nos pareció entonces) como con la política de la administración de Amsterdam en el campo de las energías renovables durante varios años.
Durante la evaluación de proyectos, a nosotros, como a muchos equipos, se nos dijo que esto no era lo que el cliente esperaba, agregando que teníamos que rehacer el proyecto si queríamos competir por un premio. No volvimos a hacer nada, renunciamos a la derrota. De los cuarenta equipos participantes, ni siquiera llegamos al top 7, aunque la elección de los organizadores, me parece, fue bastante extraña. Por ejemplo, se perdieron el equipo final, que hizo una aplicación para calcular la velocidad del viento y la radiación solar (SI) de acuerdo con los sensores de los teléfonos inteligentes: micrófono para el viento, sensor de luz para el SI. El asesino de características tenía una clasificación de hotdog / no hotdog en tres clases: el sol, el viento, el agua y la visualización del artículo de Wikipedia correspondiente (
demo ).
Dejemos por un momento el lado moral del problema: chantajear a los participantes con la posibilidad de victoria es simplemente poco ético. Dado que una de las motivaciones para participar en hackathons (especialmente desarrolladores experimentados) es la realización de sus ideas, muchos participantes fuertes simplemente pueden abandonar el evento después de escuchar tales comentarios (lo que sucedió no solo con nuestro equipo, sino también con otros que dejaron de actualizar la página) de su proyecto después de escuchar al mentor). Sin embargo, digamos que acordamos con los organizadores y rediseñamos nuestro proyecto a sus requerimientos. ¿Qué podría pasar después?
Dado que los organizadores tienen su propia comprensión del "proyecto ideal", todos los deseos (y, en consecuencia, los cambios) nos llevarán a este ideal. Los concursantes pasarán su tiempo y será cada vez más difícil negarse a participar más (ya que ya han invertido su fuerza y parece que no podrán ganar antes). Pero en realidad, la competencia por los premios aumentará, y los participantes tendrán que rehacer cada vez más el proyecto para las correcciones de los organizadores con la esperanza de recibir un premio. Como resultado, los chicos que no tomaron premios, al mirar hacia atrás, se darán cuenta de que participaron en freelance sin dinero: hicieron cambios en el cliente, pero al mismo tiempo no recibieron nada a cambio (excepto la experiencia relevante, por supuesto).
Moraleja
A menudo, los deseos y comentarios de los organizadores ayudan al proyecto. En este caso, sin embargo, los participantes no deben confiar en los consejos de los mentores como cojos. Si escuchas de los organizadores los comentarios sobre tu proyecto en el espíritu de "quítatelo, no lo ordenamos"; tu participación en el hackathon sobre esto se puede considerar completada.
Si está organizando un hackathon con una visión clara del proyecto, pero sin las habilidades o la capacidad de implementarlo usted mismo, es mejor diseñar su visión en forma de tarea técnica para un profesional independiente. De lo contrario, tendrá que pagar dos veces: por el hackathon y por los servicios de un profesional independiente.