Estimando Projetos de ETL

Eu estimo a duração e o esforço necessários em projetos de BI baseado na minha experiência. Eu fiz uma auto-análise e redigi abaixo os passos que eu sigo mentalmente para chegar em um número inicial.

Coletando os Parâmetros

A minha mecânica para estimar o trabalho de desenvolvimento do ETL de um DW é relativamente simples. Eu procuro descubrir os seguintes números:

1. Quantos analistas você terá dedicados integralmente a construir o ETL. (Além dos analistas você vai precisar de um gerente.)
2. Quantas origens de dados você terá que tratar. Fonte de dados é tudo que possa vir a alimentar o DW: bancos relacionais de sistemas transacionais, files Adabas, arquivos texto/excel, páginas web etc.
3. Quantas fatos e quantas dimensões o MD deve ter. É impossível responder essa pergunta com precisão antes de o MD ser efetivamente construído, mas você pode estimar esse número:
   1. Qual é a quantidade de processos automatizados pelo seu sistema transacional? Cada um equivale grosso modo a uma fato.
   2. Quais são os parâmetros que provavelmente filtrarão as análises? Daí conte o número de atributos que têm a resolução mais fina. Por exemplo, se você vai filtrar por ano, mês e dia, a maior resolução é obtida com dia. Ignore os outros atributos e conte um atributo só. Se as análises serão feitas contra bairro, cidade, estado, o atributo que dá a maior resolução é bairro. Como cidade e estado são do mesmo tipo (geográfica), conte mais um atributo. No final você vai ter uma lista inicial de dimensões.
   3. Exemplo: se quisermos analisar o tempo de atendimento de balcão, você precisará medir a data e hora inicial (DHi), a data e hora final (DHf), posto (cidade-bairro-posto), atendente (sexo-idade-escolaridade-nome-cpf-etc.), demanda, resolução (resolvido/pendente), tipo (reclamação/elogio/pagamento/negociação/etc.), cliente (PF ou PJ, cada qual com sua lista de atributos). Temos uma fato (atendimento) e 8 dimensões (se cliente virar uma tabela só, ou 9 se for em duas.)
4. Volume de dados. Pode ser o tamanho de todas as bases em bytes e quanto ela cresce por tempo (dia ou mês), ou (preferível) quantidade de linhas iniciais adicionadas regularmente (dia ou mês) às fontes de dados.
5. Os dados de origem estão limpos ou sujos, do ponto de vista do domínio de cada coluna/campo.
6. Os dados de origem estão limpos ou sujos, do ponto de vista do relacionamento entre as fontes. Por exemplo: os dados do cliente estão divididos entre duas fontes (CPF, RG e nome numa, RG, endereço e estado civil em outra; ela é suja se houver lacunas ou diferenças de formato na chave, o RG.)

Definindo o Processo de Estimativa

Daí eu apela para a minha experiência. Supondo que um desenvolvedor seja capaz de entregar 4-5H de trabalho por dia: (alta produtividade!)

1. Um desenvolvedor PDI proficiente leva de uma a duas semanas para cada dimensão ou fato.
2. A medida que essa experiência cai, o tempo aumenta. Uma dimensão pode levar até mesmo um mês para ficar pronta se o analista começar o projeto sem conhecimento da ferramenta (ou mesmo com um curso.) Isso ocorre por que cada processo demanda um conjunto de truques particular, e o analista leva um tempo para internalizar a ferramenta e desenvolver seu repertório de macetes – como em qualquer outra ferramenta, aliás. Como passar do tempo esse número melhora, graças ao acúmulo de experiência do analista.
3. A quantidade de fontes de dados acrescenta mais alguns dias nesse número: de nada a alguns dias (até uma semana) a mais por fonte de dados. Isso ocorre por que pode ser necessário algum estudo para integrar as origens (pior caso) ou apenas um join pode ser suficiente (melhor caso.)
4. Volume de incremento no tempo: mais dois ou três dias para desenhar uma mecânica de tratamento de incrementos, que pode ser aplicada em todas as cargas. Esse tempo tende a sumir, diluído entre todos os processos de carga de dimensões e fato.

Sujeira: esse é o fator mais selvagem. Ele pode até dobrar o tempo de encerramento do desenvolvimento, a depender da quantidade de erros e sujeiras na base, e a capacidade do cliente em lidar com erros no DW (às vezes a sujeira não afeta a análise, às vezes a torna impossível.) Normalmente o impacto da limpeza de dados só vai ser conhecido no primeiro teste do processo e por isso não é usado para estimativas.

Estimando…

Então, para nosso exemplo com 8 dimensões, uma fato, com um banco relacional como única origem, dados 100% limpos e dois analistas (mais um gerente) você tem:

9 x 1 semana (cinco dias) / 2 analistas = 22,5 dias (~3 semanas).

É seguro triplicar esse número, para incluir todas as dificuldades não-previstas e adicionar um mês de overhead no início do projeto. Então temos 9 semanas + 1 mês = 13 semanas, o que dá uns três meses, mais ou menos, até a primeira versão beta do processo. Leva-se mais um ou dois meses entre ajustar o processo para produção e homologá-lo (controle de qualidade.)

Lembre-se que você vai precisar, também, estimar o tamanho da plataforma para entregar o refresh na latência requisitada por seu cliente.

Escrevendo na Pedra

Isso é só um parâmetro inicial, descontado o levantamento de requisitos, documentação etc. Com esse número em mãos eu reviso tudo que eu sei sobre o projeto antes de ele começar e uso minha intuição para ajustá-lo. Não raro eu entrevisto os analistas para entender o fator tarimba de cada um e verificar se eu fui otimista ou pessimista. Porém, esse número nunca é uma medida, mas sim apenas um chute elaborado (ou em bom inglês, um educated guess)  – variáveis desconhecidas podem mudar tudo completamente.

Quem é do ramo já deve ter percebido que o volume de variáveis desconhecidas e incertezas sugerem o uso de Scrum para gerenciar o projeto. Como o tamanho de uma transformação é de duas ou três semanas,  possivelmente eu adotaria isso como tamanho inicial das sprints, para fazer com que cada uma equivalha a entrega de uma transformação por analista. Após uma ou duas sprints a precisão desse número pode melhorar bastante.

O que você achou? Bate com o que você faz? Deixe seu comentário!