Trio de problemas: Entendendo Design Thinking, Lean e Ágil

Jonny Schneider é praticante, autor, palestrante e líder motivado pela curiosidade e fascinado pelo "Porquê?" desde o início de algo, no desenvolvimento de interfaces e design de experiência até a gestão de produtos e liderança de design. Na conferência anual Agile Austrália 2017, Jonny comparou Design Thinking, Lean e Ágil. Citando seu próprio livro, Understanding Design Thinking, Lean, and Agile, e baseado nas lições aprendidas nas trincheiras, apresentou algumas diretrizes para trabalhar com outras equipes e aconselhou sobre o que evitar.

Para Jonny, criar produtos e serviços digitais é uma missão que requer colaboração entre diversas disciplinas; e para que os resultados sejam alcançados, é necessário trabalhar o mindset de crescimento focado em habilidade, aprendizagem e adaptação. É preciso explorar problemas complexos e encontrar oportunidades em um mundo cheio de incertezas, testar hipóteses por meio de ações, observar e realizar ajustes. A dinamicidade do mundo faz com que a solução atual não seja a solução ideal do futuro.

É preciso lutar para transformar cada ação em uma oportunidade de aprendizado com o objetivo de tomar decisões melhores, seja na entrega de software, no foco do sucesso do produto ou explorando as oportunidades e resolução de problemas. As metodologias estão auxiliando empresas a terem sucesso e, embora o Design Thinking, o Lean e o Ágil sejam mindsets proeminentes entre as equipes hoje em dia, cada uma dessas abordagens traz seu próprio valor no ciclo de vida do desenvolvimento.

Segundo Jonny, é preciso explorar os três mindsets trabalhando em conjunto para definir ações estratégicas, ações de aprendizagem, liderança de equipe para vencer e entrega soluções de software.

Como pensar - Design Thinking

Ao contrário do que uma simples busca pelo termo mostra, Design Thinking é muito mais do que linhas entrelaçadas, diagramas hexagonais, círculos sobrepostos ou loops de diagramas. Esses modelos ajudam a entender o conceito mas não a pensar de forma prática ou diferente. Este mindset também pode ser considerado um kit de ferramentas para designers explorarem novos territórios com a intenção de encontrar soluções potenciais para o problema.

Um exemplo citado por Jonny foi o de Donald Norman, autor dos livros The Design of Everyday Things e Godfather of user experience. Segundo Norman:

"Designers não buscam por uma solução até que tenham determinado o verdadeiro problema, mesmo após essa etapa ao invés de tentarem resolver o problema, eles buscam opções e consideram diversas soluções potenciais. Somente depois disso é que convergem sob uma proposta. Este processo é chamado de Design Thinking."

Neste exemplo, Norman mostra um certo descontentamento com a primeira solução e propõe uma reflexão: Quando foi a última vez que sua primeira ideia foi a melhor ideia? Normalmente, as primeiras ideias são o início e não o resultado final quando queremos resolver um problema. Quanto mais opções exploramos, mais soluções potenciais encontramos.

Jonny também explora a ideia do duplo diamante onde a intenção é divergir e convergir repetidamente. Este conceito foi explorado pelo Conselho Britânico de design em 2008 como parte de um estudo global sobre empresas que praticavam design, o "duplo diamante" é um modelo visual representado pela saída (divergência) e entrada (convergência) de informações para ajudar na definição do problema, adoção da estratégia inicial e potencial solução.

Trabalhar com Design Thinking não significa pensar em processos, é muito mais sobre pensar em habilidades. Jhony cita Carissa Carter, diretora de aprendizagem na Stanford Design School que escreveu sobre as habilidades que fazem bons designers. Segundo a autora, habilidade é como negociar com a ambiguidade, enfatizar a aprendizagem, sintetizar e experimentar enquanto processos e ferramentas são guias que nos ajudam a praticar nossas habilidades. Entretanto, o que faz um designer se tornar melhor é a prática e não o processo.

