Olá. Meu nome é Aleksandr Guzenko, sou o líder de três equipes de desenvolvimento front-end em uma grande empresa. Recentemente, um dos funcionários veio até mim e disse: “Quero crescer e me tornar líder de equipe. Por onde começo?" Foi assim que nasceu a ideia deste artigo, que prometi enviar-lhe mais tarde como guia.
Neste artigo, contarei como me tornei líder de equipe, quais habilidades você não pode prescindir nesta posição e como melhorar suas habilidades de gerenciamento de equipe se você for um desenvolvedor “comum”.
Comecemos pela teoria, sem a qual será difícil entender por que você passou a gerenciar o desenvolvimento, mas em vez disso contou o orçamento do projeto.
No sentido clássico, um líder de equipe é o chefe de uma equipe de desenvolvimento. Isto é verdade, mas com algumas reservas.
No cenário atual, os líderes de equipe vão além dos programadores e incluem designers, analistas, testadores, especialistas em SEO e vários profissionais de TI e não-TI. Portanto, é mais preciso definir um líder de equipe como o líder de um grupo de funcionários que compartilham a mesma função, embora eu me concentre especificamente nos desenvolvedores.
Em segundo lugar, o líder da equipa não é apenas um líder de equipa, mas o principal elo entre os colaboradores e a gestão. Esta é uma adição importante e tentarei explicar o porquê a seguir.
Em terceiro lugar, para compreender a responsabilidade do líder da equipa, é importante distinguir entre função e posição.
O papel do líder da equipe envolve principalmente tarefas gerenciais:
Na sua forma pura, a função raramente é encontrada, mesmo que a lista de responsabilidades no site de recrutamento indique o contrário.
A posição de líder de equipe pode combinar várias funções ao mesmo tempo: líder de equipe, líder técnico e desenvolvedor líder. Nessa posição, muitas vezes o próprio especialista escreve o código, gerencia o trabalho da equipe e é responsável pela parte técnica:
É muito mais conveniente para os negócios quando o líder da equipe e o líder técnico são uma só pessoa. Na prática, mesmo em grandes empresas, o cargo de líder de equipe envolve uma combinação das três funções em proporções diferentes. Portanto, as ideias sobre o que um líder de equipe faz geralmente diferem.
Se você perguntar a desenvolvedores de empresas diferentes quais são as responsabilidades de um líder de equipe, as respostas provavelmente serão diferentes. Haverá uma gama semelhante de opiniões entre os próprios líderes da equipe. Para verificar isso, basta acessar qualquer site de busca de empregos e consultar a lista de responsabilidades nas diferentes vagas.
Para liderar uma equipe de desenvolvimento, você precisa de sérias competências e experiência. Portanto, a forma mais comum e correta de se tornar um líder de equipe é primeiro ascender ao nível sênior e só depois almejar uma posição de liderança. Mas isso nem sempre acontece.
Se a equipe for composta apenas por programadores intermediários e entre eles houver um funcionário de iniciativa que esteja atento a todos os assuntos e apoie o projeto, ele será um excelente líder de equipe. Sim, ele tem menos habilidades técnicas que o sênior, mas se não houver ninguém superior na equipe, suas competências serão suficientes.
Ao mesmo tempo, nem todos os seniores considerarão o cargo de líder de equipa um plano de carreira adequado. Trabalhar em uma posição de liderança deve ser realmente interessante, caso contrário você pode definhar com a quantidade de carga de trabalho gerencial.
Resposta curta: experimente. Diga ao seu gerente que você deseja assumir responsabilidades adicionais gratuitamente e veja o que acontece. Este é um esquema em que todos ganham, por isso a administração geralmente está disposta a cooperar.
O líder da equipe vence : alguém faz o trabalho por ele.
O negócio ganha : o trabalho é feito, mas você não precisa pagar por isso.
O estagiário líder de equipe também tem uma vantagem : depois de trabalhar nessa modalidade por vários meses a um ano, ele pode entender por si mesmo se tem sucesso e se gosta de liderar. E se a resposta para cada ponto for “sim”, você pode pensar seriamente em crescer nessa direção.
Existem apenas duas opções. A primeira é deixar todos os outros desenvolvedores da empresa de fora e se tornar o líder da equipe como o funcionário “mais velho”. No entanto, existe o risco de a palavra “velho” não ter de ser colocada entre aspas. A segunda opção é você mesmo tomar a iniciativa.
Vou te contar como foi para mim. De acordo com meu diploma, minha profissão é gestor, e estudei programação por conta própria paralelamente aos meus estudos na universidade. Então decidi me tornar líder de equipe de desenvolvimento antes mesmo de conseguir meu primeiro emprego como programador.
No início, trabalhei em pequenas empresas. Levei dois anos para pegar o jeito e passar de júnior a um forte jogador intermediário. Sem experiência em programação, você não será capaz de se tornar um bom líder de equipe: você precisa entender como funciona o processo de desenvolvimento e quais erros e armadilhas existem.
Alguns anos depois, comecei a trabalhar em uma grande empresa e imediatamente indiquei que queria ser líder de equipe. Nas grandes empresas, uma vez a cada seis meses ou um ano, costumam realizar uma avaliação de desempenho, quando o gestor se reúne com o funcionário e juntos constroem um plano de desenvolvimento individual para o futuro próximo. Em cada uma dessas reuniões, eu disse que queria me tornar um líder de equipe. Na primeira vez me disseram: “Está tudo ótimo, mas primeiro ganhe experiência”. Criamos um plano de desenvolvimento para que eu pudesse ganhar experiência de liderança.
Durante cerca de seis meses, juntamente com o meu líder de equipa, avaliei e decompus as tarefas e tentei distribuí-las entre os colaboradores. Quando a qualidade do nosso trabalho ficou mais ou menos igual, a empresa acabou de formar uma nova equipe de desenvolvimento front-end, que eu chefiei. Nas grandes empresas, você não precisa esperar muito.
Dizem que existem dois marcos importantes no desenvolvimento de um líder de equipe: o primeiro é de dois a seis funcionários e o segundo é de 7 ou mais. No início eu tinha apenas um funcionário e agora lidero três equipes de desenvolvimento front-end – 12 funcionários.
Simplesmente mostrei iniciativa, compareci à gestão e, assim que surgiu a oportunidade, fui nomeado líder da equipe.
Os líderes de equipe são frequentemente criados dentro da empresa e é importante levar isso em consideração. Se houver perspectivas de crescimento em seu trabalho atual, você deve tomar a iniciativa e tentar assumir o papel de gestor. Mas se toda a equipe for front-end e back-end e cada um for seu próprio líder de equipe, você não deve esperar um milagre. É melhor mudar para uma empresa maior e indicar que no futuro deseja assumir uma posição de liderança. Você precisará de tempo para estudar os processos e compreender a lógica de negócios do projeto. Mas quando uma posição adequada for aberta na empresa, eles provavelmente escolherão você em vez de alguém de fora.
Na posição de líder de equipe, tanto as habilidades básicas quanto as sociais são igualmente importantes. Os desenvolvedores geralmente sabem o que falta nas habilidades básicas. Além disso, estes requisitos estão fortemente ligados à especialização e à pilha de tecnologia, pelo que não existe uma lista universal. Falarei sobre soft skills que considero críticas para o produto e para a empresa.
A velocidade e a qualidade do desenvolvimento e, portanto, o custo, dependem dos processos da empresa, mas raramente são ideais.
Por exemplo, você corrigiu um bug e está pronto para levar a construção para o estande, o negócio está esperando. Mas para fazer isso, você precisa passar por cinco pipelines e obter aprovações de todos os envolvidos. Você escreve para os responsáveis - silêncio. Você começa a puxá-los, mas chegam mensagens formais só para responder – todo mundo não tem tempo. Pode levar até seis horas para que a versão corrigida chegue ao estande. E todo esse tempo que você gasta tentando entrar em contato com seus colegas, e a empresa perde dinheiro.
Outro exemplo é o número exorbitante de acessos a diferentes sistemas, programas, estandes e repositórios. Os bancos geralmente sofrem com isso. A pessoa vem trabalhar, precisa entender o projeto, mas no primeiro mês e meio ela não consegue fazer nada, porque - isso mesmo - não tem acesso. Outro problema dos acessos é que são muitos e é impossível lembrar seus nomes. Por exemplo, em vez de “acesso ao repositório” no diretório haverá A32B18KZ - tente encontrá-lo.
Conheço casos reais em que um desenvolvedor não conseguiu começar a trabalhar por um ou dois meses. Durante todo esse tempo ele recebeu um salário, mas se desiludiu e desistiu. Ou seja, a empresa passou seis meses procurando um funcionário, pagou-lhe salário durante dois meses e depois teve que recomeçar o processo de recrutamento.
Tais problemas nos processos complicam e retardam o trabalho. A tarefa do líder da equipe é vê-los e entender exatamente o que está funcionando mal e onde ocorre a falha.
É importante não apenas ver os problemas nos processos, mas oferecer soluções. Você pode lidar com algumas dificuldades sozinho, sem envolver o gerenciamento. Por exemplo, uma equipe está enfrentando dificuldades com um gestor estadual inconveniente. Se o projeto for pequeno ou estiver apenas no início, você pode marcar uma ligação, encontrar a melhor opção e traçar como introduzir gradativamente um novo gestor estadual sem perdas. Foi encontrada uma solução e a empresa nem sabia da existência do problema.
Mas a maioria dos problemas só pode ser resolvida com a ajuda da alta administração. Por exemplo, para agilizar a liberação das construções no estande, você pode identificar uma pessoa que tenha boas conexões em todos os departamentos e tenha acesso aos tomadores de decisão, e envolvê-la no processo de aprovação. Se não houver feedback de colegas de outros departamentos, ele sabe para quem escrever e pode configurar o processo manualmente. Mas esse trabalho requer uma posição separada, por isso é necessário obter a aprovação da administração da empresa.
O problema de acesso é resolvido de forma semelhante. A maioria dos desenvolvedores precisa dos mesmos sistemas e programas. Por exemplo, para desenvolvedores front-end - repositório, estande, Jira, etc. Então por que não fazer um pacote de acesso padrão para eles e contratar uma pessoa que irá solicitá-los por um pequeno salário? Mas isto também requer a vontade da gestão de topo da empresa.
Portanto, uma das principais competências de um líder de equipe é conseguir transmitir corretamente a essência do problema ao negócio. Existem alguns segredos aqui.
Uma vez não é suficiente . Os problemas raramente são resolvidos após o primeiro contato, por isso é preciso ir até a gestão em determinados intervalos e lembrá-la do problema: “isso está desmoralizando a equipe”, “estamos perdendo produtividade”.
Se você perceber como os problemas da equipe e os interesses comerciais estão conectados, acerte este ponto . Por exemplo, houve um bug crítico que levou dois dias para ser corrigido, embora houvesse apenas algumas horas de trabalho envolvidas e, como resultado, a empresa perdeu dinheiro. Você vai até a gerência e fala sobre o problema de coordenação de construções. Nesses momentos, as empresas estão tão abertas quanto possível a sugestões. Mas a solução já deve estar pronta.
O caminho mais seguro é calcular quanto o problema está custando à empresa antes de levá-lo à gestão.
Como líder de equipe de front-end, coleto regularmente feedback dos funcionários. Por exemplo, os desenvolvedores reclamam constantemente que as tarefas são mal descritas. Por causa disso, leva muito tempo para descobrir o que o autor do problema queria deles. Em seguida, os testadores vão até os desenvolvedores e tentam entender o que foi feito e o que exatamente eles precisam testar, e mais adiante na cadeia. Como resultado, cada um ainda entende a essência à sua maneira e aparecem bugs.
Calculei que em média a equipe gasta 40% do seu tempo de trabalho corrigindo bugs. Juntamente com a equipe, realizamos uma análise retrospectiva e descobrimos que metade desses bugs surgiram apenas porque não compreenderam a essência do problema. Ou seja, 20% do tempo de trabalho dos desenvolvedores é desperdiçado porque as tarefas são mal descritas. Este é o número com o qual você deve ir à gerência. É fácil convertê-lo em dinheiro – a mesma linguagem que as empresas entendem.
Quando as pessoas gostam de trabalhar umas com as outras, qualquer interação é mais tranquila. Por que o Scrum é tão popular? Não se trata de documentação, mas de pessoas. Às vezes é mais eficaz ligar para um colega por dois minutos do que esperar dois dias para que ele documente sua resposta e descreva tudo detalhadamente. Assim, quando existe um clima de compreensão mútua e assistência mútua dentro da equipe, é mais fácil o contato entre as pessoas. Por exemplo, você encontrou um trecho de código e não entende o que ele faz. Se a situação na equipe não for boa, você simplesmente terá medo de ligar e perguntar - “ele vai me achar estúpido”.
Para manter bons relacionamentos dentro da equipe, faço ligações de uma hora uma vez por semana. Dividimos esse tempo em três partes. O primeiro é “relaxado”. Compartilhamos memes e piadas. A segunda parte é uma discussão de problemas. Às vezes jogamos cartas no Miro, o que não agrada a todos. É assim que consigo ter uma ideia do que exatamente está atrasando os caras. Depois poderemos apresentar opções de soluções, que depois pressionarei junto à administração. E terminamos “descontraídos” novamente: podemos discutir filmes ou qualquer outra coisa. Tais reuniões criam um clima positivo e me fazem, como líder, entender quais são as dores da equipe.
Um erro comum dos novos líderes de equipe é focar os processos de trabalho neles mesmos. Nesse caso, se o líder da equipe adoecer repentinamente ou sair de férias, o trabalho começará a estagnar e ele será constantemente puxado. Para evitar que isso aconteça, você pode ensinar alguém da equipe a desempenhar parte das responsabilidades do líder da equipe. Por exemplo, confie em outras pessoas para distribuir tarefas uma vez por mês. Dessa forma, outra pessoa da equipe terá essa habilidade, e o líder da equipe poderá sair de férias com tranquilidade, sabendo que nada vai quebrar sem ele.
Talvez esse seja um bom critério para avaliar o trabalho de um líder de equipe: se você for afastado da equipe, a margem de segurança deve ser suficiente para um mês.
No desenvolvimento, uma métrica como o fator barramento é usada para gerenciar riscos em um projeto. Mostra quantos membros da equipe devem ser atropelados por um ônibus fictício para derrubar todo o projeto. Se o fator de barramento = 1, você terá sérios problemas.
Por exemplo, estamos desenvolvendo um projeto complexo. Possui um módulo sofisticado e apenas um desenvolvedor sabe como funciona e como lidar com ele. Caso essa pessoa adoeça, desista ou saia de férias, a troca deste módulo se tornará um procedimento muito longo e caro, o que afetará negativamente todo o projeto. Para evitar que isso aconteça, é necessário ensinar gradativamente outros funcionários a trabalhar com módulos ou bibliotecas complexas.
O líder da equipe deve ser capaz de distribuir corretamente as responsabilidades dentro da equipe, sem confinar os processos a uma pessoa, sem torná-la crítica para o projeto.
O líder da equipe deve entender para onde o projeto está indo, quais problemas ele apresenta e como resolvê-los. Por exemplo, a carga horária total da equipe é de 100 horas semanais. E a empresa cumpre seus desejos por todas as 100 horas. Neste momento, a dívida técnica está se acumulando no projeto, o que também é hora de resolver. A tarefa do líder da equipe é acompanhar o momento antes que a dívida técnica se torne crítica e fazer lobby na gestão para que a equipe gaste uma certa porcentagem de seu tempo na solução dos problemas atuais.
É melhor saber desde o início por que os líderes da equipe estão exaustos para reconhecer os alarmes.
Esse é o problema mais comum quando, mês após mês, você tenta chegar à gestão, chega com seus problemas e uma solução pronta, mas no topo eles apenas colocam o problema no backlog e nada acontece. Podem existir várias razões. A primeira é que você está falando a linguagem errada para os negócios e deve mudar sua abordagem. A segunda é que seu chefe “sabe tudo melhor” e continua fazendo tudo do seu jeito. Neste caso, a melhor solução seria mudar de empresa.
Um exemplo simples: sua equipe está constantemente sobrecarregada de tarefas e não há mais mãos suficientes. As pequenas e médias empresas podem simplesmente não ter dinheiro para contratar novos funcionários. Nesse caso, você pode assumir uma função adicional, como a de analista de sistemas, e começar a descrever tarefas para que o trabalho seja mais rápido. Nas grandes empresas, muito provavelmente, há dinheiro, mas a cadeia de tomada de decisão é muito longa e não há garantia de que um gato não tenha passado entre os chefes de terceiro e quarto níveis e o processo não irá paralisar por causa disso. Aqui você só pode tentar conquistar alguém da alta administração para o seu lado ou apenas esperar.
Acontece que você chega a uma empresa, desenvolve uma estratégia, faz planos e é apaixonado pelo trabalho, mas o tempo passa e nada muda. Não demora muito para ficarmos desanimados aqui: “Quem precisa de tudo isso?” Nesse caso, você pode realizar uma análise retrospectiva para entender por que o projeto não está avançando. Pergunte a si mesmo: “Talvez eu esteja atingindo o alvo errado, resolvendo os problemas errados?”
Isso acontece quando você é colocado em uma posição de liderança, recebe responsabilidades, mas não recebe nenhuma alavanca de controle. Por exemplo, não há como conduzir entrevistas de forma independente e recrutar desenvolvedores para se juntarem à sua equipe. As opções aqui são apenas duas: tentar entrar em contato com a empresa e indicar sua posição ou mudar de empresa.
Para desenvolver o produto e resolver os problemas atuais da equipe, o líder da equipe deve estar em contato constante com os tomadores de decisão. Se o acesso ao “topo” for fechado, os problemas permanecerão por resolver, as estratégias de desenvolvimento promissoras permanecerão tácitas e a motivação para trabalhar será perdida. Para não se esgotar, é melhor mudar de empresa se não conseguir estabelecer relações com a gestão.
Às vezes, há muitas tarefas e a equipe não consegue mais lidar com o fluxo de entrada. Em uma situação de emergência constante, as chamadas regulares ficam em segundo plano - quem precisa de memes e conversas vazias quando esta hora pode ser gasta eliminando bugs? Com isso, toda a equipe se transforma em um cavalo conduzido, que mais cedo ou mais tarde perderá força e as pessoas começarão a sair. Tudo o que o líder da equipe pode fazer é tentar forçar a expansão da equipe ou colocar tarefas em fila.
Isso pode acontecer se você ingressar em uma equipe já estabelecida, onde todos se odeiam. Um estilo tóxico de comunicação já se enraizou na equipe e não se fala em assistência mútua. Então a única coisa que pode ser feita é dissolver toda a equipe e recrutar novamente.
Seja qual for o problema, sempre há uma chance de um resultado favorável. Não desista após o primeiro fracasso. Pode valer a pena esperar um pouco ou mudar sua abordagem. Mas se você já tentou de tudo e parece que está batendo em uma parede em branco, então a decisão de partir será a única correta.
A capacidade de resolver problemas é uma qualidade importante de um líder de equipe. Mas, infelizmente, nem sempre funciona. Mas se você sente que está marcando passo há um ou dois anos e não pode influenciar de forma alguma, mas quer crescer, mudar de empresa não é uma má ideia. Não tenha medo da mudança. Mudar de emprego é normal.