Publicado em por Fábio de Salles

Dez Entregas por Dia… Em BI!

Em junho de 2009 ocorreu a Velocity’09, onde John Allspaw e Paul Hammond fizeram a famosa apresentação 10+ Deploys Per Day: Dev and Ops Cooperation at Flickr (ou você pode vir aqui para os slides.)

Essa mudança não causou um aumento na velocidade de entrega de novas funcionalidades. Ou melhor, não causou um aumento na quantidade de novas entregas – afinal, eles não falaram que aumentaram o time e sem mais recurso você não pode fazer mais.

Ao ir de um deploy por mês para dez por dia, eles reduziram o tempo entre uma idéia entrar em desenvolvimento e chegar ao mercado. Daí, ao invés de fazer um grande release por mês eles passaram a fazer dez pequenos releases por dia.

Tudo bem, vocês dirão, e daí?! Afinal, se cada release tem um custo, eles acabaram foi multiplicando esse custo (overhead) por 200 – 20 dias úteis no mês, vezes 10 deploys.

E que raios tem isso a ver com BI?!

Vamos chegar lá. Eu vou fazer o seguinte:

  • Ilustrar o processo de como empresas criam diferencial competitivo;
  • Extrair o fundamento desse processo na forma de um conceito;
  • Extrapolar esse conceito no contexto de uma empresa contemporânea;
  • Generalizar – aqui eu chego aos dez deploys por mês;
  • Relacionar dados e o conceito acima;
  • Relacionar os dez deploys a BI.

Pegue um café, vai ser um filme!

Um Dia na Vida

Imagine duas lojas, lado a lado, na mesma rua. Ambas vendem a mesma coisa, têm o mesmo tamanho e, portanto, atendem o mesmo público.

A Loja A é gerenciada por um experiente empresário, que cresceu naquele ramo e conhece tanto os produtos quanto a clientela. Ele sabe o que todos precisam e o que vender melhor, o que dá mais lucro e como acompanhar a sazonalidade do mercado. Ele está lá há dez anos, é apreciado por todos do bairro e reconhecido como um bom comerciante. As pessoas frequentam sua loja e sentem-se bem lá.

A Loja B está no bairro a menos tempo. Como a Loja A, seu dono e gerente é um profissional experiente, competente e boa praça. Apesar de seus preços serem um pouco menores que seu concorrente, e ele ter um relacionamento bom com o bairro, seu comércio raramente tem mais público que seu vizinho.

No fundo, a única diferença entre as lojas são as coisas periféricas – arrumação dos itens, empregados, decoração etc.

Um dia, o Gerente B está parado na porta e conversando com seu vizinho e concorrente, o Gerente A:

Gerente B: Você já recebeu o novo sorvete da Kifrio?

Gerente A: Sim, recebi hoje cedo. E você, não comprou?

GB: Sim, comprei também, mas chega só amanhã. Mas, se você já comprou, porque ainda não está na vitrine?

GA: Ora, porque estamos na terça-feira. Ninguém compra coisas novas na terça-feira. Vou te dar uma dica: todo mundo quer novidade às sextas-feiras. É quando as pessoas voltam de casa se preparando para o fim-de-semana e já aparecem aqui perguntando por alguma coisa diferente. Se eu botar o sorvete agora, não terei nada novo na sexta-feira, o sorvete já não será mais novidade.

GB: Puxa, obrigado. Você não tem medo que eu te copie?

GA: Ora, temos quase tudo igual e mesmo assim eu ainda tenho mais gente aqui. Além disso, tem espaço para todos.

Isso deixou nosso herói, o Sr. Gerente B, pensativo. “É verdade”, ele concluiu, “eu posso fazer qualquer coisa e o Sr. A ainda vai vender mais que eu.”

Liberdade, Liberdade

Como o Sr. B estava em uma situação confortável, com a loja gerando um lucro satisfatório, ele ponderou que não tinha nada a perder se experimentasse algumas idéias. Afinal, depois de anos copiando o vizinho e tentando fazer tudo que ele fazia, melhor – menores preços, melhor decoração (na opinião do Sr. B, claro), mais limpa, mais iluminada etc. – ele ainda era o segundo do bairro, a alternativa quando a loja do Sr. A estava muito cheia ou estava sem um determinado produto.

Ele percebeu que estava livre para inovar.

Sua primeira ação foi colocar o sorvete na vitrine assim que o recebeu. Claro, o Sr. A torceu o nariz e até ficou meio chateado. Puxa, ele deu uma dica daquelas e o Sr. B a ignorou! Era quase uma ofensa!!

Enfim, lá foi o Sr. B vender antes os sorvetes. Na sexta-feira, dito e feito, o Sr. A começou a vender o novo sorvete e, claro, sua loja encheu como sempre.

Porém, o Sr. B notou algo: ele recebeu mais clientes atrás de sorvete do que o normal. Não mais do que o vizinho, mas mais que ele mesmo recebia.

Pega-Pega

Na semana seguinte, o Sr. B mudou sua decoração.

Na outra, alterou a posição das gôndolas.

Em seguida, comprou outras marcas de diversos produtos e passou a oferecer uma opção a mais, e para isso ele precisou reduzir o estoque de seus produtos tradicionais.

No final do mês ele mudou a decoração de novo.

O Sr. A acompanhou tudo achanda uma graça o espernear do vizinho. Afinal, esse monte de mudanças só podia significar uma coisa para o Sr. A: a Loja B devia estar com dificuldades financeiras. Talvez o Sr. B estivesse gastando muito em casa, ou esteja passando por alguma doença na família – vai saber, se consolou o Sr. A.

Do ponto de vista do Sr. B, porém, o mundo estava diferente:

  • Ao mudar sua decoração pela primeira vez, ele notou que apareceram mais crianças que o normal;
  • Quando ele mudou as gôndolas, a clientela ficou mais tempo dentro da loja;
  • As novas marcas não fizeram sucesso. Algumas pessoas voltaram por elas, mas a maioria ignorou-as;
  • Na segunda mudança de decoração, as crianças pararam de aparecer.

