9 erros em hackathon que os organizadores continuam repetindo

A maioria dos hackathons que decepcionam fracassa pelos mesmos poucos motivos, e quase nenhum deles acontece durante o evento. Eles são decididos semanas antes, quando o desafio é escrito, os jurados são escolhidos e ninguém é nomeado para assumir o que sair dali. Aqui estão os nove erros que aparecem de novo e de novo, com o que fazer no lugar.

Os nove erros

1. Fazer um hackathon porque alguém quer um hackathon. O evento é marcado antes de alguém perguntar para que ele serve. Chegam uma data, um local e uma hashtag; um propósito, não. Sem propósito, não dá para escrever um desafio, escolher jurados ou definir o que é um bom resultado, então cada escolha seguinte vira um chute. No lugar: escreva uma frase antes de qualquer outra coisa: "Depois deste evento, queremos ter ___, e ___ vai agir a partir disso." Se você não consegue preencher as duas lacunas, talvez precise de outro formato. A comparação em hackathon, design jam ou desafio de inovação ajuda a conferir.

2. Um tema em vez de um desafio. "Cidades inteligentes", "o futuro dos bancos", "sustentabilidade". Temas parecem generosos porque deixam espaço, mas as equipes passam as primeiras seis horas discutindo em que trabalhar e depois constroem o que já sabiam construir. No lugar: dê às equipes um problema real, com um dono real e uma restrição real. Um bom desafio diz quem é afetado, o que está dando errado e o que está fora de questão. Explicamos o ofício em como escrever uma declaração de desafio que as pessoas queiram resolver. Uma árvore de problemas montada com o dono do desafio antes do evento é o jeito mais rápido de achar o nível certo.

3. Ninguém responsável pelo que sai do evento. É esse o erro que explica por que tantos vencedores nunca saem do papel. Uma equipe vence, recebe um troféu, aperta mãos, e no domingo de manhã não há linha de orçamento, nem patrocinador, nem próxima reunião. No lugar: antes do evento, nomeie a pessoa que vai receber o trabalho vencedor e combine o que ela está disposta a fazer com ele: um piloto, uma construção de 90 dias, um teste com verba. Coloque esse compromisso no briefing, para que as equipes saibam pelo que estão competindo. O acompanhamento completo está em o que fazer depois do hackathon.

4. Critérios de avaliação anunciados na hora do pitch. Quando as equipes só conhecem os critérios na apresentação final, elas otimizam para o que imaginam que os jurados gostam, geralmente slides e acabamento. Os jurados então discordam, porque cada um usa em silêncio os próprios critérios. No lugar: publique os critérios junto com o desafio, explique em palavras simples o que cada um significa e prepare os jurados na véspera. Dê peso a eles de acordo com o propósito que você escreveu no erro 1. Nosso texto sobre critérios de avaliação que escolhem o vencedor certo entra em fichas de pontuação e calibragem; uma matriz de decisão ponderada é a estrutura mais simples para começar.

5. Mentores que aparecem só para a foto. Uma lista de nomes impressionantes não é um programa de mentoria. Pessoas seniores que passam vinte minutos, dão três opiniões que se contradizem e vão embora fazem mais mal do que bem, porque as equipes mudam de rumo para agradá-las. No lugar: recrute menos mentores, dê a cada um um papel claro (domínio, técnico, usuário, pitch), agende o tempo deles em blocos e diga que a função deles é fazer perguntas, não redesenhar a ideia. Mais em mentores em hackathon: como é um bom mentor.

6. Sem acesso às pessoas ou aos dados de que o desafio trata. Pede-se às equipes que melhorem um serviço para pacientes, cidadãos ou clientes que não estão em lugar nenhum do prédio, usando dados de exemplo que não se parecem em nada com os reais. Elas acabam resolvendo um problema imaginado. No lugar: deixe usuários reais de prontidão durante o primeiro dia (três ou quatro já bastam) e prepare com bastante antecedência um conjunto de dados realista e tratado. Se for preciso passar por revisões jurídicas ou de privacidade, comece na semana em que a data for marcada, não na semana do evento.

7. Premiar o melhor pitch em vez do melhor trabalho. A última hora é teatro. Equipes com um apresentador seguro e uma apresentação bonita vencem, enquanto uma equipe que testou a ideia com cinco usuários e mudou de rumo duas vezes perde porque os slides eram simples. No lugar: peça a cada equipe que mostre evidências: o que testou, com quem, o que mudou. Dê aos jurados tempo com o protótipo funcional de cada equipe antes dos pitches. Limite os slides. Você quer encontrar a ideia que mais vale a pena levar adiante, não o melhor performer.

