Projeto de Sucesso

Eu já escrevi um pouco sobre como projetos de BI “acontecem”. Em Cruel Sucesso eu divaguei sobre a eterna sensação de fracasso que algubs projetos de BI experimentam, mesmo que ele esteja indo de vento em popa. No Todos os Caminhos Levam a um DW eu me diverti escrevendo uma história maluca sobre um projeto de BI fictício, que nasce como uma planilha Excel e cresce como mandiopã, até explodir e voltar ao começo. Mudando o foco para requisitos, eu discorri sobre Ágil e BI (De Agilidade e BI), para descaradamente anunciar meu curso de requisitos de BI para gestão ágil.

Quase sempre esses posts vem do nada, motivados por alguma situação pela qual passei. Eu estava com o novo fascículo da série Soluções Clássica quase pronto (Credit Scoring), mas aconteceu de novo: me meti num debate sobre o que era um “bom” projeto de BI.

Bom, eu tenho uma idéia do que deve ser um. Vou dividir com vocês a opinião que eu coloquei no debate, mas já sabem, né?


Disclaimer: o que você vai ler é a minha opinião, logo você não é obrigado a gostar dela ou concordar. Terei prazer em ouvir críticas ou outras opiniões, mas no final – como diz o Homer Simpson – a opinião é minha e faço com ela o que quiser, certo?


Sucesso Não Existe

Primeiro, não existe mundo perfeito. Não adianta sonharmos com a próxima grande ferramenta para resolver nossos problemas, porque o melhor que pode acontecer é resolvermos os problemas atuais e caírmos em novos. O que faz a diferença, na minha humilde opinião, é evitarmos empacar. Se empacamos, o projeto começa a fazer água, e quanto mais tempo demoramos para resolver o problema da vez, menos relevante o projeto de BI se torna, até que um dia todo mundo está se virando sozinho e o projeto é mantido vivo apenas com auxílio de aparelhos.

O que torna um projeto bom, de sucesso, então, é o fato de ele estar sempre em movimento, resolvendo cada problema como um corredor salta obstáculos: pula, corre, pula, corre, pula, corre… Eventualmente, um dia a coisa toda entra em velocidade de cruzeiro, a quantidade de erros cai substancialmente e a empresa desenvolve uma cultura de BI. Esse é o projeto de sucesso: falível, sempre precisando de alguma melhoria, mas que entrega resultados e é acreditado pela organização, sustentado pela cultura de conhecimento da empresa.


Um projeto de BI de sucesso, IMHO, é aquele que resolve um problema atrás do outro, sempre entregando um pouco mais de resultados a cada etapa, capaz de suplanta as próprias limitações e ir ao encontro das expectativas do cliente.


O Caminho para o Sucesso

Ora, dirão vocês, bolas. A definição acima é uma rematada platitude: não diz nada de realmente útil ou prático. Concordo. Vamos escrevê-la ao contrário para ver se fica mais claro:


Fracassa o projeto de BI que persistir em trilhar caminhos sem saída.


Consegui me fazer entender? Quando optamos por este ou aquele caminho, corremos o risco de enveredar por uma rua sem saída. Projetos – de qualquer tipo – que reiteradamente optam por entrar em becos sem saída acabam morrendo porque, cedo ou tarde, a organização se cansa de tanto vai-e-vem! Quer seguir no caminho para o sucesso? Esforce-se por evitar decisões ruins!

Decisões, Decisões, Decisões

Devo ter engolido o grilo falante quando era criança, pois eu sempre escuto uma voz fininha, tirando onda com a minha cara. Desta vez ela disse “Intelijumento! Se soubéssemos que decisão vai dar errado, não a tomaríamos! Dã!”

Óbvio, claro, não se questiona isso. É a própria essência do processo decisório, é a meta personificada de se fazer uma escolha: fazer a escolha certa!

Como saber se uma opção, e não a outra, é a correta? Ah, de muitas formas. Em alguns casos estamos passando pelo mesmo problema uma segunda vez. Se da primeira fizemos a escolha certa, tendemos a repeti-la, e vice-versa: deu errado antes? Vamos tentar outra coisa. Em outros casos não conhecemos, ainda, as consequências de cada caminho, mas podemos avaliá-las com o que estivar à mão – opiniões, análises estatísticas, jogar cara-ou-coroa – e escolher a que parece melhor.


Em último caso, recorra a um taxista: eles sempre sabem o que os outros deviam fazer. ;-)


O Que Funciona?

E aqui chegamos no ponto em que eu queria: o que funciona em um projeto de BI? Como montar um projeto que vai empacar menos?

Armazéns de Dados

Um bom DW é fundamental para qualquer projeto de BI de sucesso. Você pode se virar com dumps, ODFs, Data Lakes, mas esses caminhos são becos sem saída: cedo ou tarde o peso da falta de integração dos dados (dumps e Data Lakes) e das manutenções de modelo e ETL (ODFs e EDW Dimensional) vão afundar seu projeto – mesmo que todo o restante funcione.

Logo, lição número um: monte um bom projeto de DW, capaz de incorporar novas fontes num estalar de dedos e de produzir novas apresentações de dados em dois palitos. Quem acompanha meu blog já sabe o que isso significa: Data Vault.

Equipes

Ferramentas são importantes, mas não são nem metade da solução. Problemas são resolvidos por pessoas com conhecimento e competência para aplicar ferramentas, não pelas ferramentas. E outra: muito ajuda quem pouco atrapalha – gerente bom é gerente quietinho, que serve a equipe, ajudando a remover obstáculos.

Processos

Há dois grupos de processos dentro de um projeto de BI, especificamente:

  • Processos de Desenvolvimento;
  • Processos de Atendimento.

O primeiro é batata: é o processo pelo qual a equipe (parte dela, na verdade) mencionada acima produz os resultados requisitados pelo cliente.

O segundo processo é virtualmente ignorado pela comunidade de praticantes de BI: é o processo pelo qual a outra parte da equipe apóia o cliente. Sim! É o time de “vendedores”, instrutores e tutores, que trabalham com o cliente para entender o que ele precisa e transformar isso em requisitos, que serão tratados pelos desenvolvedores; que ajudam cada novo usuário a aprender a usar as ferramentas e os dados do projeto. O tutor é uma figura inexistente na literatura, mas pode ser visto como um instrutor particular, que vai resolver o problema do usuário uma primeira vez, e ajudar o usuário a repetir esses passos. Ele é diferente do instrutor, que ensina a usar o que está pronto. O tutor cria coisas novas – novas práticas, novos usos dos dados, novos requisitos.

Processo de Desenvolvimento

Não tem segredo: waterfall [bigbang][bigbang_bitly] não funciona, ponto final. A única forma de gestão de projetos que dá certo é Ágil, e neste ponto Scrum é o meu preferido.

Processo de Atendimento

De novo, não tem segredo: um grupo de vendedores (ou evangelistas/analistas de requisitos) e apoiadores (instrutores e tutores) expostos exaustivamente, com uma mensagem clara: Precisa de dados? Me ligue!. Eles interagem com o processo de desenvolvimento alimentando novas histórias no backlog (para os vendedores), com o cliente por meio de chamadas de suporte (tutores/suporte técnico) e com a empresa por meio da capacitação corporativa.

Soluções

Todo projeto de BI usa quatro tipos de soluções:

  • Apresentações;
  • Relatórios;
  • OLAP;
  • Data Mining.

As três primeiras são baseadas em ferramentas, e portanto são resolvidas pela incorporação de profissionais das respectivas ferramentas ao time. Já a última é tratada como uma conjunto de projetos-filhos e raramente é tratada in house. O normal, para soluções que envolvem Data Mining, é contratar uma empresa especializada no assunto desejado.


E os painéis? Painel não é solução de BI, é ferramenta de (tcham-tcham-tcham-tcham-tcham!) apresentação de dados (e não, não é ferramenta de análise! Quem analisa é OLAP e Data Mining.) Logo, você pode ler o primeiro item da lista acima como “dashboards“. Porém, há muitas formas de se apresentar dados e eu evitaria fechar esse escopo prematuramente, jogando tudo na vala comum “painel”.


Um bom projeto de BI precisa incorporar essas categorias, sem exceções. Não precisa oferecer tudo ao mesmo tempo, desde o dia 1, mas deve garantir que o roadmap vai contemplá-las ao longo do caminho. Como conseguir isso? Tente incluir no seu time um generalista de BI, aquele cara que entende um pouco de tudo, e sabe como os assuntos se interconectam, como amadurecem ao longo do ciclo de vida do projeto.

