Mentores em hackathon: como é um bom mentor

Um bom mentor de hackathon ajuda a equipe a pensar com mais clareza sobre a própria ideia, com perguntas, feedback honesto e um desbloqueio aqui e ali, sem tomar a ideia para si. Boa mentoria é desenhada: um grupo pequeno com papéis claros, uma agenda de conversas ligada aos momentos em que as equipes travam e uma preparação curta sobre o que fazer e o que não fazer. Veja como montar isso.

Para que servem os mentores

Os mentores existem para encurtar o tempo que as equipes passam travadas. Num evento de 36 ou 48 horas, uma equipe pode perder seis horas com uma premissa errada, uma conexão de dados quebrada ou um problema enquadrado de forma ampla demais. Um bom mentor percebe isso cedo e faz a pergunta que coloca a equipe em movimento de novo.

Para o que os mentores não servem: avaliar, desenhar a solução ou trazer uma ideia de estimação. Os melhores mentores deixam a equipe sentindo que a ideia é mais dela, não menos. Isso importa no evento e depois dele: se vier um piloto, a equipe precisa acreditar no que construiu, e ninguém defende uma ideia que um visitante sênior entregou pronta.

Há quatro papéis úteis de mentor. A maioria dos eventos precisa pelo menos dos dois primeiros:

• Mentores de domínio conhecem o problema por dentro: o serviço, a regulação, o histórico do que já foi tentado.
• Mentores usuários são as pessoas afetadas, ou falam por elas. Em muitos eventos, são as pessoas mais valiosas da sala.
• Mentores técnicos ajudam com dados, ferramentas, integração e o que dá para construir de forma realista.
• Mentores de método e de pitch ajudam as equipes a testar premissas, estruturar a história e ir direto ao ponto.

Sete passos para um programa de mentoria que funcione

1. Defina do que as equipes vão precisar, e quando. Percorra a agenda e marque onde as equipes costumam ter dificuldade: enquadrar o problema nas primeiras horas, escolher uma ideia, o primeiro teste, o muro técnico de madrugada, a história final. Cada um desses é um momento de mentoria. Escolha os papéis de mentor de acordo. Se o desafio é sobre um serviço público, um mentor de domínio que conhece as regras vale mais do que dois desenvolvedores a mais. A declaração de desafio (veja como escrever uma declaração de desafio que as pessoas queiram resolver) mostra qual conhecimento é escasso.

2. Recrute menos mentores, e melhores. Uma proporção de mais ou menos um mentor para cada duas ou três equipes, por sessão, costuma bastar se o tempo deles estiver agendado. Recrute pela capacidade de escutar e pela paciência, não pela senioridade. Um executivo sênior pode ser um bom mentor, mas só se conseguir sentar com uma equipe por vinte minutos e perguntar mais do que fala. Peça a cada candidato um compromisso de tempo específico, de pelo menos dois blocos, antes de aceitá-lo. Um nome no site que aparece por dez minutos é um dos 9 erros em hackathon que os organizadores continuam repetindo.

3. Prepare os mentores antes do evento. De trinta a sessenta minutos, de preferência na véspera. Cubra o desafio e suas restrições, os critérios de avaliação (para que os mentores direcionem para o que importa; veja critérios de avaliação que escolhem o vencedor certo), a agenda e as regras da casa. A regra mais importante é simples: pergunte, não diga. Dê a eles um conjunto curto de perguntas para usar, como:

• Para quem exatamente é isso, e que momento do dia dessa pessoa vocês estão melhorando?
• Qual é a coisa mais arriscada que vocês estão supondo? Como poderiam checar isso hoje?
• O que vocês cortariam se tivessem metade do tempo?
• O que vocês aprenderam nas últimas três horas que fez vocês mudarem de ideia?

Essas perguntas levam direto ao mapa de premissas e a um rápido teste de hipótese; os mentores devem conhecer os dois bem o bastante para sugeri-los.

4. Agende o tempo; não deixe ao acaso. O esquema solto de "os mentores estão por aí, é só chamar" falha de duas formas: as equipes confiantes monopolizam os mentores e as tímidas nunca pedem. Faça rodadas fixas: por exemplo, uma conversa de 15 minutos com cada equipe depois do bloco de enquadramento do problema, outra depois do primeiro teste e uma terceira antes do pitch. Entre as rodadas, os mentores podem ser chamados sob demanda por uma fila simples. Faça os mentores circularem para que cada equipe ouça mais de uma visão, mas mantenha um mentor nomeado como contato principal da equipe, para que os conselhos não puxem para cinco direções.

