novembro 2020 – Geek BI

Publicado em 26/11/2020 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 18/11/202011/11/2020 por Fábio de Salles · 1 Comentário

BI & ToC – Parte 3

No post Por que Inteligência de Negócios estagnou em painéis? eu coloquei o seguinte questionamento:

Tudo que responde pelo nome de BI, hoje em dia, data de vinte, trinta anos atrás. Porquê?

Para descobrir esse por quê apliquei a técnica de Árvore de Realidade Corrente, da Teoria das Restrições.

Leia o primeiro post para entender a motivação. O segundo, Inteligência de Negócios & ToC, foi apenas um ponto intermediário. Não fará falta para entender o de hoje, mas fique à vontade para lê-lo.

Efeitos Indesejáveis

A lista de EIs até agora é a seguinte:

Time de BI não tem voz ativa na condução do projeto
Time gradualmente perde autonomia para tomar decisões de projeto/técnicas/ tecnológicas
Uma demanda típica requer muito trabalho
Uma demanda vai e volta várias vezes, até o usuário se dar por satisfeito
Usuário prefere adotar soluções manuais
Usuários abandonam soluções rapidamente
Valor percebido é pequeno
A análise do problema é encerrada prematuramente
A carreira do empregado corre risco
A demanda não resolve o problema de negócio
A empresa acredita que a solução do problema requer BI
A empresa decide investir em um projeto de BI
A empresa decide resolver o problema
A empresa descobre um problema
A fama de projetos de BI é ruim
As consequências (EIs) são tomadas pelos problemas (as causas)
A solução não resolve o problema de negócio
Cada demanda tem aplicação limitada ao problema que a originou
Cada problema resolvido expõe outro problema
Capacidade do time e do gestor são questionadas
Demandante questiona decisões técnicas
Demandas demoram a ser atendidas
Demandas têm pequena vida útil, tornando-se obsoletas rapidamente
Desenvolvimento emprega muitas ferramentas
Desenvolvimento requer muitos passos.
Empregado é a causa do problema
Empregado esconde a verdade
Empregado sabota projeto
Equipe de BI não é consultada para desenhar solução
Existe pressão por resultados
Gestor de BI sofre desgate de imagem
Há a impressão de que projetos de BI não saem do lugar
Objetivos são confusos
O demandante desenha uma solução para o sintoma, e não para a causa
O demandante não entende com clareza qual é seu problema de negócio
O entregado não atende ao usuário
O patrocinador do projeto se desgasta com atrasos e aumentos de custos
O problema de negócio se manifesta através de EIs
Projeto de BI sofre sabotagem branca
Projetos de BI tendem a se alongar
Retrabalho surge constantemente
Sintomas podem mudar
Soluções envolvem dados, negócio, análise, visualização e aplicação

Recapitulando: EI é o nome dado aos problemas que experimentamos. Significa Efeito Indesejável, indicando que não é o problema, mas um efeito causado pelo problema. A causa-raiz dos EIs é o (ou são os) problema(s).

Árvore de Realidade Atual

Todos os EIs anteriores estão ligados. Como explicado anteriormente, a árvore deve ser lida de baixo para cima, seguindo o formato

SE EIn ENTÃO EIm
Onde n e m são índices: EI1, EI2, EI3, …, EIn, …, EIm, …

CRT para BI versão 1.0. Clique para ver a imagem em alta resolução.

O começo da árvore se lê assim:

Se “A empresa descobre um problema” então “O problema de negócio se manifesta através de EIs”;
Se “O problema de negócio se manifesta através de EIs”, então “As consequências (EIs) são tomadas pelos problemas (as causas)”;
Se “As consequências (EIs) são tomadas pelos problemas (as causas)” e “Empregado esconde a verdade”, então “O demandante não entende com clareza qual é seu problema de negócio”
Se “…”, então “…”;
…

E assim por diante.

Sabemos se árvore está certa se faz sentido: se, ao ler o ramo, você pondera que é lógico, é puro bom senso, que faz sentido e até mesmo é óbvio, então é uma relação é válida. Se não, então eu provavelmente cometi um erro. Neste caso eu preciso re-examinar a relação e tentar entender o que não faz sentido e criar novas relações até chegar no caminho certo.

Conclusão

Eu considero que essa é uma versão 1.0 por que ela inclui os principais EIs que eu experimentei em projetos de BI:

O cliente não sabe o que quer;
O problema não é claro;
O time de BI é desafiado constantemente por causa das consequências de projetos anteriores;
Existem interesses escusos envolvidos (eu relutei em aceitar, mas no final fez sentido;)
A motivação para empregar BI não é clara, quando não é simplesmente “seguir a moda”.

A julgar pela recepção dos posts, vários de meus amigos e conhecidos experimentaram a mesma coisa ou situações semelhantes.

Como das vezes anteriores, eu deixei a árvore de lado por um tempo e voltei para lê-la. E como das vezes anteriores, já achei coisa que não faz sentido. Por exemplo, “se a empresa decide resolver o problema, então ela acredita que a solução do problema requer BI” não tem pé nem cabeça. Deveria ser algo como “se a empresa decide resolver o problema e alguém disse que BI resolve, então a empresa decide investir em um projeto de BI”.

