Publicação de Zummit

Prazos Apertados: A realidade dos projetos de data. Tem duas pessoas que sempre têm total confiança nos prazos de um projeto: o cliente e o Product Owner (PO). O problema é que esqueceram de avisar o time de dados... E aí começa a mágica de transformar semanas de trabalho em horas de dedicação e café. PO: "Precisamos desse relatório completo até sexta." Cliente: "Tranquilo, né? É só uma análise rápida." Analista de Dados: Começa a calcular mentalmente quantas madrugadas isso vai custar. A verdadeira arte não está nos gráficos e painéis visualmente atraentes, mas sim em criar soluções impossíveis no tempo mais apertado possível. "Ah, mas é só um ajuste simples!" Se eu ganhasse uma moeda cada vez que ouvisse isso, já teria financiado um civic 😂 Moral da história? Em projetos, não subestime a magia que acontece por trás dos bastidores. Se o relatório estiver na sua mesa a tempo, saiba que alguém fez milagre e sobreviveu (por enquanto)! PO's eu adoro vocês tá? 😁 Ivysson Luz

Ontem tive uma conversa interessante sobre a diferença do cargo de analista de dados e analista de negócio. O mais interessante, talvez, é que de uns meses pra cá eu mudei bastante a minha opinião sobre o tema. A essência de ambos, nesse contexto, é a mesma. Mas com algumas peculiaridades. Eu venho de um background de empresas de tecnologia. Nesse contexto, achava muito importante chamar o profissional de dados de analista DE NEGÓCIO. O motivo era bem simples: deixar claro que ele era NÃO era um profissional hardcore de tecnologia, que carrega consigo toda uma barreira de comunicação e cultura que na maioria dos casos atrapalha a relação com o profissional de negócio. Poxa, essa pessoa tem que ser o braço direito do tomador de decisão, preciso deixar claro para o gerente financeiro que esse analista sabe a diferença entre margem bruta e ebitda. Ele tem um arsenal de tecnologia, mas o foco dele SÃO NEGÓCIOS. O cenário muda quando a empresa não é puramente de tecnologia (como é o meu caso agora). Agora é importante deixar o gestor de negócios tranquilo quanto ao fato de que ele vai ter uma pessoa de tecnologia só pra ele. É claro que a comunicação ainda é (super) importante, mas a carência maior acaba sendo por alguém que saiba o que é uma API, um banco de dados, um dashboard. Ele tem mais ansiedade de parar de fazer tudo manualmente do que de conversar "de igual pra igual" com alguém. Nesse cenário, eu passei a preferir o termo analista DE DADOS. Ajuda a mostrar que esse profissional vai ser o braço de tecnologia daquela unidade de negócios. Aqui tem funcionado bem. Como funciona na sua empresa? Don't settle.

Este é o “framework” que usamos aqui para iniciar um trabalho com foco na redução de custos de plataformas de dados. - Identificamos os maiores ofensores: serviços que mais consomem recursos e mais custosos. - Tiramos relatórios de custo por dia agrupados por serviços para identificar anomalias. - Fazemos um assessment com os times técnicos para entender o uso dos recursos. - Avaliamos os tempos gastos, logs de rotinas e recursos de máquinas. - Criamos um relatório para a documentação do ambiente atual. - Criamos KPIs e metas a serem alcançadas para sucesso do projeto. - Planejamos a arquitetura e criamos uma estimativa de custos para a nova plataforma. - Fazemos POC para validar soluções. - Atacamos os maiores ofensores primeiro. - Treinamos toda a equipe para uso correto da plataforma de dados. O que achou? Como você faz trabalhos como estes? Se você quer a nossa ajuda para otimização de custos da sua plataforma de dados atual me envie uma mensagem aqui que agendamos um diagnóstico gratuito. #dataengineer

