Olá Habr! Meu nome é Andrey Gomenyuk, sou o líder de uma das equipes de desenvolvimento de servidores do Badoo .

No Meetup de Badoo Techleads de maio, dedicado ao gerenciamento de desenvolvimento, compartilhei a experiência de integrar os recém-chegados à equipe. E hoje estou compartilhando uma versão suplementada e aprimorada do meu relatório.

Imagine que hoje é seu primeiro dia útil no Badoo. Que tipo de conhecimento e habilidades o departamento espera de você, e em particular eu, do líder? Pelo menos:



Observe que não há nada como "escrever em PHP" e "conhecer o MySQL". Perguntamos sobre isso na entrevista. E nesta lista estão todas as nossas ferramentas, tecnologias e termos, bem como coisas gerais que provavelmente não gostamos de todo mundo. E quanto mais cedo você souber tudo isso, melhor.

Onboarding no Badoo

O termo integração significa inserir uma pessoa em uma equipe, apresentando-a ao projeto e aos processos. Como nosso departamento de desenvolvimento de servidores dobrou nos últimos anos (agora existem mais de quarenta de nós), nos tornamos os primeiros no Badoo a nos preocuparmos com a adaptação intensiva dos recém-chegados e sua integração no trabalho.

Destaco dois objetivos principais de integração.

O primeiro é de curto prazo. Nós, como a maioria das empresas de TI, realmente queremos colocar a pessoa no código no primeiro dia, colocar seus ingressos em produção na primeira semana, para que a pessoa se acostume o mais rápido possível. No entanto, isso não é a principal coisa para nós.

O segundo objetivo é de longo prazo. Queremos que uma pessoa alcance um certo nível de independência o mais rápido possível e comece a resolver efetivamente as tarefas.

Para fazer isso, lideramos o iniciante em cinco estágios não muito explícitos. Mas antes de falar sobre eles em ordem, observo dois pontos igualmente importantes.

Quem conhecerá o recém-chegado

No primeiro dia útil, certamente conheceremos um iniciante. Isso deve ser feito pelo líder, e nós do departamento estamos tentando cumprir esta regra. Lead conhece um homem, mostra o escritório e o apresenta à equipe. Em seguida, é realizada uma reunião pré-agendada com o departamento de pessoal, durante o qual os documentos são elaborados.


Fonte

Parece que depois disso já é possível colocar uma pessoa na mesa, mas há outro detalhe importante.

Quem "liderará" o iniciante

Em algumas empresas, todo o processo de integração está "vinculado" aos mentores. Estas são as pessoas que explicam tudo, mostram o que, onde e como, respondem às perguntas do iniciante e o reúnem com as pessoas certas.

Nós não usamos esse termo, mas, como diz a famosa canção, existe um mentor, mas não há palavras. Apenas essa função é atribuída ao líder, que pode delegá-lo a um dos funcionários. Como regra, um líder (ou uma pessoa nomeada por ele) é um ponto de partida para um iniciante em todas as questões. Durante uma breve reunião, ele apresenta o recém-chegado ao projeto, fala sobre os processos adotados pela empresa. Este é o começo da transferência de nossa cultura para uma pessoa que já trabalhou em outras empresas e está acostumada a fazer as coisas de maneira diferente. E é muito importante que o iniciante entenda o que, como e por que fazemos.

Etapas da integração

Permitirei-me dividir todo o processo em várias etapas, cada uma das quais com algum tipo de resultado:

• homem sentado em um laptop
  
• com um ambiente de trabalho customizado
  
• e faz ingressos.
  
• Pode projetar um novo recurso
  
• e trabalhar de forma independente.
  

Em seguida, considere o que acontece em cada estágio.

1. Laptop