A cada mudança, o mercado respondia. Nem sempre a resposta era boa – na verdade, nenhuma ainda não tinha valido a pena. Ele não chegou no final de semana com mais dinheiro do que na semana anterior. Porém, ele persistiu.

Um belo dia, algum tempo depois, o Sr. A tomou um susto ao notar que a Loja B tinha, aparentemente, quase tanta gente quanto a dele. No começo ele ignorou isso como uma impressão errada ou uma observação distraída. Porém, a cada semana que passava a Loja B parecia diferente e com um pouco mais de movimento. Em alguns meses a Loja B estava completamente diferente e com outros produtos. Apesar de seu movimento não ter mudado, parecia ao Sr. A que o vizinho agora tinha mais clientes, e clientes que ele não conhecia.

Consternado, mais aborrecido por perder seu posto de líder do que perder vendas, ele puxou conversa com o Sr. B, que contou que seus novos clientes eram amigos dos clientes antigos, que vinham ali por causa da propaganda boca-a-boca atrás de produtos específicos.

O Sr. A pensou e pensou e concluiu que não seria um problema se arriscar. Afinal, ele ainda era a loja do bairro. Começou a experimentar e passou pelo mesmo que o Sr. B: as mudanças alteravam as coisas (público variava, ocupação da loja variava), mas não os resultados (as vendas não mudavam).

Em pouco tempo o Sr. A desistiu de tentar fazer a mesma coisa que o Sr. B e voltou aos seus métodos tradicionais.

Eu não vou finalizar essa história, mas apenas dizer que o antigo equilíbrio estático entre as lojas acabou – a cada dia as coisas eram diferentes e nunca se repetiam. Os Senhores A e B continuam amigos até hoje, e o bairro continua com duas lojas de boa qualidade. (E foi essa paz até o dia em que o Sr. C abriu sua loja do outro lado da rua, mas essa fica para outro dia. ;-) )

O Nome do Jogo É Acumulação

Essa pequena história, totalmente fictícia e completamente baseada no filme Concorrenza Sleale, ilustra pontos importantes nos negócios:

  • Quem decide qual é a melhor empresa é o consumidor, não o empresário;
  • Ninguém nunca sabe o resultado de algo até tentar. Você pode suspeitar, mas só vai saber quando fizer;
  • Imitação não cria vantagem.

No início, o Sr. B não conseguia fazer crescer seu negócio. Ele seguiu todas as boas práticas de mercado, alinhou-se com a empresa de maior NPS do segmento e mantinha um portfólio testado e aprovado pelos consumidores. Apesar de fazer tudo certo, a Loja B não conseguiu superar seu marketshare tradicional.

O Sr. B abandonou sua estratégia tradicional e decidiu adotar inovação como um meio de gerar novos fluxos de receita. A tática inicial era “uma novidade toda semana”. Depois de algum tempo ele descobriu quais novidades geravam maiores retornos e aprendeu como rotineiramente criar esss novidades e assim sustentar um nível maior de faturamento.

Seu segredo era fazer pequenas mudanças, que alteravam a loja de um dia para outro. Enquanto ele descobria como fazer isso, a Loja A seguia repetindo suas estratégias de inovação, como lançar produtos às sextas-feiras e decorar a loja em cada data comemorativa como Natal e Páscoa.

Como resultado, enquanto que a Loja A permaneceu estável no seu segmento, a Loja B atingiu novos públicos, descobriu outros produtos e combinou o processo de inovação com o ambiente local para agradar a um número maior de consumidores, enquanto alterava seu mix de produtos para ficar mais rentável.

O gerente da Loja B assimilou uma realidade: ele não sabe o que vai na cabeça do mercado, mas sabe que testar novas idéias é o mesmo que passear com a loja pelo bairro. Testar novas idéias permite descobrir oportunidades que, bem aproveitadas, tendem a melhorar sua lucratividade.

Já o Sr. A colocou a sua loja em risco, mesmo sem saber disso: as pequenas mudanças em seu entorno distanciam a empresa do mercado. Daí, num belo dia ele vai perceber que não fatura mais tanto quanto antes. Quando ele começar a se mexer já terá perdido o passo e terá que trabalhar dobrado para alcançar o Sr. B (que está na disputa com o Sr. C).

Pequenas mudanças permitem a uma empresa explorar o espaço de oportunidades. Cada pequena vitória, cada pequena melhoria soma-se ao longo do tempo, causando um acúmulo de mudanças que dão o diferencial competitivo.

Claro, existe o lado oposto: um acúmulo de pequenas mudanças erradas vão levar a empresa pouco a pouco para o buraco. Por isso o ciclo PDCA (planeje, execute, verifique e ajuste) é tão importante: ele é um instrumento que permite determinar a qualidade e a direção dessas modificações.

Velocidade é Agilidade

Vamos voltar ao tema da 10+ Deploys Per Day. Eles dizem:

  • O negócio requer mudanças (slide 13);
  • Mudanças causam a maior parte das quebras (slide 14);
  • Diminuindo o risco de mudanças através da mudança de cultura (slide 16).

O argumento deles é que ao invés de fazer grandes mudanças a cada grande intervalo de tempo, mudanças menores a intervalos menores oferecem melhor controle sobre os resultados. Até então, o mais frequente era um grande atrito entre desenvolvimento e operação, com a operação resistindo a mudanças vinda dos desenvolvedores.

Ora, mas que danados esses desenvolvedores! Queriam mudar tudo o tempo todo!

Bom, os desenvolvedores não queriam mudar porque eram tipos irriquietos e bagunceiros, mas porque o negócio precisava mudar, ou poderia ir à falência.

Ao resistir à mudança, a operação não estava protegendo a estabilidade do serviço, mas sim barrando a inovação e impedindo a empresa de mudar e melhorar. Ao acharem como coordenar desenvolvimento e operação, criando o cerne da cultura DevOps, eles resolveram não um problema técnico, e sim um problema de negócio muito sério!

Habilitar uma grande velocidade na mudança teve um efeito intencional, aumentar a estabilidade do serviço sem barrar a mudança, e um efeito não-intencional, que foi diminuir o tempo entre a idéia e a execução. Se antes toda idéia nova levava mês ou meses até ser colocada em produção e ainda representava um risco de perda de faturamento, com DevOps a todo vapor isso caiu para o mínimo possível, deslocando o gargalo de criação de mudanças da operação para o desenvolvimento e o negócio.

