Como ganhar um Hackathon: Lições de quem saiu do código e focou na dor (e na solução) e ganhou!

O Google define Hackathon como um evento intenso e colaborativo de 24 a 48 horas para criar protótipos inovadores. Mas, após vencer uma competição recentemente, percebi que a teoria é bem diferente da prática.

O código é importante? Sim. Mas não é ele quem ganha o jogo sozinho.

Compartilho aqui um roteiro do que funcionou para minha equipe, focado não apenas em tecnologia, mas em pessoas, processos e estratégia.

1. A Armadilha do "Técnico" e a Gestão de Pessoas
O primeiro desafio é a diversidade. Você vai lidar com uma equipe multidisciplinar e, inevitavelmente, com egos. Pessoas tolerantes, outras nem tanto; algumas apaixonadas pela própria ideia (mesmo que seja ruim) e outras enviesadas pela sua área de formação.

O erro grave: Começar pensando na solução técnica. Nós, desenvolvedores, temos o instinto de abrir a IDE e pensar em stacks. Mas, no início, pensar na solução é prematuro. Você precisa, antes de tudo, entender a DOR.

2. O Funil de Ideias: Brainstorming e "Betting"
Todo mundo tem um mundo de ideias na cabeça. O segredo é ter um processo para filtrá-las sem matar a criatividade:

Brainstorming sem julgamento: Escute tudo e ANOTE em uma cartolina, onde todos possam ver.

O Betting (Aposta): Vote nas ideias. De 10 sugestões, filtre para 3.

Seleção Natural: Conforme o grupo discute as 3 finalistas, você notará que o foco naturalmente migra para a mais forte. É aqui que começa a pivotação. Aquela ideia inicial ganha escopo e corpo.

3. Validação real
Digamos que sua ideia envolva combater a "Corrupção em licitações públicas". É um problema real, o Brasil sangra com isso. Mas isso é uma hipótese.

Para validar, você precisa encontrar quem sente essa dor.

A entrevista: Não seja um escritor, seja um ouvinte. Saiba guiar a conversa.

O objetivo: Confirmar se a dor é latente. Se o "cliente" não reclama com emoção, talvez o problema não seja tão grande assim, faça as perguntas certas.

4. A Solução: O Simples Vence
Só agora falamos de tecnologia. Problemas complexos não exigem, necessariamente, soluções complexas.

No caso da corrupção, eu (como especialista em IA) poderia sugerir: "Vamos criar uma IA que analisa contratos fraudulentos e alerta o Ministério Público". Para mim, é simples. Mas a pergunta de ouro é: A equipe tem capacidade técnica e analítica para entregar isso em 48 horas?

O MVP (Produto Viável Mínimo) precisa ser o caminho mais fácil e viável de implementação. Se for difícil demais para o time, você vai falhar na entrega.

5. Liderança: O Maestro, não o Chefe
Vi equipes falharem por falta de direção ou por excesso de autoritarismo. Um bom líder de Hackathon não manda; ele conduz. Ele é o mediador que diz:

"Agora é a vez dela falar."

"Agora não é hora de julgar, é hora de escutar."

"Validamos a hipótese? Então agora podemos codar."

O líder garante que o roteiro seja seguido, evitando que o time se perca em discussões circulares.

6. O Pitch: Venda o Sonho, Não o Código
Eu sou Engenheiro de Software, trabalho home office e minha linguagem é TECH. Se depender de mim para vender uma caneta, eu passo fome.

É aqui que entra a figura do "Vendedor Nato". Toda equipe vencedora tem (ou precisa encontrar) aquela pessoa que sabe vender areia no deserto.

Essa pessoa precisa pegar toda a complexidade técnica que criamos e traduzir para uma linguagem humana, de negócios e de impacto. Ela deve mostrar o projeto rodando, claro, mas o foco é brilhar os olhos dos jurados com a solução da dor, e não com a arquitetura do banco de dados.

Conclusão
O Hackathon é um mix de habilidades: ou você aprende e desenvolve soft skills, ou você sofre. Seguir um roteiro de validação, respeitar a diversidade do time e focar na simplicidade foram os degraus que nos levaram à vitória.