Primeiro, queremos que o iniciante se concentre no trabalho, em vez de pensar em algo sem importância, e estamos tentando fazer muito antecipadamente. Portanto, entramos em contato com ele com antecedência e descobrimos os desejos do equipamento: o que o monitor, laptop, teclado e mouse desejam. Criamos todas as contas para iniciantes e emitimos privilégios, adicionamos a grupos e bate-papos. Muitos desses procedimentos são automatizados, enquanto outros são inseridos em listas de verificação para que a pessoa não corra pelo escritório no primeiro dia, descobrindo por que não pode entrar em Jira ou por que não vê o ticket que lhe foi atribuído.

2. ambiente de trabalho

Em seguida, a pessoa se senta no laptop para configurar um ambiente de trabalho. Mas toda a configuração é que ele entra em uma interface especial, seleciona um nome de usuário e carrega uma chave SSH. Feito.

O fato é que temos uma plataforma de desenvolvimento, um análogo de nossa infraestrutura de produção, criada no escritório. Além disso, para emular vários CDs, temos uma plataforma de desenvolvimento nos dois escritórios: em Londres e em Moscou. Essa abordagem tem muitas vantagens. O desenvolvedor sempre tem a versão atual do código e o software mais recente - absolutamente o mesmo que na produção. Mesmo que algo não funcione, você pode ter certeza de que alguém já está resolvendo o problema. O novato, na verdade, apenas clona o repositório, abre o IDE - e está pronto para funcionar. É suficiente para Lida garantir que ele possa entrar em todas as conversas e começar a receber correspondência.

Nesta fase, estou pronto para dar o primeiro ingresso ao iniciante.

3. Ingressos

Digamos que o primeiro ticket tenha sido assim:



Ou assim:



Provavelmente, para você, esses ingressos têm apenas uma coisa em comum - nada está claro. Eu destaquei em laranja as palavras que provavelmente causam mais perguntas e, mesmo que não, eu vou falar sobre elas de qualquer maneira.

Como era antes

Quando cheguei ao Badoo, sete anos atrás, era algo assim. Lead se senta para o recém-chegado e começa a dizer: “Veja, temos filas, uma estrutura de script. Eles funcionam assim. Preste atenção nisso. Neste bilhete, você precisará fazer isso . ”

O problema é que o líder gasta seu tempo de trabalho nessas histórias. Cada vez que ele explica a mesma coisa para iniciantes, ele sempre se esquece de algo. Cada lead diz o seu próprio caminho.

Naturalmente, o lead fornecerá apenas notas introdutórias específicas sobre o ticket relacionadas a esse ticket, perdendo os pontos que o iniciante pode não precisar no momento. Se você tiver sorte, o último poderá encontrar um link para a descrição de uma ferramenta. Mas geralmente toda essa documentação é escrita para uso interno, ou seja, entende-se que o usuário já está familiarizado com os detalhes. A documentação possui muitos detalhes que o iniciante definitivamente não precisa nos primeiros estágios. Como resultado, surgiu uma situação paradoxal: uma pessoa trabalhou por um ano ou dois na empresa, mas não há garantia de que ele se familiarizou com tudo e sabe como toda a infraestrutura funciona.


Quadro do filme Dia da Marmota

Além de colegas que responderam a várias perguntas, Aleksey Rybak, que na época gerenciava a Plataforma, deu uma palestra sobre princípios básicos, infraestrutura e serviços básicos para todos os novos funcionários. Em algum momento, ele estava cansado disso e gravou em vídeo. Mas em uma história de duas horas, você não entenderá tudo, há muitos detalhes. E então esta palestra é muito difícil de atualizar. É claro que é legal que em sete anos tenha ficado um pouco desatualizado, mas algumas partes não sejam mais relevantes.

Em algum momento, alguém criou uma página Bem-vindo ao novo desenvolvedor no Wiki. Eles lançaram um monte de links lá que seria bom ler para o desenvolvedor.

Provavelmente não estou muito enganado se disser que em qualquer empresa existem duas fontes principais de obtenção de novas informações: esse é algum tipo de analógico do Wiki (ou Google Docs) e uma sala para fumantes. Infelizmente, apenas em um deles as informações serão atualizadas, e isso não é um Wiki.

