O 'Universal' na equipe de desenvolvimento: benefício ou prejuízo?

Olá a todos! Meu nome é Lyudmila Makarova, sou gerente de desenvolvimento na UBRiR e um terço da minha equipe são 'universais'.

Reconheçam: todo Tech Lead sonha com a multifuncionalidade dentro de sua equipe. Afinal, é incrível quando uma pessoa pode substituir três, e ainda fazer isso com qualidade, sem atrasar os prazos. E, o que é mais importante, isso gera economia de recursos!
Parece muito atraente, mas será que é realmente assim? Vamos tentar entender.

Quem é nosso antecipador de expectativas?

O conceito de 'universal' geralmente se refere a membros da equipe que combinam mais de um papel, por exemplo, desenvolvedor-analista.

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

As hard skills são claras, mas as soft skills merecem atenção especial. Elas ajudam a encontrar a abordagem certa para o funcionário e direcioná-lo para a tarefa em que ele será mais útil.

Existem muitos artigos sobre os diversos tipos de personalidades dos representantes da indústria de TI. Baseando-me na minha experiência, eu dividiria os universais de TI em quatro categorias:

1. 'Universal – tudo pode'

Eles estão em todo lugar. Sempre mostram grande atividade, querem estar no centro das atenções, perguntam constantemente aos colegas se precisam de ajuda, às vezes até podem irritar. Eles se interessam apenas por tarefas significativas, cuja participação proporciona liberdade criativa e alimenta seu ego.

Em que são fortes:

• capazes de resolver tarefas complexas;
• mergulham profundamente no problema, 'cavam' e alcançam resultados;
• têm uma mente curiosa.

Mas:

• são emocionalmente instáveis;
• são de gestão difícil;
• têm um ponto de vista inabalável que é muito difícil de mudar;
• é difícil fazê-los realizar tarefas simples. Tarefas fáceis ferem o ego dos poderosos.

2. 'Universal – vou entender e fazer'

Essas pessoas precisam de um manual e um pouco de tempo – e elas resolverão a questão. Geralmente, têm uma ampla experiência como DevOps. Esses universais não se sobrecarregam com planejamento e preferem usar um método de desenvolvimento baseado exclusivamente em sua própria experiência. Podem facilmente entrar em conflito com o tech lead sobre a opção escolhida para implementar a tarefa.

Em que são fortes:

• são independentes;
• são resilientes ao estresse;
• competentes em várias questões;
• eruditos - sempre há algo para conversar com eles.

Mas:

• frequentemente quebram compromissos;
• tendem a complicar tudo: resolvem a tabela de multiplicação por integração por partes;
• a qualidade do trabalho é baixa, tudo é feito em 2-3 tentativas;
• constantemente adiam prazos, pois na verdade tudo acaba sendo mais complicado do que parece.

3. "Universal - tudo bem, deixem que eu faça, já que mais ninguém vai"

O funcionário possui um bom entendimento em várias áreas e tem a experiência correspondente. Mas não consegue se tornar um profissional em nenhuma delas, pois é frequentemente usado como um salva-vidas, tapando buracos nas tarefas atuais. Flexível, obediente, acredita ser requisitado, mas na verdade não o é.

Funcionário praticamente ideal. Provavelmente, tem uma área que prefere, mas devido à falta de clareza nas competências, não há progresso. Como resultado, a pessoa corre o risco de tornar-se obsoleta e emocionalmente esgotada.

Em que são fortes:

• responsáveis;
• orientados para resultados;
• calmos;
• totalmente controlados.

Mas:

• apresentam um desempenho médio devido ao baixo nível de competências;
• não conseguem resolver problemas complexos e abstratos.

4. "Universal - mestre em sua área"

Pessoa com uma sólida formação como desenvolvedor, possui pensamento sistêmico. Meticuloso, exigente consigo e com a equipe. Qualquer tarefa em que participa pode se expandir indefinidamente, se não forem estabelecidos limites.