A prática constante do design chama-se emersão e a melhor explicação sobre isso vem de Dave Gray, coautor de Gamestorming: A Playbook for Innovators, Rulebreakers, and Changemakers. Segundo Gray, você nunca encontrará nada a menos que esteja procurando por algo.

De fato, é muito comum encontrar coisas novas ou até objetos perdidos quando estamos procurando por alguma outra coisa. Experimente procurar um livro em uma biblioteca que nunca tenha entrado antes, comece a busca sem pensar no padrão em que as prateleiras estão organizadas e em corredores aleatórios. É possível que encontra algo interessante por lá.

Sistema de trabalho - Lean

Existem diversos tipos de Lean como Lean startup, Lean Six Sigma, Lean Product, Lean Analytics, Lean UX, entre outros. O Lean veio de uma resposta científica para o gerenciamento industrial que utiliza processos de gestão e meios gerais para controlar pessoas.

Com a filosofia de melhorar qualquer sistema que produz valor, algumas das características deste mindset são redução de desperdício, persistência para melhoria e alto padrão de qualidade. Contudo, o pensamento Lean é melhor descrito por Jones e Womack. Segundo os autores, são comportamentos como melhoria contínua na qualidade do produto fabricado, eficiência através da reflexão e aprendizagem e organização do trabalho de acordo com a demanda do cliente que formam o pensamento Lean. Tudo isso pode ser encontrado no Sistema Toyota de Produção criado por Taiichi Ōno, com alguns valores apresentados na tabela abaixo:

Jonny acrescenta que não é possível se tornar Lean apenas seguindo fielmente o modelo da Toyota porque essa abordagem não é um procedimento, é cultural e exige mudanças. Entretanto, essa mudança não acontece simplesmente pedindo para as pessoas, é preciso que haja mudança no sistema e na cultura que existe ao redor delas, é preciso mudar os princípios e valores que motivam as pessoas.

Como trabalhar - Ágil

Assim como os mindsets anteriores, o Ágil também não é um processo. Baseados nos valores listados abaixo, é utilizado normalmente no desenvolvimento de software.

• Indivíduos e interações mais que processos e ferramentas;
• Software funcionando mais que documentação detalhada;
• Colaboração do cliente mais que negociação de contrato;
• Responder a mudanças mais que seguir um plano;

Embora o Lean seja normalmente associado a sistemas de trabalho e o Ágil ao desenvolvimento de software, existem algumas semelhanças entre estes dois mindsets. Ambos produzem valor de forma iterativa e em ciclos curtos, abraçam as mudanças independente do momento em que aconteçam, focam na qualidade e na eficiência, buscam melhoria através da reflexão e do aprendizado.

Podemos diferenciá-los nos seguintes aspectos: o Lean trabalha com fluxo contínuo para otimizar sistemas de trabalho enquanto o Ágil otimiza a entrega de software através de interações baseadas em ciclos de tempo. Outra característica fundamental para entendê-los é observar as entregas, sendo um sistema de trabalho para manufatura, o Lean produz constantemente o mesmo resultado, mesmo que o produto seja otimizado a cada iteração. Enquanto isso, o software não precisa estar necessariamente pronto no final da iteração, a cada ciclo uma pequena parte funcional deve ser entregue e isso permite que as respostas a mudança sejam uma característica única do Ágil.

Quando a mágica acontece

Para Jonny, estamos sempre construindo qualidade e ao juntar esses três mindsets é possível atingir melhores resultados. Para entender as restrições, enxergar oportunidades e explorar possibilidades e entregar valor para o usuário, podemos utilizar o mindset do Design Thinking. O Lean trabalha com experimentação contínua e aprendizagem na direção da resposta certa. Com esse mindset é possível identificar a coisa certa para perseguir e melhorar o sistema de trabalho que entrega o valor para o usuário. Por último, o Ágil explora a forma como criamos soluções de software e como fazemos isso da maneira certa, com este mindset estamos sempre adaptando e mudando para construir soluções de qualidade.