Que nossa página não tinha uma estrutura comum. Reabasteceu assim. O líder de outra equipe vem até mim e diz: “Andryukha, seus desenvolvedores estão indo mal. Para fazer o bem, escrevi um artigo no Wiki. Foi adicionado ao "Bem-vindo novo desenvolvedor" para que todos os seus desenvolvedores precisem lê-lo . "



Naturalmente, ele considera seu artigo o mais importante, coloca-o no lugar mais visível e o destaca em negrito, vermelho. Como resultado, uma grande página com vários links de que ele pode precisar será lançada no iniciante. Com uma abundância de frases em negrito , DEVE LER e "Leia necessário!".

Em algum momento, percebemos que palestras, vídeos e Wikis não são mais adequados para nós. Decidimos aproveitar ao máximo essas ferramentas e fazer algo novo. E ele nos deu a idéia certa ... framework Laravel. Não conte para publicidade. Só que naquela época estávamos escolhendo a estrutura de um projeto, no mecanismo de busca da "melhor estrutura PHP" que o Laravel apareceu em primeiro lugar, e conseguimos. Nele, gostamos muito da seção de documentação do Quick Start, que mostra os princípios básicos e as ferramentas disponíveis em um exemplo real (e, depois de entender o básico, você pode começar a ler a descrição detalhada).

Início rápido

Gostamos muito desse formato e decidimos escrever um artigo semelhante para nossos iniciantes. Mas como fazer isso? Há muita informação - como manter um equilíbrio entre concisão e informatividade, mantendo a possibilidade de atualização oportuna para que os recém-chegados não precisem adquirir conhecimento na sala de fumantes? E como incentivar a leitura de um documento daqueles que trabalham na empresa há algum tempo, mas certamente possuem lacunas de conhecimento?


Fonte

Começamos reunindo uma lista de ferramentas, tecnologias e abordagens que, em nossa opinião, todos os desenvolvedores do departamento deveriam conhecer. Em seguida, eles estruturaram as informações na forma de um sumário, do simples ao complexo: dos bancos de dados e serviços ao desempenho e teste. Depois, uma pessoa escreveu os primeiros capítulos para que outros pudessem entender como apresentar o material. Depois disso, distribuímos voluntariamente os tópicos restantes a outros funcionários, e cada um escreveu um capítulo. O resultado foi um documento enorme, semanas apenas para duas leituras.

Não foi possível criar uma tarefa comum para toda a seção Início Rápido. Sim, seria ineficaz. Imagine que você atribui uma tarefa a uma pessoa - de fato, um grande recurso que cobre todas as seções. Ele trabalhará nisso por um mês ou dois, e todo esse tempo você não poderá distraí-lo com ingressos, o que contradiz o primeiro objetivo da integração.

Em cada seção, colocamos uma ou duas tarefas o mais semelhante possível às reais. Um iniciante lê uma seção, trabalha em tarefas, se familiariza com ferramentas específicas. Recomendamos que nossos líderes realizem algumas das tarefas de acordo com o processo padrão: um ticket é emitido, uma pessoa pressiona um código, um código é revisado, uma pessoa recebe muitos comentários. Depois disso, o ramo é excluído e, com ele, um ticket.

Surgiu então a questão de como manter a relevância de todo esse corpo de informações. E aqui as mesmas tarefas nos ajudaram. Por exemplo, temos pontos (shards virtuais) e um serviço responsável por comparar usuários e pontos. Na vida normal, os desenvolvedores não precisam saber disso, porque usam uma API de alto nível. Mas exigimos que eles entendam como isso funciona internamente.

Damos a tarefa: registrar o usuário no desenvolvedor, obter o identificador de ponto no seu endereço de e-mail, obter as informações do banco de dados no local, entrar lá, selecionar e ver o que está lá. Se algo mudar neste procedimento, os desenvolvedores comuns não saberão disso. Eles não saberão que você precisa entrar e corrigir a descrição. Mas o desenvolvedor que está atualmente envolvido nisso entenderá: algo está errado. Ele subirá à liderança e dirá que algo não está funcionando. O líder se sentará com ele, resolverá o problema - e atualizaremos o documento. Tentamos não incentivar os desenvolvedores a alterar o Início rápido por conta própria, para não violar a estrutura e o estilo da apresentação. Em vez disso, criamos um Google Doc no qual eles podem anotar seus desejos. Em seguida, esta lista é revisada pela pessoa responsável que faz alterações em nosso artigo.

