Olá, e sejam muito bem-vindos a mais um curso da Alura. No curso de hoje, nós vamos tratar do papel de Tech Lead (liderança técnica), produto, ciclo de vida, roadmaps (roteiros estratégicos) e decisão técnica. Este é um curso completo para pessoas Tech Lead que desejam influenciar o produto, construir roadmaps com fundamento e tomar decisões técnicas com impacto real no negócio.
Antes de começar, vou me apresentar e fazer minha audiodescrição.
Audiodescrição: Eu sou um homem branco, com barba por fazer, cabelos castanhos claros, uso óculos de armação preta redonda e visto uma camisa preta da FIAP. Ao fundo, há uma parede branca com uma luz roxa e uma luz rosa.
Falando sobre minha trajetória, atualmente eu trabalho como Tech Lead no Itaú, sou instrutor na Alura e professor de graduação na FIAP. Tenho cerca de 19 anos de experiência na área de tecnologia, com atuação em mentoria e evolução de times técnicos. Sou especialista em arquitetura de software e sistemas escaláveis, possuo certificações da AWS e de metodologias ágeis e tenho vivência cotidiana com roadmaps, priorização e decisão técnica.
Por que este curso existe? Nós preparamos uma imagem no slide para ilustrar um ponto central: na primeira figura, há um abismo entre duas áreas; na segunda, uma ponte as conecta. Essas áreas são produto e engenharia. Se não existe a figura da pessoa Tech Lead e essa pessoa não participa das decisões desde o Discovery (descoberta), isto é, desde o início da concepção do produto, teremos muitos problemas. Encontraremos diversas barreiras técnicas que poderiam ser identificadas no começo, mas que passam despercebidas por falta de quem as aponte.
Quando a engenharia entra tarde, o abismo aparece no meio do caminho. Quando se avança sem enxergar as restrições técnicas, o custo de mudança já é alto. Depois de gastar muito tempo e muito dinheiro, é preciso recriar componentes, descartar trabalhos e refazer entregas. Isso é caro e, muitas vezes, não há orçamento nem tempo.
A pessoa Tech Lead entra como a ponte antes do abismo: conecta a visão de produto à realidade técnica, permitindo que decisões melhores sejam tomadas antes que o custo apareça. É fundamental que, enquanto pessoa Tech Lead que está assistindo a este curso, você compreenda que seu trabalho também é tornar o produto e o negócio mais eficientes com base em decisões técnicas sólidas. É por isso que este curso existe. Esta é apenas uma amostra do que veremos ao longo das aulas.
Como o curso está dividido? Organizamos o conteúdo em cinco aulas:
Para quem este curso é indicado? Este curso é especialmente voltado para pessoas Tech Lead em atuação. Se você já exerce essa função no dia a dia, ele é altamente indicado. Também é ideal para pessoas Tech Lead que lideram times e desejam ampliar sua influência para além da execução técnica, atuando na estratégia de produto. Esse papel é estrategicamente orientado e muitas vezes prepara para assumir cargos de coordenação ou gerência, exigindo visão voltada ao negócio, compreensão de quem é o cliente final e dos requisitos de negócio.
Costumamos afirmar em nossos cursos que quem entende o negócio para o qual está construindo um produto trabalha de forma muito mais eficiente do que quem foca apenas em questões técnicas.
Nós recomendamos que você não atue como mero espectador ou espectadora. Em vez de apenas assistir às aulas, faça pausas periódicas e reflita sobre como encaixar cada conceito aprendido na sua realidade. Considere exemplos reais do seu cotidiano e aplique-os às situações de exemplo que apresentaremos. Em vários momentos criaremos situações fictícias e, quando mencionarmos casos reais, poderemos omitir alguns dados; por isso, vale substituir pelos seus próprios contextos com pessoas e informações do dia a dia.
Este curso faz parte da carreira de Tech Lead (liderança técnica) disponível na Alura. Naturalmente, faremos conexões com outros temas já abordados ao longo da trilha. Qualidade e liderança de pessoas constroem a base; produto, roadmap (roteiro) e decisão técnica determinam a direção e o destino.
Este curso ocupa um lugar específico na evolução da carreira de Tech Lead: pressupõe fundamentos de qualidade de software e liderança de pessoas, e agora eleva o jogo para um nível mais estratégico. A composição é a seguinte:
Apresentamos uma visão em cinco espectros:
O resultado esperado é um ou uma Tech Lead com visão de produto.
Este foi um vídeo introdutório de apresentação. Nos vemos no próximo vídeo.
Olá e seja muito bem-vindo de volta para mais um vídeo. No vídeo anterior eu me apresentei e apresentei um pouco do curso para você.
Neste vídeo, vamos começar a entrar no tema do curso. Nós vamos falar sobre o ciclo de vida do produto digital e o papel do Tech Lead (liderança técnica). O produto não começa na sprint (iteração); ele começa muito antes, e a engenharia precisa estar presente desde o início. Mencionamos isso no vídeo anterior, naquela imagem ilustrativa.
Todo produto digital passa por fases, e cada fase exige um tipo de comportamento específico. Quando a engenharia entra cedo, as restrições técnicas informam decisões de produto, hipóteses são validadas antes do comprometimento e a arquitetura fica alinhada à direção estratégica. Quando a engenharia chega tarde — ou seja, quando produto e negócio tentam fazer a fase de Discovery (descoberta) sem envolver a engenharia — decisões irreversíveis já foram tomadas, ocorre retrabalho, surgem reestimativas constantes e o time passa a apagar incêndios em vez de construir.
É fundamental que essas duas áreas — produto e engenharia — avancem em conjunto desde o momento em que o produto está sendo descoberto e concebido.
Quais são as fases no ciclo de vida de um produto? Temos Discovery (descoberta), Delivery (entrega), escala e evolução contínua. Cada fase exige uma postura técnica muito diferente. Não existe uma arquitetura ou abordagem técnica que funcione para todas as fases do produto. O ou a Tech Lead (liderança técnica) precisa entender em que fase o produto está e tomar decisões muito mais precisas do que quem aplica as mesmas soluções em qualquer contexto.
Vamos aprofundar o que caracteriza cada uma dessas fases.
Na fase de Discovery (descoberta), o objetivo é validar hipóteses antes de construir. A velocidade de aprendizado fica acima de tudo. É a fase em que não importa se o produto é escalável, se está usando a melhor tecnologia, a melhor cloud (nuvem) ou a melhor opção de mercado. O que importa é entender se o produto resolve um problema real e atende à necessidade da pessoa cliente. Nesse momento, o negócio traz a necessidade, o produto ajuda a estruturá-la e a engenharia começa a levantar questões. Por exemplo: se o produto for pensado para um público pequeno, podemos reduzir custos com uma arquitetura mais simplificada. Se, desde o início, negócio e produto indicarem que o produto será pensado para milhões de pessoas usuárias, a engenharia precisa posicionar que não pode ser construído de qualquer jeito; é necessário planejar bem, desenhar para ser escalável e dimensionar o poder de processamento conforme a quantidade de pessoas usuárias. Assim, com poucas pessoas usuárias, o sistema consome pouco processamento e gera baixo custo, e, à medida que cresce, escala automaticamente. Existem técnicas consolidadas hoje para viabilizar isso.
Na fase de Delivery (entrega), o foco é entregar com qualidade e gerar aprendizado a cada ciclo de entrega. É quando iniciamos a construção. Em metodologias ágeis, é premissa que cada sprint (iteração) entregue uma funcionalidade pronta para uso, para que possamos testar, aprender rápido e corrigir rápido. Nessa etapa, é fundamental que produto e engenharia conversem constantemente para verificar se a proposta de negócio e a funcionalidade criada funcionam no mundo real e se a decisão técnica de como construir também atende às necessidades reais. Durante o Discovery (descoberta), tudo é mais abstrato: partimos de suposições e ainda não temos um software (programa) real com pessoas usuárias reais utilizando.
Em seguida, avançamos para a fase de escala: sustentar o produto sob crescimento real de uso e volume. Em Delivery (entrega), geralmente há um grupo restrito de pessoas usuárias testando a ferramenta ou o software (programa) para validar funcionalidades e encontrar problemas rapidamente. Não é ainda um uso em larga escala. Já na fase de escala, o produto está pronto para o mercado e passa a ser utilizado por pessoas usuárias reais em volume. Precisamos acompanhar de perto, usar observabilidade e tornar o software (programa) altamente testável para garantir que qualquer mudança não gere impacto negativo para quem já utiliza o produto. Mais uma vez, é essencial que negócio, produto e engenharia atuem em conjunto nesse ciclo de vida.
Por fim, chegamos à evolução contínua: adaptar, não apenas manter. O produto responde ao ambiente. Lá na fase de Discovery (descoberta), podemos ter imaginado o produto de um jeito, mas, ao passar por Delivery (entrega) e escala, percebemos melhorias e mudanças no comportamento das pessoas usuárias. Comportamentos mudam ao longo do tempo, e estamos falando de fases que podem durar muitos anos — não é algo que se conclui em poucos meses. O Discovery (descoberta) pode levar meses ou anos, o Delivery (entrega) também, e a escala igualmente. A evolução contínua é o ato de estarmos sempre melhorando, observando o comportamento das pessoas usuárias e modificando o produto de acordo com isso.
Muitas empresas que não praticaram evolução contínua não perceberam movimentos do mercado e acabaram encerrando suas atividades. Possuíam soluções excelentes e produtos relevantes, mas não se adaptaram às necessidades das pessoas usuárias. Um exemplo clássico é a transição das locadoras físicas para os serviços de streaming (transmissão digital). As locadoras físicas foram uma explosão em determinada época, mas não perceberam a evolução das necessidades das pessoas usuárias e da tecnologia, e desapareceram. Hoje, o comum é termos muitos sistemas de streaming (transmissão digital), com a Netflix como pioneira. Para quem não sabe, a empresa começou como uma locadora de filmes físicos: as pessoas acessavam um catálogo na internet, alugavam o filme, recebiam em casa e depois devolviam. A Netflix percebeu que já preparava o terreno para deixar de trabalhar com filmes físicos e passar a oferecer filmes digitais. Esse é um ótimo exemplo de evolução contínua: uma empresa que acompanhou as necessidades das pessoas usuárias e evoluiu para não deixar de existir. Muitas outras não fizeram isso e ficaram pelo caminho.
É fundamental observar cada fase com atenção e agir de acordo.
Um comportamento que teremos em delivery (entrega) é diferente do comportamento em discovery (descoberta). Além disso, precisamos observar que o ciclo de produto e o ciclo técnico são distintos. Por isso, as áreas devem se comunicar para que essas etapas aconteçam ao mesmo tempo, em conjunto. Caso contrário, quando o produto estiver na fase de descoberta, estará explorando apenas o aspecto conceitual, sem aplicar essa investigação a necessidades reais de engenharia.
A engenharia deve ouvir as necessidades de produto — problemas e oportunidades — e traduzir isso em como construir no mundo real: como será feito? Em qual tecnologia? Em qual cloud (nuvem)? Qual tipo de arquitetura será utilizada? O produto evolui por hipóteses; a engenharia evolui por decisões. Enquanto o produto pensa no que pode ser, a engenharia não tem esse tipo de dúvida: definimos exatamente o que será construído e onde. Pode ser que amanhã mude? Pode. Mas qual é o custo dessa mudança? Por isso, uma mudança posterior em engenharia tende a ser mais cara. Uma mudança de produto, em geral, significa implementar uma nova funcionalidade ou adaptar uma existente — é mais simples. Não estamos dizendo que é fácil ou sem custo, mas a engenharia precisa se preocupar com os impactos, e o papel de Tech Lead (liderança técnica) é realizar essa ponte. Quando produto e engenharia estão desalinhados, a conta chega em forma de retrabalho. Como mencionamos, acabamos gastando tempo destruindo o que já foi construído para reconstruir do zero.
Como funciona geralmente um ciclo de produto? Parte 1: Descobrir — identificar problemas e oportunidades. Fase 2: Validar — testar hipóteses com pessoas usuárias. Fase 3: Construir — desenvolver a solução validada. Para fechar, Fase 4: Aprender — medir e retroalimentar o ciclo. É quando começamos a entender se as hipóteses criadas nas fases 1 e 2 (descobrir e validar) se justificam na vida real, após a construção.
Já o ciclo técnico funciona assim: Fase 1: Arquitetura — definir estrutura e padrões. Fase 2: Implementação — construir com qualidade e testes. Fase 3: Operação — sustentar e monitorar a produção usando técnicas de observabilidade para verificar se o produto se comporta bem ou se apresenta muitas falhas. Fase 4: Evolução — refatorar, escalar e adaptar.
Tudo isso só acontece de forma sustentável se engenharia e produto avançarem pelas fases em conjunto. Enquanto produto está descobrindo, o time de engenharia está junto descobrindo, identificando problemas e começando a pensar em possibilidades de arquitetura. Enquanto produto e negócios validam testando hipóteses com pessoas usuárias, a engenharia implementa e constrói com qualidade e testes em conjunto. Enquanto produto constrói e desenvolve a aplicação validada, a engenharia opera, sustentando e monitorando. Enquanto produto aprende, a engenharia evolui, refatorando, escalando e adaptando. Quando um ciclo acelera sem o outro, o débito técnico cresce ou o produto fica obsoleto antes da hora.
O impacto da arquitetura em cada fase é significativo. A arquitetura adequada para discovery (descoberta), como já mencionamos, não é a mesma que sustenta a escala. Cada fase do produto demanda prioridades arquiteturais distintas. Forçar a arquitetura de escala no discovery (descoberta) é tão prejudicial quanto chegar à escala com a arquitetura de discovery (descoberta). Em muitos casos, quando estamos descobrindo e testando hipóteses, a arquitetura deve ser a mais simples possível para entrar rapidamente no mercado, sem demandar muito tempo ou dinheiro.
Na fase de discovery (descoberta), a prioridade é simplicidade e velocidade de experimento. Publicamos rápido, testamos rápido, validamos rápido e, depois, descartamos e reconstruímos. O objetivo é obter validação em um produto real. Não adianta termos a melhor arquitetura e tecnologia, preparada para um milhão de pessoas usuárias, se não houver adoção. Devemos evitar overengineering (engenharia excessiva) prematura. Excesso de preocupação com clean code (código limpo), arquiteturas sólidas e escalabilidade, nesse momento, é desperdício de tempo e dinheiro.
Em delivery (entrega), a prioridade é confiabilidade e rastreabilidade. Ao construir, precisamos garantir que o sistema seja confiável e rastreável: quando ocorrer um problema, devemos identificar onde ocorreu, por que ocorreu e corrigir rapidamente para que ninguém fique impedido de utilizar. Nessa etapa, é fundamental que o sistema funcione muito bem e de forma fluida, permitindo validações cada vez mais rápidas do produto no mundo real. Devemos evitar abrir mão de testes ou observabilidade — não fazer trade-off (compensação) entre testes/observabilidade e entrega de funcionalidades. Isso é crítico, pois problemas podem gerar perda de confiança das pessoas usuárias.
Na fase de escala, as prioridades são resiliência, observabilidade e performance. Aqui a régua arquitetural sobe. Passamos a enfatizar clean code (código limpo), testes de todos os tipos — testes unitários e testes end-to-end (de ponta a ponta) — e soluções de observabilidade como Datadog ou CloudWatch, integradas em cada ponto do sistema para oferecer rastreabilidade completa. Devemos evitar monólitos sem fronteiras definidas. Quanto mais o sistema estiver todo acoplado, mais difícil será entender onde está o problema. Ao separar por camadas com responsabilidades específicas, fica mais simples entender e isolar a falha: se está no front-end (camada de interface), no back-end (camada de serviços), em alguma camada intermediária ou em um serviço específico. Em um back-end monolítico único e grande, um serviço com falha pode paralisar todo o sistema. Em uma arquitetura de microsserviços, se um serviço parar, o restante continua operando, dando tempo para correção.
Na fase de evolução contínua, a prioridade é adaptabilidade e baixo custo de mudança. Se construímos pensando na evolução, buscamos mudanças mais orgânicas, sem “derrubar uma parede inteira” para adicionar algo novo. Aproveitamos o que já existe e fazemos microadaptações para melhorar continuamente a experiência das pessoas usuárias. Devemos evitar acoplamento forte entre componentes. Esse cenário é favorecido por uma arquitetura pensada em microsserviços.
Eu encerro por aqui neste vídeo. Eu espero que vocês tenham gostado, que tenham entendido o ciclo de vida de um produto, e nós nos vemos no próximo vídeo.
Olá, boas-vindas de volta a mais um vídeo do nosso curso.
No vídeo anterior, nós falamos sobre os ciclos de vida do produto e sobre o papel da tech lead (liderança técnica). Agora, vamos tratar da participação na discovery (descoberta) técnica. É comum a área de produto e a área de negócios conduzirem a discovery (descoberta) de uma funcionalidade sem envolver a engenharia. Isso é um erro que pode custar caro. Quando a engenharia participa da discovery (descoberta), não entra para tumultuar; entra para salvar o produto de decisões irreversíveis.
O que a tech lead (liderança técnica) pode fazer na discovery (descoberta)? Avaliar a viabilidade técnica de hipóteses, mapear dependências e levantar riscos de implementação antes de o produto se comprometer. O produto pode tomar decisões que não fazem sentido no mundo real ou no contexto de engenharia. A engenharia traduz o produto para o mundo real. Enquanto algo está apenas no âmbito do produto, permanece como hipótese e possibilidade.
Há perguntas técnicas que mudam a direção. Por exemplo: “Esse banco de dados suporta o volume esperado?” Uma pergunta certa na discovery (descoberta) vale mais do que mil horas de retrabalho na delivery (entrega). Se as decisões de produto não forem bem fundamentadas, elas podem custar caro no futuro, inclusive exigindo contratações de recursos que não fazem sentido quando colocamos o produto para funcionar. É papel da engenharia explicitar limitações, compreender o que o produto quer construir, com qual finalidade e para qual pessoa usuária.
Como propor restrições sem travar a exploração? Devemos apresentar restrições como dados, não como vetos. Em vez de “Não podemos fazer X”, dizer “Se fizermos X, precisamos de Y”. Fazer trocas explícitas: “Se fizermos X, vamos precisar de Y”. Isso é melhor do que simplesmente dizer “Não podemos fazer”, pois bloqueia a execução e não oferece alternativas.
Um caso interessante: o produto decide construir uma funcionalidade que requer processamento em tempo real. Faz sentido para a pessoa usuária, mas a engenharia só descobre essa exigência quando a feature (funcionalidade) já foi comprometida com as stakeholders (partes interessadas). O custo técnico explode, pois não houve discovery (descoberta) técnica para justificar a arquitetura necessária. Se a engenharia tivesse participado dessa discovery (descoberta), teria perguntado: “Qual a latência esperada?”, “Qual o volume de eventos?”, “Temos infraestrutura para isso ou precisamos investir primeiro?” Perguntas feitas cedo podem mudar o custo da decisão. É muito diferente um produto que precisa de processamento em tempo real e um que não precisa; a arquitetura é muito distinta nas duas situações.
Seguindo em frente, como evitar decisões tardias? Decisão técnica tardia é decisão cara, e quem paga essa conta é o próprio time. Quanto mais tarde a engenharia descobre uma restrição crítica, maior é o custo de correção. A ideia é simples: o custo de mudança cresce exponencialmente a cada fase do ciclo de vida.
Sinais de entrada tardia: requisitos chegam completos para estimativa, sem espaço para questionamento técnico. Quando produto e negócios já chegam definindo “queremos uma plataforma que usará o banco de dados tal, construída na cloud (nuvem) tal, utilizando a arquitetura tal, para pessoas usuárias X”, entregam algo pronto apenas para execução, sem possibilidade de criticar ou avaliar se faz sentido. Muitas vezes há pessoas com alguma noção técnica do lado de produto e negócios e, por isso, tudo chega “envelopado” apenas para construir.
Como criar pontos de entrada técnica?
A justificativa é simples: o custo de modificar uma decisão errada é muito alto quando já estamos avançados no ciclo. Se o time de produto e negócios não ouvir, isso indica falta de preocupação com custo e uma postura pouco inteligente. Nosso papel é mostrar que não estamos ali para travar, e sim para ajudar a tomar melhores decisões.
Como influenciar sem autoridade formal — o mais importante de tudo? Nós, como tech lead (liderança técnica), não poderemos demandar da área de produto que nos coloquem.
Precisamos realizar um trabalho de convencimento, aproximando as lideranças para mostrar a importância de a engenharia estar junto. Mesmo sem poder formal de decisão, exercemos poder de influência, demonstrando por que a engenharia precisa participar desde a concepção.
Aqui, quando falamos de concepção, não tratamos apenas do início do produto. Referimo-nos à concepção de qualquer funcionalidade. Criamos o produto, realizamos um discovery (descoberta) inicial do todo, e, na sequência, o produto evolui. Novas funcionalidades são inseridas conforme o produto é utilizado por clientes, é descoberto e é mantido. Portanto, precisamos garantir a participação da engenharia em todos os momentos.
Influência técnica não vem do cargo. Ela surge de propostas bem estruturadas, fundamentadas em dados e orientadas pelo entendimento do problema que o produto precisa resolver. Devemos preparar análises antecipadas e levar análises de impacto técnico para as reuniões de produto antes mesmo de serem solicitadas. Quem vem com dados lidera a conversa.
Se já trouxermos dados sobre o porquê, fica mais fácil sustentar o caminho técnico. Em geral, todo produto seguirá certos padrões técnicos. Costumamos ter, ao menos de forma inicial, ideias de arquitetura para diferentes cenários: com poucos usuários ou muitos usuários, com resposta em tempo real ou que não precisa ser em tempo real, e assim por diante. Assim, já podemos chegar às reuniões com fundamentos para o que estamos propondo. Se questionarmos uma decisão ou mostrarmos que ela não é a melhor, precisamos apresentar dados ou exemplos do mundo real. Isso fundamenta e convence muito mais do que apenas argumentar, considerando que nem todas as pessoas têm a mesma bagagem técnica ou os mesmos exemplos que nós.
Também é essencial evitar o tecniquês. Em conversas com áreas de produto e de negócio, muitas vezes não há pessoas com conhecimento técnico. Precisamos traduzir soluções técnicas para o mundo dessas áreas, isto é, explicar no que aquilo se traduz no uso real. Por exemplo, ao afirmar que uma funcionalidade precisa de resposta em tempo real, traduzimos assim: o usuário precisa receber uma resposta na tela imediatamente após requisitar. Se não for o caso, podemos dizer: o usuário pode esperar um pouco para receber essa resposta, inclusive no dia seguinte. Assim, conseguimos aprofundar a conversa e alinhar expectativas.
Reforçando a primeira etapa:
No contexto atual, não há como falarmos de decisão, roadmap (roteiro de produto) e construção de produtos sem considerar IA como aceleradora de análise. É claro que precisamos do fator humano para decidir, pesquisar e construir. Porém, ao apresentarmos um cenário de produto para uma IA e descrevermos como queremos construir, ela pode responder muito mais rapidamente sobre as chances de sucesso ou falha, inclusive fornecendo estimativas percentuais. Isso é útil para:
Utilizemos IA para fundamentar ainda mais o que estamos propondo e para ajudar a traduzir necessidades técnicas de forma que produto e negócio compreendam. A IA pode estruturar rapidamente análises de impacto: fornecemos o contexto estratégico e ela organiza e estrutura o argumento.
Bom, pessoal, é isso que eu tinha para este vídeo. Espero que vocês tenham gostado, e nós nos encontramos em um próximo vídeo.
O curso Tech Lead: alinhar engenharia ao ciclo de vida do produto possui 191 minutos de vídeos, em um total de 37 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.
