DEV Community: uMov.me

Monitoramento de aplicações frontend com RUM.js e Kibana

Eduardo Mitkus — Tue, 21 Oct 2025 04:39:24 +0000

Monitorar aplicações de página única (SPAs) é um desafio comum no desenvolvimento frontend moderno.
Em ambientes de produção, é difícil compreender de forma precisa como os usuários estão realmente experimentando a aplicação, especialmente porque as ferramentas de auditoria locais, como Lighthouse ou DevTools, refletem apenas cenários simulados.

Para obter uma visão real da comportamento do usuário final, é possível utilizar uma combinação de ferramentas voltadas para observabilidade no frontend: RUM.js, Elastic APM e Kibana.
Estes juntos tornam possivel coletar, processar e visualizar métricas diretamente do Browser.

O que é o RUM (Real User Monitoring)

RUM é a coleta de métricas reais de uso diretamente do navegador do usuário e mede o que acontece em produção: dispositivos, redes, rotas e interações reais.

Quando o RUM está ativo e integrado ao APM, o Kibana mostra diferentes tipos de transações, que representam o que está acontecendo no app.
Principais tipos:

page-load: mede o tempo de carregamento inicial da página ou rota. Ideal para avaliar a experiência do primeiro acesso.
http-request: monitora chamadas de rede (APIs, fetch, Axios, etc.), exibindo latência, status e falhas.
user-interaction: representa ações do usuário, como cliques ou interações que disparam renderizações parciais.
authentication: rastreia o processo de login e autenticação, útil para detectar lentidão em fluxos críticos.

Além desses, o Kibana também pode exibir outras categorias, como route-change, resource e error, dependendo do comportamento da aplicação.

APM

O Elastic APM é quem recebe e organiza os dados enviados pelo RUM.
Ele deixa tudo no formato certo pra o Kibana conseguir montar gráficos, relatórios e filtros.
Em resumo, ele faz a ponte entre o navegador e o banco de dados.

Kibana

O Kibana é a parte visual onde é possível ver:

Transações: cada tipo de evento capturado
Comparações: dá pra comparar períodos (ex.: “hoje vs ontem”) e ver se a performance melhorou ou piorou.
Filtros: é possível filtrar por ambiente, versão do app, tipo de dispositivo ou navegador.
Criação e Configuração de Dashboards e Views.

Envio dos dados pro Elastic APM

O RUM coleta os dados no navegador e envia pro APM, que armazena e organiza tudo.
O fluxo é simples: Navegador (RUM.js) → APM Server → Elasticsearch → Kibana

Exemplo:

// monitoring/rum.js
import { init as initRUM } from '@elastic/apm-rum'

export const startRUM = () => {
  const apm = initRUM({
    serviceName: "my-app",
    serverUrl: "<seu_apm_server_url>",
    environment: "development",
  })

  apm.setInitialPageLoadName('App Loaded')
  return apm
}

Visualização do RUM no Kibana

Após configurar o RUM, as métricas começam a aparecer no Kibana, dentro de APM → Services.
É possível ver as transações do frontend, como page-load, http-request e longtask, e acompanhar o tempo de execução de cada etapa do carregamento.

A imagem abaixo mostra exatamente quanto tempo cada parte da aplicação levou, desde o carregamento inicial até requisições de rede, scripts e interações do usuário.

Captura de casos reais

Além das métricas automáticas, é possível enriquecer os dados enviados pro APM adicionando labels personalizadas.

try {
  await fetch('/api/login')
} catch (err) {
  apm.captureError(err)
}

Labels permitem acompanhar casos reais com mais precisão.
Por exemplo, entender se uma lentidão ocorre em um módulo específico ou para um tipo de usuário:

apm.addLabels({
  module: 'checkout',
  user_plan: 'premium'
})

Considerações finais

Monitorar o frontend com RUM.js, Elastic APM e Kibana é uma forma simples e eficaz de entender o que realmente acontece em produção.
Com poucos ajustes, é possível sair de uma visão genérica de “está lento” para identificar qual rota, qual usuário e em que contexto o problema aparece.