Se você não puder contar com um membro permanente, aceite um membro flutuante, como um coacher, por exemplo. Se não existir na empresa, procure um consultor externo. Raramente um profissional desse cresce durante um projeto de BI, e você só vai achar um na sua empresa, à sua disposição, por pura sorte.

Conclusão

Então vamos lá: um bom projeto de BI é composto por um time multi-disciplinar (especialistas em ferramentas de ETL, apresentação e exploração de dados), com uma equipe voltada para o atendimento do cliente (esqueça a idéia de ter “self-service 100%”) e outra voltada para uma linha de produção de soluções. Na entrada dessa linha está um DW baseado em Data Vault, no meio as áreas de dados para consumo e na ponta as ferramentas de uso dos dados (apresentação, relatórios e OLAP.) Pipocando aqui e ali aparecem os sub-projetos de Data Mining, tocados normalmente por consultorias externas e nascendo de necessidades pontuais. Essa visão geral pode ser melhor organizada por um generalista.

Nenhuma destas idéias é minha, e isso em parte me dá confiança nelas: Bill Inmon chama esse modelo de CIF, o inglês para Fábrica de Informações Corporativas.

Diagrama da Fábrica Corporativa de Informações.
Diagrama da Fábrica Corporativa de Informações.

Outro nome para essa abordagem é BICCBusiness Intelligence Competence Center. Veja este artigo para uma discussão mais detalhada do conceito.

Não é um BICC, mas dá uma idéia de como funciona a tal "linha de produção".
Não é um BICC, mas dá uma idéia de como funciona a tal “linha de produção”.

O restante da minha confiança nesse modelo nasce de eu ter experimentado tudo isso: Data Vault, Scrum, Data Mining, OLAP, Relatórios, equipes proficientes etc. etc. etc. Eu vi projetos de BI fracassarem ao descuidar desses fundamentos, como também vi projetos de BI que estão vivos até hoje, alguns zumbis, outros mancando, mas em operação. Se os que dão certo trazem pistas do que pode ser o mais importante, ou o que dá resultados, os que se arrastam, semi-mortos, são os mais valiosos para entender como e porque as coisas dão errado.

É isso, até a próxima. ;-)

OI vs BI – O Treinamento e o Rendimento

Há duas semanas eu coloquei minha interpretação do conflito entre as necessidades operacionais e estratégicas na exploração dos dados de uma empresa. Um dia antes de eu publicar aquele post, com ele já praticamente completo, me ligou um amigo de uma firma de grande porte, com um problema muito interessante: como medir o impacto de um treinamento sobre a empresa? Como saber que esta ou aquela iniciativa de educação corporativo deu algum resultado? Como descobrir de quanto foi esse resultado?

Que sorte! Sempre que eu começo a teorizar demais eu fico receoso de estar viajando na maionese e procuro evidências que corroborem ou neguem as minhas hipóteses, e esse caso vem bem à calhar porque demonstra claramente a diferença entre OI e BI.

Cenário

Eis o caso:


Companhia de grande porte espalhada pelo território nacional, com gestão de projetos tradicional (cascata), entendeu que precisava adotar práticas de gestão ágil. Um plano corporativo de educação foi desenhado e aplicado, e agora o alto escalão da empresa quer descobrir se deu certo, e quão certo deu.


Vale a pena notar, antes de começarmos, que essa empresa conseguiria medir o impacto do treinamento mais facilmente se tivesse estabelecido quais seriam os resultados pretendidos de antemão. Seria mais fácil se, ainda no planejamento da capacitção, tivessem declarado quais aspectos do negócio deveriam ser impactados, de que forma esperar-se-ia esse impacto, como ele seria medido etc. etc. etc. Não consigo atinar como alguém faz o [roll-out][rollout_bitly] de um projeto desse porte sem estabelecer metas, mas enfim, adiante.

Eu e meu amigo trocamos algumas idéias e no final a minha sugestão foi:


Oras, se a intenção era melhorar a gestão de projetos adotando Scrum, então basta você comparar os indicadores de qualidade de projeto antes e depois dos treinamentos (veja o comentário 1 abaixo.) Se houver uma certeza estatística de variação nesses indicadores (comentário 2), você terá uma evidência relativamente forte de que a capacitação foi a causa (comentário 3.)


Comentários:

  1. Como essa é uma das medidas a ser acompanhada em um caso desses de qualquer forma, a falha de planejamento não comprometeu a análise dos resultados – pelo menos não para esta métrica;
  2. O mundo real é dinâmico, e as coisas mudam com alguma aleatoriedade. Ao montar esse “experimento” o analista precisa se preocupar em não detectar “artefatos”, resultados que parecem legítimos e autênticos, mas no fundo não passam de um sinal transiente, ruído, problema metodológico ou puro e simples erro de medida;
  3. Um experimento precisa controlar todas as variáveis, para saber qual está causando a diferença nos resultados. Ele só pode confiar nos dados dele se, durante o período de transição, a empresa tiver levado uma vida normal, como levou em todos os anos anteriores. Se acontecer alguma coisa anormal, como uma fusão ou uma crise das brabas no seu mercado, a relação entre o treinamento (causa) e as mudanças dos indicadores de qualidades (efeito) ficará nublada.

Fazendo Ciência

Já temos material para um TCC e ainda nem chegamos aos dados ou às ferramentas! Foi esse padrão de problemas de BI que acabou a me levando à minha definição particular de BI, e há algumas semanas me levou ao caso da Inteligência Operacional (alguém por favor invente um nome melhor!!)

Meu amigo então me explicou como os projetos são registrados e tratados, e a partir daí identificamos os parâmetros que comporiam as métricas. Eis os pontos do fluxo de trabalho da empresa que são importantes para a análise:

  • Os projetos são registrados em um sistema informatizado (um software de gestão de portfólio e projetos), que coleta datas (inicial prevista/realizada, final prevista/realizada) de cada etapa (demanda, desenvolvimento, homologação e entrega;)
  • O tamanho e duração de cada projeto são estimados por meio de fórmulas e fatores históricos. A troca da técnica de gestão alterou essas fórmulas, mas o processo em si permaneceu quase inalterado: o projeto é avaliado, dimensionado e encaixado em um cronograma. A partir daí ele faz parte da vida da equipe;
  • Todos os parâmetros do projeto são editáveis a qualquer momento. Ou seja, o gerente do projeto pode alterar datas e estimativas a qualquer instante;
  • Os membros de cada equipe possuem alguma mobilidade, e podem mudar de equipe ao longo do ano;
  • Cada equipe executa vários projetos simultaneamente (um equívoco clássico.)

Os indicadores de qualidade dele são meio complicados e por isso eu vou – de novo – simplificar para facilitar a discussão.

Grosso modo, a qualidade é entendida como promessas mantidas com os clientes. Sempre que uma promessa é mantida, o projeto é avaliado como de boa qualidade. Quando uma promessa é quebrada, a avaliação é que o projeto teve baixa qualidade. E como medimos uma promessa? Simples: se prometemos entregar o projeto em certa data, com certo custo, dizemos que a promessa foi mantida se o projeto foi entregue naquela data, com aquele custo. Se não, então a promessa foi quebrada.

Partindo disso, as métricas relacionadas à qualidade de um projeto são os deltas, ou diferenças, de um parâmetro no início e no fim do projeto:

  • Delta de datas: diferença, em dias, entre uma data planejada (prometida) e a data realizada;
  • Delta de esforços: diferença, em Pontos de Função (PFs), entre o esforço planejado (prometido) e o esforço gasto no projeto (realizado.)

Evidentemente não estamos falando de projetos em andamento, mas apenas dos que já chegaram ao fim.

Um exemplo dos dados no sistema daquela empresa estão nesta tabela:

ID Projeto Data Início Prevista Data Início Realizada Data Conclusão Prevista Data Conclusão Realizada Esforço Previsto (PF) Esforço Realizado (PF)
1 22/08/15 12/09/15 17/10/15 24/10/15 92 90
2 27/04/15 07/05/15 21/05/15 25/05/15 95 86
3 14/03/15 23/03/15 04/04/15 05/04/15 48 58
4 10/08/15 08/08/15 05/09/15 04/09/15 61 69
5 13/04/15 17/04/15 25/05/15 20/05/15 100 98
6 22/05/15 18/05/15 11/07/15 15/07/15 64 60
7 22/11/15 19/11/15 09/01/16 19/01/16 27 28
8 27/02/15 31/03/15 07/04/15 08/04/15 79 69
9 01/09/15 22/09/15 03/10/15 29/09/15 36 35
10 13/01/15 17/01/15 24/02/15 09/03/15 79 89

