Precisamos especializar a engenharia de dados

Em meu último post falei sobre a visão equivocada que muitos candidatos à área de dados possuem com relação a necessidade de se tornarem verdadeiros unicórnios da ciência de dados para ingressar na carreira. Nele eu explico sobre como essas expectativas são irreais e como esse perfil unicórnio não contribui para a velocidade dentro das iniciativas de dados.

We don’t need everyone to be a Data Scientist

A principal especialização que diferencia os Data Sicentists é o conhecimento que possuem em matemática e estatística. Agora, quando tiramos o foco da matemática, o bolovo que resta é popularmente conhecido como Data Engineering. O termo não é ruim pois de fato tudo se trata, de um modo ou de outro, de engenharia de dados; mas a diversidade de contextos e de demandas nos leva ao mesmo dilema do post anterior: queremos cavalos de corrida e não unicórnios.

É uma questão de foco. Se queremos andar mais rápido, precisamos de pessoas focadas em problemas específicos e que se tornem realmente boas (e rápidas!) em resolvê-los. Hoje na Creditas buscamos acelerar nossas entregas, então por isso vamos decompor o papel de um Data Engineer em três outros.

As necessidades da grande área de dados

Quando falamos das iniciativas relacionadas aos dados de uma organização, principalmente do ponto de vista gerencial, as necessidades são muitas: desde o armazenamento, a distribuição e a disponibilização até mesmo à descoberta, governança e entendimento dos dados. E nesse fluxo participam diferentes profissionais com diferentes focos e diferentes habilidades.

A imagem a seguir mostra um diagrama de como podemos dispor as diferentes demandas em relação às quatro grandes áreas de conhecimento necessárias para se extrair valor dos dados: negócio, banco de dados, programação e matemática (estatística).

Atividades necessárias para se extrair valor dos dados de uma organização

Historicamente, pela maneira como organizamos Data Engineering aqui na Creditas (e talvez como você se organizou também), grande parte dessas demandas é responsabilidade do nosso time. Dentre elas a lista de responsabilidades que já coloquei no primeiro post:

• construção de workflows para processamento de dados;
• crawlers para captura de dados;
• ingestão de dados via streaming;
• construção e organização do data-lake;
• modelagem e construção do data warehouse;
• deploy de modelos de data-science;

além dessas podemos acrescentar:

• governança de acesso às bases de dados;
• documentação das bases de dados;
• sistemas de captura de dados de usuários;
• disponibilização de dados analíticos no ambiente operacional,
• entre outras.

O problema do BOLOVO

Olhando para nossa estrutura de times atual sobre essas responsabilidades, a figura seria mais ou menos a seguinte:

A organização dos nossos times com relação às demandas de dados

• Data Science: time de cientistas de dados focados na construção de modelos que agreguem valor ao negócio, principalmente em termos de inovação e automação de tarefas repetitivas.
• Product Development: times formados por desenvolvedores e product managers focados em fazer entregas de tecnologia que agreguem valor ao negócio. Do ponto de vista de dados são os produtores dos dados operacionais e são os time de tecnologia mais próximos do negócio.
• Analytics: times de analistas de dados focados em acompanhar KPIs da operação e responder perguntas de negócio. Do ponto de vista de dados são os principais consumidores do ambiente analítico e os principais demandantes do time de Data Engineering.
• BOLOVO Data Engineering: nosso time de super-heróis/heroínas (não que os outros não sejam =) que fazem de tudo um pouco para atender todos os times acima em suas necessidades de dados no ambiente analítico.

Embora toda essa gama de demandas traga muita diversão e aprendizado ao nosso dia a dia, muitos problemas surgem deste cenário, gerando atrito, retrabalho e ineficiência. Para citar alguns desses problemas:

1. a falta de foco diminui a profundidade das pessoas tanto em termos de domínio quanto tecnológico;
2. a troca de contexto é sempre um pedágio que precisa ser pago;
3. não raramente há retrabalho por conta de entendimento parcial do domínio a ser atendido;
4. os relacionamentos interpessoais não se fortalecem como deveriam, uma vez que a cada tarefa é preciso interagir com uma pessoa diferente;
5. é difcíl crescer o time pois é difícil encontrar pessoas com tantas qualificações;
6. os salários tornam-se inflados por profissionais com pouca profundidade ou tempo de experiência.

Para completar essa lista, no momento atual estamos em uma etapa da empresa que precisamos ganhar velocidade. Ou seja, não dá mais, precisamos desmembrar esse unicórnio. (tadinhooo… 😭)

A medida certa de multidisciplinaridade

Se voltarmos ao princípio de tudo (calma, não tão longe assim), do surgimento do conceito de data science, veremos que o grande diferencial foi a capacidade de transpor barreiras. O que antes era feito por pessoas diferentes, cada uma a partir de suas próprias capacidades e limitações, passou a ser feito de um novo jeito, mais criativo, e com menos restrições por alguém com conhecimento multidisciplinar (o unicórnio).

Como resolver este dilema, então? Simples, com pessoas que sejam capazes de transpor uma barreira, e não todas. A figura a seguir mostra como decompomos o papel do "BOLOVO Data Engineering" em três novos papéis distintos.

Os novos papéis desmembrados a partir de Data Engineering

• Analytics Data Engineering: time focado em habilitar e acelerar a obtenção de respostas para as perguntas de negócio que precisam de análise de dados. Demanda infraestrutura do time de Data Platform Engineering e colabora estreitamente com Analytics.
• Data Platform Engineering: time focado na automação da captura e redistribuição dos dados, tanto no ambiente operacional, quanto no analítico. Colabora com os times de Product Development para a captura dos dados operacionais, e com Analytics Data Engineering e Machine Learning Engineering na organização do data lake.
• Machine Learning Engineering: time focado em apoiar os cientistas de dados, atuando em todo o ciclo de vida dos modelos, desde a captura de dados para treino até a produtização dos mesmos.

Incluindo no diagrama o fluxo de geração de valor, cada time colabora com os que estão ao lado para romper as inúmeras barreiras existentes entre a produção e armazenamento dos dados até seu uso em tomadas de decisão e inovação de negócio.

Nos próximos posts irei explicar melhor o que cada um desses "novos" papéis faz e quais as habilidades esperadas para cada um. Fiquem ligados(as) pois temos vagas por abrir! Até a próxima!

Tem interesse em trabalhar conosco? Nós estamos sempre procurando por pessoas apaixonadas por tecnologia para fazer parte da nossa tripulação! Você pode conferir nossas vagas aqui.