Projeto de Quê?…

Em 29/03/2012 eu publiquei meu primeiro post:

Hello, World!

Hoje este blog completa 10 anos!

Muito obrigado a todos que passaram por aqui!

Vamos lá: após 30, 40 anos falando-se “Inteligência de Negócio” o termo simplesmente desgastou-se. Muita gente pensa em “BI” como um software: ora referem-se a um banco de dados (tecnicamente o armazém de dados em si) como “o BI”, enquanto que outros associam a sigla a relatórios e um terceiro grupo à painéis e assim por diante. A vida dessas duas palavrinhas é mais complicada que as Infinitas Terras da DC.

Um dia eu encontrei uma definição para Business Intelligence que me satisfez:

Inteligência de Negócios é a disciplina de busca da compreensão dos negócios de uma organização mediante a aplicação do Método Científico.

Eu tomo essa por a definição mais apropriada, tanto que ela forma a base do do meu livro Fundamentos de Inteligência de Negócio (comprem! :-) ).

Acontece que o que eu acho não faz diferença. O mundo inteiro pensa como pensa e é isso. Eu não posso simplesmente reformatar o mundo – posso oferecer minha contribuição e ver o que vai acontecer, só.

Mesmo assim, ainda precisamos falar sobre o assunto. Ainda precisamos dar um nome à “coisa”.

“A Coisa”

E o que é “a coisa”?

Bom, é uma iniciativa com um objetivo – resolver um problema. Parte dessa coisa é perene, como a infraestrutura (computadores, redes, softwares etc.) Outra parte tem início e fim: surge uma demanda por uma solução de um problema, alguém trabalha e o problema é resolvido – início, meio e fim.

Existem entregáveis: ao final teremos gerado algo que vai resolver o tal problema (um modelo matemático, um algoritmo, uma análise), e talvez produzido outras coisas intermediárias (mais dados no DW, uma nova perna de ETL, uma nova ferramenta na infra).

Como essas são características de projetos, é razoável qualificar “a coisa” como “projeto”. Vem daí o título deste post. ;-)

Projeto do Quê?

Projeto de “Coisa”, oras! :-)

Gracinhas à parte, no nosso contexto estamos falando de projetos que buscam resolver problemas usando os dados da organização. Logo, é razoável dizer que são “projetos de dados”.

A vantagem de um termo tão amplo é que ele abarca praticamente tudo:

  • Vamos desenhar um painel de vendas – projeto de dados!
  • Vamos analisar nossos dados e descobrir porque nossas vendas caíram – projeto de dados!
  • Vamos criar um modelo de forecasting de vendas – projeto de dados!
  • Vamos criar uma API de integração com Marketing para mala-direta – projeto de dados!

E isso também é uma desvantagem: se uma só palavra descreve tudo, então no fundo ela não descreve realmente nada. As palavras tudo e nada são bons exemplos dessa questão: Projeto de Tudo, Projeto de Nada.

Logo, Projeto de Dados é uma solução aceitável, mas não é muito boa.

Uma Coisa é Uma Coisa, Outra Coisa é Outra Coisa

Um projeto que entrega um painel de dados operacionais cai dentro de uma disciplina chamada Inteligência Operacional – se você nunca ouviu esse termo, leia o post Analítico ou Operacional – aposto que vai achar interessante.

Uma análise de dados em busca de uma resposta a um problema é aplicação do método científico sobre os dados da empresa para extrair uma informação, que é a minha definição de Inteligência de Negócios.

Já um projeto que constrói um modelo matemático para automatizar a tomada de decisão aplica o método científico sobre os dados da empresa para extrair um padrão. Isso é o emprego do processo de Data Mining atrelada à minha definição de Inteligência de Negócios.

E a construção de uma API para fornecer dados eintegrar sistemas? É um projeto de integração de dados ou simplesmente um projeto de software. (Quem conhece ferramentas de EDI sabe que mudar a definição muda a implementação.)

Além disso, projetos de softwares podem ser vistos como ferramentas, o que significa um projeto de software pode ser conduzido para, por exemplo, realizar Data Mining ou construir um painel.

Resumindo, então, temos um tipo genérico de projeto, o Projeto de Dados, que pode ser subdividido em (pelo menos) quatro tipos específicos:

  • Projeto de Inteligência Operacional;
  • Projeto de Inteligência de Negócios;
    • Projeto de Inteligência de Negócios: Data Mining;
  • Projeto de Integração de Dados

E de brinde ainda temos o também genérico Projeto de Software – que pode ser usado para implementar qualquer um dos quatro tipos acima.

Conclusão

“E daí”, perguntarão vocês, “e eu kiko?”

Ok, vocês me pegaram.

Falar projeto de BI hoje em dia é quase um atestado de petróleo: “Olá, eu sou o Fábiossauro, um velho que ficou no passado, e ainda falo BI”.