Boa noite, uma nota de esclarecimento: Nos últimos dois dias eu tenho comentado anúncios pedindo arquitetos de dados com conhecimentos específicos; em nenhum momento tive a intenção de atacar essa ou aquela empresa, mas mostrar um fato que está acontecendo globalmente, não só aqui. De repente e sem nenhuma razão aparente jogaram fora os conceitos de uma profissão que existe a mais de 30 anos da mesma forma (arquitetura de dados) comparando-a à posição de especialistas de produto de software o que é totalmente improcedente e incorreto. Essa profissão, da qual sou um membro mais que orgulhoso tem orientação eminentemente LÓGICA - não tem NADA a ver com especialista de produto. É claro, um arquiteto de dados precisa estar à par das tecnologias de dados mais recentes, mas NUNCA ser um especialista em nenhuma delas. Um arquiteto de verdade precisa conhecer modelagem, metadados, governança, dados-mestres, segurança, padronização de dados, arquiteturas de bancos de dados e outras disciplinas para poder definir acervos de informação e métodos de gestão da informação como recurso. valioso para as organizações. Muito em entristece essa banalização da minha função, que ainda mais causa confusão no mercado, pois engenheiros de dados, profissionais de governança de dados(!!!) e engenheiros analíticos precisam ter os mesmos atributos o que não faz o menor sentido - para que QUATRO profissões para fazer a mesma coisa? Eu repostei os anúncios como anúncios válidos pois se trata de uma empresa de excelente reputação no mercado, mas não pude deixar de mencionar como arquiteto de dados sênior que os requisitos anunciados estão muito longe da definição real da função de arquitetura. Qualquer profissional que tenha lido o DMBOK da DAMA International vai notar que as funções não coincidem com as expostas nesse livro. Pior que tudo, essa distorção como eu já disse é global. "Ah, o mercado quer assim" - claro, mas desde quando o mercado está sempre certo? Racionalidade é característica de mercados evoluídos e essa mistura grosseira de conceitos não beneficia ninguém - é hora do mercado entender que há erros crassos aqui e que desmerecer as funções de TI por comodismo só piora as coisas. Profissionais de TI não são recursos descartáveis e se não acredita no que digo, dê a cada uma destas funções, do jeito que são descritas hoje, a tarefa de montar uma arquitetura de dados corporativa a nível global - haverá resultados e "resultados" - e aposte em qual destas profissões dará a versão mais completa e abrangente - Não serão as funções eminentemente analíticas, com certeza. Tudo que peço é um mercado racional, não essa insanidade e desvalorização de hoje. Não é à toa que é quase um consenso que trabalhar como contratado para empresas no exterior é a melhor opção.

Dev...sua camada de dados precisa ser bem feita. 1=>Deixe claro a separação arquitetural dentro do projeto, pode ser feito isolando a mesma como um componente de infraestrutura ou separando em pastas quais são os provedores de acesso a dados. Importante que fique bem explicito onde fica cada coisa dentro do seu projeto. 2=>Não misture logica de dados com logica de negocio, isso gera um alto acoplamento e dificulta a visibilidade do que seria cada coisa dentro do projeto. 3=>Existe a tendência de querer criar abstrações altamente genéricas para a manipulação dos dados, porem tome cuidado para que isso nao crie complexidade desnecessaria. 4=> Caso esteja em um cenários de múltiplos projetos que utilizam o mesmo mecanismo de acesso a dados, pense em criar sua camada como um pacote de distribuição para as outras aplicações. 5=> Por mais que sua camada de acesso a dados seja um detalhe da sua aplicação ela pode se tornar um detalhe poluente para sua solução. 6=> Comece pelo simples...abertura de conexão com o provider escolhido e depois crie outras complexidades conforme a necessidade, não se empolgue desnecessariamente.

Não deixe de olhar o seu DataViz(PowerBI) Por mais que sua arquitetura de dados pareça performativa e robusta, usando as melhores soluções e arquiteturas, ignorar a área de negócio (Data Mart) pode arruinar todo seu esforço e impactar negativamente seu projeto. Com o tempo, novas técnicas, funções e recursos são lançados e algumas coisas já não fazem mais sentido. - Remova colunas e medidas desnecessárias. (Measure Killer) - Categorize seus dados de maneira correta e defina as colunas-chave. - Desenhe de forma eficiente seu modelo dimensional (Tabular Editor) - Adote funções e estruturas corretas nas suas funções DAX (Dax Studio). Além de trazer melhorias nítidas no seu uso, reduzirá e muito o tamanho do seu projeto final!

