“Universal” na equipe de desenvolvimento: benefício ou dano?

Olá a todos! Meu nome é Lyudmila Makarova, sou gerente de desenvolvimento na UBRD e um terço da minha equipe são “generalistas”.

Admita: todo líder técnico sonha com funcionalidade multifuncional em sua equipe. É tão legal quando uma pessoa consegue substituir três, e ainda fazer isso com eficiência, sem atrasar prazos. E, o mais importante, economiza recursos!
Parece muito tentador, mas é mesmo? Vamos tentar descobrir.

Quem é ele, nosso precursor de expectativas?

O termo “generalista” geralmente se refere a membros da equipe que combinam mais de uma função, por exemplo, analista-desenvolvedor.

A interação da equipe e o resultado do seu trabalho dependem das qualidades profissionais e pessoais dos participantes.

Tudo está claro sobre as hard skills, mas as soft skills merecem atenção especial. Eles ajudam a encontrar uma abordagem para um funcionário e a direcioná-lo para a tarefa em que será mais útil.

Existem muitos artigos sobre todos os tipos de personalidade no setor de TI. Com base na minha experiência, eu dividiria os generalistas de TI em quatro categorias:

1. “Universal – Todo-Poderoso”

Eles estão por toda parte. São sempre muito ativos, querem ser o centro das atenções, perguntam constantemente aos colegas se precisam de ajuda e às vezes podem até ser chatos. Eles estão interessados ​​​​apenas em tarefas significativas, cuja participação dará espaço à criatividade e poderá divertir seu orgulho.

Em que eles são fortes:

• são capazes de resolver problemas complexos;
• mergulhar profundamente no problema, “cavar” e alcançar resultados;
• tenha uma mente curiosa.

Mas:

• emocionalmente lábil;
• mal administrado;
• têm um ponto de vista próprio e inabalável, que é muito difícil de mudar;
• É difícil conseguir que alguém faça uma coisa simples. Tarefas fáceis ferem o ego do todo-poderoso.

2. “Universal – vou descobrir e fazer”

Essas pessoas só precisam de um manual e de um pouco de tempo - e resolverão o problema. Eles geralmente têm uma sólida experiência em DevOps. Esses generalistas não se preocupam com design e preferem usar um método de desenvolvimento baseado apenas em sua experiência. Eles podem facilmente discutir com o líder técnico sobre a opção escolhida para implementar a tarefa.

Em que eles são fortes:

• independente;
• Resistência ao estresse;
• competente em muitas questões;
• erudito - sempre há o que conversar com eles.

Mas:

• muitas vezes violam obrigações;
• tendem a complicar tudo: resolver a tabuada integrando por partes;
• a qualidade do trabalho é baixa, tudo funciona 2 a 3 vezes;
• Eles mudam constantemente os prazos, porque na realidade nem tudo é tão simples.

3. “Universal – ok, deixa eu fazer isso, já que não tem mais ninguém”

O funcionário é versado em diversas áreas e possui experiência relevante. Mas ele não consegue se profissionalizar em nenhuma delas, porque muitas vezes é usado como tábua de salvação, tapando lacunas nas tarefas atuais. Flexível, eficiente, considera-se requisitado, mas não é.

Um funcionário prático ideal. Muito provavelmente ele tem um rumo que mais gosta, mas devido à indefinição de competências, o desenvolvimento não ocorre. Como resultado, uma pessoa corre o risco de não ser reclamada e ficar emocionalmente esgotada.

Em que eles são fortes:

• responsável;
• orientado para resultados;
• calma;
• completamente controlado.

Mas:

• apresentam resultados médios devido ao baixo nível de competências;
• não consegue resolver problemas complexos e abstratos.

4. “Um versátil é um mestre em seu ofício”

Uma pessoa com experiência séria como desenvolvedor tem pensamento sistêmico. Pedante, exigente consigo mesmo e com sua equipe. Qualquer tarefa que o envolva pode crescer indefinidamente se os limites não forem definidos.

Ele conhece bem a arquitetura, seleciona um método de implementação técnica, analisando cuidadosamente o impacto da solução escolhida na arquitetura atual. Modesto, não ambicioso.

Em que eles são fortes:

• mostrar trabalho de alta qualidade;
• capaz de resolver qualquer problema;
• muito eficiente.

Mas:

• intolerante com as opiniões dos outros;
• maximalistas. Eles tentam fazer tudo certo e isso aumenta o tempo de desenvolvimento.

O que temos na prática?

Vamos ver como as funções e competências são combinadas com mais frequência. Vamos tomar como ponto de partida uma equipe de desenvolvimento padrão: PO, gerente de desenvolvimento (líder técnico), analistas, programadores, testadores. Não consideraremos o proprietário do produto e o líder técnico. A primeira é devido à falta de competências técnicas. O segundo, caso haja problemas na equipe, deverá ter condições de fazer tudo.

A opção mais comum para combinar/mesclar/combinar competências é analista-desenvolvedor. Analista de testes e “três em um” também são muito comuns.

Usando minha equipe como exemplo, mostrarei os prós e os contras de meus colegas generalistas. Há um terço deles na minha equipe e eu os amo muito.

PO recebeu uma tarefa urgente para introduzir novas tarifas num produto existente. Minha equipe conta com 4 analistas. Naquela época, um estava de férias, o outro estava doente e os demais estavam empenhados na execução de tarefas estratégicas. Se eu os retirasse, isso iria inevitavelmente perturbar os prazos de implementação. Só havia uma saída: usar a “arma secreta” - um analista-desenvolvedor versátil que dominasse a área temática exigida. Vamos chamá-lo de Anatoly.

