В He analizado varias razones para participar en hackatones. La motivación por aprender muchas cosas nuevas y ganar valiosos premios atrae a muchos, pero muchas veces, debido a errores de los organizadores o de las empresas patrocinadoras, el evento termina sin éxito y los participantes se van insatisfechos. Para que estos incidentes desagradables ocurran con menos frecuencia, escribí esta publicación. La segunda parte de la trilogía está dedicada a los errores de los organizadores.
El post está organizado de la siguiente manera: al principio hablo del evento, explico qué salió mal y a qué condujo (o puede conducir a largo plazo). Luego doy mi valoración de lo que está pasando y de lo que haría si fuera el organizador. Puesto que participé en todos los eventos, sólo puedo asumir la verdadera motivación de los organizadores. En consecuencia, mi evaluación puede ser unilateral. No excluyo que algunos puntos que me parecen erróneos en realidad tuvieran esa intención.
En cierto momento, el lector puede pensar que el autor decidió agitar los puños después de una pelea. Pero puedo asegurarles que este no es el caso. En algunos de los hackatones enumerados logré llevarme un premio, lo que, sin embargo, no impide decir que el evento estuvo mal organizado.
Por respeto a los organizadores y participantes, no habrá referencias a empresas específicas en el post. Un lector atento, sin embargo, puede adivinar (o buscar en Google) de quién estamos hablando.
Hackathon No. 1. Marcos estrictos
Hace seis meses, una gran empresa de telecomunicaciones organizó un hackathon sobre análisis de datos. 20 equipos compitieron por el fondo de premios. En el evento se entregó para su análisis un conjunto de datos que contenía información sobre llamadas al servicio de soporte de la empresa, actividad en redes sociales e información codificada sobre los usuarios (sexo, edad, etc.). La parte más interesante del conjunto de datos (mensajes de usuario y respuestas del operador (datos de texto)) era bastante ruidosa y necesitaba ser limpiada para seguir trabajando.
Los organizadores se propusieron una tarea: hacer algo interesante con los datos proporcionados y estaba prohibido utilizar conjuntos de datos abiertos adicionales de la red o analizar los datos usted mismo. También estaba prohibido proponer ideas no relacionadas con el conjunto de datos. Desafortunadamente, los datos proporcionados eran bastante "pobres": fue difícil obtener productos interesantes de ellos, y de la comunicación con los mentores quedó claro que muchas de las ideas propuestas ya se están implementando (o se implementarán en un futuro próximo). en la compañia.
Como resultado, la inmensa mayoría de los equipos (15 de 20) crearon chatbots. Durante las actuaciones, la decisión de un equipo no fue muy diferente a la anterior. Incapaz de soportarlo, uno de los miembros del jurado preguntó al siguiente equipo que subió al escenario: “¿Qué, chicos, también tenéis un chatbot?”. Como resultado, de tres premios, el primer y segundo lugar fueron para los equipos que no crearon chatbots.
A modo de comparación, tomemos un hackathon organizado por una consultora internacional para la empresa Zvezdochka hace dos años. Dado que muchos participantes del hackathon no conocían los detalles específicos de las actividades de la empresa Zvezdochka, al comienzo del evento los organizadores hablaron sobre las métricas que se utilizan en la empresa. A continuación se proporcionaron seis conjuntos de datos de diferentes tipos: texto, tablas, geolocalización: todos los participantes tuvieron margen de maniobra. Los organizadores no prohibieron el uso de conjuntos de datos adicionales e incluso apoyaron iniciativas de este tipo. En la final del concurso, diez equipos con diferentes soluciones compitieron por el premio principal, y todos los equipos utilizaron datos proporcionados por la empresa (a pesar de la ausencia de restricciones), lo que indicaba un buen potencial para obtener productos de calidad.
Moral
No es necesario limitar el flujo creativo de los participantes. Como organizador, debes proporcionar materiales y confiar en su visión y profesionalismo. Si participa en un hackathon, cualquier restricción o prohibición debería alarmarlo, lo cual suele ser una prueba de una mala organización (un ejemplo de la vida real es el deseo constante de colocar una valla en algún lugar). Si aún encuentra restricciones, prepárese para el hecho de que tendrá que crear un proyecto en un grupo con mucha competencia. En este caso, está obligado a correr riesgos: hacer algo fundamentalmente nuevo u ofrecer una "característica excelente" inusual para diferenciarse de la corriente de proyectos monótonos.
Hackatón nº 2. Tareas imposibles
El hackathon de Amador prometía ser interesante. La empresa patrocinadora, un gran fabricante de teléfonos, inició los preparativos 4 meses antes de la fecha del evento. Las relaciones públicas del evento se realizaron en las redes sociales, los potenciales participantes debían pasar una prueba técnica y escribir sobre sus proyectos anteriores para poder ser seleccionados para este evento. El fondo de premios resultó agradablemente grande. Unos días antes del hackathon, los mentores realizaron una sesión técnica para que los participantes tuvieran tiempo de comprender las particularidades de la industria.
En el propio evento, los organizadores proporcionaron un conjunto de datos de registros de equipos con un volumen de 8 GB, la tarea consistía en una clasificación binaria de averías. Hablaron sobre los criterios para evaluar proyectos: calidad de clasificación, creatividad en la creación de funciones, capacidad para trabajar en equipo, etc. Simplemente es mala suerte: para 8 GB de "funciones", solo había 20 ejemplos en el tren y 5 en la prueba. El último clavo en el ataúd del hackathon vino de los datos: los registros de equipos recibidos el miércoles contenían un error en el funcionamiento del equipo, pero los creados el jueves no (por cierto, solo dos equipos sabían de esto, y ambos eran de Rusia, la patria de mineros de datos experimentados). Aunque ni siquiera el conocimiento de las verdaderas etiquetas de la prueba ayudó a determinar la respuesta, la tarea era irresoluble. Los organizadores no obtuvieron el resultado deseado, los participantes dedicaron mucho tiempo a resolver un problema mal diseñado. El hackathon fue un fracaso.
Moral
Realice revisiones técnicas de las asignaciones y verifique que sus asignaciones sean adecuadas. Es mejor pagar de más por un examen preliminar (en este caso, cualquier científico de datos señalaría inmediatamente que es imposible resolver este problema) que arrepentirse más tarde.
En este caso, además de perder tiempo y dinero, la empresa perdió credibilidad ante los posibles candidatos y posiblemente escribió sobre los resultados. Por cierto, no sólo los participantes, sino también la empresa deberían escribir sobre los resultados exitosos, maximizando el hackathon desde el punto de vista de las relaciones públicas. Desafortunadamente, no todas las empresas hacen esto, limitándose solo a una publicación de anuncio y un par de fotos del evento en Twitter.
Hackatón nº 3. Tómelo o déjelo
Más recientemente, nuestro equipo participó en un hackathon en Ámsterdam. Como soy ingeniero eléctrico (en el campo de las fuentes de energía renovables), el tema era perfecto para nosotros: la energía. El hackathon se realizó online: nos dieron una descripción de la tarea y un mes para completarla. Los organizadores querían ver un proyecto terminado que ayudara a aumentar la eficiencia energética de las casas de Ámsterdam.
Hicimos un proyecto en el que se predijo el consumo de electricidad (antes participé en un concurso sobre este tema donde recibí una solución casi Sota, sobre la cual puedes leer ) y generación mediante panel solar. Según estas predicciones, se optimiza el rendimiento de la batería (esta idea fue tomada en parte de mi tesis de maestría). Nuestro proyecto concordaba tanto con las instrucciones de los organizadores (como nos pareció entonces) como con la política de la administración de Ámsterdam en el ámbito de las fuentes de energía renovables para los próximos años.
Durante la evaluación de los proyectos, a nosotros, como a muchos equipos, nos dijeron que esto no era lo que el cliente esperaba y que teníamos que rehacer el proyecto si queríamos competir por el premio. No rehicimos nada, aceptando 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, dejaron pasar a la final al equipo que creó una aplicación para calcular la velocidad del viento y la radiación solar (SI) utilizando datos de sensores de teléfonos inteligentes: un micrófono para el viento, un sensor de luz para el SI. La característica principal fue la clasificación de hot dog/no hot dog en tres clases: sol, viento, agua y la visualización del artículo correspondiente en Wikipedia ().
Dejemos por un momento el lado moral de la cuestión: chantajear a los participantes con la posibilidad de ganar es simplemente poco ético. Dado que una de las motivaciones para participar en hackathons (especialmente los desarrolladores experimentados) es hacer realidad sus ideas, muchos participantes fuertes pueden simplemente abandonar el evento después de escuchar dichos comentarios (lo que le sucedió no solo a nuestro equipo, sino también a varios otros que dejaron de participar). actualizando el proyecto de su página después de escuchar al mentor). Aún así, digamos que estamos de acuerdo con los deseos de los organizadores y rehicimos nuestro proyecto para adaptarlo a sus necesidades. ¿Qué podría pasar a continuación?
Dado que los organizadores tienen su propia comprensión del "proyecto ideal", todos los deseos (y, en consecuencia, los cambios) nos llevarán hacia este ideal. Los competidores perderán el tiempo y les resultará cada vez más difícil negarse a seguir participando (pues ya han invertido sus esfuerzos y parece que están a un poco de ganar). Pero, en realidad, la competencia por los premios aumentará y los participantes tendrán cada vez más que rehacer el proyecto basándose en las ediciones de los organizadores con la esperanza de ganar un premio. Como resultado, los chicos que no recibieron premios, mirando hacia atrás, entenderán que participaron en el trabajo independiente sin dinero: hicieron ediciones para el cliente, pero no recibieron nada a cambio por esto (excepto la experiencia relevante, por supuesto). curso).
Moral
A menudo, los deseos y comentarios de los organizadores ayudan al proyecto. Al mismo tiempo, sin embargo, los participantes no deben confiar en los consejos de sus mentores como un cojo sobre un bastón. Si escucha comentarios de los organizadores sobre su proyecto con el espíritu de "llévelo, no lo ordenamos", su participación en el hackathon se puede considerar completada.
Si está organizando un hackathon con una visión clara del proyecto, pero sin las habilidades o la capacidad para implementarlo usted mismo, entonces es mejor formalizar su visión en forma de especificaciones técnicas para un profesional independiente. De lo contrario, tendrás que pagar dos veces: por el hackathon y por los servicios del autónomo.
Fuente: habr.com