Em resumo

• Comece a planear com seis semanas de antecedência. É o calendário, e não a tecnologia, que faz ou desfaz o dia.
• Mantenha o tema suficientemente estreito para que uma equipa arranque em cinco minutos e suficientemente aberto para dar dez respostas diferentes.
• Forme equipas equilibradas de três a quatro elementos de propósito. Não deixe que os grupos de amigos se escolham a si próprios.
• Publique a grelha de avaliação antes de alguém escrever uma linha de código e dê mais peso ao "funciona?" do que ao acabamento.
• Premeie o esforço, o trabalho de equipa e uma demonstração clara, e não apenas quem programa mais depressa.

O que é, de facto, um hackathon escolar

Um hackathon escolar é um evento curto e concentrado em que os alunos formam equipas pequenas, escolhem um problema e constroem um protótipo funcional contra o relógio. É essa a ideia toda: muito trabalho de construção, um prazo fixo e uma demonstração no fim. Pode decorrer numa única manhã ou repartir-se por algumas sessões de clube, e funciona desde o 2.º ciclo até ao secundário, desde que o âmbito seja ajustado à idade.

A receita é fácil de descrever e fácil de estragar. Dê aos alunos um tema claro, equipas equilibradas, uma grelha de avaliação que possam consultar e equipamento que chegue para construir algo a sério. Tudo o que se segue percorre essa receita, das seis semanas de antecedência até à entrega dos prémios.

Escolha um formato à medida da sua escola

Decida a forma do evento antes de tudo o resto, porque é ela que determina todo o calendário. Um hackathon não tem de ser uma maratona. Para a maioria das escolas, a escolha honesta está entre três formatos, e cada um dá-lhe algo a troco de um custo.

Formato	Bom para	Vantagem	Atenção a
Sprint de meio dia (cerca de três horas)	Estreantes e anos de escolaridade mais baixos	Fácil de organizar, cabe numa manhã, baixo risco	As equipas mal chegam ao fim, por isso mantenha o enunciado minúsculo
Um dia inteiro de escola	Um ano de escolaridade completo ou a mostra de um clube	Tempo para uma construção a sério e demonstrações decentes	A energia cai depois do almoço, por isso planeie pausas e comida
Multissessão (algumas semanas de tempo de clube)	Projetos mais profundos e ambiciosos	Menos pressa, espaço para iterar e testar	A dinâmica perde-se entre sessões, e projetos a meio precisam de arrumação segura

Se é a sua primeira tentativa, faça o sprint de meio dia. Um evento pequeno que acaba bem ensina mais do que um fim de semana que colapsa à sexta hora.

A contagem decrescente de seis semanas

A maior parte do trabalho é logística, e a logística compensa quem tem calendário. Aqui fica uma contagem decrescente que pressupõe um evento único durante o terceiro período, mas as fases adaptam-se a qualquer data.

Seis a quatro semanas antes

Feche a data, a sala e o formato. Combine com quem partilha o espaço e verifique se não choca com testes e jogos desportivos. Esboce já o tema e a grelha de avaliação, enquanto tem tempo para pensar, e não na véspera. Calcule aproximadamente quantos alunos espera e quantos adultos consegue pôr na sala. Aponte a um mentor por cada três ou quatro equipas, para que ninguém fique encalhado vinte minutos.

Três a duas semanas antes

Abra as inscrições e forme as equipas. Envie às famílias uma nota breve sobre horários, comida e o que devem trazer. Conte o equipamento e carregue tudo pelo menos uma vez, para descobrir a bateria morta agora e não no próprio dia. Recrute os jurados cedo, porque adultos ocupados precisam de aviso prévio. Imprima ou partilhe a grelha de avaliação para que os alunos a possam ler antes de chegarem.

A última semana

Faça um ensaio com exatamente a tecnologia que os alunos vão usar: iniciar sessão, abrir o editor, ligar uma placa, correr um programa. Se falha no seu computador, vai falhar em trinta. Prepare uma folha de andamento simples com os horários e afixe-a na parede. Trate dos kits, cabos e carregadores sobresselentes e etiquete uma caixa para eles.

