DEV Community: Larissa Azevedo

Segurança no Front-end: dos ataques à prevenção

Larissa Azevedo — Mon, 16 Jun 2025 18:25:37 +0000

Se você ainda acha que segurança na web é responsabilidade exclusiva do back-end ou do time de segurança, é hora de rever esse conceito.

Cada linha de código que você escreve no front-end tem impacto direto não só na experiência do usuário, mas também na proteção dos dados, na integridade do sistema e na reputação do produto que você ajuda a construir.

Durante minha palestra “Segurança no Front-End”, eu trouxe exatamente essa reflexão: a segurança começa no seu código, na interface e no que você entrega para o navegador. E quando você entende isso, percebe que o front não é só uma camada de apresentação, mas uma parte fundamental na defesa do sistema.

Muito mais do que entender conceitos técnicos isolados, desenvolver com segurança é uma mentalidade. É estar constantemente se perguntando se o que você desenvolve não abre brechas para invasões ou vazamento de dados, e como você pode estar ciente de novas formas de invasão para se prevenir delas.

Por que segurança no front-end importa tanto?

Se tem uma coisa que você precisa internalizar é que o front-end é a porta de entrada do seu sistema. É o primeiro lugar onde o usuário interage e, da mesma forma, onde uma pessoa mal-intencionada tenta explorar qualquer brecha possível.

Existe um mito muito comum entre desenvolvedores, especialmente aqueles que estão começando a aprofundar em arquitetura, que segurança é coisa de back-end, de infraestrutura ou, pior ainda, “coisa do time de segurança”. Isso não é só falso, como também é perigoso.

Se o seu código roda no navegador, ele é público. Ele está acessível, inspecionável e, portanto, vulnerável se não for construído com cuidado. Isso significa que qualquer erro, qualquer configuração errada, qualquer input não validado, qualquer dado sensível mal gerenciado, pode abrir uma porta enorme para vazamento de informações, sequestro de sessão, roubo de identidade ou até ataques que derrubam o sistema.

E mais do que isso: o usuário não sabe (e não quer saber) se foi o back-end, o front-end, a API, o servidor ou o banco de dados que falhou. O que ele sabe é que foi o seu sistema que não protegeu ele.

De quem é a responsabilidade?

A resposta mais honesta é: de todo mundo. Mas, especificamente no front-end, existem responsabilidades diretas e intransferíveis.

Se você está construindo a interface, você precisa garantir que:

Nenhum dado sensível seja exposto ou trafegue de forma insegura
Toda interação do usuário que gere ações sensíveis esteja protegida contra falsificação de requisição, execução de scripts maliciosos ou roubo de sessão
Os dados que você envia pro back-end estejam validados, sanitizados e dentro dos padrões que impedem exploração maliciosa

No fim das contas, a segurança do sistema também começa na sua tela.

Quais são as ameaças que rondam o front-end?

Pra quem acha que segurança é só preocupação com o back-end, entender essas ameaças é o primeiro choque de realidade.

Cross-Site Scripting (XSS)

O XSS é, disparado, um dos ataques mais comuns em aplicações web. E o pior: é também um dos mais fáceis de acontecer quando quem desenvolve não entende segurança no front.

Basicamente, o atacante injeta um script malicioso que será executado no navegador da vítima. Isso permite, por exemplo, que ele roube cookies, tokens de autenticação, dados sensíveis e até sequestre a conta do usuário.

Na prática, qualquer campo que aceite entrada do usuário sem sanitização vira uma brecha em potencial. Um input de nome, um campo de comentário, uma URL com query string, qualquer coisa.

Como prevenir:

Nunca renderize dados do usuário diretamente no DOM sem sanitização
Use bibliotecas como DOMPurify
Configure corretamente a Content Security Policy (CSP) da aplicação
Trabalhe sempre com HTTPS para impedir interceptação

Cross-Site Request Forgery (CSRF)