🚀 Buscando Inspirações para Dashboards de Infraestrutura de TI! Olá, comunidade! Estou desenvolvendo uma matriz de rastreabilidade e montando dashboards no Power BI para monitorar projetos e atividades de infraestrutura de TI. A ideia é criar um painel que reúna indicadores estratégicos e operacionais, promovendo uma visão clara da eficiência, progresso e possíveis gargalos nas atividades. Gostaria de contar com a experiência de vocês! Quais indicadores vocês consideram essenciais para acompanhar a performance da infraestrutura de TI? Por exemplo: Utilização de recursos (CPU, memória, armazenamento); Disponibilidade e tempo de inatividade; Tempo médio de resolução de incidentes; Taxa de sucesso em migrações ou implementações. Aceito sugestões de indicadores, boas práticas ou até referências de dashboards que inspiraram vocês. Vamos trocar ideias? 🌐 Agradeço desde já pela colaboração! 👩💻👨💻 #InfraestruturaDeTI #Indicadores #PowerBI #GestãoDeProjetos #Dashboards

Você gostaria de acompanhar um Analista de Dados Senior desenvolvendo um projeto prático? Pensei em coletar alguns dados de uma empresa americana de compartilhamento de bicicleta, fazer uma limpeza e responder algumas perguntas de negócio comuns para esse tipo de análise. Pretendo usar ferramentas de um ecossistema diferente da Microsoft, para sair um pouco do padrão e aproveitar para ampliar as ferramentas do repertório de análise de dados. A idéia desse projeto é usar as ferramentas do ecossistema da Google, como Google Sheets para limpar, tratar e analisar os dados, Looker Data Studio para criar as análises gráficas e montar os relatórios e Google Slides para elaborar a apresentação com o desenvolvimento da solução e o resultado final para mostrar aos tomadores de decisão. Se você quiser acompanhar o passo a passo da construção dessa solução, basta fazer parte da Comunidade DS gratuitamente. Estou reunindo pessoas de vários níveis e áreas com interesse em crescer profissionalmente. Se você tem interesse nisso e quer fazer parte de um grupo assim, entra para nossa comunidade. Basta preencher o seu cadastro de afiliação através desse link: https://bit.ly/46yI5Yf

Projeto e modelo de negócio DBA/DW Uma empresa de tecnologia, decidiu fazer uma transição significativa de sua base de dados do Excel para um modelo DW transacional. Essa decisão foi tomada após uma análise minuciosa dos processos internos e das necessidades crescentes da empresa. No entanto, à medida que a empresa cresceu, inaugurou algumas filiais em diversas capitais e, consequentemente, a quantidade de dados aumentou exponencialmente, tornando-se cada vez mais desafiador gerenciar eficientemente as informações no Excel. Ao optar por um modelo transacional, a empresa decidiu busca melhorar a eficiência, a confiabilidade e a escalabilidade de suas operações de gerenciamento de dados. A transição para um sistema transacional permitirá que a empresa armazene e gerencie grande volume de dados de uma maneira mais organizada e estruturada. Ao final do projeto os benefícios foram: 💫 Capacidade de acessar dados em tempo real com atualização de informações instantâneas, o que economizará tempo valioso e permitirá tomadas de decisão mais rápidas e informadas. 💫 Maior segurança e controle de acesso aos dados, autenticação de usuários e criptografia de dados, para garantir a integridade e a confidencialidade das informações. 💫Escalabilidade do sistema transacional lidando facilmente com grandes quantidades de dados e expandindo sua capacidade de armazenamento conforme necessário. É simples, mas necessário; OBS: ♨Utilizamos o DB schema/Pentaho #powerbi #sql #dba #mysql

A maior qualidade de um Analista de Dados Sênior é a capacidade de iniciar um projeto pensando em: > Familiaridade pessoal com as tecnologias (afinal, ele quem vai encabeçar o desenvolvimento) > Usuários finais > Documentação > Familiaridade do responsável pela manutenção com os conceitos e ferramentas (muitas vezes criamos projetos como criamos filhos: para o mundo) Muito vejo falar sobre o primeiro, o segundo e o terceiro, mas raramente sobre o quarto, principalmente quando o contexto é o de um time de inovação. Frequentemente há um ambiente propício para a execução e o uso do projeto, mas a manutenção e a operação se tornam danosas ao time no médio ou longo prazo. Logo, é bom se perguntar: Seu time ou você é capaz de fornecer a manutenção e operação necessária? Se não for, para quem delegar? Em caso negativo, se torna necessário um reajuste de rota para comportar todas as etapas do produto de dados. Me conta, chovi no molhado ou esse é um tópico pouco abordado por aqui? #DataProducts #DataAnalysis #data #RProgramming