O termo hackathon vem tornando-se cada vez mais famoso e utilizado por negócios.
Seja para posicionamento junto a comunidade ou para trazer diferenciais ao negócio, existem várias formas de usá-los e nessa breve leitura espero poder ajudar e dar melhor visibilidade quanto ao modelo, falar de seus riscos, cases de insucesso e gerar insumo para que possa formar sua própria opinião, afinal, mais que dar receitas de bolo, nossos foco é estimular o pensamento crítico.
Vamos nessa?!

Comece do começo!
Parece óbvio e claro, mas a máxima de que “até o óbvio tem de estar claro” é sempre válida e isso pode evitar confusões e frustração, ainda mais quando falamos de negócio.
No NINNA Hub, sempre que um de nossos mantenedores nos propõe realizar um Hackathon, questionamos o motivo que o levou a essa decisão…. aprofundamos na demanda para entender se de fato seria esse o modelo que agregaria maior valor a necessidade deles, o quão crítica é a solução que necessitam e como está impactando o negócio, se está claro para eles o que é um hackathon e também entramos em questões do pós-evento, afinal é sabido que o hackathon por si só não tem a mágica de gerar soluções em um final de semana, ele nos ajuda em um curto período de tempo entender, validar e propor uma solução mínima para a(s) problemática(s) apresentada, sendo necessário uma maturação e evolução do modelo para de fato atender.
Parece besteira, mas vou dar um exemplo do motivo desse ponto ser importante: participei como facilitador de um hackathon a uma empresa, trabalhando a parte da ideação. Ao final do Hackathon existiam soluções propostas, porém eram simples e mínimas, como já justificado acima. O ponto é que o cliente que contratou esse hackathon ficou frustrado, uma vez que as soluções não foram adiante, sendo implementadas e gerando resultados ao negócio.
Como não fiz parte da organização do Hackathon, não tenho a real percepção do todo e do que foi acordado, porém os pontos citados acima são importantes para alinhar as expectativas e entender se a régua do cliente não está muito alta, se não está sendo depositada uma expectativa excessiva no modelo como solucionador dos problemas em um fim de semana, pois o Hackathon não serve para isso, o valor dele é outro e deve ser deixado claro.
Não trabalhar bem essa etapa culmina no que acontece hoje no mercado: muitas pessoas e empresas tem preconceitos quanto ao modelo, sem nunca terem executado um, pois tem contato com empresas que tiveram sua expectativa frustrada por colocar recursos, expectativa e tentar experimentar novos modelos e ao fim não receber o que esperava, fazendo assim com o que o modelo seja vulgarizado e colocado em descrédito.
Assim meus caros, temos algumas lições nessa parte:
O primeiro passo é entender se de fato o que o cliente necessita é de um Hackathon;
Não tente forçar o modelo, redondo não encaixa no quadrado e isso pode colocar você, sua empresa e o modelo em descrédito;
Alinhe as expectativas e todos os pontos: explique o modelo, o que será entregue, a necessidade de um esforço posterior e tudo mais que for necessário, para que você e seu cliente estejam alinhados;

