Conhecendo 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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.