Grupos

Manual do bom docente

00:52 @ 31/07/2011

Mais uma vez, como escreví num post anterior, me sentei na cadeira de aluno num curso de informática e cheguei a algumas conclusões interessantes:

  • "alunos" muitas vezes fazem jus à definição do termo (a=sem luno=luz, "sem luz") pois aceitam situações pedagogicamente "erradas" como se fossem algo "natural" (os exemplos seguem mais adiante) seja pela pouca idade ou desconhecimento de causa.
  • Maus exemplos são extremamente didáticos, pois acabam orientando sobre o que se deve fazer, de fato.
  • A origem dos problemas podem estar no sistema a nossa volta ou dentro de nós; a própria personalidade, temperamento ou modo de perceber o mundo podem ser tão prejudiciais quanto um ambiente que não colabora para que as coisas funcionem de modo adequado. Perceber isso é tão difícil quanto fundamental para quem trabalha com o público.

Enfim, vou discorrer sobre situações que presenciei enquanto aluno; antes de tudo um pedido: quem por acaso se identificar com algumas das situações a seguir, por favor encarem os comentários como forma de auto-aperfeiçoamento. Ninguém sabe tudo sobre docência e nem Bill Gates sabe tudo sobre informática.

Se a aula for em sala com computadores, evite:

1) Projetar a tela de computador em resolução alta (com letras e detalhes pequenos). Aula de informática não é exame de vista. Se você precisa mostrar um recurso que só aparece em resolução alta (tornando os detalhes da projeção um jogo de adivinhação) use "recursos de acessibilidade" como a lente de aumento do Windows, ou, após mostrar o que desejam retorne à menor resolução possível, com os elementos de tela maiores.

Se projetar em tela com detalhes grandes implicar em mostrar uma coisa e os alunos verem outra:
a) coloque a tela dos alunos na mesma resolução que a sua
b) se não for possível, tente decorar as diferenças entre a sua tela e a dos alunos (tenha uma imagem da tela como os alunos vêem sempre à mão) e explique durante a aula que na sua projeção a tela "está assim", mas na projeção dos alunos "está deste modo".

2) Terminar a aula depois do horário ou começar antes da hora. Respeite quem precisa acordar cedo no dia seguinte ou mora longe. Parece surreal mas já ví um docente fazer as duas coisas numa mesma aula...

3) Dar mais atenção aos alunos mais adiantados, pois os atrasados demandam maior atenção para compreender a matéria.

4) Não assumir que desconhece um assunto é desonestidade intelectual. Ficar com a dúvida é preguiça mental. Tente descobrir a dúvida não respondida até a aula seguinte ou final do módulo, se possível, e repasse o esclarecimento. Os alunos vão ficar com boa impressão de você, pode crer.

5) Assumir que o aluno conhece programas ou assuntos que fogem ao escopo do que é ensinado. Se o aluno não conhece um segundo programa - ou informação - que vai ajudar a realizar uma tarefa no programa principal, explique teoricamente ou faça com o aluno passo-a-passo.

Eu particularmente faço uma dinâmica ao início do curso/módulo para medir o nível de conhecimento dos alunos: peço para que realizem tarefas, relacionadas a informática básica, que serão desenvolvidas no decorrer do curso. Isso permite que eu saiba de antemão quem precisa mas de atenção dentro do grupo.

6) Abandonar os alunos mais atrasados, pois eles irão abandonar você. Crie estratégias para que os mais atrasados acompanhem os mais adiantados. Por exemplo, se - um aluno perdeu o fio da meada- o computador do aluno travou e ele não salvou - copie para ele o trabalho em desenvolvimento para ele prosseguir a partir daquele ponto.
Isso pressupõe que suas explicações são passo-a-passo, e que você desenvolve exercícios junto com os alunos.

6) Demonstrar o que não será ensinado; deixe bem claro que isso foge do escopo do curso. Mostrar e não ensinar deixa a impressão de que se está sonegando informação, no mínimo.

7) Ignorar demandas dos alunos. Se pedirem mudanças no programa, faça alterações, deixando bem claro que se está deixando de ensinar um assunto em favor de outro.

No caso de divergência, decisões por consenso são melhor do que por maioria: se a maioria decide algo que não agrada a minoria, você pode "perder" a minoria, que pode gerar um efeito dominó de esvaziamento da turma. Neste caso tente uma solução em que ambos os lados abrem mão de alguma coisa em favor da opinião do colega.

Exemplo: se a maioria decide que o curso de informática básica deve abordar instalação e uso de um programa utilitário e a minoria acha que isso não é relevante, que tal ensinar o uso de um software que tenha versão instalada, portátil e online? Mostrar o uso de um software online (que possui poucos recursos) será bem mais rápido do que instalar e explicar um software completo...

8) Fugir ao programa do curso. Se o curso é sobre o software "A" não comece a explicar o software "B" porque você acha melhor.
Imagine que num curso de "Apresentação de slides" começo a explicar um outro programa que faz organo/fluxogramas pois este faz organogramas melhores que o primeiro? E quem pagou para aprender apresentação de slides fica como?
Agora, se no final da aula parte da turma deseja dicas de como usar o segundo programa, e ele está instalado, não há problema em explicar esse assunto apenas para os que desconhecem, num intevalo ou ao final da aula...

Enfim, a lista é longa essas são apenas algumas situações recorrentes. Quem quiser dar outros exemplos ou comentar, fique a vontade.

Comentários