Não importava quão rápido negócio e desenvolvimento conseguiam inventar moda, a operação dava conta. Pensou? Programou, implantou, mudou! (E se desse pau, era mais simples e fácil voltar atrás e consertar a situação.)

Já que agilidade é definida como “a capacidade de mudar rapidamente a posição do corpo”, então agilidade tem a ver com velocidade de mudança. DevOps é, portanto, um habilitador de agilidade de negócio pois DevOps permite ao negócio mudar a empresa rapidamente.

Não confunda “capacidade de mudar rapidamente” (agilidade operacional = agilidade de negócio) com Business Agility.

Em resumo, uma empresa atual precisa ter agilidade de negócio (operacional) para poder mudar constantemente, tanto para responder às variações do mercado, quanto para explorar novas idéias. Essa agilidade é, em grande parte, garantida por coisas como DevOps.

Vamos deixar essa questão pendurada e voltar nosso olhar para outro aspecto da vida de uma empresa.

A Empresa Invisível

Uma loja de bairro é uma empresa concreta, tangível: tudo está à vista e pode ser tocado com a mão, desde o estoque no quarto dos fundos, aos consumidores entrando pela porta da frente e a operação dos empregados. Mesmo os fornecedores são visíveis, ainda que esporadicamente. Eventualmente há um computador no balcão, que processa a contabilidade, mas isso é o tudo.

Empresas um pouco maiores, porém, tendem a ser mais informatizadas: os clientes interagem por telefone ou internet, estão registrados em um sistema, que também registra o estoque e os empregados, que não necessariamente estão no mesmo local. A empresa pode oferecer algum tipo de suporte, que é controlado por outro sistema informatizado, que pode acionar remotamente os times técnicos, e assim por diante. Computadores são o que unem e fazem a empresa rodar todo dia, o dia todo.

Isso significa que muitas das novidades não serão lançadas (apenas) como produtos ou serviços mas (também) como mudanças em processos e aplicações. Em 2023, e já há algum tempo, o departamento de informática tem para a empresa contemporânea o mesmo valor que o departamento de engenharia tinha para uma fábrica de 100 anos atrás. Sâo eles que constroem os novos produtos, que implementam a gestão dos processos, as novas linhas de produção e que aumentam as eficiências. Depende-se muito da Informática para realizar as melhorias que causam crescimento e que geram vantagens de negócio.

O livro The Phoenix Project, e sua sequência, The Unicorn Project, mostram como a informatização se torna o novo centro de negócios numa empresa.

Caso o Sr. B fosse o dono de uma empresa um pouco maior que sua loja de bairro, ele faria mais experimentações com sistemas e processos do que com decorações e linha de produtos.

Se você desligar os computadores de uma empresa dessas, e de qualquer outra maior, ela simplesmente some. Quem estiver na empresa continuará a ver o que (ainda) existe de material, como estoque, mesas, armários e o próprio prédio. Porém, tudo que a empresa faz – seu funcionamento, relacionamentos com clientes e fornecedores etc. etc. etc. – sumirá, porque estão nos sistemas informatizados. Mesmo com os computadores ligados, se você olhar para longe da da sua tela, o que você verá é uma fração do que a empresa realmente é e faz.

Uma empresas informatizada é invisível e quanto mais informatizada, quanto mais digital for, menos tangível e mais invisível será a empresa.

Os dados que são criados, alterados e movidos de um lado para outro são como feixes de luz que mostram o que está acontecendo na empresa. Por isso eu sempre digo que, ao contrário da analogia feita por Clive Humby em 2006, dados não são o novo petróleo, mas sim luz: são os dados que permitem a alguém ver o que está acontecendo na empresa, a qualquer momento.

Dados não são petróleo, mas luz. Ignorar os dados é o mesmo que fechar os olhos.

Dados e Exploração

Estamos chegando lá! Aguente só mais um pouco!

Pense comigo: se a empresa existe mais como dados que como coisas, então saber o que está acontecendo na e com a empresa depende de consultar os dados. Logo, criar mudanças e até mesmo inovar depende de analisar os dados.

Além disso, para inovar você precisa testar coisas. Para saber que coisas testar e se deram certo, você precisa examinar a empresa, que é o mesmo que examinar os dados.

Portanto, da mesma forma que uma equipe de desenvolvimento e operação é algo imprescindível para uma empresa muito informatizada, uma equipe de dados é imprescindível para entender a empresa, mudar, inovar, experimentar e avaliar os resultado de tudo isso.

Quando alguém vem com uma nova idéia, junto já traz a métrica e o indicador que será necessário para avaliar os resultados dessa idéia. Por exemplo, suponha que o Marketing decide oferecer um e-book em troca dos e-mails dos visitantes, e divulgam esse e-book em uma rede social. A métrica de sucesso é quantidade de novos e-mails capturados com a página/e-book e o indicador pode ser quantidade de novos e-mails capturados por dia.

Antes mesmo de a campanha ser posta na rua o indicador já terá sido definido e já estará sendo acompanhado – afinal, faz parte da inovação. Esse é um caso onde o dado a ser usado no ciclo PDCA já será coletado e analisado de saída ao invés de entrar pela esteira típica de projetos de BI, em que as coisas são construídas durante um tempo relativamente longo (mês ou meses).

Agora, e quando nasce uma pergunta de negócios do nada? Não há escapatória: é preciso ir até a equipe de dados, abrir uma demanda e esperar que ela aconteça.

Até esses dados serem obtidos e analisados, a empresa estará parada, aguardando.

Estamos em 2023. Desenvolvimento e Operações conseguem fazer não dez, não 100, mas DEZENAS DE MILHARES DE VEZES POR DIA:

Enquanto isso, quantas entregas de dados seu time está fazendo?

Uma por dia?

Uma Entrega por Dia

Se você está em uma empresa normal, dificilmente você faz uma entrega por dia. Talvez entregue um produto de dados por semana, por time, se tanto. Daí, se você tiver cinco times, talvez entregue em média um por dia a cada semana.

