Pareto foi Engenheiro Civil, não Analista de Sistemas

E ele nunca entregou um ferrovia com apenas 80% da construção concluída. #ficaDica

Vilfredo Pareto

Ele também foi sociólogo, filósofo, cientista político e economista. Por onde passou, deixou um legado de conceitos e princípios que são usados (e abusados) até hoje!

His legacy as an economist was profound. Partly because of him, the field evolved from a branch of moral philosophy as practised by Adam Smith into a data intensive field of scientific research and mathematical equations.

Benoit Mandelbrot

Entre suas contribuições (e foram muitas), destaco:

Distribuição de Pareto

• É uma distribuição de probabilidade de Lei de Potência que atualmente é usada para descrever fenômenos sociais, científicos, geofísicos, atuariais e outros.
• Se você não entendeu p* nenhuma, não se sinta só. Eu também não entendi muita coisa.
• Foi usada por Pareto para seus estudos econômicos sobre distribuição de riqueza.

Ótimo de Pareto

• O Ótimo de Pareto é um estado de alocação de recursos onde é impossível melhorar as condições de um indivíduo sem piorar as condições de outro(s).
• Uma "Melhoria de Pareto" (Pareto Improvement) é quando um indivíduo tem seu estado melhorado sem o detrimento do estado de outro(s) indivíduo(s).
• Não é uma classificação moral ou ética - é simplesmente o reconhecimento de um fato, a partir do qual outras decisões podem ser tomadas!

E o famoso Princípio de Pareto

• Também conhecida como a regra do 80-20, distribuição A-B-C, lei dos poucos vitais ou  principio de escassez do fator.
• A que darei destaque abaixo.

Logo de cara, um leitor atento notará que dos links acima, apenas um está em português, justamente o Princípio de Pareto - e isso já dá o tom do que virá pela frente. Todos os demais artigos não foram traduzidos, ou estão apenas germinados, resumidos e sem fontes confiáveis (de acordo com a Wikipedia) em nossa língua.

Não fiquei surpreso pela falta de interesse do lusófono em se informar sobre estes assuntos... Estudar a Distribuição da Riqueza, ou buscar evitar situações de soma zero não costuma fazer parte de nossas preocupações - mas isso em si já é assunto para outro post (possivelmente em outro blog!).

Hoje, eu falo sobre o Princípio de Pareto, e dos efeitos terríveis que a aplicação burra e cega da sua máxima vem causando na economia e no futuro da Tecnologia da Informação - ou... Como burros motivados, lendo apenas *uma linha* da teoria, a saem aplicando ad nauseam sobre qualquer pretexto, desde que para livrar seus ignóbeis rabos de merecido destino.

Pausa Dramática para troca de Cenário

Após uns 8 meses de trabalho (e retrabalho) insano, ficou óbvio que o Novo Sistema™ não ficaria pronto dentro do prazo acordado com o então Futuro Cliente. Pior, os esforços de desenvolvimento estavam prejudicando a manutenção do Sistema Legado™ - que apesar de todos os problemas (que não eram poucos), era o que convencia os então Presente Clientes a pagarem nossos salários no fim do mês.

Reuniões, Planos de Contingência, e então o golpe fatal: o cara usou Pareto.

Para entender o tamanho do sacrilégio - e o motivo pelo qual o cadáver de Signore Vilfredo provavelmente deu mais voltas dentro em seu caixão que a Lua em volta da Terra, permita-me a Platéia uma breve explicação.

O Princípio de Pareto afirma que, para muitos eventos, cerca de 80% dos efeitos vêm de 20% das causas, observação feita enquanto na Universidade de Lausanne em 1896, conforme publicado em seu primeiro papel, "Cours d'économie politique". Essencialmente, Pareto mostrou que aproximadamente 80% das terras em Itália era de propriedade de 20% da população: Pareto desenvolveu o princípio pela observação de que cerca de 20% das vargens no seu jardim continha 80% das ervilhas.

Posteriormente, e por vários autores, estendeu-se o Princípio observando-se que 80% das vendas de um negócio costuma vir de 20% dos clientes; que 80% dos problemas de um empreendimento de engenharia advém de 20% de causas comuns; que 80% dos problemas de um software estão relacionados à 20% dos requisitos; e por aí vai.

As duas últimas afirmações levam à um interessante corolário: a de que detectar e sanar os tais 20% de causas eliminam 80% dos problemas que infernizam o projeto, mitigando seus riscos!