Tudo bem – eu já fui chamado de velho com 15 anos. Minha irmã me chamava de velho resmungão quando eu tinha 12 anos. Pelo visto eu nasci velho. É a boa e velha vida. ;-)

Mas quando este velho aqui morrer, as coisas continuarão sendo o que são – elas não dependem de alguém para ser, para existir. As coisas têm sentido em si. Um projeto que resolve um problema aplicando o método cientifico aos dados sempre vai ser um projeto que resolve um problema aplicando o método cientifico aos dados. Podemos escolher usar o nome por extenso ou um apelido – projeto de BI.

Eu escolho o apelido (sou preguiçoso até dizer chega.)

Então, o único motivo pelo qual eu escrevi esse post inteiro, e gastei seu tempo até aqui, foi apenas para dizer que quando eu escrevo “Projeto de BI” eu estou me referindo a um certo tipo de projeto – e não é relatório, nem painel, nem DW, mesmo que envolva essas tecnologias.

Não vejo motivo para abandonar um nome apenas porque a fama dele ficou ruim. Fizemos isso com Data Mining, que virou Data Science, e não adiantou nada – Data Science já está se queimando também. Anotem o que eu estou escrevendo: já, já vem um novo “Data Science” por aí (e isso ignorando AI, ML, Deep Learning etc. etc. etc.)

É isso. Obrigado pela visita e até a próxima!

:-)

O Início da Engenharia de Dados

Engenharia de dados é o nome que hoje se usa para indicar todas as atividades de mover e tratar dados a fim de transformá-los em recursos para os negócios. Existem definições mais precisas que isso, mas para essa basta para o que eu vou falar aqui hoje.

O Mundo Hoje

Conforme o The Phoenix Project a TI é o negócio. Assim, uma das descrições possíveis para “empresa” é “coleção de sistemas informatizados”. São esses sistemas que dão existência às operações da empresa.

De acordo com o Fundamentos de Inteligência de Negócios, toda empresa encara dois tipos de problemas: operacional e estratégico. Problemas operacionais são resolvidos no dia-a-dia e podem ou não necessitar de dados desses sistemas. A Inteligência Operacional é a disciplina que atende esse tipo de problema.

Problemas estratégicos, ainda conforme o post Analítico ou Operacional? , são resolvidos por Inteligência de Negócios, que eu defini em Paz, Afinal – Parte III.

E esse é o estado do mundo hoje:

  • Sistemas informatizados são construídos para operacionalizar um empreendimento;
  • Os dados desses sistemas são necessários em aplicações diversas;
  • OI consome dados perto de tempo real, BI longe;
  • A fim de levar os dados dos sistemas transacionais para esses usos existe a Engenharia de Dados (que é o nome bacana para integração de dados – mais sobre a bacanização desse nome num post futuro.)

Assim Não Dá, Assim Não é Possível

Esse arranjo não é ideal, nem de longe. Ele envolve muito esforço, trabalho, retrabalho, desperdícios, sem contar resultados chochos em muitos casos. Basta lembrar a métrica de fracassos de projetos de dados do Gartner, que volta e meia alguém cita:

Qualquer analista de data mining digno do seu R2 pode ver claramente que a taxa de fracasso está aumentando, e que não é improvável bater em 100%.

Na verdade, se você parar para pensar, pode existir alguma empresa por aí que tem 100% de fracasso, ou seja, que nunca viu um projeto desse tipo dar certo. Nunca. O mesmo se pode dizer de profissionais: é perfeitamente razoável imaginar gente cuja carreira é um fieira de fracassos ininterruptos. Tipo, o cara deve ser um virgem de sucesso – nunca experimentou sucesso vida.

Solução a Curto Prazo

Eu já mostrei neste blog muitas alternativas que elevam taxas de sucesso a 100%. Se você está tendo problemas e quer uma luz, me chame – quem sabe podemos chegar a algum arranjo. ;-)

Passado esse vergonhoso momento de autopromoção (gasolina tá alta pra todo mundo!), a solução a curto prazo é simplesmente parar de modismo e começar a se preocupar com o que de fato interessa: resultado.

Data lakes, data mesh (sobre o que eu vou escrever em breve, depois de engenharia de dados), gestão de times, ferramentas etc. tudo isso nasceu de modismos insensatos (desde o início eu argumento que a idéia de data lake é pouco vantajosa, por exemplo). Isso quando a moda simplesmente não muda o nome das coisas, para ficar mais bacana (ninguém ainda demonstrou que data science não é Data Mining.)

Se você quer achar a saída para o labirinto dos seus projetos, a aplicação da Teoria das Restrições a BI pode te dar uma luz. (Eu adoraria saber se ajudou, ok? :-) )

O Longo Prazo

Agora, porque é que temos que esperar um sistema entrar em produção para só então começar a nos preocupar com os dados para análise? Porque o sistema já não vem com isso como uma funcionalidade default, automática e pronta?

