Vou descrevê-lo usando o exemplo do desenvolvedor abstrato Tom. Tom conseguiu um emprego na Internetmagazinzaden como desenvolvedor intermediário de php. A empresa fabrica lojas online de modelos a complexos, com várias integrações. A empresa tem tudo de melhor Agile, SCRUM, stand-ups e retro. O Tom trabalha há 3 meses e está tudo a correr bem para ele, lançou alguns MIs, até funcionam e os clientes estão felizes.
Aí vem uma nova tarefa para o desenvolvimento de IM, mas com integração com CRM. Tom começa com a tarefa de integração e em algum momento ele falha e o prazo se estende por uma semana. Ao mesmo tempo, no rali geral, Tom diz que "entende o problema", esperando que já esteja perto de uma solução. Tom se dirige ao desenvolvedor sênior Mike (que não é seu mentor e não fica muito longe de Tom), ele o direciona para manuais e explica brevemente o que precisa ser feito.
Tom sai para ler os tutoriais e resolver o problema. Alguns dias depois, ele volta para Mike com perguntas sobre integração e eles resolvem juntos.
Tom sai para resolver o problema por alguns dias, depois dos quais ele retorna para Mike novamente e lhe dá a solução final. Mike verifica a atribuição e aponta alguns pequenos bugs que Tom irá corrigir em breve.
Parece ser uma imagem de trabalho, mas há vários pontos que nos mostram que Tom não é mais um desenvolvedor intermediário como pensávamos antes, mas junho.
- Tom passou muito tempo (neste caso, uma semana) lidando com o problema e não sinalizou o problema a tempo.
- Não consegui descobrir sozinho com o tutorial e, em vez de pesquisar no Google alguns momentos incompreensíveis, procurei Mike.
- Tom passou o tempo de outro desenvolvedor em vez de usar stand-ups e discutir seus problemas.
Às vezes, em entrevistas para o cargo de líder de equipe, eles fazem a pergunta "Como você divide os desenvolvedores em juniores, intermediários e seniores?" E minha resposta é mais ou menos assim:
- , ;
- , ;
- - .
No caso de Tom, ele acabou de obter o tutorial e a descrição da implementação de Mike, mas não conseguiu descobrir e voltou para Mike. Isso para mim foi a primeira "chamada" importante de que não somos do meio. A segunda decisão importante foi que a habilidade de “sinalizar um problema” é muito importante para o meio, e se ele não a possui, então em termos de habilidades sociais isso o traz de volta para os juniores. O terceiro "sino" é a atitude descuidada com o tempo de outro desenvolvedor inerente aos Juniors, que às vezes não entendem a importância de seguir o processo e se voltam para o desenvolvedor mais "gentil" em vez de ir para a liderança e conseguir um mentor por meio dele. Isso é importante, porque talvez o desenvolvedor Mike esteja ocupado em um projeto super responsável ou sua tarefa requeira alta concentração, mas o programador John está literalmente sentado na mesa ao lado,que acabou de terminar um projeto e ainda não teve tempo de começar a mergulhar em um novo.
Vamos considerar outro caso. O desenvolvedor sênior Vasya trabalha para a empresa há muito tempo. Vasya tem um líder de equipe, Petya. E aconteceu que Petya é um líder muito atencioso e ele não apenas define uma tarefa, mas trabalha junto com um analista de sistema em cada aspecto dela e só então a dá para funcionar. Vasya e Petya trabalham na empresa há 4 anos e este esquema já está na ordem das coisas. Ao mesmo tempo, Vasya implementa tarefas perfeitamente de acordo com as especificações técnicas escritas, documenta o código e está satisfeito que tudo esteja tão "bom e bom" com ele.
Mas azar, depois de um tempo a empresa fecha e Vasya tem que procurar um emprego e por algum motivo eles começam a qualificar Vasya durante as entrevistas não como um sênior, mas como um intermediário. "Como isso aconteceu? Onde eu caí? " Ele se pergunta.
Tudo é simples novamente, Vasya perdeu a habilidade de encontrar a solução ideal para o problema, em 4 anos o analista de sistema e o líder da equipe de atendimento relaxaram Vasily tanto que essa habilidade não era mais necessária.
O que fazer neste caso? Na maioria das vezes, tendo descoberto isso em uma empresa, você não deve tirar rublos dos desenvolvedores e reduzir seus salários (mesmo que indiretamente), mas ficar intrigado com a pergunta "isso pode ser consertado?" E se a resposta for “não”, então é melhor dizer adeus ao funcionário “gentilmente”, pois em algum momento ele ficará insatisfeito com o fato de seu salário não estar crescendo, e o restante da equipe pode ter problemas com isso. Se a resposta for sim, você precisará de um trabalho cuidadoso do departamento de treinamento de pessoal e do líder da equipe. De fato, neste caso, você terá que aprimorar a habilidade do funcionário e fazê-lo da maneira mais delicada possível para não ferir seu orgulho e dar-lhe motivação para se desenvolver.