Bem familiarizado com a arquitetura, escolhe o método de implementação técnica, analisando cuidadosamente o impacto da solução escolhida na arquitetura atual. Humilde, não ambicioso.

Em que são fortes:

• apresentam alta qualidade de trabalho;
• capazes de resolver qualquer tarefa;
• extremamente produtivos.

Mas:

• intolerantes a opiniões diferentes;
• maximalistas. Tentam fazer tudo certo, o que aumenta os prazos de desenvolvimento.

O que temos na prática?

Vamos ver como as funções e competências geralmente se combinam. Tomaremos como ponto de partida uma equipe de desenvolvimento padrão: PO, gerente de desenvolvimento (tech lead), analistas, programadores e testadores. Não consideraremos o proprietário do produto e o tech lead. O primeiro - pela falta de competências técnicas. O segundo, se houver problemas na equipe, deve ser capaz de fazer de tudo.

A opção mais comum de combinação de competências é o desenvolvedor-analista. Também são frequentes o analista-testador e o "três em um".

Usando minha equipe como exemplo, vou mostrar os prós e contras de colegas versáteis. Um terço da minha equipe é assim, e eu os aprecio muito.

A PO enviou uma tarefa urgente para implementar novas tarifas no produto existente. Na minha equipe, há 4 analistas. Naquele momento, um estava de férias, outro adoeceu, e os outros estavam ocupados com a realização de tarefas estratégicas. Se eu os chamasse, isso inevitavelmente atrasaria a execução. A única opção restante foi usar a "arma secreta" – um desenvolvedor-analista versátil, que dominava a área necessária. Vamos chamá-lo de Anatoly.

O tipo de personalidade dele é "versátil – eu vou resolver e fazer". Claro, ele tentou explicar que tinha "um backlog cheio de suas tarefas", mas com a minha decisão firme, ele foi enviado para resolver a tarefa urgente. E Anatoly conseguiu! Ele organizou a tarefa e cumpriu a implementação no prazo, e os clientes ficaram satisfeitos.

À primeira vista, tudo correu bem. Mas, algumas semanas depois, surgiram novas exigências para o aprimoramento desse produto. Agora, um "analista puro" estava encarregado da tarefa. Na fase de teste da nova implementação, demoramos a entender por que estávamos enfrentando erros na vinculação das novas tarifas e, só depois de desvendar todo o emaranhado, chegamos à verdade. Perdemos muito tempo e atrasamos os prazos.

O problema era que muitos pontos ocultos e armadilhas ficaram apenas na mente do nosso versátil e não foram transcritos em papel. Como Anatoly explicou mais tarde, ele estava muito apressado. Mas a opção mais provável é que ele se deparou com problemas durante o desenvolvimento e simplesmente os contornou, sem registrar isso em nenhum lugar.

Houve outra situação. Agora, temos apenas um testador, então algumas tarefas precisam ser testadas pelos analistas, incluindo os versáteis. Por isso, um tarefa eu passei para um suposto Fyodor – "versátil – tudo bem, eu faço, já que não há mais ninguém".
Fyodor é "três em um", mas para essa tarefa já havia um desenvolvedor designado. Portanto, Fyodor tinha que unir apenas os papéis de analista e testador.

Os requisitos foram coletados, a especificação foi enviada para desenvolvimento, e chegou a hora de testar. Fedor conhece o sistema em desenvolvimento "como a palma da sua mão" e trabalhou detalhadamente nas exigências atuais. Por isso, ele não se deu ao trabalho de escrever cenários de teste, mas testou como "o sistema deve funcionar" e depois os entregou aos usuários.
O teste foi concluído, e a melhoria foi enviada para produção. Mais tarde, descobriu-se que o sistema não apenas suspende pagamentos para certas contas de saldo, mas também bloqueia pagamentos de contas internas muito raras que não deveriam estar envolvidas nisso.

Isso ocorreu porque Fedor não fez uma checagem sobre como "o sistema não deve funcionar", não elaborou um plano de teste nem listas de verificação. Ele decidiu economizar tempo e confiou em seu próprio instinto.