Esse é o clássico golpe da ação forçada. Imagine que você está logado no seu internet banking e, sem perceber, acessa um site malicioso que, de forma escondida, faz uma requisição para transferir dinheiro da sua conta. Você não vê, não percebe, mas a ação acontece, porque o navegador carrega seus cookies de sessão automaticamente.

Como prevenir:

Configure cookies com atributos como SameSite=Strict, HttpOnly e Secure.
Adote tokens anti-CSRF nas requisições sensíveis.
Sempre verifique os cabeçalhos Origin e Referer para garantir que a requisição veio de onde deveria.
E, claro, implemente MFA.

Injeção de SQL (Sim, o front participa desse risco)

Apesar do SQL Injection ser um ataque direcionado ao back-end, a verdade é que quem não valida o que envia do front ajuda (e muito) a abrir essa porta.

Se você não controla o que o usuário digita e não valida os dados antes de enviar, você está passando input sujo que, se o back-end não tratar corretamente, vira uma bomba na mão do banco de dados.

Como prevenir:

Valide e sanitize absolutamente tudo que o usuário digita
Nunca confie que “o backend cuida disso”. Validação no front não substitui a do back, mas ela impede que algo nocivo chegue na sua aplicação

Ataques de Força Bruta

Se o seu sistema permite infinitas tentativas de login sem bloqueio, parabéns: você acabou de facilitar a vida de quem quer adivinhar senhas.

Como prevenir:

Limite tentativas de login
Adicione CAPTCHA a partir de um número razoável de tentativas inválidas
Sempre implemente autenticação de dois fatores
E eduque os usuários e os times sobre a importância de senhas seguras

Vulnerabilidades de configuração

Se você já deixou uma chave de API exposta no código do front-end, você sabe do que estou falando. E se não sabe, eu te conto: qualquer segredo que vai pro navegador está, imediatamente, acessível pra qualquer pessoa que abrir o DevTools.

Isso vale pra qualquer dado que você deixou no localStorage, sessionStorage ou até fixo em arquivos de configuração expostos no front-end.

Como prevenir:

Nunca armazene segredos no front-end
Cuide da configuração dos headers HTTP de segurança
Trabalhe com tokens que expiram rapidamente e que possam ser rotacionados
E revise constantemente o que está público no seu bundle e no armazenamento local

Além disso, é importante revisar frequentemente quem tem acesso a quais partes do sistema e se essa permissão está de acordo com o que o usuário deve acessar. Por exemplo, um profissional que foi recentemente desligado não deve mais ter acesso a áreas críticas do sistema ou doo código, e se tiver, isso é uma falha de segurança.

Como trabalhar com autenticação segura no front-end?

Essa é uma das perguntas mais recorrentes e também uma das mais negligenciadas por muitos times.

Cookies

São uma boa opção desde que configurados corretamente. Eles são enviados automaticamente para o servidor no mesmo domínio e podem ser protegidos usando atributos como HttpOnly, Secure e SameSite. Porém, se não forem bem configurados, são alvo fácil para ataques como CSRF e XSS.

Tokens

Usar JWT ou OAuth com tokens pode ser uma escolha interessante, especialmente em arquiteturas sem estado. No entanto, armazenar tokens no localStorage ou sessionStorage abre portas para ataques XSS, já que qualquer script malicioso consegue acessar esses dados.

O caminho mais seguro? Sempre que possível, use cookies com HttpOnly para tokens sensíveis e mantenha os tokens de acesso em memória, rotacionando frequentemente.

Boas práticas que não são negociáveis no front

Sanitização e validação de toda entrada de usuário
Nunca armazenar dados sensíveis no navegador além do estritamente necessário
Sempre trabalhar com HTTPS e configurar os headers de segurança corretamente
Definir políticas de Content Security Policy robustas
Feedback controlado, com erros genéricos para quem não deveria ver detalhes
Manter dependências e bibliotecas sempre atualizadas
E claro, tratar privacidade de dados como pilar, especialmente considerando a LGPD

Ferramentas que todo dev front deveria conhecer (e usar)

