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:
- Quantos analistas você terá dedicados integralmente a construir o ETL. (Além dos analistas você vai precisar de um gerente.)
- 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.
- 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:
- Qual é a quantidade de processos automatizados pelo seu sistema transacional? Cada um equivale grosso modo a uma fato.
- 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.
- 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.)
- 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.
- Os dados de origem estão limpos ou sujos, do ponto de vista do domínio de cada coluna/campo.
- 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!)
- Um desenvolvedor PDI proficiente leva de uma a duas semanas para cada dimensão ou fato.
- 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.
- 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.)
- 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!