Há coisas que são um completo mistério para mim. Por exemplo, porque algum professor acredita que um trabalho em grupo pode produzir conhecimento para os alunos.
Quero dizer, todo mundo sabe: um cara faz e o outros olham. Eu sempre fui assim, fazia tudo e mandava os outros ficarem calados e quietinhos – eu não queria nenhum mané estragando minhas notas, ou pior: ter que explicar tudo para eles! :-P
Mesmo assim, trabalhos em grupo viraram um componente básico de tudo quanto é curso. Eu estou fazendo um segunda graduação e todo santo semestre eu preciso entregar um trabalho em grupo, o famigerado Projeto Integrador.
A idéia – como todas as idéias – tem lá o seu sentido: dar aos alunos um espaço para aplicar o que aprenderam ao longo do semestre. Mas, como todas as idéias, há uma grande diferença entre a imaginação iridiscente dos docentes e a dura realidade discente.
O problema mais frequente é justamente um só aluno assumir o trabalho pelo grupo, quando os alunos simplesmente não saem no tapa por causa do projeto. (Sim, brigas que não chegam às vias de fato porque o curso é 100% EAD.)
Parte da nota da matéria é uma auto-avaliação, cujos critérios são dados pelo instrutor e cada membro atribui a si mesmo quanto acredita que merece. Neste semestre, porém, veio uma novidade: nós, membros do grupo, deveríamos escolher três critérios de auto-avaliação e realizar a avaliação de cada membro por estes critérios.
Caramba!
É fácil se atribuir nota máxima para um critério vago como “Dedicação ao resultado” ou “Participou ativamente” – afinal, são muito subjetivos. Mas quando te dão a responsabilidade de criar o critério, você enfrenta um problema muito pior:
Se você criar um critério fácil, o instrutor vai notar que você está tentando se safar e conseguir uma nota alta – ou seja, está sendo imoral;
Se você criar um critério difícil, vai prejudicar a si e aos seus colegas, fora o papel de bobo de ter se dado uma meta que você sabe que não atingiu.
E agora, José?
Como físico e um cara de BI, eu tratei o problema como um assunto de negócios. Primeiro, eu me coloquei no lugar do professor e me perguntei o quê, em um trabalho em grupo, eu gostaria que acontecesse. Achei isso:
Que o volume de trabalho fosse dividido de maneira equilibrada entre os membros;
Que a dedicação de um membro (ou falta desta) impactasse o grupo como um todo;
Que os membros levassem suas tarefas à sério e não desemcumbissem-se meramente para cumprir tabela.
Pensei em alguns outros parâmetros, mas acabei ficando com esses por entender que são mais fundamentais.
Como sabemos de Lean, uma forma de provocar um comportamento é medi-lo. Logo, eu precisava criar métricas objetivas que levassem os alunos a se auto-organizar e se policiarem mutuamente.
Depois de alguns momentos de rilhar de dentes, cheguei nestas métricas:
Colaboração
A qualidade do resultado final é diretamente dependente do entrosamento e do trabalho em time. Um cara que nunca aparece nas reuniões e nunca participa das discussões é a raiz de um problema: se ele não entendeu como as tarefas foram definidas e divididas, ele provavelmente vai dar mais trabalho e gerar menos resultado.
Por isso eu defini a nota de Colaboração como uma nota individual, representando um percentual de participação em reuniões, indo de zero porcento (nunca deu as caras) à 100% (esteve em todas!)
Entrega
Além de trabalhar em time, colaborando com os colegas, o integrante precisa ser responsável e realizar as tarefas distribuídas para ele e precisa fazê-lo dentro de um prazo, com qualidade.
Putz, qualidade? Isso não é subjetivo? Sim, mas eu achei uma forma: cada membro tem sua tarefa revisada por pelo menos dois outros (somos em seis no meu grupo.) Assim cada um tem que prestar contas aos colegas, que por sua vez não vão aceitar um resultado que vão prejudicá-los adiante. Em outras palavras, eu dei um jeito de enfiar a coação social do Scrum no trabalho de escola. U-lá-lá!! :-D
Resta a questão de dar um número para isso. Eu chamei essa métrica de Entrega, indivual, como uma média aritmética de dois outros parâmetros: “Dentro do Prazo” e “Qualidade”.
“Dentro do Prazo” é calculado como a distância entre a data na qual o aluno entregou a sua parte e o deadline para aquela parte. Se ele entregar antes ou no dia, recebe 10 em Entrega, com penalidade de dois pontos a cada dia atrasado, até ter zero se atrasar cinco ou mais dias.
“Qualidade” eu defini quase do mesmo jeito: uma nota começando em 10 e caindo 1 ponto a cada erro encontrado por outro membro da equipe. Assim, dez erros daria zero e nenhum erro, nota máxima.
Finalmente, nota Entrega = (Dentro do Prazo + Qualidade ) / 2.
Ah, os números. Eles realmente são mágicos!! Agora eu já tinha duas notas para nos avaliar! Que alegria! :-)
Só que o curso exige três notas de auto-avaliação. E eu ainda não tinha amarrado a divisão de tarefas. Resolvi criando a última métrica, que pressionasse o aluno a participar do trabalho e se comprometer com o grupo como um todo – algo na mesma linha da primeira métrica, de Colaboração, mas que afetasse todos a partir de um.
Carga
Essa é uma nota única para o grupo inteiro: se um membro fizer corpo mole (ou se um decidir ser fominha, como eu era), o grupo inteiro sai prejudicado.
O truque foi usar uma medida estatística: desvio-padrão.
Como? Fácil: a cada reunião tínhamos uma série de tarefas para fazer, distribuídas entre os alunos. Daí bastou calcular o desvio-padrão usando N como tamanho do grupo, a quantidade de tarefas como cada amostra, e a média de tarefas por membro. Voi-lá!
Como eu quero notas de zero a dez, eu defini: Carga = 10 – 2*sigma.
Se todo mundo pegasse exatamente a mesma quantidade de tarefas, fosse um ou dez, sigma (o desvio-padrão) daria zero e a nota seria 10. Se um só cara fizesse tudo, sigma chegava perto de 5 com apenas 12 tarefas – como se um só acumulasse duas tarefas de todo mundo – e isso nos daria zero.
E porque isso é legal? Ora, por uma simples questão de produtividade! A vantagem do trabalho em grupo sobre o individual é poder produzir mais em menos tempo e com menos esforço. Quando todas as tarefas estão em um único membro, o trabalho atinge a produtividade individual e o valor do grupo vai a zero – que é o que normalmente acontece.
Por outro lado, quanto mais dividida as tarefas são, maior é a produtividade do grupo como um todo – e maior o benefício desse tipo de exercício. Usando sigma eu consegui que mesmo um folgado ou um fominha já ferrasse o grupo inteiro, dando rédeas aos instintos de cada membro.
Eu sou o máximo!!!
Conclusão
Estamos em 2021, já com centenas de anos nas costas usando o mesmo modelo de educação. Esse formato já era, não serve mais e é fácil notar: estamos no meio de um enorme apagão de mão-de-obra. Graças à peste chinesa, está ainda pior porque nossos cérebros estão sendo contratados no exterior, com a mesma facilidade que seriam contratados aqui. Se existe tanta demanda por mão-de-obra, como então não estamos vendo um crescimento explosivo em cursos de formação profissional? Deveria ser o mercado mais aquecido! E não é!
Eu realmente queria deixar aqui as referências – talvez um dia eu volte a este post e conserte esse problema. Agora passa da meia-noite e ainda não entreguei o trabalho da facul e amanhã preciso pular cedo da cama, então vai como está. Sorry. :-(
Porém, um pouco de visão de negócio, uma relada de Lean e uma pitada de Scrum corrigiram – para mim – um problema que me aporrinha desde que eu era um moleque besta na quinta série.
This is Business Intelligenceeeee!!!
OUVIU ISSO, FÊSSOR? É ASSIM QUE SE FAZ!!! PRO INFERNO COM SEU DIÁRIO DE CLASSE!!!
Se você, que me lê, experimentou sucesso aplicando as técnicas ágeis a projetos de BI, mesmo que um sucesso relativo, me conte.
Bom, um dos meus amigos viu o post e me ligou: ele conseguiu! Maycon Queirós, o convidado do episódio #11 do OSBICast, adotou a prática ágil na empresa em que trabalha. E na conversa que se seguiu ele me contou o segredo, o que deu certo e o que deu errado. Este post destaca esses pontos. Boa diversão! :-)
“Considere que cada técnica ou boa prática é uma opção em um grande buffet, considere também que para se servir desta infinidade de opções é preciso ter um prato. O prato que você pega ao se dirigir ao buffet é o seu método-base, aquele que você acredita que mais tem afinidade e valor para seu processo de trabalho.”
O Maycon, em conjunto com colegas de equipe, construiu um processo ágil que segue essa filosofia. Em princípio, eles aplicam um Scrum com sprint de duas semanas, com todos os ritos (priorização, planejamento, demo e revisão) e, no lugar de histórias, eles falam demandas ou requisitos.
Uma coisa que ele notou é que o processo começou encaroçado, em que vários erros e idas e vindas aconteceram. Porém, por conta da natureza iterativa do Scrum, e das práticas de inspeção, auto-crítica e modificação, eles melhoraram a cada sprint. Hoje eles possuem um processo que funciona, dá resultado e gera pouco desperdício.
Por exemplo, as primeiras sprints precisaram tratar de infra-estrutura, qualidade de dados e aprendizado da equipe. Volta e meia algo retornava para ajustes, falhas eram corrigidas e processos eram melhorados. Conforme a comunicação como cliente melhorava, conforme a equipe ficava mais entrosada, e os problemas iam sendo tratados, a velocidade começou a aumentar.
Durante essa maturação ele realizaram algumas adaptações:
Standup/daily: o time faz duas reuniões rápidas todo dia. Uma de manhã, em que planejam o dia, e outra no encerramento, em que avaliam o que aconteceu.
Priorização: normalmente faz-se a priorização no planejamento da sprint. Eles fazem isso, mas fazem uma repriorização no meio da sprint.
Padrões: toda demanda que recebem entra via um modelo de solicitação, poupando tempo e ganhando velocidade;
Demo/Review: apresentam o resultado para o cliente e depois fazem a auto-análise e auto-crítica – padrão. O que ele apontou como diferente é que não evitam puxar a orelha do cliente se ele tiver algo errado.
Porém, na percepção dele, o que realmente faz diferença é a comunicação. Mas, uma coisa de cada vez: primeiro, vamos ver cada um destes aspectos em mais detalhes e depois veremos o detalhe da comunicação.
Ritos Não Tão Retos
Uma vez feita a priorização com o cliente (metade de um dia) e planejada a sprint (a segunda metade), eles entram no ritmo diário de daily stand-up, até concluir a sprint, quando realizam a demo para o cliente (primeira metade do dia) e a review (segunda metade).
“A gente costuma resolver os dois pontos (tanto do início quanto do fim da sprint) em menos da metade de um dia (em parte por fazer a revisão das prioridades no meio da sprint). Procuramos ser objetivos nas reuniões (principalmente quando envolvem outros times) para otimizar ao máximo o tempo.”
E o que acontece se sobrar tempo?
“A gente já acerta o que vai entrar para a próxima sprint com o cliente fazendo eventuais ajustes na prévia do que foi acordado na reunião da semana anterior. Isso costuma ser rápido por conta desse trabalho antecipado, mas nesse ponto a gente já conseguiu deixar todas as tarefas pontuadas e negociamos o que pode ser deixado para uma sprint seguinte caso a carga ultrapasse o limite de pontos que estabelecemos por sprint. Antes de começar a sprint nova, fazemos a review interna junto com a retrospectiva, o que sobrar de tempo nesse dia a gente já dedica para as tarefas da nova sprint.”
A daily tradicional é um ritual em que cada membro da equipe conta o resultado do dia anterior (o que foi feito), o plano do dia (o que será feito hoje) e as dificuldades. Quando todos fizeram isso a daily acaba e quem não tem mais nada a resolver parte para o trabalho. Quem precisa de ajuda se reúne com quem pode ajudar e debatem como resolver os problemas. Depois, esses também partem para o trabalho.
Entretanto, a equipe do Maycon realiza duas dailys por dia. A primeira do dia, de manhã, é usada para se falar sobre o que será feito. Daí, nesta mesma reunião eles já conversam sobre como realizar o trabalho, que problemas podem aparecer e que soluções devem aplicar. É como um conselho de classe, pelo que eu entendi: um fala, os outros ouvem e dão dicas, palpites, sugestões e avisos de riscos e perigos. Quando todos houverem falado, a gangue se separa para cuidar do próprio trabalho.
Daí, no final do dia, eles voltam a se encontrar para avaliar o que aconteceu. Revisam o trabalho do dia, se algum problema novo apareceu e simplesmente acabam o dia. Na minha opinião é um modelo interessante, por que poupa o esforço de se lembrar do que aconteceu e sumariar em poucas palavras. Não sei como é com programação mas, em BI, isso é um trabalho considerável. Poder fechar a porta todo dia e não precisar carregar isso para o dia seguinte me soa como algo muito bom.
No scrum padrão a sprint segue ininterruptamente, até o final. No caso deles, não: no meio da sprint eles fazem uma repriorização. Eles examinam o ritmo de produção, o backlog e decidem se vão pegar mais alguma coisa, ou se vão apenas terminar o que estão fazendo. Como eles envolvem o cliente neste momento, o resultado líquido é uma indicação de como o projeto está indo e o que provavelmente vai ser abordado na próxima iteração. Nas palavras dele:
“Nessa repriorização às vezes fazemos mudanças na sprint atual se houver algo mais urgente, mas o principal propósito é já ter uma prévia da próxima sprint, assim a gente já chega mais preparado pra quando ela começar, assim fazemos o refinamento prévio dessas demandas para entrar com elas já redondas.”
Olhando de fora parece que eles param muitas vezes para rever o andamento do trabalho e replanejar. Pelo que o Maycon descreveu, esses processos são leves, e não ocupam tanto tempo assim. Além disso, o backlog selecionado para sprint nunca ultrapassa 80% do tempo da sprint.
Foi aí que eu notei o padrão: tempo para inspeção espalhado ao longo de todo trabalho.
Eureka! :-)
Priorização
Uma coisa que vocês precisam entender sobre o Maycon é que ele é um gênio disfarçado. Conversar com ele é uma tranquilidade – um cara ponderado, rápido de pensamento, mas muito paciente para falar, ótimo ouvinte. Um cara gente-fina. Daí, no meio da conversa você percebe que ele está olhando longe, muito longe. Metaforicamente falando. Quando você começa a perceber os detalhes do que ele construiu, das escolhas que ele fez, tudo começa a brilhar. Daí que, de repente, você nota que ele é qualquer coisa, menos uma pessoa ordinária. Um gênio, escondido no meio do dia-a-dia. O padrão de deixar tempo sobrando é uma dessas genialidades.
Ele aplicou a Teoria das Restrições ao processo ágil.
A Theory of Constraints (ToC) é um paradigma administrativo e intelectual no qual o principal parâmetro de operação de uma orgamização é o fluxo de trabalho. De acordo com ela, quando esse fluxo sofre interrupção por uma restrição (constraint), a produtividade sofre e a lucratividade cai. A solução é identificar essa restrição e removê-la, para que a produtividade cresça. Se tiver interesse no assunto, leia A Meta e Não é Sorte, ambos do criador da teoria, Elyahu Goldratt.
A ToC foi desenhada para tratar indústrias, mas ela é tão poderosa que se aplica em praticamente todas as indústrias e até mesmo em TI, mesmo quando a maior parte do trabalho é intelectual. Para um bom exemplo dessa situação leia Corrente Crítica, do Elyahu Goldratt, e Projeto Fênix, de Gene Kim e outros.
Como toda sprint, a deles começa com a priorização das demandas pelo cliente. Depois eles aplicam o básico do planning poker com Fibonacci para determinar o esforço envolvido. Não existe uma correspondência direta, mas eles se acostumaram a pensar nos pontos como uma escala de dificuldade. Uma coisa com 1 ponto é considerada trabalho de algumas horas. Com dois pontos, um dia, com três, dois dias, cinco dá uma semana (meia sprint), com oito e treze pontos correspondendo à sprint inteira ou maior. Nas palabras dele:
“A ideia também é tentar evitar itens com pontuações muito altas na sprint, pois isso aumenta a incerteza do tempo de entrega. Procuramos quebrar em partes menores essas demandas mais complexas. Normalmente, não temos demandas com pontuação acima de 5 na sprint.”
Daí, eles selecionam trabalho para encher até, no máximo 80% da sprint. Aprovam com o cliente e começam.
Por quê eles fazem isso? Nas palavras do próprio Maycon, por que eles sabem que a chance de aparecer um imprevisto durante a sprint é grande. Se eles alocarem 100% do tempo ao trabalho, as emergências vão ser um duplo transtorno: vão atrasar a sprint e ficar sem atendimento. Por outro lado, se não acontecer nada, eles podem terminar com calma, o que reduz a chance de erros, podem também começar a se preparar para a próxima iteração.
A importância dessa folga que eles deixam foi descoberta pelo Elyahu Goldratt e tornada bem clara no Projeto Fênix:
O tempo de espera é dado pela razão entre a porcentagem de tempo ocupado pela porcentagem de tempo livre. Em outras palavras, se um recurso está ocupado 50% do tempo, então ele está livre 50% do tempo. O tempo de espera é 50% dividido por 50%, portanto, uma unidade de tempo. Vamos dizer que seja uma hora. Então, em média, nossa tarefa esperaria na fila por uma hora antes de ser atendida.
Por outro lado, se o recurso está ocupado 90% do tempo, então o tempo de espera é 90% dividido por 10%, ou nove horas. Em outras palavras, a tarefa esperaria nove vezes mais tempo na fila do que se o recurso estivesse livre por 50% do tempo.
The Phoenix Project, Kindle Edition, Posição 3638.
O gráfico abaixo, tirado do mesmo ponto no livro, mostra o que acontece com o tempo de espera por um recurso em função do tempo livre desse recurso:
Tempo de espera em função de tempo livre.
Quanto mais você ocupa um recurso, mais você atrasa a fila.
Vai daí que ao manter 20% de reserva de tempo na sprint, Maycon e equipe garantem que seu tempo de espera é de 80% / 20% = 4 unidades. Se a sprint toda leva 10 dias, 4 unidades são 4 dias. Mas a conta é melhor do que isso. Veja, pela definição, 4 dias seria o tempo de espera até o recurso (a equipe) acabar a tarefa corrente para poder se dedicar à emergência. Mas, como eles reavaliam o planejamento todo dia, então eles têm um horizonte de oito horas, o que dá 4 horas de tempo de espera.
Lido de outra forma:
O trabalho planejado ocupa 8h por dia;
Por definição, eles assumem 80% de carga do dia;
A definição de tempo de espera é % ocupado dividido por % livre;
O tempo de espera no dia é de 6,4 horas (80% de 8h) dividido por 1,6 horas (20% de 8h), ou 4h;
Portanto, qualquer tarefa que apareça de surpresa terá que esperar no máximo 4 horas para receber atenção.
Se você achou confuso, pense nessa situação no extremo de ocupação total (100%): a tarefa ficaria na fila indefinidamente, até a sprint acabar. Com 80% de ocupação, ela fica no máximo 4h. E dizemos “no máximo” por que cada pessoa tem seu próprio tempo de espera. Se todo mundo estiver sincronizado, e qualquer um puder pegar a emergência, então em no máximo quatro horas vai haver alguém disponível. Como ninguém anda no mesmo ritmo, sempre tem gente com uma fila menor e que pode tratar a emergência o quanto antes.
E isso é simplesmente genial.
Ele eliminou o problema de incêndios afetando o desenvolvimento. Quantas vezes você viu alguém fazendo isso? Eu vi o pessoal dobrando o tempo prometido para ter gordura para queimar, mas nunca limitando o trabalho para ter fluxo!
Modelos
Uma vez que ele domou as constantes interferências não-planejadas, a maior fonte de atrasos de um projeto simplesmente sumiu. Veja, ele não ficou mais rápido, mas sim achou uma forma de não ficar mais lento. Com essa mesma mentalidade eles trabalharam cada aspecto do projeto, melhorando e buscando formas de ganhar produtividade.
Uma das formas encontradas por eles foi normalizar as demandas: cada história, chamada de requisito ou demanda, é sempre de algum tipo que eles já fizeram:
Relatório;
Extração de dados;
Análise (OLAP);
Painel.
Raramente algo cai fora dessa lista. Na pior das hipóteses os dados não estão disponíveis, e eles precisam escrever ou atualizar um processo de ETL. Na melhor das hipóteses eles precisam apenas construir o artefato de entrega. Então, por exemplo, para um relatório o modelo fonte de dados, título, colunas, agregação, filtros, rodapé, gráfico etc. etc. etc.
Para cada uma dessas demandas há um modelo de requisição. O cliente preenche esse modelo e submete à equipe. Nem sempre o modelo vem totalmente preenchido, claro, ou com todos detalhes necessários (às vezes aparecem coisas que ainda não foram pedidas.) Quando a equipe examina o modelo, ela avalia a necessidade de dados e conversa com o cliente para definir os pontos em aberto, refinar o entendimento e acertar o entregável. Uma demanda nunca começa a ser atendida sem haver uma grande compreensão do que é para ser feito – tanto por parte da equipe, quanto por parte do cliente.
“É comum fazermos sugestões com base em demandas que entregamos anteriormente com o intuito de enriquecer a solicitação ou simplificar o escopo para entregar o resultado esperado com menos esforço.”
No começo, o Maycon contou, a comunidade de clientes da equipe de BI torcia o nariz (e alguns ainda torcem), mas com o tempo a cultura de usar modelos e conversar com a equipe se formou e hoje é aceito normalmente.
Review
Além de tudo isso, o Maycon acredita que um aspecto que colabora para o sucesso do processo ágil deles é o rito de encerramento da sprint. Eles não fazem nada de realmente diferente: no último dia da sprint, a primeira metade é fazendo a demo com o cliente e a segunda fazendo a retrospectiva com a equipe. Na verdade, eles têm levado menos de uma metade de dia para isso, graças aos ganhos de produtividade adquiridos até aqui.
O que eles fazem a mais é que rola uma DR com o cliente. Com muito tato e muito respeito mútuo, ao cliente são colocados os pontos negativos sob a responsabilidade dele, o cliente. E isso é feito publicamente, na frente da equipe e até pares do cliente. A intenção não é causar constrangimento, óbvio, mas sim deixar que o peso das consequências de escolhas inadequadas seja experimentado por completo, intensamente, pelo cliente danadinho. O Maycon sempre pega leve, é um cara tolerante e tals, mas eu sei que ele pode ser muito intenso quando algo sai errado ou quando alguém não faz a própria parte. A capacidade de abordar um ponto negativo, uma falha ou irresponsabilidade com seriedade sem criar mágoa e ainda causar impacto é algo da personalidade dele.
Porém, quando o cliente cria valor para a equipe, sendo parceiro e ajudando, trazendo soluções junto com os problemas, participando e não se furtando a tratar o que é difícil, ele ganha um reconhecimento público, perante à equipe e a seus pares e até para a empresa. Assim o processo e as pessoas envolvidas premiam quando as coisas saem bem ou melhor que o esperado.
Se eles tratam com muita seriedade e austeridade a colaboração do cliente, imagine como eles se cobram. A review, que é feita só entre a equipe, tem muito mais seriedade e muito mais auto-crítica. Entre eles há o compromisso de não deixar nada sem falar, o que leva a certos momentos mais tensos, mais pesados. Mas, de novo, esse é o teste de uma equipe vs. um bando de gente. O time conversa, argumenta, disputa, mas no final o objetivo é único e todos se entendem.
Uma coisa importante de notar, que está em linha com as práticas inauguradas pela Toyota, é nunca sair de uma sprint sem ter nada para melhorar. Com o tempo, claro, o volume de melhorias necessárias acabou diminuindo, o que os levou a se comprometeram em sempre gerar alguma mudança. No mínimo, quando nada mais precisa ser retocado, eles procuram algum incremento para o processo de requisitos – algo sempre tem que melhorar.
Quando eu pedi para o Maycon revisar o post antes de publicá-lo, ele adicionou isso:
“Acho isso muito importante, o próprio processo e ritos passaram por iterações ao longo do tempo. Vamos calibrando o tempo alocado para cada rito, frequência ou se devemos introduzir um novo processo. Por meio das métricas de desempenho das sprints (pontos entregues, bugs encontrados, problemas nos requisitos, etc.) conseguimos dizer se as mudanças estão sendo benéficas ou não. É possível que daqui uns anos o processo que a gente siga já tenha mudado para que ele se adapte à realidade enfrentada no momento.”
Simples & Interligado
Estou concluindo o post e para mim está muito firme a sensação de que mesmo que eu empregue as mesmas práticas, eu não vou obter o mesmo resultado. Batemos papo por quase duas horas, e algo constante na fala do Maycon era “comunicação”. “A gente sempre se fala bastante”, “a gente sempre conversa com o cliente o tempo todo”, “a gente nunca deixa de contar algo importante” etc. etc. etc.
as práticas dele podem até causar um impacto (a idéia do modelo é ótima!), mas eu percebi que, sem essa capacidade de manter a equipe em um estado de troca de informações constante, o resultado talvez não fosse tão bom.
Comunicação é a chave. E isso quer dizer que saber comunicar é uma habilidade crucial. Talvez seja A habilidade.
Know-How
Falamos de várias outras coisas. Por exemplo, débito técnico. Como todo mundo, eles tiveram momentos de explosão de débito técnico, que ainda está sendo tratado. Ora eram compromissos assumidos em função de tempo e restrições do projeto, ora era falta de conhecimento (na ferramenta, no assunto, em qualquer coisa.) Não há segredo para ele, aqui. É preciso estar atento para evitar criar mais débito sem querer, e estar ciente das consequências quando um débito será incorrido propositalmente. “É a vida”, disse ele. ;-)
E Continuous Delivery/Continuous Integration? Não usam, e o deploy é todo manual. Porquê? Bom, ele explicou, por que o que precisa ir à produção geralmente é bem pouca coisa. O arquivo de um novo relatório, um ajuste no ETL, um painel publicado e só. Não há tanta coisa sendo levada com tanta frequência à produção, nem é um processo tão complexo, que precise de automação. E ele completou: “mas se um dia o processo de deploy se tornar mais complexo ou comece a tomar um tempo considerável, isso vai ser considerado como uma opção de melhoria no momento da review.”
E como fica o processo de modelagem dos dados? É a complexidade de sempre: usam modelos estrela regularmente, ou outras soluções quando é necessário. Uma coisa interessante é que eles investem cerca de 10% do tempo da sprint em documentação. Eles ponderam com cuidado a relação custo-benefício para que seja documentado apenas o que será útil. A maior parte das vezes eles registram:
Dúvidas frequentes;
Padrões de design;
Desenho de soluções
Descrições de cubos e relatórios; e
Resultados de análises de dados mais complexas.
Isso, segundo o Maycon, salva muito esforço e tempo na hora de atender o cliente.
Ainda sobre o modelo, eles procuram evitar criar uma nova estrela/tabela para qualquer nova demanda. Eles tentam encaixar no que já existe, e apenas se não houver como é que se criam novos recursos de dados. Uma coisa interessante: cada modelo tem prazo de validade. Após um ou dois anos, cada modelo de dados (tabelão ou estrela ou qualquer outra coisa) é obrigatoriamente revisto. A meta é encerrar coisas antigas (desligando a carga, mas não apagando-a) e evitar que dados incorretos comecem a chegar para os usuários sem que ninguém perceba. Essa é uma excelente prática, que eu vou copiar. Aliás, eles não fazem apenas esse acompanhamento. Há uma dedicação de esforço contínuo para que o modelo se mantenha coerente e funcional, esforço no qual aplicam parcela considerável de tempo.
Conclusão
Resumindo, Maycon Queiros, da Bemobi, ajudou a construir um processo ágil de desenvolvimento de soluções de BI, composto por:
Scrum;
Dupla daily (ou duas halfies?);
Priorização/repriorização a meia-sprint;
Demo com appraisal do cliente;
Review com melhoria obrigatória.
Fora isso, alguns aspectos são relevantes mesmo fora do contexto de agilidade de projeto:
Bastante documentação;
Relação de respeito com o débito técnico;
Governança do Data Warehouse.
Essa é a parte visível. Na parte invisível, ele cuida para que haja muita comunicação, que as partes se conversem bastante e que nenhuma delas crie a sensação de ser dona da verdade, mantendo-se sempre abertos ao diálogo, a escutar o colega. O Maycon resumiu isso muito bem:
“Vale mencionar a importância de reforçar boas práticas e padrões de design e desenvolvimento, além de construir soluções de forma que sejam de fácil manutenção e extensão. Isso, claro, vem muito com a experiência. O conhecimento adquirido deve ser propagado para os membros júnior e pleno da equipe de forma que haja um estilo de desenvolvimento seguido por todos.”
Essa parte é cultural e, na minha percepção, é fruto da personalidade e do profissionalismo acima da média que o Maycon tem. O que torna fácil entender por que ele pediu para eu deixar no post a seguinte observação:
“Uma coisa, aproveitando, caso você faça referência a mim em um artigo sobre esse assunto, gostaria que mencionasse também Ciro Xavier e Eric Mozetic, eles trabalham comigo na Bemobi. Muito do que te falei foi fruto de discussões entre nós.”
Esse é o primeiro método de gestão ágil de BI que eu vejo funcionando (o meu não conta.) Adoraria saber o que você acha dele. Viu algo parecido, em algum lugar? Faria algo igual? Faria diferente? Comente!
Eu já escrevi um pouco sobre como projetos de BI “acontecem”. Em Cruel Sucesso eu divaguei sobre a eterna sensação de fracasso que algubs projetos de BI experimentam, mesmo que ele esteja indo de vento em popa. No Todos os Caminhos Levam a um DW eu me diverti escrevendo uma história maluca sobre um projeto de BI fictício, que nasce como uma planilha Excel e cresce como mandiopã, até explodir e voltar ao começo. Mudando o foco para requisitos, eu discorri sobre Ágil e BI (De Agilidade e BI), para descaradamente anunciar meu curso de requisitos de BI para gestão ágil.
Quase sempre esses posts vem do nada, motivados por alguma situação pela qual passei. Eu estava com o novo fascículo da série Soluções Clássica quase pronto (Credit Scoring), mas aconteceu de novo: me meti num debate sobre o que era um “bom” projeto de BI.
Bom, eu tenho uma idéia do que deve ser um. Vou dividir com vocês a opinião que eu coloquei no debate, mas já sabem, né?
Disclaimer: o que você vai ler é a minha opinião, logo você não é obrigado a gostar dela ou concordar. Terei prazer em ouvir críticas ou outras opiniões, mas no final – como diz o Homer Simpson – a opinião é minha e faço com ela o que quiser, certo?
Sucesso Não Existe
Primeiro, não existe mundo perfeito. Não adianta sonharmos com a próxima grande ferramenta para resolver nossos problemas, porque o melhor que pode acontecer é resolvermos os problemas atuais e caírmos em novos. O que faz a diferença, na minha humilde opinião, é evitarmos empacar. Se empacamos, o projeto começa a fazer água, e quanto mais tempo demoramos para resolver o problema da vez, menos relevante o projeto de BI se torna, até que um dia todo mundo está se virando sozinho e o projeto é mantido vivo apenas com auxílio de aparelhos.
O que torna um projeto bom, de sucesso, então, é o fato de ele estar sempre em movimento, resolvendo cada problema como um corredor salta obstáculos: pula, corre, pula, corre, pula, corre… Eventualmente, um dia a coisa toda entra em velocidade de cruzeiro, a quantidade de erros cai substancialmente e a empresa desenvolve uma cultura de BI. Esse é o projeto de sucesso: falível, sempre precisando de alguma melhoria, mas que entrega resultados e é acreditado pela organização, sustentado pela cultura de conhecimento da empresa.
Um projeto de BI de sucesso, IMHO, é aquele que resolve um problema atrás do outro, sempre entregando um pouco mais de resultados a cada etapa, capaz de suplanta as próprias limitações e ir ao encontro das expectativas do cliente.
O Caminho para o Sucesso
Ora, dirão vocês, bolas. A definição acima é uma rematada platitude: não diz nada de realmente útil ou prático. Concordo. Vamos escrevê-la ao contrário para ver se fica mais claro:
Fracassa o projeto de BI que persistir em trilhar caminhos sem saída.
Consegui me fazer entender? Quando optamos por este ou aquele caminho, corremos o risco de enveredar por uma rua sem saída. Projetos – de qualquer tipo – que reiteradamente optam por entrar em becos sem saída acabam morrendo porque, cedo ou tarde, a organização se cansa de tanto vai-e-vem! Quer seguir no caminho para o sucesso? Esforce-se por evitar decisões ruins!
Decisões, Decisões, Decisões
Devo ter engolido o grilo falante quando era criança, pois eu sempre escuto uma voz fininha, tirando onda com a minha cara. Desta vez ela disse “Intelijumento! Se soubéssemos que decisão vai dar errado, não a tomaríamos! Dã!”
Óbvio, claro, não se questiona isso. É a própria essência do processo decisório, é a meta personificada de se fazer uma escolha: fazer a escolha certa!
Como saber se uma opção, e não a outra, é a correta? Ah, de muitas formas. Em alguns casos estamos passando pelo mesmo problema uma segunda vez. Se da primeira fizemos a escolha certa, tendemos a repeti-la, e vice-versa: deu errado antes? Vamos tentar outra coisa. Em outros casos não conhecemos, ainda, as consequências de cada caminho, mas podemos avaliá-las com o que estivar à mão – opiniões, análises estatísticas, jogar cara-ou-coroa – e escolher a que parece melhor.
Em último caso, recorra a um taxista: eles sempre sabem o que os outros deviam fazer. ;-)
O Que Funciona?
E aqui chegamos no ponto em que eu queria: o que funciona em um projeto de BI? Como montar um projeto que vai empacar menos?
Armazéns de Dados
Um bom DW é fundamental para qualquer projeto de BI de sucesso. Você pode se virar com dumps, ODFs, Data Lakes, mas esses caminhos são becos sem saída: cedo ou tarde o peso da falta de integração dos dados (dumps e Data Lakes) e das manutenções de modelo e ETL (ODFs e EDW Dimensional) vão afundar seu projeto – mesmo que todo o restante funcione.
Logo, lição número um: monte um bom projeto de DW, capaz de incorporar novas fontes num estalar de dedos e de produzir novas apresentações de dados em dois palitos. Quem acompanha meu blog já sabe o que isso significa: Data Vault.
Equipes
Ferramentas são importantes, mas não são nem metade da solução. Problemas são resolvidos por pessoas com conhecimento e competência para aplicar ferramentas, não pelas ferramentas. E outra: muito ajuda quem pouco atrapalha – gerente bom é gerente quietinho, que serve a equipe, ajudando a remover obstáculos.
Processos
Há dois grupos de processos dentro de um projeto de BI, especificamente:
Processos de Desenvolvimento;
Processos de Atendimento.
O primeiro é batata: é o processo pelo qual a equipe (parte dela, na verdade) mencionada acima produz os resultados requisitados pelo cliente.
O segundo processo é virtualmente ignorado pela comunidade de praticantes de BI: é o processo pelo qual a outra parte da equipe apóia o cliente. Sim! É o time de “vendedores”, instrutores e tutores, que trabalham com o cliente para entender o que ele precisa e transformar isso em requisitos, que serão tratados pelos desenvolvedores; que ajudam cada novo usuário a aprender a usar as ferramentas e os dados do projeto. O tutor é uma figura inexistente na literatura, mas pode ser visto como um instrutor particular, que vai resolver o problema do usuário uma primeira vez, e ajudar o usuário a repetir esses passos. Ele é diferente do instrutor, que ensina a usar o que está pronto. O tutor cria coisas novas – novas práticas, novos usos dos dados, novos requisitos.
Processo de Desenvolvimento
Não tem segredo: waterfall [bigbang][bigbang_bitly] não funciona, ponto final. A única forma de gestão de projetos que dá certo é Ágil, e neste ponto Scrum é o meu preferido.
Processo de Atendimento
De novo, não tem segredo: um grupo de vendedores (ou evangelistas/analistas de requisitos) e apoiadores (instrutores e tutores) expostos exaustivamente, com uma mensagem clara: Precisa de dados? Me ligue!. Eles interagem com o processo de desenvolvimento alimentando novas histórias no backlog (para os vendedores), com o cliente por meio de chamadas de suporte (tutores/suporte técnico) e com a empresa por meio da capacitação corporativa.
Soluções
Todo projeto de BI usa quatro tipos de soluções:
Apresentações;
Relatórios;
OLAP;
Data Mining.
As três primeiras são baseadas em ferramentas, e portanto são resolvidas pela incorporação de profissionais das respectivas ferramentas ao time. Já a última é tratada como uma conjunto de projetos-filhos e raramente é tratada in house. O normal, para soluções que envolvem Data Mining, é contratar uma empresa especializada no assunto desejado.
E os painéis? Painel não é solução de BI, é ferramenta de (tcham-tcham-tcham-tcham-tcham!) apresentação de dados (e não, não é ferramenta de análise! Quem analisa é OLAP e Data Mining.) Logo, você pode ler o primeiro item da lista acima como “dashboards“. Porém, há muitas formas de se apresentar dados e eu evitaria fechar esse escopo prematuramente, jogando tudo na vala comum “painel”.
Um bom projeto de BI precisa incorporar essas categorias, sem exceções. Não precisa oferecer tudo ao mesmo tempo, desde o dia 1, mas deve garantir que o roadmap vai contemplá-las ao longo do caminho. Como conseguir isso? Tente incluir no seu time um generalista de BI, aquele cara que entende um pouco de tudo, e sabe como os assuntos se interconectam, como amadurecem ao longo do ciclo de vida do projeto.
Se você não puder contar com um membro permanente, aceite um membro flutuante, como um coacher, por exemplo. Se não existir na empresa, procure um consultor externo. Raramente um profissional desse cresce durante um projeto de BI, e você só vai achar um na sua empresa, à sua disposição, por pura sorte.
Conclusão
Então vamos lá: um bom projeto de BI é composto por um time multi-disciplinar (especialistas em ferramentas de ETL, apresentação e exploração de dados), com uma equipe voltada para o atendimento do cliente (esqueça a idéia de ter “self-service 100%”) e outra voltada para uma linha de produção de soluções. Na entrada dessa linha está um DW baseado em Data Vault, no meio as áreas de dados para consumo e na ponta as ferramentas de uso dos dados (apresentação, relatórios e OLAP.) Pipocando aqui e ali aparecem os sub-projetos de Data Mining, tocados normalmente por consultorias externas e nascendo de necessidades pontuais. Essa visão geral pode ser melhor organizada por um generalista.
Nenhuma destas idéias é minha, e isso em parte me dá confiança nelas: Bill Inmon chama esse modelo de CIF, o inglês para Fábrica de Informações Corporativas.
Diagrama da Fábrica Corporativa de Informações.
Outro nome para essa abordagem é BICC – Business Intelligence Competence Center. Veja este artigo para uma discussão mais detalhada do conceito.
Não é um BICC, mas dá uma idéia de como funciona a tal “linha de produção”.
O restante da minha confiança nesse modelo nasce de eu ter experimentado tudo isso: Data Vault, Scrum, Data Mining, OLAP, Relatórios, equipes proficientes etc. etc. etc. Eu vi projetos de BI fracassarem ao descuidar desses fundamentos, como também vi projetos de BI que estão vivos até hoje, alguns zumbis, outros mancando, mas em operação. Se os que dão certo trazem pistas do que pode ser o mais importante, ou o que dá resultados, os que se arrastam, semi-mortos, são os mais valiosos para entender como e porque as coisas dão errado.
Um dos leitores do blog deixou este comentário em 18/5/16:
Fábio, gostaria de mais instruções sobre o data vault, como aplicar, onde aplicar e como é sua modelagem e arquitetura.
Prometi a ele que o próximo post responderia essa questão. Então aqui está: Data Vault, uma visão geral sobre onde aplicar, como modelar e em que arquitetura colocá-lo.
Do Começo, Por Favor
Data Vault é uma metodologia de desenvolvimento de Armazém de Dados Corporativo (do Inglês EDW), que inclui modelagem e processo de ETL. A versão 1.0 parava aí, já a 2.0 vai adiante, até a camada de apresentação dos dados.
Aplicando Data Vault podemos desenvolver um Armazém de Dados com baixo custo, alta produtividade, baixo retrabalho, com processo de ETL de alta performance e altíssimo MTBF.
Volte Mais!
E porque precisamos de um Armazém de Dados mesmo? Bom, não é o assunto deste post, mas aqui vai, resumidamente:
No fundo, não “precisamos” de DW. Precisamos é armazenar a evolução dos parâmetros da empresa ao longo do tempo. Podemos fazer isso de várias formas: um estagiário anotando valores em um papel de pão, ou uma planilha Excel, ou dumps de bases em um cluster Hadoop. Ocorre que, por acaso, DW é a tecnologia adequada para isso.
Puxa dados dos vários sistemas da empresa para um repositório central;
Integra os dados dos diversos sistemas em uma visão abrangente.
Um EDW precisa puxar os dados de todos os sistemas porque qualquer se não olharmos em todos os dados da empresa nunca teremos a certeza de termos investigado tudo que há para ser examinado. É como perguntar que livro sumiu da biblioteca: só olhando todos vamos saber qual não está lá. Se o gerente financeiro pergunta “quais são todos os gastos da empresa”, precisamos olhar tudo!
Pense: se sua empresa tiver dois sistemas em MySQL, um em SQL Server, um em Postgres e outro em Oracle, como escrever um SQL que percorra todas essas bases? Não dá, não é? Os dados precisam estar em um repositório centralizado por simples limitação das atuais tecnologias de banco de dados: como em geral usamos SQL para fazer essas pesquisas, e um SELECT não consegue consultar – ao menos não de maneira fácil – dois ou três ou mais bancos de tecnologias diferentes ao mesmo tempo.
Os dados precisam estar integrados, o que significa bater os CPFs 012345678-00 com 1234567800. Quando puxamos um relatório do cliente 012.345.678-00 precisamos que ele seja identificado em todos os sistemas, não importando se na origem ele aparece como 1234567800, 012345678-00, 012.345.678-00 ou de qualquer outra forma. Dados não-integrados fornecem respostas erradas. Sem integrar os dados, seu DW não vale o HD no qual está gravado.
Há várias técnicas para construir um DW atendendo essas duas obrigações:
Copiar tudo da origem, mantendo os mesmos modelos, e integrar na hora de fazer a consulta. Frágil, trabalhoso e pesado (consome muita máquina;)
Copiar tudo da origem, gravando em um novo modelo na Terceira Forma Normal. Mais robusto e de melhor performance que o anterior, mas de evolução e manutenção tão difícil que beira o insano;
Copiar a origem em um novo modelo, como no item anterior, mas em um Modelo Dimensional. Não tão robusto, mas de boa performance, com evolução e manutenção práticas e simples no começo, mas tendendo à impossibilidade de manutenção e evolução com o tempo.
E finalmente, o Data Vault, que não sofre de nenhum destes problemas e tem todas as vantagens. Resumindo em figuras:
Os impactos das mudanças na arquitetura tradicional.
Os impactos das mudanças, agora no arquitetura com DV.
Só para ficar claro: por “nenhum impacto aqui”, no último quadro da figura acima, eu quero dizer “nenhum impacto de manutenção”, já que, obviamente, pode ser preciso criar algo novo. Não haverá impacto no que já existe, não será necessário mudar nada.
Adotar Data Vault como metodologia para desenvolvimento de um DW vai evitar os problemas que costuma comprometer os DWs da 3FN e Dimensionais.
Hoje vamos deixar só com essa afirmação, porque este é um post de visão geral, mas você pode seguir os links apresentados até agora para ler o (extenso) argumento explicando porque é assim.
Como Aplicar?
De fato, não há segredo na aplicação de Data Vault. A técnica meio que se resume em:
Quebrar o trabalho em “histórias”: quero medir isso, quero analisar aquilo;
Daí, para cada uma:
Identificar as tabelas na origem que respondem essas perguntas
Expandir o modelo de dados do DV com hubs, links e satélites;
Gerar automaticamente ETL de carga do DV;
Desenhar o ETL para a área de apresentação.
Existem padrões e técnicas para cada atividade, e a metodologia casa-se como uma luva à gestão ágil. Meu método preferido é o Scrum, e chega a ser surpreendente ver como DV adequa-se tão perfeitamente ao Scrum.
Veja meu post De Agilidade e BI para alguns comentários sobre o levantamento de requisitos para projetos ágeis.
Como É a Arquitetura?
Você já deve ter intuido a forma geral da arquitetura em uma das figuras anteriores. Reorganizando e renomeando as partes daquela figura temos uma visão mais clara:
Arquitetura Data Vault.
Ou seja:
Um ETL (gerado automaticamente) traz os dados de cada origem;
Um banco de dados (preferencialmente relacional, mas um Hadoop does too) recebe e, graças ao modelo de dados do DV, integra tudo “na entrada”;
A partir deste banco um segundo processo de ETL popula as soluções;
Essas soluções podem ser de todo tipo: análises multidimensionais (OLAP), Data Mining (CRM etc.), painéis, relatórios etc. etc. etc.
Cada uma destas soluções após o segundo ETL têm suas arquiteturas particulares. No fundo a arquitetura de um DV são dois ETLs com um banco com modelo de dados DV no meio, mais nada. A partir daí, tudo fica igual à qualquer outro projeto de BI.
Modelagem
A modelagem de um Data Vault é relativamente simples, e você pode ler um pouco mais sobre ela neste post. Grosso modo, porém, resume-se ao seguinte:
Identificar chaves de negócio e criar hubs;
Encontrar relacionamentos entre chaves de negócio e criar links;
Escolher os atributos de hubs e links e criar os satélites.
Hubs
Hubs são tabelas que guardam conceitos, ou chaves, de negócios. Uma chave de negócio é um conceito importante para a empresa: cliente, produto, pedido, posição no call center, empregado, etc.
Tabelas hub possuem as seguintes colunas, nem uma a mais nem a menos:
Business Key: chave primária, um inteiro sequencial;
Load Date/Timestamp: data e hora da inserção do registro;
Record Source: fonte da chave de negócios;
Source business key: chave de negócio no sistema de origem.
Uma tabela hub.
Não há grandes segredos aqui: tabelas hubs acumulam as chaves de negócio, que são a espinha dorsal do modelo. A chave primária é a BK. A cada carga insere-se apenas as novas chaves de negócio dos sistemas de origem. Se a chave já existe, nada é feito. Se a mesma chave existe em vários sistemas, apenas a primeira que chegar é inserida.
Links
Links tão tabelas que guardam o relacionamento entre dois hubs. Uma tabela link que relaciona os hubs 1, 2, … , n possuem as seguintes colunas, nem mais, nem menos:
Link Key: chave primária, um inteiro sequencial;
Load Date/Timestamp: data e hora da inserção do registro;
Record Source: fonte do relacionamento;
BK1: business key do hub 1;
BK2: business key do hub 2;
…
BKn: business key do hub n.
Uma tabela link.
Ela também não sofrem atualização: novos relacionamentos são inseridos, antigos são ignorados. Se um relacionamento já registrado não é mais detectado, ele não é apagado.
Satélites
Satélites são como tabelas de dimensão: guardam os contextos de hubs e links. Uma tabelas satélite de um hub/link que guarda os atributos A1, A2, … , An de um hub/link X possui as seguintes colunas, nem mais, nem menos:
Business Key/Link key: chave primária do hub/link
Load Date/Timestamp: data e hora da inserção do registro;
Load End Date/Timestamp: data e hora do fim da validade daquele registro (default é NULO);
Record Source: fonte dos atributos;
A1: atributo 1;
A2: atributo 2;
…
An: atributo n.
Uma tabela satélite.
Modelo Completo
A coleção dessas tabelas e seus relacionamentos dão o modelo completo:
As tabelas combinadas no modelo.
A etapa seguinte é construir o ETL para dentro do DV, e depois do DV para a camada de apresentação/consumo de dados.
ETL
Um DV possui duas vantagens “matadoras”: integração dos dados no modelo, ao invés de no ETL como é o mais comum, e um ETL padronizado. Graças à essa padronização o ETL de um DV inteiro pode ser gerado automaticamente: a partir de alguns gabaritos de SQL podemos construir o processo que lê e grava todos os hubs, links e satélites.
Eu sempre uso o Pentaho Data Integration (PDI) para processos de ETL, e meu curso de DV entrega ao aluno um gabarito de projeto completo – é só tirar da caixa e usar. A última versão dele traz até os SQLs para criar as tabelas no Data Vault.
Isso para o primeiro ETL, para dentro do DV. O segundo ETL, saindo do DV para a camada de apresentação, é mais particular, e não há como automatizar sua geração. Por outro lado, como todos os pontos de partida não são mais os sistemas de origem mas sim o DV, a “forma” geral desse segundo processo é mais uniforme, e alguns padrões acabam por facilitar seu desenvolvimento.
Por exemplo, dimensões são quase sempre construídas a partir de um hub e seus satélites, e tabelas fatos originam-se de links. Construídos os SQLs que lêem isso no DV (e nisso eles seguem um padrão de JOINs bem cadenciado), o passo seguinte é fazer trocas de chaves naturais por delegadas e, em caso de necessidade, limpar os dados.
Conclusão
Adoro quando um leitor pede algo, pois escolher o tema do próximo post, para mim, é como escolher roupa para sair: muito, muito difícil – e se não gostarem? e se ficar ruim? e se eu falar besteira por saber pouco? E se?…
Vimos que um Data Vault é uma metodologia que habilita a realização da visão de Bill Inmon, a Corporate Information Factory. A [CIF][cif_bitly] (até o advento do DV, outro mito) é como uma linha de produção, que ingere todos os dados da empresa e “fabrica” produtos de dados conforme as necessidades vão surgindo.
Data Vault é uma metodologia composta por uma modelagem, um processo de geração automática de ETL e outros elementos (como padrões e nomenclaturas.) O EDW se completa com um segundo processo de extração, que leva os dados para as áreas de apresentação, em formato dimensional ou não. Tudo em um processo de desenvolvimento que nasceu para ser tocado com gestão ágil (Scrum, na minha preferência), boa parte automatizada e com baixo ou nenhum retrabalho.
Não deixe de ver o post As Vantagens do Data Vault para mais sobre como um DV pode ajudar seu projeto de EDW.
É claro que nada é 100% a prova de falhas, defeitos ou problemas e eu mesmo já enfrentei minha cota de surpresas, dificuldades e maluquices nesse caminho que venho trilhando há alguns anos. Mesmo assim, hoje em dia, um Data Vault é a coisa que mais se aproxima de um método perfeito.
Fora essa babação no final, acredito que era isso. ;-)
Semana passada, 6/5/16, eu assisti uma palestra sobre uma empresa chamada Attunity, e suas ferramentas para Business Intelligence. Vendo as promessas do representante brasileiro eu me dei conta de que já escrevi bastante sobre DV, mas nunca escrevi especificamente sobre as vantagens trazidas pela adotação de Data Vault. Vamos corrigir isso hoje, partindo desta apresentação.
Você pode pular direto para a lista de vantagens clicando aqui.
Uma Nova Categoria
Estamos em 2016 e já lá se vão cerca de 40-50 anos desde que Bill Inmon começou o debate sobre Armazéns de Dados, e 24 anos desde seu livro Building the Data Warehouse. Muita água passou embaixo da ponte e todas suas idéias estão sedimentadas, firmes, sobre as quais se assenta a moderna indústria de DW. Um destes conceitos é a Corporate Information Factory, que agrupa as fontes de dados e seus consumidores como uma linha de produção.
Diagrama da Fábrica Corporativa de Informações.
Tal qual a revolução industrial fez com a manufatura, graus de automação sucessivamente maiores estão acelerando e simplificando o desenvolvimento, manutenção e gerenciamento de Data Warehouses. Instrumental para essa revolução foram tecnologias aparentemente irrelevantes, como modelos de dados e metodologias de desenvolvimento.
Metodologias como Scrum, Continuous Integrations e DevOps agem para diminuir a intervenção e variabilidade da ação humana, enquanto que outras, como Modelagem Dimensional e Data Vault, domam a confusão dos sistemas OLTP e permitem a criação de algoritmos. E é justamente essa criação de algoritmos que permite automatizar o processo de desenho, desenvolvimento e manutenção de DWs.
Uma nova categoria de ferramentas brotou desse fértil ambiente: ferramentas de automação de gestão de DW. Ainda não vi esse ramo ser tratado por um acrônimo, nem mesmo ter um nome mais comum, mas acho que, em Inglês, seria algo Data Warehouse Management Solutions, ou DWMS. Já sabem: se virem por aí, apareceu no GeekBI primeiro. ;-)
Continuando, essa categoria já tem alguns nomes internacionais:
Fazia tempo que eu não visitava o BI Ready, empresa de Ian Nicholson com quem já troquei umas idéias no LinkedIn. Surpresa! Ela foi adquirida pela Attunity e agora são um nome só. Não é à toa que, na apresentação, a Attunity declarou pertencer a essa turma – ela comprou “metade” das empresas dessa área!
Esse é o Ian Nicholson, fundador da BI Ready, fazendo a mesma cara que eu faria se tirasse essa foto.
Processos e Problemas
Um projeto de DW que hoje é chamado de “tradicional” (i.e., feito com metodologias de mais de 15 anos atrás) envolvia as seguintes etapas:
Levantar os requisitos;
Estudar os dados de origem;
Desenhar o modelo dimensional;
Desenhar o processo de ETL;
Colocar em produção;
Dar manutenção: propagar as mudanças dos sistemas de origem e adequar às novas necessidades do cliente.
Esse projeto em geral era tocado dentro de uma moldura PMI (a.k.a. Waterfall). Era um método tão certeiro e determinístico que até hoje todo mundo sabe que, feito assim, sempre falha.
Os problemas de um DW ‘clássico’.
DW feito por cópia dos bancos de origem é a pior escolha possível, a menos que seja para uma padaria, uma farmácia, uma banca de jornais etc. ;-) Veja que não estou falando de palco (stage), mas de montar o DW como uma coleção de réplicas. Um modelo dimensional é o mínimo necessário para sobreviver aos problemas que serão apresentados ao final desta seção.
Levantar os requisitos da próxima entrega (30 dias;)
Estudar os dados de origem até encontrar o estritamente necessário para próxima entrega;
Desenhar o DV;
Gerar automaticamente o processo de ETL;
Derivar dados para apresentação;
Colocar em produção e reiniciar o ciclo.
A manutenção é incorporada nas sprints.
Veja que, grosso modo, o processo em si não mudou muito: de projeto waterfall passamos para Scrum, de modelo Dimensional no miolo do DW passamos para um Data Vault e o ETL principal é gerado automaticamente.
Os problemas que existem (existiam e vão continuar existindo) são:
Integração: sem integrar e limpar 100% dos dados, todas as respostas são suspeitas. Ou você confiaria nos números sabendo que algo pode ter ficado de fora?
Historiamento: não adianta montar um armazém que não guarda histórico. Fazer isso é cuidar de dados operacionais e jogar a água fora com o bebê – o maior valor dos dados está no histórico;
Mudanças na origem: sistemas transacionais representam os processos que a empresa executa. Se a empresa muda, forçosamente os OLTPs precisam mudar, e o DW vai ter que ser adequado, sempre;
Performance de ETL: a menos que a empresa esteja definhando, ela sempre vai crescer, sempre vai querer mais dados. O hardware para ETL sempre acaba ficando obsoleto, por um motivo ou outro, cedo ou tarde. O truque é extrair tudo que ele pode dar, e não desperdiçar nada;
Velocidade de mudança: por fim, em cima de todos os problemas apresentados, temos o fato de que as coisas não estão ficando mais calmas, mais lentas, e sim mais rápidas, com mais demandas e mais complexidade.
Ferramentas…
As novas ferramentas de automação de DW se propõem a resolver esses problemas.
O Attunity propõe resolver um DW em dois passos:
Usando o Attunity Replicate os dados são trazidos de diversas fontes de dados para um repositório centralizado;
Daí, com o Attunity Compose, um DW é desenhado e carregado automaticamente.
Há um bom grau de magia negra envolvida (=coisas que acontecem sem entendermos claramente como), mas tudo faz um bom sentido. O Replicate se conecta aos bancos de dados de origem e fazem uma engenharia reversa total. Com essas informações ele vai ao banco de destino e recria o banco de origem, respeitando as diferenças de tecnologias. Por exemplo, ele pode replicar bancos MS SQL Server e Oracle para dentro de um único Postgres. Depois ele faz uma transferência inicial, em que replica as origem(ns) inteira(s) no(s) destino(s). A partir do final desta carga, o Attunity Replicate passa a ler o log de commits dos bancos de origem e replicar no destino, em tempo real.
Quem leu meu post Analítico ou Operacional? sabe que essa replicação não é um DW, e que fazer isso “não é BI”.
A Attunity também sabe, e dá o passo final em direção ao DW através do Compose. O que essa ferramenta faz é mais magia negra que a outra:
Através de engenharia reversa e algoritmos especiais, o Compose “descobre” os relacionamentos entre as várias colunas de todas as tabelas das origens;
Usando esse conhecimento, a ferramenta monta um DW – desenha um modelo de dados – automaticamente;
Em seguida constrói (sempre automaticamente) o ETL para esse DW;
Na última etapa ele monta uma área de apresentação de dados, seguindo indicações de que dados o cliente quer explorar.
A ferramenta ainda permite customizações e correções feitas pelo time de DW, de modo que qualquer interpretação incorreta pode ser ajustada.
Ou seja, ele automatizou 100% do processo moderno de desenvolvimento de DWs!!!! E digo mais: !!!!. Mas não pára por aí:
Esse DW guarda histórico;
A área de apresentação pode expor estrelas multidimensionais, com até mesmo SCDs tipo 2;
Ele detecta mudanças nas origens e ajusta o DW e o ETL;
Todas essas ferramentas são clusterizáveis, ou seja, podem ser escalonadas horizontalmente.
Isso são coisas que ouvi ou que perguntei durante a apresentação. Há coisas que eu não perguntei, mas presumo que também estejam no pacote, como tratamento de erros de ETL e monitoramentos diversos. Aliás, a parte de monitoramento é muito bacana, também – aprendi um negócio chamado “hot data, cold data”, sobre o qual vou fazer uns experimentos e, eventualmente, vou postar sobre.
… e Soluções
E como o Data Vault se encaixa nesse cenário? Simples: ele oferece tudo que as ferramentas oferecem, sem o custo monetário. Digo monetário explicitamente porque não existe almoço grátis, sempre precisamos pagar por algo. Se não é em dinheiro, vai ser em treinamento e capacitação, por exemplo, ou simplesmente mais trabalho.
DW ‘moderno’, re-organizado segundo DV.
Eis a lista de vantagens (ou problemas resolvidos) trazidos pela adoção de Data Vault no miolo do EDW:
Velocidade de desenvolvimento: usar DV corta o tempo necessário para desenvolver e entregar em algumas ordens de grandeza. Por exemplo, coisas que levariam meses saem em dias;
Modelo de dados: o diagrama de dados do Data Vault é construído através de regras simples, que capturam o negócio no modelo. Assim, uma vez que tenhamos a lista de esquemas, tabelas e colunas do sistema de origem, o ato de desenhar um DV é trivial e leva algumas horas, contra algumas semanas de outros formatos;
Processo de ETL: usando o Pentaho Data Integration, o processo de ETL é gerado automaticamente, a partir do modelo elaborado anteriormente. Ainda é preciso juntar as partes (as diversas transformações) dentro de um job (pré-fabricado), mas isso é uma tarefa de minutos. O ETL inteiro sai em menos de um dia;
Integração: o modelo de dados do Data Vault já arquiva os dados de maneira integrada. Ou seja, a integração ocorre via modelo, no momento em que os dados aterrisam no DV;
Historiamento: 100% dos dados de um DV são historiados, automaticamente e por definição;
Mudanças na origem: evidentemente não são tratadas automaticamente – um software pode fazer isso, não uma metodologia. Entretanto, esse impacto é mínimo:
Qualquer mudança na origem não quebra o processo de ETL, ao contrário de DWs baseados em outros modelos;
Mudanças na origem são resolvidas por um algoritmo simples, e qualquer manutenção leva praticamente o mesmo tempo de repetir o desenvolvimento (horas ao invés de semanas, portanto;)
Nenhuma mudança na origem quebra a área de apresentação. A área de apresentação é reformada apenas em casos que afetem-na. Graças a esse fato, o impacto sobre a área de apresentação causada por mudanças nas origens é de mínimo a inexistente;
Performance de ETL: várias vantagens ao usar um DV;
Alta velocidade: por tratar apenas deltas (i.e., as diferenças) por meio de comparações simples, o processo é muito rápido;
Paralelização: graças ao formato do ETL, todas as operações podem ser maciçamente paralelizadas, possibilitanto uso de hardware barato (COTS;)
Resistente a erros: o ETL de um DV é auto-reinicializável por definição, e só é interrompido por falhas graves (hardware ou dados muito corrompidos;)
Velocidade de mudança: é a mesma da velocidade de desenvolvimento – muito rápida.
Como vantagem extra, pelo fato de DV permitir atacar o problema por pedaços, ele se presta à:
Modularização em sprints;
Paralelização do desenvolvimento.
Por ser baseado em processos automatizados e algoritmos, a quantidade de erros é substancialmente menor, gerando projetos de qualidade maior, e mais padronizado.
Conclusão
Já há alguns anos a indústria de BI vem incorporando tecnologias que habilitam novas soluções de problemas complexos, como a construção, gerenciamento e manutenção de Armazéns de Dados. Essas tecnologias surgem como técnicas/metodologias e softwares.
Um software representante desta nova categoria é o Attunity, especificamente os módulos Replicate e Compose. O primeiro copia dados de diversas origens para um mesmo (ou vários) destino(s). O segundo modela um DW e cria o processo de ETL automaticamente a partir da réplica. Não sei com que qualidade, precisão e velovidade o Attunity entrega os resultados, mas a promessa é fantástica, para dizer o mínimo.
Esse produto é resultado de evoluções anteriores. Uma destas é a metodologia Data Vault, que oferece essa lista de vantagens:
Alta velocidade de desenvolvimento: entrega em dia o que levava meses;
Processo de ETL gerado automaticamente – maior velocidade, qualidade e padronização, com menos erros;
Integração: dados são integrados na entrada;
Historiamento: 100% dos dados de um DV são historiados;
Mudanças: resiliente a mudanças na origem, processo de ETL não pára e impacto global (tanto ETL quanto usuários) é de mínimo a irrisório;
ETL de alta performance, imune à erros, restartável e 100% paralelizável (é possível executar simultaneamente todas as etapas da carga do DV;)
Adequado à processos de desenvolvimento ágil;
Desenvolvimento do modelo (dada ferramenta adequada) e do ETL paralelizável.
Com um Data Vault podemos obter os mesmos resultados prometidos pelo Attunity, com menos automação, e com um custo diferente (menor?)
Clicando aqui você vê a lista dos meus posts marcados com Data Vault. Eis links para alguns do meus posts sobre o assunto:
Só para não deixar vocês pendurados: eu ofereço os dois cursos, Requisitos Ágeis e Data Vault. Fazer essa propaganda dá impressão que eu montei um post para me auto-promover, mas juro que não é o caso deste aqui. Acredito no valor que esses cursos agregam e sentiria que estaria prejudicando você, meu leitor, ao evitar contar que eles existem. Quem me acompanha sabe que quando eu vou vender algo aqui, eu aviso no começo. ;-)
Como capturar e documentar requisitos para projetos de BI gerenciados por métodos ágeis?
Ágil, Não Rápido
Quando Kent Beck, Martin Fowler, Ken Schwaber, Jeff Sutherland e toda patota declararam o Manifesto Ágil, eles não estavam preocupados com a velocidade do desenvolvendo de software, mas sim com a dificuldade cada vez maior em escrever bons produtos. Até início dos anos 2000, o paradigma de desenvolvimento de software era espelhado no paradigma de construção civil: ninguém assentava um tijolo até tudo estar absolutamente calculado e verificado.
É o mesmo que dizer que Romeu e Julieta foi escrito de uma vez, em algumas semanas, depois de Shakespeare passar alguns anos detalhando os personagens e a história. Não que eu seja especialista no processo criativo shakespeareano, longe disso! O que eu quero dizer é que construir paredes e escrever algo são atividades muito diferentes. Meu melhor exemplo são meus posts como exemplo: eu reescrevo cada post – inteirinho – pelo menos uma vez.
Imagine construir e derrubar uma parede até ela ficar perfeita. Imaginou? Bom, vá além: imagine construir e demolir uma casa inteira, até ficar como você quer. Ou pior: construir e vê-la desabar sobre o próprio peso vezes sem conta, até acertar a posição das vigas e conseguir que a centésima vigésima terceira encarnação da casa não caia só porque alguém bateu a porta da frente com força.
É ruim, hein! :-P
O cerne do conceito de desenvolvimento ágil não é a velocidade, mas a melhoria contínua.
Por isso no manifesto eles dizem que vêem valor em “processos, ferramentas, documentos etc.”, mas que vêem ainda mais valor em “indivíduos, colaboração, resultados etc.” Está lá, com todas as letras: trabalhar para obter um bom resultado é o que interessa. E não adianta trabalhar a toque de caixa, fazendo tudo nas coxas, só para chegar rapidamente ao final. O que interessa é avançar, melhorando continuamente e sem comprometer o futuro com decisões apressadas ou serviço mal-feito.
Inteligência de Negócios Ágil?
E como você trabalha melhoria contínua em Inteligência de Negócios? Como casamos BI com Ágil?
Eu venho estudando essa questão, meio que sem querer, já há alguns anos. Como sempre, tudo começou porque eu queria aplicar Scrum de qualquer maneira, custasse o que custasse! Eu havia acabado de ler Agile Project Management with Scrum, do Ken Schwaber, e estava louco para pôr em prática aquelas idéias. Era tudo tão simples, tão elegante, tão poderoso que eu precisava tocar um projeto com Scrum.
Tive uma sorte danada: havia acabado de receber um projeto e ele servia como uma luva em todas aquelas idéias. Aprendi tudo de Scrum, botei em prática, e o projeto funcionou muito bem.
Quer dizer, praticamente. Algums detalhes não deram muito certo:
Automação de Testes: como você testa um ETL ou um relatório, continuamente? Como montar testes de regressão em um modelo dimensional?
Histórias: como eu transformo a necessidade do cliente em uma história, e depois mapeio isso nas atividades típicas de um projeto de BI, como desenhar o modelo dimensional, desenvolver o ETL e construir um relatório ou painel?
Refactoring: sério, refatorar um banco de dados?? Freaking how??
Ainda não encontrei uma resposta satisfatória para os testes. Já refatorar bases de dados, por incrível que pareça, é um problema que já foi resolvido: o livro Refactoring Databases disseca o assunto completamente. Estou lendo esse livro agora mas, pelo pouco que eu já li, posso dizer que ele é essencial para qualquer DBA que seja membro de uma equipe de desenvolvimento de software – ou BI – contemporânea. Leia!
Senta que Lá Vem História…
O que nos deixa no assunto deste post: levantamento de requisitos ágeis para Inteligência de Negócios.
Existem várias técnicas de levantamento de requisitos para projetos ágeis. A mais famosa, provavelmente, é o conceito de História: o cliente e a equipe de desenvolvimento constroem uma narrativa que incorpora a necessidade do cliente na forma de uma ação, de uma história. Por exemplo: “como gerente de vendas, eu quero poder ver as vendas deste mês dia-a-dia, quebradas por vendedor, produto e cliente”.
Essa foi a minha abordagem para aquele projeto. Funcionou, no sentido em que permitiu organizar o trabalho, quebrá-lo em partes e controlar a entrega. Por outro lado criou outros problemas. Exemplo? O tamanho, para começar. Quem já está acostumado com projetos de BI vê imediatamente que o cliente precisa de 1) um cubo OLAP com três dimensões, de vários níveis cada, ligadas a uma fato, tudo isso carregado por 2) um processo de ETL que leva os dados da origem a um 3) modelo dimensiona. Ou seja, uma única história dá origem a um Data Mart inteiro! É muito grande!
Outro problema é o que a própria história conta: há tantas formas de construir a apresentar esses dados que umas poucas linhas de texto é um canal muito “estreito” para enfeixar tantas possibilidades. Como adicionar detalhes? Escrevendo mais? E como fazer o cliente entender o que foi prometido e o que está sendo desenvolvido?
Eu cheguei a escrever sobre um problema relacionado à essa imprecisão: Cruel Sucesso. Para te poupar do esforço de lê-lo, resumidamente, quando você acerta na mosca, o cliente muda a demanda. Depois de algumas iterações acontecendo isso, o cliente desenvolve a sensação contrária, e passa a acreditar que o projeto nunca acerta! E, na minha opinião, isso acontece porque ele só entende claramente o que pediu quando recebe. E é neste momento que ele reavalia sua necessidade a refina. Entendeu? Não? Bom, então leia aquele post antes de continuar, hehe. :-)
Requisitos Para Gestão Ágil
Enquanto eu batia cabeça com isso eu tomei contato com outra técnica fantástica: Data Vault. Se você acompanha meu blog sabe o quanto eu sou apaixonado por DV.
De novo, louco para construir um DV e testar todas aquelas idéias, eu consegui um projeto perfeito. Não apenas pude aplicar Data Vault, mas o fiz com Scrum, o que foi duplamente satisfatório aliás. O resultado desta experiência virou o Primeiro Curso de Data Vault do Brasil. Estou evoluindo aquele material e em 2016 eu espero lançar uma versão definitiva, completa.
E foi deste material que eu puxei uma coisa muito interessante: uma técnica para levantamento de requisitos para projetos de BI. Não apenas qualquer projeto de BI, mas principalmente projetos gerenciados com alguma técnica Ágil, como Scrum ou Kanban.
Funciona assim: ao invés de escrevermos uma história, e depois quebrá-la em modelo de dados, ETL, apresentação etc., começamos anotando cruamente o que o cliente diz que precisa. Essas anotações são transformadas em protótipos que são revisados pelo cliente e ajustadas e revisadas e ajustadas etc. etc. … Em algum momento o cliente vai se dar por satisfeito e o último protótipo vira o requisito! Daí o resto é história: montar um documento que combine protótipo e a demanda do cliente em uma forma que ajuda a equipe de desenvolvimento e comunica claramente a expectativa do cliente.
4Shot Agile BI com Pentaho
Eu contei para vocês que eu comprei um apartamento? ;-) Agora eu tenho uma dívida de quarenta anos, e preciso fazer caixa. Por isso, quando uns meses atrás a 4Linux me apresentou o conceito de Shot e me perguntou se eu tinha alguma proposta, na hora eu apresentei a idéia acima.
Um Shot é um curso de curta duração (tipicamente um dia), focado sobre um único assunto e, em geral, voltado para um público específico. A 4Linux é, com certeza, o maior fornecedor de treinamentos em Software Livre e eu tenho a honra de ter produzido o treinamento Pentaho que eles oferecem (e de vez em quando ministro uma turma.)
Semana que vem, dias 1, 2 e 3 de Setembro de 2015, ocorrerá a primeira turma deste Shot. As vagas são muito limitadas porque as turmas são propositalmente pequenas, de no máximo oito alunos. A idéia é oferecer um curso reforçado, intenso, e uma turma maior não permitiria isso. Também não é um assunto para principiantes. Não é nada esotérico, mas se esse vai ser seu primeiro curso em BI, bom, se prepare. ;-)
Máquina virtual pré-fabricada, pronta para os exercícios.
O curso inclui apostila e dois DVDs, com uma máquina virtual preparada para os exercícios, os exercícios resolvidos, templates, SQLs, backup de bancos e cópias de todos os softwares usados e mais alguns. E apesar de a propaganda dizer que ele é 80% prático, eu acabei fazendo um pouco mais – você não vai ter folga! Mas nem tudo será suor e teclados massacrados: como serão turmas presenciais, teremos o famoso coffee-break da 4Linux. :-)
Os leitores do blog que desejarem se inscrever terão um preço especial: R$199,00 contra R$299,00 do site. Para isso você precisa entrar em contato diretamente com Daniela Araújo (e-mail daniela.araujo@4linux.com.br) e contar que descobriu sobre o Shot no blog Geek BI.
Vou contar uma história usando Scrum, para simplificar. Mas se você conseguir imaginar um projeto Waterfall que dê certo, pode aplicar a mesma história, pois o resultado seria o mesmo.
No começo tudo são flores: o cliente e a equipe constroem o backlog do produto. Neste caso, uma prosaica solução de análise multidimensional, OLAP.
A equipe trabalha duro, sempre em contato com o cliente, e no final da primeira sprint conseguem demonstrar a ferramenta, instalada e funcionando, e uma estrela simples: uma fato com uma métrica de quantidade, e a dimensão Cliente. O usuário consegue, por exemplo, contar a quantidade de clientes por cidade ou estado. “Beleza, mas você vai me dar mais coisas, né?” pergunta o ansioso usuário final. Claro, reassegura-mo-lo, vai ter a sua estrela completa no final da próxima iteração.
Ao final dessa primeira demonstração o PO (Product Owner) e a equipe se reúnem para planejar a segunda sprint. O planejamento praticamente endossa o backlog anterior, com pequenas mudanças pontuais e inconsequentes. A segunda sprint começa, evolui bem e termina em ordem. Nova apresentação é feita para o cliente, agora com a primeira estrela completa. O cliente decide colocar o sistema em produção, mesmo faltando mais duas estrelas, previstas para a próxima iteração.
A apresentação ocorreu de manhã, e a retrospectiva à tarde. No dia seguinte o PO vem para o planejamento da próxima sprint.
É quando a porca torce o rabo.
Pensando Bem…
“… e este”, conclui o Scrum Master, “é o backlog atual.Acredito que vamos manter as mesmas demandas, não? Com isso nós vamos completar a primeira release do OLAP no final deste mês, daqui a duas sprints.”
O cliente olha no fundo dos olhos do SM e diz “Sabe, depois da apresentação ontem, eu voltei e pedi ao Sr. BI que me deixasse testar um pouco mais o sistema.” O Scrum Master olha para o Sr. BI, que olha de volta, inocentemente. “Ele deixou?”, pergunta o SM. Sim, ele havia deixado, e até respondeu algumas perguntas, tanto que ele se atrasou para o começo da retrospectiva. “E você achou algum problema? Quer cancelar a entrada em produção desta estrela?”
– “Não, claro que não. É que, pensando bem… Acho que as próximas estrelas não são bem o que eu preciso.”
Paciente e diligentemente, o Scrum Master e a equipe escutam as novidades, debatem para entender e ajustam o backlog.
Veja: estamos começando a terceira sprint. Da primeira para segunda, tudo certo. No final da segunda o usuário conseguiu usar o produto por umas poucas horas e, antes de começar a terceira ele pediu uma mudança. Tudo dentro do bem-comportado processo do Scrum e, até aí, nada demais.
Sprint 3
E assim a Sprint 3 começou. Como das outras vezes, a equipe buscava o PO para tirar dúvidas e manter o trabalho alinhado com o backlog, mas parece que os selvagens tempos das Cascatas insinuavam-se pelas frestas: o cliente tentou mudar o backlog quase todas as vezes!!
Não era intencional, claro, afinal o cliente sabe que sabotar a equipe de desenvolvimento causa só uma vítima – ele mesmo. Não, muito ao contrário. Ele queria evitar que a equipe entregasse algo pouco valioso. Por isso o cliente sempre estava preocupado em mostrar como, a partir da Estrela 1, que ele estava usando desde sua entrega no final da Sprint 2, ele havia descoberto que a Estrela 2 (e a 3 também) trariam uma dimensão incorreta. O grão dessas duas novas estrelas servia, para a análise que ele achava que precisava fazer, mas não serviriam para a análise que ele descobriu que precisa fazer.
Esse é um problema grave: havia um desalinhamento fundamental entre o backlog prometido no início da Sprint 3 e a realidade do cliente. Quando o cliente começou a usar a Estrela 1, ele começou a “entender” os dados, o negócio e percebeu que havia feito pressuposições, e que essas agora mostravam-se incorretas.
Cuidado Com o Que Deseja…
… por que você pode conseguir.
A maior marca de um projeto de BI de sucesso é o seu aparente fracasso.
Por quê? Porque um projeto de sucesso gera novas perguntas, que geram novas demandas de dados, que faz parecer que o projeto está sempre no início! Mas não! Ele deu tão certo que o cliente avançou e aprendeu – gerou Inteligência do Negócio a partir dos dados.
É nesse caminho que ia nossa história: assim que o cliente começou a usar os dados de uma entrega de sucesso, a compreensão do problema mudou. É uma consequência natural de se aprender mais: novos conhecimentos desafiam nossas antigas visões e percepções. Ainda que isso aconteça em projetos de outros tipos de sistemas, em soluções de Inteligência de Negócios essa dinâmica gera consequências complicadas.
Por exemplo, aonde vai nossa história? Como ela termina? Assim.
O Scrum Master sacou o problema e decidiu convocar um fim abrupto para a Sprint 3. O cliente sentou novamente com a equipe e refizeram o backlog. A Sprint 4 começou e seguiu sem problemas. A demonstração ao final conseguiu recuperar o moral da equipe – estavam de novo na crista da onda, entregando valor para o cliente! Yeah! Touchdown!
Começaram a Sprint 4, que agora ia incluir novas dimensões e estrelas para aumentar a comunidade de usuários. O PO agora eram duas pessoas: o primeiro cliente e um novo usuário do outro departamento. Montaram um backlog para as próximas três sprints e planejaram a Sprint 5. Enquanto isso o novo cliente passou a usar as estrelas que já haviam sido entregues.
E adivinhe o que aconteceu? Isso mesmo: ele percebeu que havia entendido algumas coisas incorretamente. De novo a equipe não conseguia andar na sprint porque o novo cliente não colaborava. Mas desta vez a recusa era hostil!
“Vocês atenderam o outro direitinho! Porque não querem fazer o que eu preciso? Isso que nós combinamos não estava certo! Agora eu percebo isso, e não adianta continuar, eu não vou usar o que vocês estão fazendo!”
Conclusão
Preciso continuar a história? A Sprint 5 foi abortada – de novo – e a sprint 6 e 7 replanejadas. A Sprint 6 saiu redondinha, mas o sucesso deixou uma sensação de desconforto ao invés de alívio. A Sprint 7 foi abortada, virou 8, que deu certo etc. etc. etc.
Estou montando esse cenário na melhor das situações, com equipe funcional e capaz, Scrum Master habilidoso, clientes inteligentes etc. Imagine uma empresa que desenvolva em Waterfall, com feudos departamentais disputando acesso e posse dos dados, usuários mal-preparados ou obtusos…
E esse é um problema ainda mais insidioso porque eu nunca vi ninguém percebê-lo. Por um tempo achei que eu estava viajando! A história acima tem um ritmo acelerado, e talvez a velocidade normal de um projeto seja um impecilho para identificar essa situação. Projetos de BI têm a bagunça da redefinição de requisitos como normal, como consequência da indecisão do cliente. Ainda que haja um nível de indecisão, não acredito que seja esse o responsável por fazer o projeto parecer retroceder periodicamente.
Se você não se identificou com a história, pense um pouco e tente se lembrar: algum de seus clientes parece estar sempre aguardando a próxima versão? Tem algum cliente que sempre volta pedindo alguma mudança? Um novo relatório, uma mudança na dimensão, outra agregação para a mesma métrica? Será que ele não está mudando os requisitos por que está aprendendo?
Da próxima vez que alguém reclamar que o projeto de BI está patinando, erga as orelhas: o projeto pode estar sendo vítima do próprio sucesso!
Até a próxima!
P.S.: eu não sei como lidar com isso. Eu ainda não consegui pegar um caso destes acontecendo claramente, e mesmo que tivesse pego, não sei se saberia o que fazer. Intuitivamente eu diria que precisamos deixar o cliente com o sistema a sós por algum tempo – uma semana? um mês? – antes de planeja a próxima etapa de desenvolvimento, mas duvido que algum cliente toparia isso…
Quem tem filhos pequenos (e usa-os como desculpa para assistir desenhos animados) conhece essa: o Phineas anuncia ao Ferb que “já sabe o que vamos fazer hoje”, olha para os lados e diz “ué, cadê o Perry?” O telespectador já sabe: segundos antes o Perry se esgueirou e sumiu por alguma passagem secreta, em direção à sua próxima missão contra o mais recente -inator do Dr. Doofenshmirtz – só o Phineas e cia. bela é que ainda não tinham notado.
O mundo está cheio destes momentos: “ué, cadê os números romanos?”, “ué, cadê a máquina de escrever?” e assim por diante. (Sério, os números romanos demoraram centenas de anos para sumir de vez.)
O que caracteriza esse momento ué-cadê-o-perry, na minha opinião, é o instante em que ele sai, mas ninguém no desenho notou ainda. É quando uma novidade que vai mudar a cara do mundo apareceu, mas ninguém ainda se deu conta dela, ou de que ela já mudou o mundo.
Tantas Opções, Tão Poucos Projetos…
Então, já repararam na quantidade de novos bancos de dados que apareceram recentemente? Hadoop é o mais vistoso, mas temos coisas como VoltDB, Vertica, MongoDB, InfiniDB, Infobright etc. etc. etc. E note bem: nenhum deles veio para ser um Hadoop-me-too ou um novo Postgres. Cada um deles oferece recursos específicos para tarefas específicas.
Com esse monte de opções, e com um entendimento mais claro de como um Data Warehouse Corporativo (ou EDW) pode ser arquitetado, vemos que não precisamos mais de um Banco de Dados Relacional para montar um DW. Com isso sabemos que um Sistema Gerenciador de Bancos de Dados Relacional pode se dedicar a tarefa que faz melhor (executar transações) e deixar soluções de BI usar outros softwares.
Arquitetura Típica de EDW
Um EDW deve acumular dados por um tempo a fio, sem final em vista. Até hoje, em quase quinze anos nesta indústria fundamental, eu nunca vi um modelo de dados mais adequado a um EDW que Data Vault. Acredito que a melhor técnica para um EDW é um modelo de dados DV montado sobre um Hadoop. Graças tanto à flexibilidade e resiliência do DV, quanto a escalabilidade do Hadoop, um arranjo desses pode se sustentar durante anos a fio sem problemas.
Mas como DVs são bons para acumular e péssimos para apresentar (e não é por causa do Hadoop, que por acaso também tem o mesmo problema), a exploração não pode acontecer dentro do EDW. Neste ponto notamos que precisamos de Data Marts.
Esses Data Marts são trechos do EDW colocados ao alcance do usuário final. Disparado, a melhor organização para atender essa necessidade é um Modelo Dimensional.
Então temos dados extraídos dos sistemas de origem carregados em um EDW Hadoop+DV, e deste arranjo dados para exploração pelo cliente são carregados em Data Marts Dimensionais. Como Data Marts prestam-se, principalmente, à análise multidimensional e relatórios, a melhor opção para guardar esse extrato de dados é uma tecnologia que privilegie essa função. Não é uma discussão encerrada, mas há uma seção inteira de bancos de dados analíticos (ou colunares) dedicados a atender exatamente esse tipo de demanda. Exemplos dessa turma são o proprietário gratuito (até 1TB) Vertica, o livre InfiniDB e o fantástico (e caro, proprietário) SybaseIQ.
Ué, Cadê o SGBDR?
Colocando em uma figurinha simples, temos:
Soluções de BI sem Bancos de Dados Relacionais
Ué, cade o banco de dados relacional em BI?
Não tem, sumiu. Enquanto ninguém olhava, ele esgueirou-se em direção às novas missões transacionais, e deixou esse nicho ser (adequadamente) preenchido por tecnologias mais apropriadas a BI.
Conclusão
O título original deste post era “Fim de Uma Era”, mas achei pomposo demais e muito ordinário. Isso, porém, não muda o fato de que a era dos SGBDs Relacionais usados para Soluções de BI realmente acabou. Ainda vamos ver empresas investindo nessa tecnologia para montar EDWs porque temos uma inércia em tudo que fazemos, e ainda estamos na curva ascendente de criação de mão-de-obra especializada em Hadoop et. al.
Mas tão logo a oferta mão-de-obra cresça o bastante, o sinal da equação vai mudar e a dobradinha de bancos NoSQL + Analíticos passará a a ser mais barata e eficiente que bancos relacionais, quando então teremos aquele momento:
Long gone are the years when to have or not a BI Solution (or Decision Support System) was yet an option. A company who choose not to analyze its data today won’t grow beyond a certain point. It has no tomorrow.
To have working BI initiatives is not easy, let alone simple. A sucessfull BI project depends on a lot of factors and to lead one is not a job for the faint of heart. Business Intelligence projects are experience- and knowledge-intensives. Even the customer must control a degree of education to reap the benefits.
A best selling book does not come from anyone armed with a word processor. A new software is not born out of the hands of its final user just because he/she has a point-and-click Java IDE within reach. Business Intelligence Solutions does not either. The whole big world is a complex place with less and less room for amateurs. Go educated or go extinct!
The Agile Manifesto
This was a milestone for the Information Technology Industry. The Agile Manifest broke the shackles tying projects to ever-late schedules in doomed iniatives, and opened up a road of unprecedent success. As a developer and manager I have embraced the A.M. and adopted Scrum as the means to implement AM. I ended using them both to do everything I do, including Teaching and building Business Intelligence projects.
Recently I became aware that, influenced by the A.M., I have brought some of those principles under a BI light, and I am sharing my insights here.
Agile Business Intelligence Manifesto
The highest priority is to help the customer to answer his questions through early and continuous delivery of quality data and tools for its exploration.
Changing requirements are a must because only so data exploration can shape new hypothesys and drive an increase in knowledge.
Deliver working advances on data platforms frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
Take part in the customer’s problem: To help the customer answer his questions is to help him formulate them by employing specialized knowledge on tools and techniques.
A customer answering its questions is the primary measure of progress, so he can make new questions.
Conclusion
This list does not stand on itself, but rather extends the Agile Manifesto. It also does not take care of effective delivering the results, which should be achieved by using Scrum and a special, iterative technique for BI projects, soon to be posted here.
Personally I don’t agree that Agile BI is only about tools. It sounds like too little, leaving a lot outside, begining with the very customer.
I didn’t invent the above principles, I more like found them spontaneously sprouted and began guiding my work whilst studying and applying the A.M., Scrum and some other methodologies and strategies to my daily job. The statements I posted above are in fact the Agile Manifest adapted to BI needs as per my point of view. I missed a list like that a lot and as until now nobody made a movent toward them, I did. So, here is my proposal.
What is your opinion?
To my English speaking fellows a note: In Portuguese the generic third person is the male form – he/him/his etc. So when we say “he” as the meaning of “anyone” we also refers to women as well. So, I am not confortable with using “one” or “he/she” when refering to an unknown person, what led me to using “he/him” above in the place of a generic “customer”. Please! I have a lot of intelligent women as friends besides my own wife, and I would never downplay the importance of them! I just wanted to sweep the ethnical differences aside so not to taint the discussion or raise any wrong criticism. Right criticism is welcomed <grin>.
Há anos Inteligência de Negócios deixou de ser uma opção. A empresa que não usa BI, hoje e no futuro, simplesmente não irá crescer além de certo ponto.
Inteligência de Negócios não é fácil, muito menos simples. Um projeto de BI de sucesso depende de muitos fatores, e não é uma tarefa para leigos. Projetos de Inteligência de Negócios são intensivamente dependentes do conhecimento dos gestores, dos desenvolvedores e do cliente. O cliente de um projeto de BI precisa estar educado para poder usufruir dele.
Um best-seller não nasce de qualquer um que disponha de um editor de textos. Um novo software não nasce a partir das mãos de um usuário com um produto point-and-click. Soluções de BI também não. O mundo é um lugar complexo e tem cada vez menos espaço para amadorismo e ignorância. Go educated or go extinct!
Manifesto Ágil
Esse foi um documento que dividiu as águas da indústria de artistas que são os desenvolvedores e criadores das tecnologias de TI, incluindo programadores, projetistas de hardware e software e um sem-número de outros profissionais. Apreender o M.A. quebrou os grilhões dos cronogramas atrasados, dos projetos destinados ao fracasso e me permitiu trilhar caminhos de sucesso sem precedentes.
Meu credo como desenvolvedor e gestor é o Manifesto Ágil, e Scrum é o método que eu adotei para implementá-lo. Eu os uso como ferramentas para tudo que faço, incluindo e especialmente Ensino e Inteligência de Negócios.
Eu descobri que, influenciado pelo M.A., tenho seguido alguns destes princípios para projetos de Inteligência de Negócios, e vim dividi-los com vocês.
Manifesto de Inteligência de Negócios Ágil
A maior prioridade é ajudar o cliente a responder suas perguntas, através da entrega contínua e cedo de dados e interfaces para sua exploração.
Mudanças nos requisitos são obrigatórias porque só assim a exploração cognitiva toma forma e novas hipóteses podem nascer.
Entregar avanços nas plataformas de dados frequentemente, entre semanas e meses, com preferência para o intervalo menor.
A principal medida de sucesso é o cliente encontrar resposta à suas perguntas, para que possa fazer novas perguntas.
Participar do problema do cliente: ajudá-lo a responder suas perguntas para ajudá-lo a formulá-las através do emprego de conhecimento especializado de técnicas e ferramentas.
Conclusão
Essa lista não se sustenta sozinha, mas sim estende o Manifesto Ágil. Ela também não executa o desenvolvimento, isso é feito por Scrum e uma técnica especial para BI, que eu postarei aqui em breve.
Não concordo que Agile BI seja apenas sobre ferramentas. É muito pouco, e deixa muito de fora – a começar pelo clientes.
Eu não inventei esses princípios. Depois de estudar o Manifesto Ágil, Scrum e várias outras técnicas, e aplicá-las ao meu dia-a-dia profissional, eu descobri que esses princípios surgiram espontâneamente e vêm norteando minha prática profissional. Eles são praticamente o Manifesto Ágil adaptado para BI – algo do qual eu sinto uma falta tremenda. Como ninguém ainda propôs nada, eis a minha proposta.
Geek BI 