No próprio dia

Comece com um briefing de dez minutos: o tema, as regras, a grelha de avaliação e o momento em que o relógio para. Depois saia da frente. Mantenha uma contagem decrescente visível, anuncie o meio do percurso e dê um aviso firme quinze minutos antes do fecho do código. Reserve o último bloco para as demonstrações e a avaliação, para que o dia não se atrase.

Defina um tema com balizas

Um bom tema é uma cerca, não uma jaula. Demasiado vago ("construam algo fixe") e metade das equipas passa uma hora a decidir o que fazer. Demasiado apertado ("construam um robô seguidor de linha que vire duas vezes à esquerda") e todos os projetos ficam iguais. Aponte a um enunciado com um assunto claro e muito espaço, como "ajudar alguém na nossa escola", "tornar a nossa sala de aula mais segura" ou "algo que reaja ao que o rodeia".

Dê a cada equipa um enunciado de uma página com o tema, as restrições, o prazo e a grelha de avaliação. Acrescente duas ou três direções de exemplo, para que as equipas mais nervosas tenham um ponto de partida, e deixe claro que são sementes e não as únicas opções.

Forme as equipas de propósito

Equipas de três a quatro são o ponto ideal. Aos pares faltam ideias e papéis; a cinco fica sempre alguém parado. Resista a deixar os alunos escolherem os seus grupos, porque os grupos de amigos tendem a separar-se entre os confiantes e os postos de lado. Misture níveis de experiência e dê a cada equipa pelo menos um aluno que já tenha programado e outro que não.

Atribua papéis leves para que ninguém se esconda: um construtor, um programador, um relator e um apresentador, com rotação se quiser. Os papéis contam sobretudo na demonstração, quando uma equipa calada com um grande projeto pode ainda assim perder porque ninguém se preparou para o explicar.

Avalie com uma grelha que os alunos possam ver

A maior melhoria de justiça é mostrar a grelha antes de os alunos começarem. Transforma a avaliação de mistério em alvo. Limite-a a um punhado de critérios, pontue cada um numa escala pequena, como de zero a cinco, e dê peso aos que premeiam trabalho a sério.

• Funciona? Uma coisa tosca que corre vale mais do que uma coisa bonita que não corre. Dê a este critério o maior peso.
• Adequação ao problema. A construção responde mesmo ao tema ou a equipa derivou para uma missão paralela vistosa?
• Criatividade. Premeie uma abordagem invulgar, e não apenas mais funcionalidades.
• Trabalho de equipa. Todos os membros conseguiam explicar uma parte? Isto desencoraja discretamente que um aluno faça tudo.
• Demonstração. Uma explicação clara de noventa segundos com uma execução ao vivo.

Instrua os jurados a fazerem perguntas em vez de caçarem erros e a tratarem todas as equipas da mesma forma. Dois jurados por equipa, a pontuar de forma independente e a comparar depois, atenuam o avaliador severo e o brando.

Equipamento e logística

O equipamento é onde os bons planos morrem em silêncio, por isso trate-o como uma tarefa própria. Calcule o que cada equipa precisa e depois acrescente uma margem. Um conjunto de turma de dez kits para oito equipas significa dois sobresselentes para quando — e não se — algo se partir. Carregue tudo na véspera, etiquete os cabos e mantenha uma caixa de reparação com cabos sobresselentes, uma chave de fendas e fita adesiva.

As placas programáveis mantêm um hackathon físico em vez de o prenderem a um ecrã. Um conjunto consistente, como a placa sheenbot∞, significa um só conjunto de instruções e um só fluxo de início de sessão a ensinar, em vez de cinco configurações diferentes para depurar ao mesmo tempo. Se está a reforçar um conjunto de turma ou a substituir cabos gastos, as peças e os kits da loja poupam-lhe uma correria na semana anterior. Seja o que for que usar, normalize numa só plataforma para que os seus mentores não passem o dia a traduzir entre sistemas.

Uma nota sobre energia para as salas sul-africanas. Planeie para os cortes de eletricidade: saiba qual é o seu horário, carregue com antecedência e tenha pronta uma tarefa alternativa sem tomada, para que um corte de duas horas não afunde o evento.

