Por que a maioria dos vencedores de hackathon nunca é lançada, e o que fazer depois do hackathon

A maioria dos vencedores de hackathon nunca é lançada porque o evento foi desenhado para terminar, não para passar o bastão. A crença por trás disso é que uma ideia forte, depois de vencer em público, vai encontrar sozinha patrocinador, orçamento e equipe. Isso raramente acontece. O que funciona é definir o dono, o orçamento e a data de decisão antes do evento e, depois, percorrer de forma deliberada um caminho de 90 dias do protótipo ao piloto.

A crença, dita de forma justa

A crença é mais ou menos esta: "Fazemos o hackathon, a melhor ideia vence e a liderança, depois de vê-la, naturalmente vai apoiá-la. Boas ideias se vendem sozinhas."

Não é uma crença tola. Hackathons geram energia real e alguns conceitos fortes. Líderes seniores comparecem às apresentações finais e muitas vezes dizem coisas encorajadoras. E há histórias conhecidas de produtos que nasceram em eventos desse tipo. Por isso os organizadores supõem, com razão, que visibilidade mais qualidade é igual a adoção.

Por que ela falha na prática

O trabalho de ninguém mudou na segunda-feira. A equipe vencedora volta para as suas funções do dia a dia. Os gestores dela não concordaram em liberá-la. O protótipo fica parado num notebook. A visibilidade criou boa vontade, mas não tempo, e sem tempo nada anda.

Aplauso não é orçamento. Um líder sênior dizer "isto está excelente, vamos levar adiante" diante de uma sala é um gesto social, não uma decisão de financiamento. O orçamento do ano seguinte foi definido meses antes, e nada nele leva o nome do vencedor.

O protótipo foi construído sobre areia. Para terminar em 48 horas, as equipes simulam coisas: dados fixos no código, segurança pulada, uma etapa manual escondida atrás de uma tela. Essa é a maneira certa de construir um protótipo, mas significa que a distância entre a demo e a produção é muito maior do que a sala imagina. Quando a TI vê o código, a resposta honesta é "teríamos de refazer isto", e o entusiasmo escorre.

Os jurados não eram os donos. Muitas bancas são escolhidas pela senioridade e pela visibilidade. Depois, as pessoas que teriam de operar a solução, cujos sistemas ela toca e cujas equipes a usariam, a veem pela primeira vez semanas mais tarde, sem nenhum compromisso com ela.

Vencer era a linha de chegada. Disseram às equipes que o objetivo era vencer. Depois que venceram, a história está completa. Ninguém lhes disse que vencer era o começo de um teste.

Nenhuma dessas é uma falha da ideia. São falhas de desenho: o evento foi construído para produzir uma cerimônia, e foi o que produziu.

O que funciona no lugar

Antes do evento: construa a pista de pouso

As decisões que mais importam acontecem semanas antes de alguém escrever uma linha de código.

1. Nomeie o dono e a zona de pouso. Uma pessoa que vai levar o vencedor adiante, e a linha de orçamento ou o programa que vai absorvê-lo. Como organizar um hackathon que produz algo real chama isso de acordo de uma página.
2. Combine a liberação de tempo com antecedência. Antes do evento, os gestores diretos dos prováveis participantes concordam que as equipes vencedoras terão um tempo definido, por exemplo um dia por semana durante seis semanas.
3. Coloque os donos na banca. Entre os jurados estão a pessoa que vai operar a solução e a pessoa cujos sistemas ela toca. Use critérios que premiem a possibilidade de adoção, não só a ambição; veja critérios de avaliação que escolhem o vencedor certo.
4. Faça um pré-mortem. Pergunte à equipe organizadora: "Daqui a seis meses, nada deste hackathon foi lançado. Por quê?" Um Pré-mortem (premortem) costuma trazer à tona os problemas de acesso, orçamento e liberação enquanto ainda há tempo para resolvê-los.

Os 90 dias seguintes

Trate o período depois do evento como um projeto em si.