Calculamos os deltas entre cada par de parâmetros (datas e tamanho), e chegamos a uma tabela assim:

ID Projeto Delta Início (Dias) Delta Fim (Dias) Delta Esforço (PF)
1 21 7 -2
2 10 4 -9
3 9 1 10
4 -2 -1 8
5 4 -5 -2
6 -4 4 -4
7 -3 10 1
8 32 1 -10
9 21 -4 -1
10 4 13 10

Esses números são, então, usados para calcular a média e o desvio-padrão de cada delta. Fazendo estas contas nas linhas da figura acima teríamos o seguinte resultado:

Medida Delta Início (Dias) Delta Fim (Dias) Delta Esforço (PF)
Média 9,2 3,0 0,1
Desvio Padrão 11,4 5,5 6,9

A interpretação desses resultados é feita assim:

  • Em média, um projeto começa com um atraso de 9 dias, e termina com um atraso de 3 dias;
  • Em média, a estimativa de esforço está subestimando o tamanho do projeto em 7 pontos de função;
  • Pela Desigualdade de Chebyshev, há 75% de chance de um projeto começar entre 2 dias adiantado e 20 dias atrasado (2 desvios-padrão.)

Por favor, releve qualquer erro que encontrar neste último item. Interpretar desvio-padrão em distribuições não-normais é um treco trucoso e talvez nem sequer seja uma análise apropriada. Uso-o apenas por conta de ser uma medida comum, fácil de calcular e porque vai servir para demonstrar meu ponto.

Analisando a Eficácia

Até aqui eu expliquei o problema (medir eficácia do treinamento) e como resovê-lo (comparar métricas de qualidade antes e depois.) Agora vamos aplicar essa solução a um conjunto de dados para ver como ela mostraria a eficácia – ou falta de – do treinamento. Como eu obviamente não posso usar os dados da empresa, eu gerei um conjunto de dados – e isso significa que eles conterão qualquer verdade que eu queira. Prometo não forçar a barra. ;-)

Vamos dizer que, em 2015, a empresa realizou 100 projetos, e que a capacitação ocorreu durante junho. Vamos analisar os dados agrupados mês a mês e comparar antes de junho com depois de junho. Por exemplo, pegaremos todos os projetos que tinham previsão de começar em janeiro de 2015 e calcularemos o erro de previsão para data de início de cada projeto, depois calcularemos a média de erros e finalmente o desvio-padrão dessa média. Colocaremos esses dados em uma tabela e passaremos para fevereiro, depois março e assim por diante até dezembro de 2015.

Eis a lista dos projetos que tinham previsão para começar em janeiro de 2015, tirados da minha massa de dados artificiais:

ID Projeto Data Início Prevista Delta Início
12 04/01/15 11
10 13/01/15 4
33 17/01/15 15
92 17/01/15 -9
34 18/01/15 48
72 20/01/15 4
78 22/01/15 41
88 22/01/15 6
49 26/01/15 0

A média de erros de estimativa em janeiro é (11 + 4 + 15 – 9 + 48 + 4 + 41 + 6 + 0) / 9 = 13 dias (positivo), significando que os projetos em janeiro de 2015 atrasaram, em média, 13 dias, ou quase duas semanas. O desvio padrão dessa população é de 18 dias, indicando uma dispersão relativamente grande. Ou seja, a média de atrasos pode não ter sido tão grande – quase duas semanas – mas a dispersão foi, indicando que há projetos que erram por muito mais que a média. Vê-se facilmente isso: há dois projetos que se atrasaram mais de 40 dias, enquanto que existe só um que se adiantou (projeto 92, 9 dias), e os outros ficam entre menos que uma e até duas semanas de atraso.

Se o treinamento tiver surtido efeito, então os líderes de projeto farão melhores estimativas e, consequentemente, a média e o desvio-padrão serão menores para projetos começados depois do treinamento. Se não mudarem muito, então o treinamento não causou o efeito desejado. Se tiver piorado, bom, então a capacitação foi uma catástrofe completa.

Eis as métricas para o erro da data de início de projetos (Delta Início) para o ano de 2015 inteiro (dados artificiais, não se esqueça!):

Mês Média Desvio Padrão
1 13 18
2 10 13
3 24 10
4 7 8
5 24 18
6 33 13
7 20 19
8 20 20
9 14 20
10 14 14
11 14 16
12 14 13

Como ninguém é de ferro, vamos traçar um gráfico com estes números: colocaremos a média como um histograma e o desvio-padrão como uma linha, com os meses no eixo X:

Média dos erros de estimativa do início do projeto, com os respectivos desvios-padrão.
Média dos erros de estimativa do início do projeto, com os respectivos desvios-padrão.

De cara vemos um gráfico conspicuamente aleatório: essas curvas não tem “cara” de nada. Se o treinamento tivesse funcionado, os cinco ou seis últimos pontos seriam mais parecidos entre si, com tendência a cair. Claro: se um dos impactos do Scrum é melhorar as estimativas, então o erro entre o previsto e realizado deve diminuir ao longo do tempo, até que passe a oscilar em torno de zero, significando que as promessas de datas estão sendo cumpridas com mais seriedade.

Olhando com um pouco de boa-vontade, até parece que algo aconteceu: de setembro em diante o erro teve um período de estabilidade em 14 dias. É um começo.

Se essa for uma tendência causada pelo treinamento, é razoável supor que o desvio-padrão também deve mostrar uma tendência de queda, ou no mínimo ter atingido algum patamar. Mais: se a precisão de estimativa está melhorando por causa do treinamento, então essa melhoria deve acontecer para todos os projetos criados depois de junho.

Antes de voltar ao desvio-padrão, vamos olhar a média de novo. A olho nú não notamos, no gráfico anterior, nenhuma tendência expressiva ou indubitável. Já que olhar não está ajudando, vamos partir para a Matemática: uma hipótese razoável é que se a média estiver melhorando, se estiver caindo, então uma simples regressão linear nestes pontos deve apresentar um coeficiente angular negativo (valores caem com o avanço do tempo.)

Eis o gráfico da regressão linear sobre as médias para o ano inteiro:

Regressão linear da média de erros ao longo de 2015: levemente negativa.
Regressão linear da média de erros ao longo de 2015: levemente negativa.

Ora! Levemente negativa? É pouco, mas pelo menos não é positiva! Como dizem no Mythbusters, o experimento está indo bem.

Como também não distinguimos a olho nu uma tendência no desvio-padrão, vamos aplicar-lhe a mesma técnica – regressão linear. A hipótese, de novo, é que se o treinamento tiver surtido efeito, então a dispersão dos pontos ao redor da média está caindo, o que seria evidenciado por um coeficiente angular negativo.

Regressão linear do desvio-padrão dos erros ao longo de 2015: positiva.
Regressão linear do desvio-padrão dos erros ao longo de 2015: positiva.

Positivo! Ou seja, conforme o tempo passa, o desvio-padrão tende a aumentar. Isso é ruim! Significa que as previsões estão ficando mais aleatórias, com erros cada vez mais irregulares.

Só que há um erro metodológico na conclusão acima – um artefato. O correto é aplicar uma regressão antes e outra depois do treinamento, já que em princípio devem haver comportamentos diferentes em cada lado. Ficaria assim:

Regressão linear para média e sigma (desvio-padrão) antes e depois da capacitação.
Regressão linear para média e sigma (desvio-padrão) antes e depois da capacitação.

Ah-HÁ! Agora estão claras as tendências! Ou no mínimo menos ambíguas:

  • Antes do treinamento a empresa tinha uma tendência a errar cada vez mais, mas todo mundo junto (dispersão diminuindo;)
  • Depois do treinamento, a tendência da média do erro mudou de sinal e ficou negativa, indicando que o erro de estimativa começou a diminuir – e a dispersão passou a diminuir mais rapidamente.

E, finalmente, a mágica: resolvendo a equação para Média < 1 e Sigma < 1 descobrimos quantos meses até a empresa cair para um erro de estimativa menor que um dia.

Erro médio:

    Erro Médio em Dias = -1,35 * meses + 28,81 dias
    1 > -1,35 * meses + 28,81
    1 - 28,81 > -1,35 meses
    1,35 meses > 27,91
    meses > 20,7