5. Dê aos mentores um jeito de compartilhar o que veem. Depois de cada rodada, reúna os mentores por dez minutos. Quais equipes estão travadas? Quais estão prestes a construir algo que viola uma restrição? Quais não falaram com um único usuário? Isso permite que os organizadores ajam cedo, mandando, por exemplo, um mentor usuário para a equipe que precisa de um. Também evita que os mentores repitam os conselhos uns dos outros. As anotações dos mentores nunca devem ir para os jurados como notas; mentoria e avaliação precisam ficar separadas, senão as equipes deixam de ser honestas com os mentores.

6. Proteja a autoria da equipe. Fique atento às falhas comuns: o mentor que redesenha a ideia, o mentor que insiste na tecnologia que ele prefere, o mentor cuja senioridade faz a equipe abandonar um bom caminho para agradá-lo. Diga aos mentores, na preparação, que quem decide é a equipe. Diga às equipes também: "Os mentores dão conselhos. Vocês decidem o que aproveitar." Se um mentor continuar se impondo, mude-o de papel discretamente.

7. Feche o ciclo depois do evento. Pergunte às equipes qual mentoria ajudou e qual não ajudou, usando uma matriz de captura de feedback. Agradeça aos mentores com algo específico: a equipe que ajudaram, o que mudou por causa disso. Se uma ideia vencedora virar piloto, o mentor que conhece o domínio muitas vezes é a melhor pessoa para continuar envolvida nas primeiras semanas. Essa continuidade faz parte do que acontece depois do hackathon.

O que fazer e o que evitar como mentor

Faça

• Comece toda conversa perguntando o que a equipe está tentando fazer e onde está travada.
• Insista no contato com usuários e dados reais cedo, no primeiro dia se possível.
• Sugira um teste rápido (um protótipo em papel, uma conversa de cinco minutos) em vez de um longo debate.
• Diga com honestidade quando algo viola uma restrição, e explique por quê.
• Deixe cada equipe com um próximo passo claro.

Evite

• Pegar a caneta. Se você está desenhando a solução, está projetando a solução.
• Trazer a sua própria ideia e procurar uma equipe para construí-la.
• Dar conselho sobre tudo; escolha a coisa que mais importa agora.
• Contradizer outro mentor na frente da equipe; levante o assunto na reunião dos mentores.
• Ser mentor de uma equipe que você também vai avaliar.

Exemplo ilustrativo

Ilustrativo. Um trust do serviço nacional de saúde do Reino Unido fez um hackathon de dois dias sobre como reduzir as faltas em consultas ambulatoriais. No primeiro evento, doze médicos e gestores seniores constavam como mentores. A maioria passou uma vez, rapidamente. Três equipes mudaram de rumo depois que um médico especialista sugeriu um app de lembretes; na hora do pitch, quatro equipes tinham construído apps de lembrete quase idênticos.

O evento seguinte foi redesenhado em torno dos momentos em que as equipes travam. Os organizadores recrutaram sete mentores: dois atendentes do ambulatório que lidavam com remarcações todos os dias, dois pacientes do painel de pacientes do trust, um analista de dados, um médico e um facilitador para testes e pitch. Os sete foram preparados na noite anterior com uma página de perguntas e uma regra: pergunte, não diga. Cada equipe teve três conversas agendadas e um mentor principal. Na primeira reunião, os mentores sinalizaram que cinco equipes tinham suposto que os pacientes esqueciam as consultas; os atendentes sabiam que muitos pacientes não conseguiam se liberar do trabalho nos horários oferecidos. Os mentores pacientes confirmaram. As equipes que testaram isso com os mentores pacientes migraram para a troca flexível de horários em vez de lembretes. A ideia vencedora entrou num pequeno piloto com o gestor do ambulatório como dono, e um dos atendentes continuou como consultor.

Perguntas frequentes

O que faz um mentor de hackathon? Um mentor ajuda as equipes a avançar fazendo perguntas, dando feedback honesto, compartilhando conhecimento técnico ou do domínio e destravando problemas. Ele não avalia e não desenha a solução pela equipe.

De quantos mentores um hackathon precisa? Depende do número de equipes e da duração do evento, mas mais ou menos um mentor para cada duas ou três equipes em cada sessão funciona quando o tempo deles está agendado. A variedade de papéis importa mais do que o total.

Um mentor também pode ser jurado? Melhor não. As equipes precisam poder admitir dúvidas aos mentores sem medo de perder pontos. Se for inevitável sobrepor, garanta que ninguém avalie uma equipe da qual foi mentor.

Para onde ir agora

Para o desenho completo do evento, veja como fazer um hackathon que produza algo real e o mapa dos formatos em hackathons, jams e desafios: todos os tipos explicados. Os guias de mapa de premissas, teste de hipótese e protótipo em papel são os três que todo mentor deveria conhecer.