E você? O que acha da lista de EIs até agora? E da árvore?

Comente! :-)

Publicado em 11/11/202003/11/2020 por Fábio de Salles · 2 Comentários

Direto na Raiz… do Dente?!

Inteligência não escolhe casa. Passeando pela web eu dei de cara com um site de sistema para clínicas odontológicas que, pasmem, aplica BI direitinho:

O post, publicado por um certo Mizael Oliveira em 6/7/20, fala sobre “análise preditiva”, que é um jargão para modelagem matemática. Ele explica o que é a tal análise, por que se deve fazê-la, dá alguns objetivos de negócio e uma visão geral de como se fazer esse tipo de estudo.

Na boa? Eu queria ter escrito este post. Descontados os erros de português (que não são poucos, nem especiais), o artigo é irretocável:

Ele respeita o público-alvo (gestores de clínicas), não se pavoneando em explicar regressões ou cluretizações bá blá blá;
É voltado para negócio, explicando como o processo impacta a vida financeira da clínica;
É concreto, pois dá exemplos de indicadores a se analisar, exemplificando as consequências;
Apesar de não entrar em detalhes de baixo nível, ele dá uma ponta para o gestor desfiar o novelo: tabule os dados em Excel e examine os gráficos das métricas. Serem humanos não conseguem extrair correlações complexas, mas conseguem descobrir visualmente o comportamento de uma variável ao longo do tempo;
Possui ritmo e encadeamento: o autor introduz o assunto por uma justificativa de negócio, explica a ideia, coloca as condições para realizar as análises e dá uma noção de como fazer. Ao longo do texto ele insere links para assuntos relacionados e termina com uma conclusão modesta e poderosa, sem bancar o sabe-tudo.

Estou lendo e relendo (e fechando os olhos para os errinhos chatos de português) e fico cada vez mais fascinado. A sugestão de legendar (ganhou pontos por evitar taggear e etiquetar) os dados é genial, tanto do ponto de vista de análise quanto pedagógico.

O cara é bom. Putsgrila, muito bom.

E por quê eu vim aqui pagar pau para um post tão fora do meu assunto? Por que não é nem um pouco fora do meu assunto! Aquilo é Business Intelligence raiz! Tomem o que o Moziel escreveu como uma lição de Inteligência de Negócios: pensem suas empresas e estratégias como o artigo, com foco em Negócio, clareza de objetivos e processos e relevância de ações.

Um dia eu vou postar coisas tão boas quanto ele. :-)

Publicado em 04/11/202028/10/2020 por Fábio de Salles · 2 Comentários

Dica: Erro de Certificado de Segurança no PDI

Eu tenho a honra de participar de um grupo de WhatsApp sobre Pentaho, no qual estão os maiores e melhores profissionais brasileiros (e alguns internacionais ;-) ) em BI e Pentaho. Como ninguém sabe tudo sobre tudo, volta e meia alguém pede uma ajuda aos “colegas”. Semana passada colocaram a questão:

Estou tentando usar um HTTP Client em uma página com HTTPS, mas está dando erro de certificado…

O erro todo é esse:

    2020/10/25 11:12:30 - Spoon - Running transformation using the Kettle execution engine
    2020/10/25 11:12:30 - Spoon - Transformation opened.
    2020/10/25 11:12:30 - Spoon - Launching transformation [transf_download_files]...
    2020/10/25 11:12:30 - Spoon - Started the transformation execution.
    2020/10/25 11:12:31 - transf_download_files - Expedindo in�cio para transformação [transf_download_files]
    2020/10/25 11:12:31 - Generate rows.0 - Finished processing (I=0, O=0, R=0, W=1, U=0, E=0)
    2020/10/25 11:12:31 - Add constants.0 - Finished processing (I=0, O=0, R=1, W=1, U=0, E=0)
    2020/10/25 11:12:31 - HTTP client.0 - ERROR (version 9.0.0.0-423, build 9.0.0.0-423 from 2020-01-31 04.53.04 by buildguy) : Because of an error, this step can't continue: 
    2020/10/25 11:12:3…

Observando o erro, o Marcello Pontes (um cara para lá de super-mega-poderoso e, não à toa, CTO da OnCase) comentou que o certificado parece ser self-signed. Para lidar com essa condição, o Marcello explicou, é preciso adicionar esse certificado ao sistema operacional que está rodando o PDI, e sugeriu olhar estes casos:

Com isso, o Marco Smanioto achou a solução do problema do nosso amigo:

Acesse o site;
Copie o certificado para o disco local;
Importe-o com o comando abaixo (Windows):
"c:\Program Files\Java\jdk1.8.0_241\bin\keytool" -alias CERT_IBAMA -import -keystore c:\Program Files\Java\jdk1.8.0_241\jre\lib\security\cacerts" -file "c:\[USURÁRIO]\cert_ibama.cer"

Se você estiver no Linux ou Mac, o programa usado é o mesmo: keytool. Apenas preste atenção em como passar os parâmetros, e tudo deve funcionar.

No caso do certificado do IBAMA (que é o site que gerou esse problema), a senha dos certificados é changeit.

Se essa dica te ajudou, não deixe de passar nos perfis do Marcello Pontes e do Marco Smanioto e deixar um muito obrigado. ;-)