A resposta honesta sobre como avaliar projetos de robótica é esta: classifique o raciocínio que produziu o robô, não os trinta segundos em que ele atravessa uma mesa. Uma demonstração que funciona diz-lhe que a equipa acabou por lá chegar. Não lhe diz quem percebeu o código, quem copiou de um colega, nem se um fio bem arrumado por sorte salvou um projeto que estava, na verdade, avariado. Uma boa avaliação numa aula de robótica olha para as provas do processo recolhidas ao longo do caminho e trata a depuração como uma competência que merece cotação própria.

Isto conta sobretudo em junho, quando os relatórios do 2.º período têm de sair e está a tentar transformar um período inteiro de trabalho prático e barulhento num número defensável. Se o único elemento que tem é a corrida final, fica com muito pouco para escrever. Se tiver diários, registos e curtas explicações orais, a nota escreve-se quase sozinha.

Porque é que "mexeu-se" é uma nota fraca

Uma demonstração final é uma única amostra de um sistema instável. As pilhas descem de tensão, o chão tem uma aderência que a bancada de testes não tinha, e um seguidor de linha afinado com a luz da manhã comporta-se de outra forma sob o sol da tarde à janela. Duas equipas podem chegar ao mesmo resultado visível por caminhos muito diferentes: uma raciocinou até lá, a outra foi por força bruta, mudando números até algo funcionar. Avaliar apenas o resultado premeia as duas por igual, o que ensina discretamente aos seus melhores alunos que compreender é opcional.

Também penaliza a ambição. Uma equipa que tenta um mecanismo mais difícil e chega a 80% do caminho pode parecer pior no dia da demonstração do que uma equipa que jogou pelo seguro. Se a sua grelha só vê a linha de meta, os alunos aprendem a escolher problemas fáceis. Avaliar o processo permite-lhe premiar honestamente a tentativa mais difícil.

Avalie o processo, não apenas o produto

Passe a maior parte do peso para as provas que os alunos geram enquanto trabalham. Três elementos fazem quase todo o trabalho pesado e nenhum deles exige software especial.

• Diários de projeto. Uma entrada curta e datada em cada aula: o que tentámos, o que esperávamos, o que aconteceu de facto, o que vamos mudar a seguir. Meia página chega. O valor está na distância entre o esperado e o real, porque é nessa distância que a aprendizagem acontece.
• Registos de iteração. Uma lista corrida de versões com uma linha a justificar cada alteração. "v3: abrandei o motor esquerdo, o robô puxava para a direita." É a janela mais clara para perceber se um aluno está a raciocinar ou a adivinhar. No nosso canvas de programação por blocos, o histórico de gravações já mostra essa progressão, pelo que o registo pode ser tão simples como anotar que gravações contaram e porquê.
• Explicações a pares. Antes de um projeto contar como terminado, um elemento da equipa explica a outro grupo, em linguagem corrente, uma secção escolhida do código ou da construção. Você ouve durante dois minutos. Um aluno que escreveu a lógica consegue narrá-la; um aluno que a copiou encalha no primeiro "porquê assim e não de outra maneira".

O objetivo destes três instrumentos é tornar visível o raciocínio invisível, para que tenha algo para avaliar além da última corrida.

Uma grelha que premeia a depuração

A depuração é o verdadeiro trabalho da robótica, por isso deve pesar a sério, em vez de ser tratada como um fracasso a esconder. Uma grelha que lhe dá nome muda o comportamento dos alunos: passam a escrever o que se avariou em vez de voltarem discretamente a uma cópia de segurança e fingirem que nunca aconteceu.

Uma grelha simples de quatro dimensões funciona bem num projeto normal com a placa sheenbot ou qualquer kit semelhante. Distribua a cotação de modo a que nenhuma dimensão sozinha consiga sustentar um projeto fraco.

• Compreensão (25%) — o aluno consegue explicar o que faz cada parte da sua solução e porquê.
• Processo e iteração (30%) — qualidade do diário e do registo; prova de que uma alteração foi testada contra uma previsão, em vez de ajustes aleatórios.
• Depuração (25%) — como uma falha foi isolada e corrigida; um erro claramente documentado, encontrado e resolvido, deve valer mais do que um projeto sem qualquer problema registado.
• Resultado (20%) — a construção final cumpre o enunciado. Continua a contar. Apenas não domina.

Repare que o resultado é a dimensão mais pequena. É deliberado. Quando os alunos veem que um erro bem caçado vale mais do que um projeto suspeitosamente limpo e sem histórico, deixam de esconder as dificuldades e começam a mostrar o seu trabalho.

Trabalho de grupo e equidade

A queixa mais antiga em qualquer disciplina prática é o passageiro: um aluno conduz o portátil enquanto os outros assistem. As provas do processo são a sua melhor defesa, porque são individuais por construção. Cada elemento mantém o seu próprio diário curto, e a explicação oral é feita por um aluno indicado, sobre uma secção que o professor escolhe e não uma que ele ensaiou. Faça rodar um papel visível em cada aula, para que o condutor, o construtor e o testador sejam pessoas diferentes de semana para semana, e registe essa rotação.

Mantenha uma pequena parte da nota individual e o resto partilhado. Uma divisão comum ronda os 70% de equipa e 30% individuais, sendo a parte individual retirada quase toda do diário do próprio aluno e da sua explicação oral. Chega para tornar visível quem se deixa levar, sem transformar um projeto colaborativo em quatro projetos a solo. Os formatos de competição já seguem esta linha: as equipas que se preparam para a FTC são avaliadas por um portefólio de engenharia que documenta toda a época, e não apenas pelo robô no dia do jogo — exatamente o hábito que está a construir na sala de aula.

Torná-lo sustentável

Nada disto sobrevive se duplicar a sua carga de correção. Mantenha os instrumentos leves. Os diários têm meia página e são corrigidos com um visto rápido contra três perguntas, e não com um parágrafo de comentários em cada um. As explicações orais acontecem em direto durante a aula, pelo que lhe custam tempo de escuta e não tempo de serão. Os registos de iteração leem-se na diagonal, não linha a linha. Integre os pontos de controlo na sequência das aulas desde o início, em vez de acrescentar a avaliação no fim, tal como o nosso currículo da academia distribui pequenas paragens de reflexão ao longo de um projeto em vez de um grande julgamento no final. Uma avaliação que vive dentro do trabalho é muito mais sustentável do que um momento de correção à parte.

Em resumo

"O robô mexeu-se" é um ponto de partida, não uma nota. Desloque o peso da sua avaliação para as provas do processo: diários de projeto datados, registos de iteração honestos e curtas explicações a pares. Construa uma grelha que pague aos alunos pela compreensão e pela depuração, e mantenha o resultado final como a dimensão mais pequena, e não como a história toda. Faça isso e os seus relatórios ficam mais fáceis de escrever, os passageiros silenciosos ficam mais difíceis de esconder e os seus alunos aprendem a lição que verdadeiramente se transfere para fora da sala: na engenharia a sério, o raciocínio é o produto.