Melhor maneira de treinar novas contratações [fechado]

Atualmente, a equipe que faço parte de uma rotatividade bastante alta, com membros normalmente se mudando para diferentes projetos dentro da mesma empresa. Atualmente, nosso "treinamento" para novos membros é emparelhá-los com um contato principal (geralmente a pessoa mais recente para concluir seu treinamento), que lhes proporcionará experiência prática e perguntará a desenvolvedores seniores se a contratação mais recente pedir algo ao mentor não sabe. Ele fornece uma chance para o novo contratado se envolver rapidamente e desafia o mentor a melhorar também sua compreensão do sistema.

No entanto, como você pode imaginar, esse estilo de treinamento consome muito tempo e não fornece uma transferência muito boa de conhecimento (os conceitos errados se propagam, as lacunas se expandem).

Fui encarregado de gerar documentação e materiais de treinamento para nossas futuras contratações. Eu já escrevo técnicas ocasionalmente, mas é para o usuário final e é altamente específico com muitas capturas de tela e consome uma grande quantidade de tempo para ser concluído.

Criar a nova documentação para novas contratações é considerada de baixa prioridade e atualmente só tenho ~ 40 horas para trabalhar nela. Documentar o sistema da maneira atual em que escrevo a documentação técnica mal arranharia a superfície em 40 horas. Especialmente considerando que tenho que documentar não apenas a base de código, mas também as implantações e suporte.

Como posso escrever rapidamente a documentação para atualizar as contratações o mais rápido possível, sem investir tempo significativo na redação da documentação?

Informações adicionais:
Atualmente, temos um wiki e alguma documentação de treinamento, no entanto, ambos são escassos.

Boa pergunta. O treinamento no programador no trabalho raramente é levado a sério, nem é discutido com frequência.

Algumas idéias que eu vi funcionar bem:

• No seu wiki, tenha um documento de rampup para novos contratados (o que você está escrevendo). Nesse documento, descreva as tarefas que o novo contratado executará nas primeiras 1-2 semanas. Onde trabalho, há muito a saber desde o início, desde ferramentas / softwares internos até processos, até locais de tipos específicos de informações. editar> temos instruções como "instalar x, y, z em ordem" com capturas de tela para configuração, etc. Portanto, configurando um sistema ou farm (VMs) com o Win Server, SQL Server, SharePoint, BizTalk, nosso software não é tão simples quanto sons. Isso vale para as outras versões dos aplicativos que suportamos.
• Pratique problemas. Onde estou, temos um produto que expõe uma API grande. Portanto, é sempre benéfico para nós revisar a documentação de nossos próprios produtos para escrever extensões (pré-determinadas) da mesma forma que nossos clientes. Portanto, se você tinha uma biblioteca de matemática como parte da API do seu produto, tenha um problema prático que é "escreva uma calculadora usando nossa API" ou algo parecido.
• Os mentores são bons. Mantenha-os. Também fazemos isso aqui, e não apenas é uma boa maneira de conhecer pessoas / fazer amigos, mas eles são inestimáveis ​​como fonte de aprendizado. Eu recomendo que não seja a pessoa mais recente para concluir o treinamento, pois eles não têm o histórico de conhecimento corporativo que outra pessoa possa ter. Todos devem fazer isso em rotação.
• Fazemos (aproximadamente) apresentações semanais / palestras técnicas. Peça aos novos contratados que escolham algo do seu produto (ou o atribua) e façam uma apresentação após a terceira semana. Certifique-se de que eles saibam que há espaço para eles estarem errados, e a equipe poderá corrigi-los se apresentar alguma coisa na apresentação.
• Faça com que as novas contratações trabalhem na documentação quando começarem. Obriga-os a ler.

Como observa Dan McGrath, é uma boa idéia incentivar novos contratados a melhorar o wiki para eles também.

Primeiro, sugiro que você não precise fazer com que seu novo documento de treinamento de contratação seja tão completo quanto algo que escreveria para um cliente. Ele precisa ser técnico o suficiente para que um novo desenvolvedor possa usar como guia, mas não tão detalhado que descreva tudo. Eles poderão conversar com a equipe se tiverem alguma dúvida, afinal.

Quais são as 10 principais coisas que um novo contratado precisa saber para ser útil à sua equipe? Concentre-se nessas coisas. Faça deles sua lista de itens de sucesso, para que um novo desenvolvedor tenha o suficiente para fazer e informações suficientes para mantê-lo em funcionamento. Se você tiver muitas coisas na lista, pergunte a si mesmo se elas o farão nas primeiras duas ou três semanas. Se eles não farão algo nesse período, talvez não deva constar no guia de embarque.

Para cada seção do seu guia, verifique se há uma pessoa destacada na parte superior. Dessa forma, se o novo contratado tiver alguma dúvida, eles saberão a quem procurar ajuda. Além disso, certifique-se de que um membro da equipe não seja o responsável por muitas seções. Você não quer gastar o tempo de uma pessoa com perguntas sobre novos contratados, se ela não for a mentora.