Um vez esclarecido o assunto, voltemos ao nosso roteiro original: o cara usou Pareto.

Através de um intenso processo de racionalização descolada da realidade (nenhum sistema lógico é válido, por mais sonora que seja a corretude dos processos, se seus axiomas são falsos!), concluiu-se que deveríamos tratar 80% dos problemas que estivessem afetando os 20% maiores clientes e então estaríamos protegidos pelo Cânone Metafísico de Pareto - a variante sobrenatural do Princípio que afirma que recorrer ao Signore Vilfredo em nossas preces, digo, estratégias garante-nos sucesso divino.

Como se os 20% maiores clientes da empresa estivessem pagando apenas 80% da tarifa - ou se não precisássemos dos demais 80% dos clientes para ter lucro no fim do mês.

E foi assim, prezados, que o então Futuro Cliente se tornou Presente Cliente de outrem, bem como boa parte daqueles nossos 80%. Não tenho a menor dúvida que fizemos felizes 100% de nossos concorrentes.

Quem paga 100% da tarifa quer 100% do serviço/produto/whatever. PONTO. Entregar 80% do acordado não é uma estratégia sustentável de captação e fidelização de clientes.

E, por fim, você não quer que aqueles tais 20% se tornem 100% da sua clientela. Confiem neste que vos narra, eles são a causa de 80% dos seus problemas. :-)

Vaidade, vaidade - Tudo é vaidade...

O que há com esta geração com menos de 30, 35 anos? Possuem uma autoestima tão exacerbada (ou uma baixa autoestima tão patológica que precisam provar à todos o tempo todo o quanto se amam) que são incapazes de reconhecer que existe coisas mais importantes que eles próprios?

Então um mantenedor de um projeto interesse cai no lado negro dos mantenedores de um outro projeto do qual o cara era fã - ele construiu algo tão bacana quanto, e os carinhas ficaram de mau e não o chamaram mais para as festinhas.

Ok. Sacanagem. Alijaram ele de uma Comunidade, e propaganda é a alma do negócio.

Mas daí o cara vai lá e derruba o projeto dele, porque ele não se sente bem fazendo algo que promova o projeto dos carinhas que machucaram seu coraçãozinho...

Crianças, aprendam com o titio Lisias: amor, amizade e acolhimento se procura de quem lhe ama, lhe tem apreço e gosta de você.

Com o resto, você convive e colabora em troca de um benefício mútuo - e se você gosta dos caras ou eles de você é, francamente, irrelevante. Ótimo se rolar, mas irrelevante assim mesmo.

Quando você derruba um projeto grande porque não quer mais jogar confete nos seus desafetos, você não está cuspindo nos seus desafetos, mas nos seus usuários. São eles que ficaram sem o projeto, são eles que confiaram em você e por isso ficaram na mão.

Se você mija em todo mundo porque uns poucos mijaram em você - isso não te faz alguém algumas ordens de magnetude pior que eles? 

Unit Testing - Ou como jogar tempo e dinheiro fora e ainda ir pra casa com a sensação de Dever Cumprido.

Fonte. Giphy.

Testes de Unidade.

Que invenção maravilhosa - todos os mais comuns erros detectados antes mesmo do push.

Ficaram no passado as longas horas de debugging, o tempo desperdiçado escrevendo documentação, os recursos desviados fazendo testes de aceitação antes do deploy.

Só que não. :-)

Há long time ago, in a job far, far away eu fiz parte de um time de desenvolvimento bem interessante. A diversidade de talentos e níveis de experiência era bem alta (o que é bom!!!), mas por outro lado, a consolidação de uma cultura rígida e dogmática num ambiente dito ágil levava regularmente ao uso... pouco ortodoxo... das práticas da metodologia que achavam que estavam aplicando.

Paradoxal? Com certeza! Participei de equipes sob RUP bem mais flexíveis!

Uma destas práticas era o Teste de Unidade.

Quase 50% do esforço de desenvolvimento era gasto em Testes de Unidade, numa tentativa de se economizar esforço em Documentação e Requisitos. O Código era a Documentação, e havia um "Teste de Unidade" para cada Use Case.

A teoria até que faz sentido - é fato que, no primeiro gargalo, a documentação é a primeira vítima porque os recursos são desviados para onde se efetivamente agrega valor ao produto, código. Mas existe uma coisa chamada Requisito Não Funcional, e isto não se documenta com eficácia num Teste de Unidade.

