mais lidos
Life at Nu
Conheça a sede do Nubank em Pinheiros, São Paulo/Brasil jan 11
Design
A nova aparência do Nubank: conheça nossa nova logo maio 17
Culture & Values
Como os valores e a cultura da Nu moldam os produtos que criamos ago 7
Carreiras
Reunimos grandes mentes de diversas origens que permitem a discussão e o debate e melhoram a resolução de problemas.
Saiba mais sobre nossas carreiras



O que um Analista de Negócios faz exatamente?
Ouvimos muito essa pergunta, e a resposta muitas vezes surpreende as pessoas. Em algumas empresas, os Analistas de Dados criam painéis de Inteligência de Negócios (BI). Em outras empresas, os Analistas de Dados extraem dados e “executam consultas” para outras pessoas. Não é isso que fazemos.
Somos a divisão de Análise de Dados do Nubank, e percebemos que nosso nome transmite mal o que fazemos. Tanto interna quanto externamente. Nosso objetivo é tornar toda a empresa mais produtiva na utilização de dados, aplicando princípios estabelecidos de engenharia de software e técnicas de modelagem de dados a todos os domínios de negócios do Nubank.
Para o Nubank, os dados são cruciais. Não é novidade que uma empresa fintech moderna como a nossa utiliza dados em todos os lugares. Por exemplo, um caso de uso importante é a tomada de decisão automática para concessões e limites de crédito usando modelos de aprendizado de máquina (ML).
Não usamos dados apenas para a tomada de decisões. Também temos obrigações regulamentares de prestação de informações a autoridades como bancos centrais e entidades de prevenção a lavagem de dinheiro – sempre respeitando as leis de proteção de dados, independente do mercado em que operamos.
Nós, como Analistas de Dados, somos todos alocados em esquadrões, que são os times autônomos e multidisciplinares do Nubank. Em abril de 2020, tínhamos quase cem esquadrões, como Aquisição, Cobrança, Empréstimo etc. Um Analista de Dados trabalha para tornar os outros membros de seu esquadrão mais produtivos na utilização de dados.
Além disso, liberamos o restante do esquadrão de fazer tarefas pesadas de engenharia de dados, de modo que pudessem se concentrar em suas especialidades. Além do trabalho em seus respectivos esquadrões, todos os Analistas de Dados se reúnem às sextas-feiras para trabalhar em projetos horizontais. Por exemplo: como possibilitar a integração de dados entre empresas.
No Nubank, nos esforçamos muito para capacitar cada funcionário a utilizar os dados que julgar necessários para o seu trabalho, desde que estejam alinhados com a nossa política de privacidade de dados.
Para entender melhor como fazemos isso, primeiro explicaremos o cenário de dados antes dos Analistas de Dados. Segundo, apresentaremos a divisão de Análise de Dados e mostraremos seu foco e escopo em comparação às divisões já existentes. Por fim, avaliaremos a adequação do nome da divisão dentro e fora do Nubank, e pensaremos em alternativas.
Confira nossas oportunidades de trabalho
Conheça nossas oportunidades
Cenário de dados no Nubank antes de 2019
O banco de dados backend que você normalmente encontra no Nubank é chamado Datomic, uma tecnologia bastante incomum. O Nubank optou por usar o Datomic desde muito cedo porque acredita que esse banco de dados tem superpoderes. Um desses superpoderes é particularmente valioso para fins analíticos: o fato de o Datomic ser apenas cumulativo. Isso significa que, em condições normais, o banco de dados apenas acumula dados novos e não esquece (exclui ou modifica) dados antigos.
Isso é diferente de como as pessoas geralmente usam bancos de dados SQL. A diferença é que no Datomic você apenas INSERE novas linhas – você não pode ATUALIZAR ou EXCLUIR. Como resultado, os analistas e modelos de aprendizado de máquina (ML) do Nubank têm acesso a uma riqueza de dados históricos.
Por muito tempo, desde seu início em 2014, o Nubank conseguiu funcionar bem sem um sistema analítico separado e uma equipe de dados especializada. Em outras palavras, analistas de negócios, cientistas de dados e outras pessoas extraíram eles próprios os dados de que precisavam. Eles consultavam o Datomic diretamente e executavam a análise em sua própria máquina.
Além dos ocasionais resmungos sobre a linguagem de consulta alienígena do Datomic, a Datalog (a maioria das pessoas está acostumada com a linguagem SQL), esse “pipeline de análise” (ou a falta dele) funcionou bem inicialmente. O problema foi o declínio no desempenho das consultas, causado por uma base de clientes em rápido crescimento.
Além disso, o aumento do número de funcionários ávidos por dados só piorou a situação. Os analistas recorreram a truques inteligentes, como dividir suas consultas em partes e concatenar os resultados em suas máquinas. Isso funciona, mas não por muito tempo.
Podemos dizer que as consultas aos nossos maiores bancos de dados começaram a parar de verdade em 2016. Vimos que não poderíamos continuar assim, e precisávamos que nossos dados ficassem disponíveis em um banco de dados que atendesse especificamente a cargas de trabalho analíticas.
Ao mesmo tempo, não gostávamos da ideia de ter vários pipelines de dados personalizados e contratar equipes de engenharia de dados para cuidar deles – necessidades comuns na abordagem desses tipos de problemas de acesso a dados. Porém, não precisamos fazer isso, pois o uso universal do Datomic pelo Nubank nos permitiu implementar apenas um tipo genérico de pipeline de extração de dados. Dentro de um mês, todos os serviços foram conectados usando esse pipeline e os dados originais começaram a fluir para nossa plataforma de dados.
Decidimos construir uma plataforma de dados de autoatendimento. No Nubank, gostamos de investir em plataformas e abstrações desenvolvidas e mantidas em equipes horizontais por especialistas, para que generalistas em equipes verticais possam iterar rapidamente em alto nível de abstração.
Por exemplo, os engenheiros têm autonomia para implantar seu próprio software. Não temos uma equipe de DevOps que cuida desse tipo de trabalho. De forma parecida, nossa plataforma de dados de autoatendimento permitiu que as pessoas criassem seus próprios conjuntos de dados (visualizações materializadas) baseadas nos dados originais, e outras pessoas conseguem gerar novos conjuntos de dados baseados nesses subconjuntos, e assim por diante. Na verdade, precisávamos apenas de uma pequena equipe de infraestrutura especializada para cuidar da plataforma que processa as crescentes quantidades de dados.
A plataforma de dados de autoatendimento possui uma arquitetura ETL moderna típica. Extraímos todos os dados do Datomic e os salvamos em nosso data lake em um serviço de armazenamento em bloco na nuvem. Depois, nós o transformamos de um log Datomic em uma tabela relacional (usando o que chamamos de “contratos” – veja “Extração de dados e tomada de decisão” nesteartigo). Por fim, carregamos tudo em um banco de dados analítico que todos na empresa podem acessar – desde o atendimento ao cliente até os executivos.
A plataforma foi um sucesso, pelo menos em termos de rápida adoção. As pessoas ficaram felizes por poder acessar todos os dados (novamente) e começaram a contribuir com conjuntos de dados para a plataforma (veja nossa conversa no encontro sobre DS e ML em São Paulo para mais detalhes). Também melhoramos claramente em termos de desempenho de consulta.
Mas com o tempo, à medida que construíam com mais e mais novos conjuntos de dados, o data lake foi ficando confuso. Os analistas ficavam confusos com o grande número de conjuntos de dados com diferenças sutis e nenhuma indicação clara de qual deles usar em seu trabalho. Ao mesmo tempo, não houve incentivo para que os usuários da plataforma de dados investissem em modelagem e reutilização, o que teria organizado a bagunça. Infelizmente, mas sem nenhuma surpresa, os dados na nossa plataforma de dados foram se tornando uma “grande bola de lama”.
A empresa começou a sofrer com definições de dados cada vez mais conflitantes ou ambíguas. Ao mesmo tempo, não sabíamos quem deveria assumir a responsabilidade de focar nessas questões. Não se espera que os analistas estudem as melhores práticas de modelagem, e os engenheiros geralmente se concentram no lado transacional, não no analítico. Encontramos uma lacuna: ninguém estava focado na governança dos dados do Nubank.
No próximo mapa, modelamos mais ou menos as diferenças relativas de como quatro divisões relacionadas a dados (Analistas de Negócios, Cientistas de Dados, Engenheiros de Aprendizado de Máquina e Engenheiros de Software) investiram sua energia em cinco escopos relacionados a dados selecionados antes de 2019. Portanto, quanto mais longe o polígono colorido se afasta do centro, mais energia é gasta em tal escopo.
Finalmente, este mapa mostra que nenhuma divisão teve como foco principal Pipelines de Dados de Relatório e Análise e Governança de Dados e Modelagem Dimensional. Essa é a lacuna.
Apresentando uma função de dados especializada
Na tentativa de preencher a lacuna acima, decidimos introduzir uma nova função especializada em dados no Nubank.
Chamamos essa função de Analista de Dados, visto que alguns engenheiros que já trabalhavam em nossa infraestrutura de dados se identificavam como engenheiros de dados. Além disso, encontramos vagas de analista de dados em algumas empresas semelhantes ao que procurávamos. Os primeiros integrantes dessa nova divisão ingressaram no Nubank em outubro de 2018.
À medida que ampliamos a função e aprendemos a melhor forma de agregar valor de forma estratégica, a identidade dessa nova divisão evoluiu. Nossos analistas de dados atuam como multiplicadores, ajudando seu esquadrão a melhorar a legibilidade dos dados e o design dos fluxos de trabalho de dados. Eles promovem as melhores práticas em engenharia de dados, modelagem de dados e governança de dados.
Os analistas de dados também passam 20% do seu tempo trabalhando juntos em projetos estratégicos de dados que impactam a empresa como um todo. Esse tempo recorrente alocado fora do esquadrão é incomum no Nubank, mas essencial para nós, analistas de dados, já que um dos nossos objetivos é alcançar a integração horizontal de dados em toda a empresa (entre todos os esquadrões).
Abaixo descrevemos alguns exemplos de iniciativas nas quais os analistas de dados do Nubank estiveram envolvidos até agora. Os dois primeiros tratam de projetos específicos de esquadrões, e o terceiro trata da já citada integração horizontal de dados, por meio de uma iniciativa que chamamos de “Conjunto de Dados Centrais”.
Reconciliação automática de dados
Conforme apresentado em “Microsserviços no Nubank, uma visão geral”, um dos nossos problemas é detectar e responder às alterações no valor dos dados em tempo hábil. Além disso, ao unir dados distribuídos de diferentes microsserviços, pode ser complicado perceber que os valores são divergentes ou inconsistentes.
Fazendo parte de uma equipe intimamente ligada à Controladoria, alguns Analistas de Dados construíram um sistema de reconciliação automática para solucionar esses problemas. A equipe se inspirou nos testes de software tradicionais, que são categorizados em testes unitários e testes de integração. O sistema de reconciliação verifica o data lake todos os dias e garante invariantes para nosso sistema distribuído.
Auditoria contínua
Na mesma linha do nosso projeto de reconciliação automática citado acima, alguns Analistas de Dados da equipe de Auditoria Interna do Nubank construíram um sistema futurista de auditoria contínua. Atuando como uma última linha de defesa automatizada, ele é repleto de consultas automáticas que são executadas todos os dias. Ao ser acionado, o sistema envia seus resultados para outro sistema que auxilia os auditores no acompanhamento dos alertas acionados.
Essa automação elimina a necessidade de contratar uma grande equipe de auditores, o que normalmente é inevitável em grandes empresas. Os Analistas de Dados recentemente conseguiram ensinar aos outros auditores não técnicos como contribuir, sem ajuda, com a plataforma de verificações automáticas.
Governança de dados/Conjuntos de dados centrais
Uma das principais iniciativas de governança de dados que a divisão iniciou no início de 2020 é o design dos conjuntos de dados centrais. Os conjuntos de dados centrais oferecerão uma melhor experiência para os usuários de dados do Nubank, uma alternativa ao confuso data lake que temos hoje. Um conjunto de dados central carrega um selo de aprovação, reduzindo a sobrecarga cognitiva dos analistas quando procuram os dados para usar.
O selo garante quatro coisas:
A seguinte citação do excelente artigo:“A queda do engenheiro de dados”, de Maxime Beauchemin, captura bem o contexto:
“O armazém de dados precisa refletir o negócio, e a empresa deve ter clareza sobre como pensa sobre análise. Nomenclaturas conflitantes e dados inconsistentes em diferentes áreas, ou “data marts”, são problemáticos. Se quiser desenvolver confiança de uma forma que apoie a tomada de decisões, você precisa de um mínimo de consistência e alinhamento.”
Reconhecemos o enorme desafio de alinhar a empresa no que diz respeito às definições. Principalmente considerando que o Nubank se esforçou pouco para isso anteriormente. Mas tivemos a sorte de uma boa adesão dos usuários de dados de outras divisões da empresa desde que anunciamos nossos planos. Afinal, as pessoas estão cada vez mais sobrecarregadas pelo caos do nosso data lake, começando a reconhecer o valor da padronização.
Como resultado do trabalho árduo dos analistas de dados e das partes interessadas, estamos agora entregando os primeiros conjuntos de dados centrais. Eles estão deixando o status “alfa” e se tornando disponíveis para as partes interessadas da empresa – substituindo implementações legadas.
Para ser claro, o que hoje é conhecido como “conjuntos de dados centrais” era apenas uma vaga ambição quando iniciamos a divisão. No final de março de 2020, a ambição tornou-se realidade: lançamos o nosso primeiro conjunto de dados centrais e criamos um plano para o próximo trimestre. Nesse plano, é nossa divisão que busca consenso e orquestra as permissões dos conjuntos de dados centrais para as partes interessadas bem informadas.
Com o tempo, descobrimos como queremos resolver a lacuna de governança de dados no Nubank. Além dos conjuntos de dados centrais, também nos concentramos na classificação de dados e na minimização de dados pessoais. Acreditamos que nosso nome atual não reflete esses escopos.
Como mostra o próximo mapa, o Nubank preencheu a lacuna com o esforço de seus analistas de dados. A função de Analista de Dados cobre a responsabilidade pelos escopos descobertos anteriormente (que são “Pipelines de Dados de Relatório” e “Análise e Governança de Dados e Modelagem Dimensional”).
Surge a função de Engenheiro de Análise no Nubank
Ao longo de 2019, a divisão de Analista de Dados cresceu de 5 para 25 membros. Agora existem analistas de dados trabalhando em diversos esquadrões em todo o Nubank, colaborando com analistas de negócios, engenheiros, cientistas de dados, engenheiros de aprendizado de máquina etc. A divisão alcançou uma escala e cobertura grandes o suficiente para sermos capazes de abordar iniciativas de dados em toda a empresa. Mas com o aumento de escala, aumentou também a necessidade de maior clareza de funções durante suas interações.
Dado o nome, é perfeitamente normal que alguém presuma que os analistas de dados se concentrem em… bem, analisar os dados! Porém, a análise de dados não é a atividade central dessa função. Conforme descrito acima, a função é muito mais focada em análises mais produtivas por meio da governança de dados possibilitada pela engenharia. Então decidimos procurar um novo nome para descrever melhor essa função.
Desde o início, a função de Analista de Dados no Nubank tinha uma forte ligação com a engenharia. Para usar um conceito de desenvolvimento de software, basicamente “bifurcamos” a estrutura de desenvolvimento da carreira de engenharia do Nubank, adaptando algumas atividades, mas mantendo a maioria igual. Parecia apropriado que o nome da função refletisse seu foco de engenharia.
Observando como a indústria tem descrito funções que lidam com dados especializados ultimamente, acabamos com duas alternativas principais: Engenheiro de Dados e Engenheiro de Análise. Existem postagens recentes descrevendo funções muito semelhantes em espírito à função descrita aqui, usando tanto um nome quanto o outro.
Um exemplo interessante de uma empresa que definiu ambas as funções é o Spotify, onde os engenheiros de dados parecem concentrar-se mais nos desafios de engenharia de nível inferior, enquanto os engenheiros de análise estão mais próximos dos domínios de negócios, alinhados à função descrita aqui.
Uma vantagem do termo engenheiro de dados é que ele é mais amplamente utilizado e reconhecido na indústria. No entanto, a definição do que um engenheiro de dados faz varia amplamente em diferentes empresas. O recente termo engenheiro de análise, por outro lado, tem sido usado de forma muito menos ambígua. Optamos por aquele que traz mais clareza:
Os analistas de dados do Nubank agora são chamados de Engenheiros de Análise.
A divisão concorda unanimemente que o nome se adapta melhor ao trabalho que realizamos. Ao mesmo tempo, é um pouco arriscado mudar nosso nome. Principalmente pensando em contratações. Tivemos a sorte de contratar uma equipe incrível de engenheiros de análise com nosso anúncio de emprego para analistas de dados.
Em outras palavras, teríamos encontrado as mesmas pessoas se tivéssemos usado o nome engenheiro de análise anteriormente? Como sempre, examinaremos atentamente nosso processo de contratação para garantir que ainda estamos atraindo as pessoas certas com nosso novo nome.
Também teremos que trabalhar muito na comunicação interna e externa, garantindo que todos no Nubank saibam o que faz um Engenheiro de Análise. Até agora, não investimos muito na divulgação da clareza das funções porque queríamos descobrir como deveria ser o nosso escopo ideal. Estamos muito mais confiantes sobre isso hoje, e prontos para começar a espalhar a palavra.
Conheça nossas oportunidades