Juntos, o Design Thinking e o Lean podem nos ajudar a entender onde estamos e onde queremos chegar, nos ajudam a explorar o caminho utilizando o aprendizado e testando coisas. O Design Thinking e Ágil colaboram em entregas reais, construindo coisas possivelmente mais interessantes e que são valiosas para o cliente. Juntando o Ágil e o Lean, trabalhamos a estratégia de execução, o Lean nos fornece um framework para aprendizagem e o Ágil um caminho para responder o que aprendemos.

Proposta, alinhamento e autonomia

Seja teimoso em suas visões mas flexível nos detalhes." (Jeff Bezos)

Em sua apresentação, Jonny ressalta que é importante não esquecer a proposta do nosso trabalho, de que fazemos coisas para o cliente. É fácil perder o foco. Um bom exemplo é a clássica user story que utilizamos no Ágil: "Como cliente, quero me logar no sistema, então poderei fazer algo". Mas sou cliente e não quero fazer login, esta é uma afirmação equivocada sobre a intenção e valores para o cliente. Nenhum cliente deseja fazer login, pois querem alcançar alguma outra coisa.

Então como teremos certeza de que estamos alinhados com os objetivos do cliente? Uma forma de fazermos isso é utilizando a gestão visual, técnica simples que nos ajuda na proposta da comunicação permitindo a visualização do fluxo através de tudo o que estamos trabalhando. Alguns exemplos são as paredes de produtos, paredes de aprendizagem e diagramas de alinhamento. O livro chamado Mapeamento de Experiências: Um guia para criar valor por meio de jornadas, blueprints e diagramas de Jim Kalbach, mostra em torno de 30 versões diferentes desse tipo de trabalho e como utilizá-los em diferente situações para ajudar a conduzir a equipe.

Jonny cita as condições para criar autonomia descritas no livro Drive: The Surprising Truth about What Motivates Us de Daniel H. Pink. As pessoas precisam conduzir suas próprias vidas e tem necessidade de ser melhor em algo, buscam o propósito para fazer alguma coisa importante. Uma forma simples de fazer isso é enquadrando o que estamos fazendo em termos de resultados, contudo, resultados não são entregas.

Embora a IBM chame isso de Hills e Playbacks e os militares rotulem como missões, ambas seguem a ideia de setar um objetivo e dar às pessoas os recursos necessários para que possam alcançá-los. Nessa jornada, coisas inesperadas e desconhecidas vão acontecer e isso vai mostrar que não estamos falando sobre prever cada entrega ou circunstância, estamos falando sobre treinar pessoas para responder a qualquer situação. Esta é a verdadeira habilidade quando pensamos em Design Thinking, Lean e Agile. Não é sobre o processo, é sobre a habilidade.

Lições aprendidas

"Se mensurar tiver alguma importância é porque isso tem necessariamente um efeito imaginável no comportamento e nas decisões." (Douglas W. Hubbard)

Quando estamos medindo algo importante, é fácil medir coisas erradas, entretanto, medir é o caminho certo para tomar decisões certas. É preciso entender o que está sendo mensurado. Para saber se as coisas que estão sendo medidas irão ajudar na tomada de decisões, perguntas como essas podem ajudar:

• É possível medir?
• Isso vai ajudar a tomar decisões?
• Saberei que alcancei algo quando medir isso?
• Poderei parar quando chegar em algum ponto ou o esforço continuará?
• Está alinhado com os resultados do cliente?

Neste exemplo temos uma operação para facilitar a vida do cliente, vamos analisar como podemos medir o seguinte objetivo: Os clientes poderão encontrar facilmente o que estão procurando.

Outro exemplo exemplo citado por Jonny foi sua experiência com um consultor em uma central de contatos. As métricas baseavam-se na resolução da primeira chamada e no service score. Isso significa que quando o problema de um cliente estivesse resolvido o consultor deveria seguir o script e perguntar: "Existe mais alguma coisa em que eu possa ajudá-lo hoje?". Em uma determinada ocasião o cliente respondeu: "Na verdade tem sim, existe mais uma coisa para consertar". O consultor concordou, contudo, sugeriu concluir o primeiro chamado e solicitou que o cliente preenchesse o questionário de satisfação. Após 5 minutos, o consultor voltaria a ligar para o cliente e o transferiria para a pessoa que iria resolver o seguinte problema.

