Olá pessoal! Meu nome é Lyudmila Makarova, sou gerente de desenvolvimento da UBRD e um terço da minha equipe é universal.
Reconhecer: Todo líder técnico sonha com uma funcionalidade cruzada dentro de sua equipe. Afinal, é tão legal quando uma pessoa é capaz de substituir três, e até mesmo fazê-lo qualitativamente, sem mudar o prazo. E, mais importante, economiza recursos!
Parece muito tentador, mas é realmente assim? Vamos tentar descobrir.
Quem é ele, nosso antecipador de expectativas?
O termo "generalista" geralmente é entendido como membros da equipe que combinam mais de uma função, por exemplo, analista de desenvolvimento.
A interação da equipe e o resultado de seu trabalho dependem das qualidades profissionais e pessoais dos participantes.
Por habilidades difíceis, tudo fica claro, mas habilidades pessoais merecem atenção especial. Eles ajudam a encontrar uma abordagem para um funcionário e direcionam-no precisamente para a tarefa em que ele será mais útil.
Existem muitos artigos sobre todos os tipos de tipos de personalidade de representantes do setor de TI. Com base na minha experiência, eu dividiria os universais de TI em quatro categorias:
1. "Universal - Todo Poderoso"
Existem tais em toda parte. Eles sempre mostram grande atividade, querem estar no centro das atenções, perguntam constantemente a seus colegas se é necessária sua ajuda, às vezes até irritante. Eles estão interessados apenas em tarefas significativas, cuja participação dará espaço à criatividade e poderá divertir o orgulho.
O que são fortes:
- capaz de resolver problemas complexos;
- profundamente imerso no problema, "cavando" e alcançar o resultado;
- possui uma mente inquisitiva.
Mas:
- emocionalmente lábil;
- mal administrado;
- ter seu próprio ponto de vista inabalável, que é muito difícil de mudar;
- difícil fazer uma coisa simples. Tarefas fáceis prejudicam a onipotência do orgulho.
2. "Carrinha - eu vou descobrir e fazer"
Essas pessoas têm manual suficiente e um pouco de tempo - e resolverão o problema. Geralmente, eles têm um grande background por trás deles como DevOps. Tais generalistas não se preocupam com o design e preferem usar o método de desenvolvimento apenas com base em sua própria experiência. Eles podem facilmente fazer um lanche com o techlide sobre a opção escolhida para implementar a tarefa.
O que são fortes:
- independente;
- resistente ao estresse;
- competente em muitos assuntos;
- erudito - sempre há algo para conversar com eles.
Mas:
- muitas vezes violam obrigações;
- tendem a complicar as coisas: eles resolvem a tabuada de multiplicação integrando em partes;
- a qualidade do trabalho é baixa, tudo acontece 2-3 vezes;
- eles estão mudando constantemente os prazos, porque, na realidade, tudo acaba não sendo tão simples.
3. "Universal - tudo bem, deixe-me, já que não há mais ninguém"
O funcionário é bem versado em várias áreas e possui experiência relevante. Mas ele não consegue se tornar um profissional em nenhum deles, porque costuma ser usado como bóia salva-vidas, abrindo buracos para as tarefas atuais. Maleável, eficiente, se considera uma demanda, mas não é.
Funcionário ideal prático. Provavelmente, ele tem uma direção de que gosta mais, mas devido ao embaçamento de competências, o desenvolvimento não ocorre. Como resultado, uma pessoa corre o risco de se tornar não reclamada e emocionalmente esgotada.
O que são fortes:
- são responsáveis;
- focado no resultado;
- calma;
- totalmente controlado.
Mas:
- mostrar um resultado médio devido a um baixo nível de competências;
- não pode resolver problemas complexos e abstratos.
4. “Universal é um mestre de seu ofício”
Uma pessoa com um histórico sério de desenvolvedor tem um pensamento sistêmico. Pedante, exigente de si e da equipe. Qualquer tarefa com a participação dele pode crescer até o infinito, se você não definir limites.
Ele conhece bem a arquitetura, escolhe o método de implementação técnica, analisando cuidadosamente a influência da solução escolhida na arquitetura atual. Modesto, não ambicioso.
O que 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 papéis e competências são combinados com mais frequência. Como ponto de partida, tomemos a equipe de desenvolvimento padrão: PO, gerente de desenvolvimento (especialista técnico), analistas, programadores, testadores. Não consideraremos o proprietário do produto e o líder técnico. O primeiro - devido à falta de competências técnicas. Segundo, se houver problemas na equipe, ele deve ser capaz de fazer tudo.
A opção mais comum para combinar / mesclar / combinar competências é um desenvolvedor analítico. Além disso, um analista de testes e um três em um são muito comuns.
Pelo exemplo da minha equipe, mostrarei os prós e os contras de outros universalistas. Há um terço deles na minha equipe e eu os amo muito.
A PO recebeu uma tarefa urgente de introduzir novas tarifas em um produto existente. Minha equipe tem 4 analistas. Naquela época, um estava de férias, o outro ficou doente e o restante estava envolvido na implementação de tarefas estratégicas. Se eu os retirasse, isso inevitavelmente interromperia os prazos de implementação. Havia apenas uma saída: usar a "arma secreta" - o universal do analista desenvolvedor, que possuía a área de assunto necessária. Vamos chamá-lo de Anatoly.
O tipo de personalidade dele é
"vagão - eu vou descobrir
e fazê-lo" . Obviamente, ele tentou por um longo tempo explicar que tinha "uma lista completa de tarefas", mas, por minha decisão voluntária, ele foi enviado para resolver uma tarefa urgente. E Anatoly fez isso! Ele organizou e concluiu a implementação no prazo, e os clientes ficaram satisfeitos.
À primeira vista, tudo deu certo. Porém, após algumas semanas, os requisitos para revisão surgiram novamente neste produto. Agora, a configuração dessa tarefa foi tratada por um analista "puro". Na fase de testes do novo empreendimento, por um longo tempo não conseguimos entender por que tivemos erros ao vincular novas tarifas e só então, depois de desenrolar todo o emaranhado, chegamos ao fundo da verdade. Passamos muito tempo e perdemos os prazos.
O problema era que muitos momentos ocultos e armadilhas permaneciam apenas na cabeça de nossa caminhonete e não eram transferidos para o papel. Como Anatoly mais tarde explicou, ele estava com pressa. Mas a opção mais provável é que ele se deparou com problemas já em desenvolvimento e simplesmente os contornou, sem refletir em nenhum lugar.
Houve outra situação. Agora, temos apenas um testador; portanto, algumas tarefas que os analistas precisam testar, incluindo generalistas. Por isso, dei uma tarefa ao Fedor condicional -
“universal - tudo bem, deixe-me, já que não há mais ninguém” .
Fedor - “três em um”, mas o desenvolvedor já foi escolhido para esta tarefa. Portanto, Feda precisava combinar apenas um analista e um testador.
Os requisitos são coletados, a especificação é entregue ao desenvolvimento, é hora de testar. Fedor conhece o sistema em desenvolvimento "como as costas da mão" e elaborou minuciosamente os requisitos atuais. Portanto, ele não se incomodou em escrever scripts de teste, mas testou “como o sistema deveria funcionar” e depois o repassou aos usuários.
O teste foi concluído, a revisão foi para o baile. Mais tarde, descobriu-se que o sistema não apenas suspende pagamentos para determinadas contas de saldo, mas também bloqueia pagamentos de contas internas muito raras que não deveriam estar envolvidas nisso.
Isso ocorreu devido ao fato de o Fedor não ter verificado o funcionamento do sistema, não elaborou um plano de teste, nem as listas de verificação. Ele decidiu economizar tempo e confiou em seu próprio instinto.
Como trabalhamos com problemas?
Tais situações afetam a eficácia da equipe, a qualidade dos lançamentos e a satisfação do cliente. Portanto, eles não podem ser ignorados e análise dos motivos.
1. Para cada problema que causou dificuldades, solicito que você preencha um formulário unificado: um mapa de erros que permita identificar o estágio em que ocorreu o "rebaixamento":
2. Após identificar gargalos, com cada funcionário que influenciou o problema, uma sessão de brainstorming “O que mudar?” (não consideramos casos especiais em retrô), como resultado de ações específicas (para cada tipo de personalidade) nascem com prazos.
3. Introduzimos as regras de interação dentro da equipe. Por exemplo, concordamos em registrar necessariamente todas as informações sobre o andamento da tarefa no sistema de gerenciamento de projetos. Ao alterar / identificar artefatos durante o processo de desenvolvimento, é necessário exibi-lo na base de conhecimento e na versão final do TOR.
4. O controle começou a ser realizado em cada estágio (atenção especial é dada aos estágios problemáticos no passado) e automaticamente com base nos resultados da próxima tarefa.
5. Se o resultado da próxima tarefa não mudou, não coloco o vagão em questão no papel com que ele lida mal. Tento avaliar sua capacidade e desejo de desenvolver competências nesse papel. Se eu não encontrar uma resposta, deixo-o no papel que está mais próximo dele.
Qual é o resultado?
O processo de desenvolvimento tornou-se mais transparente. O fator BUS diminuiu. Os membros da equipe, trabalhando nos erros, ficam mais motivados, melhoram seu carma. Estamos melhorando gradualmente a qualidade de nossos lançamentos.
Conclusões
Os funcionários da Universal têm seus prós e contras.
Vantagens:- Você pode fechar a tarefa de flacidez a qualquer momento ou resolver um bug urgente em pouco tempo;
- uma abordagem integrada para resolver o problema: o artista olha para o lado de todas as funções;
- generalistas podem fazer quase tudo igualmente bem.
Desvantagens:- O fator BUS está crescendo;
- as competências essenciais inerentes ao papel são corroídas. Por isso, a qualidade do trabalho é reduzida;
- a probabilidade de uma mudança nos termos aumenta, porque não há controle em cada estágio. Também há riscos de crescer 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 só podem permanecer “na cabeça” do funcionário.
Como você pode ver, há mais falhas. Portanto, eu uso universais apenas se não houver recursos suficientes e a tarefa é urgente o suficiente. Ou uma pessoa tem competências que outras não têm e a qualidade está em risco.
Se no trabalho conjunto de uma tarefa a regra de distribuição de papéis é observada, a qualidade do trabalho aumenta. Observamos problemas de diferentes ângulos, nossos olhos não ficam borrados, sempre aparecem novos pensamentos. Além disso, cada membro da equipe tem todas as oportunidades de crescimento profissional e expansão de suas competências.
Acredito que o mais importante é se sentir envolvido no processo, se engajar no seu trabalho, aumentando gradualmente a amplitude de suas competências. No entanto, os vagões de uma equipe são benéficos: o principal é garantir que eles efetivamente combinem diferentes papéis.
Desejo a todos uma equipe auto-organizada de "mestres universais de seu ofício"!