Olá! Bem-vindas e bem-vindos a outro curso aqui na Alura. No curso de hoje, vamos falar sobre Tech Lead (pessoa líder técnica), gestão de pessoas e orientação para alto desempenho. Antes de começar a falar sobre o curso, vou me apresentar. Vou fazer minha autodescrição.
Audiodescrição: É um homem branco, com cabelo castanho escuro, barba curta, usando óculos redondos de armação preta e uma camiseta da Alura, do Grupo Alura. Ao fundo, há uma parede branca iluminada por uma luz rosa e uma luz roxa, alinhadas com o tema visual da Alura.
Tenho aproximadamente 19 anos de experiência na área de tecnologia. Atualmente trabalho como Tech Lead (pessoa líder técnica) no Banco Itaú, sou professor de graduação na FIAP e também estudei aqui na Alura, com alguns cursos especificamente da trilha de Tech Lead (pessoa líder técnica). Além disso, tenho muita experiência em mentoria e evolução de cargos técnicos, sou especialista em arquitetura de software e sistemas escaláveis e tenho algumas certificações da AWS (Amazon Web Services), metodologias ágeis e áreas relacionadas.
Por que este curso existe? Principalmente porque, quando começamos a atuar como Tech Lead (pessoa líder técnica), deixamos de focar em excelência individual e passamos a buscar excelência como grupo. Deixamos uma frase para leitura no slide (apresentação): ser excelente individualmente não garante que conseguimos elevar o desempenho de um time.
A excelência individual ocorre quando resolvemos problemas sozinhos, precisamos ser os mais rápidos, dominamos a stack (pilha tecnológica) e, muito provavelmente, isso nos trouxe até aqui. Isso permitiu evoluirmos de júnior para pleno, de pleno para sênior, e agora alçamos voos mais altos. Ao assumirmos o papel de Tech Lead (pessoa líder técnica), o foco passa a ser a capacidade coletiva. Já abordamos esse ponto em outros cursos, mas aqui iremos nos aprofundar em como guiar pessoas para o alto desempenho e como orientar um time para o alto desempenho.
O próximo nível exige que o time resolva melhor, com mais autonomia. A IA virá para acelerar a execução, mas aumentará a necessidade de julgamento humano. No momento em que vivemos, a IA deve ser uma ferramenta inserida no nosso contexto para potencializar nosso trabalho, usada com cautela e da maneira correta. Vamos ver um pouco sobre isso também ao longo deste curso.
Como este curso está dividido? Teremos cinco aulas:
Para quem é este curso?
Antes de avançarmos para a próxima parte, um apontamento importante: para pessoas profissionais que estão no início de carreira, este vídeo e este curso também serão úteis. Embora o foco esteja em pessoas mais avançadas, que já pensam em atuar como Tech Lead (líder técnico) ou que já ocupam esse papel, qualquer pessoa desenvolvedora que aprenda e aplique essas técnicas se diferenciará e acelerará seu crescimento. Se você ainda não está em nenhum dos papéis mencionados, pode fazer o curso sem problema; talvez não se aplique tanto à sua realidade atual, mas você poderá usar as ferramentas e adaptá-las ao seu contexto.
Como aproveitar melhor o curso? Recomendamos que, em vez de assistir aos vídeos de forma contínua, sem pausas e sem reflexão, façamos interrupções periódicas. Se algo não ficar claro, volte e assista novamente. O curso gravado permite rever quantas vezes forem necessárias até fixar e compreender bem o conteúdo.
Sugerimos utilizar os modelos detalhados das aulas, pausar o vídeo, complementar com situações reais do seu contexto e praticar o que realizarmos aqui. Haverá exercícios práticos; faça-os também. Procure mapear tudo para a realidade da sua equipe, pensando nas pessoas reais com quem você trabalha. Use seu contexto real e evite buscar a resposta perfeita: o valor está na aplicação no dia a dia. Ao ouvir um conceito, reflita: isso ocorre na sua equipe? Você já passou por situação semelhante? Como aplicar o que está aprendendo no seu ambiente? O que você observa no cotidiano que se encaixa nas situações que a pessoa instrutora está apresentando?
Escolha e execute pelo menos um experimento por aula com sua equipe antes da próxima. Pegue um exemplo da aula, tente aplicá-lo, conduza uma dinâmica, convide sua equipe e coloque em prática o que estiver aprendendo. Isso consolidará muito mais o conteúdo do que apenas assistir. Como há muito conteúdo, provavelmente esqueceremos parte dele e manteremos apenas fragmentos. Por isso, faça anotações e retome os materiais após conversas reais, os one-on-ones (conversas individuais) com sua equipe e as dinâmicas que realizar. Revise se algo passou despercebido, se algum detalhe foi omitido ou se há pontos que podem ser aprimorados. A releitura com contexto prático potencializa o aprendizado. Precisamos de etapas: primeiro ouvimos, depois escrevemos, depois praticamos; cada etapa ajuda a fixar o conhecimento e construir, no fim, uma base sólida.
É essencial conectar o conteúdo do curso com a carreira, pois a qualidade técnica não se sustenta sem liderança de pessoas. Trabalharemos quatro pilares que devem ser conectados à sua realidade:
Tudo o que veremos aqui precisa se traduzir em resultados concretos na sua trajetória. Esses quatro pilares orientarão o que você precisa saber, aprender neste curso e como construir sua atuação como Tech Lead (líder técnico) ou como alguém que exercerá uma liderança técnica mais eficiente.
Para fechar, sintetizamos a proposta do curso para que você saiba o que vai aprender e avalie se está alinhado ao que busca: oferecer clareza, critérios e rituais para liderar uma equipe técnica em alta performance. Nosso objetivo é que você saia com um plano claro, sem dúvidas sobre o caminho a seguir e o que precisa fazer.
Abordaremos:
Esperamos que você aproveite bastante, se dedique e saia com um aprendizado útil para o seu dia a dia. Encerramos este vídeo. Nos vemos no próximo.
Olá, bem-vindas e bem-vindos de volta.
No vídeo anterior, fizemos uma breve introdução sobre o curso, apresentamo-nos e falamos sobre como aproveitar melhor o conteúdo.
Neste vídeo, vamos abordar a transição e a mudança de mentalidade de pessoa desenvolvedora sênior para liderança técnica (líder técnico).
Vamos começar pelo mito do super-herói técnico. Certamente já convivemos com alguém que era referência para tudo: sempre que havia um problema, chamavam essa pessoa, e pensávamos “essa pessoa com certeza vai resolver”. Até aí, tudo bem. Ter excelentes pessoas técnicas no mercado, no time e na empresa não é um problema em si. O problema começa quando essa pessoa excelente — que sabe muito, resolve problemas complexos, revisa PRs complexos, corrige erros difíceis, domina linguagem, conhece profundamente estruturas de desenvolvimento, o ecossistema de desenvolvimento como um todo e arquitetura, destacando-se pela experiência técnica — é promovida a líder técnico e continua atuando exatamente como atuava quando era pessoa desenvolvedora sênior ou quando estava no papel de Staff Engineer (pessoa engenheira staff). Nesse ponto, começa a se tornar um gargalo, centralizando tudo.
Em um time com muitas pessoas, não pode existir apenas uma pessoa responsável por aprovar tudo o que todes fazem, porque, do contrário, as entregas demoram a sair. Uma pessoa não consegue revisar os PRs de oito pessoas desenvolvedoras. No nosso time, temos oito pessoas. Imaginem se tivéssemos que revisar todos os PRs que essas oito pessoas abrem: nada sairia no prazo, haveria muito atraso, e, além disso, gastaríamos tempo demais apenas com isso. E as outras responsabilidades, como ficariam? Ao buscarmos o “super-herói técnico”, não teremos uma liderança técnica eficiente, mas sim alguém que cria gargalos, gera impedimentos e burocratiza o processo.
Na apresentação, separamos alguns pontos para discutir:
Saber tudo
Desbloquear todo mundo
Centralizar crises
Centralizar decisões
Eu mesmo vou passar por isso em breve: vou sair de férias, sou líder técnico do meu time e terei que escolher alguém para atuar como interino. É uma pessoa com quem venho conversando há bastante tempo, muito próxima do meu dia a dia, que sabe como trabalho, o que faço e como tomo decisões. Vou deixá-la bem alinhada: nenhuma decisão difícil deve ser tomada de forma isolada. Chamem o time, envolvam a coordenação, envolvam a gerência se necessário, e tomem a decisão. Não pode ser apenas a liderança técnica que detém o domínio do conhecimento e o poder de decisão; o time deve saber como e por que as decisões são tomadas.
Costumamos dizer que, no início de quem está começando no papel, há insegurança. É natural não saber qual é a melhor decisão e ficar em dúvida entre o caminho A ou o B. Usem mentores para apoiar esse processo; quem pode orientar são, em geral, pessoas que já estão atuando como liderança técnica. Conversem com outras lideranças técnicas para entender como elas decidem, por que escolhem o caminho A ou B e, gradualmente, quem está começando nesse papel vai ganhando “músculo” para ter mais clareza e confiança para decidir sem recorrer sempre à opinião de outras pessoas.
Eu tenho quase 20 anos de carreira, quase metade atuando em liderança técnica. Hoje já tenho “músculo” para saber o que posso e o que não devo fazer e, ainda assim, às vezes peço a opinião da coordenação e da gerência. Não custa nada buscar mais segurança para decidir e também compartilhar decisões.
Evitemos, portanto, o papel de super-herói. Enquanto estamos como pessoas desenvolvedoras sênior, é possível focar muito no desempenho individual. Reforçamos isso em outras ocasiões: ao migrar para a liderança técnica, deixa de ser sobre o nosso desempenho individual e passa a ser sobre o desempenho do time — quão eficiente é o nosso trabalho para tornar o time cada vez mais eficiente. Tornamo-nos muito mais estratégicos do que operacionais. O “super-herói” é um mito a ser desconstruído: liderança técnica não é, definitivamente, ser super-herói. Competência técnica elevada ajuda muito o time, mas não pode parar aí; o papel passa a se orientar para outras dimensões.
Sigamos. Qual é o custo quando uma liderança técnica tenta ser super-herói? O custo é altíssimo. Erros críticos, revisões de PRs, dúvidas de arquitetura, decisões de design e múltiplas demandas convergem. Se visualizarmos um funil, entra um volume grande de itens, e se a liderança técnica é a única a desbloquear, haverá gargalo — não tem outro resultado. Isso cria:
No nosso time, estamos introduzindo práticas para mitigar esses riscos. Por exemplo, conhecimento compartilhado: mantemos uma página de documentação na qual registramos tudo o que é feito, com documentação técnica acessível ao time. Isso reduz concentração de conhecimento, facilita a autonomia e diminui o risco operacional.
Houve um caso recente em que uma pessoa engenheira saiu de férias e apenas ela conhecia determinado sistema legado. Quando isso aconteceu, não tínhamos ninguém que dominasse o sistema para poder atuar. Precisamos intervir, exercendo a liderança técnica, assumindo a responsabilidade de entender o contexto, investigar o histórico e identificar que não havia documentação. Diante disso, revisamos o histórico do Git para compreender como as coisas tinham sido feitas anteriormente.
No final, conseguimos resolver. Assim que identificamos a solução, criamos uma página de documentação técnica para garantir que, se amanhã não estivermos disponíveis, qualquer outra pessoa consiga acessar essa página, entender como solucionar o problema e seguir adiante. Esse é o papel de uma pessoa líder técnica eficiente: compartilhar conhecimento e democratizá-lo, para que qualquer pessoa da equipe seja capaz de resolver o problema, evitando dependência de especialistas únicos em temas específicos ou de “donos de domínio”.
Já vivenciamos diversos casos: férias, incidentes, code review (revisão de código) parado, reuniões excessivas e vários outros sintomas de uma equipe que ainda não alcançou autonomia real. O primeiro passo é reconhecer o padrão: quase sempre existe uma pessoa centralizadora tentando ser “super-herói”. Não devemos ser essa pessoa.
Se atualmente exercemos a liderança técnica e atuamos de maneira centralizadora, precisamos dar um passo atrás, observar nossa atuação e avaliar se realmente estamos sendo eficientes ou se estamos apenas tentando provar nosso valor a qualquer custo, esquecendo que nosso valor se demonstra por meio do desempenho do time, não apenas pelo que fazemos diretamente. Devemos refletir: se hoje nossa equipe nos avaliasse, receberíamos uma avaliação positiva como boa liderança técnica que ajuda as pessoas a evoluir e destrava o time, ou seríamos vistos como centralizadores que tentam ser super-heróis?
Para quem ainda não está no papel de liderança técnica, vale a reflexão: a liderança técnica que temos hoje, ou as pessoas de referência técnica ao nosso redor, trabalham de forma distribuída ou centralizada? Vamos conectar isso com a prática: o modelo ideal é o que estamos apresentando aqui. Precisamos verificar se ele se encaixa com o que vivemos hoje — tanto para quem já está em uma posição de liderança quanto para quem está a caminho — e identificar se estamos trabalhando de uma forma ou de outra.
Ao deixarmos de atuar como pessoas desenvolvedoras sênior e passarmos à liderança técnica, o que muda de competência? Quando estamos no papel de desenvolvimento, ainda é mais aceitável centralizar, porque temos tarefas próprias e responsabilidades diretas. Indiretamente, mesmo como pessoa desenvolvedora sênior, já ajudamos outras pessoas e temos a responsabilidade de democratizar o conhecimento; isso não é exclusividade da liderança técnica. Ainda assim, é comum pensar: “Nós resolvemos mais rápido”, “Sabemos fazer”, “O time espera nossa aprovação”. Porém, isso muda quando assumimos a liderança técnica: essa postura deixa de ser aceitável.
Passamos a ser multiplicadores de capacidade. O time aprende, decide com critério e o sistema funciona sem que tudo precise passar por nós. A decisão é distribuída, praticamos mentoria ativa e mantemos padrões claros e compartilhados. Existem duas faces da mesma moeda: a pessoa que centraliza e a que trabalha de forma distribuída. A transição não significa abandonar a excelência técnica, mas colocá-la a serviço do coletivo. Deixamos de ser quem sabe tudo para nos tornarmos quem faz com que todas as pessoas saibam.
Para este vídeo, nosso objetivo é fazer uma primeira introdução e desconstruir um mito muito forte sobre liderança técnica. Gostamos de ilustrar com o filme Top Gun e, mais recentemente, com Top Gun: Maverick, que é uma continuação direta. Maverick é excelente tecnicamente e como executor, mas é um gestor e líder ruim. Ele sabe executar muito bem, porém tem dificuldade em organizar um time e torná-lo eficiente. Na história, o time não está performando bem; ele entra, mostra que é possível executar e prova isso ao grupo. Temos novamente as duas faces: ele começa sem saber liderar ou gerir, é muito bom executando, mas, ao longo do filme, aprende. O time estava desmotivado porque não conseguia; então ele mostra que é possível.
Às vezes, teremos de ser quem demonstra ao time que é possível, mas isso deve ser exceção. Só devemos entrar e executar quando o time não está conseguindo ou quando a moral está baixa. Entramos, mostramos, fazemos junto, provamos que é possível — sempre com foco no coletivo, no time, e nunca no desempenho individual. Em Maverick, essa intervenção elevou a moral e levou o time junto. Ele acabou indo na missão porque dominava um voo necessário, e, ao final, tornou-se uma boa liderança: alguém que ninguém esperava que fosse, que nunca tinha sido promovido e que sempre esteve no mesmo posto. No fim, foi uma boa liderança porque uniu técnica e gestão; as coisas se complementaram.
Como é, então, o “super-herói” de hoje? O “super-herói” que realmente funciona — não o mito que acha que sabe tudo —, para fechar este vídeo, é a pessoa líder técnica que sabe delegar a quem, por que e quando intervir. Ou seja, sabe quando entrar. No exemplo de Maverick, ele soube exatamente o momento de intervir.
Julgamento: distinguir o que exige atenção imediata do que pode esperar. Nem tudo é urgente; às vezes algo é importante, mas não urgente, ou urgente, mas não importante. O Quadrante de Eisenhower ajuda nessa decisão e vale a pena pesquisá-lo, pois é muito útil.
Critério: definir o padrão de qualidade que o time persegue de forma autônoma. Ter documentação clara, padrões definidos com o time sobre o que se deve e não se deve fazer, padrões de commit (registro de alterações), documentação que servirá como referência e acordos explícitos — por exemplo: não realizar deploy (implantação) às sextas-feiras nem às segundas-feiras. Critério claro, documentação clara, centralizada, democratizada e disponível para todas as pessoas.
Guardrails (barreiras de segurança): limites explícitos que impedem o time de fazer coisas equivocadas e garantem segurança sem microgestão. O time sabe o que pode e o que não pode fazer, porque as regras do jogo foram combinadas. Não precisamos vigiar tudo o tempo todo. Não é necessário nos tornarmos gargalo aprovando tudo que o time faz, pois a equipe sabe trabalhar. Podemos nos aproximar mais em alguns momentos para garantir qualidade e, gradualmente, afrouxar a supervisão conforme percebemos que o time atua corretamente.
Intervenção precisa: saber o momento certo de entrar — nem cedo demais, nem tarde demais. Como no exemplo: Maverick interveio quando viu o time extremamente desmotivado, para mostrar que era possível. E nós, como liderança — em algumas empresas a gestão se combina com a liderança técnica; em outras, os papéis estão mais separados, mas indiretamente já atuamos um pouco como gestão — precisamos saber o momento de entrar, quando deixar o time avançar com as próprias mãos e quando, após esgotar as possibilidades, pedir ajuda, trazer reforços ou agregar nosso conhecimento.
Se entrarmos sempre com nosso conhecimento e não deixarmos o time tentar primeiro, o grupo não evolui. Nem cedo demais nem tarde demais: esse discernimento diferencia a liderança que tira o time do atoleiro quando ele não consegue resolver daquela que carrega o time nos braços o tempo todo, tratando profissionais como se fossem pessoas que precisam de ajuda constante e supervisão permanente.
Precisamos lembrar que o time é formado por pessoas competentes, adultas, que devem saber tomar decisões. Se o time ficar dependente de nós, nunca será autogerenciável nem crescerá. Mesmo quando o time erra, o erro é fundamental para o crescimento. As pessoas precisam errar para entender quando estão fazendo um bom trabalho e quando não, e assim evoluir como pessoas e como profissionais. Erramos, aprendemos, não repetimos o mesmo erro e seguimos em frente — é assim que crescemos até encontrar nosso caminho.
Eu encerro por aqui neste vídeo. Nos vemos no próximo vídeo.
Olá! Seja bem-vinde de volta.
No vídeo anterior, discutimos o mito do super-herói. Neste vídeo, vamos detalhar quais são as competências reais de uma pessoa Tech Lead (liderança técnica), isto é, o que de fato se espera desse papel. Para organizar a discussão, vamos dividir em quatro quadrantes: engenharia, arquitetura, agente de mudança e senso de dono.
Espera-se que uma boa pessoa Tech Lead navegue pela engenharia com profundidade técnica para avaliar soluções, reconhecer riscos e manter o padrão de qualidade da equipe. Precisamos dominar arquitetura, com repertório em diferentes abordagens e clareza sobre qual se ajusta melhor a cada contexto. A visão sistêmica é essencial para antecipar impactos, conectar decisões e garantir coesão técnica no longo prazo. Um sistema mal concebido não se sustenta: pode funcionar bem no início, mas, aos poucos, degrada e colapsa.
Podemos comparar com a construção de um edifício. Se a fundação for bem pensada e bem executada, o prédio se mantém. Porém, é preciso projetar a sustentação considerando a quantidade de andares. Uma fundação adequada para um prédio de três andares não é a mesma para um de vinte. Portanto, precisamos nos adaptar ao contexto e entender qual arquitetura melhor atende a cada situação.
Além disso, atuamos como agente de mudança: movemos a equipe, criamos adesão a novos padrões e conduzimos transições com clareza. Isso inclui “vender” bem as mudanças. Em equipes que trabalham de um determinado modo há muito tempo, a chegada de uma pessoa Tech Lead nova pode gerar resistência, sobretudo quando surgem várias ideias e propostas de alteração. Precisamos conquistar a equipe e comunicar de forma cuidadosa. O objetivo não é mudar por mudar, nem por considerar que o trabalho atual é ruim. Reconhecemos o que já foi feito, valorizamos os resultados e mostramos que podemos ser ainda melhores ao introduzir determinada ferramenta ou processo. Com tato, vamos convencendo gradualmente, sempre com fundamentação sólida e acordo coletivo.
Fechando as competências esperadas, entra o senso de dono. Assumimos o impacto das decisões do time e não encaramos escolhas como se fôssemos meramente pessoas empregadas sem responsabilidade. Tomamos decisões como se a empresa fosse nossa, considerando os efeitos reais. Assim como fazemos em nossas vidas pessoais — por exemplo, ao decidir gastos, avaliando se podemos, se fará falta depois e se todas as contas estão pagas —, trazemos essa mesma preocupação para o contexto do negócio, da empresa e da equipe. Também entendemos que nossas decisões têm impacto real na vida das pessoas. Mesmo quando não temos propriedade direta para contratar ou desligar, análises sobre desempenho podem servir de insumo para promoções ou desligamentos. Por isso, precisamos de muito cuidado com o que dizemos, lembrando que nosso papel principal é fazer com que as pessoas tenham sucesso. Se a maioria estiver indo mal, isso pode indicar que nosso trabalho não está efetivo.
Há casos em que alguém realmente não está contribuindo, gera prejuízo ou atraso, não demonstra intenção de melhorar e todas as tentativas de apoio já foram esgotadas. Nesses cenários, o desligamento ou a realocação podem ser o único caminho. Entretanto, essa deve ser a exceção. Nosso trabalho é fazer com que as pessoas trabalhem com eficiência. Isso também está ligado ao senso de dono, pois a alta rotatividade é ruim para nós, para a equipe e para a empresa. Portanto, cuidamos da empresa e do produto como se fossem nossos.
Mantemos a mesma base técnica, mas mudamos a “lente”. A base que tínhamos como pessoas desenvolvedoras, especialmente no nível sênior, continua válida; porém, como Tech Lead, passamos a observar de cima, com uma perspectiva mais ampla. Isso acontece, entre outros motivos, porque passamos a ter mais contato com a gestão, coordenações e visão de longo prazo da empresa — para onde a organização quer ir. Muitas decisões do time precisam ser avaliadas à luz desse horizonte, não apenas no contexto imediato da equipe. Atuamos como ponte de comunicação: do time para a empresa e da empresa para o time.
Quanto ao que se espera no dia a dia, falamos sobre a supervisão das entregas técnicas. A pergunta deixa de ser “sabemos fazer?” e passa a ser “sabemos avaliar se está bem feito?”. Precisamos avaliar:
Não precisamos, necessariamente, revisar todo o código e todas as solicitações de integração, sob risco de nos tornarmos gargalo. Podemos adotar ferramentas de análise estática e utilizar IAs para apoiar a revisão. Para cobertura de testes, também implementamos ferramentas e práticas que auxiliam nesse controle. Em relação à documentação técnica, estabelecemos um acordo com a equipe: tudo o que for feito e ainda não estiver documentado deve receber documentação. A pessoa Tech Lead pode, inclusive, documentar suas próprias entregas para apoiar o time e facilitar a manutenção futura, mas, principalmente, isso precisa fazer parte do fluxo do time — idealmente integrado à definition of done (definição de concluído).
Hoje não há desculpa para não produzir documentação técnica. Antes, reconhecemos que era difícil separar tempo para escrever conteúdos extensos e bem estruturados. Agora, agentes de IA geram textos coesos a partir de uma base fornecida e podem até publicar automaticamente. No Itaú, por exemplo, usamos a Devin. Quando especificamos o que queremos e onde publicar, a ferramenta — com acesso ao Git — cria o código, abre um pull request (solicitação de integração) e, após fazermos o "merge" (mesclagem), a documentação é publicada e democratizada, acessível para todas as pessoas. Portanto, documentação técnica deve ser critério obrigatório.
Em análise de logs (registros) e observabilidade, todas as pessoas do time precisam ter fluência, mas a pessoa Tech Lead em especial deve saber onde e como analisar, orientar o restante da equipe e garantir a execução correta. Aqui entra a eficiência técnica: além de saber fazer, precisamos ensinar, transferir conhecimento, exigir a execução adequada e, sobretudo, avaliar entregas feitas com apoio de IA. Vivemos uma realidade em que a IA é parte integrante do time, e a pessoa Tech Lead que não sabe lidar com ela nem orientar o melhor uso deixa de ser eficiente, porque essa é a realidade atual de trabalho em tecnologia.
Atualmente, temos equipes que não deixam de usar ao menos uma ferramenta de IA, seja para desenvolver, seja para criar documentação ou para atividades semelhantes. Qual é o critério de avaliação que devemos adotar como Tech Lead (pessoa líder técnica)? Nossa visão de outputs (resultados) já não depende exclusivamente de quem gerou o artefato. Precisamos avaliar com critério objetivo: se está correto, testado e seguro, quem assume a responsabilidade? Isso se conecta diretamente com o Code Review (revisão de código). O critério de qualidade é independente da auditoria.
Podemos adotar o seguinte princípio: acima da auditoria, o resultado precisa ser compreendido, validado e assumido por alguém. Conectando com o que já dissemos, independentemente de termos sido nós ou não quem escreveu esse código ou quem está fazendo essa entrega, como Tech Lead (pessoa líder técnica), nós precisamos ser capazes de avaliar e também de identificar se a ferramenta correta foi usada, se a IA foi utilizada de forma adequada. Às vezes, alguém pode simplesmente ter delegado para a IA e feito o envio desse código sem criticá-lo antes, sem testá-lo previamente, sem garantir que tudo foi corretamente testado, que foram desenvolvidos testes unitários. Precisamos criticar isso e saber como acordar esses padrões com o time.
Quem digitou não é a pergunta principal. A origem do código pode ser humana ou assistida por IA; isso é secundário frente à qualidade e à segurança do resultado. Não importa tanto quem fez, se foi uma pessoa desenvolvedora, se foi uma IA ou se foi um híbrido. O que importa é o que está sendo efetivamente entregue, com todos os padrões que devem ser cumpridos, todos os critérios acordados com o time e todos os critérios de qualidade: passou no Sonar, tem cobertura de 100%, tem testes unitários. Ao falar de cobertura, referimo-nos a testes unitários, mas é essencial que esses testes cubram 100% e que todas as verificações estejam passando.
Tudo isso pode ser colocado na pipeline (esteira de entrega): se não passar, é critério de exclusão para que a pipeline (esteira de entrega) falhe. Há várias técnicas para fazer isso, inclusive na prova de qualidade de código. Mostramos um pouco como fazer, mas vamos prosseguir para não perder o foco.
Quem assume a responsabilidade? Todo PR, toda decisão arquitetural e todo deploy (implantação) precisam de uma pessoa responsável humana identificada e ciente do risco. Não importa se não fomos nós quem criou esse padrão arquitetural. Não importa se não fomos nós quem tomou a decisão, desde que estejamos de acordo e conscientes, porque, no final, se no futuro alguém questionar, não perguntarão diretamente ao time; perguntarão a nós. Precisamos estar muito conscientes e a par do que o time está entregando — sem nos tornarmos gargalo, sem depender de o time encaminhar tudo para nossa aprovação para que as coisas aconteçam, mas, no mínimo, sendo comunicados.
Podemos participar eventualmente de alguns Code Reviews (revisões de código). Podemos participar eventualmente do desenvolvimento de algo, conversando com a pessoa desenvolvedora para entender como chegou àquele ponto, o que desenvolveu, quais decisões tomou e quais ferramentas utilizou, para verificar se os padrões estão sendo seguidos. A responsabilidade segue sendo nossa, ainda que não estejamos assinando tudo diretamente. Precisamos estar a par do que as pessoas fazem e de como fazem.
Que evidência sustenta a decisão? Testes, logs (registros) e revisão por pares. Quando o PR passou e foi aprovado por pelo menos duas pessoas, pode ser que não tenhamos aprovado diretamente; não importa. Se pelo menos duas pessoas aprovaram, significa que mais pessoas revisaram esse código e garantiram que segue os padrões. Quanto aos logs (registros), quando executamos o projeto, eles mostram que tudo está ocorrendo corretamente ou indicam muitos erros. O índice de erro no sistema é um alerta e precisamos nos preocupar com isso. Não devemos ter logs (registros) de erro o tempo todo; erro deve ser exceção, quando ocorre um problema não previsto. É papel do Tech Lead (pessoa líder técnica) vigiar esses padrões.
O raciocínio documentado é a evidência que torna a decisão defensável. Quando há documentação do que foi feito, precisamos concluir: que evidência sustenta? Ao subir uma alteração, temos evidência de que isso foi testado? Temos captura de tela mostrando que foi testado e teve sucesso, ou os logs (registros) gerados após a execução? Tudo isso deve ser anexado quando fazemos uma entrega, porque, depois, se ocorrer algum problema, nós, como Tech Lead (pessoa líder técnica), teremos sustentação e argumentos para comprovar que aquilo funcionou e foi desenvolvido da forma correta.
Se a área que está validando, que usa o que foi desenvolvido, encontrou problemas ou algo diferente do que precisava, pode ser que a especificação inicial também não tenha sido clara. Só saberemos disso se tivermos a especificação do que foi pedido versus o que foi entregue. Se pediram A e entregamos A, e agora se trata de A.1 ou A+B, isso é uma nova solicitação. Caso contrário, ficamos expostos. Sem a documentação do que foi pedido e do que foi entregue, se alguém disser que está errado, como vamos provar que estamos certos? Como vamos provar que o time fez um bom trabalho e que, na realidade, o que está sendo pedido agora é uma nova solicitação? Isso ocorre com frequência.
Portanto, saber quem entregou não é o mais importante; o mais importante é o que se entrega. A responsabilidade segue sendo nossa, como liderança do time, como liderança do grupo e como Tech Lead (pessoa líder técnica). Devemos fomentar evidências. Esses três pontos são critérios que estarão acima de qualquer auditoria, porque estamos fazendo o trabalho de forma correta, garantindo que o time navegue pelo que é mais importante. Mais do que sermos gargalo, estamos fazendo um bom trabalho e dotando o time de evidências, provas e trabalho bem feito.
No fim, o Tech Lead (pessoa líder técnica) precisa ser multiplicador. O valor do Tech Lead (pessoa líder técnica) aparece quando o time melhora sem depender dessa liderança em cada passo; quando coordenamos bem o jogo; quando distribuímos conhecimento; quando atuamos para que as pessoas cresçam, se autoexijam e façam autorreflexões; quando as pessoas evoluem mesmo sem nossa presença. Precisaremos nos ausentar. O time segue funcionando bem quando não estamos? Se sim, significa que estamos fazendo um trabalho excelente. Estamos presentes para ajudar a coordenar quando algo sai do padrão, quando alguém da empresa solicita algo e ajudamos a transmitir ao time, ou quando entramos em um problema crítico para ajudar a resolver e a tomar as melhores decisões. No dia a dia, o time precisa funcionar sem que estejamos presentes o tempo todo; caso contrário, tornamo-nos gargalo, passamos a microgerenciar e não somos uma liderança eficiente.
Alguns elementos que fazem parte do papel do Tech Lead (pessoa líder técnica) como multiplicador:
Isso era tudo para este vídeo. Nos vemos em um próximo vídeo.
O curso Tech Lead: guiar times para alta performance possui 338 minutos de vídeos, em um total de 41 atividades. Gostou? Conheça nossos outros cursos de Liderança 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.
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:
Catálogo de tecnologia para quem é da área de Marketing
Envie imagens para a Luri e ela te ajuda a solucionar problemas, identificar erros, esclarecer gráficos, analisar design e muito mais de forma ilimitada.
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.