A razão pela qual o consultor decidiu fazer isso foi porque sabia que se a transferência fosse feita imediatamente, ele não seria reconhecido como primeira resolução. Então, se o próximo consultor falhasse no próximo atendimento, a experiência negativa iria refletir em sua avaliação. Ele sabia que separar as chamadas não afetaria seu tempo médio de trabalho que também seria medido. Como podemos observar estes indicadores de performance existem para ajudar o cliente a ter uma experiência melhor mas atualmente isso faz o oposto porque está medindo a coisa errada.

Tomar decisões baseadas no aprendizado

"Não olhe para fatos ou respostas, busque perguntas melhores. Essa é a pergunta que respondemos, o significado que exploramos e que irá gerar insights mais úteis para a estratégia." (Dr. Jason Fox)

Segundo Jonny, aprendemos pela mesma razão que medimos, para tomar decisões assertivas. Referindo-se a citação acima, Jonny acredita que a diferença entre buscar algo para validar e explorar algo para aprender é crítica. Um caminho interessante é ser mais intencional sobre o que se deseja aprender, defina suas crenças e premissas, decida o que é mais importante aprender e então desenhe os experimentos que irão fazê-lo aprender. Parece tão simples que normalmente não damos este único passo para nos ajudar a aprender e então tomar decisões.

O modelo Problema/Premissas criado por Jonny Schneider e Barry O'Reilly pode nos ajudar a perguntar qual é o problema, como podemos resolver, quais premissas assumimos em nossa solução e como testamos essas premissas.

O mais interessante neste modelo é que pode ser usado a partir do problema, da solução, da premissa ou das perguntas. Muitas pessoas iniciam em 'como podemos resolver isso', exploram o problema a ser resolvido e somente nos estágios avançados assumem premissas, ou seja, encontram a solução e depois pensam sobre o problema que está sendo resolvido.

Tenho o exemplo de um engajamento recente, estávamos trabalhando em uma cadência semanal focando em uma nova área a cada semana. Dividimos as semanas para entender os desafios, descobrir o que precisávamos aprender, desenhar experimentos, sair e interagir com pessoas, medir coisas, observar, aprender e descobrir o que deveria ser feito em seguida. Existem diversos caminhos para aprender e é possível fazer rápido.

• Segunda-feira - Modelar o desafio e explorar algumas opções.
• Terça-feira - Decidir o que aprender
• Quarta-feira - Desenhar os experimentos
• Quinta-feira - Conduzir as pesquisas
• Sexta-feira - Analisar os resultados e decidir o que fazer em seguida

Na imagem abaixo é possível imaginar o que isso parecia para nossa equipe, este engajamento em particular foi divertido. Esta é a foto da nossa parede de aprendizagem, a pessoa na foto é o Matt, que parece um pouco preocupado, a razão é que todas as nossas ideias falharam. Entretanto, todas elas vieram dentro de 6 semanas.

Como consultor foi um pouco difícil entender por que as ideias não funcionavam e isso não era exatamente o que os clientes esperavam. Não tínhamos nenhum sinal que isso valeria mais investimento e trabalhar dessa forma é muito desafiador. Contudo, ajudamos essa empresa a não investir um grande montante de dinheiro nas primeiras ideias e isso era um bom resultado.

Desenhar os experimentos certos para aprender a coisa certa

Após descobrir o que deve ser aprendido, é hora de entender como aprender. Quando iniciamos um experimento não devemos considerar apenas o custo monetário, existem outras coisas envolvidas como o tempo, esforço, as pessoas e recursos, além do dinheiro em si. A confiança é outro fator sensível porque os resultados dos testes darão maior confiança ao tipo de aprendizagem que está sendo feita e para a tomada de decisões. É interessante pensar se realmente estamos aprendendo sobre um problema, explorando uma solução ou testando uma demanda para aquela solução que irá nos ajudar a seguir em frente.