Não gaste sua semana inteira neste documento. Deixe algum tempo para ajustá-lo depois de permitir que pelo menos um novo contratado passe por ele. Veja o que funciona bem, o que não funciona e corrija.

Recentemente, iniciei um documento semelhante no meu local de trabalho, com restrições de tempo semelhantes. Eu enfatizo que é fácil querer escrevê-lo em um nível muito detalhado, como também fiz inicialmente, mas isso pode ser realmente contraproducente.

Se alguém novo está começando em uma função, provavelmente será inundado com informações pelas primeiras semanas. Ter o treinamento inicial como um despejo de cérebro de um desenvolvedor que está em uma empresa há vários anos, em minha mente, vai complicar muito o que alguém precisa saber nos primeiros meses ou mesmo ano nessa posição. Mantenha o nível alto, tente usar jargões e conceitos padrão e expanda-os com as especificidades dos processos da empresa.

Para mim, a primeira iteração deste documento é simplesmente um esboço do SDLC que usamos no meu local de trabalho, com uma lista de funções associadas a cada etapa, alguns exemplos de pessoas que cumprem essas funções e listas de verificação específicas associadas a cada etapa do ciclo de vida também. Pessoalmente, considero as listas de verificação indispensáveis ​​para fins de treinamento, mas também qualquer outra coisa que faço no trabalho. Por exemplo:

• O gerente de projetos (Joe) atribui uma tarefa a você no Jira.
• Defina um tempo estimado de conclusão na tarefa com base na fórmula x.
• Defina o ticket como 'em andamento' quando começar a trabalhar nele.
• Crie uma ramificação a partir do git, clique no link para ver um vídeo de 30 segundos sobre esse progresso.
• Escreva testes de unidade com base em restrições no documento de design, consulte a página y para convenções de nomenclatura de testes de unidade.
• Defina o ticket para revisão e envie o código para o sistema de revisão .. 'etc.

Esperamos que seu novo funcionário esteja familiarizado com a maioria dos conceitos e agora tenha um guia passo a passo de como os processos são aplicados na empresa. Também faço uma rápida demonstração do processo, do início ao fim, usando documentos reais de projetos que considero bem executados.

Como mencionado, também é um documento ativo, para que as seções possam ser expandidas conforme for identificado que eles precisam de mais informações. Toda a equipe deve estar envolvida em mantê-lo atualizado. Pode ser um wiki, documento do OneNote, seja o que for, mas algo que todas as pessoas possam editar e revisar e, depois, começar a envolver outras pessoas na melhoria, quando tiverem uma hora livre aqui e ali. Dessa forma, uma pessoa não está fazendo isso e propagando sua própria rotação do processo para todos os novos contratados.

Depois de revisar o processo, peça a eles que executem um pequeno recurso / correção de bug em um projeto não de missão crítica e peça que façam perguntas que o documento não cobre. Registre quais são essas perguntas, porque elas provavelmente devem ser as primeiras coisas que você adiciona ao documento na próxima vez em que trabalhar nele.

Você não pode combinar fazer algo assim tão bom sem gastar tempo. Pelo menos, se você quiser fazer isso sozinho. Você deve se perguntar se é realmente necessário documentá-lo da maneira mais precisa possível.

A única alternativa seria deixar os novos contratados fazerem o trabalho principal. Deixe-os escrever algumas partes. O tempo gasto para corrigi-los (na forma de feedback) será menor do que nas situações atuais. Forneça alguns bons modelos e você não precisa se preocupar com layout.

Acredito que você já sabe que eles lhe deram uma missão impossível. Como escritor, você provavelmente já conhece a citação de Mark Twain:

Se eu tivesse mais tempo, teria escrito menos.

Dado que praticamente não há recursos, provavelmente o melhor que você pode fazer é obter um arquivo e pedir a todos que façam uma cópia do que já possuem e coloque a cópia no arquivo. Dessa forma, você pode pelo menos dizer ao novo contratado: "Se você deseja pesquisar algo sobre o sistema, o lugar para começar é no arquivo".

Uma boa escrita leva tempo, ponto final. Além disso, ele precisa ser adaptado ao público-alvo. O que funciona para os usuários finais não será o que um programador precisa.

Sem mencionar que um bom treinamento não se limita a materiais escritos, incluiria uma aposta completa de recursos educacionais, incluindo on-line, sala de aula, multimídia etc.

Como se costuma dizer: "Se você acha que a educação é cara, tente o custo da ignorância".

Além disso, é desnecessário dizer que visualizar a documentação como algo a ser feito após o fato, em vez de torná-la parte integrante do processo desde o primeiro dia, é indicativo de um problema organizacional sistêmico.