Não existe problema complexo

Dias atrás fomos apresentados ao novo logo do Google que se visualmente não apresenta uma diferença drástica em relação ao anterior teve uma redução considerável em termos de tamanho. Antes a versão do logo ocupava cerca de 14 mil bytes e agora ocupa apenas 305 bytes. Ok, mas e daí? Com isso uma das páginas mais acessadas do mundo, a home do buscador, poderá ser carregada de uma maneira muito mais rápida! Lendo sobre essa notícia pensei: cara que ideia simples e ao mesmo tempo genial! Outras soluções poderiam ser dadas para tornar o acesso mais rápido como uso de novas tecnologias ou novos algoritmos, mas provavelmente nenhuma mais barata e simples como essa. Ao mesmo tempo também levantei uma questão: será que no nosso dia-a-dia pessoal e profissional buscamos a solução ideal ou apenas usamos a que está mais na moda? Será que somos educados da forma apropriada para resolver problemas?

Resolvemos problemas a todo o tempo. Alguns mais triviais e outros nem tanto. Esses últimos, os problemas complexos acabam por consumir nossas energias diárias. Uma forma de resolver problemas complexos e conseguir soluções simples e eficientes, como do exemplo da Google, é utilizar uma técnica também utilizada para escrever algoritmos computacionais: a técnica top-down de resolução de problemas.

O que é essa técnica top-down? A técnica top-down consiste em resolver problemas complexos pensando-os como uma coleção de problemas simples. É como se fosse a fatoração de um único problema em uma série de problemas mais simples. Sempre que se tenha algum problema que parece ser de difícil solução é prudente questionar: qual é realmente o problema que deve ser resolvido? Entender o problema e buscar novas informações são passos para obter uma série de microproblemas que compõe o problema principal, que é o objetivo da técnica top-down. Esses problemas fazem parte do conjunto de problemas que apresentam soluções simples e ideais e com essa coleção de soluções simples e ideias a melhor solução para um problema complexo poderá ser alcançada. 

O grande problema é que na prática poucas pessoas acabam utilizando dessa forma de raciocínio para lidar com problemas. O motivo? O uso de soluções já prontas e por vezes mirabolantes que, na maioria das vezes, não são as melhores. Parecemos estar vivendo na época da epidemia de preguiça intelectual. Informações volumosas e rápidas nos tornam cada vez mais meros receptores sem critério. Resolver problemas da forma abordada aqui pode não ser a mais fácil, porém a genialidade das coisas está em como as tornamos simples. E você, topa o desafio?

A Cauda Longa para as Instituições Bancárias

Nota do autor:

Recentemente (para ser mais preciso, hoje) publiquei o artigo inaugural na minha nova coluna sobre usabilidade no Dicas-L. O artigo se chama “A Cauda Longa para a Usabilidade”.

Apesar do tema ter sido usado lá primeiro a verdade é que este artigo (a Cauda Longa para as Instituições Bancárias) foi escrito antes, com alguns dias de antecedência. Ele surgiu quando, em uma conversa sobre a inteligência competitiva das organizações surgiu a pergunta: “como os bancos poderiam se adequar melhor aos clientes do futuro?”.

Na mesma hora o texto abaixo surgiu em minha cabeça, pronto e acabado. Reproduzo-o aqui pois considerei ser uma visão interessante sobre como os bancos farão negócio no futuro.

Também usei a Cauda Longa como tema no Dicas-L pois considero o assunto  interessantíssimo, de extrema relevância na sociedade atual e por acreditar que ainda falta muito a ser explorado sobre isso.

Agora o artigo de verdade:

Basicamente, o resultado da Cauda Longa é a máxima personalização dos produtos e serviços, levando a uma adequação perfeita das necessidades dos usuários. Em ultima instância, seria como voltar a fabricar tudo sob medida para os consumidores (atendendo os desejos destes) mas com grande vantagem econômica para os produtores (maximização do lucro, economia com estoque e sobras de produção).

Hoje os bancos continuam calculando riscos e oferecendo serviços baseados em grandes grupos de consumidores: classes A, B, C, D e E, por exemplo. Entretanto, os clientes obteriam muito mais vantagens se fossem separados em nichos mais específicos levando em consideração mais variáveis, como histórico de compras, local de residência, etc. E, com clientes obtendo mais vantagens e consumindo mais serviços bancários, os Bancos também lucrariam mais.