Por que é que em 2023 ainda não temos a tecnologia e gestão e cultura necessária para entregar um produto de dados por dia?

Se você quiser tornar a sua empresa verdadeiramente ágil, capaz de descobrir e explorar oportunidades enquanto elas existem, você precisa tornar o seu projeto de dados tão rápido (=ágil) quanto um projeto DevOps.

Você precisa receber uma demanda de dados de manhã e entregá-la à tarde.

Pergunte-me como. :-)

Conclusão

A Humanidade conhece a alvenaria há milênios e mesmo assim ainda dá trabalho construir uma casa. Temos Engenharia Civil, Arquitetura, Eletricidade, Hidráulica e um monte de outros conhecimentos envolvidos na construção que seja de um simples puxadinho no fundo do terreno. Depois de pronta, uma construção de alvenaria precisa receber manutenção periódica, sem contar a limpeza e eventuais tratamentos químicos (como descupinização).

Construir um prédio em alvenaria não é o mesmo que fazer um bolo de caixinha: requer conhecimento especializado, profissionais capazes e experientes, um bom plano, tempo e dinheiro. E, insisto, temos essa tecnologia há milênios. Milhares de anos. Centenas de milhares de dias.

A Informática com computadores eletrônicos nasceu há coisa de 70 anos e nesse curtíssimo espaço de tempo (todos os bebês que nasceram junto com o primeiro computador eletrônico do mundo ainda podem estar vivos) já mudou e mudou e mudou. Ainda estamos aprendendo a usar essa ferramenta. Já tentamos construir sistemas usando as mesmas técnicas de Alvenaria, e vimos que não funciona. Faz vinte anos que estamos testando outra abordagem e parece estar indo melhor.

Ainda falta muito para descobrir (ou para termos certeza) de qual é a maneira correta de se construir sistemas e desenvolver soluções informatizadas.

Agora, e com dados? Pior ainda!! Se erramos com desenvolvimento por décadas, imagine com dados, que está por aí há metade desse tempo!

Hoje estamos vivendo a Era Ágil, que entrega melhorias e mudanças rapidamente, com menos riscos de interrupções e menos tempo entre idéia e execução.

Os projetos de dados precisam atingir o mesmo patamar. Não existe motivo para um executivo descobrir uma pergunta de negócio de manhã e não ter a resposta à tarde.

Se você almeja sustentabilidade da sua empresa, isto é, que ela dure por gerações, você precisa estar sempre um passo à frente. Para isso, precisa saber o que está acontecendo nela que, graças à informatização, é invisível aos cinco sentidos. Você precisa de dados disponíveis e analisados em horas ao invés de meses ou mesmo semanas. Não dias, horas.

Para você conseguir fazer isso você precisa colocar a Tecnologia em segundo plano e subordiná-la ao Negócio.

Até a próxima! ;-)

Publicado em por Fábio de Salles

Quem Não Se Comunica, se TrumBIca!

Há algum tempo eu comentei que nunca vi um projeto de BI aplicar técnicas ágeis com sucesso. E completei:

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! :-)

Padrão Scrum

Jorge Kotick Audy, meu mestre em Ágil & mudanças, diz que:

“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.”

Se fosse um buffet, o método escolhido seria o prato!

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!

:-)

Publicado em por Fábio de Salles · 2 Comentários

Agile BI?

Em agosto de 2005 eu lancei um mini-curso sobre como fazer levantamento de requisitos para projetos de Business Intelligence. O que diferenciava aquele curso da prática tradicional era ser voltado para projetos ágeis. Você pode ver aquele post clicando aqui, conhecer o curso aqui e assistir ao vídeo promocional seguindo este link.

O assunto é interessante por demais da conta. Nestes dois últimos anos eu tenho me dedicado a estudar como melhorar a implementação de projetos de BI e DW usando técnicas ágeis. Tenho visitado palestras, lido artigos pela web, conversado com inúmeros profissionais. O resultado desse envolvimento todo apareceu na minha palestra do Pentaho Day 2017, BI E.V.A., que teve uma boa recepção junto à comunidade Pentaho.

Hoje eu recebi um e-mail da TDWI, um respeitado instituto de Data Warehousing. O assunto? É óbvio, né?

Agile BI.

E-mail do TDWI convidando para um curso de Agile BI.

Claro que eu tinha que ver do que se tratava. Eis o conteúdo prometido:

  • Agile modeling values and principles
  • Techniques for determining the right level of up-front design
  • How to avoid overbuilding solutions by designing for what is needed
  • Domain modeling
  • Data model patterns
  • Data smells and the impact of technical debt
  • Continuous integration
  • Safe refactoring techniques for making incremental design changes
  • How to determine the right level of design documentation that is needed
  • Effective collaborative modeling practices for cross-functional teams
  • How to minimize the amount of unnecessary rework through reference and conceptual designs
  • How to establish iteration zero as an agile practice that gives teams the runway to start delivering

Hmm… Interessante. Uma das coisas que eu comento no BI E.V.A. é que há muito sendo discutido sobre como se transformar o processo de modelagem de dados, em especial Modelagem Dimensional, em um processo “ágil”. No fundo, o que muito da literatura tem pregado é como incorporar Scrum ao processo tradicional.

Eu já fiz isso, e não adianta.

Pense um pouco: o cerne de ser ágil é prover melhoria contínua. Mas o cerne de um processo de modelagem dimensional é entender a necessidade do cliente. Não é muito evidente, mas o fato é que essas motivações são incompatíveis. Ainda não tenho um argumento finalizado e por enquanto eu recomendo a leitura das notas da apresentação BI E.V.A. – é o melhor que eu consigo no estágio atual.

Ainda não é uma Conclusão

Voltando ao curso do TDWI, o que é que eles oferecem? Uma outra abordagem ao processo de modelagem de dados? Não.

Um outro modelo de dados? Não.

Uma outra forma de tratar os levantamentos de requisito? Não. (Meu curso faz isso.)

Eles propõe “modelar apenas o suficiente para galvanizar o cliente e desenvolvedores ao redor de uma compreensão compartilhada do domínio do problema, arquitetura e modelo de dados”.

