Guia do Mentor

Cada projeto possui um(a) mentor(a), a pessoa responsável por ajudar os aprendizes na realização das tarefas ao longo do evento. Cada projeto também possui um(a) mentor(a) auxiliar que atuará no projeto caso o(a) mentor(a) não possa concluir a participação no evento.

Requisitos

  • Estar vinculado(a) à organização que submeteu o projeto;
  • Ter conhecimento das tecnologias e/ou do contexto do projeto submetido para que possa ajudar o(a) aprendiz;
  • Dedicar no mínimo 20 (vinte) horas ao longo do evento para a execução das atividades referentes ao projeto, devendo esta carga horária ser distribuída igualmente durante o evento (aproximadamente duas horas e meia semanais).

Atividades e responsabilidades

O(a) mentor(a) é reponsável por avaliar candidatos a aprendiz, visando escolher de forma justa a pessoa com perfil mais adequado ao seu projeto e incentivando a participação de minorias sociais e grupos minoritários, como também pessoas que não possuam experiência.

Durante o evento, o(a) mentor(a) deve guiar o(a) aprendiz no desenvolvimento. Isso não quer dizer necessariamente dar as respostas aos problemas, mas apoiar e orientar o(a) aprendiz na descoberta de suas próprias soluções. Ter acompanhamentos diários ou no mínimo semanais é essencial para que o projeto corra bem, seja por chamadas de voz/vídeo, mensagens de texto ou revisões de código. Por isso, recomendados no início da fase de desenvolvimento combinar horários com seu(sua) aprendiz e também estabelecer os meios de comunicação que serão usados.

O(a) mentor(a) não deve produzir código, porém, junto ao aprendiz ou à aprendiz, deve realizar três apresentações: duas nas entregas parciais e uma apresentação final, conforme as datas estipuladas no programa. O ideal é que consiga expor o progresso feito e, caso haja necessidade, apresentar as mudanças que ocorreram na proposta de projeto ao longo do desenvolvimento.

O(a) mentor(a) será avaliado pelo(a) aprendiz e pela OpenDevUFCG, e também deverá avaliar o(a) aprendiz e o andamento do projeto através de um formulário que iremos disponibilizar semanalmente.

Como acompanhar o(a) aprendiz

Acompanhar o(a) aprendiz não deve ser uma tarefa difícil, mas exige constância. Estar presente semanalmente para tirar dúvidas e analisar o progresso é importante para avaliar se o projeto está indo bem ou exige mudanças. Mesmo que o(a) aprendiz demonstre que não precisa de ajuda, tente sempre fazer perguntas para acompanhar o progresso. Algumas sugestões são:

  • O que você fez e aprendeu nos últimos dias?
  • Está com dúvida em alguma parte do código? Em alguma tecnologia?
  • Tem algo que está travando seu andamento?
  • Após terminar essa atividade, o que irá fazer?
  • Como você fez essa atividade? Quais passos seguiu?
  • As especificações do projeto ainda fazem sentido?

Leve em consideração que concluir uma atividade toda semana não é necessariamente sinônimo de progresso. Na verdade, o que se espera é que o(a) aprendiz esteja se esforçando e aprendendo conceitos e tecnologias novas, e é seu papel acompanhar esse andamento. Procure mantê-lo(a) motivado(a), pois o processo de aprendizado pode ser frustante no início.

Modelos de reuniões

Caso esteja em dúvida de que modelos de reuniões seguir, temos algumas sugestões usadas por vários times de desenvolvimento de software ao redor do mundo. Sinta-se livre para adequá-los às suas necessidades! De maneira geral, priorize realizar reuniões curtas e adiantar o que se pode por texto.

O ideal é que sejam realizadas reuniões de acompanhamento de atividades e de planejamento, sendo a primeira muito mais simples e direta e a segunda exigindo discussões e estudo. A seguir, descrevemos orientações para ambos tipos de reunião.

Reuniões de acompanhamento

As reuniões de acompanhamento podem acontecer com frequência variada, idealmente em intervalos menores. Nelas, o(a) aprendiz pode relatar o que aprendeu e que atividades conseguiu ou não realizar, podendo haver discussões rápidas para tirar dúvidas ou para o(a) mentor(a) fazer sugestões. Sugerimos os seguintes modelos:

  • Reuniões diárias com menos de 15 minutos para relatar progresso feito, o que pode se adequar para acontecer apenas nos dias em que o(a) aprendiz trabalha. São ótimas por serem rápidas e sempre conseguir acompanhar cada pequeno progresso feito;
  • Reuniões semanais de 20 a 40 minutos para repassar atividades, sendo mais longas para disponibilizar maior espaço para discutir cada atividade.

Reuniões de planejamento

As reuniões de planejamento podem ocorrer em frequências menores. Nelas, deve-se analisar o que foi feito e junto ao aprendiz ou à aprendiz planejar as próximas atividades. Idealmente, deve-se produzir algum tipo de documento que as descreva. Sugerimos os seguintes modelos:

  • Reuniões semanais, dependendo da frequência de reuniões de acompanhamento, para não sobrecarregar o(a) aprendiz;
  • Reuniões quinzenais, podendo ser de 20 minutos a uma hora;
  • Reuniões mensais, entre 30 minutos e uma hora, atentando às datas de entregas parciais e final.

Revisão de código

Caso seu(sua) aprendiz produza código constantemente, recomendamos que você também faça constantes revisões de código para avaliar a qualidade e corretude. Caso não tenha conhecimento técnico, avalie apenas o resultado produzido pelo código e peça para outra pessoa revisá-lo. A revisão do que está sendo desenvolvido é o momento perfeito para acompanhar o que o(a) aprendiz aprendeu e fazer sugestões construtivas.

Se seu projeto está no GitHub ou GitLab, essas ferramentas possuem ótimas páginas que facilitam na revisão de código e permitem fazer sugestões. Você pode seguir esse tutorial do GitHub de revisão de pull requests para aprender como funciona o processo.

Havendo uma boa separação de atividades no planejamento, o(a) aprendiz conseguirá submeter pequenas partes para revisão, podendo ser para branch master ou para uma branch isolada, sendo o caso do projeto.

Você também pode usar o sistema de issues dessas ferramentas para separar atividades e acompanhar seu progresso. Nelas, você pode adicionar descrição, comentários, fazer referências a pull requests como também adicionar labels que as categorizem. Se não for utilizar issues, é fortemente recomendado que você use outra ferramenta para cadastrar progresso de atividades.

Peça ajuda também

O(a) mentor(a) não precisa ser o conhecedor de todo o projeto e suas tecnologias, nem precisa saber responder todas as dúvidas do(a) aprendiz de imediato. Seu papel é ser guia e acompanhar o(a) aprendiz, não abandoná-lo(a) e estar sempre disposto(a) a ajudar. Por isso, caso tenha dúvidas, seja sobre o projeto em si, sobre tecnologias ou sobre gerenciamento, peça ajuda!

Peça ajuda para sua organização, para a comunidade do evento no Discord ou para a própria OpenDevUFCG. Somos uma comunidade que quer que todos seus membros cresçam juntos, e por isso ajudamos uns aos outros!