Olá, pessoal, tudo bem? Hoje vamos nos aprofundar em um tema que muitas pessoas ignoram até o sistema cair ou chegar a fatura de um fornecedor de nuvem: requisitos não funcionais. O nome pode parecer entediante ou acadêmico, mas é exatamente isso que separa um sistema amador de uma arquitetura de alto nível.
A proposta é sair daquela visão de arquitetura feita apenas de desenhos bonitos, cheios de blocos, setas e tecnologias da moda. Quando falamos de arquitetura de verdade, de nível sênior, falamos de decisões que sustentam a qualidade. Pare para pensar: o sistema pode até cumprir todos os requisitos funcionais perfeitamente e, ainda assim, ser um fracasso completo. Pode vender, registrar, consultar e processar tudo o que a pessoa cliente pediu, mas continuar lento, cair com frequência, não escalar quando a equipe de marketing faz uma campanha, ser vulnerável, não gerar logs úteis quando as coisas se complicam e, no fim, custar mais caro para manter do que o lucro que realmente gera.
Neste módulo, trataremos de como os requisitos não funcionais são os verdadeiros direcionadores que orientam a arquitetura e por que a qualidade deve ser pensada desde o início, desde o primeiro dia, e não como um remendo improvisado depois que o sistema está em produção. Vamos falar sobre latência, segurança, observabilidade e como não gastar milhões com fornecedores de nuvem.
Bom, deixem-me apresentar: eu sou Fernando Silva, sou o Arquiteto Principal de Soluções na GetNet, uma empresa adquirente do grupo Santander. Já fui palestrante no TDC, escrevi muitos artigos na revista .NET Magazine — quem se lembra da .NET Magazine? — abordando tecnologias .NET. Também sou professor universitário, ministro aulas de pós-graduação, MBA, e tenho mais de 20 anos de experiência entre engenharia e arquitetura de soluções.
Onde estamos neste curso? Tivemos um módulo em que falamos sobre o papel da pessoa arquiteta de soluções e o pensamento arquitetural. Em seguida, passamos por modelagem de domínio e arquitetura orientada ao negócio. Vimos como desenhar os diagramas de nossas soluções, de forma muito orientada ao negócio. Agora, entramos no módulo de requisitos não funcionais.
O que vamos aprender hoje? Antes de entrar em cada tópico, vamos fazer uma introdução rápida do que vamos cobrir e, em seguida, começar com uma pergunta provocadora: quantas pessoas aqui já viram um sistema que funcionava perfeitamente — a pessoa usuária conseguia fazer tudo o que precisava — mas, ainda assim, era lento, caía com frequência, era difícil de escalar ou ninguém sabia o que estava acontecendo dentro dele? Quase todas as pessoas já participaram de um projeto assim.
É exatamente isso que os requisitos não funcionais endereçam. Um sistema pode estar 100% correto do ponto de vista funcional e, ainda assim, oferecer uma experiência terrível.
Vamos ao primeiro tema: requisitos não funcionais. Vamos falar bastante de NFRs (requisitos não funcionais) como impulsionadores de arquitetura. É aqui que a pessoa arquiteta demonstra sua capacidade, porque requisitos não funcionais não são ornamentais; eles direcionam a arquitetura da solução.
Se o sistema precisar, por exemplo, de baixa latência, a arquitetura deverá ser projetada para satisfazer esses requisitos não funcionais. Portanto, precisamos preparar a arquitetura para isso. Se precisarmos de mais segurança, vamos projetar a arquitetura considerando segurança desde o início. Vamos aprender a identificar esses impulsionadores antes de iniciar o desenho da solução.
Em seguida, vamos tratar de conflitos entre requisitos. Se quisermos uma disponibilidade de 99,99%, ótimo — teremos disponibilidade muito alta —, porém o custo pode ser elevado. Se quisermos desempenho extremo, talvez precisemos abrir mão de consistência imediata. Vamos discutir como mitigar requisitos mal interpretados e como conduzir conversas difíceis com o time de negócio.
Depois, vamos falar sobre latência, disponibilidade e escalabilidade — três elementos que costumam ser a maior preocupação em qualquer Black Friday (sexta-feira de promoções). Vamos mostrar que latência não é apenas rede; é estratégia. Vamos discutir que escalar não é apenas comprar uma máquina mais potente e adicionar capacidade de computação; muitas vezes significa escalar horizontalmente, mantendo o sistema sob controle.
Na sequência, passaremos por segurança, confiabilidade e observabilidade. Vamos detalhar a camada de segurança e reforçar que segurança não é apenas um firewall (barreira de proteção de rede). Confiabilidade não é apenas “não ficar fora do ar” e, consequentemente, observabilidade não é apenas um dashboard (painel) com um indicador vermelho ou verde. Vamos falar sobre SRE (Site Reliability Engineering, Engenharia de Confiabilidade de Sites), o que é SLI (Service Level Indicator, Indicador de Nível de Serviço) e o que é SLO (Service Level Objective, Objetivo de Nível de Serviço), para sabermos se o sistema está saudável de fato ou apenas aparenta estar tudo bem.
Depois, vamos revisar métricas arquiteturais: como conseguimos comprovar, por meio de métricas, que a arquitetura realmente está evoluindo. Vamos falar também sobre ADR (/Architecture Decision Records/, Registros de Decisões de Arquitetura). Se não documentarmos por que tomamos determinada decisão, em seis meses teremos de revisá-la e poderemos concluir, dependendo do contexto não registrado, que alguém a definiu de forma equivocada.
Por fim, vamos discutir arquitetura orientada pela qualidade e erros comuns de priorização — um dos maiores riscos para quem atua em arquitetura. Um exemplo é a prática de overengineering (superengenharia): projetar um “Ferrari” para, no fim, entregar uma pizza na esquina. Vamos analisar o custo da solução: se a arquitetura custa mais do que o problema que resolve, não temos uma solução; temos um novo problema.
Este é o panorama do que vamos ver hoje: uma visão abrangente sobre requisitos não funcionais.
Vamos começar falando sobre requisitos não funcionais e, daqui para frente, vamos nos referir a eles pelo acrônimo NFR (Non-Functional Requirements, Requisitos Não Funcionais), como um dos principais drivers (diretrizes) de arquitetura. Vamos partir do básico, e queremos destacar a importância desse básico, pois é onde a maioria dos projetos já começa errando.
O que é um requisito não funcional? A definição formal indica que requisitos não funcionais são atributos de qualidade de um sistema — não o que ele faz, mas como ele faz.
Pensando em uma analogia fora do mundo do software: ao comprar um carro, o requisito funcional pode ser “deslocar-se do ponto A ao ponto B”. Teoricamente, qualquer carro pode fazer isso, como um carro antigo, por exemplo, um Fusca ou uma Brasília. Mas por que nós escolhemos, de repente, um SUV (utilitário esportivo) ou um carro esportivo? Porque queremos que ele nos leve com segurança, com velocidade, com ar-condicionado e, talvez, com economia de combustível; ou seja, buscamos mais conforto. Esses são os requisitos não funcionais do carro.
Trazendo para o mundo do software: quando uma pessoa do time de negócio — um(a) stakeholder (parte interessada) — afirma “precisamos que a pessoa usuária consiga fazer login (autenticação)”, isso é um requisito funcional: um comportamento, uma ação. Implementamos, testamos e, ao clicar no botão, a pessoa entra no sistema. No entanto, quando perguntamos “em quanto tempo esse login precisa acontecer?”, passamos ao território dos requisitos não funcionais. O sistema pode permitir o login, mas ainda assim proporcionar uma experiência ruim. Um login que leva 10 segundos funciona? Funciona. É aceitável? Talvez não. O ponto é: o sistema pode estar correto do ponto de vista funcional e, ainda assim, oferecer uma experiência ruim para a pessoa usuária. Requisitos não funcionais separam um sistema que funciona de um sistema que funciona bem.
Vamos analisar alguns exemplos. Um requisito funcional poderia ser: “o sistema deve permitir que a pessoa usuária se autentique com e-mail e senha”. Esse requisito tem começo, meio e fim: implementamos, escrevemos testes, codificamos e validamos sua aprovação.
Um requisito não funcional poderia ser: “o login deve acontecer em menos de 500 milissegundos para 99% das pessoas usuárias”. Repare a diferença. O requisito não funcional geralmente terá um número (menos de 500 milissegundos), poderá incluir um percentual (99% das requisições abaixo de 500 milissegundos), o que implica que até 1% pode ser mais lento — e isso pode ser aceitável. Quando bem definido, esse tipo de requisito estabelece critérios claros de aceitação.
Requisitos não funcionais não são vagos: são mensuráveis e guiam decisões de arquitetura. Com eles, podemos definir estratégias de caching (armazenamento em cache), infraestrutura, topologia, posicionamento de clusters (agrupamentos) e servidores. Se levarmos isso para uma região de cloud (nuvem), eles influenciam quais regiões a arquitetura deve utilizar.
É importante evitar uma armadilha comum: requisitos não funcionais não se limitam a desempenho e latência. Eles definem a qualidade de operação do sistema como um todo:
Todos esses requisitos, quando bem definidos, alteram decisões de arquitetura.
Vamos fechar com uma provocação para levarmos à próxima sessão de refinamento de discovery (descoberta) de uma solução. Quando alguém disser “precisa ser rápido”, perguntem:
Quando alguém disser “precisa ser seguro”, perguntem:
Se for necessário escalar, perguntem:
Essas perguntas transformam intenções vagas em requisitos que guiam a arquitetura. É exatamente isso que vamos aprender durante este módulo.
Agora que nós já conhecemos os requisitos não funcionais e entendemos o que são, vamos passar pelos principais, pois cada um aparece de forma diferente no dia a dia e tem impacto distinto na arquitetura. Provavelmente vamos reconhecer situações já vivenciadas.
Vamos falar sobre desempenho. Desempenho é o requisito mais citado e, curiosamente, o mais mal definido. Esobre velocidade, tempo de resposta, capacidade e processamento. Aqui falamos de latência, throughput (vazão) e tempo de renderização. Parece simples, mas o impacto na arquitetura é grande. Ao endereçar desempenho, precisamos pensar em cache (armazenamento em cache), CDN (rede de entrega de conteúdo), estratégias de processamento assíncrono, otimizações de queries (consultas) e índices de banco de dados. O ponto crítico é: desempenho precisa de número. Dizer “rápido” não constitui um requisito não funcional; é necessário quantificar. Por exemplo: “95% das requisições de leitura precisam ocorrer em menos de 200 milissegundos”. Sem número, não sabemos se estamos entregando ou não.
Vamos falar sobre disponibilidade. Disponibilidade é manter a aplicação no ar quando necessário. Esse é um requisito não funcional que assusta quando colocado em números reais. Quando dizemos “minha aplicação tem 99,0% de disponibilidade”, parece bom, mas, diluindo ao longo de um ano — e veremos esses números em seguida — isso representa aproximadamente 88 horas de indisponibilidade anuais.
Para um e-commerce (comércio eletrônico), 88 horas de indisponibilidade significam receita perdida. Para um sistema de saúde, isso também pode representar um problema muito grave. O impacto arquitetural sobre a disponibilidade é direto. Precisamos pensar em redundância, em failover (comutação por falha) automático, em múltiplas zonas de disponibilidade, em planos de disaster recovery (recuperação de desastres) e em ter RTO e RPO bem definidos. Nenhuma dessas decisões é barata; todas precisam ser justificadas pelo quanto o negócio perde se o sistema ficar fora do ar.
Falemos sobre escalabilidade, que é a capacidade do sistema de crescer sem precisar ser redesenhado do zero. Aqui há uma distinção importante: escalar não é apenas suportar mais pessoas usuárias; é suportar mais pessoas usuárias e mais requisições mantendo outros requisitos não funcionais, como performance, disponibilidade e segurança. Se o sistema fica lento quando dobramos o volume, ele não escala. Se ele fica inseguro, também é inadequado. O impacto arquitetural quando falamos em escalabilidade é grande. Antes de qualquer decisão, devemos perguntar: qual é o volume real hoje? Qual é o volume esperado em 12 meses? Qual é o volume esperado para um cenário de campanha publicitária, como a Black Friday (data promocional)? A solução projetada para um determinado número de requisições será diferente se precisarmos lidar com 10, 15, 20 ou 30 vezes o acesso normal.
Segurança é um requisito não funcional que gera muito debate: muitas pessoas acham que estão fazendo, mas poucas realmente fazem de maneira adequada. O impacto arquitetural não é “uma caixinha”; segurança é transversal, não é um componente que se adiciona no começo, no meio ou no fim. Ela se manifesta por meio de identidade e acesso, rede, criptografia, secrets (segredos), segurança na pipeline (esteira) de deploy (implantação) e proteção de APIs. Cada camada da arquitetura tem uma superfície de ataque que precisa ser considerada. Costumamos reforçar que segurança adicionada depois pode custar 10 ou 100 vezes mais caro do que se tivesse sido planejada desde o início. Isso não é exagero. O custo de reescrever a autenticação de uma aplicação já em produção ou de refatorar o modelo de permissão do sistema com anos de dados pode ser muito elevado.
Manutenibilidade — o próprio nome já sugere a complexidade — é um dos requisitos não funcionais mais negligenciados. Ela impacta tanto a arquitetura de solução quanto o time de engenharia, porque o problema geralmente não é visível de imediato; muitas vezes aparece depois de seis meses ou um ano, ou quando um time novo tenta fazer uma mudança aparentemente simples e leva semanas. Manutenibilidade é sobre o custo de mudar o sistema ao longo do tempo. Nós projetamos soluções buscando baixo acoplamento, alta coesão, uso de design patterns (padrões de projeto), separação de responsabilidades, cobertura de testes e documentação viva. Todas essas práticas existem para atender a um requisito não funcional. O impacto na arquitetura é direto: a forma como definimos as fronteiras dos nossos módulos, serviços e domínios determina o quão fácil ou difícil será evoluir o sistema. Uma decisão ruim de acoplamento hoje pode gerar dívida técnica que cresce com juros compostos. Aquele módulo em que nós falamos sobre modelagem de domínio ajuda a definir fronteiras para uma manutenção mais tranquila do software.
Observabilidade é a capacidade de entender o que está acontecendo dentro do sistema por meio dos sinais que ele emite. Nós vamos abordar logs (registros), métricas e traces (rastreamentos). O impacto arquitetural da observabilidade não se resume a instalar uma ferramenta; trata-se de design (projeto). A solução precisa ser projetada para emitir os sinais certos, no formato certo, no momento certo. Um sistema que não foi pensado para observabilidade desde o início pode até ter logs (registros), mas eles não dizem nada — são inúteis. Pode ter métricas sem contexto, e, quando acontecer um incidente em produção, você ficará sem visibilidade. A regra é simples: se conseguimos responder o que está acontecendo no sistema agora em, no máximo, 2 a 5 minutos, não temos um problema de observabilidade. Portanto, nossa arquitetura de solução deve considerar como projetar a aplicação para atender à observabilidade.
Portabilidade é a capacidade de o sistema ser movido ou adaptado para diferentes ambientes — como cloud (nuvem), sistemas operacionais ou outros contextos de implantação — sem precisar reescrever a solução. O impacto da portabilidade na arquitetura é especialmente relevante em cenários de multi-cloud (múltiplas nuvens) ou quando precisamos operar tanto on-premises (localmente) quanto em cloud (nuvem). Devemos projetar a arquitetura pensando em containers (contêineres) e em cloud native (nativo de nuvem). Podemos também considerar os princípios dos 12 fatores, que são respostas comuns quando falamos de requisitos não funcionais relacionados à portabilidade.
Por último, mas não menos importante, temos compliance (conformidade) e regulatório — requisitos não funcionais que costumam gerar resistência, pois envolvem governança. Ainda assim, são fatores que dependem do contexto da empresa e são inegociáveis. Compliance (conformidade) é o conjunto de obrigações legais e regulatórias que o sistema precisa atender. Exemplos incluem a LGPD no Brasil, a GDPR na Europa, SOC 2 para clientes corporativos e normas do Banco Central para fintechs. O impacto na arquitetura pode ser significativo: precisamos pensar em isolamento de dados, trilha de auditoria imutável, retenção de logs (registros) pelo período definido, anonimização de dados pessoais e controles de acesso documentados e auditáveis. Nada disso é opcional quando há um regulador cobrando conformidade. Um ponto crucial: compliance (conformidade) não pode ser adicionado depois. Um sistema construído sem considerar, por exemplo, a LGPD exigirá um esforço muito grande para readequação. Quando a solução é projetada com compliance (conformidade) desde o início, tudo se torna mais tranquilo.
Olhando para esses requisitos não funcionais — aqui consideramos oito —, a mensagem é a seguinte: cada um deles, quando ignorado, pode se transformar em um problema de negócio. Não é apenas um problema técnico. Desempenho ruim pode fazer perder pessoas usuárias. A falta de segurança pode fazer perder confiança e até gerar multas. Manutenibilidade ruim pode paralisar o time ou aumentar demais o tempo de desenvolvimento. Compliance (conformidade) ignorado pode até encerrar operações. Requisitos não funcionais não são um detalhe no desenho da solução; eles também são uma estratégia.
[♪]
Este slide é muito bom, não por ser complexo, mas por ser simples. Ele descreve algo que ocorre em praticamente todos os projetos em que participamos ou presenciamos. Vamos começar com uma pergunta simples.
Quem já viu, em uma reunião de Discovery (Descoberta) ou de refinamento, frases como: precisa ser rápido, ser seguro, escalar, não deve cair? Provavelmente todas as pessoas já ouviram isso, assentiram com a cabeça, não questionaram, anotaram e seguiram em frente.
É exatamente aí que começa o problema. Essas frases parecem requisitos não funcionais, têm a forma de requisitos não funcionais, estão no documento, o cliente já assinou e, pior, isso foi colocado no backlog (lista de pendências). Contudo, não são requisitos não funcionais; são intenções: a intenção de ser rápido, a intenção de ser seguro, a intenção de escalar.
Existe uma diferença grande entre uma intenção e um requisito não funcional. O requisito não funcional é algo mensurável, testável e validável; a intenção é algo cujo descumprimento só descobrimos quando o sistema já está em produção e, consequentemente, a pessoa cliente está insatisfeita. Por isso, isso pode ser um problema real.
Tomemos, por exemplo, o requisito não funcional “tem que ser rápido” e vamos desdobrá-lo. Quando dizemos “tem que ser rápido”, o que é rápido? Rápido para quem? Em qual operação: em uma busca, em um relatório, em um checkout (fechamento de compra)? Sob qual volume de uso: 10 pessoas usuárias simultâneas ou 10 mil?
Quando deixamos a frase “tem que ser rápido” desse jeito, cada pessoa da equipe a interpreta da maneira que faz mais sentido para si. A pessoa desenvolvedora de front-end (desenvolvimento de interface) pode otimizar o tempo de carregamento de uma página; a pessoa desenvolvedora de back-end (desenvolvimento de servidor) pode otimizar as consultas ao banco de dados; a pessoa arquiteta pode pensar em cache (armazenamento em cache). Todas fazem coisas diferentes sem saber se estão tratando do mesmo problema, porque ninguém definiu o que, de fato, precisa ser resolvido. Ao final, cada uma dirá: “Fiz minha parte. Coloquei cache no carregamento.” A pessoa arquiteta definiu a estratégia de cache, mas o sistema ainda pode permanecer lento de um modo que ninguém abordou.
Outro exemplo de requisito não funcional: “não deve cair”. O que significa “não deve cair”? Nunca? Qual a disponibilidade: 99% ou 99,99%? E, se cair, em quanto tempo precisa se recuperar? Terá um RTO, que é a sigla de Recovery Time Objective (Objetivo de Tempo de Recuperação), ou um RPO, isto é, quanta informação pode se perder?
O termo “não deve cair”, interpretado por uma pessoa arquiteta, pode resultar em uma arquitetura multi-origem, ativo-ativo, com redundância total e, por consequência, custar 3, 4 ou 5 vezes mais do que o necessário. Ou pode não resultar em absolutamente nada, porque a equipe, ao final, considerou um excesso e deixou para depois.
Sem números, as duas interpretações são válidas: ou fazemos muitas coisas, ou deixamos para depois e não fazemos nada. E fazer muito ou não fazer nada pode ser igualmente perigoso.
E o impacto mais silencioso de todos: quando projetamos a arquitetura a partir de um requisito não funcional vago, corremos dois riscos opostos.
O primeiro ponto é o over-engineering (superengenharia): interpretamos “tem que escalar” como “tem que suportar 10 milhões de pessoas usuárias” e construímos uma infraestrutura complexa, sobredimensionada, para um produto que tem apenas 100, 200 ou 300 pessoas usuárias. Assim, gastamos recursos, tempo e dinheiro resolvendo um problema que ainda não existe.
O oposto é o under-engineering (subengenharia), que representa a falta de solução para esse cenário. Interpretamos “tem que ser rápido” de forma minimalista, não fazemos nada específico para isso, o sistema vai para produção com uma latência que pode afastar a pessoa usuária e, então, descobrimos que refatorar o desempenho em uma arquitetura que não foi pensada para isso pode ser custoso, especialmente quando teria sido mais eficiente considerar essa necessidade desde o início. Portanto, um requisito mal interpretado deixa de ser apenas um problema de comunicação; torna-se um problema de arquitetura e, consequentemente, um problema de negócio.
Como mitigar requisitos mal interpretados? Precisamos fazer as perguntas corretas, no momento adequado e com as pessoas adequadas. Sempre que o requisito for vago, antes de aceitar e registrar, procedemos da seguinte forma:
Há um último ponto relevante antes de avançarmos: muitas vezes a pessoa interessada (stakeholder) não sabe responder a essas perguntas. Muitas vezes não saberá qual é o volume esperado, qual é o tempo aceitável ou qual é o impacto financeiro de uma hora de indisponibilidade. Isso é normal e faz parte do processo. O papel da pessoa arquiteta não é apenas aceitar os requisitos; também é ajudar a construí-los: sentar-se com quem entende do negócio, trazer benchmarks (referências comparativas) de mercado, propor números iniciais razoáveis e validar com quem usa o sistema.
Um requisito não funcional mal interpretado, que ninguém questiona, é responsabilidade coletiva de todas as pessoas envolvidas. Um requisito bem definido nos ajudará a orientar a arquitetura e, consequentemente, é o que separa um projeto bem-sucedido de um projeto que será reescrito em dois ou três anos.
O curso Requisitos Não Funcionais e Qualidade Arquitetural possui 214 minutos de vídeos, em um total de 42 atividades. Gostou? Conheça nossos outros cursos de Arquitetura em DevOps, ou leia nossos artigos de DevOps.
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.
Programação, Data Science, Front-end, DevOps, Mobile, Inovação & Gestão, UX & Design, 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.
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.
Escolha os ebooks da Casa do Código, a editora da Alura, que apoiarão a sua jornada de aprendizado para sempre.
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.
Escolha os ebooks da Casa do Código, a editora da Alura, que apoiarão a sua jornada de aprendizado para sempre.
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.
