Hackathon interno ou aberto ao público?

Escolha um hackathon interno quando o que você mais precisa é de adoção: soluções que se encaixem nos seus sistemas e pessoas que vão levá-las adiante depois. Escolha um hackathon aberto ao público quando o que você mais precisa é de pensamento de fora, talentos novos ou visibilidade, e você aceita que a maioria das ideias vai precisar de um longo caminho até entrar na sua organização. Se precisa das duas coisas, faça um formato misto: um evento aberto com pessoas da casa distribuídas em todas as equipes, ou um evento interno com um pequeno número de convidados de fora.

A escolha raramente tem a ver com o evento em si. Tem a ver com o que acontece depois, com quem é dono dos resultados e com quanto risco você pode correr com dados e reputação. Para o conjunto mais amplo de formatos, veja Hackathons, jams e desafios: todos os tipos explicados.

A comparação num relance

Quando um hackathon interno faz sentido

• Você quer que o resultado seja usado. As equipes internas conhecem os sistemas, as aprovações e as pessoas. As ideias delas são menores, mas mais delas sobrevivem.
• O seu objetivo real é cultura ou capacidade. Um hackathon interno muitas vezes é a primeira vez que pessoas de departamentos diferentes constroem algo juntas. Só isso já pode justificá-lo.
• Os dados são sensíveis. Se as equipes precisam de dados reais de clientes, pacientes ou finanças, é muito mais fácil mantê-los dentro dos controles que você já tem.
• Você está no começo do trabalho de inovação. Fazer primeiro um evento interno ensina a preparar o briefing, a mentoria e o acompanhamento antes de ter uma plateia assistindo.

O ponto fraco é a mesmice. As equipes internas compartilham os pontos cegos da organização. Compense misturando departamentos e níveis e convidando alguns usuários ou pessoas da linha de frente para testar as ideias durante o evento.

Quando um hackathon aberto faz sentido

• Você está preso nas próprias premissas. Quem é de fora faz as perguntas que a sua equipe parou de fazer.
• Você quer encontrar pessoas. Muitas organizações usam hackathons abertos em parte para conhecer desenvolvedores, designers e startups que poderiam contratar ou com quem poderiam trabalhar.
• O problema pertence a uma comunidade. Problemas de cidade, cívicos e setoriais costumam ganhar com a participação de quem convive com eles.
• Você tem algo para abrir. Dados abertos, uma API, um sandbox ou um dono de desafio real fazem um evento aberto valer o fim de semana das pessoas.

O ponto fraco é o vazio depois. Equipes de fora não conseguem simplesmente entrar na sua organização na segunda-feira. Sem um caminho claro (um piloto remunerado, um programa de startups, um processo de compras), os vencedores voltam para casa e as ideias se apagam. Veja Por que a maioria dos vencedores de hackathon nunca lança nada.

Perguntas para decidir

Antes de escolher, responda a estas perguntas com o seu patrocinador:

1. O que precisa existir três meses depois do evento? Uma solução em piloto aponta para o interno; uma carteira de parceiros ou contratações aponta para o aberto.
2. Quem vai ser dono das ideias vencedoras? Se nenhum dono interno estiver pronto para receber o trabalho de uma equipe de fora, um evento aberto vai decepcionar.
3. Que dados você pode compartilhar, e com quem? Se a resposta for "só internamente", monte a versão aberta com dados sintéticos ou abertos, ou escolha o interno.
4. O que você pode prometer aos vencedores? Participantes de fora esperam mais do que um troféu. Seja claro sobre o que você consegue entregar.
5. Quanta exposição você aguenta? Um evento aberto é uma declaração pública. Faça um pré-mortem curto: imagine que deu errado na imprensa e liste por quê.

Se as respostas forem mistas, pontue as duas opções segundo os seus critérios com uma matriz de decisão ponderada, em vez de decidir por preferência.

Combinando os dois

Os eventos mais fortes muitas vezes misturam os formatos:

