Como organizar um hackathon que produz algo real

Para organizar um hackathon que produz algo real, decida o que acontece com os vencedores antes de decidir qualquer outra coisa: quem é o dono, de qual orçamento eles vão depender e quando a decisão será tomada. Depois, prepare o problema, os dados e as pessoas para que as equipes passem o evento construindo, e não esperando. O evento em si é a parte fácil; a maior parte do trabalho está nas seis semanas anteriores e nas doze semanas seguintes.

Os passos abaixo partem de um hackathon interno ou de ecossistema, de um a três dias. Se você ainda está escolhendo entre formatos, comece por todos os tipos de hackathon e jam explicados.

Antes de começar: o acordo de uma página

Escreva uma única página e obtenha a aprovação do patrocinador sênior. Ela tem cinco linhas:

• O problema em uma frase, e por que ele importa agora.
• O dono que vai levar adiante o protótipo vencedor, com nome.
• A zona de pouso: a linha de orçamento, a equipe ou o programa que vai absorver o vencedor.
• A data de decisão: quando, depois do evento, o dono diz seguir, adaptar ou parar.
• O que "real" significa: um piloto com 50 usuários, um teste de integração, um pedido de compra. Seja específico.

Se você não consegue preencher essa página, não está pronto para organizar um hackathon. Talvez esteja pronto para um ideathon ou para uma fase de descoberta.

Passo a passo

1. Enquadre o problema com seis semanas de antecedência

Entreviste quem convive com o problema: equipes da linha de frente, clientes, os donos dos sistemas. De cinco a oito Entrevistas com stakeholders bastam para evitar que você apresente o problema errado. Organize causas e efeitos com uma Árvore de problemas e depois escreva de duas a quatro Perguntas Como poderíamos (How might we) como trilhas do desafio. Cada trilha deve ser estreita o bastante para que uma equipe de cinco pessoas construa algo relevante em 48 horas, e ampla o bastante para que duas equipes não construam a mesma coisa. A redação do briefing em si está em como escrever um enunciado de desafio que as pessoas queiram resolver.

2. Libere os acessos com quatro semanas de antecedência

É aqui que a maioria dos hackathons corporativos fracassa em silêncio. As equipes chegam e descobrem que não conseguem acessar a API, que os dados não foram liberados ou que o ambiente de testes não existe. Com quatro semanas de antecedência, liste tudo com que uma equipe vai precisar mexer e obtenha aprovação por escrito da TI, da proteção de dados e da segurança. Prepare um sandbox com dados de teste realistas. Se os dados reais não puderem sair do sistema, crie um conjunto sintético com a mesma estrutura.

3. Recrute para formar equipes mistas

Abra as inscrições com três a quatro semanas de antecedência e pergunte às pessoas qual é a competência delas, não o cargo. Uma boa equipe de quatro a seis pessoas tem pelo menos alguém que constrói, alguém que conhece o tema e alguém que vai conversar com os usuários. Deixe espaço para que pessoas se inscrevam individualmente e sejam alocadas. Evite que departamentos inteiros entrem como uma única equipe; você perde o valor de atravessar silos que justifica o evento.

4. Oriente jurados e mentores com duas semanas de antecedência

Entre os jurados devem estar o dono do seu acordo de uma página, alguém que controla orçamento e alguém que represente o usuário. Combine os critérios com eles antes do evento e publique-os para os participantes. Um conjunto sensato: força da evidência de que o problema é real, encaixe com a zona de pouso, viabilidade dentro dos sistemas existentes e qualidade do protótipo. Atribua pesos numa Matriz de decisão ponderada (matriz de priorização). Mais sobre isso em critérios de avaliação que escolhem o vencedor certo.

Mentores não são jurados. Dê a cada mentor uma trilha, uma agenda de acompanhamentos e uma orientação: fazer perguntas, destravar acessos, não assumir o trabalho. Veja mentores em um hackathon.

5. Conduza o evento em torno de três checkpoints

Um plano de 48 horas que funciona:

• Abertura (primeiras duas horas). O patrocinador explica pessoalmente o problema e a zona de pouso. Depois, os donos do problema, e não os organizadores, respondem às perguntas. As equipes se formam e escolhem uma trilha.
• Checkpoint um (por volta da sexta hora). Cada equipe declara seu usuário, sua premissa e o que vai construir. Incentive as equipes a listar as crenças mais arriscadas usando um Mapa de premissas (assumption mapping). Elimine duplicações cedo.
• Checkpoint dois (por volta da hora 24). Cada equipe mostra algo funcionando, mesmo que feio, e relata um teste com um usuário real ou um sistema real. Um Protótipo em papel vale para interfaces que ainda não foram construídas.
• Checkpoint três (última manhã). Congele as funcionalidades. O resto é testar, corrigir e preparar uma demonstração curta.