Novas informações são adicionadas ao Início rápido da mesma maneira: alguém encontra uma nova ferramenta que não está descrita no documento e escreve sobre ela no Google Doc. E as pessoas responsáveis ​​decidem se esse é um caso especial que não é interessante para a maioria dos desenvolvedores ou se vale a pena escrever sobre isso no Início Rápido.

Os próprios desenvolvedores às vezes adicionam "pequenas coisas" legais ao documento. Por exemplo, um contador para a duração da leitura e o número de páginas foram adicionados a cada capítulo. Também em algumas seções foram adicionados links que abrem imediatamente a classe desejada no PhpStorm.

Então começamos a pensar: como fazer com que os idosos estudassem o documento? Afinal, o Início Rápido era enorme e ninguém queria passar duas semanas lendo. Então, fizemos um teste: com base no documento, fizemos cerca de 100 perguntas sobre diferentes tópicos e todos foram convidados a passar anonimamente. Cada desenvolvedor teve a opção de cerca de 40 perguntas. O objetivo não era testar o conhecimento, mas ajudar as pessoas a entender o que não sabiam. Ou seja, o teste era uma ferramenta de aprendizado, não um teste e, se a pergunta não foi respondida corretamente, foram oferecidos avisos e links imediatamente, onde você pode ler sobre isso no Início Rápido.


Um exemplo de pergunta de um teste

Nós não controlamos a passagem do teste pelos iniciantes. Acredita-se que, para eles, essa seja a conclusão lógica para aprender o Início Rápido. Ao mesmo tempo, mantemos estatísticas de todas as respostas. Quando os "idosos" passaram no teste, selecionamos várias perguntas que não respondiam da maneira que gostaríamos e pedimos a caras experientes que escrevessem artigos sobre esses tópicos.

O Início rápido e o teste são a parte mais impressionante do nosso processo de integração.

Mais ingressos

Geralmente, junto com o Início rápido, uma pessoa recebe imediatamente um ou dois tickets simples. Gradualmente, seu número aumenta e o lead garante que os novos tickets correspondam ao que o desenvolvedor conseguiu se familiarizar. Assim, o processo de leitura é diluído com trabalho real, e todos juntos levam cerca de dois meses. Idealmente, no final do período de teste, a pessoa deve ser versada em nossa infraestrutura, ferramentas e abordagens.

Depois de ler o Início rápido, o significado dos tíquetes acima ficará muito mais claro para você:



Como líder, só preciso me dar uma pequena introdução aqui: existe um campo no local e um campo no serviço, eles não são sincronizados para o usuário; Você precisa corrigir o erro e sincronizar. E o iniciante já sabe qual script executar e como fazer isso.

Ou um segundo exemplo:



Aqui está a mesma coisa: a foto acabou no álbum errado, provavelmente o cliente simplesmente enviou o álbum errado; você precisa entender se ainda existem casos assim e corrigi-lo.

Os ingressos, de fato, são simples, por uma hora de trabalho.

4. Projetando um novo recurso

Por “projetar” não quero dizer a organização de classes e código, mas como o iniciante trabalhará com dados, onde ele criará tabelas, quais eventos ele adicionará, onde serão transmitidos, quais serviços uma pessoa acessará. Nesta fase, o iniciante está pronto para tomar decisões técnicas sobre como os recursos são feitos. Isso geralmente é alcançado pela prática. Quanto mais tarefas, mais conhecimento e experiência.

É verdade que isso nem sempre é possível, porque não é possível encontrar um número suficiente de tarefas interessantes para cada iniciante. No teste, esses tópicos costumam ser difíceis de abordar, porque as situações são diferentes. Em diferentes casos, você precisa acessar serviços diferentes e, em qualquer lugar, suas próprias características.