• Evento aberto, equipes semeadas. Torne o hackathon público, mas coloque uma ou duas pessoas da casa em cada equipe. Elas trazem as restrições e a rede interna; quem é de fora traz o olhar novo. Depois, as pessoas da casa levam a ideia vencedora para dentro.
• Evento interno, convidados de fora. Mantenha-o interno, mas convide um pequeno número de usuários, estudantes ou fundadores de startups como membros das equipes ou como testadores.
• Duas etapas. Faça uma etapa interna para escolher e afiar os desafios e depois uma etapa aberta para resolvê-los. Ou faça uma etapa aberta de ideias e depois traga as melhores para uma semana interna de construção.
• Primeiro interno, depois aberto. Use hackathons internos durante um ano para ganhar músculo em briefing, mentoria e acompanhamento. Depois abra, com um histórico para mostrar.

Seja qual for a escolha, prepare a passagem de bastão cedo. Um checklist de implantação para as ideias vencedoras, acordado antes do evento, importa mais do que o formato.

Exemplo ilustrativo

Ilustrativo. Um banco regional no sul da Europa queria simplificar os pedidos de crédito para pequenas empresas. A equipe de inovação propôs um hackathon aberto; as equipes de risco e compliance se opuseram a compartilhar qualquer dado de pedidos.

Chegaram a um desenho em duas etapas. Primeiro, um evento interno de dois dias reuniu analistas de crédito, pessoal das agências e TI para mapear a jornada do pedido e definir três desafios específicos. Depois, um hackathon aberto de fim de semana convidou estudantes e desenvolvedores de fintechs locais, usando um conjunto de dados sintético montado com os mesmos campos dos pedidos reais. Cada equipe incluía um funcionário do banco como membro, não como mentor.

A equipe vencedora, formada por dois estudantes, um desenvolvedor de uma startup local e uma analista de crédito, propôs uma pré-checagem guiada que dizia aos solicitantes quais documentos ainda faltavam antes de enviar o pedido. Como a analista de crédito estava na equipe, a ideia teve um patrocinador interno desde o início, e o banco ofereceu à startup um piloto remunerado pelo processo de fornecedores que já existia.

O que fazer e o que evitar

Faça

• Decida com base no que precisa acontecer depois do evento, não em como o evento vai parecer.
• Publique termos claros para eventos abertos: PI, dados, elegibilidade, prêmios e conduta.
• Coloque pessoas da casa dentro das equipes nos eventos abertos, não só como mentores.
• Prepare um caminho real para os vencedores: piloto, parceria, contratação ou incubação.
• Comece pelo interno se você nunca fez um hackathon.

Evite

• Fazer um hackathon aberto para parecer inovador. Os participantes percebem quando não há um dono por trás do desafio.
• Compartilhar dados sensíveis com o público, mesmo que "só no fim de semana".
• Prometer implementação a equipes de fora, a menos que você tenha orçamento e processo para cumprir.
• Manter os eventos internos fechados a qualquer olhar de fora. Alguns usuários ou testadores vão afiar cada ideia.
• Avaliar equipes internas e externas pela mesma régua de viabilidade. Quem é de fora não tem o seu contexto; premie o insight.

Perguntas frequentes

Hackathons abertos produzem ideias melhores? Eles tendem a produzir ideias mais variadas, porque os participantes partem de lugares diferentes. Hackathons internos tendem a produzir ideias mais fáceis de implementar. Nenhum é melhor em geral; depende de você precisar de novidade ou de adoção.

De quem são as ideias de um hackathon aberto? De quem o seu regulamento publicado disser, e é por isso que você precisa escrevê-lo antes de abrir as inscrições. Muitos organizadores deixam a PI com as equipes e pedem o direito de negociar primeiro. Busque orientação jurídica para o seu caso.

Funcionários podem participar de um hackathon aberto organizado pelo próprio empregador? Sim, se o regulamento permitir, e muitas vezes é uma boa ideia. Deixe claro se eles podem ganhar prêmios e de quem é o que eles constroem durante o evento.

Métodos para a preparação

Use um mapa de stakeholders para ver quem precisa apoiar o evento e quem vai receber os resultados, e um mapa de premissas para testar o que você está supondo sobre os participantes e os resultados. Para coorganizar com outras organizações, veja O hackathon de ecossistema; para conduzir o evento em si, veja Como fazer um hackathon que produza algo real.