Modelagem do evento
Chegamos ao consenso que de fato é um Hackathon que será o caminho para nós!!
Bacana, então é hora de colocar a mão na massa e aí que vem a parte complicada.
Sou favorável a ter um modelo base, bem como um framework, e disso adaptar a necessidade do cliente, afinal vivemos em uma era de singularidade e a um bom tempo “one size does not fits all”.
O que isso quer dizer: que o evento tem que ser modelado conforme a necessidade do cliente.
Sabemos que o Hackathon tem sua baseline de contextualização da problemática, workshops de ideação, validação, prototipação, pitch, etc….
Mas vamos colocar um cenário: imagine que uma empresa já tem clara a problemática, tem parte da solução já pronta e somete precisam de um pedaço para acoplar e fechar o ciclo. Além disso, irá fazer o Hackathon somente interno, ou seja, somente colaboradores participando, com foco em equipes da área de tecnologia e trazendo o parceiro que fornece a solução para dar suporte na contextualização, liberar API´s e mentorar durante o evento. Temos disponibilidade do time de negócios e de tecnologia da empresa, os colaboradores já tem acesso ao devido ambiente e conhecem o negócio.
Faz sentido eu seguir na jornada descrita acima, baseada em um modelo mais tradicional?
Ou então podemos pensar e modelar algo para essa empresa: uma jornada focada no início em contextualizar a problemática com a área de negócio para alinhamento da expectativa, alinhamento com a área de tecnologia para melhor entendimento da arquitetura e demais necessidades que tenham, alinhamento com o parceiro que provém a solução que atende parcialmente e, ao final, uma facilitação sobre ideação. Tudo isso regado a uma jornada de mentorias em 3 períodos ao dia para alinhamento e tira dúvidas com a área de negócio, tecnologia e parceiro da solução, com outra facilitação sobre pitch no último dia e mentorias pela manhã e tarde para arremate da entrega, que foi alinhada no início como sendo um código funcional que acople a solução que atende parcialmente e promova a melhor experiência possível ao cliente desse cliente.
O motivo de modelar assim?
Aderência a necessidade do cliente, participantes que já conhecem a realidade e tem conhecimento prévio sobre validação e prototipação e, principalmente, foco na solução, imersão total no que agrega valor ao final.
Assim, otimizamos o tempo, fornecemos momentos de alinhamento de expectativa / tira dúvidas e mantemos as equipes ao máximo focadas em resultado!
Poderia ser só mais um Hackathon, mas com esse olhar, queremos realizar O HACKATHON!
Nessa etapa, podemos tirar algumas lições:
Entenda o ambiente, as possibilidades e a expectativa para propor o modelo e tentar otimizar ao máximo a experiência do cliente, dos participantes e do resultado;
Pense no hackathon como uma jornada, não como um processo, pois assim pode tirar insights para acoplar ao citado acima: a melhor experiência e jornada a todos;
Tenha um framework base, porém lembre “one size does not fit all”

Gran finale, o pós-Hackathon

Hackathon finalizado, missão cumprida!! (??)
Como disse no início, mais do que entender a expectativa ao final é alinhar todos os pontos com o cliente e um deles é o pós-evento.
Mesmo que seu papel esteja cumprido ao fim do hackathon, o fator de sucesso é o que vem após ele e que vejo muitas vezes sendo falho, pois, reitero, vendem-se hackathons como a solução final, sendo que ele é um meio de validar e criar possibilidades de solução de forma rápida, sendo que o sucesso ou não está na continuidade da construção, para de fator entender e obter resultados.
No NINNA Hub, por termos contato direto com os clientes, sempre os questionamos sobre o que irão fazer com a solução: internalizar para que um time de desenvolvimento a evolua, trazer as equipes vencedoras para próximo do negócio, com foco em evoluir a solução, etc…
Esse é o fator que será diferencial e poderá trazer maior possibilidade de sucesso: deixar o negócio ciente de sua responsabilidade quanto aos resultados do Hackathon!
Parece besteira, mas lembra que no início disse que até o óbvio tem de ser dito?! Então, esse é o caso e agrega diferencial na forma de lidar, pois muitas vezes o modelo é colapsado nessa passagem de bastão, por não ter sido deixado claro ao cliente a responsabilidade dele, por não ser analisado o cenário e se existe “braço” para dar seguimento ao que foi criado e por, novamente digo, muitas vezes um hackathon ser vendido como a solução absoluto dos problemas.
Cada corporação tem um nível de maturidade e muitas vezes podem correr para o modelo como forma de inovar e diferenciar no mercado, porém sem levar em conta esses pontos.
Cabe a quem irá entregar e ser responsável, falar dos riscos e dos esforços necessários, para que o modelo seja usado da forma correta: como uma ponte entre a problemática e uma hipótese de solução de forma ágil, porém que precisa ser maturado e evoluído para que possa de fato gerar os resultados que despertaram o interesse na busca pelo modelo.

Aqui, creio que nossas lições são:
Deixe o negócio ciente sobre o nível da entrega que será feita;
Esclareça e tenha claro de como será o pós-evento, tanto para o negócio preparar-se quanto para deixar claro aos participantes e eles saberem o nível de comprometimento necessário;
De forma rápida e sucinta, essa é a forma que acreditamos ser o melhor caminho para que o Hackathon seja usado de forma estratégica, dando suporte ao negócio sair de sua rotina, experimentar ousar na resolução de algumas problemas, demonstrar-se aberto, seja pelo envolvimento de colaboradores saindo da rotina ou da exposição de suas necessidades ao público externo, além de gerar uma mudança de mentalidade quanto a, muitas vezes tradicional, forma de resolver problemas.
E aí, será o Hackathon a resposta pra tudo?!