Limite as apresentações a cinco minutos mais perguntas e exija uma demonstração ao vivo. Slides sobre o que o produto faria não são um protótipo.

6. Avalie pela adoção, não pelos aplausos

Conduza a avaliação como um Painel de desafio (challenge panel): cada jurado pontua em privado, pelos critérios publicados, antes de qualquer discussão; depois, o painel compara as notas e discute apenas as diferenças. Anuncie não só o vencedor, mas o próximo passo: "O dono vai se reunir com esta equipe na terça-feira para planejar um piloto de quatro semanas." Se você anunciar um prêmio e nenhum próximo passo, as pessoas vão entender exatamente o que foi o evento.

7. Faça a passagem em até dez dias úteis

Em até dez dias úteis depois do evento, o dono se reúne com cada equipe selecionada, combina quem faz o quê usando uma Matriz RACI (matriz de responsabilidades) e reserva, por escrito e com os gestores diretos, o tempo de que a equipe precisa. Conduza os primeiros passos do piloto com um Checklist de implantação (checklist de go-live). Na data de decisão, o dono diz seguir, adaptar ou parar, e diz isso publicamente. Por que a maioria dos vencedores de hackathon nunca é lançada aprofunda essa fase.

Exemplo ilustrativo

Ilustrativo. Uma seguradora regional do sul da Europa queria encurtar o tempo entre o cliente comunicar um sinistro leve de automóvel e receber o pagamento. Seu líder de inovação escreveu primeiro o acordo de uma página: o diretor de sinistros era o dono do resultado, o programa digital de sinistros o absorveria e uma decisão seria tomada seis semanas depois do evento.

Com quatro semanas de antecedência, a TI montou um sandbox com registros de sinistros anonimizados e uma cópia do serviço de envio de documentos. As equipes de cinco pessoas misturavam reguladores de sinistros, desenvolvedores e um atendente da central. No checkpoint dois, uma equipe tinha descoberto, ao ligar para três clientes com sinistros recentes, que o atraso não estava na análise, e sim nos clientes enviando as fotos erradas. Ela construiu um fluxo guiado de fotos e o testou com atendentes da central fazendo o papel de clientes. Venceu pela evidência e pelo encaixe, não pelo acabamento. O diretor de sinistros se reuniu com a equipe na terça-feira seguinte, e um piloto de quatro semanas rodou em uma agência.

O que fazer e o que evitar

Faça

• Obtenha a assinatura do acordo de uma página antes de anunciar a data.
• Faça o dono do problema, e não o organizador, apresentar o briefing às equipes.
• Publique os critérios de avaliação já nas inscrições.
• Alimente bem as pessoas e deixe-as dormir. Uma equipe que dormiu constrói melhor no segundo dia.
• Registre o que cada equipe aprendeu, inclusive as que não venceram; os achados delas muitas vezes evitam que o vencedor repita erros.

Evite

• Começar pelo local, pela identidade visual ou pelo prêmio.
• Deixar as equipes descobrirem na manhã do evento que não conseguem acessar os sistemas.
• Aceitar uma apresentação de slides no lugar de uma demonstração.
• Escolher jurados que nunca mais vão ver o projeto.
• Comemorar na sexta e sumir no domingo. 9 erros de hackathon que os organizadores continuam repetindo lista o resto.

Perguntas frequentes

Quanto tempo deve durar um hackathon corporativo? Dois dias é o mínimo prático para algo que funcione; 24 horas só servem para problemas muito estreitos. Mais de três dias e você está fazendo um sprint, o que tudo bem, mas planeje-o como tal.

De quantas pessoas você precisa para organizar um hackathon? Para 50 a 80 participantes, conte com um organizador principal, um líder técnico para acessos e ambientes, um mentor por trilha, uma banca de três a cinco jurados e alguém dedicado à logística. O líder técnico é o papel que mais costuma faltar.

Os participantes de um hackathon devem ser remunerados ou ganhar folga? Hackathons internos devem acontecer no horário de trabalho ou ser compensados, e os gestores devem concordar com antecedência. Se as pessoas tiverem de abrir mão de um fim de semana sem remuneração, você só vai ouvir quem pode fazer isso, e vai perdê-las na fase do piloto.

Para onde ir agora

Os guias que fazem a maior parte do trabalho aqui são a Árvore de problemas, o Mapa de premissas (assumption mapping), a Matriz de decisão ponderada (matriz de priorização) e o Checklist de implantação (checklist de go-live). Cada um leva menos de uma hora para aplicar com uma equipe.