Em Considerei algumas razões para participar em hackathons. A motivação para aprender algo novo e ganhar prêmios valiosos atrai muitos, mas muitas vezes, devido a erros dos organizadores ou empresas patrocinadoras, o evento termina mal e os participantes saem insatisfeitos. Para que tais situações desagradáveis ocorram com menos frequência, escrevi este post. A segunda parte da trilogia é dedicada aos erros dos organizadores.
O post está organizado da seguinte forma: no início, falo sobre o evento, explico o que deu errado e a que isso levou (ou pode levar a longo prazo). Em seguida, dou minha avaliação do que aconteceu e como agiria se estivesse no lugar dos organizadores. Como participei de todos os eventos, posso apenas supor a verdadeira motivação dos organizadores. Assim, minha avaliação pode ser tendenciosa. Não excluo que alguns pontos que vejo como errados possam ter sido realmente planejados dessa forma.
Em certo momento, o leitor pode achar que o autor decidiu agitar os punhos depois da briga. Mas posso assegurar que não é assim. Em alguns dos hackathons mencionados, consegui conquistar um prêmio, o que, no entanto, não impede de afirmar que o evento foi mal organizado.
Por respeito aos organizadores e participantes, o post não indicará empresas específicas. O leitor atento, no entanto, pode adivinhar (ou pesquisar) sobre quem estou falando.
Hackathon nº 1. Restrições rigorosas
Há seis meses, uma grande empresa de telecomunicações organizou um hackathon sobre análise de dados. Um prêmio foi disputado por 20 equipes. No evento, um conjunto de dados foi fornecido para análise, que incluía informações sobre atendimentos ao cliente, atividades nas redes sociais e informações codificadas sobre os usuários (gênero, idade, etc.). A parte mais interessante do conjunto de dados — mensagens de usuários e respostas dos operadores (dados textuais) — era bastante "ruidosa"; para um trabalho mais aprofundado, era necessário filtrá-la.
Os organizadores deram a tarefa de fazer algo interessante com os dados fornecidos, proibindo o uso de conjuntos de dados abertos da internet ou de realizar scraping dos dados. Também era proibido sugerir ideias não relacionadas ao conjunto de dados. Infelizmente, os dados fornecidos eram bastante "pobres": era difícil obter produtos interessantes e, após conversas com os mentores, ficou claro que muitas das ideias propostas já estavam sendo realizadas (ou seriam realizadas em um futuro próximo) pela empresa.
Como resultado, a esmagadora maioria das equipes (15 de 20) criou chatbots. Durante as apresentações, a solução de uma equipe era pouco diferenciada da anterior. Não aguentando, um dos membros do júri perguntou para mais uma equipe que subiu ao palco: "Então, pessoal, vocês também têm um chatbot?" No final, dos três lugares de prêmio, o primeiro e o segundo foram conquistados por equipes que não optaram por desenvolver chatbots.
Para comparação, vamos considerar o hackathon organizado por uma consultoria internacional para a empresa "Estrela" há dois anos. Como a natureza das atividades da empresa "Estrela" era desconhecida para muitos participantes do hackathon, no início do evento, os organizadores explicaram as métricas utilizadas na empresa. Após isso, foram fornecidos seis conjuntos de dados de diferentes áreas: textos, tabelas, geolocalização – havia amplo espaço para todos os participantes. Os organizadores não proibiram o uso de conjuntos de dados adicionais e até apoiaram tais iniciativas. No final da competição, dez equipes com soluções diferentes disputaram o prêmio principal, sendo que todas as equipes utilizaram os dados fornecidos pela empresa (apesar da ausência de proibições), o que demonstrava um bom potencial para a obtenção de produtos de qualidade.
Moral
Não limite o fluxo criativo dos participantes. Como organizador, você deve fornecer materiais e confiar em sua visão e profissionalismo. Se você é um participante do hackathon, quaisquer restrições ou proibições devem acender um sinal de alerta. Isso geralmente é sinal de uma má organização (um exemplo da vida real — a constante vontade de colocar uma cerca em qualquer lugar). Caso você se depare com restrições, esteja preparado para criar um projeto em um ambiente altamente competitivo. Nesse caso, você deve correr riscos: fazer algo fundamentalmente novo ou oferecer um "recurso matador" incomum para se destacar entre a enxurrada de projetos semelhantes.
Hackathon nº 2. Tarefas impossíveis
O hackathon em Amadora prometia ser interessante. A empresa patrocinadora — um grande fabricante de telefones — começou a se preparar quatro meses antes da data do evento. Nas redes sociais, houve uma campanha de marketing para o evento, e os potenciais participantes precisavam passar por um teste técnico e descrever seus projetos anteriores para serem selecionados para este evento. O prêmio era agradavelmente generoso. Alguns dias antes do hackathon, mentores realizaram uma sessão técnica para dar aos participantes tempo para se familiarizarem com a especificidade do setor.
No evento em si, os organizadores forneceram um conjunto de dados de logs de equipamentos com volume de 8 GB, e a tarefa era a classificação binária de falhas. Eles explicaram os critérios de avaliação dos projetos — qualidade da classificação, criatividade na criação de recursos, capacidade de trabalhar em equipe, etc. Mas, aqui está o problema — em 8 GB de "recursos", houve apenas 20 exemplos no conjunto de treino e 5 no teste. A gota d'água para o fracasso do hackathon foi a discrepância nos dados: os logs de equipamentos coletados na quarta-feira continham um erro no funcionamento do equipamento, enquanto os gerados na quinta-feira não apresentavam (e isso, por sinal, só era sabido por duas equipes, ambas da Rússia — a terra dos experientes mineradores de dados). Embora conhecer os rótulos verdadeiros do teste não tenha ajudado a gerar uma resposta adequada, a tarefa era, de fato, irresolúvel. Os organizadores não obtiveram o resultado desejado, enquanto os participantes perderam uma quantidade considerável de tempo resolvendo uma tarefa mal formulada. O hackathon foi um fracasso.
Moral
Realize auditorias técnicas das tarefas e verifique seus trabalhos quanto à adequação. É melhor pagar a mais pela auditoria preliminar (neste caso, qualquer cientista de dados teria imediatamente apontado a impossibilidade de resolver essa tarefa) do que depois se arrepender.
Nesse caso, além do tempo e dinheiro gastos, a empresa perdeu a credibilidade perante candidatos potenciais e talvez escreva sobre os resultados. Vale mencionar que os resultados bem-sucedidos devem ser narrados não apenas pelos participantes, mas também pela empresa, maximizando a realização do hackathon do ponto de vista de PR. Infelizmente, nem todas as empresas fazem isso, limitando-se a uma postagem de anúncio e algumas fotos do evento no Twitter.
Hackathon nº 3. Leve ou deixe.
Recentemente, nossa equipe participou de um hackathon em Amsterdã. Como sou formado em engenharia elétrica (na área de fontes de energia renováveis), o tema era perfeito para nós — energia. O hackathon foi realizado online: nos deram uma descrição da tarefa e um mês para conclusão. Os organizadores queriam ver um projeto pronto que ajudasse a aumentar a eficiência energética das casas de Amsterdã.
Criamos um projeto que prevê o consumo de energia elétrica (antes disso, participei de um concurso com esse tema, onde obtive uma solução de cerca de SOTA, sobre a qual é possível ler) e a geração por painéis solares. Com base nessas previsões, otimiza-se o funcionamento da bateria de armazenamento (essa ideia foi parcialmente baseada na minha dissertação de mestrado). Nosso projeto estava bem alinhado tanto com a tarefa dos organizadores (como nos parecia na época), quanto com a política da administração de Amsterdã em relação às fontes de energia renováveis nos próximos anos. )
Durante a avaliação dos projetos, nós, assim como muitas equipes, recebemos a informação de que não era isso que o cliente esperava, acrescentando que deveríamos refazer o projeto se quiséssemos concorrer a um lugar no pódio. Nós não refizemos nada, aceitando a derrota. Das quarenta equipes participantes, não chegamos nem mesmo ao top 7, embora a escolha dos organizadores tenha sido, na minha opinião, bastante estranha. Por exemplo, eles deixaram passar para a final uma equipe que desenvolveu um aplicativo para calcular a velocidade do vento e a radiação solar (RS) com dados de sensores de smartphone: um microfone para captar o vento e um sensor de luminosidade para a RS. A grande novidade foi a classificação hotdog/not hotdog em três classes: Sol, vento e água, além da exibição do respectivo artigo na Wikipédia.).
Deixemos de lado, por um minuto, o lado moral da questão: chantagear os participantes com a possibilidade de vitória é simplesmente antiético. Dado que uma das motivações para participar de hackathons (especialmente para desenvolvedores experientes) é a realização de suas ideias, muitos participantes fortes podem simplesmente abandonar o evento ao ouvirem esse tipo de feedback (o que não ocorreu apenas com nossa equipe, mas também com várias outras que pararam de atualizar a página de seus projetos após o feedback do mentor). Supondo, entretanto, que concordamos com os desejos dos organizadores e refizemos nosso projeto de acordo com suas exigências. O que pode acontecer a seguir?
Como os organizadores têm sua própria visão do que é um "projeto ideal", todas as sugestões (e, consequentemente, as alterações) nos direcionarão para esse ideal. Os concorrentes gastarão seu tempo e será cada vez mais difícil para eles desistirem da participação (já que esforços já foram investidos, e parece que a vitória está a poucos passos). Mas, na verdade, a competição por prêmios aumentará, e os participantes terão que refazer seus projetos conforme as correções dos organizadores na esperança de conquistar um prêmio. No final, os que não conquistaram prêmios olharão para trás e perceberão que participaram de um trabalho freelancer sem remuneração: fizeram alterações conforme o cliente pedia, mas não receberam nada em troca (exceto, é claro, pela experiência adquirida).
Moral
Muitas vezes, os desejos e feedbacks dos organizadores vêm em ajuda ao projeto. No entanto, os participantes não devem depender dos conselhos dos mentores como um manco depende de uma bengala. Se você ouvir dos organizadores um feedback sobre o seu projeto no sentido de "remova isso, nós não pedimos" — sua participação no hackathon pode ser considerada encerrada.
Se você está organizando um hackathon com uma visão clara do projeto, mas sem habilidades ou possibilidades de realizá-lo sozinho, é melhor formalizar sua visão em um documento técnico para um freelancer. Caso contrário, você terá que pagar duas vezes — uma pelo hackathon e outra pelos serviços do freelancer.
Fonte: habr.com