Cenários de baixa confiança e baixo custo como no caso da imagem acima talvez não sejam algo necessariamente ruim. Pode ser que o momento para uma tomada de decisão não deva ser baseado nos itens localizados nessa região. Algumas pessoas falam sobre triangulação de informações onde múltiplas fontes dariam mais confiança sobre o que está sendo feito. Contudo, não existe resposta certa para isso, é preciso entender o que estamos tentando aprender e utilizar as ferramentas certas que irão ajudar.

Tivemos uma experiência negativa com uma empresa de serviços financeiros, estávamos reconstruindo o serviço de experiência do cliente para esta empresa. Eles operam como corretores intermediando a isenção de impostos para consumidores internacionais. Portanto, se você fez uma viagem internacional e comprou algo e conseguiu reembolso no aeroporto, provavelmente negociou com uma empresa desse tipo.

Neste projeto, acreditamos que informar os passageiros sobre como proceder para ter o reembolso da taxa gratuita iria resultar no aumento da utilização do aplicativo, atingiríamos o objetivo quando o número de usuários ativos do protótipo aumentasse 6% e o nível de assertividade dos formulários enviados em 30%. Então elaboramos nossas hipóteses, parametrizamos, medimos coisas diferentes, fizemos protótipos nos sentindo presunçosos em relação ao que estávamos fazendo.

Embora pareça que estamos falando sobre aquisições, o objetivo era entender como fazer o trabalho de captação, como dar acesso a novos clientes e fazê-los utilizar a nova plataforma. Estávamos aprendendo e este experimento definitivamente não era sobre aquisições, a ideia era fazer com que o cliente aderisse à otimização, duas coisas bem diferentes.

De fato, estávamos testando fora da empresa, levando o protótipo para as ruas, interagindo com o cliente e coletando feedback. Ou seja, nosso trabalho foi validar o design da execução criando uma experiência significativa e entregar um aplicativo que ninguém podia encontrá-lo ou utilizá lo foi uma experiência realmente incrível mas infelizmente este projeto não obteve um grande resultado. Investimos muito tempo e esforço e mesmo assim falhamos, aquilo mexeu com todos, incluindo nosso cliente.

Aceitar a incerteza e abraçar as falhas

Acredito que seguir cegamente um caminho onde existe apenas uma forma de validar as coisas no modo "perde ou ganha" pode ser frustrante. Infelizmente não é tão simples, muitas vezes quando tentamos explorar ou aprender alguma coisa não aprendemos sobre o que acreditamos que iríamos fazer e acabamos aprendemos coisas diferentes do que imaginamos inicialmente.

Entendi como funciona este tipo de emergência mecânica e por que explorar é tão significante. Para tratar os erros como oportunidade de aprendizagem, é preciso testar e aprender, entretanto, isso pode ser realmente difícil.

Neste exemplo, mapeamos um grupo de conexões entre centenas de ideias no início de uma empreitada. Não tínhamos certeza para onde ir, qual direção tomar ou o que poderíamos fazer sobre isso. Queríamos encontrar algum significado e então tentamos conectar tudo tentando achar algum significado.

Uma etapa realmente difícil foi conversar com os responsáveis sobre aquelas ideias. Levar isso para o cliente e ouvi-los dizer que aquilo na verdade era uma ideia terrível e que não iria funcionar foi realmente uma experiência difícil para os envolvidos. Entretanto, era preciso tratar como uma oportunidade de aprendizagem, descobrir o significado daquilo e planejar o que deveria ser feito em seguida.

Muitos mindsets em apenas uma única equipe

Quando equipes trabalham juntas fazendo coisas diferentes, não existe uma verdade universal em relação aos mindsets, mesmo tendo propostas diferentes existe uma tendência de polarizar pessoas. Quando isso acontece, alguns atritos podem ocorrer dentro da equipe. Nós realmente entendemos como juntar estes mindsets e exploramos o benefício de cada um de forma coerente e colaborativa.