Ou seja, contando de julho de 2015, se nada mais mudasse e tudo seguisse no mesmo ritmo, a empresa atingiria erro menor que um dia mais ou menos 21 meses depois, em abril de 2017. E coisa de um mês depois, em maio/17, atingiria uma dispersão menor que um dia:

    Desvio Padrão em Dias = -1,35 * meses + 29,91 dias
    1 > -1,35 * meses + 29,91
    1,35 meses > 28,91
    meses > 21,5

Agora Sim: OI vs. BI

Usando os dados disponíveis no sistema transacional da empresa pudemos avaliar a qualidade dos projetos antes e depois da aplicação do treinamento.

Suponha que aquele primeiro gráfico vá parar em um painel, e fique à disposição da diretoria. No primeiro dia os diretores olham o painel e está lá o gráfico:

Média dos erros de estimativa do início do projeto, com os respectivos desvios-padrão.
Média dos erros de estimativa do início do projeto, com os respectivos desvios-padrão.

Justamente por não ter forma nenhuma é que podemos entender que nada mudou – as coisas não parecem melhores depois do treinamento. Alarmados, eles começam a cutucar todo mundo: como assim o treinamento não surtiu efeito?

Se a análise tivesse sido feita comparando-se as tendências antes e depois, os diretores veriam imediatamente que surtiu efeito, e quanto. Mas os dados não foram analisados, eles foram colocados em um gráfico e contemplados a olho nu, meramente.

Bom, não dá outra, no dia seguinte o gráfico está assim:

Inclinações dos indicadores no dia seguinte: negativa!
Inclinações dos indicadores no dia seguinte: negativa!

Lembram-se que o sistema de gestão daquela empresa não trava nada? Lá no começo está anotado:

  • Todos os parâmetros do projeto são editáveis a qualquer momento. Ou seja, o gerente do projeto pode alterar datas e estimativas a qualquer instante.

Bastou um dia de rádio-corredor e os dados, que passaram um ano estáticos, mudaram como se nunca houvessem sido diferentes.

E tem mais! Ao longo de um projeto, um gerente super-zeloso pode entender que certos ajustes são necessários e – legitimamente – realizar esses ajustes. Como é um sistema transacional, e tipicamente esse tipo de sistema não arquiva histórico, uma vez que os parâmetros tenham sido ajustados, os valores anteriores se perderam! Logo, de um dia para outro, literalmente, o projeto passou de muito atrasado para pouco atrasado, de tamanho grande para tamanho médio, ou qualquer outra mudança.

Pense: se os dados que rolam pela organização são maleáveis, e eles deveriam refletir a realidade, então a realidade é maleável e muda ao sabor das opiniões! Por puro e simples contato com a dura realidade sabemos que isso não é verdade!

Note que eu não estou afirmando que se alguém puder forjar fatos para ficar melhor na fita, esse alguém adulterá-los. Não estou afirmando que olhar dados operacionais, correntes, é um risco porque o caráter humano, falho, de todos nós fatalmente vai nos levar a fraudar os dados. Longe disso!

Estou afirmando que, feita sobre dados vivos, a análise certeira de hoje vira o mico corporativo de amanhã e a falha estratégica de depois de amanhã. (Nesse ritmo, a organização vai à falência até a semana que vem.)

Primeira Diferença: Técnica de Análise

Nós começamos com uma tabela listando os vários parâmetros de todos os projetos de um ano inteiro, e terminamos com quatro funções lineares. Repare que, até o final, olhar o gráfico não contou nenhuma história. Ou melhor, contou sim: que não dava para entender nada só olhando. Contrário ao mantra das ferramentas de visualização de dados, que formam o miolo da Inteligência Operacional, “ver” os dados não criou nenhum valor. E quando os dados foram divididos em dois períodos, quando pudemos acreditar que havia uma inflexão na tendência dos indicadores, foi necessário aplicar uma regressão para poder extrair alguma conclusão melhor que “o treinamento surtiu efeito”. Responder quanto de melhoria foi obtida e poder estimar quanto tempo até zerar os erros partiu de uma análise trivial, mas nem um pouco gráfica.

Em que pese o fato de os dados terem sido gerados aleatoriamente (o resultado acima foi uma feliz coincidência, eu não entrei nada manualmente!), a realidade não é diferente. Na verdade, é ainda pior: eu isolei o problema em UMA variável (data de início do projeto) e DUAS métricas. Imagine analisar um problema com três ou quatro variáveis, cada qual com meia-dúzia de métricas? Só a estatística descritiva univariada já cobre isso: média, mediana, desvio-padrão, variância, moda e esperança.


Em última análise, nossa capacidade está limitada pela capacidade das ferramentas. Escolher a ferramenta adequada e saber manuseá-la representam metade da solução de qualquer problema.


Segunda Diferença: OLTP <> Histórico

E outra: demos sorte que o sistema dele registra esse monte de parâmetros. E se fosse um outro problema, um em que o sistema não registre esses milestones? Pense em um sistema que controla o estado de – digamos – um ticket de atendimento, mas não registra as datas dos estágios pelo qual o ticket passou. Como é que poderíamos saber se algum assunto vai-e-volta, se tudo que podemos olhar é o aqui e agora, se não podemos ver o histórico das mudanças?


Sem dados históricos não há análises estratégicas. Como não é parte da responsabilidade de sistemas transacionais acumular histórico, não podemos confiar nos dados vivos para conduzir análises estratégicas.


Terceira Diferença: Consistência

Neste exemplo, ao olharmos os dados de um ano para trás, estamos vendo o que aconteceu naquela época? Ou estamos vendo o resultado de ajustes feitos na melhor das boas intenções? Os dados mudaram ao longo do tempo?


As coisas mudam, e olhar dados vivos trazem riscos inerentes à esse fato. Não se pode analisar dados dinâmicos mais do que podemos mirar em um alvo que se desloca erraticamente: se não temos certeza do caminho que ele percorre, só vamos acertá-lo por pura sorte.


Conclusão

Uma organização faz perguntas sobre si própria continuamente. Ora é preciso saber o que está acontecendo agora, neste instante, ora é preciso entender como as coisas estão funcionando, aonde se está indo. O primeiro caso é a essência da “Inteligência Operacional”, enquanto que o segundo é “Inteligência de Negócios”. A importância em se distinguir as duas coisas resume-se aqui:

  • Desenhar um gráfico com pontos pode contar uma história invisível aos olhos, mas visível sob o microscópio da Matemática e da Estatística: aprenda a escolher a ferramenta adequada e a manuseá-la, ou você poderá acabar com as mãos vazias na melhor das hipóteses. Na pior, pode ser levado a acreditar em algo incorreto;
  • Aqueles que ignoram o passado estão condenados a repeti-lo: não se fie nos sistemas transacionais para guardar o histórico de dados, pois essa não é a função deles. Cuide você de arquivar os dados importantes;
  • As coisas mudam, os dados mudam. Analisar dados vivos, dinâmicos, é garantia de não se poder garantir nada;

Retomando o post que deu origem à série, olhemos a tabela que separava OI de BI:

Aspecto Estratégico Operacional
Ciclo de vida dos dados Histórico Vivos, quase tempo-real
Origem dos dados Armazém de Dados Sistema de origem
Velocidade de manuseio dos dados Não é crítica Crítica
Funcionalidade mais importante Data Mining Formas de visualizar os dados

Em qual coluna se encaixa o caso mostrado? Vejamos:

  • Ciclo de vida dos dados: o estudo dos indicadores de qualidade consumiu dados históricos, que idealmente deveriam ser estáveis;
  • Origem dos dados: por sorte o transacional arquivava os atributos importantes, como as datas de cada etapa do projeto, e as estimativas iniciais. Sem isso, a única forma de se dispor desses dados teria sido um DW;
  • Velocidade de manuseio dos dados: irrelevante, ou não-crítica, pois meu amigo tinha alguns dias para conseguir uma resposta, e o volume de dados é pequeno;
  • Funcionalidade mais importante: descrição estatística dos dados, o que não chega a ser Data Mining, mas é bem mais que só um gráfico. A mera visualização gerou apenas dúvidas.

Logo, esse caso clasifica-se (pela minha régua, claro!) como um caso de BI e não de OI.

Tente imaginar em que situação esse caso teria sido classificado como OI:

  • Se os dados necessários fossem os dados do OLTP, vivos;
  • Se quiséssemos comparar valores ou percentuais do total – ideal para ser feito por gráficos;
  • Se o volume de dados afetasse negativamente a navegação deles, deixando o processo de análise lento para uma demanda de resposta rápida.