Para entender a idéia eu preciso colocar uma coisa antes: Data Vault. Essa tecnologia resolve todos os problemas de integração, ingestão, consumo etc. e por isso ele é o caminho mais fácil e curto para um projeto de dados de sucesso. Graças a Data Vault, aliás, hoje é possível manter projetos de dados 100% automatizados, com uma só pessoa trabalhando.

A partir das premissas de Data Vault é possível desenvolver um Data Warehouse como um componente do sistema transacional, embutido no código, de saída. Graças aos paradigmas de Data Vault podemos construir uma extensão a um ORM, como o Hibernate, para gerar um DW ao compilar o código. Daí, a usando os padrões de refatoramento de bancos de dados do Martin Fowler e ferramentas como Liquibase, podemos automatizar evoluções de base em um pipeline CD/CI.

A idéia me veio hoje, lendo um comentário do Daniel Linstedt (pai do Data Vault) num post do Snowflake:

08/03/2022 Dan Linstedt: I predict a future where Operational Systems make the jump to Snowflake technology – where Snowflake builds a platform to enable operational application support for data scalability world-wide. Would be interesting to see for sure.

Ele implica o cenário em que um sistema transacional contrata uma solução de DW automatizada (que é uma das formas de operação do Snowflake). A ideia faz tanto sentido (e ele é tão próximo da Snowflake) que algo nesta linha provavelmente vai aparecer.

Eu tentei imaginar como isso seria e de repente a coisa toda cristalizou-se: dá para fazer um DW como código e embutir no próprio sistema transacional! Inclusive, isso daria incentivo à implementação de mecanismos de CDC direto no sistema!

E a coisa não pára nisso. Uma empresa raramente usa um só sistema e o normal é existir vários. De novo, graças aos paradigmas de um Data Vault, é muito simples integrar vários DWs-As-Code em um DW federado maior, sem perder escalabilidade e sem aumentar a complexidade. Dá para virar um padrão de indústria, até.


DW-As-Code: DWAC

CONSEGUI, INVENTEI UMA NOVA BUZZWORD, HAHAHAHA! VEM NI MIM, GARTNER!

(Pelo menos não achei nada no Google, ainda. :-)


Conclusão

No artigo What Is Disruptive Innovation?, Clayton Christensen explica como ocorre a inovação disruptiva:


Specifically, as incumbents focus on improving their products and services for their most demanding (and usually most profitable) customers, they exceed the needs of some segments and ignore the needs of others. Entrants that prove disruptive begin by successfully targeting those overlooked segments, gaining a foothold by delivering more-suitable functionality—frequently at a lower price. Incumbents, chasing higher profitability in more-demanding segments, tend not to respond vigorously. Entrants then move upmarket, delivering the performance that incumbents’ mainstream customers require, while preserving the advantages that drove their early success. When mainstream customers start adopting the entrants’ offerings in volume, disruption has occurred.


Em tradução livre e abreviada, “um desafiante, menor e com menos recursos que os maiores jogadores, escolhe focar em clientes de setores mal-servidos, onde conseguem firmar um pé ao melhorar a situação desses clientes; daí, os novatos se movem ‘mercado acima’, abocanhando setores cada vez mais valiosos, até que finalmente os clientes do mercado principal também adotam esses produtos; neste ponto dizemos que ocorreu a disrupção”.

A situação de projetos de dados hoje não é sequer uma coisa marginal – está ruim e confuso para todo mundo. Mesmo uma melhoria pequena já dá vantagens. Adicionar um DW como código a um sistema transacional é resolver um problema que nem sequer existe claramente. Fazer isso em um sistema que nem está no mercado, que está sendo desenvolvido, é ainda mais impensável.

Hoje ninguém seguirá essa direção, com certeza. Mas talvez um dia DWs sejam partes integrantes de um sistema informatizado, e o ecossistema de dados evolua para outro cenário.

E o que tem isso tudo com o nome do post, O Início da Engenharia de Dados?

Como eu disse no começo, EdD hoje é grosso modo a disciplina que monta e configura softwares e ambientes para mover dados de um lado para outro (fornecimento para análise também é mover dados de um lado para outro.) Com todo respeito, o conceito de Engenharia está para essas atividades assim como o conceito de Culinária está para bolo de caixinha. Na minha humilde e totalmente irrelevante opinião (mas minha, none the less), isso não é engenharia de dados. Para dar um exemplo, modelagem, que é uma coisa importantíssima, é um assunto marginal em EdD.

Para tentar deixar mais claro meu ponto de vista, considere o que chamamos de Engenharia de Computação, que é a carreira dentro da qual se aprende a desenvolver e programar sistemas, e compare com a Engenharia de Dados, que praticamente uma coletânea de softwares e processos.

Ao começar a tratar DW como parte de um sistema informatizado, e não como um apêndice, crescendo à parte e perpetuamente encrencado, eu entendo que estamos mudando o paradigma do campo “ETL com Python” ou talvez “Integração de Dados com Kafka”.

A partir deste ponto eu entendo que será o início de uma disciplina de Engenharia de Dados tão séria e profunda quando Engenharia de Computação.

