En He considerado varias razones para participar en hackatones. La motivación de aprender mucho y ganar premios valiosos atrae a muchos, pero a menudo, debido a errores de los organizadores o empresas patrocinadoras, el evento termina en fracaso y los participantes se van insatisfechos. Para que estos desagradables incidentes ocurran con menos frecuencia, he escrito 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é ha llevado (o podría llevar a largo plazo). Luego doy mi evaluación de lo que ocurrió y cómo actuaría yo en el lugar de los organizadores. Dado que en todos los eventos he participado como concursante, solo puedo suponer la verdadera motivación de los organizadores. Por lo tanto, mi evaluación puede ser unilateral. No descarto que algunos aspectos que considero erróneos podrían haber sido propuestos de esa manera.
En cierto momento, al lector puede parecerle que el autor ha decidido sacar conclusiones después del hecho. Pero puedo asegurarles que no es así. En algunos de los hackatones mencionados, logré obtener un lugar en el podio, lo cual, sin embargo, no impide hablar de que el evento fue mal organizado.
Por respeto a los organizadores y participantes, en la publicación no se harán menciones específicas a empresas. Sin embargo, un lector atento puede adivinar (o buscar en Google) de quién se trata.
Hackathon Nº 1. Líneas estrictas
Hace seis meses, una gran empresa de telecomunicaciones organizó un hackatón sobre análisis de datos. 20 equipos competían por el fondo de premios. En el evento se proporcionó un conjunto de datos para el análisis, que contenía información sobre las consultas al servicio de atención al cliente de la empresa, actividad en redes sociales y datos codificados sobre los usuarios (género, edad, etc.). La parte más interesante del conjunto de datos — mensajes del usuario y respuesta del operador (datos textuales) — era bastante "ruidosa" y, para un trabajo posterior, era necesario limpiarla.
Los organizadores establecieron la tarea de hacer algo interesante con los datos proporcionados, prohibiendo el uso de conjuntos de datos abiertos adicionales de la red o la recolección de datos por cuenta propia. También estaba prohibido proponer ideas no relacionadas con el conjunto de datos. Lamentablemente, los datos proporcionados eran bastante 'pobres': era difícil obtener productos interesantes de ellos, y de las conversaciones con los mentores quedó claro que muchas de las ideas propuestas ya estaban siendo implementadas (o se implementarán en un futuro cercano) en la empresa.
Como resultado, la gran mayoría de los equipos (15 de 20) hicieron chatbots. Durante las presentaciones, la solución de un equipo se diferenciaba poco de la anterior. No pudiendo soportarlo, uno de los miembros del jurado preguntó a otro equipo que subía al escenario: '¿Qué pasa chicos, ustedes también tienen un chatbot?'. Al final, de los tres lugares premiados, el primer y segundo lugar fueron otorgados a los equipos que no hicieron chatbots.
Para comparar, tomemos el hackathon organizado por una empresa de consultoría internacional para la firma 'Estrella' hace dos años. Dado que la naturaleza del trabajo de la empresa 'Estrella' no era familiar para muchos de los participantes del hackathon, al inicio del evento los organizadores presentaron las métricas que se aplican en la empresa. Después de eso, se proporcionaron seis conjuntos de datos de diferentes enfoques: textos, tablas, geolocalización, brindando a todos los participantes un amplio margen de maniobra. Los organizadores no prohibieron el uso de conjuntos de datos adicionales e incluso apoyaron tales iniciativas. Al final de la competencia, diez equipos con diferentes soluciones lucharon por el premio mayor, y todos los equipos utilizaron los datos proporcionados por la empresa (a pesar de la falta de prohibiciones), lo que evidenció un buen potencial para la obtención de productos de calidad.
Moral
No debes limitar el flujo creativo de los participantes. Como organizador, debes proporcionar materiales y confiar en su visión y profesionalismo. Si eres participante de un hackathon, cualquier restricción o prohibición debería alertarte. Generalmente, esto es señal de una mala organización (un ejemplo de la vida real es el constante deseo de clavar una cerca en un lugar). Si te enfrentas a alguna limitación, prepárate para crear un proyecto en un entorno altamente competitivo. En tal caso, debes arriesgarte: hacer algo radicalmente nuevo o proponer una 'característica killer' inusual para destacar entre la corriente de proyectos homogéneos.
Hackathon #2. Tareas imposibles
El hackathon en Amador prometía ser interesante. La empresa patrocinadora, un importante fabricante de teléfonos, comenzó su preparación cuatro meses antes de la fecha del evento. Se llevó a cabo una campaña de promoción en redes sociales y los potenciales participantes debían pasar una prueba técnica y describir sus proyectos previos para ser seleccionados para este evento. El fondo de premios era bastante atractivo. Unos días antes del hackathon, los mentores realizaron una sesión técnica para que los participantes tuvieran tiempo de familiarizarse con la especificidad del sector.
Durante el evento, los organizadores proporcionaron un conjunto de datos de logs del equipo de 8 GB; el objetivo era la clasificación binaria de fallos. Explicaron los criterios de evaluación de los proyectos: calidad de la clasificación, creatividad en la creación de características, habilidad para trabajar en equipo, etc. Sin embargo, el problema era que de las 8 GB de 'características', solo había 20 ejemplos en el entrenamiento y 5 en la prueba. El clavo final en el ataúd del hackathon fue la fuga de datos: los logs del equipo obtenidos el miércoles contenían un error en el funcionamiento del equipo, mientras que los generados el jueves no lo tenían (de esto, por cierto, solo dos equipos sabían, y ambos eran de Rusia, la tierra de los experimentados dataminers). Aunque conocer las etiquetas verdaderas de la prueba no ayudó a ajustar la respuesta, la tarea resultó ser irresoluble. Los organizadores no obtuvieron el resultado deseado, y los participantes gastaron una gran cantidad de tiempo resolviendo una tarea mal planteada. El hackathon fue un fracaso.
Moral
Realice auditorías técnicas de tareas y verifique la adecuación de sus asignaciones. Es mejor pagar de más por una evaluación previa (en este caso, cualquier científico de datos señalaría inmediatamente la imposibilidad de resolver esta tarea) que lamentarse después.
En este caso, además del tiempo y dinero gastados, la empresa perdió la credibilidad entre posibles candidatos y posiblemente escribir sobre los resultados. Por cierto, sobre los resultados exitosos no solo deben escribir los participantes, sino también la empresa, maximizando el hackatón desde el punto de vista del PR. Desafortunadamente, no todas las empresas lo hacen, limitándose solo a una publicación de anuncio y un par de fotos del evento en Twitter.
Hackatón Nº3. Accepta o déjalo.
Recientemente, nuestro equipo participó en un hackatón en Ámsterdam. Dado que soy ingeniero en energías eléctricas (en el área de fuentes de energía renovables), el tema era perfecto para nosotros: energía. El hackatón se llevó a cabo en formato online: nos dieron la 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 que predice el consumo de electricidad (antes de esto participé en un concurso sobre este tema donde obtuve una solución aproximada que se puede leer ) y la generación de energía solar. Basándose en estas predicciones, se optimiza el funcionamiento de la batería (esta idea fue parcialmente tomada de mi trabajo de maestría). Nuestro proyecto estaba bien alineado tanto con la tarea de los organizadores (como nos parecía en ese momento) como con la política de la administración de Ámsterdam en el área de energías renovables para los próximos años.
Durante la evaluación de proyectos, como a muchos equipos, nos dijeron que no era lo que el cliente esperaba, añadiendo que debíamos rehacer el proyecto si queríamos competir por un lugar en el podio. No hicimos ningún cambio, aceptando nuestra derrota. De los cuarenta equipos participantes, no llegamos ni al top 7, aunque la elección de los organizadores, a mi parecer, fue bastante extraña. Por ejemplo, dejaron pasar a la final a un equipo que desarrolló una aplicación para calcular la velocidad del viento y la radiación solar (SI) a partir de los datos de los sensores del teléfono: un micrófono para el viento, un sensor de luz — para la SI. La killer feature era la clasificación hotdog/not hotdog en tres clases: Sol, viento, agua y mostrar el artículo correspondiente de Wikipedia.).
Dejemos a un lado por un momento el aspecto 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 hackatones (especialmente para desarrolladores experimentados) es llevar a cabo sus ideas, muchos participantes sólidos pueden simplemente abandonar el evento al escuchar esa retroalimentación (lo que no solo ocurrió con nuestro equipo, sino con varios otros que dejaron de actualizar la página de su proyecto después de escuchar al mentor). Supongamos que aceptamos la solicitud de los organizadores y rehacemos nuestro proyecto según sus requisitos. ¿Qué podría suceder después?
Dado que los organizadores tienen su propia visión de un “proyecto ideal”, todos los deseos (y por lo tanto, los cambios) nos llevarán a ese ideal. Los concursantes dedicarán su tiempo y les será cada vez más difícil renunciar a su participación (ya que han invertido esfuerzo, y parece que la victoria está a la vuelta de la esquina). Pero en realidad, la competencia por los lugares premiados aumentará, y los participantes tendrán que rehacer sus proyectos cada vez más a menudo según los ajustes de los organizadores con la esperanza de ganar un premio. Al final, los chicos que no ocuparon lugares premiados, al mirar hacia atrás, entenderán que participaron en un trabajo freelance sin pago: realizaron cambios para el cliente, pero no obtuvieron nada a cambio (excepto, por supuesto, la experiencia correspondiente).
Moral
A menudo, los deseos y comentarios de los organizadores son de gran ayuda para el proyecto. Sin embargo, los participantes no deben apoyarse en los consejos de los mentores como un cojo en una muleta. Si recibe comentarios de los organizadores sobre su proyecto en el sentido de 'eliminen esto, no lo solicitamos', puede considerar que su participación en el hackathon ha concluido.
Si está organizando un hackathon con una visión clara del proyecto, pero sin habilidades o la posibilidad de llevarlo a cabo por sí mismo, es mejor plasmar su visión en un documento técnico para un freelancer. De lo contrario, tendrá que pagar dos veces: por el hackathon y por los servicios del freelancer.
Fuente: habr.com