Perguntas da cepa “estamos no segundo dia de treinamento; a frequência está boa? Tem muita gente faltando?” e assim por diante, se encaixam mais no paradigma de dados operacionais. Para começo de conversa, descartaríamos um DW logo de cara.

Espero que tenha deixado tudo mais claro.

Até a próxima! ;-)

De Agilidade e BI

Como capturar e documentar requisitos para projetos de BI gerenciados por métodos ágeis?

Ágil, Não Rápido

Quando Kent Beck, Martin Fowler, Ken Schwaber, Jeff Sutherland e toda patota declararam o Manifesto Ágil, eles não estavam preocupados com a velocidade do desenvolvendo de software, mas sim com a dificuldade cada vez maior em escrever bons produtos. Até início dos anos 2000, o paradigma de desenvolvimento de software era espelhado no paradigma de construção civil: ninguém assentava um tijolo até tudo estar absolutamente calculado e verificado.

É o mesmo que dizer que Romeu e Julieta foi escrito de uma vez, em algumas semanas, depois de Shakespeare passar alguns anos detalhando os personagens e a história. Não que eu seja especialista no processo criativo shakespeareano, longe disso! O que eu quero dizer é que construir paredes e escrever algo são atividades muito diferentes. Meu melhor exemplo são meus posts como exemplo: eu reescrevo cada post – inteirinho – pelo menos uma vez.

Imagine construir e derrubar uma parede até ela ficar perfeita. Imaginou? Bom, vá além: imagine construir e demolir uma casa inteira, até ficar como você quer. Ou pior: construir e vê-la desabar sobre o próprio peso vezes sem conta, até acertar a posição das vigas e conseguir que a centésima vigésima terceira encarnação da casa não caia só porque alguém bateu a porta da frente com força.

É ruim, hein! :-P


O cerne do conceito de desenvolvimento ágil não é a velocidade, mas a melhoria contínua.


Por isso no manifesto eles dizem que vêem valor em “processos, ferramentas, documentos etc.”, mas que vêem ainda mais valor em “indivíduos, colaboração, resultados etc.” Está lá, com todas as letras: trabalhar para obter um bom resultado é o que interessa. E não adianta trabalhar a toque de caixa, fazendo tudo nas coxas, só para chegar rapidamente ao final. O que interessa é avançar, melhorando continuamente e sem comprometer o futuro com decisões apressadas ou serviço mal-feito.

Inteligência de Negócios Ágil?

E como você trabalha melhoria contínua em Inteligência de Negócios? Como casamos BI com Ágil?

Eu venho estudando essa questão, meio que sem querer, já há alguns anos. Como sempre, tudo começou porque eu queria aplicar Scrum de qualquer maneira, custasse o que custasse! Eu havia acabado de ler Agile Project Management with Scrum, do Ken Schwaber, e estava louco para pôr em prática aquelas idéias. Era tudo tão simples, tão elegante, tão poderoso que eu precisava tocar um projeto com Scrum.

Tive uma sorte danada: havia acabado de receber um projeto e ele servia como uma luva em todas aquelas idéias. Aprendi tudo de Scrum, botei em prática, e o projeto funcionou muito bem.

Quer dizer, praticamente. Algums detalhes não deram muito certo:

  1. Automação de Testes: como você testa um ETL ou um relatório, continuamente? Como montar testes de regressão em um modelo dimensional?
  2. Histórias: como eu transformo a necessidade do cliente em uma história, e depois mapeio isso nas atividades típicas de um projeto de BI, como desenhar o modelo dimensional, desenvolver o ETL e construir um relatório ou painel?
  3. Refactoring: sério, refatorar um banco de dados?? Freaking how??

Ainda não encontrei uma resposta satisfatória para os testes. Já refatorar bases de dados, por incrível que pareça, é um problema que já foi resolvido: o livro Refactoring Databases disseca o assunto completamente. Estou lendo esse livro agora mas, pelo pouco que eu já li, posso dizer que ele é essencial para qualquer DBA que seja membro de uma equipe de desenvolvimento de software – ou BI – contemporânea. Leia!

Senta que Lá Vem História…

O que nos deixa no assunto deste post: levantamento de requisitos ágeis para Inteligência de Negócios.

Existem várias técnicas de levantamento de requisitos para projetos ágeis. A mais famosa, provavelmente, é o conceito de História: o cliente e a equipe de desenvolvimento constroem uma narrativa que incorpora a necessidade do cliente na forma de uma ação, de uma história. Por exemplo: “como gerente de vendas, eu quero poder ver as vendas deste mês dia-a-dia, quebradas por vendedor, produto e cliente”.

Essa foi a minha abordagem para aquele projeto. Funcionou, no sentido em que permitiu organizar o trabalho, quebrá-lo em partes e controlar a entrega. Por outro lado criou outros problemas. Exemplo? O tamanho, para começar. Quem já está acostumado com projetos de BI vê imediatamente que o cliente precisa de 1) um cubo OLAP com três dimensões, de vários níveis cada, ligadas a uma fato, tudo isso carregado por 2) um processo de ETL que leva os dados da origem a um 3) modelo dimensiona. Ou seja, uma única história dá origem a um Data Mart inteiro! É muito grande!

Outro problema é o que a própria história conta: há tantas formas de construir a apresentar esses dados que umas poucas linhas de texto é um canal muito “estreito” para enfeixar tantas possibilidades. Como adicionar detalhes? Escrevendo mais? E como fazer o cliente entender o que foi prometido e o que está sendo desenvolvido?

Eu cheguei a escrever sobre um problema relacionado à essa imprecisão: Cruel Sucesso. Para te poupar do esforço de lê-lo, resumidamente, quando você acerta na mosca, o cliente muda a demanda. Depois de algumas iterações acontecendo isso, o cliente desenvolve a sensação contrária, e passa a acreditar que o projeto nunca acerta! E, na minha opinião, isso acontece porque ele só entende claramente o que pediu quando recebe. E é neste momento que ele reavalia sua necessidade a refina. Entendeu? Não? Bom, então leia aquele post antes de continuar, hehe. :-)

Requisitos Para Gestão Ágil

Enquanto eu batia cabeça com isso eu tomei contato com outra técnica fantástica: Data Vault. Se você acompanha meu blog sabe o quanto eu sou apaixonado por DV.

De novo, louco para construir um DV e testar todas aquelas idéias, eu consegui um projeto perfeito. Não apenas pude aplicar Data Vault, mas o fiz com Scrum, o que foi duplamente satisfatório aliás. O resultado desta experiência virou o Primeiro Curso de Data Vault do Brasil. Estou evoluindo aquele material e em 2016 eu espero lançar uma versão definitiva, completa.

E foi deste material que eu puxei uma coisa muito interessante: uma técnica para levantamento de requisitos para projetos de BI. Não apenas qualquer projeto de BI, mas principalmente projetos gerenciados com alguma técnica Ágil, como Scrum ou Kanban.

Funciona assim: ao invés de escrevermos uma história, e depois quebrá-la em modelo de dados, ETL, apresentação etc., começamos anotando cruamente o que o cliente diz que precisa. Essas anotações são transformadas em protótipos que são revisados pelo cliente e ajustadas e revisadas e ajustadas etc. etc. … Em algum momento o cliente vai se dar por satisfeito e o último protótipo vira o requisito! Daí o resto é história: montar um documento que combine protótipo e a demanda do cliente em uma forma que ajuda a equipe de desenvolvimento e comunica claramente a expectativa do cliente.

150827_DAEBI_004

4Shot Agile BI com Pentaho

Eu contei para vocês que eu comprei um apartamento? ;-) Agora eu tenho uma dívida de quarenta anos, e preciso fazer caixa. Por isso, quando uns meses atrás a 4Linux me apresentou o conceito de Shot e me perguntou se eu tinha alguma proposta, na hora eu apresentei a idéia acima.

150827_DAEBI_001Um Shot é um curso de curta duração (tipicamente um dia), focado sobre um único assunto e, em geral, voltado para um público específico. A 4Linux é, com certeza, o maior fornecedor de treinamentos em Software Livre e eu tenho a honra de ter produzido o treinamento Pentaho que eles oferecem (e de vez em quando ministro uma turma.)

Eu produzi um vídeo explicando melhor a idéia.

150827_DAEBI_002