Quem viver, verá.

Eu sempre quis dizer isso!!! :-D

BI Full Stack Etc.

Hoje eu vi um anúncio de vaga de emprego com estas responsabilidades:

Esse é um bom exemplo de perfil profissional da Velha Economia:

  • Confuso: já começa pedindo uma coisa incomum, que é a tal gestão de acesso de ferramentas. Não seria gestão de acesso às ferramentas? Ou é o controle de acesso de um conjunto de ferramentas (qual?) à bancos de dados? E o que é gestão neste caso, seria controlar as credenciais de cada ferramenta a uma outra coisa?
  • Barulhento: Data Wrangling é um outro nome para ETL, com a “diferença” que DW (péra, esse acrônimo já tem uso…) deixa o dado ainda cru mas reorganizado para outra aplicação. Afinal, depois de sofrer alguma transformação, ainda é dado crú?!
  • Quem faz tudo, não faz nada: o perfil vai fazer – nesta ordem de relevância – relatórios, levantar requisitos, especificar (o quê??), modelar (o quê???), construir painéis e (finalmente!!) ETL, mas não é Data Wrangling, que é ETL com dado crú… Q????
  • Fazer três coisas iguais usando nomes diferentes: OLAP (que usa MDX se for da MS), MDX (para OLAP da MS) e DAX (que é uma espécie de “linguagem” para painéis – que são análise multidimensionais em essência, que é a definição de OLAP que usa MDX…)
  • Especialista do assunto: além de toda essa confusão de tecnologias, buzzwords e conceitos, o feliz escolhido vai ter que fazer análise de indicadores de produtos. Em outras palavras, ele precisa conhecer o produto, conhecer o mercado, conhecer as tecnologias e analisar isso (para quê? para pendurar na parede?) E tem a tal da análise de mídia digital. Dá para intuir o que isso deve ser pela associação com análise de indicadores, mas mesmo assim, putz;

Faixa-bônus: “estruturar a coleta dados e estruturação das métricas de acompanhamento de mídia digital e CRM em todas as fases da cadeia de mídia”. Sem contar o “estruturar a estruturação”, isso não é um resumo de tudo que está escrito antes?

Vocês dirão: mas, Fábio, é só uma empresa pequena; provavelmente esse aí vai ser o “eupartamento” de BI ou a “euquipe” de dados, onde um cara só faz tudo e ainda passa o café!

Pois então, não. É uma vaga oferecida pela holding dona de uma multinacional brasileira (nativa!), com milhares de lojas pelo mundo. Então, não: é uma mega-empresa!

Como alguém pede um perfil desses? Só posso imaginar que seja um ambiente confuso, algo caótico ou que não possui valor dentro da empresa e por isso não recebe atenção e cuidado.

Vaga de Nova EcoNOmia

Pelo restante da descrição da vaga (que eu não coloquei aqui), eles procuram um analista de produto, focado no negócio. Se eu fosse pedir esse profissional, eu colocaria a lista de requisitos assim:

  • Perfil analítico: possuir formação em Estatística, como graduação principal, parte de outra formação (como Física ou Engenharia) ou curso livre;
  • Carreira desenvolvida em gestão de produto;
  • Usuário de ferramentas de análises de dados, como OLAP, relatórios e painéis;
  • Conhecimento de tecnologias e processos de construção de produtos de dados, incluindo mas não limitado à ETL, clusters Hadoop (“BigData”) Data Warehousing, Modelagem Dimensional e 6a. forma normal (Data Vault);
  • Experiência em processos leans e ágeis.

Esse cara está preparado para “monitorar resultados de campanhas, trabalhar dados de mídia e negócio, criar e experimentar modelos matemáticos contra o mercado para entender e monitorar a jornada do cliente, e disto extrair insights para gerar valor para o negócio”.

Repare que a lista anterior era praticamente um resumo de buzzwords soltas, desconexas: esse o mindset da empresa linear, tradicional. Empresas inovadoras, focadas no negócio e em seus valores, com clareza de propósitos, constroem descrições mais parecidas com a segunda lista.

Conclusão

A descrição da vaga inteira dá uma boa idéia de que profissional está sendo buscado. Infelizmente, a comunicação disso ainda é muito deficiente quando se desce ao nível dos traços de conhecimento e personalidade almejados. Parece aquela história, “eu sei o que é, só não sei como falar”.

Isso é ruim? Em parte sim, em parte é indiferente. Duvido que essa descrição esquisita afaste quem quer trabalhar naquela empresa. E, se o processo deles for minimamente razoável, vão encontrar quem estão buscando. Então, é só uma coisa chata, mesmo.

Mas hoje em dia ainda existe uma grande distância entre trabalhar em Inteligência de Negócios e entender o que realmente é Inteligência de Negócios.

É isso. :-)

Kibana é Inteligência Operacional

