: :
os agilistas

ENZIMAS #195 – Saiba como funciona o Discovery em um projeto de dados

ENZIMAS #195 – Saiba como funciona o Discovery em um projeto de dados

os agilistas
: :

Marcelo Szuster: Bom dia, boa tarde, boa noite, este é mais um episódio de Enzimas, breves reflexões que te ajudam a catalisar o agilismo em sua organização.

Pedro Ivo: Bom dia, boa tarde, boa noite, aqui é Pedro Ivo, eu atuo como designer de produtos da DTI digital e a gente está aqui hoje para falar sobre discoveries em projetos de dados. Recentemente tivemos algumas experiências com um cliente que é uma seguradora e um dos discoveries que a gente teve oportunidade de conduzir com esse cliente chegou através de um desafio de aprimorar alguns relatórios gerenciais que até então eram gerados e visualizados através do Excel. A partir desse desafio a gente conduziu algumas entrevistas semiestruturadas e utilizamos algumas ferramentas de design para conduzir oficinas em que a gente conciliou algumas visões das áreas de negócio, do departamento jurídico da companha e também das áreas técnicas como arquitetura e engenharia, onde a gente inicialmente fez um diagnóstico sobre como esse primeiro relatório era gerado através de bases muito fragmentadas, que eram extraídas de locais diferentes e que eram atualizadas, algumas delas, manualmente por algumas áreas de negócio. Isso gerava algumas inconsistência e principalmente problemas de performance nesse relatório que precisava ser atualizado diariamente, mas que em função do volume de dados, do aumento dessa série histórica acabava endo atualizado duas ou três vezes na semana, porque esses problemas de performance já estavam inviabilizando, de certa forma, essa atualização diária. Além disso, como existiam essas bases de diversas fontes e principalmente que eram extraídas, eram manipuladas por áreas distintas da companhia e por seres humanos existia uma preocupação com a inconsistência em algumas informações e a necessidade dessa pessoa que até então gerava esse relatório de fazer cruzamento nessas bases, de vários tratamentos manuais para que o relatório estivesse gerado. Inicialmente a gente conduziu esse entendimento sobre o problema sustentando fazer algumas perguntas norteadoras sobre como o relatório era gerado, quais riscos eram associados a esse relatório, ou se nada fosse feito no modelo atual o que aconteceria. Uma das possibilidades era fragmentar esse relatório para que ele se tornasse dois ou três relatórios, o que poderia prejudicar a tomada de decisões de certa forma, porque eram dados relacionados, mas que estavam sendo a opção de fragmentar acabou dividindo ou piorando a visualização desses dados. Além disso a gente também tentou mapear qual o cenário ideal para a ferramenta nessas oficinas, atualização diária seria um dos cenários ideais, além disso melhorar o controle de acessos para que algumas informações sensíveis só estivesse disponíveis para alguns usuários em específico, e a partir desse momento a gente tentou trabalhar com os conceitos com as pessoas de negócio, entendendo que alguns conjuntos de dados tinham um a mesma nomenclatura, uma nomenclatura que se confundia, então a gente tentou fazer esse entendimento dos dados em específico, depois desse entendimento inicial voltado para o negócio. Conseguimos fornecer inicialmente uma solução provisória para que esses problemas iniciais já estivessem resolvidos o mais rápido possível e na sequencia trabalhamos também com o mapeamento de uma jornada futura, considerando a construção de um habilitador técnico, que no caso é um data lake, para que outras áreas da companhia também pudessem usufruir de uma ferramenta que permite a manipulação de um volume muito maior de dados, com mais segurança e uma melhor performance, disponibilizando esses dados para consumo em uma ferramenta adequada de visualização, que nesse caso era o Power BI. Então a partir desse momento a gente conseguiu fazer contato também com a área jurídica da companhia, estabeleceu alguns critérios para atender os requisitos legais e regulatórios da área de seguros e também a questão relacionada com a governança de dados, preenchimento dos relatórios de impacto de proteção de dados, em que a gente definia o ciclo de vida desses dados e quais eram as bases de tratamento adequadas de acordo com LGPD, que varia de acordo com o conjunto de dados que a gente está trabalhando, se ele for mais sensível, se existe um dado pessoal identificável ou não. Foi um trabalho interessante, que a gente conseguiu gerar esse valor para o cliente refaturando alguns relatórios e também construindo esse habilitador técnico para que futuramente esse mesmo cliente pudesse usufruir de uma ferramenta mais robusta para manipular e visualizar os dados.