Semana que vem, dias 1, 2 e 3 de Setembro de 2015, ocorrerá a primeira turma deste Shot. As vagas são muito limitadas porque as turmas são propositalmente pequenas, de no máximo oito alunos. A idéia é oferecer um curso reforçado, intenso, e uma turma maior não permitiria isso. Também não é um assunto para principiantes. Não é nada esotérico, mas se esse vai ser seu primeiro curso em BI, bom, se prepare. ;-)

Máquina virtual pré-fabricada, pronta para os exercícios.
Máquina virtual pré-fabricada, pronta para os exercícios.

O curso inclui apostila e dois DVDs, com uma máquina virtual preparada para os exercícios, os exercícios resolvidos, templates, SQLs, backup de bancos e cópias de todos os softwares usados e mais alguns. E apesar de a propaganda dizer que ele é 80% prático, eu acabei fazendo um pouco mais – você não vai ter folga! Mas nem tudo será suor e teclados massacrados: como serão turmas presenciais, teremos o famoso coffee-break da 4Linux. :-)


Os leitores do blog que desejarem se inscrever terão um preço especial: R$199,00 contra R$299,00 do site. Para isso você precisa entrar em contato diretamente com Daniela Araújo (e-mail daniela.araujo@4linux.com.br) e contar que descobriu sobre o Shot no blog Geek BI.


Compre! :-D

Inteligência de Negócios à Serviço da Educação

Mês passado (julho/2015) a Editora Packt conduziu uma pesquisa entre profissionais de TI para tentar entender como o conhecimento e habilidades desses profissionais influenciaram o sucesso em suas carreiras e seus salários. Receberam mais de 20.000 participações.


Isso é tanta gente que bateu todas as outras pesquisas do genêro. Para você ter uma idéia, se pegarmos só os respondentes dos Estados Unidos já dá mais participantes que a mesma pesquisa feita pela StackOverflow algum tempo antes. Uau!


E o que a Packt fez com isso? Lembre-se: eles não são uma instituição de caridade, eles querem é vender mais. ;-) Bom, eles analisaram todos esses dados e chegaram à some fascinating findings. Baseado nas conclusões das pesquisas, às quais você pode ter acesso por este link, a Packt montou pacotes de livros pensados para trazer ao leitor justamente os conhecimentos que podem gerar maior vantagem profissional nos próximos anos!

Falassério!!! Genial!!!

A empresa usa seu alcançe com leitores de todos os países e ramos da TI para pesquisar o que está fazendo diferença na vida deles. Daí estuda esses dados e monta uma campanha para ajudar seus leitores a escolher seus livros!

“Ah, Fábio, como você é inocente! Eles estão fazendo isso para ganhar mais dinheiro!”

SIM!! Ou você acha que o Pão de Açúcar faz promoção de queijos e vinhos apenas para o nosso deleite? Pense: nós, leitores, estamos ganhando com o conhecimento deles, já que nada nos impede de buscar livros de outras editoras.

A idéia não seria ruim, até, se não fosse pela segunda metade do pacote: neste link você tem acesso aos pacotes que eles montaram para vários tipos de profissionais. Por exemplo:

Aprendendo e dominando processamento de dados com Hadoop ("BigData".)
Aprendendo e dominando processamento de dados com Hadoop (“BigData”.)
Data Mining ("Data Science" - pfff, buzzwords...) com R e Python, trilha completa.
Data Mining (“Data Science” – pfff, buzzwords…) com R e Python, trilha completa.
Hoje nada é completo sem "mobile": eis um pacote para desenvolvimento Android.
Hoje nada é completo sem “mobile”: eis um pacote para desenvolvimento Android.

E como isso se isso não fosse o bastante, a Packt deu um passo além: se você quiser montar um pacote específico, que você entenda como útil na sua carreira, você pode: escolhendo qualquer conjunto de 5 livros, você paga apenas US$25,00 por eles!!

Falassério, Parte 2!!!

Ah, você não achou 5 livros? Quer um ou dois? Ou apenas um vídeo para completar seus conhecimentos? Fácil: até o final da promoção, que é em 7 de agosto, todos os livros e vídeos estão por US$10,00 cada!

É isso. Quer saber o que nossos colegas de TI estudam, e que conhecimentos eles acham que vai ser importante nos próximos anos? Acesse a pesquisa. Acha que precisa estudar um pouco mais, sobre alguma coisa? Até 7 de agosto, neste link você pode montar um pacote de até 5 livros por US$25,00 – ou comprar qualquer livro ou vídeo por US$10,00.


E qual é o meu interesse em fazer essa pusta propaganda no meu blog?

  1. Meu amigo da Packt me pediu ajuda para divulgar a campanha. Só o afago no meu ego já seria o bastante (a Packt acha que eu sou importante? Uau!)
  2. Francamente, é uma promoção boa demais para não divulgar. Em um país com tanta necessidade de conhecimento e educação, qualquer oportunidade de aprender a um custo menor é muito valiosa para manter segredo.

Normalmente eu ganho um livro ou dois por ajudar a divulgar uma promoção ou fazer uma resenha. Só que desta vez isso não vai me fazer diferença: eu já ganhei tantos livros em troca de resenhas e divulgação que eu simplesmente não tenho mais o que pedir…

Boas compras! :-)

Instalando A Base Beltrano S/A

Em breve publicarei um post sobre o uso de metamodelos como fontes de dados no PRD. O post de hoje é para ajudá-lo a se preparar, e não traz nada de novo: como instalar Postgres e as bases da Beltrano S/A.

Esse post é uma atualização das instruções de instalação da base de treinamento Beltrano S/A. Você pode seguir este link para conhecer a Beltrano e como ela foi pensada. O texto a seguir apareceu pela primeira no Capítulo 3 do livro Pentaho na Prática.

Instalando e Configurando um Postgres

Para usar as bases OLTP e DW da Beltrano você precisa ter um Postgres instalado e funcionando, bem como conhecer o usuário root e sua senha. Se você já tem um, clique aqui e pule para etapa seguinte. Caso contrário, siga os passos descritos nesta seção para instalar um Postgres em sua máquina.

Se você usa Windows, continue lendo. Se usa Linux, pule para a próxima seção.

Instalar PostgreSQL no Windows XP

As instruções de instalação no Windows estão disponíveis em um e-Book gratuito.

Capa do e-Book Instalando Postrgres 9.0 no Windows.
Capa do e-Book Instalando Postrgres 9.0 no Windows.

Você pode usar o Calibre ou qualquer outro programa leitor de e-Pubs para lê-lo.


Eu tinha uma licença do WindowsXP e resolvi aproveitá-la para fazer esse tutorial. Pelo mesmo motivo (falta de licença) não existe tutorial para Windows mais novos. Entretanto, a uniformidade entre as versões do Windows deve ser o bastante para que você possa seguir praticamente 100% do tutorial em qualquer versão mais recente do Windows.


Instalar PostgreSQL no Linux

Linux é um sistema operacional com n sabores – distribuições – e é virtualmente impossível cobrir todas. Por isso eu não fiz um livro mostrando como instalar Postgres em Linux, mas fiz para Windows. Vamos ver um passo-a-passo para Debian/Ubuntu. Se não for o suficiente, acesse a página de instalação do PostgreSQL para outros Linuxes.

Esse procedimento funciona em qualquer derivado Debian (como o Ubuntu). Existem opções gráficas, mas a linha de comando é universal e relativamente simples.

  1. Abra um terminal de comandos;
  2. Digite,seguido de \[ENTER\]:
    sudo apt-get install postgresql
    
  3. Se perguntado, responda Y ou S. Assim que a instalação acabar você terá um banco instalado, configurado e em operação, mas vazio;Em seguida, altere a senha do usuário-padrão, postgres, para algo fácil de lembrar (e potencialmente inseguro), como postgres. Faça assim:
  4. Entre na conta de usuário Postgres do sistema operacional (aquele que executa o programa do servidor:)
    sudo su – postgres
    

    Esse usuário do sistema operacional (postgres) tem permissão para acessar o servidor PostgreSQL diretamente. Ele é criado pelo processo de instalação do banco e recebe uma senha aleatória, que nunca é mostrada ao usuário final. Como não sabemos nem a senha do usuário nem a senha do root do banco, precisamos fazer login na conta de sistema operacional postgres com sudo. Você até pode modificar a senha desse usuário, mas não há razão para isso.

  5. Agora entre no programa de interface de linha de comando do PostgreSQL, o PSQL, digitando o comando:
    psql
    
  6. Deve aparecer um prompt, esperando comandos, parecido com isso:
    postgres=#
    

    Pronto, você está no prompt do PSQL. Agora altere a senha do usuário do banco (que é diferente do usuário do sistema operacional no qual o banco é executado):

    ALTER ROLE postgres with password 'postgres';
    

    ROLE é o usuário, e entre as aspas simples está a nova senha – postgres. Se deu tudo certo, deve aparece uma mensagem como:

    ALTER ROLE
    postgres=#
    
  7. Saia do PSQL, digitando \q seguido por \[ENTER\];
  8. Faça logout da conta postgres, digitando exit seguido por \[ENTER\].

