Na
parte anterior da trilogia, examinei várias razões para participar de hackathons. A motivação para aprender muito e ganhar prêmios valiosos atrai muitos, mas muitas vezes por causa dos erros dos organizadores ou empresas patrocinadoras, o evento termina sem sucesso e os participantes saem insatisfeitos. Para que esses casos 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 começo, falo sobre o evento, explico o que deu errado e o que levou (ou pode levar a longo prazo). Depois, faço uma avaliação do que está acontecendo e como agiria no lugar dos organizadores. Como agi como participante de todos os eventos, só posso assumir a verdadeira motivação dos organizadores. Como resultado disso, minha avaliação pode ser unilateral. Não excluo que alguns dos pontos que considero errôneos foram realmente concebidos.
Em algum momento, pode parecer ao leitor que o autor decidiu balançar os punhos após a luta. Mas posso garantir que não é assim. Em alguns dos hackathons listados, consegui receber um prêmio, o que, no entanto, não me impede de dizer que o evento foi mal organizado.
Devido ao respeito pelos organizadores e participantes, a postagem não indicará empresas específicas. Um leitor atento, no entanto, pode adivinhar (ou google) de quem está falando.
Hackathon No. 1. Estrutura rigorosa
Seis meses atrás, uma grande empresa de telecomunicações organizou um hackathon de análise de dados. Para o fundo do prêmio lutou 20 equipes. No evento, foi fornecido um conjunto de dados para análise, que continha informações sobre ligações para o serviço de suporte da empresa, atividade nas redes sociais e informações codificadas sobre os usuários (sexo, idade, etc.). A parte mais interessante do conjunto de dados - mensagens do usuário e resposta do operador (dados de texto) - era bastante “barulhenta”, precisava ser limpa para mais trabalhos.
Os organizadores definiram a 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 oferecer idéias não relacionadas ao conjunto de dados. Infelizmente, os dados fornecidos eram bastante “ruins”: era difícil obter produtos interessantes e, ao se comunicar com os mentores, ficou claro que muitas das idéias propostas já estavam sendo implementadas (ou seriam implementadas em um futuro próximo) na empresa.
Como resultado, a grande maioria das equipes (15 em 20) fez bots de bate-papo. Durante as apresentações, a decisão de uma equipe não foi muito diferente da anterior. Insustentável, um dos membros do júri perguntou à próxima equipe no palco: “O que, pessoal, vocês também têm um bot de bate-papo?” Como resultado, dos três prêmios, o primeiro e o segundo lugares foram para equipes que não fizeram bots de bate-papo.
Para comparação, veja o hackathon, organizado por uma empresa de consultoria internacional, para a empresa Zvezdochka há dois anos. Como os detalhes da empresa Zvezdochka não eram familiares a muitos participantes do hackathon, no início do evento, os organizadores conversaram sobre as métricas usadas na empresa. Depois disso, seis conjuntos de dados de várias orientações foram fornecidos: texto, tabelas, posições geográficas - havia espaço para manobras para todos os participantes. Os organizadores não proibiram o uso de conjuntos de dados adicionais e até apoiaram tais compromissos. Na final da competição, dez equipes com decisões diferentes disputaram o prêmio principal, e todas as equipes utilizaram os dados fornecidos pela empresa (apesar da ausência de proibições), o que indicava 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 suas opiniões e profissionalismo. Se você é membro de uma hackathon, quaisquer restrições ou proibições devem alertá-lo. Geralmente, isso é evidência de organização precária (um exemplo da vida real é um desejo constante de colocar uma cerca em algum lugar). Se você ainda encontrar restrições, esteja preparado para o fato de precisar criar um projeto no pool com grande concorrência. Nesse caso, você deve correr riscos: faça algo fundamentalmente novo ou ofereça um “recurso matador” incomum para se destacar do fluxo de projetos monótonos.
Hackathon número 2. Tarefas impossíveis
O hackathon em Amadore prometeu ser interessante. A empresa patrocinadora, grande fabricante de telefones, iniciou os preparativos quatro meses antes da data do evento. Um evento social foi realizado nas redes sociais, os participantes em potencial tiveram que passar por um teste técnico e escrever sobre seus projetos anteriores para serem selecionados para este evento. A premiação era agradavelmente grande. Poucos dias antes do hackathon, os mentores realizaram uma sessão técnica para que os participantes tivessem tempo de penetrar nas especificidades do setor.
No evento, os organizadores forneceram um conjunto de dados de equipamentos de 8 Gb com uma classificação binária de avarias. Eles falaram sobre os critérios para avaliar projetos - a qualidade da classificação, a criatividade na criação de recursos, a capacidade de trabalhar em equipe etc. Isso é apenas azar - para 8 GB de "recursos", havia apenas 20 exemplos no trem e 5 no teste. A unha final na tampa do caixão do hackathon marcou um rosto nos dados: os registros de equipamentos recebidos na quarta-feira continham um erro na operação do equipamento, e os criados na quinta-feira não continham (a propósito, apenas duas equipes sabiam disso e ambas eram da Rússia - a terra dos datameners experientes ) Embora o fato de conhecer os rótulos reais do teste não tenha ajudado a personalizar a resposta, a tarefa era insolúvel. Os organizadores não obtiveram o resultado desejado, os participantes passaram muito tempo resolvendo uma tarefa mal composta. O hackathon foi um fracasso.
Moral
Realize exames técnicos de tarefas e verifique suas tarefas quanto à adequação. É melhor pagar a mais por um exame preliminar (nesse caso, qualquer datacenter indicaria imediatamente que é impossível resolver esse problema) do que se arrepender mais tarde.
Nesse caso, além do tempo e dinheiro gastos, a empresa perdeu um empréstimo fiduciário de possíveis candidatos e é possível escrever sobre os resultados. A propósito, não apenas os participantes, mas também a empresa deve escrever sobre resultados bem-sucedidos, realizando ao máximo o hackathon do ponto de vista do PR. Infelizmente, nem todas as empresas fazem isso, limitando-se apenas a um pós-anúncio e algumas fotos do evento no Twitter.
Hackathon número 3. Pegue ou deixe
Mais recentemente, nossa equipe participou de um hackathon em Amsterdã. Como sou engenheiro elétrico em treinamento (no campo de fontes de energia renováveis), o assunto era apenas para nós - energia. O hackathon foi realizado em formato online: recebemos uma descrição da tarefa e um mês para concluir. Os organizadores queriam ver um projeto concluído que ajudaria a aumentar a eficiência energética das casas de Amsterdã.
Fizemos um projeto no qual o consumo de eletricidade é previsto (antes participei de uma competição sobre esse tópico, onde obtive uma solução quase-sota, que pode ser lida
aqui ) e geração por um painel solar. Com base nessas previsões, o desempenho da bateria é otimizado (essa ideia foi parcialmente retirada do diploma de mestrado). Nosso projeto estava de acordo com a tarefa dos organizadores (como nos pareceu na época) e com a política do governo de Amsterdã no campo das energias renováveis por muitos anos.
Durante a avaliação dos projetos, nós, como muitas equipes, fomos informados de que não era o que o cliente esperava, acrescentando que tivemos que refazer o projeto se quiséssemos competir por um prêmio. Não refazemos nada, resignamos à derrota. Das quarenta equipes participantes, nem chegamos ao top 7, embora a escolha dos organizadores, a meu ver, tenha sido bastante estranha. Por exemplo, eles perderam a equipe final, que fez um pedido para calcular a velocidade do vento e a radiação solar (SI) de acordo com os sensores do smartphone: microfone para vento, sensor de luz para SI. O assassino de recursos tinha uma classificação de cachorro-quente / não-cachorro-quente em três classes: o sol, o vento, a água e a exibição do artigo correspondente da Wikipedia (
demo ).
Vamos deixar 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 hackers (especialmente desenvolvedores experientes) é a realização de suas idéias, muitos participantes fortes podem simplesmente sair do evento depois de ouvir esse feedback (o que aconteceu não apenas com nossa equipe, mas também com vários outros que pararam de atualizar a página). do seu projeto depois de ouvir o mentor). No entanto, digamos que concordamos com os organizadores e redesenhamos nosso projeto de acordo com os requisitos deles. O que poderia acontecer a seguir?
Como os organizadores têm seu próprio entendimento do “projeto ideal”, todos os desejos (e, consequentemente, mudanças) nos levarão a esse ideal. Os participantes gastam seu tempo e será cada vez mais difícil recusar-se a participar ainda mais (já que eles já investiram sua força e parece que não conseguirão vencer antes). Mas, na realidade, a competição por prêmios aumentará, e os participantes terão que refazer cada vez mais o projeto de correções dos organizadores, na esperança de receber um prêmio. Como resultado, os caras que não receberam prêmios, olhando para trás, perceberão que participaram de freelancers sem dinheiro: fizeram alterações no cliente, mas ao mesmo tempo não receberam nada em troca (exceto a experiência relevante, é claro).
Moral
Muitas vezes, os desejos e feedback dos organizadores vêm em auxílio do projeto. Nesse caso, no entanto, os participantes não devem confiar nos conselhos dos mentores, como os mancos da bengala. Se você ouvir dos organizadores o feedback sobre o seu projeto com o espírito de "levar embora, nós não o pedimos" - sua participação no hackathon sobre isso pode ser considerada concluída.
Se você estiver organizando um hackathon com uma visão clara do projeto, mas sem as habilidades ou a capacidade de implementá-lo, é melhor projetar sua visão na forma de uma tarefa técnica para um freelancer. Caso contrário, você terá que pagar duas vezes - pelo hackathon e pelos serviços de um freelancer.