Marcelo Szuster: Bom dia, boa tarde, boa noite, este é mais um episódio de Enzimas, breves reflexões que te ajudam a catalisar o agilismo em sua organização. Pedro Ivo: Bom dia, boa tarde, boa noite, aqui é Pedro Ivo, eu atuo como designer de produtos da DTI digital e a gente está aqui hoje para falar sobre discoveries em projetos de dados. Recentemente tivemos algumas experiências com um cliente que é uma seguradora e um dos discoveries que a gente teve oportunidade de conduzir com esse cliente chegou através de um desafio de aprimorar alguns relatórios gerenciais que até então eram gerados e visualizados através do Excel. A partir desse desafio a gente conduziu algumas entrevistas semiestruturadas e utilizamos algumas ferramentas de design para conduzir oficinas em que a gente conciliou algumas visões das áreas de negócio, do departamento jurídico da companha e também das áreas técnicas como arquitetura e engenharia, onde a gente inicialmente fez um diagnóstico sobre como esse primeiro relatório era gerado através de bases muito fragmentadas, que eram extraídas de locais diferentes e que eram atualizadas, algumas delas, manualmente por algumas áreas de negócio. Isso gerava algumas inconsistência e principalmente problemas de performance nesse relatório que precisava ser atualizado diariamente, mas que em função do volume de dados, do aumento dessa série histórica acabava endo atualizado duas ou três vezes na semana, porque esses problemas de performance já estavam inviabilizando, de certa forma, essa atualização diária. Além disso, como existiam essas bases de diversas fontes e principalmente que eram extraídas, eram manipuladas por áreas distintas da companhia e por seres humanos existia uma preocupação com a inconsistência em algumas informações e a necessidade dessa pessoa que até então gerava esse relatório de fazer cruzamento nessas bases, de vários tratamentos manuais para que o relatório estivesse gerado. Inicialmente a gente conduziu esse entendimento sobre o problema sustentando fazer algumas perguntas norteadoras sobre como o relatório era gerado, quais riscos eram associados a esse relatório, ou se nada fosse feito no modelo atual o que aconteceria. Uma das possibilidades era fragmentar esse relatório para que ele se tornasse dois ou três relatórios, o que poderia prejudicar a tomada de decisões de certa forma, porque eram dados relacionados, mas que estavam sendo a opção de fragmentar acabou dividindo ou piorando a visualização desses dados. Além disso a gente também tentou mapear qual o cenário ideal para a ferramenta nessas oficinas, atualização diária seria um dos cenários ideais, além disso melhorar o controle de acessos para que algumas informações sensíveis só estivesse disponíveis para alguns usuários em específico, e a partir desse momento a gente tentou trabalhar com os conceitos com as pessoas de negócio, entendendo que alguns conjuntos de dados tinham um a mesma nomenclatura, uma nomenclatura que se confundia, então a gente tentou fazer esse entendimento dos dados em específico, depois desse entendimento inicial voltado para o negócio. Conseguimos fornecer inicialmente uma solução provisória para que esses problemas iniciais já estivessem resolvidos o mais rápido possível e na sequencia trabalhamos também com o mapeamento de uma jornada futura, considerando a construção de um habilitador técnico, que no caso é um data lake, para que outras áreas da companhia também pudessem usufruir de uma ferramenta que permite a manipulação de um volume muito maior de dados, com mais segurança e uma melhor performance, disponibilizando esses dados para consumo em uma ferramenta adequada de visualização, que nesse caso era o Power BI. Então a partir desse momento a gente conseguiu fazer contato também com a área jurídica da companhia, estabeleceu alguns critérios para atender os requisitos legais e regulatórios da área de seguros e também a questão relacionada com a governança de dados, preenchimento dos relatórios de impacto de proteção de dados, em que a gente definia o ciclo de vida desses dados e quais eram as bases de tratamento adequadas de acordo com LGPD, que varia de acordo com o conjunto de dados que a gente está trabalhando, se ele for mais sensível, se existe um dado pessoal identificável ou não. Foi um trabalho interessante, que a gente conseguiu gerar esse valor para o cliente refaturando alguns relatórios e também construindo esse habilitador técnico para que futuramente esse mesmo cliente pudesse usufruir de uma ferramenta mais robusta para manipular e visualizar os dados.

Descrição

Como aplicar o processo de Discovery em um projeto de dados? No Enzimas de hoje, convidamos o Designer de Produto Pedro Ivo, que compartilha sua experiência com o projeto de uma seguradora. Quer saber como essa metodologia pode ser aplicada nesse contexto? Dá o play!

Quer conversar com Os Agilistas? É só mandar sua dúvida/sugestão para @osagilistas no Instagram ou pelo e-mail osagilistas@dtidigital.com.br que nós responderemos em um de nossos conteúdos!

See omnystudio.com/listener for privacy information.