PEDRO: Bom dia, boa tarde, boa noite. Estamos aqui, mais uma gravação dos agilistas como sempre, estou com a minha parceira de Diulia, tudo bem, Diulia?
DIULIA: E aí gente, beleza? E aí o tema de hoje é bom, não é? Eu nem gosto de falar do tema de hoje, eu empolgo.
PEDRO: É isso aí. Hoje a gente vai falar sobre discovery contínuo, não é? Em oposição aos modelos tradicionais cascata, antigos famosos modelos de construção de software que gera muitas frustrações na entrega de soluções digitais, que a gente faz toda aquela especificação logo de cara, antes de fato fazer a construção, não é? A gente já falou bastante sobre o product discovery em geral aqui também. Muitos times de produto realizam um bom processo de product discovery, mas poucas equipes sabem trabalhar de forma contínua, de fato. E aí a gente está com duas convidadas super especiais, eu vou deixar elas se apresentarem aqui. Oi, Raquel, tudo bem?
RAQUEL: Ei, Pedro, ei Diulia, ei Lorena, tudo bem?
PEDRO: Conta para a gente um pouquinho aí, Raquel, que que você faz? De onde vem?
RAQUEL: Eu sou Raquel, eu sou aqui de BH mesmo, eu sou formada em design de produto e hoje eu atuo com a gestão de produtos, trabalho como product owner aqui na dti há mais ou menos uns dois anos e meio, estou muito feliz de estar aqui porque eu sou fã hoje dos agilistas.
PEDRO: Legal. Primeira gravação com a gente, não é, Raquel? Muito bem-vinda.
RAQUEL: Primeira, primeiríssima. Espero que de muitas.
PEDRO: Com certeza vai ser.
DIULIA: Seja muito bem-vinda.
PEDRO: Isso aí. E Lorena, tudo bem?
LORENA: Ei, pessoal, boa tarde. Então.
PEDRO: Pode usar o jargão à vontade, bom dia, boa tarde, boa noite. Os convidados também podem falar.
LORENA: Então tá, bom dia, boa tarde, boa noite. Meu nome é Lorena e eu sou product designer aqui na dti já tem quase dois anos. Mas eu sou formada em design gráfico, mas aí eu migrei para a área de produtos digitais, que é uma área que eu curto muito mais.
PEDRO: Está feliz com a migração?
LORENA: Nossa, estou muito mais feliz.
PEDRO: Que bom. Que bom, sem arrependimentos, então.
LORENA: Não, eu acho que tem uma intercessão, tem muita intercessão em alguns momentos.
PEDRO: Com certeza. Com certeza, mas vamos lá, não é? A gente vai falar hoje sobre discovery contínuo, como eu falei, mas acho que antes de a gente entrar de fato no discovery contínuo, acho que seria legal só a gente, de leve, falar um pouco sobre product discovery em geral também, não é? Que é, na verdade, talvez o mais padrão que as equipes fazem de uma maneira geral, fazem bem, não é? E aí, para a gente poder falar um pouco melhor das dificuldades do contínuo, a gente podia só passar um pouquinho para o público sobre o product discovery. Você me ajuda nessa, Diulia?
DIULIA: Claro. Então, quando a gente fala de product discovery, é até um termo que ficou muito na moda recentemente, não é? A gente acha cursos diversos para poder se fazer a respeito de product discovery e inclusive é um termo que ficou tão na moda que agora as pessoas, às vezes, até ouvem discovery e já dão aquela arrepiadinha dizem: nossa, vai ser um mega processo complexo, intenso, quando na verdade, quando a gente fala de product discovery, a gente está falando de entender de maneira mais aprofundada sobre as necessidades reais que existem ali e entender quais propostas de solução fazem mais sentido para a gente testar rápido, e aí a gente validar se realmente aquela hipótese de solução fazia sentido. Então, quando a gente pensa em longos processos de discovery, ele por si só já fica um processo meio duvidoso assim, porque se você gasta muito tempo para poder aprender, vai gastar muito tempo para poder validar. Na verdade, você não está ganhando tanto tempo assim. Então o discovery contínuo, ele entra para poder casar com product discovery, e complementar e possibilitar que o processo seja mais aderente a uma realidade que a gente chama, de mundo VUCA, BANI, e por aí vai, em que as coisas estão mudando constantemente. Então, quando entra uma coisa ou entra outra, não é? Normalmente, o produto discovery, ele entra muito no início quando a gente vai começar uma iniciativa, mas a gente pode ter ele também como um marco de uma nova fase, de um produto, como um marco de uma nova frente de um produto. Mas normalmente é quando a gente tem uma divisão grande entre o que a gente já conhece e um desconhecido, que a gente vai começar a aprofundar, a conhecer um pouco mais. Agora, quando a gente fala do discovery contínuo, é justamente porque no product discovery, se a gente está falando de um período curto de tempo para a gente poder ter um aprendizado, quando a gente vai para o desenvolvimento, é natural que a gente não tenha feito todas as perguntas, aprofundado em todos os detalhes e nem é esperado que a gente fique gastando tempo imaginando todas as perguntas possíveis, não é? Senão a gente vai ficar ali assim, hipoteticamente levantando um monte de coisas que não necessariamente a gente vai usar. Então, a passagem de bastão é do product discovery, inicialmente que vai ter esse conhecimento, que é a base do que que vai ser feito na sequência. E o discovery contínuo, e aí que cresceu muito esse termo, até com a Teresa Torres, ele é esse hábito contínuo do time de aprender sobre o que precisa ser feito de maneira incremental. Então, à medida que o time faz pequenas entregas, ele aprende com que ele entregou, à medida que vai pegar uma nova parte da solução, tenta aprofundar um pouco mais sobre aquela parte que precisa ser desenvolvida e sempre focando em mitigar riscos, sempre focando em pesquisar o que de fato é necessário para aquele momento, para que a gente não corra, também, o risco de botar tudo em discovery contínuo quando, às vezes pode ser que tenham features ali que elas já estavam bem delimitadas, o risco é baixo e elas poderiam ir diretamente para um refinamento e depois caminhar para o desenvolvimento. Então, discovery contínuo é assim: existe um risco? Pode ser uma ótima opção para a gente poder mitigar, antes do time gastar tempo desenvolvendo. Fez sentido?
PEDRO: Sim, sim. Fez demais. Muito legal você ter falado da Teresa Torres, eu já li um dos artigos dela, o nome do artigo, se não me engano já é: Quanto tempo a gente deve gastar com discovery? Ela já começa falando que essa não deveria ser nem a pergunta, que na verdade, eu não lembro, quem lembra qual que era a pergunta que ela que ela sugeria lá? Era alguma coisa: qual que é o melhor caminho para determinado resultado que a gente quer obter? Alguma coisa nesse sentido.
DIULIA: Pois é, eu não lembro desse artigo especificamente, mas eu suponho que sejam duas perguntas que precisam ser entrelaçadas. A primeira é, qual é o problema de fato que a gente quer resolver? E depois disso, qual é a melhor proposta de solução e como que a gente identifica que essa proposta de solução é adequada? E sim, não é? São as perguntas base. Muitos dos processos de discovery, inclusive que a gente vê que se estendem muito, é que as pessoas não sabem quais são as perguntas que elas querem responder, e aí elas começam a entrar num limbo assim, porque quanto mais você procura, mais você descobre. Mas não necessariamente é o que você está precisando aprender agora, não é? Você poderia focar só no que você precisa aprender para agora, e depois você expande para outras coisas sobre necessidade mesmo. Mas enfim, está vendo? Eu não posso começar a falar dessas coisas que eu começo a pegar o episódio e ficar falando.
PEDRO: Está certo, então vamos passar a bola para as nossas convidadas, então. A Diulia já comentou um monte sobre a prática do discovery contínuo, não é? Para que que serve. Mas a gente consegue sumarizar qual é o benefício que essa prática traz ou o principal do benefício, talvez?
RAQUEL: O principal benefício quando a gente faz um discovery contínuo é, acho que a gente não pode fazer do discovery uma grande cascata. Então, se o desenvolvimento está indo de forma ágil, a gente tem que quebrar esse discovery em pequenas partes até para a gente conseguir fazer uma entrega legal. E quando a gente faz, a gente divide esses problemas em problemas menores, vai fazendo pequenas entregas, a gente consegue às vezes validar ou invalidar alguma hipótese que a gente tinha anteriormente. Então acaba que a gente deixa de entregar coisas que não teriam valor nem para o usuário, nem para o negócio, e a gente começa a entregar produtos. A gente entrega features e produtos, histórias mais assertivas para o usuário, para o negócio. Eu acho que uma grande vantagem é a gente não fazer cascata em forma de discovery.
LORENA: E aí só complementando o que a Raquel comentou. A gente também ganha celeridade no desenvolvimento, então a gente também com o discovery, a gente consegue mapear todos os impedimentos que poderiam impactar o time de delivery. Então, assim, por mais que às vezes a gente fala que vai gastar tempo com o discovery, inversamente, a gente está otimizando também o delivery, então é muito comum que times que tenham discovery muito desenvolvido, a gente tenha poucos impedimentos. Porque também a gente não está blindado contra essas situações, mas a probabilidade de você ter impedimentos que vão impactar nas suas entregas é muito menor, porque você já tentou mitigar mais os riscos, sejam riscos, questões de usabilidade, negócio, arquiteturais. Então assim, o desenvolvimento ele é mais fluido. Então, a gente tem mais tempo para errar e aprender também nesse sentido.
PEDRO: Perfeito até a Diulia comentou no início, que muitas vezes, as pessoas, as organizações, elas podem se assustar um pouco por entender que o discovery vai tomar uma super quantidade de recursos, de tempo, etc. Mas até para desmistificar um pouco isso, como que o discovery contínuo faz parte da rotina do time?
LORENA: Começou com passos pequenos. Eu acho que você vir falar para um cliente que não conhece tanto da metodologia, para pessoas que não estão tão ligadas na forma que a gente trabalha, pode ser de fato, assustador. Então, assim, a gente também não tem um papel de impor as coisas. A gente também tem que explicar e apresentar dados que vão colaborar com o que a gente está querendo propor para o cliente. Então, como que a gente começou aqui? A gente começou a levar dados quantitativos para o cliente, onde que isso estava, de fato, otimizando e minimizando as chances de a gente desenvolver coisas que poderiam ser descartadas eventualmente, e que também não gerariam um valor para ninguém. Então assim, seriam coisas que seriam utilizadas por um, dois meses, mas que eventualmente, precisariam ser refaturadas ou descartadas totalmente. Então, além de levantar esses dados e trazer isso para os nossos clientes, a gente também trouxe ações que eram muito mais educativas. A gente tem uma ação que é muito interessante no nosso time, que a gente traz livros. A gente leu o livro da Teresa Torres em conjunto com nossos clientes para que todo mundo entenda também, sabe? Porque não adianta só a gente vir falando, mas também tem que ter a compreensão completa, entenda que aquilo a gente está querendo otimizar o trabalho, não de gerar morosidade nas coisas. Então assim, a gente começou a fazendo esses passos, e aí o cliente em si ele começou a ver mais valor naquilo, porque ele viu que de fato, a gente estava otimizando e trazendo para claridade coisas que estavam passando imperceptíveis, sabe? Então assim, foi dessa forma que a gente começou. Então, assim a gente começou educando também, não é? Apresentando essa questão e trazendo dados para colaborar com esses nossos argumentos.
DIULIA: Pois é, até uma coisa legal que você comentou aí, é justamente esse papel empático junto com o cliente, não é? Porque assim, também é esperar demais que a pessoa já seja assim, você já chegue enquanto pessoa de produto, pessoa de design e faço uma proposição de vamos fazer um produto discovery, vamos trabalhar com discovery contínuo e a pessoa e fala: vamos super. Entenda o que que é, vamos, vamos começar para ontem. Porque para muitas pessoas os termos não são termos do dia a dia, não é? Não são coisas que elas estão acostumadas e dominam e sabem a complexidade. Então para alguns, pode até soar meio que assim, não, mas espera aí dentro do ágil nunca ouvi falar em discovery contínuo, dentro de todas as coisas que eu já ouvi, não sei, eu talvez já tenha ouvido alguma coisa. Mas a gente traduzir isso em ações e conseguir quebrar de forma evolutiva também para ir dando esses passos que começam realmente um pouco menores e depois a gente vai conseguindo evoluir, é muito legal. E aí, hoje, dentro da rotina do time de vocês. Como é que vocês equilibram as atividades de delivery com o discovery contínuo?
RAQUEL: Acho que é legal, Diulia, a gente falar um pouquinho do contexto nosso. A gente está descomissionando um produto legado do cliente, não é? Então, esse produto já é um produto mais antigo que muita informação deles se perdeu. Então a gente tem que fazer uma, às vezes, uma engenharia reversa com o cliente sobre o nosso produto. Assim, no nosso caso seria impossível a gente simplesmente sair fazendo, porque a gente tem que entender. Então não é aquela coisa que você falou só do discovery, não é? A gente tem que ir fazendo isso aos poucos, não bastaria a gente ficar no início do projeto entendendo o que que é que a gente teria que fazer. É uma coisa que a gente vai cavoucando mato literalmente. Então, a gente vai abrindo essa porteira aos poucos, é um trabalho que tem que ser feito, não é?
LORENA: No sentido de operação, como que a gente faz isso, não é? Faz essas questões rodarem? No nosso time, a gente tem um time que a gente chama de time cross. É um time que está responsável tanto por puxar as questões referentes a discovery, mas também que atua no delivery, não é? Ali, para auxiliar os desenvolvedores, então a gente tem sprints que acontecem, onde a gente define qual que vai ser o nosso objetivo naquela sprints. E aí nessa sprint a gente tem atuação de designers, tem a atuação do PO, a gente tem a atuação do nosso arquiteto de dados, arquiteto de soluções. Então assim, na nossa operação a gente faz com que o discovery seja do time completo, não é de responsabilidade do designer ou da pessoa de produtos. Então assim, eu, como designer, não vou conseguir levantar, mitigar riscos referentes à questões tecnológicas, arquiteturais e que estão aplicadas aos nossos produtos. Então, assim, é preciso que eu também tenha esse olhar técnico ali, para que também no desenvolvimento a gente não tenha tantas surpresas, principalmente no nosso contexto que envolve uma questão tecnológica muito grande. Então, nessas sprints a gente trabalha em conjunto, então assim, a gente vai montando um quebra-cabeça durante a sprint, então o arquiteto de dados, ele participa de todas as iniciativas que o design puxa, da mesma forma que a gente também participa das iniciativas deles. E aí, no momento que a gente sente que a gente está ok, a gente tem uma solução que está se mostrando aderente que de fato é um problema real e que vai solucionar o que a gente identificou, aí a gente passa para o time de delivery, mas também não é só uma passagem de bastão. O time de delivery, ele não vai exclusivamente ficar responsável por fazer a construção. É importante que o time de delivery também tenha compreensão do que ele está fazendo, do que que ele está resolvendo. Então, a gente também tem um rito, onde a gente passa todas essas questões que foram descobertas em discovery, porque o pessoal que está em desenvolvimento, por não estar tão emergindo nas coisas, podem ter uma visão que talvez passou para a gente despercebido, porque a gente já está muito poluído de todas as informações e tudo o que a gente está consumindo. Então, repassando isso para o time de delivery, eles também têm autonomia para ter uma compreensão das regras que a gente está querendo aplicar, o que a gente está querendo propor para o cliente e qual é o valor que a gente vai agregar. Então, basicamente é dessa forma que a gente está tentando atuar hoje.
RAQUEL: Aqui a gente tem esse privilégio de conseguir fazer o dual track separado, a gente tem um board de discovery, a gente tem um board de delivery e é obrigatório, não é? A gente seria assim, o orgulho da Teresa Torres que a gente tem o product trio, que ela chama. A gente tem a participação dos meninos técnicos também no nosso discovery, por necessidade. Mas eu já estive em outros times também, que chamei para dentro de conversas os engenheiros, porque querendo ou não, a gente pode pensar em alguma solução que não tenha viabilidade técnica. E aí, como é que faz, adianta? Não adianta, tem que ir todo mundo junto para a gente conseguir entregar a melhor solução.
PEDRO: Quero fazer só um parêntese aqui, porque a gente já falou várias vezes da Teresa Torres, não é? Só para o público saber, caso alguém não conheça, a Teresa Torres, ela é uma autora aclamada internacionalmente. E ela escreve sobre práticas sustentáveis e estruturadas de realizar continuous discovery, não é? Se não me engano, até a Diulia citou no início do podcast, o livro Continous Discovery Habits que a gente super recomenda, e também ela tem o Product Talks também, não é? Um blog super interessante, tem vários artigos aí, como o que eu citei lá no início.
RAQUEL: Só para comentar também tem várias palestras, várias conversas no youtube também que ajudam para quem, às vezes, não vai ter tempo para poder ler todo o livro, enfim, mas que a pessoa consiga ter o overview do que ela traz, porque ela propõe o que ela propõe. Porque é muito legal a proposta.
LORENA: Eu ia até comentar sobre essa questão da participação técnica, como que ela é importante para a gente, dentro do nosso time, dentro do discovery, porque isso também faz com que o time, por exemplo, eu, como designer, a Raquel, como PO, também começa a ter um olhar sobre outras coisas que a gente não prestava atenção. Então assim, às vezes, por questões de conflitos, pode ser que um arquiteto ele não consiga participar de uma conversa. Mas você já tem essa maldade de perguntar sobre algumas questões e também você já sabe até onde você consegue ir, sabe? Por exemplo, sobre alguma solução que você quer propor. Então acaba que o conhecimento ele começa a ficar muito mais disseminado no time, e acaba que ninguém é só tipo: eu não só vou olhar exclusivamente as habilidades, da mesma forma que o arquiteto, ele não vai só olhar a questões de dados. Ele pode também sugerir as questões das soluções no nível de usabilidade, eu também posso sugerir em questões referentes a dados, então assim, o conhecimento ele fica muito mais diluído no time, e também faz com que as discussões sejam muito mais proveitosas, sabe? Porque não é cada um olhando para o seu quadrado, sabe? É todo mundo olhando para o nosso produto todo, no geral.
DIULIA: Um time de verdade, orgulho.
PEDRO: Que isso. Muito chique. Eu queria, inclusive, entender um pouquinho melhor o seguinte, por ser contínuo, não é? Vocês estão me dando a entender que vocês realizam o discovery em todo sprint, não é? Então, a todo momento, eu queria entender um pouquinho melhor, como é que fica a frequência das atividades, por exemplo, vocês fazem pesquisa em todo o sprint? Entrevista em todo o sprint? Mapeamento em todo sprint? Como é que isso consome o time?
RAQUEL: Aqui, Pedro, a gente tem realmente sprints separadas. Porque como é um produto muito complexo, a gente tem sprints separadas para a gente falar qual o tópico a gente está trabalhando. Então, por exemplo, a gente tem um tópico X. A gente tem tarefas de design, a gente tem tarefas de produtos, a gente tem tarefas de engenharia em todas as tarefas que a gente faz. Então, sim, quando a gente, na verdade, a gente abre novas oportunidades, é assim que a gente faz e aí, dentro dessas oportunidades, que às vezes podem ser mais de um sprint que elas duram, toda oportunidade, com certeza a gente vai ter entrevistas, por exemplo. Mas a gente também vai ter que fazer um modelo de dados, a gente vai ter que fazer essa engenharia reversa, também. Todas as nossas entregas, então, sim, a gente tem, com certeza, entrevistas em todos.
LORENA: E aí acontece também que como a gente já está atuando ali, o nosso discovery ele está tão fluido agora ele está assim, está sendo tão eficiente que acaba que a nossa atuação em delivery, ela é mínima. Então são situações muito críticas para que eu precise ir ali dar suporte para o time de delivery, da mesma forma que os arquitetos também não tem essa cadência tão grande de a gente ter uma atuação ali, tanto que a nossa capacidade é muito reduzida na atuação da sprint de delivery. Não quer dizer que a gente está isolado, a gente participa de tudo o que o delivery faz, está ali para eles. Mas acaba que, como o time de delivery também já tem autonomia e tem esse processo todo de repasse de conhecimento que a gente tem, acaba que as coisas ficam muito mais tranquilas para a gente. Então a gente consegue focar no discovery e que se acontecer uma situação extraordinária no delivery, a gente consegue dar o suporte ali da mesma forma, sem gerar grandes impactos para o nosso discovery. Então, acabou que a nossa operação, hoje ela está bem encaixada, então acaba que a nossa atuação no delivery ali é muito mais no sentido de auxiliar na homologação, auxiliar eventuais dúvidas. Mas o time de delivery já tem autonomia completa e também tem o conhecimento necessário para decisões que estão ali dentro, cabem a eles.
RAQUEL: A gente volta no ponto que, eu acho que um time que tem um bom discovery contínuo, ele tem pouco impedimento no delivery, não é? Então a gente realmente não chega a ter problemas, muito raro. Então, eu acredito muito nisso. Um time que tem um bom discovery, ele consegue fazer um ótimo delivery, também.
PEDRO: Reloginho suíço, não é? Tudo funcionando, encaixado.
F: Só para a gente poder ajudar o pessoal a se situar. Então, por exemplo, vocês são uma estrutura de time como um todo, não é? Só que aí dentro da estrutura de uma sprint, a gente vai ter o time que é mais focado em delivery, olhando para algumas atividades. E vocês que estão olhando mais para a etapa de discovery, vocês até vão dar suporte em delivery também. Mas vocês já vão estar olhando para a sprint que vai vir no futuro, não é? O que o time que está focado na parte de delivery está construindo agora, desenvolvendo mesmo a solução, já foi validado, já foi aprofundado anteriormente, então espaço, tempo, vocês estão vivendo a sprint assim, enquanto o time. Mas as tarefas e o foco das atividades é que muda para cada um, não é?
PEDRO: Legal e assim, com essa explicação que vocês me deram, eu acho que eu já tenho um spoiler da resposta. Mas essas atividades diminuem a velocidade do time de uma maneira geral? No sentido de que a solução vai demorar mais para ser entregue ou os sprints vão demorar mais para serem entregues?
LORENA: Então eu tenho uma resposta que é a resposta que ninguém quer dar. Depende. Porque depende muito do que está sendo olhado no discovery
e do tamanho da solução que a gente quer implementar, porque existem features que tem um risco muito menor, então pode ser que por elas terem um pouco menos, assim, ainda necessita de uma validação, mas ela é de um risco mais baixo, então ela vai para o delivery mais cedo. Mas, às vezes, existem questões que são tão grandes no nosso contexto, igual a Raquel comentou. A gente está lidando com produto legado, então assim a gente tem conhecimento disseminado em pessoas, então a gente tem que ficar ali procurando as pessoas, descobrir quem tem a informação. A gente também tem outros produtos que necessitam conversar com a gente. Então, assim, pode ser que o discovery desse item, ele seja relativamente um pouco maior do que outro que a gente já disponibilizou, mas isso não quer dizer que a gente tá demorando mais tempo. A gente também está ali no processo de montar um quebra-cabeça para que o delivery seja rápido, e também que a gente construa algum delivery que de fato vai atender o que a gente precisa, vai atender as regras necessárias e também eventuais integrações que a gente precisa fazer. Então assim, vai depender muito da situação e do tamanho do problema que você tem na mão, sabe? Então, assim, às vezes a gente não tem noção tanto do problema que a gente tem até aprofundar. E aí, às vezes a gente fica: é realmente a gente não sabia que isso seria tão grande, e a gente precisa parar, refletir, vamos quebrar isso mais? Então, assim acontecem essas situações com a gente também, principalmente no contexto que a gente tem, tudo é muito novo. Ninguém sabe de nada. Então assim, e como tem esse contexto que a gente precisa sempre aprofundar nas coisas, a gente ainda não tem a resposta para falar assim: vai ser rápido ou não, sabe?
RAQUEL: É, mas como a operação a gente sempre pensa, não é? Podemos quebrar mais esse problema? Isso é uma coisa que a gente sempre tem que pensar, porque a gente é assim, não é? A gente gostaria que backlog fosse um problema, mas a gente tem que entregar o produto, então é contínuo. A gente quebra o máximo que a gente dá e a gente vai entregando, e a gente vai inteirando também. Então a gente entrega uma primeira parte: essa aqui é o MVP da coisa, vamos ver como a gente pode melhorar, em qual parte vai ser mais importante de priorizar, também com o feedback dos usuários e do negócio. Então é uma coisa que é contínua, afinal de contas.
DIULIA: Pois é, e acho que independente da complexidade, é lógico que assim tem uma questão de qualidade atrelada ao gasto desse tempo aí, não é? Porque uma coisa é, por exemplo, a gente poderia levar o problema para desenvolvimento muito rápido, tirando as regras ali do que a gente acredita que é, porque sempre foi assim ou porque, enfim, não é? A gente fez uma conta lógica e a gente acredita que esse é o caminho mesmo. Mas tendo esse momento de reflexão, de aprofundar um problema, a gente está deixando de levar esse conjunto de indefinições para frente, não é? De levar para o time desenvolver e aí descobrir lá na frente que na verdade não sabe de onde vai puxar os dados, não sabe quais são as regras que precisa conter ali na solução. Então, por mais que às vezes a gente tem essa questão, tipo do, depende. Acho que de toda forma, o tempo atrelado à qualidade acaba gerando mais celeridade, justamente por causa dessa diminuição, igual vocês comentaram, diminuição do número de impedimentos, diminuição dos atritos na hora do delivery. Então acaba fluindo, não é? Vocês comentaram do discovery fluido. E isso que é o mais legal, não é? E aí, assim como é que vocês comentaram já que não foi um processo de já introduzir um monte de atividades, by the book, tudo lindo e tal. Como é que vocês começaram com Discovery contínuo dentro da rotina do time?
RAQUEL: Eu entrei no meio, a Lorena … Mas tem uma polêmica sim, que na verdade o time tinha começado antes e não deu certo, que não tinha tido esse discovery prévio para conseguir realmente fazer uma entrega. Aí Lorena fala mais, aí.
LORENA: Eu acho que a gente não contou sobre esse histórico do nosso contexto. A gente teve essa iniciativa com esse cliente, mas por algumas questões a gente não conseguiu prosseguir porque existiam muitas indefinições sobre o produto ainda. Estavam coisas a serem esclarecidas, e aí no retorno a gente teve vários aprendizados nesse período, não é? A gente de início, a gente teve um time que já tinha todos os desenvolvedores, já tinha designer, arquiteto, estava o time completo, pronto ali para construir o produto. Só que a gente não sabia por onde a gente começaria, porque a gente está falando de um produto muito grande e muito crítico. Nosso cliente. E aí quando a gente retornou, a gente começou com um time menor, que seria o time voltado para pelo menos, começar a identificar onde que a gente ia começar e qual era a solução que a gente ia começar implementando. Então foi um time, era de um designer, arquiteto de dados, arquiteto de soluções e o SEM. Esse foi o time que iniciou para que a gente tentasse pelo menos ter um norte, entender o que a gente queria entregar como primeira entrega, como MVP, para que eventualmente a gente conseguisse ir crescendo e também crescer o time de forma orgânica, para que todo mundo tenha tempo para aprender as coisas, mas também que a gente não saísse entregando coisas que não vão entregar nada, só porque a gente tem um time alocado ali, precisa desenvolver. Então, basicamente foi assim que a gente começou. Ao invés de a gente começar já com o time de delivery, a gente ficou uns dois, três meses só com essas figuras no time, para que a gente identificasse tudo que a gente precisava e chegasse nessa primeira solução, que aí poderia ser disponibilizado em produção e a gente conseguiria já começar a testar. Então, basicamente foram esses os nossos caminhos.
RAQUEL: Mas em outros contextos que eu já estive também, eu acho que ajuda muito a gente marcar sempre uma agenda fixa com o cliente, para a gente ir entendendo e mostrando, para eles verem que eles estão construindo junto esse produto, sabe? Então, essa visão de construção junto e na hora que a gente faz uma entrega não é uma surpresa grande para ninguém, isso facilita muito, porque o pessoal sente que eles estão construindo a várias mãos o produto. Nós aqui na dti, nós somos consultores e a gente não está ali no dia a dia deles. Então, essa aproximação entre a gente e o usuário e o negócio é extremamente importante para a gente realmente conseguir entregar valor.
LORENA: E sobre o que a Raquel comentou no nosso contexto, essa visibilidade que a gente começou a dar sobre as descobertas e sobre os problemas que talvez não era claro nem para o cliente, também fez com que o cliente ganhasse mais confiança e desse mais autonomia para o time. Então hoje a gente tem liberdade para contratar quem a gente quer, porque o cliente entende que aquilo lá é importante. Ele vê valor no que a gente está trazendo para eles. Você fazer um discovery não garante nada se você não trazer a visibilidade para o cliente sobre o que você está fazendo, também, e sobre o que você está gerando como artefato, seja dores ou problemas que você identificou para o cliente, então basicamente a gente aprendeu isso, sabe? Então a gente tem agendas contínuas que a gente apresenta esses resultados. A gente debate tudo o que a gente está fazendo, sobre essas soluções e acaba que, igual a Raquel comentou, é tudo assim, feito em várias mãos. Não fica só exclusivamente aqui com a gente como consultor.
DIULIA: Muito legal.
PEDRO: Então, eu estou pensando em mudar de assunto, gente. Quase, praticamente mudar de assunto. Não, é o seguinte, o que vocês comentaram sobre a forma que começou. Eu queria entender até se vocês tiveram barreiras organizacionais assim, que tiveram que vencer? Ou o que vocês entendem que eram os principais desafios de realmente se aplicar as práticas do discovery contínuo?
LORENA: Existiu essa barreira porque a gente estava lidando com um cliente onde que ele ainda está no processo de transformação digital. Então, o nosso produto, ele tem uma característica que está alocado de uma área que está ali no processo, que tem um olhar mais tradicional. Então você chegar lá e falar assim: vamos fazer discovery? Foi uma coisa que pegou todo mundo, sim. Mas para que a gente vai fazer discovery? Por que não é só simplesmente refazer o que a gente já tem no legado? Então, assim, existiu essa barreira, mas também por isso que a gente começou com essa iniciativa que a gente comentou do line lupin, porque isso também trouxe eles para perto para eles também crescerem assim profissionalmente, para eles verem que essa transformação vai fazer que o que eles estão querendo entregar com esse produto, para a companhia no geral, fato vai ser mais eficiente se a gente seguir dessa forma. Então, assim, não foi tão fácil assim, por causa desses atritos referente às questões de visão, mesmo, de como que a gente toca um produto. Que eu acho que existia muito uma visão de: do que é um produto e o que é um projeto. Acho que entrou muito essas visões, mas aí a gente conseguiu contornar de uma forma que todo mundo ficasse confortável e que também todo mundo compreendesse o valor que a gente estava gerando com o discovery.
RAQUEL: Mas nem tudo são flores, não é? Até hoje, às vezes a gente tem umas barreiras, a gente está descomissionando um produto antigo, então, o objetivo é descomissionar, mas a gente não pode simplesmente descomissionar, não entregando mais valor do que é, o produto antigo, até porque se a gente for simplesmente fazer um copia e cola, a gente tem que fazer um discovery técnico para entender como funciona. Mas a gente acredita que a gente consegue sempre fazer uma entrega melhor, agregando mais valor para a companhia, não é?
PEDRO: E que vocês entendem então ser fator de sucesso, assim? Se vocês puderem citar um ou dois, não é? Obviamente, tem várias coisas que vão fazer um discovery contínuo realmente funcionar. Mas o que vocês diriam ser primordial, assim?
RAQUEL: Teve uma entrega que a gente fez aqui, que foi essa entrega com várias mãos. A gente procurou muito os usuários e a gente conseguiu diminuir muito um tempo de processamento de um cálculo que fazia no outro produto. Aí quando a gente entrega com métrica e o pessoal, tipo, vê aquilo e sabe o que fez parte daquilo, você vê o olho da pessoa brilhando, não tem como. Elas vão falar assim: isso aqui não foram eles, foi a gente. Isso é um fator de sucesso muito grande. A gente vê a satisfação das pessoas que estão usando e a satisfação do negócio também, de de ver que o usuário dele, em vez de travar a máquina dele, ter que ficar 20 minutos sem poder trabalhar, ele já, tipo, já é um sistema web que ele pode conseguir fazer outras coisas ao mesmo tempo, aumentar a produtividade e ainda por cima diminuir esse tempo, desses cálculos entregues. Eu acho que isso faz brilhar muito os olhos de todo mundo. Todo mundo fica feliz com isso, não tem como. Então, entregas com métricas, não tem o que dizer, está ali escrito.
LORENA: Eu ainda complementaria dizendo que existe um fator que a gente precisa ter um certo desapego sobre as coisas, principalmente sobre as soluções que a gente propõe, às vezes, o cliente não se sente confortável. E eu acho que também tem aquela questão de: ai, mas a gente ficou aqui tanto tempo batendo nisso, a gente queria tanto fazer isso, mas naquele momento não é possível. Então, é importante também trabalhar esse desapego no time para que a gente também não fique muito, tipo assim, enviesado sobre outras soluções que a gente precisa trazer, porque no nosso contexto a gente tem muitas limitações, muitas, então assim às vezes gente quer entregar uma Ferrari, mas a gente não vai conseguir. A gente vai conseguir entregar uma patinete, e a gente tem que ficar tipo assim: ok, tudo bem, um patinete também vai gerar valor, então a gente também precisa ter certo desapego sobre essas limitações, porque são limitações momentâneas que eventualmente a gente vai conseguir passar por cima, mas para aquele contexto a gente vai ter que de fato seguir para aquela solução que talvez a gente não está tão feliz, mas que ela vai de fato funcionar e vai gerar valor. Da mesma forma que a gente também tem que ter o desapego sobre ouvir soluções que talvez não são provenientes do próprio time, porque às vezes tem outras pessoas de fato, que tem um olhar de fora que podem dar uma sugestão sobre alguma coisa. Então assim, também tem que ter essa questão para você também saber que a construção ela em conjunto, é colaborativo. Então assim, às vezes é uma ideia que você teve que é incrível e maravilhosa, mas não vai ser aquela solução que a gente vai implementar, por mais que você tenha feito discovery, por mais que você tenha todos os embasamentos. Então, acho que é necessário ter essa mentalidade também que você tem que resolver o problema, não é? Você não vai ter que amar sua solução.
DIULIA: Maravilha.
PEDRO: Adorei, gente, podemos fazer uns alguns take aways aqui para concluir? Eu queria até falar um que eu preparei aqui de acordo com o que vocês falaram, vocês podem me corrigir se eu estiver errado. Basicamente, com o discovery contínuo, a gente quer tomar as melhores decisões. A gente quer fazer isso da forma mais rápida possível, não é? Então, para conseguir fazer isso, é preciso que o time de produto inteiro esteja aprendendo de forma contínua. A Raquel falou do mindset colaborativo, super fator de sucesso para um discovery contínuo, bem como entregas com métricas, não é? E o que a Lorena falou aqui agora, que eu achei super legal é que, por exemplo, o que a gente descobriu que resolveria determinado problema meses atrás, pode não resolver mais, não é? Ou pior que isso, o problema pode nem ser mais tão importante como ele era antes. Então, o discovery pode ajudar, até mesmo a evitar desperdícios, correto? E aí, o desapego das soluções que a Lorena comentou. Vocês completariam com algo, aí?
RAQUEL: Acho que você falou tudo, Pedro, é isso. Nem precisava de 30 minutos de episódio.
LORENA: Basicamente isso, e perseverança, persevere sempre. Não desista.
PEDRO: Está vendo, gente? Diulia, eu estou virando designer.
RAQUEL: Um trabalho de formiguinha, não é? Não precisa chegar com um grande plano, de um discovery enorme, contínuo enorme, é tipo: vamos ali conversar com os usuários, entender realmente as dores. Eu acho que é um trabalho bem de formiguinha, até realmente ele conseguir tomar uma robustez que chegamos, não é? Que aqui no nosso time a gente está agora.
PEDRO: E vocês mesmas comentaram que vocês não tiveram sucesso logo de cara, não é? Então vocês tiveram que ir lá e tentar novamente. Isso que é legal, que teve aprendizado entre uma rodada e outra.
RAQUEL: Com certeza.
LORENA: É, além do aprendizado, a gente foi pedir socorro para várias pessoas dentro da rede DTI, para ajudar a entender como que eles faziam cada item ali, para a gente ver como que a gente poderia encaixar isso aqui no nosso contexto. É assim, além de atestar como que a gente poderia fazer a operação do nosso time funcionar com esse discovery, a gente também foi atrás de outras pessoas para falar sobre o nosso contexto e pegar tipo ideas também para ver o que que a gente poderia testar até a gente chegar onde que a gente está hoje. Então assim, foi um trabalho assim, bem colaborativo também com outras pessoas, de outros clientes, de outros times.
RAQUEL: E uma fofoca off topic aqui, rapidão. Assim, nosso produto não é o único produto do cliente que tem que ser descomissionados. A gente tem outros produtos que tem que andar junto com o nosso, que a gente inclusive tem várias interdependências. Outro dia a gente viu um dos gestores lá falando que um dos times, não é, que não é daqui nosso não fazia discovery. Era por isso que a gente ia ter que refazer, tipo, várias coisas no produto, porque eles não fizeram.
PEDRO: O barato que saiu caríssimo, não é?
RAQUEL: Barato que saiu caríssimo. Aí a gente vê, não é, a gente fica com orgulho, ver e nosso trabalho sendo valorizado, perfeito.
DIULIA: Desce até a lágrima.
LORENA: É, para complementar essa fofoca, foi a mesma pessoa que não queria fazer discovery no início.
DIULIA: Olha aí.
LORENA: Então foi uma mudança de mentalidade, muito doida, sabe?
DIULIA: Nossa muito legal. Um último tópico que eu acho que daria para a gente acrescentar nesse fechamento, é só que nem sempre vai precisar de atividades de discovery contínuo, não é? Às vezes, o que já teve de descoberta anteriormente é o suficiente para a gente encaminhar com algumas histórias para sprint, para ir diretamente pelo líder. Só para a gente também não criar um gargalo, de tudo que for entrar, tem que entrar em discovery contínuo, porque a gente fez o product discovery lá no começo, dentro do discovery contínuo a gente pode descobrir coisas que são … a gente pode renovar esse aprendizado, dar algo que vai mais para frente. Então dava para reutilizar conhecimento, não é? Muito bem-vindo isso.
PEDRO: Discovery, ele vai despender mais esforço quanto maior for a incerteza, faz sentido falar isso?
RAQUEL: Com certeza. E às vezes a gente vê até com o discovery anterior, a gente entregou alguma coisa, e aí, com o feedback do usuário, que pede alguma coisa, como a gente já fez um discovery lá antes, a gente consegue ver: isso aqui é tranquilo. Eu acho que faz sentido sim. Bora para delivery, vida que segue. Não precisa entrar na sprint de discovery para a gente passar para o delivery, não é?
PEDRO: Pode pular a catraca, se já estiver pronto.
LORENA: É, mas essa armadilha aí do discovery, ela pode acontecer também com o cliente, porque às vezes os olhos brilham tanto, tipo: nossa, discovery é incrível, que aí tudo eles falam: vamos fazer discovery? Aí você tem que falar assim: calma, calma, não precisa disso.
PEDRO: Parece que o jogo virou, não é mesmo?
LORENA: Exatamente. Já aconteceu muitas situações com a gente que era isso. Era uma coisa muito simples, falou assim, vamos fazer discovery. Eu fiquei assim, gente, não precisa disso não, mas isso mostra também que como que eles compraram a ideia, mas também é arriscado. Eu acho que é importante também o time saber podar essas questões para que também tudo não vire um processo muito moroso, e o que veio para agilizar só faz que a gente tenha mais trabalho e gaste muito mais tempo.
PEDRO: Muito legal, gente. Sucesso viu? Parabéns pelas conquistas aí no projeto de vocês. Espero que consigam gerar bastantes bons exemplos para a gente poder disseminar.
DIULIA: É bom demais, é muito bom quando a conversa vem com questões práticas, não é? Que a gente, para além de falar da metodologia, para além de falar de abordagem de ritos, de textos, a gente fala do time que tentou, igual a Lorena, comentou, perseverou e tem perseverado, e tem corrido atrás. Que não teve só momentos de alegria, mas é bom porque acho que dá até uma renovada na esperança de todo mundo, não é? Nas nossas, nas de quem está ouvindo, para a gente poder olhar e falar assim: não, calma, a gente vai conseguir, está todo mundo tentando encontrar a melhor forma de construir as soluções. Mas foi excelente, gente. Parabéns demais pelo trabalho que vocês vêm desenvolvendo. Temos um belíssimo episódio, não é?
PEDRO: Com certeza. Muito obrigado pela participação, Raquel, Lorena. Quando vocês tiverem terminado de descomissionar o sistema, a gente chama vocês de volta para contar como é que foi. Nem que seja uma enzima, não é, Diulia? Fazer o desfecho aí para a galera.
DIULIA: Lorena até passou a mão na testa.
LORENA: É, 2030, a gente vem aqui contar para vocês como foi a história.
PEDRO: É ótimo que seja, gente, faz parte. Nem tudo é rápido. Obrigado pela participação, gente.
RAQUEL: Obrigada Diulia, amei.
LORENA: Obrigada Pedro, tchauzinho.
DIULIA: Para quem gostou desse episódio, quem gostar dos outros também não deixem de, falei né, de ouvir que a gente já fica super feliz de ter vocês ouvindo podcast, mas também nos seguir nas redes sociais, no @osagilistas, a gente também está presente no LinkedIn, tem canal do youtube e além disso, não deixem de seguir, dar like, favoritar nas plataformas de streaming porque ajuda a gente, inclusive ter métricas. A gente falou de métricas aqui, não é? A gente tem métricas também que está sendo legal, interajam com a gente também. Fiquem à vontade para poder mandar nas redes sociais o que vocês gostariam de ouvir aqui como tema dos agilistas. É isso, pessoal, muitíssimo obrigada.
PEDRO: É isso.
LORENA: Até mais, gente, tchauzinho.
DIULIA: Até mais.
PEDRO: Obrigado, galera. Até a próxima.