Agora você tem um servidor PostgreSQL instalado e pronto para ser usado. Sempre que precisar acessá-lo para algo, comande:

    psql postgres -U postgres

Se ele pedir senha, ela será postgres.

Fazer o Postgres Aceitar Qualquer Conexão


Atenção! O procedimento abaixo vai abrir seu PostgreSQL para acesso por qualquer um na mesma rede em que você está! Lembre-se disso ao criar bancos e gravar dados nele. Essa configuração é útil para desenvolvimento, testes, treinamento, mas é perigosa para ambientes de produção ou no caso de dados sensíveis.


  1. Volte à conta do postgres. Em um terminal, entre novamente:
    sudo su – postgres
    
  2. Abra o arquivo de configuração pg_hba.conf para edição com seu editor de textos favorito. Nosso exemplo usa o nano:
    nano etc/postgresql/X.Y/main/pg_hba.conf
    
  3. Vá até o final do arquivo e insira a seguinte linha:
    host all all 0.0.0.0/0 md5
    

    Isso vai fazer com que o servidor aceite conexões de qualquer IP, desde que forneça usuário (postgres) e senha (postgres) para qualquer banco;

  4. Salve o arquivo (nano: CTRL+O) e depois saia do editor (nano: CTRL+X);
  5. Agora edite o arquivo de configuração do servidor postgres.conf:
    nano etc/postgresql/X.Y/main/postgresql.conf
    
  6. Role o arquivo até encontrar a linha com listen_addresses;
  7. Altere localhost para *. Isso vai fazer com que o servidor passe a ouvir conexões de qualquer IP;
  8. Salve o arquivo (nano: CTRL+O) e depois saia do editor (nano: CTRL+X);
  9. Re-inicie o servidor:
    /etc/init.d/postgresql restart
    
  10. Finalmente saia da conta de usuário postgres:
    exit
    

A partir de agora qualquer cliente PostgreSQL pode se conectar ao seu servidor.


Dica: se você for adotar o PostgreSQL como banco para sua empresa, contrate suporte especializado e treine pelo menos um DBA. Você faria isso com Oracle e MS SQL Server, porque vai deixar de fazer com PostgreSQL (ou MySQL)?


Instalando as Bases

Primeiro, instale as bases:

  1. Baixe-as destes links (clique nos nomes dos bancos:)
    1. Beltrano (OLTP) (arquivo beltrano_oltp_10k_pedidos.backup.zip;)
    2. Beltrano DW (arquivo beltrano_dw.backup.zip;)
    3. Beltrano Log (arquivo beltrano_log.backup.zip;)
  2. Descompacte-as em um diretório conhecido e sem espaços no path. Por exemplo, C:\ no Windows e /opt/beltrano no Linux.
  3. Se você usa Linux, não se esqueça de mudar as permissões dos arquivos (já descompactados) com um chmod 777 *.backup.Usando o PSQL (interface de linha de comando do Postgres), conecte-se ao servidor, crie um banco vazio para cada base e restaure-as neles:
  4. Rode o PSQL:
    1. Windows: rode o programa SQL Shell, que fica em Menu Iniciar -> Programas -> Posgtres <Versão> -> SQL Shell (psql);
    2. Linux: abra um terminal e comande psql -U postgres. Isso vai conectar você ao servidor localhost, porta 5432, banco postgres, com usuário postgres;
  5. Crie o novo banco de dados, comandando:
    1. Beltrano OLTP: CREATE DATABASE beltrano; (inclua o ponto-e-vírgula!);
    2. Beltrano DW: CREATE DATABASE beltrano_dw; (não se esqueça do ponto-e-vírgula!);
    3. Beltrano Log: CREATE DATABASE beltrano_log; (já sabe, não? Ponto-e-vírgula incluso!);
  6. Conecte-se a cada uma das bases recém-criadas e restaure-as. Ou seja, ainda no psql, comande (pressionando \[ENTER\] ao final de cada linha:)
    \c beltrano
    \i /opt/beltrano_oltp_10k_pedidos.backup
    \c beltrano_dw
    \i /opt/beltrano_dw.backup
    \c beltrano_log
    \i /opt/beltrano_log.backup
    

    Cada um destes comandos terá uma resposta. Os comandos \i efetivamente populam o banco, processando cada linha do script, e por isso resulta em uma lista maior de respostas – uma para cada comando do arquivo de backup.


Esse script é para Linux!


Windows: entre os mesmos comandos acima, mas use o caminho c:\, com barra contrária, ao referenciar o arquivo. Por exemplo:

  • \i c:\beltrano_oltp_10K_pedidos.backup
  • \i c:\beltrano_dw.backup
  • \i c:\beltrano_log.backup

Voilà! Bases instaladas e prontas para os exercícios. Você pode comprovar usando o pgAdmin para examinar os bancos e verificar o conteúdo das tabelas.

Bases restauradas (pgAdmin III do Windows.)
Bases restauradas (pgAdmin III do Windows.)

Primeiro Curso de Data Vault no Brasil

Bom, notícias primeiro:

Em setembro de 2014 a IT4Biz aplicou a primeira turma de Data Vault com Pentaho do Brasil (e, considerando-se o “com Pentaho”, talvez até do mundo.) O cliente da IT4Biz mostrou-se contente com o resultado e comentou que DV tornou-se uma peça importante de sua estratégia, e que vai seguir para implementação de um projeto inicial.

Estou dando a notícia porque o curso foi desenhado e ministrado por mim mesmo. O cliente da IT4Biz é uma empresa brasileira de grande porte. Ela não é a filial de uma multinacional no Brasil, mas uma empresa do Brasil, que aliás é uma multinacional. Ou seja, não é uma empresa de fundo-de-quinta, uma farmácia ou uma padaria.É uma empresa grande, complexa e com um número enorme de variáveis e fatores.

Apesar de o curso ter ocorrido há quase dois meses, eu estava esperando para ver como o material seria usado – ou se ao menos seria usado. Em outras palavras, eu esperei para saber o real impacto que esse novo conhecimento teve para eles:

(…) avançamos bastante. Só pra ter uma ideia, conseguimos chegar no modelo dimensional com um dia de trabalho (+/- 8h), gerando o DV, fatos, dimensões e o cubo preliminar. É claro que precisa de ajustes no modelo. (…)

Em outras palavras: a partir do conteúdo e do material do curso (que inclui templates de transformações, documentos de modelagem e documentação de requisitos etc.), eles conseguiram passar a primeira etapa do projeto em um dia. Isso mesmo: um DW começado em UM DIA, já com uma estrela, com dimensões e tudo. Dê um desconto de duas semanas para revisar e finalizar e me diga se é ou não algo muito poderoso. ;-)

Deep Impact

Bom, como dizia o filme, teve um impacto profundo: entrou como uma dos componentes da arquitetura. Não apenas adotaram, mas estenderam o que foi passado. Claro que eram alunos excepcionalmente competentes e inteligentes, mas não teriam feito nada se o assunto não fosse relevante para eles.

Eu entrei como professor freelancer e como o cliente não é meu, eu não posso dar nenhum outro detalhe. Se minha palavra vale, nesse tempo todo o cliente aplicou o material do curso (que inclui templates de transformações, documentos de modelagem e documentação de requisitos etc.) com maestria e obteve os resultados que buscava.

Se o mercado demandar, talvez a IT4Biz abra outras turmas. Se você tem interesse, manifeste-se para eles: http://www.it4biz.com.br/.

Packt Pub. Celebrates 10 Years with US$10 Campaign!

Packt Publisher, the “We got IT covered” company, is celebrating 10 years this July 2014 with an offering on their site: every e-book and video on sale for US$10,00!

Packt slogan sounds like a weak pun, but in fact summarizes the truth: Think about a software – there are big chances Pack has a book on it. Not software, but hardware? Ok, they have it too! What about a supercluster with a thousand Raspberry Pis for a weekend project? (They have so many titles on so many things it is kind of ludicrous… Really! They’ve got a title blending Minecraft – yeah, the game – with hardware!!)