OWASP ZAP para varredura de segurança
Nmap para análise de rede
Burp Suite para inspeção e manipulação de requisições
Nessus para scanner de vulnerabilidades
E claro, ferramentas como Snyk, Dependabot e npm audit para gestão de vulnerabilidades em dependências

Além disso, consulte o site da OWASP para entender mais sobre segurança na web.

A LGPD te envolve também

Se você coleta dados, você responde por eles. Se você guarda informações sensíveis que não faz sentido, se mantém dados do usuário oouu cliente quando não há motivo… você não só aumenta sua superfície de ataque, como também se expõe legalmente.

Portanto, pratique Privacy by Design: quanto menos dado você coleta e armazena, menor é seu risco.

Segurança não é uma opção, é sua responsabilidade

Quando você entende que segurança não é uma camada, mas um pilar do seu trabalho, sua visão sobre desenvolvimento muda. Você deixa de ser só alguém que resolve tarefas e passa a ser parte ativa da construção de sistemas robustos, profissionais e confiáveis.

E não tem sensação melhor do que olhar pro seu próprio código e saber que ele não só funciona, mas protege quem usa.

Se você chegou até aqui, quero te ouvir:
Quais práticas você já aplica?
Qual dessas te deixou mais reflexiva hoje?
E qual ferramenta de segurança ainda tá na sua lista pra dominar?

📲 Me acompanhe nas redes para mais conteúdos de front-end e carreira:

Instagram - LinkedIn - YouTube

Ferramentas do GitHub que otimizam o trabalho de qualquer dev

Larissa Azevedo — Tue, 15 Apr 2025 20:16:45 +0000

Se até esse momento tu só usa o GitHub para adicionar seus projetos, sem nem sequer caprichar um pouco na documentação dele, você está deixando de se beneficiar com diversas ferramentas que vão otimizar a forma como tu coda, colabora e se desenvolve.

A ideia desse artigo é te mostrar como o GitHub vai muito além do versionamento e como você pode explorar esse ecossistema a seu favor, inclusive com exemplos reais de como uso cada recurso no meu dia a dia para você já começar a aplicar.

Bora lá?

1. GitHub Actions: Automatize tudo, desde compilação, testes e pipelines

O GitHub Actions é a ferramenta de automação nativa do GitHub. Com ela, você pode configurar workflows que executam desde testes e linters até deploys e atualizações de dependências.

Como eu uso:

Rodar testes automatizados a cada push
Rodar o lint antes de permitir um merge
Deploy automático de sites com Vercel

Na documentação existem modelos prontos de fluxos de trabalho que você pode utilizar, vale a pena conferir.

2. GitHub Codespaces: Desenvolva de qualquer lugar

Já pensou em abrir seu VSCode com todo o ambiente do projeto pronto, só que direto do navegador? O Codespaces permite isso. É um ambiente de desenvolvimento seguro, configurável e dedicado que funcione como e onde você desejar.

Para que serve:

Colaboração mais ágil com outros devs
Trabalhar em dispositivos com menos potência
Garantir que todo mundo está usando o mesmo setup

Como eu uso:

Se me veio aquela ideia na mente e eu quero desenvolver, sem ter que configurar tudo do zero, é uma boa opção. Ou mesmo quando há algum ajuste a ser feito em uma pull request, eu posso utilizar o Codespaces para fazer o ajuste sem ter que alterar meu ambiente de desenvolvimento com outro trabalho em andamento. É produtivo!

Conheça mais dele aqui.

3. GitHub Projects: Gestão de tarefas dos seus próprios projetos

O GitHub Projects é uma espécie de Trello embutido no GitHub — só que muito mais integrado. Você pode criar quadros com colunas, conectar issues e pull requests, e acompanhar o progresso do time sem sair da plataforma.

Como eu uso:

Em projetos open source ou pessoais, organizo ideias, bugs e melhorias com colunas de "To do", "In progress" e "Done" nos próprios repositórios

Assim não preciso de outra ferramenta que disperse as informações ou que me dificulte de atualizar.

Integração poderosa: combine com GitHub Actions para mover cards automaticamente com base em eventos (ex: PR merged)

