Szuster: Bom dia, boa tarde e boa noite. Vamos começar mais um episódio de Os Agilistas. Estou aqui mais uma vez com Vinição. Tudo bem Vinição?
Vinição: E aí pessoal, tudo bem? Vamos lá.
Szuster: Vinição calminho, não é Vinição? Hoje ele está calminho.
Vinição: Hoje é. Hoje já teve as doses necessárias.
Szuster: Então pessoal, hoje o episódio do podcast, nós vamos trazer um tema que a gente considera fundamental para que você possa realmente gerar valor na construção de produtos digitais. Um tema recorrente aqui no podcast, é da necessidade de gerar valor. Uma coisa evidente, uma coisa óbvia, é que você tem que gerar valor, só que é impressionante que apesar de evidente isso não é um caminho fácil. Você tem que ter um foco enorme na geração de valor, você tem que ter uma série de processos, metodologias para que você possa realmente gerar valor. Tem que ter uma estrutura adequada, enfim. A gente explora esse tema aqui em diversas formas diferentes, então a gente quer falar hoje um pouco sobre como é o processo de discovery contínuo. Por que assim, quando se pensa em um produto, a gente sempre cai na armadilhazinha do waterfall também, e aí pensa em um discovery de um produto, -o pessoal vai explicar daqui a pouco o que é-. Mas pensa que já descobriu tudo que precisava no começo. Parece que é irresistível as armadilhas do waterfall. Então nós vamos falar a verdade de um discovery, que é um discovery contínuo e além do ser um discovery contínuo nós vamos trazer uma dificuldade adicional que a gente percebe em muitos clientes, por motivos que vamos explorar aqui, que é o difícil acesso aos usuários de sinais. Então muito das vezes você tem essa dificuldade adicional. Então como se lidar com isso com um contexto desse. Para falar sobre isso, temos aqui dois experts, dois especialistas e queria que se apresentassem, primeiro a Melissa. Tudo bem Melissa?
Melissa: Ei Szuster, boa tarde, prazer. Estou aqui, estou muito feliz participando. Eu atuo aqui na DTI como PO já há algum tempo, já tem dois anos e estou muito feliz de a gente bater esse papo com você.
Szuster: Ótimo. Estamos aqui com o Jones. Eu estou rindo porque o nome, não é Jones, mas a gente só o chama de Jones. Falou Jones, se apresente.
Jones: Agora que veio para o podcast como Jones, é oficial. Prazer, para todo mundo. Prazer, obrigado Szuster e Vinição. Sou Jones, product designer aqui na DTI e vamos fazer três anos agora. Atuei bastante nesse tempo, contextos a gente tinha a dificuldade de acessar os usuários e a gente mesmo assim conseguiu fazer um trabalho de discovery contínuo bem interessante. Acho que a gente poder trocar uma ideia boa.
Szuster: Comecemos do básico aqui então. O que é um product discovery? Começar.
Melissa: Bom, eu acho que quando a gente fala de project discovery, a gente fala muito do -a gente descobriu o que é, o porquê-, com base eu acho, na necessidade dos usuários. A gente precisa entender muito o problema, eu acho que a gente aprofundar na dor, muito antes da gente pensar na solução. Muito do que a gente conversa aqui nesse podcast, às vezes está direcionado já a ir direto para a solução daquela dor, quando na verdade de product discovery a gente precisa de fato aprofundar mesmo em qual que é o problema para gente de uma forma mais precisa e eficiente, achar a solução ali para aquele produto. Eu acho que a gente mitiga muitos riscos trabalhando dessa forma. Quando a gente fala também de product discovery é a gente trabalhar muito com ciclos menores, para que? Para a gente aprender rápido, a gente experimentar, validar e invalidar também hipóteses. Então acho que é muito baseado nisso. Acho que product discovery é a gente aprofundar. Eu acho que eu resumiria muito dessa forma, a gente aprofundar de fato na dor antes mesmo de pensar na solução ali ideal.
Szuster: Entendi. O nome discovery já dá uma sensação de humildade mesmo, assim, descobrir o que tem que ser feito. A gente não sabe ainda. Mas fala aí Jones, acabei te interrompendo.
Jones: Eu ia comentar aqui que acho que quando a gente fala de produto discovery, é legal a gente entender que a gente está se aprofundando nessa (inint) [00:04:00], compreendendo o contexto, explorando N questões que vão estar ali em volta desse local que a gente ganhou para explorar. Muito do que quando a gente está falando para fazer o produto certo. Que é o que a gente vem falando muito aqui dentro da DTI. No fundo vão ter N soluções para aquele problema e a gente vai fazer discovery para conseguir encontrar o que a gente acredita que melhor resolva aquela dor e que crie e gera uma maior quantidade de valor possível também, diminuindo retrabalho e outras coisas. Então acho que isso tudo resume bem assim quando a gente começa a falar de produtos discovery.
Szuster: E quando a gente fala para poder ficar um pouco mais tangível, não é? Porque se a pessoa não está escutando pode pensar -ah, isso é o que? Uma entrevista? -. O que significa? Que tipo de ferramentas de processos que envolvem fazer um product discovery?
Jones: Eu acho que a gente vai ter N ferramentas, quando a gente fala de product discovery. A gente vai de entrevistas a fazer uma pesquisa de campo, observando o usuário que talvez não seja o caso aqui que a gente vai conversar, porque a gente está falando de cenários onde a gente tem pouco acesso as pessoas. A gente vai de workshops com área de negócio. A gente vai usar análise de dados. A gente vai trazer informações de algum outro tipo de pesquisa que pode ter sido feita. No fundo vai ter N ferramentas, N coisas que a gente pode construir e que vão categorizar esse resultado de discovery. Eu acho que tem uma ferramenta única e um método único para fazer isso. Eu acho que é muito mais o propósito que é sobre explorador, compreender o que tem de oportunidade ali de riscos que a gente pode mitigar.
Melissa: Eu acho que eu complemento muito do que você falou, Jones, por que não existe uma receita de bolo quando é descoberta ali, é muito de a gente adequar qual o momento que a gente está para a gente ver qual framework que a gente pode aplicar. Então, muito no bate papo que a gente vai ter que às vezes da dificuldade ali de a gente ter acesso ao usuário. A gente precisa criar meios mesmos, porque existem de a gente poder de fato entender o problema para a gente poder atuar no produto ali melhor.
Vinição: E o que é feito, eu já vi muitas palestras de pessoal debatendo um pouco sobre aquela questão. Às vezes eu sinto que essas coisas podem virar uma coisa de ficar perguntando muito. E aí na minha visão essas coisas podem talvez não demonstrar de fato o que é o comportamento do usuário, pois eu já vi que tem algumas, até não sei se já chegou a explorar algumas coisas desse tipo aqui na DTI, mas eu achei muito interessante. eu acho que foi até uma palestra que eu vi, acho que foi até do (Dave Snowden) [00:06:20], ele falando sobre etnografia ou alguma coisa do tipo. Achei muito interessante, por que assim, ao invés de você ficar perguntando muito, você observa o comportamento. A gente já chegou a fazer alguma coisa desse tipo aqui na DTI?
Jones: O processo de sombra é muito sobre isso. Sobre você observar, entender o que aquela pessoa está fazendo, mais do que você fica perguntando o que é um problema no seu dia a dia? É você vai acompanhar o dia a dia. Tem um caso muito comum que a gente começou a falar de discovery que é uma pessoa que estava observando alguém fazer o trabalho dela, se não me engano era um caixa de supermercado. E essa pessoa estava usando um software que já existia, só que ela continuamente fazia anotaçõeszinhas em um bloco de papel. E acho que esse tipo de cenário, se alguém perguntar-se para aquela pessoa -ou, você precisa de um lugar para fazer anotações, não sei o que ou isso é uma dor-, talvez não surgisse por que já era muito cotidiano dessa pessoa fazer algumas anotações ali ao longo do dia. E sei que isso acabou gerando todo um processo maior de entender e transformar isso em outra coisa, mas que virou uma feature depois com o produto, onde a gente conseguiu perceber que existiu uma necessidade que não estava mapeada e que esses usuários nunca tinham também pontuados, mas que aconteceu por que a gente foi lá observar e entender mais do que ficar perguntando o que era necessário.
Melissa: Quando a gente observa, eu acredito muito que quando a gente observa e pergunta menos, a gente consegue entender de fato o processo que está acontecendo ali. Então é muito do que o Jones falou. Quando a gente chega às vezes para fazer alguma entrevista pelo usuário, eu acho que já é intuitivo que ele vai responder o que a gente quer ou gente explicar por que que a gente está ali, que a gente vai querer entender um problema que está ocorrendo com ele. Já é intuitivo que ele já vai responder de fato o que ele acha. Agora, se gente fica ali acompanhando no dia a dia eu acho que a gente consegue insight muito mais valiosos e às vezes que a gente não consegue em uma entrevista, a gente não consegue às vezes conversando com a alta gestão. A gente estar realmente próximo ali, aquele contexto que a gente possa de fato entender o que o cliente ali, usuário do produto está utilizando.
Szuster: Mas nós não estamos falando aqui nós vamos fazer uma dificuldade…
Vinição: Eu vou fazer exatamente essas perguntas. Como que isso tem sido feito com a questão do remoto, não é?
Szuster: A gente pode até começar a entrar nisso. Por que é curioso assim, não é. Eu já li em outro lugar, outro contexto, por exemplo. Você pega um especialista em uma área, e ele não sabe o que ele sabe, ele não sabe o que ele sabe, ele faz um tanto de coisa que ele faz, ele já faz de forma tão automática ou de forma aí. Ele é cheio de conhecimento tácito, que o processo só de você ficar perguntando e pedindo para alguém explicitar o que faz, ele é por natureza imperfeito mesmo. Que assim, sei lá, tem 20 anos que a pessoa faz aquilo, ela não sabe nem explicar que ela faz, no detalhe, apesar de a gente achar isso estranho, pois como não, mas ele sabe fazer, não quer dizer que ele sabe tudo que ele faz. E ai, nós estamos falando o seguinte: poxa para poder descobrir o que esse produto tem que fazer, eu tenho que descobrir quais os processos são executados, quais são as dores que existem lá. Tem que observar o que acontece para aí sim, vir com uma solução, que seria o produto. Mas aí a pergunta é para entrar bem no nosso tópico aqui. Ok, nós temos N ferramentas e processos, mas se a gente não tem acesso ao usuário. Primeiro: porque a gente não tem acesso? Não é só ter acesso? Não é porque que o cliente impediria esse acesso por exemplo?
Melissa: Aí eu acho que vão N motivos. Às vezes por restrições, às vezes como o Vinição comentou, a questão de a gente estar online e a dificuldade às vezes de mobilidade de estar no local que o usuário está. Às vezes o próprio cliente restringe por questões de gerenciamento às vezes de expectativas, -não quero você muito próximo ali do contexto-, às vezes não gerar uma expectativa do que a gente vai desenvolver de fato e entregar naquele momento. Então eu acho que são vários pontos aí o porquê que a gente não tem contato com o cliente, sabe. E aí falando um pouquinho da questão da sombra, até do que o Vinição perguntou, a gente consegue, a gente fez em algumas atuações que eu estive aqui. A gente conseguiu fazer sombra sem às vezes ter o contato direto com o usuário. Primeiro na questão do online, então hoje tem algumas ferramentas que a gente consegue sim fazer o acesso com o usuário e acompanhar ele, utilizando um determinado sistema. Então isso ajuda a gente um pouquinho. A gente vai acompanhando-o ali, fazendo um atendimento e vendo ele utilizando o sistema ou às vezes a gente consegue dependendo do produto que a gente está atuando, a gente fazer a pesquisa e a sombra com o usuário reais mesmo. Então a gente às vezes puxa um parente, um conhecido que utiliza ali um produto às vezes parecido. Aí a gente já entra junto na questão de pesquisa de mercado para entender um pouco da visão mesmo do que o usuário tem. Então eu acho que são coisas que dá para a gente trabalhar para fazer-se sair como se diz: dessas dificuldades que a gente tem, sabe.
Jones: Nesse cenário do por que não ter acesso de vez em quando e como lidar com isso, acho que além desse cenário todos que a Melissa trouxe, tem um outro que é muito que eu viso que é diferença de fuso horário e barreira de linguagem. A gente trabalha com um produto que atende um público na China.
Szuster: Você não sabe chinês, você não sabe chinês não poxa?
Jones: Eu tenho uma frase, mas eu vou poupar vocês aqui do podcast que eu não preciso disso registrado, eu acho. Mas eu aprendi inclusive com eles, o pouco contato que a gente teve eu aprendi com eles. Então assim, tem algumas barreiras que às vezes não são nem corporativas, são barreiras realmente de a gente estar distantes. Nossos produtos caros e internacionais. Nossa operação ficou internacional nesse sentido, então a gente teve que aprender a lidar também com esse tipo de contexto e obviamente a gente usou de tudo que a gente pode imaginar, que nem a Melissa falou, ao invés de fazer uma sombra com a pessoa, era observar usando algum programa que monitorasse cliques, hitmaps e trouxessem uma visão meio que emulando aquilo que a gente faria no dia a dia. Ou seja, fosse às vezes arrumando um intérprete pra gente entrevistar alguém. Foi todos os jeitinhos que a gente foi dando ao longo do caminho para conseguir entender um pouco da realidade daquelas pessoas que estavam tão distantes e que realmente impossíveis de acessar, até quando estavam acessíveis, a gente não conseguia se comunicar às vezes. Então tem esse desafio também, acho que é algo que a gente poderia ignorar.
Vinição: Então, assim eu vou insistir um pouco nesse ponto que eu falei lá, da questão da observação. Eu vejo que é muito comum não só da DTI, mas geral aquelas abordagens que eu acho que foi o Google que inventou lá do Design Sprint etc. É muito comum a gente fazer isso usando um mecanismo às vezes de sala, de momento, de uma semana, todo mundo se reúne ali. Isso não é meio contraintuitivo? Eu sei que as técnicas são complementares, claro que você não tem que usar só um tipo de técnica, mas por exemplo, isso não limita muito o conjunto de técnicas que tem a ver com a observação. Porque assim, você não está observando alguma condição mais real ali, você está de forma meio artificial, juntando todo mundo. Acaba que você não consegue observar como vocês driblam isso. Isso tem a ver com essa parte do discovery contínuo, tipo assim, eu faço uma -que eu achei até um ponto que depois a gente poder entrar-, como que entra a característica até do Agilismo, de tendo realimentado com coisas que eu coloco para funcionar enfim. Acho que vocês entenderam o ponto aí.
Jones: Eu acho que quando a gente começa a falar de workshops desse jeito, seja inception ou design sprint ou o que seja. Elas são ferramentas complementares a observação. Talvez você inclusive observa, em um cenário onde você consegue ir lá e observar. Então você vai observar e depois vai trazer esse público para idear junto com você, explorar aquele problema. Uma coisa não substitui a outra necessariamente. Eu acho que uma coisa mais importante ainda, nesses cenários onde a gente tem pouco acesso, essas ferramentas do jeito que a gente lê, vamos falar na biografia, seja designer sprint, acabam funcionando ou simplesmente não funcionando. Então a gente teve que adaptar muito disso também. Encontrar formas de como fazer isso, de não com usuários que estavam distantes. Então assim, muitas dessas agendas a gente teve que aprender aonde fazer quebras mais detalhadas, aonde fazer algumas pausas nesses workshops às vezes para começar em uma semana e terminar em outra. Novamente não é o cenário ideal, mas a gente precisa encontrar como fazer isso para que a gente pudesse aí sim, alimentando aquele processo que gerasse o resultado que a gente esperava. Já que a gente não ia conseguir pôr todo mundo na mesma sala ao mesmo tempo.
Szuster: Então Jones, você podia contar um case, podia contar uma história obviamente respeitando aí a confidencialidade de informações, mas contar uma história que tangibilizasse mais o que nós estamos querendo trazer aqui. O que você acha?
Jones: Posso pensar em um aqui. Deixa-me ver. Que a gente tenha feito alguma designer sprinter ou workshop remoto e que foi de difícil acesso. A gente teve um nesse próprio cliente da China que eu comentei. Nós começamos um produto novo e surgiu uma necessidade, o cliente trouxe para a gente uma necessidade. E disse que eles tinham área de tecnologia, tinham uma dificuldade muito grande de se relacionar ao usuário final, até porque a área de tecnologia estava em um país e o usuário final estava na China. Então a própria área de tecnologia já tinha essa dificuldade. E aí o que a gente fez foi, inclusive muito através de observações e um pouco do que a gente já falou aqui, ao invés de pegar e tentar trazer todo mundo para sala que era uma coisa que eles já tinham tentado fazer no passado e não tinha dado certo, nós pegamos o que já existia de solução, mergulhamos muito a fundo para entender o que era aquilo, como funcionava. A tecnologia fez o melhor papel que ela pode obviamente em mostrar para a gente o que era o que já existia, que era algumas das visões que eles tinham também de problema. A gente conseguiu muito pontualmente uma pessoa para participar de algumas dessas sessões, que aí era realmente da china e conseguia falar inglês com a gente, para validar algumas das dúvidas que foram surgindo ao longo do processo. Mas no fundo o que a gente acabou fazendo foi usando toda a pesquisa que a gente fez, questão de entendimento do que era aquilo, um levantamento de como a área funcionava, quais eram as necessidades, uma pesquisa enorme inclusive também sobre demografia para entender quem era esse público que era muito diferente da nossa vivencia aqui no Brasil. A gente conseguiu levantar uma série de oportunidades e coisas que a gente queria testar e que aí sim, a gente levou isso já muito mais mastigado para esse público que estava na China, por que eles tinham uma janela muito pequena com a gente para fazer isso. Então não adiantava a gente achar que a gente ia passar o dia inteiro falando com eles. Um dia inteiro significaria a noite inteira para a gente. Então a gente teve que traduzir um pouco essas necessidades usando muito pesquisa, observação e tentando conectar a tecnologismo, aceitar que a gente ia errar algumas dessas coisas, que a gente ia aprender fazendo.
Szuster: Quase que uma engenharia reversa. Vocês ficavam ouvindo e voltavam nos porquês, nas hipóteses subjacentes, para daí tentar validar com pessoal e observar. E você Melissa, que tipo de exemplo você pode trazer?
Melissa: Posso trazer um muito interessante que é o acompanhamento ali do comportamento do usuário através de ferramentas que a gente conseguiu gravar a utilização dele em produtos que a gente entregou. Então hoje existem algumas ferramentas que a gente consegue avaliar o mapa de calor, a forma como ele utiliza, qual que é a interação dele em algumas funcionalidades. Então a gente conseguiu, a gente implementou, a gente colocou dentro desse produto essa a ferramenta para gente gravar o comportamento do usuário ali na utilização do sistema. E a gente teve vários insight, então através dessas gravações, a gente depois ali junto com os designer, a gente fez, -a gente até brincou, como se fosse um Netflix mesmo, – a gente assistiu várias gravações ali e tivemos vários insights com pequenas mudanças no produto com pequenas funcionalidades que a gente gerou valor expressivo mesmo nas nossa entrega. A gente entendeu por exemplo que o usuário estava ficando perdido na primeira tela, porque ele estava se comportando como se ele tivesse que sair da tela ali, na verdade a gente estava colocando um ícone, que na verdade não era para ele sair. A gente conseguiu entender no comportamento dele, a forma como ele fazia algumas pesquisas. A gente trouxe outras funcionalidades ali para agregar valor também para aumento de receita para esse cliente. Então eu acho que quando a gente não consegue ter o cliente próximo ali para a gente acompanhar, seja em uma gravação ou uma sombra, hoje existem também essas ferramentas que a gente consegue ver o comportamento do usuário e de um grande número também. Então a gente teve aí vários vídeos que a gente conseguiu de fato entender o perfil e o tempo de engajamento em algumas telas. Então até para a gente poder priorizar ali com o cliente o que de fato a gente ia entregar nas próximas interações.
Szuster: Você até perde talvez, ver o usuário e as expressões dele, mas você ganha um tanto de coisa por outro lado que é muito mais é objetivo. O caminho que ele fez, onde ele clicou ou não clicou, onde ele parou, onde ele gastou mais tempo. Sabe, e você pode ver várias vezes, um negócio bem. Mas aí vem uma coisa que eu acho interessante. Ai desculpe, o Vinição está querendo perguntar. Fala aí Vinição.
Vinição: Só emendando até a ver com o outro ponto que eu falei. Vocês já exemplificaram um pouco desse mecanismo de observação, esses pontos que a Melissa colocou bem interessante, até de software que ajudam nisso. Mas eu sinto as vezes que o mercado em geral, os clientes muitas vezes, têm uma certa dificuldade de realmente querer aceitar e pagar pelo processo do aprendizado em si, que na minha visão inclusive barateia o tudo. O que eu quero dizer com isso? Muitas vezes esse processo que a Melissa descreveu aí, eu não sei se foi assim, mas eu imaginaria que, tipo assim, eu tive uma concepção de algo, eu fiz ali o discovery e provavelmente eu já produzi o software. Eu imagino que o processo discovery ele já deveria envolver um processo onde produz mais protótipo. Quando eu falo protótipo pode ser até parecer uma coisa bem real, mas ainda é protótipo, ainda não é um software que escala. Ou seja, eu ainda não desembolsei o que seria o princípio do ajo, de eu ir realmente tirando dinheiro do bolso à medida que eu vou tendo evidência que aquele caminho lá é mais promissor. Como que vocês enxergam esse cenário? Vocês têm visto os clientes, tipo assim, aceitando por que quando eu estou na fase de protótipo, apesar de muito do que ele pode ser desperdiçado, em tese eu estou usando um ferramental que é barato, porque construir o software que escala que responde uma série de coisas, normalmente é um investimento alto.
Melissa: Sim e a gente mitiga riscos mesmos às vezes, do que a gente acha que vai fazer sentido e gerar valor. Nesse exemplo que eu comentei, de fato a gente já tinha implementado, mas o que eu vejo sobre isso que você falou Vinição da questão do cliente enxergar valor. Eu acredito muito de a gente trazer o cliente, educar o cliente, explicar para ele o que é esse trabalho que a gente faz, o que é o discovery, qual que é o benefício. Levar muito em uma linguagem fácil mesmo, que ele possa entender e a gente falar com ele -olha eu posso experimentar uma vez aqui e te mostrar o benefício disso? -. E aí quando a gente mostra isso para o cliente e a gente mostra o benefício e implementa ele fica mais aberto e aí é onde a gente tem a validação ali da experimentação então eu tive também um contexto aqui na DTI, de a gente trabalhar primeiro com os protótipos, prototipar várias alternativas de solução para um determinado produto e aí a gente envolveu ali o próprio cliente, os próprios usuários finais para ele trazer, para a gente levar para o cliente e falar: olha o que a gente estava achando que ia gerar valor, o que você estava achando,- de fato o cliente próprio usuário final para ele não vai gerar valor nenhum. Então a gente seguir para esse caminho e às vezes uma solução muito mais simples que iria adequar. Então assim, eu vejo que de fato o mercado tem um pouco dessa dificuldade de entender de a gente trazer primeiro; validar a ideia ele, mas eu acredito muito nessa educação sabe, da gente explicar para ele de uma linguagem mais simples e tentar pegar um pequeno, experimentar mesmo, é o experimento. Eu modelar um experimento, trazer o cliente para modelar esse experimento junto. Então a gente fez isso em alguns contextos aqui. Poxa, mas o que isso vai gerar de resultado, vem aqui, vamos modelar o experimento juntos, vamos pensar no que a gente quer validar ou o que a gente quer desenhar porque ele se sente parte daquilo, sabe.
Vinição: Às vezes eu fico pensando o caminho que você descreveu. Às vezes eu fico pensando que o caminho que é bem interessante na minha visão é tentar explorar o lado econômico da coisa do que eu não fiz. Isso é meio contraintuitivo, mas do tipo assim, tem caminhos que a gente fosse testando e não seguindo na medida que eu fui tendo evidências que ele parece que não vai dar certo, mas eu tentar fazer como se fosse uma simulação de quanto eu teria gasto no modelo que eles estão acostumados. Eu construir todo o software e fazer meio que tentar mostrar versões alternativas do mundo possível que poderia ter ido, vários caminhos que eu não fui, mas que poderia ter ido e que normalmente a gente vai. Às vezes é porque ele demanda porque ele acha que é mais eficiente, porque ele não quer gastar com protótipo que foi jogado fora, entendeu? Eu não sei se a gente chegou a fazer coisas desse tipo, mas se eu fosse voltar para “o mão na massa”, eu acho que tentaria coisas assim.
Jones: Eu ia falar só que a gente teve um cenário bem focado nisso, e que a gente usou muito dessa argumentação de como fazer esse processo discovery poderia economizar dinheiro no final das contas. A gente tinha um produto que já estava entregue um pedaço dele, mas surgiu uma hipótese junto até inclusive com o pessoal da área de negócio. Acho que tinha algum entendimento de alguns dos botões que a gente nesse software que não estavam adequados, acho que o público por ser da China também, não compreendia aquilo da mesma forma que a gente estava compreendendo e eles estavam propondo que a gente trocasse esses botões. E eles tinham absoluta certeza ali naquele momento de que podia trocar o botão, que estava errado. E a gente usou muito do -vamos fazer uma pesquisa primeiro, vamos tentar encontrar uma forma antes de validar se a gente precisa mesmo trocar esses botões-. A gente tinha estimado acho que era uma mudança que ia gastar alguns desses prints de desenvolvimento, não era uma mudança pequena. E a gente conseguiu convencer alguns desses (inint) [00:25:03] de que se a gente gastasse uma semaninha ou alguma coisa assim do nosso time de produto. A gente pensou em uma pesquisa inclusive que usava pouquíssimo texto, era pesquisa quase todo visual que os usuários tinham que clicar, então era protótipo semi-interativo com algumas perguntas no meio do caminho. E a gente conseguiu tirar vários insights e aí pedindo para o pessoal obviamente que estava ali, mas um pouco mais próximo desses usuários na China que eles tentassem navegar naquilo e a gente conseguiu provar de alguma forma que o entendimento não estava errado, tinha outro problema no produto que a gente não ia mexer se a gente tivesse feito o que eles pediram. Então a gente conseguiu no final das contas economizar dinheiro do cliente nesse sentido também. Mostrando que tem realmente um problema, mas só não é o que a gente está falando. A gente mudou uma outra coisa.
Szuster: O problema é o jeito que o ser humano é, porque o ser humano não sente que ele não gasta, ele sente que ele gasta. É engraçado isso. Você não sente. (inint) [00:25:55]. Imagine um grafo os caminhos com valores, você vai mostrar as coisas que você economizou, que você deixou de fazer. Assim eu acho que existe um problema que vocês vejam, os assuntos sempre são no fundo uma discussão da essência do Agilismo. Porque essência do Agilismo e você realmente entender que é um processo de aprendizado, o desenvolvimento desse produto. Se é um processo de aprendizado você tem que fazer descoberta, tem que fazer experimentação. Só que de alguma forma isso não é bem aceito na cultura tradicional, nas corporações, a área orçamentaria. Sabe, tem um milhão de variáveis e aí todo mundo na verdade, tem que querer, vai para o lado de que tem certeza ou que é desperdício tentar aprender. Sendo que eu desperdiço é não aprender. Assim não porque é engraçado (inint) [00:26:38], que o desperdício que o (inint) [00:26:39] declara, eu gosto muito disso, no (inint) [00:26:42] para eliminar desperdício. O desperdício que (inint) [00:26:46] declara é: num ambiente certo o meu desperdício é não aprender. Tem que criar um jeito de aprender rápido.
Vinição: Então o Szuster, assim, esse ponto que você colocou antes, da característica do ser humano. Tem horas que às vezes eu acho, a comunidade do Agilismo, essas coisas assim, às vezes eu acho que pode ser muito nerd. Sabe assim, as críticas. Não parece que essa comunidade se comunica tão bem do ponto de vista de negócio, sabe. Tipo assim, se a gente explicar essa mesma coisa, uma coisa que é mais da técnica em si, mais da abordagem, mais transformando a coisa em uma coisa econômica, eu acho que que seria mais bem sucedido, entendeu? Para atacar exatamente esse lado do que.
Szuster: Também é assim, parece que qualquer pessoa de negócio gostaria de economizar dinheiro desse jeito, mas de alguma forma a discussão são longas. A estrutura é feita de tal forma que separa os mundos. E o ajo era patrocinar os mundos. O mundo é separado. Fica quase que uma solução terceirizada, um negócio terceirizado de uma solução para TI. E aí a TI não tem nem essa possibilidade muitas vezes. A TI que eu falo a gente (inint) [00:27:51] cliente. Não tem às vezes essa possibilidade. Mas é o que eu falo, essa é a essência da discussão nossa aqui, na verdade. É isso pessoal alguma outra, acho que nós estamos chegando aqui ao fim do episódio. Parece que exploramos bem o tema. E a verdade, falar sobre ajo é falar sobre adaptação, para mim o vocês mostraram hoje é um exemplo de adaptação. Por mais que você possa até falar, o certo é ir lá fazer etnografia, observar o usuário, o certo é isso, o certo é aquilo. No mundo real, vocês deram vários motivos aqui pelos quais muitas vezes o certo entre aspas, não dá para fazer. E aí você tem que encontrar alternativos e usar novas tecnologias a nosso favor, que é o que vocês deram de exemplo aí também.
Melissa: Só complementar Szuster. Acho que os caminhos existem, a gente tem que ir atrás dele.
Szuster: Beleza pessoal.
Vinição: Um grande abraço aí, valeu.
Szuster: Para todos um muito obrigado.
Jones: Valeu, obrigado.
Melissa: Tchau gente.