No post Analítico ou Operacional eu proponho a existência de um campo análogo à Inteligência de Negócio chamado Inteligência Operacional. À época eu mal consegui confirmar meu ponto-de-vista, pois parece que poucos haviam realizado essa observação. Eu aprofundei aquela abordagem e, eventualmente, criei uma apresentação chamada “Cultura de Dados”, que eu transmiti ao vivo em 1/4/2020.

Hoje, assistindo um vídeo para começar a aprender sobre o Kibana, qual não foi minha surpresa ao ver que reconhecido o campo de OI!

Para quem tiver interesse, o vídeo está aqui. e esse slide aparece aos 1’20”.

Pode parecer besteira, mas o simples fato de relacionarem uma ferramenta à uma disciplina tem um grande efeito. Para começar, legitima o conceito. Em segundo lugar, ao oferecer um caso concreto ele ajuda a contratastar com disciplinas similares, como BI. Por último, ele dá aquela centelha na cabeça de todos, que começam a se questionar “o que mais é OI?” e “que outros casos de OI existem?”.

Em última instância, o fortalecimento do conceito de OI ajuda o debate sobre o conceito de BI, permitindo separar as duas coisas. Essa separação, por fim, permite melhorar o resultados dos projetos de ambos os tipos, já que misturar coisas diferentes piora os resultados.

É isso! Go, OI!:-)

Trabalho em Grupo

Há coisas que são um completo mistério para mim. Por exemplo, porque algum professor acredita que um trabalho em grupo pode produzir conhecimento para os alunos.

Quero dizer, todo mundo sabe: um cara faz e o outros olham. Eu sempre fui assim, fazia tudo e mandava os outros ficarem calados e quietinhos – eu não queria nenhum mané estragando minhas notas, ou pior: ter que explicar tudo para eles! :-P

Mesmo assim, trabalhos em grupo viraram um componente básico de tudo quanto é curso. Eu estou fazendo um segunda graduação e todo santo semestre eu preciso entregar um trabalho em grupo, o famigerado Projeto Integrador.

A idéia – como todas as idéias – tem lá o seu sentido: dar aos alunos um espaço para aplicar o que aprenderam ao longo do semestre. Mas, como todas as idéias, há uma grande diferença entre a imaginação iridiscente dos docentes e a dura realidade discente.

O problema mais frequente é justamente um só aluno assumir o trabalho pelo grupo, quando os alunos simplesmente não saem no tapa por causa do projeto. (Sim, brigas que não chegam às vias de fato porque o curso é 100% EAD.)

Parte da nota da matéria é uma auto-avaliação, cujos critérios são dados pelo instrutor e cada membro atribui a si mesmo quanto acredita que merece. Neste semestre, porém, veio uma novidade: nós, membros do grupo, deveríamos escolher três critérios de auto-avaliação e realizar a avaliação de cada membro por estes critérios.

Caramba!

É fácil se atribuir nota máxima para um critério vago como “Dedicação ao resultado” ou “Participou ativamente” – afinal, são muito subjetivos. Mas quando te dão a responsabilidade de criar o critério, você enfrenta um problema muito pior:

  • Se você criar um critério fácil, o instrutor vai notar que você está tentando se safar e conseguir uma nota alta – ou seja, está sendo imoral;
  • Se você criar um critério difícil, vai prejudicar a si e aos seus colegas, fora o papel de bobo de ter se dado uma meta que você sabe que não atingiu.

E agora, José?

Como físico e um cara de BI, eu tratei o problema como um assunto de negócios. Primeiro, eu me coloquei no lugar do professor e me perguntei o quê, em um trabalho em grupo, eu gostaria que acontecesse. Achei isso:

  • Que o volume de trabalho fosse dividido de maneira equilibrada entre os membros;
  • Que a dedicação de um membro (ou falta desta) impactasse o grupo como um todo;
  • Que os membros levassem suas tarefas à sério e não desemcumbissem-se meramente para cumprir tabela.

Pensei em alguns outros parâmetros, mas acabei ficando com esses por entender que são mais fundamentais.

Como sabemos de Lean, uma forma de provocar um comportamento é medi-lo. Logo, eu precisava criar métricas objetivas que levassem os alunos a se auto-organizar e se policiarem mutuamente.

Depois de alguns momentos de rilhar de dentes, cheguei nestas métricas:

Colaboração

A qualidade do resultado final é diretamente dependente do entrosamento e do trabalho em time. Um cara que nunca aparece nas reuniões e nunca participa das discussões é a raiz de um problema: se ele não entendeu como as tarefas foram definidas e divididas, ele provavelmente vai dar mais trabalho e gerar menos resultado.

Por isso eu defini a nota de Colaboração como uma nota individual, representando um percentual de participação em reuniões, indo de zero porcento (nunca deu as caras) à 100% (esteve em todas!)

Entrega

Além de trabalhar em time, colaborando com os colegas, o integrante precisa ser responsável e realizar as tarefas distribuídas para ele e precisa fazê-lo dentro de um prazo, com qualidade.