Conheça mais dele aqui.

4. GitHub Pages: Sites direto do repositório

O GitHub Pages é uma ferramenta que permite hospedar sites estáticos diretamente de um repositório no GitHub, sem você precisar configurar servidor ou gastar com hospedagem. É muito utilizado por devs para portfólios, documentações e páginas institucionais de projetos.

Para que serve:
Permite criar e publicar sites a partir de arquivos HTML, CSS e JavaScript diretamente do repositório. O GitHub gera um domínio gratuito (https://seunome.github.io) e mantém seu site sincronizado com o conteúdo da branch configurada (geralmente main ou docs).

Como eu uso:
Crio páginas para meus projetos usando o domínio fornecido pelo GitHub Pages. Facilita demais a minha vida!

Conheça mais dele aqui.

5. GitHub Copilot — Seu par de programação com IA

O GitHub Copilot é um assistente de código que utiliza IA para sugerir trechos de código enquanto você digita. Baseado no Codex (da OpenAI), ele aprende com seu contexto e antecipa o que você está tentando escrever.

Para que serve:

Aumentar a velocidade de escrita de código
Reduzir tarefas repetitivas
Explorar padrões de solução que talvez você não conhecesse

Como eu uso:
Utilizo para fazer refatorações mais rápidas, escrita de testes e pedir sugestões de código em momentos de bloqueio.

Importante: não aceite tudo no automático. Use como ponto de partida, sempre validando o que está sendo sugerido, até para ajudar no seu raciocínio na hora de codar.

Conheça mais dele aqui.

6. Outras ferramentas que valem conhecer

GitHub Discussions: fórum dentro do repo para debates e perguntas.
Security & Dependabot: alertas e atualizações automáticas de segurança para suas dependências.

7. Onde/como aprender mais

8. Conclusão

O GitHub não é só uma vitrine do seu código, é um ecossistema de produtividade completo para devs. Se você quer se destacar profissionalmente, seja júnior ou sênior, vale a pena investir tempo em dominar essas ferramentas. Elas encurtam caminhos, reduzem erros e mostram maturidade na sua forma de desenvolver.

E aí, qual dessas ferramentas você já usou? Qual quer começar a explorar essa semana?

📲 Me acompanhe nas redes para mais conteúdos de front-end e carreira:

Instagram - LinkedIn - YouTube

Como transformar seu README do GitHub em uma vitrine profissional irresistível

Larissa Azevedo — Thu, 10 Apr 2025 12:33:29 +0000

“O GitHub pode ser só um repositório de código — ou pode ser a vitrine que vai atrair sua próxima grande oportunidade. A escolha é sua.”

Em 2020, escrevi um artigo ensinando como criar um README.md “sensacional” no GitHub. De lá pra cá, muita coisa mudou. O mercado mudou. O comportamento dos recrutadores mudou. E eu mudei também.

Hoje, com quase 10 anos de experiência em desenvolvimento web e ajudando devs a evoluírem suas carreiras, percebo que o GitHub vai muito além de código. Ele é um dos espaços mais poderosos para demonstrar:

O que você domina;
Como você pensa;
O impacto que você gera;
E principalmente: como você se posiciona.

Neste artigo, quero te mostrar como transformar seu README em um verdadeiro portfólio interativo — que comunica suas habilidades técnicas, mas também seu branding, sua trajetória e seu diferencial.

Vamos juntos?

Como criar o repositório com README personalizado no GitHub

Antes de qualquer mágica acontecer, você precisa criar um repositório público com o exato nome do seu usuário no GitHub. Por exemplo: se seu usuário for @seunome, o repositório deve se chamar seunome.

📌 Importante:

O repositório precisa ser público.
Marque a opção de incluir um README.md na criação do repositório.

Assim que fizer isso, o próprio GitHub vai exibir uma mensagem especial avisando que você desbloqueou a funcionalidade de personalizar seu perfil com o README desse repositório.

É nesse momento que o seu GitHub deixa de ser só um repositório de código… e começa a ser uma vitrine poderosa do seu potencial como dev.

Anatomia de um README com impacto

Agora que você já tem o repositório, é hora de criar um README que realmente represente quem você é, o que você sabe fazer e onde você quer chegar.

Aqui estão os principais elementos para incluir:

✍️ 1. Introdução com branding pessoal

Comece com uma saudação acolhedora, seguida de uma frase que mostre quem você é e o que te move como profissional.

Exemplo:

👋 Olá, eu sou a Larissa Azevedo!  

Frontend Software Engineer | Microsoft MVP | Mentora de Carreira | Palestrante  

🚀 Minha missão é ajudar devs a alcançarem o ápice de suas carreiras na programação, unindo código, comunicação e propósito.

🧠 2. Stack e especialidades

Liste as tecnologias com as quais você trabalha e destaque sua zona de especialização. Pode ser com ícones, badges ou listas simples.

Exemplo:

Stack:
React | Next.js | TypeScript | Node.js | Prisma | MySQL | Jest | Testing Library | Cypress  

Design & Estilo:
TailwindCSS | MUI | Styled Components | SASS | BEM

📂 3. Projetos com contexto, propósito e diferencial

Evite listar projetos soltos sem explicação. Use descrições curtas para mostrar por que você fez e o que aprendeu/entregou.

Formato:

🔗 [Projeto Nome do Projeto](link)
> Aplicação criada para resolver [problema X]. Utilizei [tecnologias].  
> Destaque: [implementação específica, aprendizado, resultado ou métrica].

📊 4. Como mostrar evolução (contribuições, histórico, insights)

O gráfico de contribuição, os commits e os repositórios organizados contam uma história. Mostre constância, curiosidade e progressão.

Você também pode incluir seções como:

📈 Em aprendizado:
- Clean Architecture no Front-end
- Testes E2E com Playwright

💡 Próximos passos:
- Finalizar projeto X
- Contribuir com Open Source em Y

🌐 5. Links estratégicos

Conecte seu GitHub ao seu ecossistema digital.

📲 Me encontre em outros cantos da internet:  LinkedIn | Newsletter | YouTube | Portfólio

🎨 6. Visual e identidade (emojis, badges, gifs, imagens, storytelling)

Solte a criatividade! Personalidade é um diferencial. Você pode usar emojis, badges, gifs curtos ou até uma colagem visual feita no Canva.

⚙️ Ferramentas que ajudam

🛡 Geradores de badges
Shields.io
Simple Icons
Markdown Badge Generator

📈 Stats e contribuições
GitHub Readme Stats
GitHub Profile Trophy

🧱 Layout com markdown
Markdown Cheatsheet
Emojipedia

📣 Compartilhe seu perfil e ajude outros devs!

Criou um README com mais impacto e propósito? Poste no LinkedIn, compartilhe seu link e marque este artigo!

Vamos fortalecer a comunidade mostrando como o GitHub pode ser muito mais do que código — pode ser seu diferencial no mercado.

📲 Me acompanhe nas redes para mais conteúdos de front-end e carreira:

Instagram - LinkedIn - YouTube

Clean Code no Front-end

Larissa Azevedo — Wed, 09 Apr 2025 13:07:32 +0000

Escrever código limpo vai muito além de seguir boas práticas técnicas — é sobre construir legados sustentáveis dentro dos projetos e ser reconhecida como uma profissional que entrega valor de forma consistente.

Durante a palestra Clean Code no Front-End, que compartilhei em parceria com a NodeBr no evento NodeBR [Campinas] #002 - The Fun Part of NodeJs - Part 2, falei sobre como aplicar os princípios do Clean Code de forma prática no dia a dia de quem trabalha com desenvolvimento front-end.

E mais do que isso: como essas práticas podem fortalecer sua imagem profissional, facilitar a colaboração em equipe e garantir mais segurança, escalabilidade e manutenibilidade para as aplicações.

Por que Clean Code importa?

Você já parou pra pensar que o código que você escreve hoje será lido — talvez várias vezes — por outras pessoas (ou por você mesma no futuro)?

Estudos mostram que, em média, para cada 10 linhas lidas, escrevemos 1 linha de código. Isso significa que legibilidade e clareza não são luxo — são necessidade.

Código limpo é um ato de respeito com quem vai manter e evoluir seu trabalho. E mais: é também um diferencial competitivo para quem quer crescer como dev.

Entendido sua importância, vamos olhar mais para o conceito.

Princípios

Durante a palestra, discutimos os pilares clássicos que fazem parte da filosofia do Clean Code — e como aplicá-los com sabedoria no dia a dia:

DRY (Don’t Repeat Yourself): Evite duplicações. Sempre que possível, reutilize funções e abstrações já existentes.
KISS (Keep It Simple, Stupid): Soluções simples são mais fáceis de manter, testar e expandir.
YAGNI (You Aren’t Gonna Need It): Não implemente o que ainda não é necessário. Evite lógica prematura.

Boas práticas

Também é importante aplicar boas práticas de desenvolvimento:

Nomes significativos: Variáveis e funções devem se explicar sozinhas. Um bom nome reduz necessidade de comentários.
Funções curta e coesas: Cada função deve ter uma única responsabilidade. Código modular é mais legível e testável.
Evite código morto e comentários inúteis: Comente apenas quando necessário e opte sempre por deixar o próprio código o mais autoexplicativo possível.
Organização de pastas e componentes: Estruture o projeto de forma que qualquer pessoa consiga navegar e entender as responsabilidades dos arquivos.
Componentização e separação de responsabilidades: Cada módulo/component deve ter uma função bem definida dentro do sistema.
Evite escopo global e variáveis mal controladas: Utilize const e let com consciência, limitando escopo sempre que possível.

Ok, mas e no front-end? Tem algo mais?

Vamos olhar mais algumas boas práticas do clean code no front-end, já que é a principal pauta do artigo.

Organização de diretórios e arquivos

No front-end, a estrutura do projeto impacta diretamente na produtividade e manutenção.

Agrupe por funcionalidades
Separe responsabilidades: componentes, serviços, contextos, hooks, estilos

Dica prática: mantenha a estrutura simples no início, mas extensível com o crescimento do projeto.

Componentização e reutilização

Evite repetir código criando componentes reutilizáveis e com responsabilidades bem definidas.

Exemplo:
Crie um <Button /> genérico que aceita variações por props, ao invés de recriar o mesmo botão 10 vezes.

Assim você:

Deixa uma melhor legibilidade
Facilita nos testes
Torna uma refatoração mais segura
Padroniza o visual da aplicação

Nomes claros e autoexplicativos

// Evite
const x = true;

// Prefira
const isUserLoggedIn = true;

Isso vale para:

Props dos componentes
Hooks personalizados
Estados e variáveis

Separação de responsabilidades (SoC)

Não misture lógica, visual e efeitos colaterais.

Como aplicar:

Coloque regras de negócio em hooks
Separe estilo com CSS-in-JS, Tailwind ou SCSS
Evite lógica complexa dentro do JSX

Use funções pequenas e coesas

Funções grandes tendem a se tornar difíceis de manter.

// Prefira isso
function validateUserData(data) { ... }
function submitUserData(data) { ... }
function refreshUI(data) { ... }

Cada uma com uma única responsabilidade.

Comentários com propósito

Evite comentários redundantes. Prefira documentar de forma útil com JSDoc:

/**
 * Calcula a área de um triângulo.
 * @param {number} base
 * @param {number} height
 * @returns {number}
 */
function calculateTriangleArea(base, height) {
  return (base * height) / 2;
}

Manipulação de eventos e DOM

Mesmo com frameworks, entenda o que está por trás:

Use delegação de eventos com parcimônia
Evite múltiplos manipuladores desnecessários
Centralize lógica de eventos em handlers nomeados

Async/Await com tratamento de erros

Sempre trate exceções de forma clara:

try {
  const response = await fetchData();
  updateUI(response);
} catch (error) {
  showToast("Erro ao buscar dados");
}

Bastante coisa, não é?

Clean Code é para todas as fases da carreira

Não importa se você é dev júnior, pleno ou sênior — o compromisso com um código limpo começa desde cedo. E cada Code Review, refatoração ou nova funcionalidade é uma oportunidade de aplicar esses princípios.

Como mencionei durante a apresentação: o código limpo que você escreve hoje pode ser o código que você mesma vai agradecer por ter deixado legível amanhã.

Ferramentas que ajudam nesse processo

Algumas ferramentas que foram citadas na palestra e que podem facilitar essa missão no dia a dia:

Linters e formatadores (ESLint, Prettier): Garantem padronização e ajudam a evitar deslizes.
Testes automatizados (Jest, Testing Library): Com código desacoplado, testar fica mais fácil — e confiável.
CI/CD (GitHub Actions, Jenkins): Automatizam análise de qualidade e ajudam a manter o padrão mesmo em times grandes.

Escrever um código limpo te faz crescer profissionalmente

Mais do que uma prática técnica, adotar o Clean Code é uma atitude de maturidade profissional. Devs que se preocupam com clareza, legibilidade, manutenibilidade e escalabilidade do seu código ganham não só o respeito dos times, mas também visibilidade — e isso influencia diretamente nas oportunidades de promoção, liderança e reconhecimento.

Se você leu até aqui, quero que compartilhe comigo como você escreve um código limpo no seu dia a dia :D

📲 Me acompanhe nas redes para mais conteúdos de front-end e carreira:

Instagram - LinkedIn - YouTube

💼 E acompanhe também a NodeBr trazendo cada vez mais conteúdo incrível para você:

Acompanhe a comunidade NodeBR

Assista à live completa do evento no YouTube

🎤Comece já a palestrar!

Larissa Azevedo — Fri, 24 Jun 2022 03:28:47 +0000

Palestrar é uma ótima forma de compartilhar seu conhecimento com outras pessoas, além de poder alavancar muito a sua carreira e te expor a muitas oportunidades.

Não se sabote pensando que o seu conteúdo é "simples demais" ou "básico", ele certamente será útil para alguém, principalmente quem não conhece o assunto que você compartilha.

E não se cobre demais a respeito do nível ou complexidade que você terá no começo, conforme estiver tendo mais experiência, a forma como seu conteúdo é abordado irá evoluir, tranquilize-se quanto a isso.

Em relação ao conteúdo que você pode palestrar, pode ser qualquer assunto, especialmente o que conhece ou trabalha e também o que deseja aprender, ensinar outras pessoas é uma das formas mais eficientes de se entender sobre um assunto, além da vivência. Trazer seu ponto de vista e experiência será um baita diferencial na sua apresentação.

Então, entendido que você pode SIM palestrar, vamos ver o que precisa fazer e se atentar para fazer uma ótima palestra.

O que precisa para começar?

Vejamos, então, as primeiras e mais importantes etapas:

Saiba do que você irá falar

Liste algumas opções e escolha um tema que queira palestrar. Busque responder algumas perguntas para ter uma ideia de como decidir, como O que é isso?, Para que serve isso?, Como usa isso?, Quando usa isso?, Por que usa isso? , Qual importância isso tem na sua vida e na vida de outras pessoas? e entre várias outras.

Defina os objetivos da sua palestra

Analise o que você quer que as pessoas absorvam do conteúdo que você irá abordar, seja as características de uma tecnologia, os diferentes casos de uso de uma ferramenta, como tomar determinada decisão, ou até mesmo o que precisam saber sobre determinada coisa. Dessa forma será muito mais fácil para você elaborar seu conteúdo e para seu público entender. Lembre-se que deve ter um começo, meio e fim, garanta que nada será mencionado e deixado esquecido, sem conexão com o assunto principal.

Atente-se ao local (presencial/online)

Ao preparar a sua apresentação, garanta para quem lhe assiste a boa captação do que você fala, gesticula, apresenta e interage, independente de estar presencialmente ou a distância.

Saiba qual seu público (iniciantes/experientes)

Não tente abraçar o mundo, foque apenas no público destinado o seu conteúdo, e especifique-o ao divulgar sua palestra.

Apresente para um público pequeno (grupo de amigos/colegas de trabalho)

Em casos onde ainda sinta um certo bloqueio, receio ou vergonha, acomode-se com um grupo menor de pessoas e apresente diversas vezes, com a prática você estará mais confortável.

Divulgue sua palestra

Não hesite nesse ponto, chame as pessoas para conhecer o que você sabe. Publique em suas redes, avise as pessoas, não sinta vergonha de compartilhar seu trabalho.

Preparando sua apresentação

Vejamos agora o que fazer para seus slides, lembrando que se tratam de uma ferramenta de apoio e não o conglomerado de seus estudos e anotações.

Crie uma apresentação e título atraentes

Abdique dos temas prontos e sem graça do Power Point, vale até pegar um template do Canva ou do Prezi e capriche na identidade visual. A respeito do título, use algo que chame atenção e que passe a ideia do que será encontrado na sua apresentação.

Alguns exemplos que eu utilizei em palestras minhas para te ajudar:

Evite muitos textos nos slides

Como já foi mencionado, a ideia de utilizar um slide é de dar apoio ao conteúdo que você está apresentando, a atenção deve estar na sua fala ao invés de no slide. Portanto cuidado com a quantidade de texto que colocar, lembrando que deve ficar legível e com a ortografia correta.

Utilize elementos visuais à sua apresentação

Traga imagens, vídeos, gráficos, exemplos, o quanto conseguir trazer de conteúdo visual acerca do seu tema para ajudar na compreensão de quem assiste. E não esqueça de dar as devidas explicações sobre esses elementos, como também mencionar suas fontes.

Utilize tópicos para guiar seu conteúdo

Além de facilitar a compreensão para quem assiste, te ajuda a elaborar e apresentar. Lembre-se do começo, meio e fim.

Disponibilize o material usado após a palestra

É uma ótima forma de manter um bom material de consulta para quem assistiu sua palestra.

Começando a palestrar

Seguimos agora com atenções que devem ser dadas quando estiver apresentando:

Atente-se ao seu linguajar e sua performance (no palco/em frente à câmera)

Não fique igual uma estátua, gesticule, articule bem quando for falar, utilize tanto da linguagem verbal quanto a corporal e se possível, ande pelo palco ou entre as pessoas da sala.

Mantenha-se alerta e prepare-se para lidar com imprevistos

É preferível que corra tudo bem, mas não se pode contar sempre com a sorte. Mantenha a calma e aja rápido caso aconteça algo que esteja fora dos seus planos.

Comece com uma história (ou uma piada)

Além de conectar o público logo no começo, você cria um ponto de partida para o seu conteúdo. Quem já viu minhas palestras já me viu contando piadas no início, faço isso tanto para fazer essa quebra de gelo como também mostrar um pouco de quem eu sou além da palestra. Ao preferir contar uma história, conecte-a ao seu conteúdo, pode ser uma situação fictícia ou vivenciada por você.

Envolva os participantes

Incentive perguntas, questione quem já presenciou a situação que você narrou, conecte-se com seu espectador.

Dicas adicionais

Ao finalizar, esteja aberto à feedbacks

Ao fazer isso você saberá o que fez de bom e o pode melhorar na sua apresentação, acolha e aplique o que te falarem.

Não se prepare de última hora

Pesquise, elabore histórias, traga exemplos, valide suas informações, trabalhe duro para fornecer o melhor conteúdo possível.

Treine o quanto for possível (e mais um pouco)

Qaunto mais fizer, mais fácil fica. Não ache que está bom, sempre tem o que melhorar.

Sempre que faço minhas palestras, coloco todos esses tópicos em ação. Você adicionaria algum à lista? Me conta nos comentários e me chama pra conversar nas minhas redes :D

Um abraço e até a próxima ✨