[Equipe] Por que tantos cargos de Dados? Preciso criá-los em minha equipe?

"Na minha época era tudo uma coisa só!"

Uma pergunta e uma afirmação que muitos profissionais de Dados de gerações anteriores usam para demonstrar um descontentamento ao se depar com distintos nomes de cargos da área. E é verdade, "naquela época" era tudo uma coisa só...

Assim como ainda mais anteriormente "àquela época", todo profissional da área trabalhava com Processamento de Dados . Assim como em décadas passadas todo profissional de Tecnologia era Engenheiro. Assim como em séculos passados Fisioterapeutas, Enfermeiros e demais cargos da saúde eram Médicos da Família.

E tem problema nisso?!

TL;DR: Se você já estudou ou leu sobre Fordismo, a resposta para a pergunta do título deste já foi respondida na sua cabeça e a leitura do mesmo é dispensável (a não ser que queira entender como isso está acontecendo na área de Dados)!

Quando comecei a trabalhar com Dados haviam 2 tipos profissionais no mercado: DBAs e Analistas de Business Intelligence (BI). Na rotina desse último, que era onde eu me enquadrava, nosso dia se resumia a atividades de:

(I) Integrar com bancos de dados e sistemas da empresa;

(II) Extrair dados para um local central;

(III) Limpar, Transformar e Organizar dados;

(III) Construir relatórios e dashboards para monitoramento de indicadores.

E pasmem...Hoje essas mesmas 4 atividades comuns seriam feitas por pelo menos 4 profissionais com cargos de Dados distintos. (Alguém imagina quais?)

Mas por que não dá pra continuar centralizando tudo em um único cargo, no Analista de BI?! Vou te explicar porque:

1. Há 10 anos atrás você chegaria em uma empresa para trabalhar com bancos de dados SQL Server, MySQL ou no máximo com algum conector bem específico de algum ERP.
2. Para organizar e transformar os dados você iria se deparar com soluções OLAP ou OLTP e decidiria entre umas 3 soluções de ETL da época.
3. Na hora de construir relatórios você teria a disposição algum SAP BO (isso se fosse uma empresa grande) ou precisaria aprender sobre uma solução de dashboards tão específica e customizada da empresa que você sabia que nunca iria utilizar daquele conhecimento fora dali.

Desse ponto do artigo pra frente você imagino que você achou que eu iria trazer o comparativo dos passos anteriores mas na visão de hoje, certo? Olha, eu adoraria, mas esse artigo passaria de 5 páginas porque cada item da lista anterior virariam pelo menos outros 3.

Atualmente, ao chegar em uma empresa você:

• Vai se deparar com a necessidade de integrar com bancos de dados relacionais, não-relacionais, dispositivos externos, sistemas e páginas web, redes sociais, (coloque aqui qualquer uma das milhares de fontes internas e externas que trazem informações valiosas para sua empresa).
• Vai precisar decidir entre construir um Data Warehouse padrão, ou um Data Lake, Data Lakehouse, usando algum framework do tipo Medallion Archicteture, ELT (ao invés de ETL). Ou usar alguma das centenas de soluções de arquitetura e transformação open-sources ou pagas do mercado.
• Vai precisar entregar relatório utilizando alguma das dezenas de ferramentas de BI no topo do quadrante mágico do Gartner ou usar alguma das dezenas de bibliotecas de Visualização de Dados (D3.js, Shiny, Seaborn, Plotly, .etc) e subir uma aplicação web pra simplificar o uso pelos usuários.

Nesse ponto você deve estar pensando: "Mas poxa, a galera tá criando prego pra martelo!" (Pra quem não conhece esse ditado, ele define um comportamento improdutivo de procurar problema para uma solução, quando o mais eficiente deveria ser o inverso).

E é ai que entra o desafio! Nenhuma dessas centenas de soluções de Dados da atualidade são iguais. Cada uma traz contigo soluções específicas para problemas específicos. E vou te dizer...São muitos os problemas específicos, muito mais do que víamos "na minha época". Problemas de volumetria, velocidade entre a ingestão e consumo, governança, perfis de consumo, qualidade de dados e etc.

E diante de tantos problemas específicos e soluções específicas, é de se esperar que um único cargo não seja mais capaz de resolver a todos. Os Analistas de BI se "descentralizaram" em Analistas de Dados, Engenheiros de Dados, Data Engineers, Cientistas de Dados, Data Product Managers (ou Data Strategists ou Data Translators).

Isso quer dizer que precisamos ter todos esses cargos em nossos times de Dados? NÃO!

Isso quer dizer que o Analista de BI não existe mais? NÃO!

Isso quer dizer que, especialmente como líderes, precisamos entender quais as especificidades da empresa e qual conjunto de atuações específicas são ou não necessárias.

Isso também quer dizer que, como líderes, precisamos analisar e entender profundamente se um novo cargo surgindo no mercado é apenas uma variação, uma hype ou uma real necessidade para o momento atual e futuro do negócio e da sua estratégia.