В Analisei vários motivos para participar de hackathons. A motivação para aprender muitas coisas novas e ganhar prêmios valiosos atrai muitos, mas muitas vezes, por erros dos organizadores ou empresas patrocinadoras, o evento termina sem sucesso e os participantes saem insatisfeitos. Para fazer com que esses incidentes desagradáveis aconteçam 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 o que levou (ou pode levar no longo prazo). Depois dou a minha avaliação do que está acontecendo e do que faria se fosse o organizador. Como participei em todos os eventos, só posso assumir a verdadeira motivação dos organizadores. Como resultado, minha avaliação pode ser unilateral. Não excluo que alguns pontos que me parecem erróneos tenham sido de facto concebidos dessa forma.
A certa altura, o leitor pode pensar que o autor decidiu agitar os punhos após uma briga. Mas posso garantir que não é esse o caso. Em alguns dos hackathons listados consegui levar um prêmio, o que, no entanto, não nos impede de dizer que o evento foi mal organizado.
Por respeito aos organizadores e participantes, não haverá referências a empresas específicas no post. Um leitor atento, porém, pode adivinhar (ou pesquisar no Google) de quem estamos falando.
Hackathon nº 1. Estruturas rígidas
Há seis meses, uma grande empresa de telecomunicações organizou um hackathon sobre análise de dados. 20 equipes competiram pelo fundo de prêmios. No evento foi disponibilizado para análise um conjunto de dados que continha informação sobre chamadas para o serviço de apoio da empresa, atividade nas redes sociais e informação codificada sobre os utilizadores (género, idade, etc.). A parte mais interessante do conjunto de dados – mensagens do usuário e respostas do operador (dados de texto) – era bastante barulhenta e precisava ser limpa para trabalhos futuros.
Os organizadores definiram uma tarefa - fazer algo interessante com os dados fornecidos, e foi proibido usar conjuntos de dados abertos adicionais da rede ou analisar os dados por conta própria. Também foi proibido propor ideias não relacionadas ao conjunto de dados. Infelizmente, os dados fornecidos eram bastante “fracos”: era difícil obter deles quaisquer produtos interessantes e, a partir da comunicação com os mentores, ficou claro que muitas das ideias propostas já estão a ser implementadas (ou serão implementadas num futuro próximo). na empresa.
Como resultado, um grande número de equipes (15 em 20) criou chatbots. Durante as atuações, a decisão de uma equipe pouco diferente da anterior. Incapaz de aguentar, um dos jurados perguntou à próxima equipe que subiu ao palco: “E aí, pessoal, vocês também têm chatbot?” Com isso, dos três prêmios, o primeiro e o segundo lugares foram para as equipes que não confeccionaram chatbots.
Para efeito de comparação, tomemos um hackathon organizado por uma empresa de consultoria internacional para a empresa Zvezdochka há dois anos. Como as especificidades das atividades da empresa Zvezdochka eram desconhecidas para muitos participantes do hackathon, no início do evento os organizadores falaram sobre as métricas que são utilizadas na empresa. Depois disso, foram fornecidos seis conjuntos de dados de diferentes tipos: texto, tabelas, geolocalização – houve margem de manobra para todos os participantes. Os organizadores não proibiram a utilização de conjuntos de dados adicionais e até apoiaram tais iniciativas. Nas finais da competição, dez equipes com soluções diferentes disputaram o prêmio principal, sendo que todas as equipes utilizaram dados fornecidos pela empresa (apesar da ausência de restrições), que indicaram bom potencial para obtenção de produtos de qualidade.
Moralidade
Não há necessidade de limitar o fluxo criativo dos participantes. Como organizador, você deve fornecer materiais e confiar na sua visão e profissionalismo. Se você participa de um hackathon, quaisquer restrições ou proibições devem alarmá-lo. Geralmente, isso é evidência de má organização (um exemplo da vida real é o desejo constante de colocar uma cerca em algum lugar). Se você ainda encontrar restrições, esteja preparado para o fato de que terá que criar um projeto em um pool com muita concorrência. Nesse caso, você é obrigado a correr riscos: fazer algo fundamentalmente novo ou oferecer um “recurso matador” incomum para se destacar no fluxo de projetos monótonos.
Hackatona nº 2. Tarefas impossíveis
O hackathon em Amador prometia ser interessante. A empresa patrocinadora, grande fabricante de telefones, iniciou os preparativos 4 meses antes da data do evento. A RP do evento foi realizada nas redes sociais; os potenciais participantes tiveram que passar por um teste técnico e escrever sobre seus projetos anteriores para serem selecionados para este evento. O fundo de prêmios era agradavelmente grande. Poucos dias antes do hackathon, os mentores realizaram uma sessão técnica para que os participantes tivessem tempo de entender as especificidades do setor.
No próprio evento, os organizadores disponibilizaram um conjunto de dados de registros de equipamentos com volume de 8 GB, a tarefa era uma classificação binária de avarias. Falaram sobre os critérios de avaliação de projetos – qualidade de classificação, criatividade na criação de funcionalidades, capacidade de trabalhar em equipe, etc. É apenas azar - para 8 GB de “recursos”, havia apenas 20 exemplos no trem e 5 no teste. O último prego no caixão do hackathon veio dos dados: os logs de equipamentos recebidos na quarta continham erro no funcionamento do equipamento, mas os criados na quinta não (aliás, apenas duas equipes sabiam disso, e ambos eram da Rússia, terra natal de mineradores de dados experientes). Embora mesmo o conhecimento dos verdadeiros rótulos do teste não tenha ajudado a determinar a resposta, a tarefa era insolúvel. Os organizadores não obtiveram o resultado desejado; os participantes gastaram muito tempo resolvendo um problema mal elaborado. O hackathon foi um fracasso.
Moralidade
Conduza revisões técnicas de atribuições e verifique se suas atribuições estão adequadas. É melhor pagar a mais por um exame preliminar (neste caso, qualquer cientista de dados apontaria imediatamente que é impossível resolver este problema) do que se arrepender mais tarde.
Nesse caso, além do desperdício de tempo e dinheiro, a empresa perdeu credibilidade junto a potenciais candidatos e possivelmente escreveu sobre os resultados. Aliás, não só os participantes, mas também a empresa devem escrever sobre resultados bem-sucedidos, maximizando o hackathon do ponto de vista de relações públicas. Infelizmente, nem todas as empresas fazem isso, limitando-se apenas a um anúncio e algumas fotos do evento no Twitter.
Hackatona nº 3. É pegar ou largar
Mais recentemente, a nossa equipa participou num hackathon em Amesterdão. Como sou engenheiro eletricista de formação (na área de fontes de energia renováveis), o tema era o ideal para nós - energia. O hackathon foi realizado online: recebemos uma descrição da tarefa e um mês para concluí-la. Os organizadores queriam ver um projeto concluído que ajudasse a aumentar a eficiência energética das casas de Amsterdã.
Fizemos um projeto em que era previsto o consumo de energia elétrica (antes participei de um concurso sobre esse tema onde recebi uma solução quase sota, sobre a qual você pode ler ) e geração por painel solar. Com base nessas previsões, o desempenho da bateria é otimizado (esta ideia foi parcialmente retirada da minha tese de mestrado). O nosso projecto estava de acordo tanto com as instruções dos organizadores (como nos parecia então) como com a política da administração de Amesterdão no domínio das fontes de energia renováveis para os próximos anos.
Durante a avaliação dos projetos, nós, assim como muitas equipes, fomos informados de que não era isso que o cliente esperava, acrescentando que teríamos que refazer o projeto se quiséssemos concorrer ao prêmio. Não refazemos nada, aceitando a derrota. Das quarenta equipas participantes, nem sequer chegámos ao top 7, embora a escolha dos organizadores, me parece, tenha sido bastante estranha. Por exemplo, deixaram chegar à final a equipe que fez um aplicativo para cálculo da velocidade do vento e da radiação solar (SI) a partir de dados de sensores de smartphones: um microfone para o vento, um sensor de luz para o SI. A característica matadora foi a classificação cachorro-quente/não-cachorro-quente em três classes: Sol, vento, água e exibição do artigo correspondente na Wikipedia ().
Deixemos por um momento o lado moral da questão: chantagear os participantes com a possibilidade de vitória é simplesmente antiético. Como uma das motivações para participar de hackathons (especialmente desenvolvedores experientes) é concretizar suas ideias, muitos participantes fortes podem simplesmente deixar o evento após ouvir tal feedback (o que aconteceu não apenas com nossa equipe, mas também com vários outros que pararam atualizando o projeto da página após ouvir o mentor). Ainda assim, digamos que concordamos com os desejos dos organizadores e refizemos o nosso projeto para atender às suas necessidades. O que poderia acontecer a seguir?
Como os organizadores têm a sua própria compreensão do “projeto ideal”, todos os desejos (e, consequentemente, mudanças) nos levarão a esse ideal. Os concorrentes vão perder tempo e será cada vez mais difícil para eles recusarem novas participações (visto que já investiram os seus esforços e parece que estão um pouco longe de vencer). Mas, na realidade, a competição pelos prémios aumentará e os participantes terão cada vez mais de refazer o projecto com base nas edições dos organizadores, na esperança de ganhar um prémio. Com isso, a galera que não levou prêmios, olhando para trás, vai entender que fez freelancer sem dinheiro: fez edições para o cliente, mas não recebeu nada em troca por isso (exceto pela experiência relevante, de curso).
Moralidade
Freqüentemente, desejos e comentários dos organizadores ajudam o projeto. Ao mesmo tempo, porém, os participantes não devem confiar nos conselhos dos mentores como um homem coxo numa bengala. Se você ouvir o feedback dos organizadores sobre o seu projeto no espírito de “tire, não pedimos isso”, sua participação no hackathon pode ser considerada concluída.
Se você está organizando um hackathon com uma visão clara do projeto, mas sem as habilidades ou capacidade de implementá-lo sozinho, então é melhor formalizar sua visão na forma de especificações técnicas para um freelancer. Caso contrário, você terá que pagar duas vezes – pelo hackathon e pelos serviços do freelancer.
Fonte: habr.com