Seu tipo de personalidade é “universal – vou descobrir e fazer”. É claro que ele tentou por muito tempo explicar que “tem um acúmulo completo de tarefas”, mas por minha decisão obstinada ele foi enviado para resolver um problema urgente. E Anatoly conseguiu! Ele realizou a preparação e concluiu a implementação no prazo, e os clientes ficaram satisfeitos.

À primeira vista, tudo deu certo. Mas depois de algumas semanas, surgiram novamente requisitos de melhoria para este produto. Ora, a formulação deste problema foi realizada por um analista “puro”. Na fase de testes do novo empreendimento, durante muito tempo não conseguimos compreender porque é que cometíamos erros na vinculação das novas tarifas, e só então, depois de desvendado todo o emaranhado, chegámos ao fundo da verdade. Perdemos muito tempo e perdemos prazos.

O problema é que muitos momentos ocultos e armadilhas permaneceram apenas na cabeça da nossa perua e não foram transferidos para o papel. Como Anatoly explicou mais tarde, ele estava com muita pressa. Mas a opção mais provável é que ele já tenha encontrado problemas durante o desenvolvimento e simplesmente os contornou, sem refletir isso em lugar nenhum.

Houve outra situação. Agora temos apenas um testador, então algumas tarefas precisam ser testadas por analistas, inclusive generalistas. Portanto, dei uma tarefa ao Fedor condicional - “universal – ok, deixe-me fazer isso, já que não há mais ninguém”.
O Fedor é um “três em um”, mas já foi alocado um desenvolvedor para essa tarefa. Isso significa que Fedya teve que combinar apenas um analista e um testador.

Os requisitos foram coletados, a especificação foi submetida ao desenvolvimento, é hora de testar. Fedor conhece o sistema que está sendo modificado “como a palma da sua mão” e elaborou minuciosamente os requisitos atuais. Portanto, ele não se preocupou em escrever scripts de teste, mas realizou testes sobre “como o sistema deveria funcionar” e depois os repassou aos usuários.
O teste foi concluído, a revisão foi para produção. Mais tarde descobriu-se que o sistema não só suspendeu pagamentos para certas contas de saldo, mas também bloqueou pagamentos de contas internas muito raras que não deveriam participar neste processo.

Isso aconteceu porque Fedor não verificou como “o sistema não deveria funcionar”, não elaborou plano de testes ou checklists. Ele decidiu economizar tempo e confiar em seus próprios instintos.

Como lidamos com os problemas?

Situações como essas impactam o desempenho da equipe, a qualidade do lançamento e a satisfação do cliente. Portanto, não podem ficar sem atenção e análise dos motivos.

1. Para cada tarefa que causou dificuldades, peço que preencham um formulário unificado: um mapa de erros, que permite identificar a fase em que ocorreu o “rebaixamento”:

2. Após a identificação dos gargalos, é realizado um brainstorming com cada funcionário que influenciou o problema: “O que mudar?” (não consideramos casos especiais retrospectivamente), a partir dos quais nascem ações específicas (específicas para cada tipo de personalidade) com prazos.

3. Introduzimos regras para interação dentro da equipe. Por exemplo, concordamos em registrar necessariamente todas as informações sobre o andamento de uma tarefa no sistema de gerenciamento de projetos. Quando os artefactos são alterados/identificados durante o processo de desenvolvimento, isso deve ser refletido na base de conhecimento e na versão final das especificações técnicas.

4. O controle passou a ser realizado em cada etapa (é dada especial atenção às etapas problemáticas do passado) e automaticamente com base nos resultados da próxima tarefa.

5. Se o resultado da próxima tarefa não mudou, então não coloco o generalista em questão na função que ele desempenha mal. Procuro avaliar sua capacidade e desejo de desenvolver competências nesta função. Se não encontro resposta, deixo-o no papel que lhe é mais próximo.

O que aconteceu no final?

O processo de desenvolvimento tornou-se mais transparente. O fator BUS diminuiu. Os membros da equipe, trabalhando nos erros, ficam mais motivados e melhoram seu carma. Estamos melhorando gradativamente a qualidade de nossos lançamentos.

Descobertas

Funcionários generalistas têm seus prós e contras.

Apresenta:

• você pode encerrar uma tarefa pendente a qualquer momento ou resolver um bug urgente em pouco tempo;
• uma abordagem integrada para resolver um problema: o executor olha para ele do ponto de vista de todas as funções;
• os generalistas podem fazer quase tudo igualmente bem.

Desvantagens:

• O fator BUS aumenta;
• as competências essenciais inerentes à função são desgastadas. Por conta disso, a qualidade do trabalho diminui;
• a probabilidade de uma mudança nos prazos aumenta, porque não há controle em cada estágio. Também existem riscos de se tornar uma “estrela”: o funcionário tem certeza de que sabe melhor que é um profissional;
• aumenta o risco de esgotamento profissional;
• muitas informações importantes sobre o projeto podem ficar apenas “na cabeça” do funcionário.

Como você pode ver, existem mais deficiências. Portanto, só uso generalistas se não houver recursos suficientes e a tarefa for bastante urgente. Ou uma pessoa tem competências que faltam aos outros, mas a qualidade está em jogo.

Se a regra de distribuição de funções for observada no trabalho conjunto em uma tarefa, a qualidade do trabalho aumenta. Vemos os problemas de diferentes ângulos, nossa visão não é turva, novos pensamentos sempre aparecem. Ao mesmo tempo, cada integrante da equipe tem todas as oportunidades de crescimento profissional e ampliação de suas competências.

Acredito que o mais importante é se sentir envolvido no processo, fazer o seu trabalho, aumentando gradativamente a amplitude das suas competências. No entanto, os generalistas numa equipa trazem benefícios: o principal é garantir que combinam eficazmente diferentes funções.

Desejo a todos uma equipe auto-organizada de “mestres universais em seu ofício”!

Fonte: habr.com