Putz, qualidade? Isso não é subjetivo? Sim, mas eu achei uma forma: cada membro tem sua tarefa revisada por pelo menos dois outros (somos em seis no meu grupo.) Assim cada um tem que prestar contas aos colegas, que por sua vez não vão aceitar um resultado que vão prejudicá-los adiante. Em outras palavras, eu dei um jeito de enfiar a coação social do Scrum no trabalho de escola. U-lá-lá!! :-D

Resta a questão de dar um número para isso. Eu chamei essa métrica de Entrega, indivual, como uma média aritmética de dois outros parâmetros: “Dentro do Prazo” e “Qualidade”.

“Dentro do Prazo” é calculado como a distância entre a data na qual o aluno entregou a sua parte e o deadline para aquela parte. Se ele entregar antes ou no dia, recebe 10 em Entrega, com penalidade de dois pontos a cada dia atrasado, até ter zero se atrasar cinco ou mais dias.

“Qualidade” eu defini quase do mesmo jeito: uma nota começando em 10 e caindo 1 ponto a cada erro encontrado por outro membro da equipe. Assim, dez erros daria zero e nenhum erro, nota máxima.

Finalmente, nota Entrega = (Dentro do Prazo + Qualidade ) / 2.

Ah, os números. Eles realmente são mágicos!! Agora eu já tinha duas notas para nos avaliar! Que alegria! :-)

Só que o curso exige três notas de auto-avaliação. E eu ainda não tinha amarrado a divisão de tarefas. Resolvi criando a última métrica, que pressionasse o aluno a participar do trabalho e se comprometer com o grupo como um todo – algo na mesma linha da primeira métrica, de Colaboração, mas que afetasse todos a partir de um.

Carga

Essa é uma nota única para o grupo inteiro: se um membro fizer corpo mole (ou se um decidir ser fominha, como eu era), o grupo inteiro sai prejudicado.

O truque foi usar uma medida estatística: desvio-padrão.

Como? Fácil: a cada reunião tínhamos uma série de tarefas para fazer, distribuídas entre os alunos. Daí bastou calcular o desvio-padrão usando N como tamanho do grupo, a quantidade de tarefas como cada amostra, e a média de tarefas por membro. Voi-lá!

Como eu quero notas de zero a dez, eu defini: Carga = 10 – 2*sigma.

Se todo mundo pegasse exatamente a mesma quantidade de tarefas, fosse um ou dez, sigma (o desvio-padrão) daria zero e a nota seria 10. Se um só cara fizesse tudo, sigma chegava perto de 5 com apenas 12 tarefas – como se um só acumulasse duas tarefas de todo mundo – e isso nos daria zero.

E porque isso é legal? Ora, por uma simples questão de produtividade! A vantagem do trabalho em grupo sobre o individual é poder produzir mais em menos tempo e com menos esforço. Quando todas as tarefas estão em um único membro, o trabalho atinge a produtividade individual e o valor do grupo vai a zero – que é o que normalmente acontece.

Por outro lado, quanto mais dividida as tarefas são, maior é a produtividade do grupo como um todo – e maior o benefício desse tipo de exercício. Usando sigma eu consegui que mesmo um folgado ou um fominha já ferrasse o grupo inteiro, dando rédeas aos instintos de cada membro.

Eu sou o máximo!!!

Conclusão

Estamos em 2021, já com centenas de anos nas costas usando o mesmo modelo de educação. Esse formato já era, não serve mais e é fácil notar: estamos no meio de um enorme apagão de mão-de-obra. Graças à peste chinesa, está ainda pior porque nossos cérebros estão sendo contratados no exterior, com a mesma facilidade que seriam contratados aqui. Se existe tanta demanda por mão-de-obra, como então não estamos vendo um crescimento explosivo em cursos de formação profissional? Deveria ser o mercado mais aquecido! E não é!