Como resultado, simplesmente coletamos uma dúzia de recursos realmente grandes que envolviam vários serviços, filas, pontos e os desenvolvedores prepararam breves descrições para eles (um análogo da tarefa técnica). Quando o recém-chegado está pronto, o líder oferece a ele uma escolha de uma tarefa. Ele pondera por algum tempo e relata que está pronto para discutir a solução. Está agendada uma reunião com o autor do recurso, no qual o desenvolvedor explica seu esquema: ele o faria, solicitaria tal serviço, armazenaria os dados aqui, assinaria esses eventos. Em resposta, o autor conta como ele fez e para o que chamou atenção. Como resultado, o desenvolvedor aprende muitas coisas novas, ele começa a tirar uma foto geral. Ele entende como esse ou aquele processo funciona, como tomamos decisões. Tudo bem se ele entrou no código com antecedência e espionou como o recurso é implementado, isso é ainda mais provável.

No final da reunião, o líder coleta feedback e pode oferecer ao desenvolvedor o estudo cuidadoso de uma seção e a reflexão sobre o que aprendeu.

5. Trabalho independente

O quinto estágio, de fato, não é expresso de forma alguma. Essas são as coisas que fazemos durante todo o trabalho na empresa. Realmente apreciamos o desejo do desenvolvedor de se comunicar com outras equipes, para descobrir como o que funciona. Se algo não der certo, você precisa saber a quem recorrer para obter ajuda. A tarefa do líder é apresentar o novato a todos, mostrar quem fica onde, dizer quem e em que casos você pode entrar em contato.


Fonte

Uma pessoa deve ser guiada em nossos processos. Embora não tenhamos Scrum e Agile, o fluxo de trabalho é bastante flexível. Nós realmente apreciamos quando um desenvolvedor não apenas segue nossos processos sem pensar, mas entende por que eles são e quais tarefas eles resolvem. Isso permite que, em algumas situações, encontre soluções alternativas. Por exemplo, para entender que um ticket específico pode ser enviado sem a realização de testes completos, e o outro precisa ser feito mais rapidamente. Dizemos com quem entrar em contato e como priorizar para que o ticket funcione hoje.

Esperamos do novo desenvolvedor que, durante o período de teste, ele se familiarize com o conjunto máximo de nossos recursos e componentes. Idealmente, se o período de teste terminar, ele conhecerá algum componente ou recurso com profundidade suficiente para poder acompanhá-lo.

Também adicionamos imediatamente uma pessoa à avaliação de desempenho , para que ela possa receber feedback não apenas de seu líder, mas também de todos com quem ele interage: das equipes de produtos, controle de qualidade e clientes.

Sumário

Aqui estão talvez os cinco principais componentes do nosso processo de comissionamento para iniciantes:

• Atenção mínima para os sem importância. Fazemos tudo para que uma pessoa se concentre no trabalho e não se distraia com pequenas coisas (inclusive) domésticas.
  
• Início rápido.Não ousamos continuar com isso por um longo tempo e pensamos que era impossível fazer isso. Mas acabou sendo mais fácil do que pensávamos, mas já valeu a pena muitas vezes.
  
• Teste. Em termos de proporção entre os benefícios recebidos e o tempo gasto, ele perde um pouco para o Quick Start, mas também é um elemento importante do processo de aprendizado.
  
• Tarefas práticas.
  
• Feedback da equipe e líder. Quanto mais, melhor.
  

Resultados

, . , , , «» .

. . - . , , — .


Fonte

O que vem a seguir

— Quick Start , , . Quick Start.

, . Quick Start , , , , , , . , - . , . , .

Finalmente, lembra-se da primeira foto com vários termos? Você provavelmente pensou: "Por que tanto?" Parece que tudo é muito complicado para nós e o desenvolvedor provavelmente não precisa saber sobre tudo isso. Ao ler o Início rápido, é muito fácil ver coisas que podem ser simplificadas, e estamos trabalhando nessa direção.