Olá! Eu me chamo Roosevelt.
Audiodescrição: Estou vestindo uma camisa marrom. Tenho pele morena, barba e cabelo castanho escuro. Uso óculos de grau com armação redonda preta.
Trabalho como líder técnico há nove anos. Já passei por empresas de diferentes portes, de ambientes de startup a grandes corporações multinacionais. Estamos aqui, dentro da nossa trilha de liderança técnica, para abordar o curso sobre agilidade, fluxo e previsibilidade.
A proposta deste curso é explicar, de maneira prática, com experiências que nós, como liderança técnica, vivenciamos no dia a dia, como tudo funciona e quais ferramentas, recursos e métodos podemos utilizar para entregar esses três temas com precisão. Assim, alcançaremos uma equipe ágil, com fluxo uniforme e seguro, e com alta assertividade em previsibilidade. Vamos começar.
Nesta primeira aula, vamos mostrar que a pessoa líder técnica nem sempre é a melhor pessoa programadora da equipe. Existe o mito de que a liderança técnica deve ser exercida pela pessoa desenvolvedora mais experiente, com mais tempo de carreira ou com o “melhor” código. Na prática, estamos falando de papéis diferentes. A liderança técnica atua na gestão do sistema e não na gestão de tarefas. Portanto, neste primeiro vídeo, discutiremos essa diferença — um erro grave que as equipes costumam cometer ao promover a melhor pessoa programadora para a liderança técnica, quando os perfis de especialista e de liderança são distintos.
Ao falarmos de liderança técnica moderna, não se trata apenas da melhor pessoa programadora do time, e sim de quem melhora o nosso sistema de entrega. Surge então a pergunta: “Roosevelt, como percebemos isso? Como funciona na prática?” Vamos mostrar isso no próximo slide.
Nos últimos anos, o papel da liderança técnica mudou. Em ambientes corporativos, víamos frequentemente equipes de desenvolvimento nas quais a pessoa desenvolvedora mais experiente, que conhecia todo o ecossistema de código da empresa, era naturalmente promovida à liderança técnica. Muitas vezes, porém, essa especialista não tem as características de liderança, como a capacidade de coordenar e orquestrar a equipe.
Façamos uma analogia: se partíssemos da premissa de que a melhor pessoa jogadora deve ser a líder do time, um jogador de futebol de elite, como Cristiano Ronaldo, não precisaria de treinador. Na realidade, são papéis diferentes: uma pessoa rege a orquestra; a outra entrega o melhor desempenho pelo time.
Qual é, então, o papel da liderança técnica hoje? Menos controle de tarefas e mais foco na gestão do fluxo. Qual é o pesadelo de uma equipe de tecnologia? Excesso de tarefas, baixa previsibilidade e muito retrabalho. Quando a liderança técnica não enxerga que a forma como estamos trabalhando faz a equipe andar em círculos e gerar retrabalho constante — não apenas para si, mas também para as colegas e os colegas — surgem gargalos invisíveis.
O que são gargalos invisíveis? Podemos ter uma equipe de desenvolvimento que conclui tarefas muito rapidamente, mas com um gargalo na revisão de código que se torna lenta. Nesse cenário, temos um ponto de estrangulamento no fluxo.
A equipe entrega muito bem, mas descuida dos testes unitários ou dos testes de integração, e muitas coisas que entrega voltam depois como bugs (erros) ou ficam como dívida técnica. Isso gera gargalos invisíveis. São situações que normalmente são percebidas por uma pessoa com características de liderança técnica.
O que nosso curso mostrará nas próximas aulas e encontros? Conectaremos a agilidade, então aprenderemos a ser ágeis no nosso dia a dia como pessoas líderes técnicas de nossas equipes. Nós vamos transformar tudo isso de que falamos, sair do discurso abstrato e passar a métricas reais. Aprenderemos a extrair métricas reais de como nossa equipe está sendo produtiva. Por exemplo, há pessoas líderes técnicas e pessoas gerentes de projeto que acreditam que a equipe que rende mais é a que escreve mais linhas por semana, que escreve mais linhas por sprint (iteração), que entrega mais pontos. Vemos que são métricas pobres, de pouco valor relevante. Nosso papel é ensinar você, pessoa líder técnica, a obter métricas reais para perceber que sua equipe está evoluindo.
Também falaremos sobre a cultura DevOps (integração entre desenvolvimento e operações), que vem crescendo muito nos últimos anos e cuja tendência é continuar crescendo, falaremos um pouco sobre SRE (Site Reliability Engineering) e, sobretudo, sobre previsibilidade. Todo esse ecossistema de que falamos reúne conteúdos essenciais para construirmos equipes ágeis, equilibradas e, acima de tudo, confiáveis. Quando passamos a ter uma melhor previsibilidade, tornamos nossa equipe mais confiável para o cliente final, para a pessoa stakeholder (parte interessada).
Precisão é fundamental. Por exemplo: existe uma grande probabilidade — 80% ou 90% — de que entreguemos este trabalho até a sexta-feira. Isso é muito mais confiável do que dizer “talvez eu te entregue amanhã”. Ter métricas e valores concisos e coerentes ajuda muito na questão da confiabilidade da equipe. “Ah, veja, a equipe do Fulano entrega.” Aprenderemos, por meio de métricas e metodologias, a alcançar esse nível de maturidade na liderança técnica.
E o foco aqui, como disse antes, é que eu tenho experiência em liderança técnica de vários anos, desde startups (empresas iniciantes) até ambientes corporativos com grande volume de pessoas. Em cada vídeo que eu fizer junto com você, trarei foco na aplicação prática: falarei de uma situação que vivi em algum lugar onde trabalhei, contarei sobre um problema que tive, um momento em que fracassei na minha carreira, um momento em que acertei, um momento em que aprendi e construí a solução para esse erro. Então, nosso foco, aula a aula, vídeo a vídeo, será 100% na aplicação prática.
Por exemplo, se você é sênior na sua equipe e quer uma promoção para se tornar pessoa líder técnica, ou se já está atuando como pessoa líder técnica na sua equipe, mas percebe que precisa melhorar em alguns aspectos, muito do que você verá nos vídeos comigo poderá aplicar no dia seguinte no seu ambiente de trabalho. O foco aqui é 100% na aplicação prática; não vamos nos concentrar muito na teoria acadêmica.
Tudo o que eu, Roosevelt, disser no decorrer deste vídeo estará 100% orientado à aplicação prática. Do tipo: você assistiu a este vídeo hoje comigo, eu garanto que amanhã, no seu trabalho, você vai conseguir fazer um experimento e aplicar o que está aprendendo nesta aula de hoje. São métodos aplicados e validados sempre no mercado real.
Em cada aula, trarei um caso que eu tenha vivido, ou que eu conheça alguém que tenha passado por ele, e darei o passo a passo real sobre o método, para que você encontre, na prática, o mesmo cenário e também possa buscar os mesmos resultados.
Resumindo, damos as boas-vindas a este conteúdo; a aplicação aqui será 100% prática e começaremos a aprofundar a partir do próximo vídeo. Um abraço e até a próxima.
No vídeo de hoje, vamos discutir um tema simples: como mudamos nossa mentalidade do código para o sistema. Quando deixamos de ocupar uma posição de pessoa programadora, precisamos alterar essa mentalidade: deixamos de focar apenas no código para enxergar o sistema como um todo.
Esse é um desafio quando somos promovidos à liderança técnica ou quando atuamos como pessoas desenvolvedoras sênior e desejamos nos tornar liderança técnica. Essa barreira cultural e mental precisa ser exercitada.
Como pessoas programadoras, tendemos a pensar de forma individual: nós, nosso computador e a entrega de código. Na liderança técnica, somos nós, a equipe que lideramos e a necessidade de orquestrar o sistema.
Costumamos propor uma pergunta provocadora, inclusive já feita em um vídeo anterior: a liderança técnica precisa sempre ser a melhor pessoa programadora do time? Gostaríamos de conhecer sua opinião sobre isso.
Vamos expor nossa opinião: nem sempre a liderança técnica é a melhor pessoa programadora. Muitas pessoas acreditam que, ao se tornar sênior, automaticamente alguém se torna liderança técnica. Isso é muito comum.
Eu tenho, no total, 23 anos de carreira como pessoa desenvolvedora de software. Comecei como estagiário, tornei-me pessoa desenvolvedora júnior e, em seguida, pessoa desenvolvedora plena. Quando cheguei a pessoa desenvolvedora sênior, passei a programar intensamente; as pessoas observavam: “Caramba, Roosevelt é uma pessoa programadora experiente; automaticamente, as demais ocuparão posições abaixo dele, e ele se torna liderança técnica.” Na primeira vez em que me tornei liderança técnica, percebi que não sabia liderar nada. Portanto, não funciona dessa forma.
Qual é a responsabilidade de uma pessoa desenvolvedora sênior? Resolver incidentes, corrigir bugs, conduzir uma boa evolução de profissionais mais júnior, participar do processo de evolução do código dessas pessoas, realizar revisão de código e explicar por que certas partes precisam ser modificadas. Assim, a pessoa desenvolvedora sênior tem o papel de resolver problemas de código e de representar ou apoiar o time.
Entretanto, quando damos esse passo e saímos da posição de sênior, de especialista, para a liderança técnica, passamos a lidar com questões mais amplas. Removemos causas-raiz, eliminamos bloqueios do time, criamos observabilidade e, sobretudo, automatizamos processos triviais.
Um exemplo é o processo de revisão de código, no qual muitas tarefas triviais do dia a dia são cansativas para o time de desenvolvimento. O papel da liderança técnica, nessa parte trivial — tipagem, sintaxe, indentação de código e afins — é assumir: nós vamos criar uma ferramenta para automatizar essa verificação, ou faremos com que isso seja organizado automaticamente durante um processo de implantação. Tudo o que pudermos automatizar, criar de observabilidade e manter como padrões de código do nosso time é responsabilidade da liderança técnica.
Uma liderança técnica pensa em como todas as pessoas trabalham de forma orquestrada, em conjunto e com conforto. Já a pessoa desenvolvedora sênior tem como função se destacar em relação às demais para servir de referência técnica para as pessoas mais juniores. A liderança técnica, por sua vez, garante que todas as pessoas trabalhem de maneira orquestrada e convivam, no dia a dia, em um ambiente que gere conforto e potencial de entrega.
Gostamos de mostrar no slide que as pessoas cuidam da tarefa. A liderança técnica cuida do sistema. O sistema — a sprint (iteração), todo o nosso ecossistema de entrega de valor — é uma responsabilidade assumida pela liderança técnica. Enquanto pessoas desenvolvedoras juniores, plenas e seniores atuam com maturidade orientada de tarefa em tarefa, a liderança técnica olha para o todo.
Quando nos referimos ao sistema, não estamos falando apenas do código que estamos desenvolvendo. O sistema é um todo: é composto por pessoas, processos e, principalmente, tecnologia. Ao sairmos de uma posição de especialidade mais individualista para exercer uma posição de liderança técnica, precisamos “vestir esse chapéu” e mudar nossa mentalidade para atuar sempre em prol da coletividade, visando que nosso time trabalhe melhor.
Para que isso ocorra, não é necessário ser a melhor pessoa programadora. Precisamos ter um bom entendimento de todo o ecossistema da aplicação — seja do front-end (camada de interface), do back-end (camada de servidor), da camada de integração de API (Interface de Programação de Aplicações) ou do mobile (aplicação móvel). Devemos saber como dialogar com a área de Produto e com UX (experiência da pessoa usuária), e como transmitir conteúdos de profundidade técnica de maneira simples para pessoas não técnicas, que são as/os stakeholders (partes interessadas). Esse conjunto de atribuições nos tira do universo estrito do código para atender a esse tipo de demanda.
No vídeo de hoje, fica o exercício para pensarmos em como devemos transformar nossa mentalidade e nosso modo de atuar, agora que estamos como liderança técnica e não mais como pessoas desenvolvedoras sênior.
Eu espero que você tenha gostado deste vídeo. Um forte abraço e nos vemos no próximo.
No vídeo de hoje, vamos falar sobre o pensamento orientado ao fluxo. Como isso funciona? Para quem viu os vídeos anteriores, falamos bastante sobre a mudança de mentalidade ao deixar de ser uma pessoa desenvolvedora sênior e passar a atuar como pessoa líder técnica de uma equipe. A mentalidade muda: precisamos “mudar o chip”, deixar de pensar como indivíduos, como referência técnica, e passar a pensar no coletivo, de forma semelhante ao trabalho de um treinador de futebol, que orquestra, posiciona a equipe e define em que posição cada pessoa vai atuar. Em cada parte do ecossistema, cada pessoa entregará código e realizará as tarefas que lhe correspondem. Passamos a trabalhar questões de observabilidade, a perceber gargalos na equipe e a notar nuances que podem ser melhoradas para a operação e a entrega como um todo, a entrega como equipe. Esse é um papel da pessoa líder técnica. E, para começar, precisamos mudar a forma de pensar: o pensamento passa a estar orientado ao fluxo.
Para sustentar esse pensamento orientado ao fluxo, trouxemos quatro circunstâncias e quatro definições sobre as quais vamos falar brevemente. Primeira coisa: muitas pessoas confundem produtividade com fluxo. É um erro comum de quem vai exercer funções de liderança técnica pensar que produtividade tem semelhança ou correlação direta com fluxo. Na realidade, produtividade é diferente de fluxo. Muito trabalho iniciado não significa muito valor entregue.
Qual é um erro capital quando uma pessoa líder técnica chega com tudo à equipe querendo se destacar? Entramos como liderança técnica em uma equipe — algo que já ocorreu em diversos ambientes —, chegamos a uma empresa nova, fomos promovidos e estamos responsáveis por gerir a equipe. Chegamos com a ideia de “vamos chegar, transformar e fazer as coisas acontecerem”. Qual é nosso primeiro trabalho? Observar os pontos que podemos melhorar. Identificamos: isto pode ser refatorado, aquela funcionalidade podemos assumir para fazer também e assim por diante. E queremos que tudo ocorra ao mesmo tempo. É nesse momento que a liderança técnica falha e surgem os problemas, porque produtividade é distinta de fluxo. Muito trabalho iniciado ao mesmo tempo não significa muito valor entregue. Precisamos, portanto, trabalhar com os conceitos de entrega de valor.
Ao entrar em uma equipe, devemos observar: qual é a primeira demanda que podemos assumir para gerar uma primeira entrega de valor? Refatoração do sistema de login? Então vamos nos concentrar apenas nisso. Nosso backlog tem 20 tarefas. Quais são as que podemos executar para entregar valor no módulo de login? São 4 tarefas; são essas 4 que vamos retirar do backlog para o pipeline. Destas 4, vamos colocar uma a uma dentro do pipeline de desenvolvimento e realizar as entregas. Muito trabalho iniciado não significa muito valor entregue. Precisamos ter a percepção do que “cabe” na equipe. Caso contrário, iniciamos muitas coisas ao mesmo tempo e ficamos com um grande volume de trabalho pela metade. Esse é um problema quando queremos ser produtivos, mas ignoramos o fluxo.
Outro ponto: deixar de começar e passar a terminar. Trouxemos um exemplo simples e criamos um cartão para visualizar. Qual é o melhor cenário? Temos um backlog com 9 tarefas e um sprint de 2 semanas. Qual abordagem traz mais valor para a equipe como um todo?
Cenário A: pegamos tarefa 1, tarefa 2, tarefa 3, tarefa 4, tarefa 5, tarefa 6, tarefa 7 e tarefa 8, e colocamos todas em “Em progresso”, sob a justificativa de “já estamos fazendo, já começamos”. A equipe passa a codificar em 8 frentes ao mesmo tempo e, quando chega o fim do sprint, concluímos 2 tarefas. Esse é um cenário: assumimos 8 tarefas e concluímos 2.
Cenário B: trabalhamos orientados ao fluxo e pensamos onde podemos entregar valor no sprint. Podemos entregar valor se concluirmos tarefa 1, tarefa 2 e tarefa 3. O que fazemos? Pegamos tarefa 1, tarefa 2, tarefa 3 e tarefa 4, deixamos o restante no backlog, temos a percepção do que cabe na equipe para esse sprint e apenas isso colocamos em “Em progresso” para entregar. Ao final do sprint, conseguimos entregar tarefa 1, tarefa 2, tarefa 3 e tarefa 4.
Qual cenário é mais produtivo? Aquele em que colocamos 8 tarefas em progresso e, ao final do sprint, entregamos apenas 2, deixando 6 pela metade, ou aquele em que assumimos 4 tarefas e entregamos as 4? Daí parte a premissa: começar menos e terminar mais. Por quê? Porque caso contrário ficamos com muito trabalho pela metade. Precisamos deixar de começar e passar a terminar.
Seis itens iniciados e seis itens entregues são muito melhores do que vinte itens iniciados e três itens entregues. Por que dizemos isso? Porque a pessoa cliente não é técnica, a parte interessada não é técnica; elas querem saber o que significa uma tarefa estar pronta.
Ao final de um sprint (iteração), durante a review (revisão) e o lançamento em produção, geramos muito mais valor ao entregar quatro tarefas concluídas do que ao entregar apenas duas e informar que outras seis estão em andamento. Quando assumimos muitos itens simultaneamente, ocorre troca constante de raciocínio e de contexto. Se uma pessoa desenvolvedora está concentrada na funcionalidade A e, de repente, sai desse código para trabalhar no código B, precisa modificar toda a linha de raciocínio, o que reduz a eficiência.
Outro ponto importante: podemos ter uma equipe de desenvolvimento muito eficiente para lidar com várias tarefas ao mesmo tempo. Porém, quando todas essas tarefas migram para a coluna de QA (garantia de qualidade), o QA tende a ficar sobrecarregado para testar tudo. Com essa sobrecarga, a qualidade e o rigor dos testes caem. É nesse cenário que funcionalidades chegam à produção com bugs (defeitos), fora de padrões de desenvolvimento, ocasionando falhas frequentes nas entregas.
Portanto, o pensamento orientado ao fluxo recomenda selecionar poucos itens e concluí-los, em vez de iniciar muitos e quase não finalizar nada. Precisamos adotar esse pensamento orientado ao fluxo porque uma coisa leva à outra: a previsibilidade nasce do fluxo.
Quando existe um fluxo sem gargalos — por exemplo, uma equipe que, a cada sprint (iteração), assume quatro tarefas e, de forma consistente, entrega as quatro —, a previsibilidade emerge naturalmente. Se o que nos comprometemos a fazer é cumprido, mantendo um ciclo constante do início ao fim, tornamo-nos mais previsíveis. E uma equipe previsível é uma equipe confiável.
Logo, a previsibilidade é consequência da organização do fluxo. Com um fluxo uniforme, entendemos a capacidade da equipe, negociamos com o stakeholder (parte interessada) e com a área de negócio e, consequentemente, tornamo-nos mais previsíveis e confiáveis.
Esse é um erro que já vivenciamos: ao tentar “aumentar a produtividade” puxando muitas tarefas ao mesmo tempo, o quadro exibia inúmeras cartas em progresso e quase nada era entregue. Já passamos meses sem realizar uma entrega de valor porque se trabalhava com muitas tarefas simultaneamente. Esse pensamento orientado apenas à “produtividade”, de querer fazer tudo e “abraçar o mundo”, termina por não resolver nada de forma adequada.
Entender a capacidade da equipe dentro da janela de trabalho é fundamental para torná-la confiável e previsível.
Devemos estabelecer um fluxo contínuo no quadro de trabalho, contemplando as seguintes etapas:
Esse é, basicamente, um fluxo contínuo de desenvolvimento para uma equipe saudável.
Para concluir, reforçamos os quatro pontos do pensamento orientado ao fluxo e, principalmente, a necessidade de entender a capacidade da equipe para gerar um fluxo saudável e, como consequência, termos uma equipe confiável nas entregas.
Eu espero que você tenha gostado deste vídeo. Um forte abraço e nos vemos no próximo vídeo.
O curso Tech Lead: agilidade, fluxo e previsibilidade possui 402 minutos de vídeos, em um total de 68 atividades. Gostou? Conheça nossos outros cursos de Liderança Técnica em Gestão & Negócios, ou leia nossos artigos de Gestão & Negócios.
Matricule-se e comece a estudar com a gente hoje! Conheça outros tópicos abordados durante o curso:
O Plano Plus evoluiu: agora com Luri para impulsionar sua carreira com os melhores cursos e acesso à maior comunidade tech.
2 anos de Alura
Matricule-se no plano PLUS 24 e garanta:
Jornada de estudos progressiva que te guia desde os fundamentos até a atuação prática. Você acompanha sua evolução, entende os próximos passos e se aprofunda nos conteúdos com quem é referência no mercado.
Back-end, Dados, Front-end, DevOps, Mobile, Gestão & Negócios, UX & Design, Cibersegurança, Cloud, Inteligência Artificial
Formações com mais de 1500 cursos atualizados e novos lançamentos semanais, em Programação, Inteligência Artificial, Front-end, UX & Design, Data Science, Mobile, DevOps e Inovação & Gestão.
A cada curso ou formação concluído, um novo certificado para turbinar seu currículo e LinkedIn.
Acesso à inteligência artificial da Alura.
No Discord, você participa de eventos exclusivos, pode tirar dúvidas em estudos colaborativos e ainda conta com mentorias em grupo com especialistas de diversas áreas.
Catálogo de tecnologia para quem é da área de Marketing
Faça parte da maior comunidade Dev do país e crie conexões com mais de 120 mil pessoas no Discord.
Acesso ilimitado ao catálogo de Imersões da Alura para praticar conhecimentos em diferentes áreas.
Explore um universo de possibilidades na palma da sua mão. Baixe as aulas para assistir offline, onde e quando quiser.
20% de desconto na Pós Tech
Luri Vision chegou no Plano Pro: a IA da Alura que enxerga suas dúvidas, acelera seu aprendizado e conta também com o Alura Língua que prepara você para competir no mercado internacional.
2 anos de Alura
Todos os benefícios do PLUS 24 e mais vantagens exclusivas:
Acesso ao catálogo da Casa do Código e leitura dentro da plataforma
Chat, busca, exercícios abertos, revisão de aula, geração de legenda para certificado.
Modo entrevista - Pratique situações reais e evolua com feedback personalizado
Envie imagens para a Luri e ela te ajuda a solucionar problemas, identificar erros, esclarecer gráficos, analisar design e muito mais.
Aprenda um novo idioma e expanda seus horizontes profissionais. Cursos de Inglês, Espanhol e Inglês para Devs, 100% focado em tecnologia.
Para quem quer atingir seus objetivos mais rápido: Luri Vision ilimitado, vagas de emprego exclusivas e mentorias para acelerar cada etapa da jornada.
2 anos de Alura
Todos os benefícios do PRO 24 e mais vantagens exclusivas:
Lives CareerUp: eventos exclusivos com foco em empregabilidade e carreira
Mentorias de carreira: 2 encontros individuais com mentores do Talent Lab
Conecte-se ao mercado com mentoria individual personalizada, vagas exclusivas e networking estratégico que impulsionam sua carreira tech para o próximo nível.