Como lidamos com problemas?

Situações como essa afetam a eficiência do trabalho em equipe, a qualidade das versões lançadas e a satisfação dos clientes. Portanto, não podem ser deixadas sem atenção e análise das causas.

1. Para cada tarefa que causou dificuldades, peço que seja preenchido um formulário unificado: um mapa de erros, que permite identificar em que etapa ocorreu a "queda":

2. Após identificar os pontos críticos, realizamos uma brainstorming com cada colaborador afetado pelo problema, perguntando "O que mudar?" (não analisamos casos específicos nas retrospectivas), resultando em ações concretas (cada tipo de personalidade terá suas próprias) com prazos.

3. Estabelecemos regras de interação dentro da equipe. Por exemplo, concordamos em registrar todas as informações sobre o andamento da tarefa no sistema de gerenciamento de projetos. Ao mudar ou identificar artefatos no processo de desenvolvimento, isso deve ser refletido na base de conhecimento e na versão final da documentação de requisitos.

4. O controle começou a ser realizado em cada etapa (com atenção especial às etapas problemáticas do passado) e automaticamente com base nos resultados da tarefa seguinte.

5. Se o resultado da próxima tarefa não mudou, não coloco o universal discutido naquela função em que ele não se sai bem. Tento avaliar sua capacidade e desejo de desenvolver competências nessa função. Se não vejo engajamento, deixo-o na função mais próxima a ele.

Qual foi o resultado?

O processo de desenvolvimento tornou-se mais transparente. O fator BUS diminuiu. Os membros da equipe, ao trabalharem em correções, ficam mais motivados e melhoram sua energia. Estamos gradualmente elevando a qualidade de nossos lançamentos.

Como resultado, obtemos um serviço de "monitoramento como serviço", automatizado na linha de produção de integração contínua. O desenvolvedor ou testador precisa apenas definir a lista de métricas em um arquivo JSON, e tudo o mais acontece automaticamente. Obtemos um controle de qualidade transparente dos lançamentos: todas as notificações sobre desempenho, consumo de recursos ou regressões arquitetônicas.

Os funcionários polivalentes têm seus prós e contras.

Vantagens:

• pode-se encerrar uma tarefa pendente a qualquer momento ou resolver um bug urgente rapidamente;
• abordagem abrangente na resolução de tarefas: o executor analisa a situação sob diversas perspectivas;
• os polivalentes conseguem fazer praticamente tudo de forma igualmente boa.

Desvantagens:

• aumenta o fator BUS;
• as competências essenciais para cada função se diluem. Isso resulta na diminuição da qualidade do trabalho;
• a probabilidade de atrasos aumenta, pois não há controle em cada etapa. Também surgem riscos de 'estrelar': o funcionário se convence de que sabe mais, acreditando ser o especialista;
• aumenta o risco de burnout profissional;
• muitas informações importantes sobre o projeto podem permanecer apenas "na cabeça" do funcionário.

Como podem ver, há mais desvantagens. Por isso, uso polivalentes apenas quando não há recursos suficientes, e a tarefa é urgente. Ou quando a pessoa possui competências que os outros não têm, e a qualidade está em jogo.

Se a regra de distribuição de funções é respeitada ao trabalhar em conjunto na tarefa, a qualidade do trabalho aumenta. Abordamos os problemas de diferentes ângulos, mantendo a mente aberta e constantemente surgindo novas ideias. Ao mesmo tempo, cada membro da equipe tem todas as oportunidades para crescimento profissional e ampliação de suas competências.

Acredito que o mais importante é sentir-se parte do processo, realizar seu trabalho, ampliando gradualmente a gama de suas competências. No entanto, ter polivalentes na equipe traz benefícios: o essencial é garantir que eles consigam combinar diferentes funções de maneira eficaz.

Desejo a todos uma equipe auto-organizada de 'polivalentes mestres de seu ofício'!

Fonte: habr.com