Prémios que contam

Os prémios definem o tom, por isso tenha cuidado com aquilo que premeia. Se o único troféu vai para a construção mais polida, ensina a todos os outros que desperdiçaram o dia. Reparta o reconhecimento por categorias, para que mais equipas saiam com a sensação de terem sido vistas: melhor solução para o tema, ideia mais criativa, melhor trabalho de equipa, melhor demonstração e uma escolha do júri para a equipa que recuperou de um desastre.

Mantenha os prémios em si modestos. Certificados, um pequeno componente de kit ou o direito a demonstrar o projeto na assembleia funcionam todos. O que os alunos realmente recordam é terem sido chamados e terem ouvido o nome do seu trabalho, e não o valor do objeto.

Formas comuns de falhar

• Âmbito que cresce sem controlo. As equipas planeiam uma catedral e acabam um caixilho de porta. Insista para que todos definam uma "versão mínima que funciona" na primeira meia hora.
• O passageiro silencioso. Os papéis e o critério de trabalho de equipa apanham isto, mas um mentor também deve detetar o aluno que ficou calado e trazê-lo de volta.
• Tecnologia que falha logo no início. Noventa minutos perdidos com inícios de sessão é o clássico. O ensaio da última semana existe precisamente para evitar isto.
• Avaliação que parece aleatória. Uma grelha visível e dois jurados por equipa resolvem a maior parte das queixas.
• Sem tempo para apresentar. Se as equipas construírem até tocar a campainha, as demonstrações desaparecem e a aprendizagem com elas. Proteja o bloco final sem cedências.

Conclusão

Um hackathon escolar é sobretudo gestão de projeto com um relógio em contagem decrescente. Comece seis semanas antes, escolha um formato que consiga mesmo organizar, defina um tema com balizas, forme as equipas de propósito e avalie com uma grelha que todos já viram. Acerte nisso e a tecnologia trata quase toda de si própria. Se preferir ver o ritmo antes de organizar o seu, os nossos workshops de férias usam o mesmo formato de construir e demonstrar a uma escala menor, e pode ler mais notas para organizadores na sala de imprensa.

Perguntas frequentes

Quanto deve durar um primeiro hackathon escolar?

Meio dia. Cerca de três horas concentradas chegam para que equipas mais novas construam algo e o demonstrem sem se esgotarem, e é curto o suficiente para o conseguir organizar e recuperar se a tecnologia se portar mal. Estique para um dia inteiro só depois de já ter feito um e conhecer os seus estrangulamentos.

Os alunos precisam de saber programar primeiro?

Nem todos. As equipas mistas funcionam melhor, com pelo menos um aluno que já tenha programado para desbloquear os restantes. Se a maioria dos seus alunos for principiante, faça uma sessão curta de aquecimento com as mesmas ferramentas uma semana antes, para que o hackathon seja sobre ideias e não sobre aprender a iniciar sessão. Uma aula experimental é uma forma pouco exigente de perceber em que ponto está um grupo antes de planear o evento.

De quantos mentores preciso?

Cerca de um adulto por cada três ou quatro equipas. Menos do que isso e os alunos ficam encalhados; os mentores estão ali para fazer perguntas e dar um empurrão, não para construir. Alunos mais velhos e uns quantos pais disponíveis também contam.

E se faltar a eletricidade a meio do evento?

Parta do princípio de que vai faltar e planeie em conformidade. Carregue placas e portáteis na véspera, saiba qual é o seu horário de cortes de energia e tenha pronta uma tarefa sem tomada, como esboçar o desenho ou preparar a demonstração, para que um corte se torne uma pausa e não o fim do dia.

Deve haver um único vencedor?

Prefira várias categorias a um grande prémio único. Melhor adequação ao tema, mais criativo, melhor trabalho de equipa e melhor demonstração permitem que mais equipas saiam com alguma coisa, e premeiam os comportamentos que realmente quer. Um vencedor único diz a todas as outras equipas que o dia foi desperdiçado.