Eu realmente queria deixar aqui as referências – talvez um dia eu volte a este post e conserte esse problema. Agora passa da meia-noite e ainda não entreguei o trabalho da facul e amanhã preciso pular cedo da cama, então vai como está. Sorry. :-(


Porém, um pouco de visão de negócio, uma relada de Lean e uma pitada de Scrum corrigiram – para mim – um problema que me aporrinha desde que eu era um moleque besta na quinta série.

This is Business Intelligenceeeee!!!

OUVIU ISSO, FÊSSOR? É ASSIM QUE SE FAZ!!! PRO INFERNO COM SEU DIÁRIO DE CLASSE!!!

THIS IS ESPAAAAAAARTAAAAAA!!!!

Kkkkk…

20 Anos Depois

Em 2000 eu pude participar de uma conferência do SAS – como empregado, nos bastidores – e ver Bill Inmon palestrar. Por essas coisas de eventos e ranks, eu não tive a oportunidade de conhecê-lo e, no fundo, não teria sido nada tão extraordinário para mim. Lembro-me de vê-lo falando e do sentimento de reverência por estar assistindo o pai do assunto, mas nada mais que isso.

Acho que deve ser o que sentimos quando vemos um jornalista da TV na rua: ah, puxa, ele é da TV, e acaba nisso. (Muito diferente, por exemplo, de assistir o show do Robert Plant e Jimmy Page no Hollywood Rock – muuuuito diferente.)

Hoje, praticamente 20 anos depois, o destino me leva para o lado do pai do DW mais uma vez. Mas agora, na mesma página:

Literalmente na mesma página, no WWDVC 2021

He, he. Agora eu me sinto no show do Led Zeppelin. :-D No palco do show, para ser exato.

Então é isso: em 2021 eu vou apresentar uma palestra ao vivo (um case) e outra pré-gravada (Data Culture) no palco do World Wide Data Vault Consortium 2021.

Este ano ele será totalmente virtual – por isso eu consegui me inscrever como palestrante. Mas isso significa que ninguém precisa mais pagar um vôo até Vermont, e hotel, para assistir a conferência!! Interessado? Acesse a página do evento e inscreva-se!

Ok, acabei de ver o Scott Ambler… eitap***a…

Há Vagas Para… Desenvolvedor BI

Apesar de estar muito satisfeito em meu emprego, eu sempre dou uma olhada no que o Mercado de BI procura. Afinal, nunca é demais termos um ou dois Planos B na manga.

Algumas vagas chamam a atenção, ou porque pedem um perfil inédito até então, ou porque combinam nomes de perfis distintos e criam uma nova espécie.

Hoje eu vou examinar uma oferta de vaga que procura por um Desenvolvedor BI.

Pseudo-screenshot do LinkedIn
(Achievement! Poliglota – três línguas em frase curta.)

Como eu sou adepto da idea de BI como conceito e não como produto, esse título me chamou a atenção. Eu entendo que Business Intelligence não é uma linguagem de programação, nem um tipo de framework que possa ser usado em um desenvolvimento de sistemas e muito menos um sistema pronto, algo que requeira um desenvolvedor.

A descrição fala “desenvolvemos o BI do futuro”. Legal! Ainda há muito a ser feito, parece instigante.

Depois vem a área de atuação: cientista de dados. Hmm… Cientista de dados é o termo hype para “analista de Data Mining“, que é a pessoa que resolve problemas de negócio construindo modelos matemáticos para automação de tomada de decisão. Não chega a ser um papel novo, existindo com o nome antigo já há uns 30 anos, mas é uma área onde se pode fazer muito pelo conceito de BI. Ainda mais se pensarmos que a empresa contratante está mirando em NLP.

A descrição, entretando, vira-se para o lado oposto: a função do analista de Data Mining é “desenvolver relatórios customizados para os clientes”. Ainda que um modelo matemático possa ser a base para um relatório, não constuma ser o emprego mais valioso de tais modelos. Indicadas como ferramentas para construir tais relatórios – presume-se – está R e Python. Ainda que possam realizar um trabalho muito bom, não são plataformas cuja missão é gerar relatórios. Para isso existem softwares muito mais aptos, que reduzem a carga de trabalho e entregam resultados tão bons quanto. É uma escolha bem curiosa.

Uma tarefa comum a perfis de BI é lidar com o público, o que está na vaga. Algo menos alinhado é monitorar e gerencia a saúde (qual?) dos clientes.

Seres humanos exibem a tendência de criar foco e se concentrar na tarefa à mão. Pular entre várias funções, ainda mais quando exigem mindsets diferentes, pode gerar perda de rendimento. O pensar e agir como desenvolvedor é razoalvelmente diferente do pensar e agir de um como gerente, ainda mais levando em conta a gama de ações de cada papel.

Recomendo este artigo aborda para conhecer por alto a questão do context switching.

É uma combinação impossível? Não, acredito que não. É uma boa combinação? Na minha percepção, não. Criou-se a idéia do profissional com perfil-T, que consegue exercer tanto uma atividade especialista, quanto generalista, algo muito requisitado em times ágeis e auto-organizados. Mas a vaga não parece mirar nesse tipo de profissional. O pouco que se descreve desse papel de gerente dá a entender que a descrição do trabalho inclui atuar como gerente de contas, em que o relacionamento com o cliente é a atividade central. Nesse caso, a distância entre os dois papéis (analista e gerente) é ainda maior e a tensão entre as duas atuações é ainda mais acentuada.

Estou Contratanto: Desenvolvedor & Gestor

Eu não conheço a empresa, nem seus desafios. Como eles almejam criar o futuro da Inteligência de Negócios, não posso sequer querer saber como é a vida lá, já que eu sou do passado. Sabendo que papéis que lidam com pessoas tendem a requerer perfis diferentes dos profissionais que lidam com desenvolvimento (sendo realizado em R ou Python, como desenvolvimento de software tradicional), talvez possamos descrever essa vaga de forma a buscar um profissional mais apropriado – começando por separá-la em duas.

Vaga 1: Cientista de Dados

Descrição: realizar análise de problemas de negócio e construir modelos matemáticos a partir de dados para automatizar a tomada de decisão. Necessário habilidade analítica em R ou Python.

Vaga 2: Gerente de Conta

Descrição: empregar ferramental analítico para examinar a saúde (financeira? mercadológica?) dos clientes e propor ações para reduzir riscos e mitigar problemas. Requer raciocínio lógico, habilidade de comunicação escrita, apresentação de resultados e acompanhamento de clientes. Funcionará em colaboração estreita com o Cientista de Dados, levando problemas do cliente e trazendo as soluções para estes.

Essa redação procura reaproveitar o texto original. Porém, talvez a Vaga 1 não seja para um data scientist. Me parece que esta descrição a seguir tem mais relação com o contexto “desenvolver soluções de BI usando NLP e Data Mining”:

Vaga 1′: Engenheiro de Computação

Descrição: desenvolver sistemas de Processamento de Linguagem Natural para interpretar demandas de negócio e traduzi-las em análises de dados e em processos automáticos ou semi-automáticos de Data Mining. Requisitos: dominar linguagens C++, Rust e JavaScript; familiariedade com APIs; conhecer e empregar os toolkits de IA em nuvem, como Google IA , AWS Machine Learning, TensorFlow, DataRobot e outros.

Algo conspicuamente ausente é o já habitual cabedal de proficiências contemporâneas, como algum tipo de habilidade Ágil (metodologias, ferramentas etc.), CI/CD, infra-como-código e outros quejandos. Como é uma vaga de BI e sabemos que BI é um bicho resistente à essas modernidades, talvez não seja uma ausência notável, no final.

Não Mande Seu Currículo!

… por que eu não estou contratando ;-) .