Ou seja: adotemos ágil e, na hora de construir o modelo de dados, vamos fazer apenas o mínimo para começar. Do que se depreende que desenvolvimento incremental, aqui, deve ser “uma dimensão por história”, “uma estrela por épico” ou coisa do tipo!

Foi exatamente o que eu tentei. Deu resultado, mas ainda não me permitiu os fantásticos ganhos de produtividade que Scrum normalmente proporciona. Leia “Scrum: a arte de fazer o dobro do trabalho na metade do tempo” para saber do que é que eu estou falando. ;-)

Ganhos fantásticos!

O que eu acabei descobrindo é que o que atrapalha o desenvolvimento ágil – incremental – é a dificuldade de expressar a necessidade do cliente de modo que permita correções e ajustes, o que acabou me levando a rever o problema por outro ângulo.

Então este é o estado do BI Ágil, hoje?

Claro, existe mais sendo feito por aí. Quem leu o Building a Scalable Data Warehouse with Data Vault 2.0, por exemplo, viu uma outra abordagem. Mas ainda não nasceu algo que verdadeiramente habilite a construção de projetos de BI e DW calcados nos fundamentos ágeis – melhoria contínua, incremental, articulada.

A busca continua! :-)

Publicado em por Fábio de Salles · 2 Comentários

Pentaho Day 2017 – BI E.V.A.

Neste exato momento estou assistindo a uma palestra do Pentaho Day 2017, ao qual eu tive a honra de ser convidado como palestrante. Minha palestra foi ontem, dia 11/5/17, e chamava-se BI E.V.A. – Enxuto, Valioso, Ágil. Ela teve uma recepção muito boa, acima do que eu esperava, e estou muito feliz de ter podido proporcionar aos participantes algo que eles tenham gostado.

Neste link você pode baixar um PDF das notas, que traz os slides e todos os comentários que eu “fiz”.

BI E.V.A.

O clipe do começo pode ser assistido neste link, para o Youtube. É o videoclipe Houdini, do Foster The People.

Foster The People – Houdini.

Eu estava salvando minhas (poucas) idéias para o Pentaho Day 2017. Agora que passou, voltarei a postar com mais frequência, focando justamente os temas de valor, agilidade e lean em BI.

É bom estar de volta. :-)

Publicado em por Fábio de Salles · 9 Comentários

A Culpa é do Cubo!

Em 12 de janeiro de 2017 eu estive no evento DBTalk Liderança Ágil, tocado pelo meu ídolo agilista Jorge “Kotick” Audy. Foi uma hora e meia sendo soterrado por avalanche atrás de avalanche de assunto sobre liderança, Ágil, organizações, modelos, psicologia…

Como todo bom evento, semelhante a um boi, nada se perdeu, tudo se aproveitou. Depois de tudo que veio na palestra, ainda tive chance de bater papo com ele e muitas outras figuraças que estavam por ali.

É sério, não percam esse evento, que ocorre frequentemente em Porto Alegre, sede da empresa, e com alguma frequência aqui em São Paulo. É do balacobaco.

Uma dessas conversas foi o espanto geral de que há pouco, em termos de Ágil, sendo feito em Inteligência de Negócios. Na verdade é pior que isso: o pouco que eles viram fui eu que levou – um zé ruela qualquer. Fora o que este vosso humilde servo-zé-ruela fez, eles mesmos confirmaram que nunca viram nada.

E porquê? Por que tão pouco existe sobre BI, com Ágil?

Eu descobri essa resposta há muito tempo, mas só ali a minha “Guernica” 1 BI-Ágil ficou completa, só ali é que a última peça fez clique no lugar.

Por causa do cubo.

Adoro Kimball, tanto que fiquei muito triste ao saber que se aposentou – acabou-se minha chance ter aulas com ele. Mas o enorme sucesso de suas idéias acabou levando a uma absurda prevalência da Modelagem Dimensional em projetos de dados para BI. Como em geral são projetos de DWs ou data marts, acabamos sendo levados a pensar tudo em termos de cubos.

Estão acompanhando? Atrelada a projetos de BI existe uma forte cultura de modelagem de dados à moda do Kimball. Assim, nos acostumamos a “pensar” os dados de projetos de BI como organizados em cubos multidimensionais.

E – na minha humilde opinião – esse é O problema. É esse o motivo para existir tão pouca coisa de Ágil para Inteligência de Negócios.

Não sei se vou conseguir passar, aqui, por escrito, a minha percepção do problema e como intuí a resposta, mas vamos tentar.

O Mundo Não é um Quadrado em 3D

Para começar, há muitas necessidades em BI para as quais um cubo é uma abordagem inadequada, quando não atravancadora.

Um exemplo fácil é Data Mining

Resumidamente, Data Mining ou Garimpagem de Dados na minha tradução favorita, é um processo que parte de uma questão de negócios, como o que fazer para aumentar as vendas em 5%? ou como decidir quanto crédito fornecer a cada cliente, e usa Matemática sobre os dados disponíveis para construir um modelo da realidade. Realidade esta que não se apresenta clara, límpida e cristalina nos bancos de dados da empresa, mas sim como uma massa bagunçada e suja de dados oriundos de inúmeras fontes – sistemas transacionais, pesquisas, bases externas, canais diversos etc.

O resultado do processo de garimpagem é um modelo matemático que descreve a realidade, e a realidade é suja.

Para fornecer um resultado com algum grau de confiabilidade, Data Mining precisa de dados crús.

Por outro lado, dados limpos, como os necessários para análises multidimensionais típica, não refletem a realidade completamente. Erros, vazios, nulos, tudo isso é descartado para levar ao cliente uma estrutura com dados claros, que permitam interpretação sobre o que sabemos, já que não adianta especular sobre o que não foi capturado.

Na melhor das hipóteses, dados sujos são disponibilizados para análise com alguma marcação, como “Não preenchido”, “Inválido” etc. Empresas que sofrem com qualidade de dados fazem isso porque assim conseguem um mínimo de certeza em suas respostas. E alguma informação é melhor que nenhuma, sempre.

Outro exemplo? Claro: painéis.