Uma indústria que já se beneficia desta segmentação é a de seguros automotivos. O seguro é fortemente baseado em nichos bastante específicos (embora ainda possa melhorar muito) e utiliza centenas de variáveis para calcular o preço de uma apólice (distância percorrida diariamente, local de residência, local de trabalho, tipo de alarme, faixa etária, modelo do veículo, cor, etc, etc).

O seguro conseguiu atingir este alto grau de personalização pois utiliza vários processos automatizados para calcular os preços, utilizando inclusive técnicas estatísticas, de calculo diferencial e integral, álgebra, etc.

Os bancos, por outro lado, ainda continuam calculando taxas de juros para empréstimo e de risco levando em conta grandes tendências e grupos com milhões de pessoas e fazendo análises de risco manualmente.

Por que a taxa de um empréstimo para uma mulher de 25 anos que mora no Distrito federal e quer comprar uma TV tem que ser a mesma de um homem de 30 anos que mora em Santa Catarina e quer comprar um iPad para trabalhar? A renda dos dois é a mesma, o valor do empréstimo é o mesmo, mas os perfis são outros, históricos de compra diferentes e o objetivo final do empréstimo também.

Com a cauda longa seria possível criar taxas diferenciadas para atrair perfis diferentes de clientes com um preço quase zero, pois a segmentação seria feita a partir de um questionário e as variáveis analisadas e calculada pelo computador, diminuindo em muito o trabalho braçal da análise de riscos, por exemplo.

Sobre biquinis e lingeries

Essa semana nosso colunista (que começou a escrever sobre si mesmo na terceira pessoa, sem motivo aparente) resolveu falar sobre moda intima e de praia e a sua (aparentemente desconexa) relação com o desenvolvimento de sistemas, a vida, o universo e tudo mais.

Antes de começar nossa análise, vamos primeiro passar por um momento de observação/reflexão: analise a foto abaixo. Qual das duas garotas está vestindo um biquíni e qual está vestindo lingerie?

Hey caras! Continuem a ler o artigo, por favor!

Tenho certeza que foi bastante desafiador (até para os que conseguiram prestar atenção nas vestimentas) distinguir quem vestia o biquíni e quem vestia a lingerie. Por quê?

Bom, para começar, visualmente as duas peças de roupa são bastante semelhantes. Embora conceitualmente separadas em diversos aspectos (roupa de banho versus roupa intima, por exemplo) quando colocamos os dois modelos acima lado a lado, em ambientes semelhantes, a maior parte das diferenças desaparece e um paradigma é quebrado.

Quantas ações em nosso dia-a-dia são limitadas por conceitos que não fariam a menor diferença caso fossem removidos? Quantos paradigmas poderiam ser quebrados, diariamente, se simplesmente prestássemos atenção para as regras que não fariam a menor falta?

Vamos pensar um pouco no mundo da tecnologia. Alguém ai pode me dizer, de verdade, qual a diferença entre Java e C#? Vistas de fora em um ambiente semelhante, as duas parecem a mesma coisa: são orientadas a objeto, baseadas em C/C++, rodam sob máquinas virtuais (eu sempre machuco os sentimentos de alguém quando digo que o .NET Framework é uma máquina virtual… desculpem), tem performance semelhante e para os usuários finais parecem exatamente a mesma coisa.

Muitas das regras que seguimos ou que prestamos atenção fazem sentido apenas dentro de um contexto específico. Quando tentamos generalizar ou entender seus princípios vemos que não há razão para manter a distinção entre as regras.

Que tal discutirmos (superficialmente) a diferença entre desenvolvimento cascata e espiral? Sério. Ninguém nunca disse que ao desenvolver em cascata você precisa fazer uma única, gigante e normalmente acima do custo e prazo iniciais, entrega. Você pode muito bem fazer vários mini projetos em cascata obtendo os mesmos benefícios do desenvolvimento espiral: diminuição da curva de mudanças, agilidade nas entregas e disponibilização de melhorias para as áreas de negócio.

As diferenças reais estão apenas nos conceitos: definições limitadoras que muitas vezes não fariam falta mas que limitam nossa liberdade na tomada de decisão e que diminuem a agilidade e capacidade de pensarmos fora da caixa.

Então, da próxima vez que for escolher uma metodologia, modelo de desenvolvimento, linguagem de programação, framework ou simplesmente a roupa que irá usar para sair, pare e pense: será que estou sendo limitado por um conceito sem importância e que não faria falta se não existisse?

Se a resposta for sim, parabéns, você acabou de quebrar um paradigma e tornar o mundo um lugar mais fácil para se viver.

____________

Ah! E, para aqueles que ficaram na dúvida, as duas fotos acima eram de lingeries.