Pior, Testes de Unidade também são código, e portanto acabam duplicando o esforço de programação quando um Requisito Funcional acaba tendo que ser mudado - o que leva à uma resistência dos gestores em admitir mudanças em features já implementadas (afinal, vai custar o dobro!) e... bom... acaba sufocando o principal objetivo da Metodologia, que é a agilidade.

Alguns Requisitos são mais baratos de serem mantidos com o trio Documentação, Teste e Código (esta tríplice aliança ainda será discutida neste blog!) - há mais profissionais disponíveis na empresa capacitados nos dois primeiros que no último (pense nisso!).

O pessoal chegava à um nível de detalhamento absurdo - fazendo Testes de Unidade para o CRUD no banco de dados! Vá pra porra, se você não confia no BD e/ou no framework (afinal, estes componentes possuem seu próprio ciclo de vida e foram aprovados em algum momento, não?), então você não deve usá-los em produção e ponto final!

Isso adicionalmente causava um overhead de (estou chutando) 10 a 15% no tempo de processamento dos Testes de Aceitação e, pior, davam uma sensação de falsa segurança - porque a quantidade enorme de pequenos Testes De Unidade (que não testavam o core business da aplicação) que nunca falhavam mascaravam as fragilidades no Controle de Qualidade.

Um exemplo clássico e trágico é a historiazinha que segue:

A Aplicação Web em questão tinha uma estratificação entre os clientes: aqueles que consumiam muito mais conteúdo que geravam (quando o faziam), e os que geravam muito mais conteúdo do que consumiam. Óbvio que era vital para o Product Owner evitar situações (sejam técnicas ou políticas) que pudessem boicotar a facilidade com que o conteúdo pudesse ser consumido, mas principalmente ele precisava à todo custo desemperrar qualquer empecilho à criação deste conteúdo (sem os poucos que geraram conteúdo, não haveria o que consumir pelos demais clientes).

A Aplicação, então, tinha (entre outras, lógico), duas Health Metrics: a quantidade de usuários cadastrados, e a quantidade de conteúdo no sistema.

Parece óbvio. Era óbvio. Mas ainda assim....

No meio daquela mar de Testes de Unidade, ninguém se deu ao trabalho de fazer um Teste que garantisse que as métricas de conteúdo fossem corretamente atualizadas no Painel de Controle do Product Owner. Só isso. :-)

O P.O. tinha na mão as Histórias implementadas, e a informação de que os Testes de Unidade estavam todos sendo executados com 100% de aprovação. E confiou nisso (era responsabilidade da Equipe garantir a integridade dos Testes, não dele!).

Um belo dia, uma crise política qualquer (que, falemos francamente, é cotidiana - todo mundo adora um drama, e a concorrência óbvio que usa isso para fatiar o mercado e tirar o dela), ocorreu uma debandada de usuários. Já havia acontecido este #mimimi antes, e a crise tinha sido superada identificando, pelas métricas, quais grupos de usuários estavam debandando, e então mitigando pontualmente as causas.

Mas desta vez, o P.O. não conseguia acertar a mão. Nada do que ele fazia parecia dar certo. Levou-se umas duas semanas (se a memória não me falha) para se detectar o que estava acontecendo, e neste momento o estrago estava grande o suficiente para comprometer os objetivos estratégicos da empresa com a aplicação.

O que aconteceu é que, por questões de "performance", as métricas de conteúdo não estavam sendo atualizadas automaticamente (ou com a regularidade necessária, não lembro mais ao certo). O P.O. sabia que estava perdendo consumidores (porque estas métricas estavam funcionando), mas como as métricas de conteúdo estavam artificialmente boas, ele concluiu que precisava atuar na captação de consumidores, quando na verdade o problema é que ele precisava desesperadamente trabalhar para evitar o sangramento de produtores!!!

Do meu ponto de vista, a falha aqui foi a absoluta falta de preocupação com os Testes de Integração, necessários para garantir a corretude da implementação das Histórias. Achou-se que os Testes de Unidade eram suficientes, e ninguém empregou esforços para garantir a completude e corretude das Histórias.

O aftermath foi que, por estes e outros motivos, quando eu fui pedir ao gestor minha transferência da equipe (porque, francamente, eu já não confiava mais nela), fiquei sabendo que o P.O. também havia pedido a cabeça da equipe. :-D

O que aconteceu depois é papo para outra oportunidade. Hint: eu consegui o que pedi, mas não da forma que eu desejava! ;-)