В Observei varias razóns para participar en hackathons. A motivación por aprender moitas cousas novas e gañar valiosos premios atrae a moitos, pero moitas veces, por erros dos organizadores ou das empresas patrocinadoras, o evento remata sen éxito e os participantes marchan insatisfeitos. Para que incidentes tan desagradables sucedan con menos frecuencia, escribín esta publicación. A segunda parte da triloxía está dedicada aos erros dos organizadores.
A publicación organízase do seguinte xeito: ao principio falo do evento, explico o que foi mal e a que levou (ou pode levar a longo prazo). Despois dou a miña valoración do que está a suceder e do que faría se eu fose os organizadores. Xa que participei en todos os eventos, só podo asumir a verdadeira motivación dos organizadores. Como resultado, a miña valoración pode ser unilateral. Non exclúo que algúns puntos que me parecen erróneos fosen de feito pensados así.
En certo momento, o lector pode pensar que o autor decidiu axitar os puños despois dunha pelexa. Pero pódoche asegurar que non é así. Nalgunhas das hackathons listadas, conseguín levarme un premio, o que, porén, non impide dicir que o evento estaba mal organizado.
Por respecto aos organizadores e participantes, non se farán referencias a empresas concretas no post. Un lector atento, con todo, pode adiviñar (ou Google) de quen estamos a falar.
Hackathon no 1. Límites estritos
Hai seis meses, unha gran empresa de telecomunicacións organizou un hackathon sobre análise de datos. 20 equipos competiron polo fondo do premio. No acto facilitouse para a súa análise un conxunto de datos que contiña información sobre chamadas ao servizo de soporte da empresa, actividade nas redes sociais e información codificada sobre os usuarios (sexe, idade, etc.). A parte máis interesante do conxunto de datos, as mensaxes dos usuarios e as respostas dos operadores (datos de texto), era bastante ruidosa e necesitaba ser limpa para seguir traballando.
Os organizadores estableceron unha tarefa: facer algo interesante cos datos proporcionados, e estaba prohibido usar conxuntos de datos abertos adicionais da rede ou analizar os datos vostede mesmo. Tamén estaba prohibido propoñer ideas non relacionadas co conxunto de datos. Desafortunadamente, os datos proporcionados eran bastante "pobres": era difícil obter produtos interesantes deles, e a partir da comunicación cos mentores quedou claro que moitas das ideas propostas xa se están implementando (ou se implementarán nun futuro próximo) na empresa.
Como resultado, o número abrumador de equipos (15 de 20) fixo chatbots. Durante as actuacións, a decisión dun equipo foi pouco diferente á anterior. Incapaz de soportar, un dos membros do xurado preguntou ao seguinte equipo que subía ao escenario: "Que, rapaces, tamén tedes un chatbot?" Como resultado, de tres premios, o primeiro e o segundo posto foron para os equipos que non fixeron chatbots.
A modo de comparación, tomemos un hackathon organizado por unha empresa de consultoría internacional para a empresa Zvezdochka hai dous anos. Dado que os detalles das actividades da empresa Zvezdochka eran descoñecidos para moitos participantes en hackathon, ao comezo do evento os organizadores falaron sobre as métricas que se usan na empresa. Despois disto, proporcionáronse seis conxuntos de datos de diferentes tipos: texto, táboas, xeolocalización: había marxe de manobra para todos os participantes. Os organizadores non prohibiron o uso de conxuntos de datos adicionais e mesmo apoiaron este tipo de iniciativas. Nas finais da competición competiron polo premio principal dez equipos con diferentes solucións, todos os equipos empregando datos facilitados pola empresa (a pesar da falta de restricións), que indicaban un bo potencial para obter produtos de calidade.
Moralidade
Non hai que limitar o fluxo creativo dos participantes. Como organizador, debes proporcionar materiais e confiar na súa visión e profesionalidade. Se participas nun hackathon, calquera restrición ou prohibición debería alarmarte. Normalmente isto é unha evidencia de mala organización (un exemplo da vida real é o desexo constante de pegar un valado nalgún lugar). Se atopas restricións, prepárate para o feito de que terás que crear un proxecto nunha piscina con moita competencia. Neste caso, estás obrigado a asumir riscos: facer algo fundamentalmente novo ou ofrecer unha "función asasina" inusual para destacar do fluxo de proxectos monótonos.
Hackathon no 2. Tarefas imposibles
O hackathon en Amador prometía ser interesante. A empresa patrocinadora, un gran fabricante de teléfonos, comezou os preparativos 4 meses antes da data do evento. O PR para o evento realizouse nas redes sociais; os potenciais participantes tiveron que pasar unha proba técnica e escribir sobre os seus proxectos pasados para ser seleccionados para este evento. O fondo do premio foi gratamente grande. Uns días antes do hackathon, os mentores realizaron unha sesión técnica para que os participantes tivesen tempo para comprender as particularidades do sector.
No propio evento, os organizadores proporcionaron un conxunto de datos de rexistros de equipos cun volume de 8 GB, a tarefa foi unha clasificación binaria de avarías. Falaron dos criterios de avaliación dos proxectos: calidade da clasificación, creatividade na creación de características, capacidade de traballo en equipo, etc. É só mala sorte: para 8 GB de "funcións", só había 20 exemplos no tren e 5 na proba. O cravo definitivo no cadaleito do hackathon saíu dos datos: os rexistros do equipamento recibidos o mércores contiñan un erro no funcionamento do equipamento, pero os creados o xoves non (por certo, só dous equipos sabían disto, e ambos eran de Rusia, a patria dos experimentados mineiros de datos). Aínda que mesmo o coñecemento das verdadeiras etiquetas da proba non axudou a determinar a resposta, a tarefa era irresoluble. Os organizadores non obtiveron o resultado desexado, os participantes dedicaron moito tempo a resolver un problema mal deseñado. O hackathon foi un fracaso.
Moralidade
Realice revisións técnicas dos traballos e comprobe a súa adecuación. É mellor pagar de máis por un exame preliminar (neste caso, calquera científico de datos sinalaría inmediatamente que é imposible resolver este problema) que lamentarse máis tarde.
Neste caso, ademais de perder tempo e diñeiro, a empresa perdeu credibilidade cos posibles candidatos e posiblemente escribiu sobre os resultados. Por certo, non só os participantes, senón tamén a empresa deberían escribir sobre os resultados exitosos, maximizando o hackathon desde o punto de vista das relacións públicas. Desafortunadamente, non todas as empresas fan isto, limitándose a só unha publicación de anuncio e un par de fotos do evento en Twitter.
Hackathon no 3. Tómao ou déixao
Máis recentemente, o noso equipo participou nun hackathon en Amsterdam. Como son enxeñeiro eléctrico de formación (no campo das fontes de enerxía renovables), o tema era o adecuado para nós: a enerxía. O hackathon realizouse en liña: déronnos unha descrición da tarefa e un mes para realizala. Os organizadores querían ver un proxecto rematado que axudase a aumentar a eficiencia enerxética das casas de Amsterdam.
Fixemos un proxecto no que se prevía o consumo de electricidade (antes participei nun concurso sobre este tema onde recibín unha solución case sota, que podedes ler). ) e xeración mediante panel solar. En base a estas previsións, optimízase o rendemento da batería (esta idea foi tomada en parte da miña tese de máster). O noso proxecto concordaba tanto coas indicacións dos organizadores (como nos pareceu entón), como coa política da administración de Amsterdam en materia de enerxías renovables durante varios anos.
Durante a avaliación dos proxectos, a nós, como moitos equipos, dixéronnos que non era o que esperaba o cliente, engadindo que tiñamos que refacer o proxecto se queriamos competir polo premio. Non refacemos nada, aceptando a derrota. Dos corenta equipos participantes, nin sequera chegamos aos 7 primeiros, aínda que a elección dos organizadores, paréceme, foi bastante estraña. Por exemplo, permitiron ao equipo pasar ás finais que fixo unha aplicación para calcular a velocidade do vento e a radiación solar (SI) utilizando datos dos sensores dos teléfonos intelixentes: un micrófono para o vento, un sensor de luz para o SI. A característica asasina foi a clasificación de hotdog/non hotdog en tres clases: Sol, vento, auga e visualización do artigo correspondente na Wikipedia ().
Deixemos por un momento o lado moral da cuestión: chantaxear aos participantes coa posibilidade de vitoria é simplemente pouco ético. Dado que unha das motivacións para participar en hackathons (especialmente os desenvolvedores experimentados) é realizar as súas ideas, moitos participantes fortes poden simplemente abandonar o evento despois de escoitar tales comentarios (que non só lle pasou ao noso equipo, senón tamén a outros que deixaron de participar). actualizando o seu proxecto de páxina despois de escoitar ao mentor). Aínda así, digamos que coincidimos cos desexos dos organizadores e que refacemos o noso proxecto para adaptalo ás súas necesidades. Que podería pasar despois?
Dado que os organizadores teñen a súa propia comprensión do "proxecto ideal", todos os desexos (e, en consecuencia, os cambios) levaránnos cara a este ideal. Os competidores perderán o seu tempo e será cada vez máis difícil que se neguen a seguir participando (xa que xa investiron os seus esforzos, e parece que están a un pouco de gañar). Pero en realidade, a competencia por premios aumentará e os participantes terán que refacer cada vez máis o proxecto en función das edicións dos organizadores coa esperanza de gañar un premio. Como resultado, os mozos que non levaron premios, mirando atrás, entenderán que participaron en freelance sen diñeiro: fixeron edicións para o cliente, pero non recibiron nada a cambio diso (salvo a experiencia pertinente, de curso).
Moralidade
Moitas veces os desexos e comentarios dos organizadores veñen en axuda do proxecto. Ao mesmo tempo, con todo, os participantes non deben confiar no consello de mentores como un coxo nun bastón. Se escoitas comentarios dos organizadores sobre o teu proxecto co espírito de "quítao, non pedimos isto", a túa participación no hackathon pode considerarse rematada.
Se estás a organizar un hackathon cunha visión clara do proxecto, pero sen as habilidades nin a capacidade de implementalo por ti mesmo, é mellor formalizar a túa visión en forma de especificacións técnicas para un autónomo. En caso contrario, terás que pagar dúas veces: o hackathon e os servizos do autónomo.
Fonte: www.habr.com