8. Curto demais para construir, longo demais para manter o foco. Alguns organizadores espremem um hackathon numa tarde; outros o esticam por três dias exaustivos e sem estrutura. O primeiro produz esboços; o segundo produz gente cansada que para de pensar com clareza na segunda noite. No lugar: ajuste a duração ao que você espera ter no fim. Um conceito testado precisa de mais ou menos um dia e meio de trabalho. Um protótipo funcional com dados reais precisa de mais, e precisa de pontos de checagem para que as equipes não se percam. Monte a agenda de trás para frente, a partir da demonstração final.

9. Nenhum registro de quem fez o quê. Quando o evento termina, o único vestígio é uma foto dos vencedores. Participantes que fizeram um trabalho sério, inclusive os de equipes que não venceram, saem sem nada que possam mostrar, e a organização perde a noção de quem deveria convidar de novo ou envolver no piloto. No lugar: registre o enquadramento do problema de cada equipe, o que testou, o que construiu e quem contribuiu com o quê. Envie aos participantes e aos gestores deles. É o jeito mais barato de fazer as pessoas quererem voltar.

O que fazer e o que evitar

Faça

• Escreva o propósito e o compromisso pós-evento antes de reservar qualquer coisa.
• Faça um pré-mortem com a equipe organizadora: "Passaram-se três meses e o hackathon não deu em nada. Por quê?"
• Publique desafio, critérios e prêmios juntos.
• Reserve na agenda do dono que vai receber o resultado a semana seguinte ao evento.
• Use um checklist de implantação para a logística, para que a energia da equipe organizadora vá para o desafio, não para o coffee break.

Evite

• Deixar o patrocinador escrever o desafio sozinho; quem convive com o problema deve dar forma a ele.
• Convidar jurados que não leram o desafio.
• Prometer uma implementação que você não consegue financiar.
• Tratar o número de participantes como medida de sucesso.

Exemplo ilustrativo

Ilustrativo. Uma autoridade regional de transporte público numa cidade europeia de porte médio fez seu primeiro hackathon sobre "mobilidade melhor". Vieram oitenta pessoas, doze equipes apresentaram, e a equipe vencedora construiu um app de planejamento de rotas muito parecido com três que já existiam no mercado. Ninguém foi designado para levá-lo adiante.

Para o segundo evento, os organizadores começaram de outro jeito. Escreveram primeiro o propósito: encontrar uma forma de reduzir o número de passageiros que ficam sem condução à noite quando perdem a última conexão, algo que o diretor de operações concordou em pilotar em duas linhas. Fizeram uma sessão de árvore de problemas com motoristas e com a equipe da central de controle e depois escreveram o desafio como uma pergunta Como poderíamos, com as restrições explícitas: nenhum veículo novo, nenhum app novo. Os critérios foram publicados com o briefing. Três motoristas do turno da noite ficaram de prontidão durante o primeiro dia. O conceito vencedor, uma regra simples de segurar e avisar entre motoristas e a central de controle, entrou em piloto no mês seguinte, com o diretor de operações como dono.

O segundo evento foi menor. Foi também o primeiro que mudou alguma coisa.

Perguntas frequentes

Qual é o motivo mais comum para um hackathon fracassar? Ninguém responsável pelo resultado. Ideias sem alguém disposto a financiá-las ou pilotá-las param no momento em que o evento termina, por melhores que sejam. Resolva isso antes de resolver qualquer outra coisa.

De quantos jurados um hackathon precisa? Três a cinco costumam bastar. Mais do que isso torna a deliberação lenta e dilui a responsabilidade. O que importa mais é que pelo menos um jurado seja a pessoa que vai assumir a ideia vencedora depois.

Um hackathon deve ter um desafio ou vários? Num evento interno, um ou dois desafios bem escritos costumam ser melhores do que cinco vagos. Vários desafios fazem sentido quando cada um tem seu próprio dono e seus próprios recursos prontos para agir depois.

Para onde ir agora

Comece pelo mapa completo dos formatos em hackathons, jams e desafios: todos os tipos explicados e depois siga o passo a passo em como fazer um hackathon que produza algo real. Para a preparação, os guias de árvore de problemas, Como poderíamos e pré-mortem cobrem quase tudo o que dá errado, e a matriz de decisão ponderada dá aos seus jurados uma estrutura justa.