“Como assim!”, exclamarão vocês, “painéis se dão muito bem com cubos!”

É, não posso negar que se dão bem, vocês quase têm razão.

Quase.

Como é mesmo aquilo que dizemos sobre martelos? “Para um martelo, todo mundo é prego.” Se você quer montar um modelo de dados dimensional, para tudo, vai estar condicionando tudo a uma visão dimensão vs. fatos.

Painéis tendem a aglomerar diferentes visões sobre um dado aspecto da sua organização. Logo, não raro temos em um único painel widgets apontando para diferentes fontes de dados. Diferentes origens.

Diferentes cubos.

Vou escrever ao contrário para ver se fica mais claro:

Preparar dados para um painel usando um único cubo requer a consolidação de diferentes grãos em um único, que sirva para tudo.

Caso isso não seja possível, precisaremos de mais de um cubo.

Logo, uma visão de cubos te obriga a transformar toda sua realidade, em que as relações são mais complexas que as relações de um modelo dimensional, em vários pedaços. Isso acaba destruindo a produtividade porque para cada pedaço você precisa passar por todo processo de desenvolvimento de modelo dimensional!

É isso que redime o setor de Data Discovery, meu eternamente incômodo e aborrecido setor de ferramentas para Data Discovery.

Não tenho nada contra ferramenta nenhuma! Mas tenho contra argumentos frágeis e superficiais! Leia aqui!

O que está no centro de uma ferramenta de Data Discovery não é a capacidade de produzir resultado sem precisar de um DW. Caramba, uma ferramenta de DD não tem nada que uma de BI não tenha! São absolutamente iguais!

O que destaca DD da prática tradicional de BI é que Data Discovery prescinde do processo de modelar um cubo como intermediário para análise! Você nunca pode se livrar de um DW porque o Tempo é a variável mais importante de todas, mas em nenhum lugar está dito que é obrigatório ter um cubo para historiar dados! O que no fundo DD faz é abrir mão de um horizonte de tempo maior em prol de maior velocidade na geração de valor!

Worlds Collide!

Eis aqui o Manifesto Ágil:

Manifesto para o desenvolvimento ágil de software

Estamos descobrindo maneiras melhores de desenvolver software, fazendo-o nós mesmos e ajudando outros a fazerem o mesmo. Através deste trabalho, passamos a valorizar:

> Indivíduos e interações mais que processos e ferramentas

> Software em funcionamento mais que documentação abrangente

> Colaboração com o cliente mais que negociação de contratos

> Responder a mudanças mais que seguir um plano

Ou seja, mesmo havendo valor nos itens à direita, valorizamos mais os itens à esquerda.

Esse é precisamente o ponto:

Indivíduos e interações mais que processos e ferramentas

O que é que acontece quando colocamos um cubo à frente de qualquer resultado? Resposta: estamos valorizando o processo e a ferramenta!!

Por que é que temos tão pouco de Ágil em BI?

Que tal analisar o que existe de Ágil para BI listando os livros que tocam no assunto?

Entrei na Amazon.com e coloquei BI e Agile. Deu nisso:

Ágil e BI na Amazon: livros sobre... DW?
Ágil e BI na Amazon: livros sobre… DW?

