Olá! Acho que todo desenvolvedor que faz a transição para uma função de líder de equipe inicialmente se esforça para retornar à codificação e à resolução de tarefas junto com a equipe. Posteriormente, passamos a abranger mais tarefas e questões de negócio, mergulhando em desafios relacionados ao negócio, comunicação entre departamentos ou clientes e arquitetura. A partir daí, não temos mais tempo nem vontade de fazer outra coisa. O calendário de um líder de equipe típico começa a se parecer com isto: Como retorno ao desenvolvimento e começo a codificar novamente? Por onde devo começar? Também é importante avaliar o quão realmente ocupado você está e como é seu dia de trabalho típico. Você se dedica ao autoaperfeiçoamento depois do trabalho ou não? Todos esses são fatores cruciais. Com base na minha experiência, sugiro seguir o caminho de “nenhum tempo antes ou depois do trabalho, nenhum desejo ou oportunidade” até “estou sempre no computador e esta é a minha paixão”. Bloqueie seu tempo! Um ponto de partida eficaz é agendar um tempo dedicado para o desenvolvimento. Simplesmente bloqueie o 'tempo de codificação' em seu calendário por uma hora ou mais. Se possível, considere reservar meio dia ou um dia inteiro por semana especificamente para realizar tarefas técnicas. Sim, pode envolver mudar as reuniões, eliminar as desnecessárias ou discutir a necessidade de comparecer a algumas delas. No entanto, considere reavaliar se certas sessões de preparação ainda são relevantes para você. Talvez você esteja passando uma hora lá sem muito impacto? Redirecione esse tempo para a codificação! Revisão de código com sua equipe! O segundo e mais crucial aspecto para otimizar certos processos ao seu redor é comunicar os valores ou abordagens do projeto aos seus colegas. Nem todo desenvolvedor vê a mesma abordagem para a solução de problemas, por isso é essencial predefinir estilos de codificação, cobertura de testes e os métodos e mecanismos fundamentais da plataforma ou dos serviços separadamente. Sempre conduza revisões de código e, se houver a sensação de que uma questão está se arrastando, reúna a equipe para resolver rapidamente os problemas nas solicitações pull (PRs). Como mostra a prática, essa abordagem acelera o tempo de resolução de problemas, melhorando consequentemente o tempo de lançamento de recursos no mercado. Com o tempo, sua equipe compreenderá e aplicará totalmente abordagens de desenvolvimento que requerem menos atenção. Você se concentrará exclusivamente em resolver a tarefa em questão e sua lógica, o que economizará alguns minutos inicialmente e, no longo prazo, potencialmente horas de desenvolvimento. Pelo que você é responsável? Pode não parecer a tarefa mais óbvia, mas pergunte-se: pelo que você é responsável? O que você precisa fazer? Anote todos esses pontos em uma folha de papel e veja se você fez algo desnecessário. Talvez você esteja fazendo o trabalho de outra pessoa só porque isso se tornou um hábito. Talvez você esteja ajudando uma equipe vizinha em seus processos e ainda esteja envolvido. Defina claramente a sua posição e o que você contribui para o projeto ou para a empresa. Se você lidera uma equipe grande, use notas onde possa criar uma fila de tarefas e problemas. Sempre conduza revisões e certifique-se de que, se você for um líder de DevOps, por exemplo, não esteja lidando inadvertidamente com tarefas destinadas a desenvolvedores de aplicativos móveis. Se você está sobrecarregado de tarefas e dependências, vale a pena parar para conversar com seus superiores e descobrir por que isso está acontecendo em seu departamento. Por exemplo, se você for uma equipe de DevOps responsável por engenheiros de dados e eles tiverem seu próprio líder, pode fazer sentido delegar responsabilidades ao líder deles, em vez de ao seu departamento. Crie especificações e documentos necessários para formalizar acordos ou quaisquer detalhes ocultos sobre configuração ou manutenção e devolva as pessoas às suas respectivas equipes. É fundamental ressaltar que este é apenas um exemplo, e cada um tem sua equipe e princípios de formação. Priorização e Delegação É possível que você não esteja realizando as coisas porque as prioridades estão sempre mudando. A empresa inteira opera em sprints de duas semanas, mas essa configuração não combina mais com você e você não vê valor nela. Os recursos não estão sendo concluídos em um sprint devido a prioridades fracas. Isso é relevante para equipes orientadas a serviços. Considere explorar o Kanban ou uma abordagem de fluxo de água. Nossas equipes são como ilhas separadas onde temos o direito de tentar mudar os processos para melhor. Teste a transição para a nova abordagem por um mês e observe suas métricas. Na minha experiência, algumas semanas foram suficientes para perceber que o Scrum não era adequado para nós e mudamos para o Kanban. Nosso tempo de lançamento no mercado diminuiu drasticamente porque as prioridades agora podem mudar duas vezes por semana, o que nos permite resolver os problemas com mais rapidez. Em seguida, tente dividir a equipe em zonas de domínio, mas não de forma muito granular. Mergulhe cada membro da equipe seguindo a regra 70/30: 70% dedicados à sua pilha principal, projeto ou produto 30% para todo o resto Se sua equipe tiver mais de 5 pessoas, você cobrirá todos os serviços e funções, permitindo que os indivíduos mergulhem mais rapidamente na área temática. O que isso alcança? Ele permite delegar algumas tarefas para a equipe ao invés de fazer tudo sozinho caso perceba que um desenvolvedor já tem um bom entendimento e imersão. Você não precisa descrever todo o algoritmo e integrações! Eles já sabem tudo! Gestão de Tempo e Produtividade Como a equipe está planejando seu horário de trabalho? Vamos começar com algo simples: como vocês atuam em equipe? Dê uma olhada em suas estimativas e como você avalia as tarefas. Está tudo em ordem? Talvez haja espaço para melhorias ou a introdução de um coeficiente de carga de trabalho? O coeficiente de carga de trabalho ajuda a entender como cada membro da equipe está sobrecarregado durante um sprint ou semana, considerando possíveis distrações para suporte. Por exemplo, se você faz parte de uma equipe de serviço com seu próprio produto para manter, outras equipes podem buscar sua assistência ou solicitar melhorias, o que leva ao tempo gasto na comunicação dentro do sprint. O mesmo vale para lidar com bugs; você pode frequentemente ser desviado para resolver problemas urgentes no ambiente de produção. Mas esse é um tópico separado, e recomendo verificar meu artigo anterior sobre como fazer melhorias graduais nesta área. https://hackernoon.com/just-go-ahead-and-test-your-project-part-1?embedable=true Agora, de volta ao coeficiente. Se reconhecermos que cada um de nós é chamado para um bate-papo ou reunião pelo menos 1 dia em 5 para resolver um problema, leve isso em consideração durante o planejamento. Dessa forma, você conseguirá de forma realista realizar tarefas que realmente beneficiem a equipe, potencialmente liberando tempo para escrever código. Experimente a técnica Pomodoro. Nada inovador; basta usar um aplicativo no seu telefone que permita que você se concentre em uma tarefa por um intervalo de tempo definido, como 45 minutos. Nada de especial, eu acho. Utilize rastreadores. Faça uma investigação sobre onde você gasta suas 8 horas de trabalho – registre cada hora e minuto de suas atividades durante a semana ou mês. Você pode descobrir fatores que o distraem ou pode perceber que fazer uma caminhada de 15 minutos depois do almoço faz com que você trabalhe com mais eficiência – talvez essa seja a chave para o sucesso? Ou, se você tiver três reuniões consecutivas, você não fará nada durante uma hora depois, apenas lendo as especificações? Talvez seja um desafio para você? O objetivo é examinar minuciosamente o que você está fazendo e acredito que você identificará áreas para melhoria. Participação em projetos tecnicamente desafiadores Se você não puder participar de reuniões dedicadas ao projeto de sistemas ou soluções arquitetônicas, leia os acompanhamentos ou a documentação. Tente entender como e o que resolve o problema. É preferível não perder essas reuniões e esforçar-se para mergulhar o máximo possível nos aspectos técnicos. Selecione projetos ou aspectos do projeto que exigem um mergulho profundo no código. Isso o ajudará a ficar atualizado sobre novas tecnologias e metodologias de desenvolvimento. RnD para você Se você notar áreas no projeto que apresentam problemas ou onde a funcionalidade pode ser melhorada, sinta-se à vontade para criar protótipos. Isso não só permitirá visualizar as mudanças propostas, mas também fornecerá à equipe material tangível para discussão e tomada de decisão. O objetivo principal não é apenas apresentar ideias, mas implementá-las no projeto, caso se revelem genuinamente significativas ou benéficas. Por exemplo, se você sempre sonhou em migrar serviços desatualizados do Java 1.8 para a versão 21, por que não tentar? Crie um protótipo, mostre-o à equipe, desenvolva sua solução e documente minuciosamente todo o processo para referência futura. Esta abordagem ajuda não só a implementar melhorias técnicas, mas também a criar um entendimento partilhado dentro da equipa relativamente a potenciais mudanças. Assim, poderá dar um contributo construtivo ao projeto, garantindo o seu efetivo desenvolvimento e fomentando a inovação. Ponto de revisão! , você terá algumas horas para escrever código, propor soluções e então poderá fazer uma pausa. É claro que a posição de liderança simplesmente não permitirá que você faça as duas coisas e, se o seu foco ainda estiver no desenvolvimento, talvez valha a pena considerar um retorno. Nesta fase Não há nada de errado com isso – perceber que o gerenciamento está se tornando enfadonho para você, mesmo que você se destaque nisso, está tudo bem. Acontece que, neste momento, perdeu o apelo para você. Se você ainda tiver algum tempo livre Aprendizagem e Autodesenvolvimento Eduque-se continuamente lendo literatura técnica, explorando cursos educacionais e participando de conferências técnicas. Isso o ajudará a ficar atualizado sobre as últimas tendências e melhores práticas em desenvolvimento de software. A leitura da literatura técnica oferece uma oportunidade única de se aprofundar nas novas tecnologias, metodologias e melhores práticas. Isso pode incluir livros, artigos, blogs e outros materiais que cobrem vários aspectos do desenvolvimento de software. Fazer cursos educacionais é uma forma estruturada e sistemática de adquirir conhecimentos sobre novos temas e tecnologias. As plataformas de cursos online oferecem uma ampla variedade de cursos sobre diferentes linguagens de programação, estruturas e conceitos. A participação em conferências técnicas abre a oportunidade não apenas de aprender sobre as últimas tendências e inovações, mas também de interagir com profissionais do setor. As conferências fornecem uma plataforma para compartilhar experiências, discutir questões desafiadoras e construir conexões dentro da comunidade técnica. Em resumo, a aprendizagem contínua através da leitura, da realização de cursos e da participação em conferências permite aos desenvolvedores de software não só acompanhar as últimas tendências, mas também integrar ativamente novos conhecimentos e competências no seu trabalho diário. Exemplos: leetcode, Udemy ou Youtube (às vezes podemos encontrar conteúdo GRATUITO muito bom lá!). Trabalhando em projetos pessoais Se possível, trabalhe em projetos pessoais no seu tempo livre. Isso não apenas aprimorará suas habilidades de programação, mas também servirá como fonte de novas ideias para seu trabalho principal. Além disso, combinar esta atividade com o ponto de P&D do artigo pode ser um incentivo extra à criatividade e inovação. Trabalhar em projetos pessoais permite aplicar suas habilidades em cenários práticos, experimentar novas tecnologias e resolver problemas do mundo real. Esses projetos podem envolver o desenvolvimento de seus próprios aplicativos web, a criação de projetos de código aberto ou a participação em projetos paralelos interessantes. Integrar esta atividade com o trabalho de pesquisa e desenvolvimento (P&D) mencionado anteriormente permite criar protótipos e apresentá-los em seu local de trabalho. Abrir seu projeto ao público, como participar do desenvolvimento de código aberto, não apenas melhora suas habilidades, mas também contribui para construir conexões profissionais valiosas e obter reconhecimento por sua criatividade. Porém, é fundamental lembrar que aderir à política de confidencialidade (NDA) do seu trabalho principal é uma prioridade. Antes de embarcar em projetos pessoais, é aconselhável consultar profissionais jurídicos e de gestão para garantir que o seu processo criativo não viole as regras estabelecidas e para facilitar o livre desenvolvimento da sua energia criativa, preservando a confidencialidade dos dados sensíveis. Conclusão Encontrar tempo para programar como líder de equipe requer esforço consciente e gerenciamento eficaz de prioridades. Lembre-se que sua função envolve não apenas liderar diretamente a equipe, mas também manter suas habilidades técnicas em um nível satisfatório. Será um desafio e desejo-lhe boa sorte! Eu vi o problema há muito tempo. Se você gostaria de ler livros profissionais, recomendo que leia livros: e link link