Essas ferramentas não servem só pra medir performance, mas pra enxergar a experiência do usuário como ela é de verdade.

_Foto do Artigo: [Elastic Observability Docs](https://www.elastic.co/pt/blog/performing-real-user-monitoring-rum-with-elastic-apm)_

Cada equipe tem a sua história e seu caminho. Onde possível, compartilhe.

Daniel Wildt — Fri, 20 Jun 2025 04:09:17 +0000

Quais práticas estão padronizadas na sua equipe? Quais práticas são compartilhadas entre todas equipes? Quais problemas existem hoje na estrutura da equipe? Quais serão as próximas práticas a serem adotadas?

Cada equipe minimamente deve saber falar sobre três itens:

reabastecimento
sincronia
melhoria

O reabastecimento fala sobre priorização e o olhar de conexão de negócio e evoluções técnicas internas. A sincronia envolve alinhamento, das pessoas saberem onde estão e o que está “pegando” com a equipe. Pode ser uma reunião online, atualizações em algum canal de comunicação, como a equipe resolver se organizar. E também melhoria, com alguma cerimônia onde a equipe reflete sobre como está trabalhando e sobre como pode melhorar, seja em questões técnicas ou em processos de trabalho.

A partir disso, as equipes devem entender como vão tratar as diferentes partes do fluxo: priorização de trabalho, análise de negócios pensando em artefatos e técnicas de fatiamento de trabalho e cadências, estratégias de arquitetura e design, estratégias de automação de testes e pipelines de entrega, formas de validação e revisão do trabalho realizado e além disso a liberação de funcionalidades (deploy é diferente de release) para clientes além de entender como o trabalho realizado deve ser medido.

Aí entram ferramentas de apoio para medição de desempenho, carga e outras variáveis de negócio que podem entender sobre a saúde do sistema e do trabalho entregue. Fora isso, ainda existem as preocupações de como a equipe faz para trabalhar com feedbacks e processos de escuta, além das estratégias de aprendizagem.

Entender o funcionamento de uma equipe, independente do tamanho, é algo que pode ser complicado, mas pode ter padrões e expectativas. E o principal: pode ser desafiado, melhorado e aperfeiçoado.

Existe algo que seja comum para todas as equipes? A necessidade de entregar valor, de entregar com frequência, de entregar com qualidade. É uma tarefa de equipe, de responsabilidade individual e coletiva. A equipe deve se importar com o trabalho em andamento e com o trabalho que precisa ser terminado. Lembrar que terminar o que está em andamento é mais importante que iniciar novo trabalho. Ainda mais considerando que o que está em andamento é o trabalho priorizado.

— Daniel Wildt

P.S.: Esse texto faz parte de um handbook que venho documentando faz alguns meses, sobre o que aconteceu na equipe da uMovme desde 2009. Aprendendo e refletindo sobre os diferentes caminhos que a equipe já percorreu, e trazendo aquilo que emerge e persiste no funcionamento das equipes. Esse handbook está se tornando um conjunto de princípios e práticas que a equipe reconhece e desafia no seu trabalho diário.

P.S.2: Foto do artigo, Paths, de Simon Clayson (via Flickr, licença Creative Commons).

Como Implementar um Design System em Projetos Vue.js: Boas Práticas e Benefícios

Ronaldo Paulino Filho — Mon, 07 Oct 2024 13:04:34 +0000

O desenvolvimento front-end moderno exige que a experiência do usuário (UX) seja consistente e eficiente. Para isso, o uso de Design Systems se tornou essencial, especialmente em projetos grandes e escaláveis. Neste artigo, vou compartilhar insights sobre como aplicar um Design System em aplicações Vue.js, garantindo produtividade, escalabilidade e consistência.

O Que é um Design System?
Um Design System é um conjunto de padrões reutilizáveis que definem os elementos visuais e interativos de um projeto digital. Ele vai além de uma simples biblioteca de componentes de UI, abrangendo diretrizes de marca, regras de acessibilidade e até padrões de comportamento de interações.
Para equipes de desenvolvimento, um Design System permite:

Consistência Visual: Todas as telas e componentes seguem a mesma identidade visual.

Eficiência: Componentes reutilizáveis evitam a reinvenção da roda em cada nova feature.

Colaboração: Designers e desenvolvedores falam a mesma linguagem, facilitando a comunicação e a implementação.

O Vue.js oferece uma arquitetura reativa e componentizada que se alinha perfeitamente à filosofia de Design Systems. Algumas razões incluem:
Componentes Modulares: Com Vue.js, podemos encapsular elementos da UI em componentes reutilizáveis, alinhados às regras do Design System.
Facilidade de Integração: O Vue permite a integração de bibliotecas externas e facilita a adição de tokens de design, como cores, tipografia e espaçamentos.
Flexibilidade: Vue é altamente customizável, tornando-o uma excelente escolha para projetos que requerem uma base sólida, mas com liberdade para escalar.
Passos Para Implementar um Design System em Vue.js

Defina a Base de seu Design System
O primeiro passo é estruturar os princípios do Design System. Isso inclui cores, tipografia, espaçamentos, e grids. A documentação desses padrões em uma plataforma como Storybook é uma excelente maneira de começar.
Crie Componentes Atômicos
Utilize o conceito de Atomic Design, que separa componentes em átomos (botões, ícones), moléculas (cards, formulários) e organismos (menus completos, cabeçalhos). No Vue.js, isso pode ser feito utilizando componentes isolados que podem ser estilizados através de SASS ou CSS-in-JS.
Crie Tokens de Design
Tokens de design são variáveis que podem ser reutilizadas ao longo do projeto para garantir consistência. No Vue.js, você pode definir essas variáveis utilizando SASS ou CSS Variables.
Documente Seus Componentes
A documentação clara dos componentes é fundamental. Ferramentas como o Storybook permitem que você documente e visualize cada componente em diferentes estados e variações, tornando o Design System acessível para todos da equipe.
Teste e Valide
Antes de incorporar seus componentes em larga escala, valide se eles atendem aos requisitos de acessibilidade e design. No Vue, ferramentas como o Jest podem ser usadas para testes de unidade, e o Vue Test Utils ajuda na simulação de interações.

Benefícios de Usar um Design System em Vue.js
Escalabilidade: Novos desenvolvedores podem rapidamente entender o padrão de componentes, acelerando o desenvolvimento.
Redução de Bugs: Ao reutilizar componentes testados e documentados, a probabilidade de erros visuais diminui drasticamente.
Manutenção Simplificada: Alterar a aparência ou o comportamento de um componente central é muito mais fácil quando tudo está centralizado no Design System.
Conclusão
A implementação de um Design System em projetos Vue.js garante consistência e escalabilidade, facilitando a colaboração entre times de desenvolvimento e design. Além de otimizar a produtividade, um Design System bem estruturado simplifica a manutenção e aumenta a qualidade da experiência do usuário.
Se você trabalha com Vue.js e está buscando melhorar a organização de seus componentes e garantir uma experiência consistente, considere investir em um Design System. Com ele, você terá uma base sólida para escalar suas aplicações e fortalecer a qualidade do código.

UX: Criando Soluções que Conectam Pessoas e Tecnologia

Ronaldo Paulino Filho — Mon, 30 Sep 2024 11:21:20 +0000

Em um mundo digital em constante evolução, a experiência do usuário (UX) vai além da interface estética ou das interações superficiais. O verdadeiro poder do UX está em criar conexões significativas entre as pessoas e a tecnologia, garantindo que as soluções não apenas funcionem, mas que façam sentido e gerem impacto positivo em suas vidas. Vamos mergulhar mais fundo em alguns conceitos cruciais:
Pesquisa de Usuários: A base do Design Centrado no Humano A pesquisa de usuários é o coração de um design bem-sucedido. Ela permite que os designers compreendam profundamente o comportamento, os desejos e as frustrações dos usuários. A coleta e análise de dados qualitativos e quantitativos fornecem insights fundamentais para orientar decisões estratégicas, resultando em produtos que ressoam com os usuários finais. Como Don Norman enfatiza, "não projetamos para nós mesmos; projetamos para o outro".
Prototipação: Validando Ideias Rápida e Frequentemente Prototipar não é apenas construir uma versão inicial de um produto, mas sim uma ferramenta de aprendizado essencial. A prototipação rápida permite testar hipóteses e ajustar soluções antes do lançamento, economizando tempo e recursos. Como Rafael Matone destaca, "um protótipo é para todos", reforçando a cultura de experimentação contínua. Isso garante que as soluções sejam testadas e validadas com usuários reais, minimizando riscos.
Acessibilidade e Design Inclusivo: Garantindo Igualdade Digital Acessibilidade não deve ser uma reflexão tardia. Quando incluímos a acessibilidade no início do processo de design, garantimos que o produto funcione para todos os usuários, independentemente de suas habilidades físicas ou cognitivas. O custo de ignorar a acessibilidade pode ser alto – tanto em termos financeiros quanto na exclusão de parte significativa da população. Como Marcelo Sales afirma, "o que custa caro é a falta de planejamento para incluir a acessibilidade desde o começo".
Lean UX e Agile UX: Adaptabilidade e Velocidade As metodologias ágeis, combinadas com o Lean UX, permitem que equipes entreguem valor continuamente, ajustando-se rapidamente às necessidades do mercado e dos usuários. O foco está em reduzir desperdícios e maximizar o aprendizado com ciclos rápidos de feedback. Integrar UX no desenvolvimento ágil significa criar uma cultura de colaboração onde designers, desenvolvedores e stakeholders trabalham juntos desde o início, resultando em produtos que evoluem continuamente.
UX Writing: A Importância das Palavras O UX Writing vai além de microcopias; ele é essencial para guiar os usuários, informar decisões e reduzir fricções durante a navegação. O uso de uma linguagem clara e direta, que ressoe com o público-alvo, pode impactar diretamente o engajamento e a conversão, evitando que as empresas percam oportunidades por não "falar a língua" dos seus usuários.
Ubiquidade e Experiência Multiplataforma: O Futuro do UX Com a expansão da Internet das Coisas (IoT), o UX não está mais restrito a um único dispositivo ou plataforma. Agora, é necessário criar experiências fluídas e coerentes que acompanhem os usuários em diferentes contextos e dispositivos. A ubiquidade exige que designers pensem além de interfaces isoladas, criando ecossistemas de produtos que sejam relevantes, contextuais e contínuos.
Design Systems: Consistência e Escalabilidade À medida que as equipes de design crescem e os produtos se tornam mais complexos, os sistemas de design garantem consistência visual e funcional em todos os pontos de contato. Eles são a base para a padronização, permitindo que as equipes mantenham a coesão da marca e acelerem o desenvolvimento de novos componentes. Como Glauber Laender comenta, “tudo deve ser padronizado” para garantir uma experiência coesa.
Descoberta de Produtos: Balanceando Satisfação e Resultado No processo de Product Discovery, o objetivo é encontrar o equilíbrio entre as necessidades dos usuários e os objetivos de negócio. Um bom processo de discovery entrega valor e satisfação para o usuário, ao mesmo tempo em que gera resultados significativos para a empresa. Trata-se de validar ideias rapidamente e ajustar o caminho à medida que se aprende mais sobre o problema e a solução.
👉 O UX é uma disciplina holística que envolve pesquisa, prototipação, acessibilidade, design de serviços, escrita estratégica e muito mais. Ao adotar uma abordagem centrada no usuário em todas as fases do processo, garantimos que estamos criando experiências significativas, que não apenas resolvem problemas, mas também enriquecem a vida das pessoas.
Vamos continuar explorando e aplicando esses conceitos para transformar as interações digitais em algo verdadeiramente impactante!

UX #DesignThinking #LeanUX #UXResearch #ProductDiscovery #DesignDeServiços #UXWriting #DesignSystems

A relação UX Writing - Desenvolvimento de Software

Ronaldo Paulino Filho — Thu, 15 Aug 2024 14:25:58 +0000

No mundo do desenvolvimento de software, estamos constantemente focados em criar funcionalidades incríveis e interfaces elegantes. Mas o que acontece quando os usuários não entendem como usar essas funcionalidades? É aí que entra o UX Writing.
Se trata de criar uma experiência fluida e intuitiva, onde cada mensagem, botão ou instrução é utilizada com praticidade.
🎯 Por que é importante para desenvolvedores?
Como desenvolvedores de software, nossa missão é resolver problemas e facilitar a vida dos usuários. A escrita desempenha um papel crucial nessa missão, pois ajuda a eliminar a frustração e a ambiguidade, tornando a navegação mais intuitiva e os processos mais fáceis de entender.
💡 Como incorporar o UX Writing no seu fluxo de trabalho?
A ligação e proximidade entre desenvolvimento e conteúdo é essencial para criar uma interface coesa.
Teste e ajuste: O texto, assim como o código, deve ser testado e ajustado sempre que possível.
Testes de usabilidade podem revelar onde o conteúdo não está claro ou não atende às expectativas dos usuários.
Textos curtos e diretos são mais eficazes. Evite termos técnicos e comunique-se na linguagem dos seus usuários.
🚀 Conclusão
No desenvolvimento de software, o UX Writing é uma ferramenta que ajuda a experiência do usuário. Ao integrar essas práticas , criamos produtos não apenas funcionais, mas também fáceis e agradáveis de usar.

ux

softwaredeveloper

frontend

Crescimento profissional e a cultura de aprendizagem.

Daniel Wildt — Fri, 12 Jul 2024 17:09:06 +0000

Contexto: texto escrito em 2022

Em 2009 eu inicio uma nova jornada. Apoiar na transformação de uma empresa baseada em projetos e diversos nichos, para uma empresa de produto, construindo um produto (que virou uma plataforma) para embarcar estes nichos.

A jornada nunca é simples quando estamos mudando o foco de serviço para produto. A cobrança não é mais baseada em simplesmente horas de serviço e suporte ao que é entregue. Não é mais simplesmente crescer em clientes, com novos projetos. Trabalhar com produtos envolve encontrar o tal encaixe ("fit") entre produto e mercado. Ganhamos a oportunidade de pensar em algumas coisas com mais força. Exemplo, aprender como posicionar o produto no mercado. E não aceitar mais simplesmente "tirar pedidos" ou "fritar pastéis" para adequar a necessidade de clientes com o projeto contratado.

Eu entendi na época que eu precisava construir um perfil de produto, já que meu foco dos 13 anos anteriores era focado em serviços e projetos e consultoria. Também entendi que não teria chance de fazer isso, se não tivesse uma equipe em aprendizado constante.

Construir projetos baseados no puro interesse de um cliente ainda exige pensamento de priorização e entendimento de como fatiar entregas, mas quem define o alvo está dentro do projeto. Não é o caso do pensamento quando estamos atuando com produto. Vamos descobrir ao longo do tempo clientes importantes, que podemos entrevistar e aprender mais e mais sobre o mercado que eles vivem. Clientes que nos inspiram no jogo de entrega de valor. Só que no final do dia, a atividade de aprendizagem sobre o que fazemos e sobre o que queremos melhorar é nossa responsabilidade.

No caso do pensamento de produto, a construção do futuro do produto precisa de aprendizagem. Viveremos constantemente um pensamento entre certezas, suposições e dúvidas, que serão constantemente desafiadas e atuam na nossa convivência com a incerteza. Precisa de uma equipe constantemente questionando como pode fazer o que faz melhor. Envolve entender este processo tanto tecnicamente como em processos para evolução do produto. Isso conecta com foco de mercado, entendimento de negócios.

Pensei em listar aqui atividades que considerei importante ao longo de 2009 até 2022 nesse pensamento de construção de culturas de aprendizagem, que eu considero como sendo uma das minhas habilidades. E também indicando práticas ligadas com o pensamento de evolução e aprendizado técnico, importante neste jogo de produto.

Em abril/2009 DevOps e Lean Startup estavam nascendo

Eu sabia que falhar o mais rápido possível e aprender mais rápido ainda era uma das únicas oportunidades que tinha neste processo de evoluir equipes e produtos. Criar uma estrutura de apoio para a melhoria, com retrospectivas, espaços técnicos para a equipe se desafiar, também.

Já tinha aprendido também com o meu aprendizado sobre eXtreme Programming, que automação de testes ajudaria a equipe a conseguir evoluir constantemente garantindo a tal coragem necessária para modificar código e saber que ele vai quebrar se algo não estiver ok.

Pelo pensamento Lean, eu sabia que precisava melhorar, encontrar maneiras mais fáceis de produzir software e garantir que uma equipe conseguiria dar manutenção e ensinar pessoas novas a fazer o mesmo.

Também sabia que atuar no desperdício da espera era o meu grande trunfo. Se eu melhorar os tempos de repasse de trabalho nas equipes, consigo aumentar o desempenho delas em muitas vezes.

Em abril de 2009, Eric Ries já tinha cunhado o termo Lean Startup, unindo Lean Thinking + eXtreme Programming + Customer Discovery/Customer Development.

Em 2009 uma palestra chama muita atenção, de uma empresa que eu acompanhava desde o ano anterior. O Flickr tinha uma estrutura no blog de código onde avisavam o que estava acontecendo com relação a updates de código e quem estava fazendo isso.

Eu já era fã fazia tempo e mantinha umas imagens desta época (confesso que elas estavam em uma pasta esquecida, mas eu não tinha esquecido)

Essa palestra, apresentada em junho no Velocity 2009, trouxe uma visão para o mainstream do desenvolvimento de software sobre a nossa capacidade de poder entregar software em produção de forma frequente.

Acho interessante que muitas revoluções relacionadas com a engenharia de software aconteceram em empresas que tiveram reviravoltas com o sucesso. O Flickr passou por diversas jornadas, desde aquisição do Yahoo e depois passando por dificuldades e demissões, até hoje em dia ser um produto em busca de significado. Particularmente gosto do serviço e sou assinante faz algum tempo.

Estes movimentos inspiraram diversas empresas e aqui no Brasil posso dizer que fui bastante influenciado por este tipo de movimento. Deploy contínuo era algo impossível de ser alcançado.

Antes da primeira linha de código, tenha princípios!

Desde cedo eu tinha consciência de alguns princípios que precisava colocar em funcionamento. Alguns relacionados a evolução de código fonte para produção e organização de como podemos gerar valor para clientes.

Eu não tinha dinheiro para contratar uma equipe altamente experiente. Eu precisava compor a equipe existente, aprender novas linguagens de programação ou expandir o uso das linguagens existentes. O mesmo com as práticas de engenharia de software. Sabia o que não queria, no caso de construir um produto no estilo plataforma. E somava nisso todos aprendizados que tive no meu passado mantendo códigos de 10+ anos nos dias atuais.

Testes automatizados, e para quem conseguir, desenvolvimento orientado a testes. Desde muito cedo comecei a trabalhar sessões de Coding Dojo, trazendo para as equipes o ritmo de codificar, evoluir e aprender sobre como modelar cenários de teste.
Trunk Based Development, que muito rapidamente envolve permitir que uma base de código possa ser levada para produção quando for de interesse da equipe. E para que isso possa acontecer precisamos garantir que o código "acordado" esteja com testes passando e o código "dormindo" esteja configurado de forma adequada para não afetar o comportamento de produção. Pensa que nesta época ainda não usávamos sistemas como Git, mas mesmo sendo git eu sigo operando no modelo TBD.
O sistema vai cair. Então como organizamos para que saibamos o que precisa funcionar e como podemos colocar para funcionar.
O sistema pode evoluir sem depender do banco de dados. Muito cedo começamos a aplicar Database refactoring, para garantir que eu poderia evoluir o modelo de dados sem depender da sincronia de instalação de código novo. O mesmo valeria para uma necessidade de rollback de um módulo.
O rollback precisava ser rápido, muito mais rápido que o tempo de instalação. Rollback é só mais uma instalação (deploy).
Uma instalação de código não é igual features novas para clientes. Importante ter uma estrutura de toggles, para habilitar que um cliente tivesse acesso a uma determinada funcionalidade antes de outros clientes, para fins de testes.
O cliente não tem acesso a um ambiente de testes. O teste é em produção. Assim como a bateria de testes chegava em um ambiente de produção, os clientes validavam uma funcionalidade também em produção, no seu próprio ambiente.

Alguns destes princípios levaram bons anos para entrar no fluxo da equipe. Mesmo hoje em 2022 ainda preciso explicar os benefícios de trabalhar com TBD para uma equipe que quer avançar e evoluir código. Assim como preciso ainda explicar os valores do manifesto ágil, sobre a importância de comunicação, de entregar software, de adaptar e manter contato próximo com quem demanda novas evoluções de um produto de software. Sempre lembrando que a coisa mais importante é maximizar o trabalho que não precisa ser feito, a tal simplicidade.

O caminho para a cultura de aprendizagem?

Momentos de aprendizagem, por todos os lados. O aprendizado "on the job", na prática, também. Isso vai desde o processo seletivo até o dia a dia evoluindo alguma funcionalidade de produto.

Se for resumir a base deste processo, é poder operar em dois materiais importantíssimos de Nonaka e Takeuchi:

Transformar conhecimento tácito em conhecimento explícito.
Entender o novo jogo para desenvolvimento de produtos.

Relaciono aqui alguns destes momentos que considero importantes e relevantes para este processo de construção de conhecimento.

Coding Dojo.
Treinamentos internos, palestras e rodas de conversa.
Ambiente de infraestrutura não adequado.
Automação de infra e escala.
Espaços de aprendizagem, criando eventos.
Processo seletivo com toda a equipe.
Operar de forma multimídia, com textos, áudio (podcast na época da trevisan), vídeo

O que mudou nisso tudo em 2022?

Muita coisa. Isso falando no problema de formação de pessoas. Vivemos em um mundo cada vez mais desigual. Se queremos um mundo diferente, precisamos ser intencionais.

Isso inclui remover barreiras para conhecer pessoas. Muitas empresas ainda falam sobre suas estratégias para contratar pessoas somente de melhores universidades do Brasil, pessoas em universidades e esquecem da infinidade de pessoas excelentes em cursos técnicos e pessoas que estão na prática mas não participam de processos de educação formal.

As empresas precisam conectar com comunidades de tecnologia e apoiar onde puderem, patrocinando eventos para unir as pessoas, criando espaços, oferecendo tempo das suas pessoas para palestras e mentorias. As oportunidades são diversas.

E não tente ser a melhor ou a única iniciativa.

Não importa quantas iniciativas sejam criadas sobre aprendizagem e formação de pessoas. Nenhuma delas vai ser suficiente.

Em 2010 o problema já era grande. Em 2022 o problema aumentou de tamanho. E agora está afetando empresas que nem pensavam que esse seria um problema lá em 2010.

O que eu ainda considero que pode nos ajudar, como indústria de tecnologia Brasileira, é operar em uma cultura de aprendizagem, para dentro e para fora das empresas, chegando em instituições de ensino, comunidades e outras empresas.

-- Daniel Wildt