Embora operem em cadência diferente, a descoberta e a entrega do produto acontecem em paralelo. Encontrar um meio de colocá-los na mesma cadência é realmente um desafio porque não são lineares ou síncronos, não fazemos o design antes da construção, é preciso encontrar um caminho de desenvolvê-los ao mesmo tempo.

Este trabalho representa as descobertas acontecendo ao mesmo tempo que o desenvolvimento. Tivemos inspiração para tentar alcançar um estado ideal e nos esforçamos a partir da perspectiva do primeiro cliente. Nossa hipótese sobre como iríamos ganhar estava empregada no que estávamos aprendendo neste experimento, e aprender formando mapas de user stories e, em seguida, medir o que realmente acontece quando o produto é lançado no mercado muda constantemente e refina nosso pensamento.

Aprenda seu próprio meio de melhorar as práticas

Essa não é uma tarefa fácil, as pessoas precisam aprender seu próprio caminho para melhorar suas práticas. Jonny diz para mudar uma coisa de cada vez e deixar o valores e princípios de diferentes mindsets o ajudarem a descobrir como fazer isso. Diagnosticar um problema maior e explorar possíveis soluções para que configurem algum direção, testar algumas coisas e aprender sobre isso diversas vezes. Usando este padrão de forma contínua descobrimos como aprender e trabalhar no que vai funcionar, caso contrário é somente um processo.

Este tipo de coisa provavelmente gerará algum desconforto e provavelmente haverá algum ajuste para fazer. Isso acontece porque apesar das similaridades, como falado antes, estes mindsets tem um jeito de polarizar as pessoas. Às vezes, as pessoas ficam dogmáticas sobre o caminho certo de se fazer as coisas certas e isso realmente se sobrepõe à intenção de atingir algum resultado para o cliente, as pessoas se sentem mais confortáveis com o que sabem.

Pensando sobre modos diferentes de desenvolvimento de produtos, existem coisas diferentes em etapas diferentes. Na fase de exploração é possível testar e aprender muitas coisas, mas isso provavelmente será mais difícil trabalhando com uma equipe menos adaptável.

Sinto que a maioria das pessoas são muito boas em se adaptar, assim como o Ágil tem sido por longo tempo. Em resumo, estamos falando sobre boas práticas, sobre se preparar para ajustar às mudanças que acontecem com o tempo.

Conclusão

Precisamos explorar os problemas e podemos fazer isso com o Design Thinking, utilizando o Lean para pensar sobre como podemos aprender e plugando o ágil para responder às adaptações que ocorrem constantemente durante o caminho. Assim poderemos responder significativamente às coisas que estamos aprendendo à todo o tempo. A ideia é pegar emprestado o melhor de cada mindset e colocá-los juntos de uma forma que funcionem melhor para cada equipe dentro de um determinado contexto. Contudo, é preciso aprender a fazer isso por si próprio.

Para isso é preciso ter foco em uma proposta alinhada a autonomia; podemos iniciar com os clientes. Para medir coisas importante, a gestão visual é uma ferramenta que pode ajudar a alinhar os trabalhos. Tomar decisões baseadas no aprendizado, desenhar experimentos para aprender as coisas certas, aceitar as incertezas e abraçar as falhas. Finalmente, muitos mindsets em uma equipe aprendem seu próprio caminho para utilizar as práticas que funcionam e adaptam sua própria jornada para fazer as coisas de maneira diferente.

Sobre o Autor

Edeilson Silva é analista de projetos está engajado com o mindset ágil, sua missão é ajudar desenvolvedores junior a resolver problemas com agilidade, assim poderão se transformar em sênior mais rápido e entregar produtos com mais valor. Acredita que não deve haver barreiras para a aprendizagem e por isso ajuda a comunidade traduzindo artigos para a InfoQ Brasil.