• Semanas 1–2: passagem. O dono se reúne com cada equipe selecionada. Combinem os papéis com uma Matriz RACI (matriz de responsabilidades), confirmem por escrito a liberação de tempo e listem o que foi simulado no protótipo.
• Semanas 2–4: nomeie as crenças arriscadas. Use um Mapa de premissas (assumption mapping) para organizar o que o protótipo supõe sobre usuários, sistemas e custo. Escolha as duas mais perigosas.
• Semanas 4–8: teste-as. Escreva cada uma como um Teste de hipótese com um critério de aprovação definido de antemão e rode-o com usuários reais ou dados reais, em pequena escala.
• Semanas 8–12: decida. Vá para o piloto com um Checklist de implantação (checklist de go-live), adapte e teste de novo, ou pare. Os três são bons desfechos, desde que sejam deliberados.

Durante todo o tempo, mantenha participantes e patrocinadores informados com um Plano de comunicação com stakeholders simples. O silêncio depois de um hackathon é lido, com razão, como abandono, e influencia se as pessoas vão se inscrever da próxima vez.

Torne respeitável o ato de parar

Alguns vencedores não devem ser lançados. Um teste na sexta semana pode mostrar que os usuários não querem aquilo ou que o custo é alto demais. É um bom resultado, obtido a baixo custo. Diga isso publicamente, reconheça a equipe pelo que aprendeu e registre. Quando parar é tratado como fracasso, os donos evitam a decisão e os projetos ficam meio vivos, o que é pior do que qualquer um dos desfechos. Como encerrar bem um projeto trata disso.

Exemplo ilustrativo

Ilustrativo. Um grupo de hospitais universitários na Holanda fez um hackathon interno para reduzir as faltas em consultas ambulatoriais. A equipe vencedora, duas enfermeiras, uma agendadora e um desenvolvedor, construiu um fluxo de lembretes que permitia ao paciente remarcar com uma única resposta. O diretor de operações elogiou a ideia no palco. Três meses depois, nada tinha acontecido: o desenvolvedor tinha ido para outro projeto e ninguém era dono do sistema de mensagens aos pacientes.

No ano seguinte, o grupo mudou o desenho, não o evento. A chefe dos serviços ambulatoriais foi nomeada dona antes de as inscrições abrirem. Os gestores diretos concordaram com um dia por semana durante oito semanas para os vencedores. O gestor do sistema de mensagens fez parte da banca. Depois do evento, a equipe vencedora fez uma Retrospectiva (retro de equipe) sobre o protótipo, mapeou suas premissas e testou a mais arriscada, se pacientes mais velhos responderiam a uma mensagem de texto, em um ambulatório. Responderam, na maioria. Na décima segunda semana, o piloto se estendeu a três ambulatórios.

Erros comuns

• Anunciar um vencedor sem anunciar um próximo passo. Diga sempre o que acontece e em que data.
• Tratar o prêmio como a recompensa. Para a maioria das equipes, a verdadeira recompensa é ver o próprio trabalho em uso. Dinheiro de prêmio sem um caminho diz a elas que o trabalho não importou.
• Deixar o protótipo virar o produto. Reconstrua direito quando o conceito estiver comprovado; não estique código de hackathon até a produção.
• Esquecer as equipes que não venceram. Os achados delas muitas vezes contêm a melhor evidência do evento. Registre-os.
• Fazer o próximo hackathon antes de os vencedores do último terem uma decisão. As pessoas percebem. Leia 9 erros de hackathon que os organizadores continuam repetindo para ver mais.

Perguntas frequentes

O que deve acontecer depois de um hackathon? Em até duas semanas, o dono nomeado deve se reunir com as equipes selecionadas, combinar papéis e tempo e listar o que o protótipo simulou. Depois, testar as premissas mais arriscadas ao longo dos dois meses seguintes e tomar uma decisão clara de pilotar, adaptar ou parar.

Por que os projetos de hackathon fracassam depois do evento? Normalmente porque ninguém é dono deles, não há orçamento associado e a equipe não tem tempo liberado do trabalho normal. A ideia raramente é o problema; o problema é a passagem que não aconteceu.

Como manter o embalo depois de um hackathon? Marque a primeira reunião de acompanhamento antes de o evento terminar, informe o progresso aos participantes a cada poucas semanas e publique a decisão sobre cada vencedor, inclusive as de parar. O embalo vem de decisões visíveis, não de entusiasmo.

Para onde ir agora

Os guias que levam um protótipo para além do evento são o Pré-mortem (premortem), o Mapa de premissas (assumption mapping), o Teste de hipótese e o Checklist de implantação (checklist de go-live). Para o mapa completo dos formatos, veja todos os tipos de hackathon e jam explicados.