Algo que merece ser discutido na criação de produtos, quiçá na vida, são os vieses de confirmação, efeitos psicológicos e outros desafios que nossa mente fica suscetível quando temos que criar novos produtos e serviços. De certa forma, os vieses não são ruins, é apenas o nosso cérebro criando alguns atalhos para reduzir esforço e carga cognitiva. Entretanto, para quem cria produtos e serviços, é sempre bom ficar atento quando estamos entrando por algum viés.
Neste Artigo
Minha ideia neste artigo não é criar uma lista exaustiva desses efeitos, mesmo porque creio que seria impossível. A imagem abaixo apresenta uma lista quase completa de vieses cognitivos.
A Wikimedia permite que você navegue pela imagem, basta ver o artigo neste link aqui.
Neste artigo apresento o TOP 5 segundo os critérios do Avelino mesmo. Pode ser que não sejam o que mais aconteçam, mas são aqueles que percebo que acontecem com bastante frequência.
Viés do Otimismo
Também conhecido como Viés do Otimismo Excessivo ou Tendência de sonho de conto de fadas. É muito comum no início de novos projetos. Uma área da organização acaba de ganhar um orçamento para fazer o Projeto XPTO, ela contrata um monte de gente, monta um time bacana e deixa todos empolgados.
Nesse otimismo costuma a aparecer a Análise SWOT (strengths, weaknesses, opportunities e threats) que, particularmente, prefiro o nome em português: FOFA (forças, oportunidades, fraquezas e ameaças). É uma partida que eu diria ser injusta. Forças e Oportunidades costumam superar em muito as Fraquezas e Ameaças.
Já estive em um projeto que começou com um belo coquetel e quando fizemos algumas contas básicas, descobrimos que o resultado dele não pagaria sequer o custo de operação do serviço. Nem precisa dizer o rolo que deu para encerrar o projeto antes que consumisse ainda mais dinheiro.
Não me entenda mal, é sempre bom ter certo otimismo no início de algo novo, porém não podemos confundir otimismo com irresponsabilidade. Precisamos de métricas, métricas e mais métricas antes de começarmos o desenvolvimento. Além disso, a ideia de que precisamos construir produtos rápidos e que possam ser invalidados, isso mesmo, invalidados, é fundamental. Falamos um pouquinho sobre invalidações no artigo sobre MVP. Além disso, temos que conhecer o mercado onde iremos atuar, qual o share (fatia) no mercado onde nossa empresa atual, se há demanda para o projeto etc. Sem isso, sobra otimismo e falta realidade.
Viés do Pessimismo
Também conhecido como Viés do Pessimismo Excessivo ou Tendência do Caminho da Perdição. É o extremo oposto ao Viés do Otimismo. Aqui a conversa nem começa e as pessoas já acham que vai dar tudo errado. “Porque quando tentamos isso em 1989 não deu certo”; “já trabalhei em uma empresa que fez isso e ela acabou falindo” e coisas semelhantes. Provavelmente você já teve vontade de espalhar esse distintivo abaixo entre algumas pessoas da sua equipe.
Não ignore os pessimistas, eles podem ter informações importantes. Entretanto, evite entrar na marcha da morte com eles. Assim como métricas, invalidações e compreensão do mercado afastam o otimismo exacerbado, as mesmas coisas afastam o pessimismo extremo.
Viés da Confirmação
Meu favorito. Nos dois anteriores falei como métricas podem ser utilizadas para afastar vieses. Até aqui tudo bem, mas as métricas também podem ser utilizadas para o mal. Por exemplo, para confirmar suposições olhando apenas para os dados que interessam enquanto preferimos não ver aqueles que discordam dos nossos pressupostos.
O viés da confirmação é um dos mais estudados e que mais aparece no nosso mundo digital. Principalmente agora com a divisão política entre esquerda e direita. Dependendo do seu ponto de vista político, você tenderá a buscar números, fatos e narrativas que confirmem o seu ponto de vista.
Coisa semelhante acontece em nossos projetos. Quando olhamos para um tema e gostamos do que vemos, é normal corrermos atrás de números que corroboram com o nosso ponto de vista e ignorarmos aqueles que discordam de nós. Se não gostamos, faremos o contrário. Infelizmente este é um viés muito humano e a única forma de combatermos é estarmos cientes de que ele existe e quando ele está agindo. Recomendo a leitura desses livros.
Como mentir com Estatística de Darrell Huff, um clássico, e The Tyranny of Metrics de Jerry Z. Muller, em inglês apenas, são importantíssimos para você entender como as métricas, quando mal utilizadas, podem fazer com que você entre em lugares terríveis. Também te ajudam a entender melhor quando você está sendo manipulado ou se manipulando para acreditar naquilo que a pessoa, ou você mesmo, quer acreditar. Já o Teste da Mãe de Rob Fitzpatrick ensina a invalidar ou validar produtos através de técnicas que evitam o viés de confirmação. Por fim, A Startup Enxuta de Eric Ries, outro clássico, ensina a ver quando estamos utilizando Métricas da Vaidade para “comprovar” suposições sem bases sólidas.
Viés de sobrevivência
Lembra o viés da confirmação, porém tem algumas diferenças. Na confirmação nós queremos achar dados que corroborem com o ponto de vista e contrariem o que somos contrários e fazemos isso de forma ativa. Já o Viés da Sobrevivência nós focamos apenas em parte dos dados que demonstram sucessos passados e ignoramos aqueles que representaram fracassos.
Esse viés ficou famoso com o experimento acontecido com bombardeiros americanos, em 1943, durante a 2ª Guerra Mundial por Abraham Wald: A Method of Estimating Plane Vulnerability Based on Damage of Survivors. Durante a guerra, pediram para que os fabricantes de bombardeiros olhassem quais os pontos que deviam ser reforçados na fuselagem do avião para que eles, quando fossem alvejados, não caíssem. Eles fizeram um levantamento dos aviões que retornaram com perfurações e concluíram o seguinte desenho:
Talvez você já tenha se tocado no problema. O esquema acima mostra apenas os aviões que conseguiram retornar, mas ignora completamente aqueles abatidos em combate porque foram alvejados em partes vitais. Seria menos ruim, multiplicar a imagem por -1 e reforçar justamente os pontos onde não há marcas de balas.
Nas empresas ainda temos muito o viés da sobrevivência. Investimentos pesados feitos em um mercado com empresas que já possuem um “campeão”. Por exemplo, olhamos para os números da Uber e parece que é uma excelente ideia criar um aplicativo de carona. Entretanto, ignoramos as dezenas ou centenas de empresas que tentaram criar um aplicativo de carona e faliram ou descontinuaram o produto.
Ao criar algo novo é importante verificar também o que não deu certo em outras empresas ou até mesmo dentro da empresa. Pelo menos, você terá uma ideia melhor de onde você reforçará a ideia.
Paradoxo da Escolha
Você acabou de se tornar o Product Owner de uma empresa. Como um jogador de futebol que chega em um novo clube, no dia da apresentação é tudo uma maravilha. Você é bem recebido, crachá novo, talvez uma festa ou até mesmo um bolinho de boas-vindas. Passada a festa você ganha acesso ao Product Backlog, abre e pááá!!!! 256 itens para você Fatiar, Descartar e Priorizar. O recorde que eu já vi de um backlog eram mais de 4.000 itens. Como diria o Grupo Raça:
Aí vem o desespero
Grupo Raça, Eu Menti.
Machucando o coração
Em um primeiro momento, nós dizemos que gostaríamos de ter muitas opções, mas na verdade, nosso cérebro não foi feito para operar avaliando múltiplas possibilidades simultaneamente. Basta fazer um teste: Priorize as três cidades que você gostaria de visitar na Europa. Agora priorize as dez cidades que você gostaria de visitar no mundo. Provavelmente a segunda será muito mais difícil. Se é que você não desistiu antes de concluir porque as cidades entre 7 e 10 ficam difíceis de escolher e priorizar.
Veja o exemplo do McDonalds, o menu é pequeno justamente para evitar a) que os clientes sofram com o Paradoxo da Escolha; b) para que reduzir o Customer Lead Time (tempo de espera) dos clientes. Tenho como contraexemplo um restaurante super tradicional aqui no Rio de Janeiro que existe há quase 150 anos. O menu deles oferece opções que vão desde mingau até Bacalhau à Minhota. Em todas as vezes que fui lá, sempre peço o mesmo prato. Eu gosto de comer coisas novas, mas não tenho paciência para folhear páginas e mais páginas do menu. Veja que isso não o impediu de ser um restaurante centenário, mas não o transformou em um McDonalds.
Logo, se temos no nosso portfólio muitos projetos ou no nosso backlog, muitos itens, temos que descartar tudo o que for possível.
Workshop de Despriorização e Descarte
A K21 tem um Workshop de Despriorização e Descarte de projetos para ajudar nesse tipo de trabalho.
1. Começamos levantando critérios que são importantes para que um projeto entre no portfólio.
2. Buscamos acordo com os envolvidos no processo de despriorização e descarte. Estabelecemos metas mínimas para o Não-descarte. É importante definir antes, porque se a meta ficar aberta, você terá que enfrentar choradeira das pessoas que tiveram seus projetos descartados. Como diz a máxima: “o combinado não sai caro”.
3. Definimos um corte que é compatível com o número de times disponíveis para a construção do projeto. Um pouco mais do que o dobro de times. Por exemplo, se temos 10 times para construir os projetos, serão selecionados algo entre 20 e 22 projetos no máximo.
4. Agora, através de métricas objetivas e subjetivas avaliamos cada projeto. Aqueles que não atingiram a meta inicial, são descartados.
5. A priorização é feita de acordo com a pontuação dos critérios.
6. Descarta os projetos que ficaram fora do corte (Item 3).
7. Pronto, você tem o portfólio de projetos para o ano. Com um detalhe, se temos 10 times e priorizamos 20 projetos, o 11º projeto só começa quando um dos 10 anteriores acabar. Sem paralelismo.
Tivemos uma experiência muito boa com a Bradesco Seguros Auto e Ramos Elementares. Eles tinham 260 projetos. No Workshop de Despriorização e Descarte foram jogados fora 248 projetos (+95%) dos projetos de 2017. Sobraram 12 para serem construídos pelos 6 times, sendo que o 7º projeto só começaria quando um dos seis primeiros terminasse. Resultado, enquanto o mercado de seguros teve uma retração naquele ano, eles cresceram 2 dígitos. Altíssimo foco no que dá resultado.
Pense nisso quando estiver criando um produto e incluindo funcionalidades em cima de funcionalidades.