Depois do terceiro resultado tudo ficava mais ou menos confuso – ou tinha pouco/nada a ver com BI ou com Ágil ou com ambos. Fechei a busca, e coloquei Data Warehouse e Agile:

  • Agile Data Warehouse Design: Collaborative Dimensional Modeling, from Whiteboard to Star SchemaNov 24, 2011
  • Agile Data Warehousing for the Enterprise: A Guide for Solution Architects and Project LeadersOct 8, 2015
  • Better Data Modeling: An Introduction to Agile Data Engineering Using Data Vault 2.0Nov 21, 2015
  • Super Charge Your Data Warehouse: Invaluable Data Modeling Rules to Implement Your Data Vault (Data Warehouse…May 20, 2012
  • The Official Data Vault Standards Document (Version 1.0) (Data Warehouse Architecture)Sep 27, 2012
  • Data Architecture: A Primer for the Data Scientist: Big Data, Data Warehouse and Data VaultNov 26, 2014
  • Agile Data Warehousing Project Management: Business Intelligence Systems Using ScrumSep 28, 2012
  • Growing Business Intelligence: An Agile Approach to Leveraging Data and Analytics for Maximum Business ValueSep 21, 2016
  • Growing Business Intelligence: An Agile Approach to Leveraging Data and Analytics for Maximum Business ValueSep 19, 2016
  • Extreme Scoping: An Agile Approach to Enterprise Data Warehousing and Business IntelligenceAug 15, 2013
  • Agile Data Warehousing: Delivering World-Class Business Intelligence Systems Using Scrum and XPAug 5, 2008
  • Test-Driven Database Development: Unlocking Agility (Net Objectives Lean-Agile Series)Feb 21, 2013
  • Lean Analytics: Use Data to Build a Better Startup Faster (Lean Series)Mar 21, 2013

Ou seja: muita coisa sobre DW e Ágil, mas pouca sobre BI e Ágil.

Ora, bolas, é a Amazon! Eles vendem, e isso enviesa tudo. Vamos procurar uma coisa mais abrangente, mais neutra: o Google!

Ágil e BI, segundo o Google: ferramentas?!...
Ágil e BI, segundo o Google: ferramentas?!…

(Claro que eu sei que o Google também enviesa os resultados. Na verdade, enviesa tanto que eu precisei remover a renca de anúncios que vinha antes do quadro acima. Mas é mais aberto que a Amazon.com, não resta duvida.)

De novo, foco em ferramentas! Ou quase. Se seguimos o link para a Wikipédia, achamos algo mais próximo de Ágil:

Agile Business Intelligence (BI) refers to the use of the agile software development methodology for BI projects to reduce the time-to-value of traditional BI and helps in quickly adapting to changing business needs.(…)

Opa, agora sim! “Ágil BI refere-se ao uso da metodologia de desenvolvimento de software ágil para projetos de BI, para reduzir o tempo-até-valor”! Eles até citam a “metodologia” que nasceu para resolver problemas de desenvolvimento de software, mas focam no que é importante: rápida geração de valor para a organização.

Curiosamente, essa mesma definição tem como referência produtos de software para “fazer BI Ágil”, um tal de Consensus e outro, Logix – nunca havia ouvido falar de nenhum dos dois, o que para mim é suficiente para colocar esse artigo em quarentena. Vou lê-lo e estudar essas ferramentas com mais calma e decidir se é mais algum fornecedor querendo surfar hype, ou se me parece válido, sólido.

Vamos refazer nossa pergunta: por que é que temos tão pouco de Ágil em BI?

Resposta: não sei. Mas se eu precisasse chutar algo, diria que é porque todo mundo entende que o tratamento de dados vem no centro de todo projeto de BI, que por sua vez está perpetuamente voltado para o modelo dimensional.

Colocando de outra forma:

IMHO, temos pouco de Ágil para BI porque quem se dedica a este assunto acaba preso na questão de produzir dados e não de solucionar problemas.

E eu acredito que, também IMHO, isso acontece porque o enorme sucesso da Metodologia de Modelagem Dimensional, de Ralph Kimball, criou em nós uma associação automática entre BI e Cubo.

Conclusão?

Dificilmente isto aqui é uma conclusão, pois eu ainda não cheguei nela. O que eu tenho, por enquanto, é a forte sensação de que o problema de produzir dados para projetos de BI está polarizando a aplicação de técnicas ágeis para BI, causando foco excessivo no desenvolvimento de cubos, ou seja, de modelos multidimensionais.

Eu ainda não achei uma evidência forte de que isso bloqueia o desenvolvimento ágil, ou de como esse bloqueio atuaria, se existir. Intuitivamente eu percebo que um modelo dimensional não é algo muito difícil de ser atacado com métodos ágeis, e até por isso mesmo há tanto material sobre esse assunto. Me parece que o fato de termos um modelo dimensional no meio do caminho entre a necessidade de negócio e a solução de BI é que atravanca as coisas, que por sua vez é justamente a causa aparente do sucesso do Data Discovery. E não podemos ignorar a frequência de fracassos de projetos de DW.

Por exemplo, se um DW cresce pela colagem de um cubo em outro através de dimensões comuns ou conformadas – a tal Bus Matrix – então cada nova necessidade acaba criando algum retrabalho ou uma nova expansão do DW. Eu estou começando a achar que o Modelo Dimensional permite muito pouco reaproveitamento. Quase como se, a cada nova funcionalidade de um sistema fosse preciso duplicar um pedaço grande do sistema, e customizar essa nova parte.

Como lidar com um armazém de dados construído para um único propósito – análise multidimensional – em uma empresa que pode possuir n demandas de m tipos para os dados, em que cada demanda requer praticamente um cubo próprio? E pior: como lidar com as necessidades operacionais?

Confuso? Para mim também. :-(

Eu acho que encontrei a solução (sim, tem Data Vault envolvido, claro!), mas ainda não está madura o bastante para sair aqui. Mas assim que estiver, você será o primeiro a saber.

Até a próxima! ;-)

  1. Guernica é o nome de um famoso quadro sobre um episódio da Guerra Civil Espanhola, pintada por Pablo Picasso. Sua interpretação é muito controversa. Uma das que eu ouvi é que é cheio de partes que representam aspectos do conflito, e tenta capturar a dificuldade que é, para uma mente humana, abarcar uma realidade complexa, cheia de nuances e contradições. Baseado nessa visão eu estou rascunhando um post que tenta mostrar como BI se assemelha mais à Guerra Civil Espanhola, complexa e cheia de partes, que a uma coisa como Física, que é feita de partes interconectadas e articuladas entre si. ↩
Publicado em por Fábio de Salles · 3 Comentários

Livros

Mais ou menos uma vez por mês eu entro na Amazon, seção de livros, e digito “dw” ou “bi” ou “data mining” ou algum jargão da nossa área. Eu reviso a lista resultante e vou separando (clicando com o control apertado, para abrir em outras abas) todo e qualquer livro que eu ache interessante. Reviso essa seleção mais uma vez e escolho um ou dois para ler.

A última rodada me trouxe quatro livros do balacobaco.

Impossible Data Warehouse Situations

O mais divertido de todos, de longe, foi este:

Impossible Data Warehouse Situations.
Impossible Data Warehouse Situations.

É um livro antigo, do início dos anos 2000, que aborda um rosário de problemas comuns em implementações de DW. Por exemplo:

  • Quando o protótipo vira produção;
  • TI é o assassino;
  • Clientes não sabem o que querem, clássico dos clássicos!
  • A quem o time de DW deve se reportar? (CIO, gerência de departamento etc.)

Ou seja, problemas comuns. Por que, então, o título de situações impossíveis? Bom, justamente por serem comuns é que são impossíveis: impossíveis de se evitar, quase impossíveis de se resolver.

E nenhum destes problemas faz parte de nenhum curso de DW. Pode olhar, pode procurar. O máximo que você vai conseguir achar é um professor mais experiente que passou ou resolveu algumas destas situações, e vai te contar alguma coisa se você perguntar.

Dessa constatação temos o valor que esse livro possui: inestimável. Até porque não é um autor prescrevendo soluções mágicas, mas sim um painel de profissionais gabaritados que dão sua opinião a cada tópico.

Veja esta situação, como exemplo:

  • Should a line of business build its own DM?

Ou, no meu tradicional e macarrônico estilo de tradução, “um departamento deve construir seu próprio DW?” Ela é descrita, contextualizada e daí vários dos colaboradores do livro dão sua opinião. Alguns são bem rasantes, outros são mais acadêmicos, uns são pé-no-chão enquanto que outros, viajantes. Assim você acaba sempre com várias visões e idéias e propostas para o problema – uma riqueza enorme!

A resposta desse exemplo, para mim, vale ouro. Vários foram quadradinhos, “sim, porque o DW é a coleção dos Data Marts” ou “não, porque o DW é uma coisa centralizada”. Bah, isso eu já sei. Mas aí vem a Jill Diché, minha favorita: go togheter with IT. Ou seja, aproxime-se da TI e ofereça para dividir a carga: você colabora com profissionais e ganha, em troca, priorização. Como é você quem vai fazer a sua parte, você recebe antes. Isso deixa o departamento feliz, a TI feliz (porque tem mais mãos para trabalhar) e não aborrece os consumidores que competem com recursos! Gênio!

E o livro está cheio dessas!

Claro que, com essa idade, alguma coisa acaba datada, como essas duas “situações impossíveis” por exemplo:

  • O sistema de origem muda continuamente; ou uma variação
  • O sistema de origem está passando por uma mudança.

As soluções propostas são de gerenciamento, mitigação de riscos e fortalecimento dos padrões e do modelo dimensional. Hoje em dia temos outra opção (já sabe, né? Data Vaul!), mas mesmo assim não é uma mudança tão grande.

O livro fala sobre negócio (mal-entendidos, desinteres, motivação), times (disfuncional, prima-donas, encrenqueiros), clientes (chatos, ruins), chefes (burros, preguiçosos ou bagunçados), técnicas (metodologia, falta de conhecimento, de experiência), padrões (usados errados, sem padrões), ferramentas e qualidade dados, entre outros.

Como eu disse, adorei esse livro. Não consigo deixar de mencionar outros dois favoritos meus, dos padrões:

  • Os empregados usam a terminologia de maneira errada;
  • Tudo é Data Mining.

:-D

Clinical Intelligence

O nome inteiro do livro é enorme:

Clinical Intelligence: The Big Data Analytics Revolution in Healthcare: A Framework for Clinical and Business Intelligence

E ele fala exatamente isso: como usar os conceitos e idéias de BI aplicado ao campo da Saúde. Há algum exagero e um pouco de mal-entendidos, mas nada que prejudique a idéia central.

Por exemplo, ele separa BI e Analytics (item 1.2, paǵina 26), e classifica machine learning, pattern recognition e predictive modeling como motores (engines) e – não bastasse – ainda por cima diferentes. Como se um padrão não fosse um modelo preditivo, e coisas nessa linha. Dá para suspeitar um pouco se ele realmente chegou a entender tudo do que fala, mas – torno a insistir – não compromete o resultado final. Apenas leia com algum resguardo, pois ele não é da área de BI.

Já na parte que realmente interessa, meus caros, ele arrebenta.

E o que realmente interessa é o índice do capítulo 2:

Sumário do capítulo 2.
Sumário do capítulo 2.

(Peço perdão pela baixa qualidade da imagem. Puxei-a do site da Amazon, e ele não estava colaborando muito…)

Vêem? Ele mostra um tipo de análise para cada um dos vários assuntos médicos! Tem desde aspectos administrativos, como casos de uso, scorecards e indicadores diversos, a complexos modelos de atendimento clínico e previsões de custos, passando por modelos de predição de osteopatia e acompanhamento de antibióticos.

Na boa, esse é o livro de cabeceira de QUALQUER gestor de saúde. Quanto mais abrangente a responsabilidade desse gestor, mais importante se torna esse livro. Em outras palavras: leitura obrigatória para secretários e ministros da Saúde, ponto.

É uma leitura que eu passei meio por alto, afinal eu sou um alien para esse campo. Eu me detive apenas nas partes de BI (onde ele faz uma zona com alguns conceitos, acerta outros e se embanana todo com ainda outros) e matemática (em que ele, aparentemente, coleta trabalhos feitos por diversos outros times, uma coisa absolutamente normal, aceitável, afinal, só um ser sobrenatural poderia saber tanto sobre tanta coisa diversa.)

Agile Data Warehouse Design

Este livro tem uma proposta muito bacana: estabelecer uma metodologia para captura de requisitos para DW adequada a projetos ágeis, e ágil em si mesma.

Cara, ficou ruim. Deixe-me tentar de novo:

Este livro tem uma proposta muito bacana: explicar um método ágil de capturar requisitos para DW, requisitos estes adequados a projetos de gestão ágil.

Bem melhor!

Ágil como em ninja, não como em rápido.
Ágil como em ninja, não como em rápido.

E seria um livro excelente não fosse tão… poluído? Pesado? Foi difícil lê-lo do início ao fim, e eu falhei nisso – depois de um tanto saí pulando até onde aguentei. O método é interessante, parece que funciona e não é difícil. Acho que o maior galho dele é justamente ser uma receita de bolo. Ele tenta passar um conhecimento “situacional”, ou seja, de como agir em cada situação, e fica tão cheio de exemplos e detalhes e senões que a coisa toda fica pesada, trabalhosa.

A sensação é que, uma vez assimilado esse conhecimento, a coisa flui. Assimilá-lo é que parece mesmo um trabalho duro. E, já que estou no assunto, ele não resolve os problemas típicos de projetos, nem de projetos de DW, justamente como aqueles colocados no Impossible Situations – esse mesmo, sobre o qual escrevi acima.

Vale a pena ler? É, pode ser que sim. Se tiver tempo, com certeza. Mas não me parece uma daquelas técnicas que abalam o mundo, como – adivinhe? – Data Vault ou Análise Bayesiana. Mesmo assim, ele agrega.

Até porque eu cheguei numa técnica semelhante, muito mais modesta e de alcance muito menor, mas na mesma linha. ;-)

Variados

E esses eram livros que eu havia lido, mas sobre os quais ainda não falara nada. Além deles, em 2016 eu li alguns outros. Dessa leva de coisas da Amazon falei um pouco no post Férias = Livros!. Não custa relembrar (não custa mesmo, é só um copy-paste aqui, hehe):

Cada um deles é um primor de conteúdo e forma. O de expressões regulares eu deixei até separado, de tanto que eu uso. O de análise bayesiana eu leio e leio e leio e uma hora eu vou dominar!

Já o Building A Scalable DW, bom, pelamordedeus, leia! Ele e o DW Toolkit são a base para um DW Corporativo feliz e saudável! ;-)

Alguma Dica?

E isso fecha o meu ano de leitura. Agora estou procurando as coisas para 2017.

Alguma sugestão? ;-)

Publicado em por Fábio de Salles · 6 Comentários

A.B.I.M.

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>.