So, if you are in need of learning something about a software (be it Free or Proprietary) or hardware, give a look at Packt until tomorrow (July 5) to take advantage of a good offer. I bet you won’t regret it!

Packt Comemora 10 Anos com tudo a US$10!

Em julho a Editora Packt  completou 10 anos e lançou uma campanha: todos vídeos e e-books no site por US$10,00!

Imagine que você precisa aprender algo novo – seja por trabalho, por interesse particular, por qualquer motivo. Como fazemos hoje? Google! Tutorial, Passo-a-Passo, blogs, fóruns etc. etc. etc.

Bom, a Packt oferece centenas de livros para novatos e profissionais que precisem aprender algo sobre uma determinada tecnologia. Não é brincadeira: valem por um curso! Quer exemplos?

  • Vídeo Building a Data Mart with PDI: em um conjunto de vídeos com excelente qualidade de som e imagem você aprende como montar um Data Mart dimensional. Autor? Ninguém menos que o Diethard Steiner, um dos grandes profissionais Pentaho no mundo;
  • Livro Pentaho Data Integration Cookbook (2nd. Ed): a arca do tesouro do PDI!! Imperdível!
  • Livro Hadoop Beginner’s Guide: eu consegui montar um servidor Hadoop seguindo as orientações desse livro, que não apenas é muito bom, mas é gostoso de ler!
  • Livro HP Vertica Essentials: de novo, eu saí do zero e completei um servidor Vertica sozinho, sem precisar de Internet nem nada! Outra pérola!
  • Livro QlikView 11 for Developers: tudo que você sempre quis saber sobre o QV, mas não tinha na Internet! Finalmente consegui entender como o QV funciona (e desmistificar aquele “qualquer data, de qualquer lugar”! QV dá tanto trabalho quanto qualquer ferramenta!)
  • Livro Bonita Open Solution 5.x Essentials: outro caso de muita informação de qualidade e valor.
  • Data Mining (RapidMiner, R), Zabbix, Postgres, MySQL, Minecraft (!!!), Apache, Oracle, SQL Server, Closure, HTML5, PenTesting, jQuery, Spark, Lumion 3D, Raspberry Pi, OpenStack …

Putz… Acho que faz tempo que não leio nada que não venha da Packt (e olha que eu sou fã da Wiley!)

Enfim, você está trabalhando com TI? Precisa aprender a mexer com alguma tecnologia (hardware, software – livre _E_ proprietário), ou precisa melhorar? Está curioso e quer brincar com robôs ou automação do lar? A Packt tem – e é bom!

A promoção acaba amanhã, 5 de julho, mas ainda dá tempo: dê um passeio no site deles, você não vai se arrepender.

Book Review – Practical Change Management

I work supporting and developing Business Intelligence solutions, a job that is all about changing things: updating a table layout in a database, changing an IP address in the ETL, adding users to the OLAP tool – pretty standard GitHub/SourceForge chores and the like. So when I was given a chance to review the new Impackt book, Practical Change Management for IT Projects, I dove in, little knowing how mistaken I was and how happy this misunderstanding was about to become.

Reading the book was like seeing the sea for the first time: wow! There is a whole field of corporate change management, with people planning and rolling out a change in detail!

I work with a large (+10.000 employees, US$1Billion/Year) brazillian federal government IT company and we do plan our rollouts (for new systems, new process, new softwares, corporate culture change and so on), but the book addresses it in a deeper level than we have ever done. The author writes with focus, with the tight and well constructed sentences only those who had done something a lot are able to use. You can see it is so and not a professional polished text because among the concise wording, here and there, you can spot some odd constructions, and sometimes the train of thought is strained a bit too long, even for the native English speaker.

Managing the Change without Chance

If Change Management, the discipline of planning and conducting some change in an organisation, were a shrink-wrapped product, this book would be its instruction manual. It neatly explains what change management is and how the change eventually go around happening (or not.) She explains what are and and then identifies the components of a change (the “Pillars of Change”), the participants, the components of a change program and finally she lays out a project pattern for making the change happen in an orderly fashion. So there is quite a detailed work break-down, with roles, activities, milestones, deliverables, documentation (with templates and credible examples), control meetings. The whole shebang.

Concurrently, and I believe this is what add most value to this book, while the author presents all the information and the method she walks the reader trough every piece of it by using a Case Study set at the beggining of the book. In it, Acme Corp is adopting a new buying system in replacement for an old one. This change must happen in every division of the company and, to makes things look worse, this very system holds a sizeable amount of responsability for the results of Acme. If something goes awry this fictional company profitability might be badly hurten.

The Only Constant is Change

Practical Change Management for IT Projects is worth every penny. If you might be affected by change anytime, buy and read it at once. It seems Change Management is not that widespread discipline as is Project Management so it might be possible your company has never heard about it in that formal way. I am no novice on corporate life and it strucks me with some shame I have never seem it around. I am at ease to confess my loss at it just because the last words in the book are saved for telling you (the reader) the importance of the awareness of Change Management, that this awareness is key to success and how to rise it. Hence, to share those ideas and the book are an important exercise alongside everything else.

The Hands Down

I must admit I became an Emily Carr’s fan. I enjoyed reading the book by its sheer style, the upbeat never-surrender-never-retreat attitude. There is some inspiring grandeur in how she poses the problem and the hardship everyone faces daily, and the feeling she imparts on the need for change just makes you feel good.

Well, now that I said how much the book is worth and much I enjoyed it, I can tell what I didn’t like.

The Caveats

To make it sure: the book is good, you won’t regret buying it. However…

She operates the change management on some level of optimism. Unfortunatelly, real companies seem to be much more difficult to deal than Acme. On ocasion she sets some ideal situation that is simply not every time attainable. Some sort of compromise usually kicks in everything we do but she does not acknowledge that much (she doesn’t deny it, thoug.) For instance, on location 2187 she states the extreme importance of having every event you invite user to to be well planed and features a bug-free version of the product involved in the change. Good luck getting it…

She avoids dealing with all the possible variations and cenarios, or even with a small set of possibilities, so everything seems to be under an “ideal world” lighting. Although the consideration on some variability would enrich the book, taking in consideration its lenght, the templates, walkthroughs, insights and tips, by not addressing this much of variability doesn’t hurt the final results and, after all, makes for a more readable and practical book.

Another thing I can spot as some hidden hindrance to the newly broken Change Manager is that she makes it seem so much easy and success prone. There is nothing wrong here, for with some training and a bit of practicing it will probably became easier to drive a change program. The risk is not being aware how easy it is not. She knows how to do and have come confidence on doing it and she stress constantly a Change Program takes a lot of effort to turn in a success, but she writes very well and easily gets the reader carried away (again, nothing wrong – passion is good. Just kiss with lights on, and with open eyes.)

Finally, I couldn’t find any reference to Scrum or some Agile method. The program has a very conservative look of a waterfall planing. Of course if it works out good, I can’t ask for anything else. But Scrum is such a powerfull way of managing project that Change Management, being all about commiting changes, should be connected to it in some way.

Conclusion

As I said, Practical Change Management for IT Projects is very good and in fact a must have: practical, usefull guide on how to make change happen and how to have some control on it. All in all, a good read in all the senses. Its only downsides are some optmism and a couple of beatifull scenarios. I also miss some relationship with Scrum or any Agile technique, but none of those aspects are really an issue.

There is some changing come my way and I am very happy I have mistakenly turned to this book for some dull code-versioning stintch. After all it was not anything I would imagine, but thanks to this misunderstanding now I can really help make change happening, something I didn’t even know about a couple of weeks ago.

Treinamento Pentaho BigData+Sparkl em Maio/2014

Logo após o Pentaho Day (que serão dois dias, na verdade), ocorrerá em São Paulo um treinamento oficial Pentaho sobre BigData e Sparkl.

Vocês podem ver os detalhes aqui. O preço é meio salgado, mas vale cada centavo: não apenas é um curso oficial, como será ministrado diretamente pelo inventor da tecnologia Sparkl, Pedro Alves, Sênior Vice-Presidente da Pentaho.

Eu ainda não consegui parar para estudar Sparkl, mas se tudo que eu ouvi tem a ver com a realidade, então vai ser o bicho. Imagine poder construir, ad hoc, um aplicativo de BI diretamente sobre qualquer base de dados INCLUSIVE BigData!!