O problema é que não entendemos o problema

Essa frase é de Paul MacCready, considerado um dos melhores engenheiros mecânicos aeronáuticos do século XX. Interessante, não é? Quantas vezes estamos tão envolvidos na solução dos problemas de maneira rápida que nem ao menos paramos por algum tempo para verificar se realmente entendemos o problema.

Em 1959, o magnata britânico Henry Kremer lançou um desafio ao mundo: um avião pode voar movido apenas pela força do corpo do piloto? Como ele acreditava que era possível, ofereceu 50 mil libras para quem construísse um aparelho que pudesse voar um número oito em torno de dois marcadores a meia milha de distância. Além disso, ofereceu 100 mil libras para a primeira pessoa a voar pelo canal. Em dólares americanos modernos, digamos que isso equivaleria hoje a US$ 1,3 milhão e US$ 2,5 milhões.

Dezoito anos depois, Paul MacCready decidiu tentar. Ele decidiu partir seu projeto da análise do porquê as outras soluções haviam falhado e não buscar solucionar a resolução para a questão fim: um avião pode voar movido apenas pela força do corpo do piloto? Quando analisou o problema, verificou como as soluções anteriores falharam e como as pessoas repetiram os projetos.

Na minha visão, o que Paul realmente fez, àquela época, foi aplicar os conceitos de Design Thinking: Empatia, Definição, Ideia, Prototipação e Teste. O engenheiro chegou à conclusão de que as pessoas estavam resolvendo o problema errado. “O problema é”, disse ele, “que não entendemos o problema”.

O insight de MacCready foi que todos os que trabalhavam na solução de voos movidos por humanos passavam mais de um ano construindo um avião em conjecturas e teorias sem o embasamento de testes empíricos. Com sucesso, eles completavam o projeto e o levavam para teste. Minutos depois, um ano de trabalho era esmagado no chão. Mesmo voos bem-sucedidos terminavam com o piloto exausto fisicamente. Depois do fracasso, a equipe trabalhava por mais um ano para reconstruir, testar novamente, reaprender. O progresso era lento por razões óbvias, mas isso era de se esperar na busca de uma solução tão difícil.

Paul então percebeu que o que precisava ser resolvido era o processo e a busca de um objetivo sem a compreensão de como enfrentar desafios difíceis. Ele apresentou um novo problema e se propôs a resolver: como construir um avião que poderia ser reconstruído em horas e não meses. E ele fez. Ele construiu um avião com uma espécie de plástico transparente, tubos de alumínio e arame.

Os primeiros aviões não funcionaram. Mas, como o problema era criar um avião que poderia ser consertado em horas, Paul conseguia resolver rapidamente. O ciclo de reconstrução, de testar novamente e de reaprendizagem passou de meses e anos para horas e dias. Aqui vejo novamente o conceito atual de Design Thinking: “Falhe com rapidez e frequência, depois volte para a prancheta e faça melhorias onde você falhou. Os protótipos passam por várias iterações nas quais o feedback dos usuários é incorporado e as alterações são feitas para chegar a uma solução final eficaz”.

Através de caso vemos que anos se passaram até que Paul MacCready mudasse o entendimento do problema a ser resolvido e conseguisse construir um avião movido apenas pela força do corpo do piloto. Meio ano depois, o Gossamer Condor da MacCready voou 2.172 metros para ganhar o prêmio. Pouco mais de um ano depois disso, o Gossamer Albatross voou pelo canal.

E a que conclusão chegamos? Quando estiver resolvendo um problema difícil, refaça a pergunta para que sua solução o ajude a aprender mais rapidamente. Encontre uma maneira rápida de falhar, recuperar e tentar novamente. Se o problema que você está tentando resolver envolve a criação de uma grande obra, você pode estar resolvendo o problema errado!

*Por Fabio Reginaldo, diretor de Serviços Latam da NICE