Eu comecei o blog porque eu ouvia muita opinião e precisava expressar a minha (mas ninguém queria me ouvir kkkk). Então, tudo aqui é um exercício de auto-expressão, de emitir uma opinião particular, sem intencionar um fim ou falar para alguém.

Eu fiz essa análise para registrar minha posição sobre uma oportunidade de trabalho em um mercado que, me parece, está cada vez mais confuso e bagunçado, mas longe de mim querer dizer o que é certo ou errado.

Eu tentei disfarça a vaga, mas se você – o dono desse anúncio – estiver aborrecido com estas mal-traçadas, por favor, me chame no LinkedIn e eu retirarei o post do ar no mesmo instante. Fechado? ;-)

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!

:-)

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:

  1. Time de BI não tem voz ativa na condução do projeto
  2. Time gradualmente perde autonomia para tomar decisões de projeto/técnicas/ tecnológicas
  3. Uma demanda típica requer muito trabalho
  4. Uma demanda vai e volta várias vezes, até o usuário se dar por satisfeito
  5. Usuário prefere adotar soluções manuais
  6. Usuários abandonam soluções rapidamente
  7. Valor percebido é pequeno
  8. A análise do problema é encerrada prematuramente
  9. A carreira do empregado corre risco
  10. A demanda não resolve o problema de negócio
  11. A empresa acredita que a solução do problema requer BI
  12. A empresa decide investir em um projeto de BI
  13. A empresa decide resolver o problema
  14. A empresa descobre um problema
  15. A fama de projetos de BI é ruim
  16. As consequências (EIs) são tomadas pelos problemas (as causas)
  17. A solução não resolve o problema de negócio
  18. Cada demanda tem aplicação limitada ao problema que a originou
  19. Cada problema resolvido expõe outro problema
  20. Capacidade do time e do gestor são questionadas
  21. Demandante questiona decisões técnicas
  22. Demandas demoram a ser atendidas
  23. Demandas têm pequena vida útil, tornando-se obsoletas rapidamente
  24. Desenvolvimento emprega muitas ferramentas
  25. Desenvolvimento requer muitos passos.
  26. Empregado é a causa do problema
  27. Empregado esconde a verdade
  28. Empregado sabota projeto
  29. Equipe de BI não é consultada para desenhar solução
  30. Existe pressão por resultados
  31. Gestor de BI sofre desgate de imagem
  32. Há a impressão de que projetos de BI não saem do lugar
  33. Objetivos são confusos
  34. O demandante desenha uma solução para o sintoma, e não para a causa
  35. O demandante não entende com clareza qual é seu problema de negócio
  36. O entregado não atende ao usuário
  37. O patrocinador do projeto se desgasta com atrasos e aumentos de custos
  38. O problema de negócio se manifesta através de EIs
  39. Projeto de BI sofre sabotagem branca
  40. Projetos de BI tendem a se alongar
  41. Retrabalho surge constantemente
  42. Sintomas podem mudar
  43. 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:

  1. Se “A empresa descobre um problema” então “O problema de negócio se manifesta através de EIs”;
  2. 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)”;
  3. 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”
  4. 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! :-)

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:

Início do post.

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