Schuster: Bom dia, boa tarde e boa noite. Vamos começar mais um episódio dos Agilistas. Hoje eu estou aqui com Vinição mais uma vez, beleza, Vinição?Vinícius: Tudo bem, pessoal? Vamos lá.Schuster: Estamos aqui também com Vitor Rangel. Tudo bom, Vitor?Vitor Rangel: Fala, Schuster. Beleza, pessoal? Beleza, Vinição?Schuster: Vitor, é a primeira vez, cara, que você participa do podcast? É, não é?Vitor Rangel: Cara, primeira vez. Sou fã do podcast, escutava ele desde antes de entrar para a DTI. É uma emoção grande estar aqui participando.Schuster: Que legal, legal demais. Cara, faz o seguinte, antes de a gente entrar no assunto – aliás, deixa só eu introduzir antes para o público. A gente chamou o Vitor. O Vitor, ele é um dos nossos especialistas em produtos, então a gente sabe que hoje um dos temas mais relevantes para as organizações que querem realmente gerar valor com o desenvolvimento de software é começar a partir para uma visão de produto. Esse tema tem sido explorado em vários episódios nossos, a gente tem um movimento forte em todos os nossos clientes para que isso aconteça. A ideia aqui é discutir vários aspectos do que é a visão de produto, porque isso é importante, o que dificulta, os riscos, enfim, explorar bastante esse tema e sempre com um viés, que eu acho legal, que a gente tenta ter aqui na DTI, que é uma consistência teórica aliada com a prática também, que a gente realmente aqui é bem pragmático, gosta muito de teoria, porque eu acho que a base teórica é importante, mas a gente também gosta de aplicar as coisas e ver o que acontece no dia a dia. Mas antes disso, Vitor, faz de uma breve apresentação. Eu prevejo aqui mais participações do Vitor, galera, acho que vai ser bom.Vitor Rangel: Pessoal, então meu nome é Vitor Rangel, igual o Schuster comentou, sou formado em engenharia mecânica, então bem de fora desse mundo de tecnologia. Comecei a trabalhar com gerenciamento de projetos e acabou que, nas idas e vindas do mundo, eu fui parar nesse mundo de tecnologia. Comecei a trabalhar bem no esquema de gerenciamento de projeto mesmo, voltado para a tecnologia, e acabou que essa atração do projeto com o produto e essa mudança – a gente vai até falar sobre isso aqui também – eu acabei migrando para produto. Estou trabalhando na DTI já tem quase um ano, um pouco mais de um ano, e sou apaixonado por esse assunto, converso bastante com o Vinição sobre isso. É um negócio que eu lembro, logo quando eu comecei a trabalhar com isso, a minha noiva falou, tinha tempo que eu não via o meu olho brilhar tanto sobre um assunto igual esse. Então é algo que eu sou apaixonado por isso mesmo.Schuster: Que bacana. Só uma curiosidade: você disse que trabalhou com gestão de projeto. Você começou na gestão mais tradicional? Ou você começou já na gestão mais Ágil?Vitor Rangel: Quando eu comecei a trabalhar com gestão de projetos foi em uma indústria mecânica mesmo, então era PMP mesmo, aquele projeto bem tradicional, de fazer escopo. E até uma das coisas que a gente fala muito: gestão de projeto é tudo diferente de produto, você tem um planejamento longo, tem aquele prazo bem definido. Então a regra número um de projeto: projeto tem início, meio e fim. Isso já é diferente para caramba de produto, comecei muito com isso. Eu sou uma pessoa muito organizada, mas eu acho que o legal é unir um pouquinho dos dois. Eu já sou uma pessoa organizada e eu desenvolvi muito a minha organização trabalhando com projeto tradicional, então quando eu fiz essa gestão de escopo, gestão de risco, foi muito que eu peguei um pouco dessa organização minha, que o Schuster já até falou que vai ajudar ele bastante.Schuster: É, pessoal, esse programa aqui tem um pré-roteiro. Normalmente eu brinco que a gente é Agilista e faz na hora, mas hoje temos um roteiro aqui.Vinícius: Emoções do (inint) [00:03:50], não é?Schuster: Haverá improvisos com certeza. Então, começando, você falou um pouquinho: projeto, a própria definição de projeto, tem início, meio e fim, inclusive a luta é para acabar de algum jeito. O que acontece no projeto sempre é isso, fica uma luta para acabar de algum jeito e partir para outro. Isso já diz muito sobre a diferença de abordagem. Como é que você resumiria quais são as principais diferenças e as implicações dessas diferenças entre essa visão de produto versus a visão de projeto e por que o mundo está indo, as organizações têm que ir mais para essa visão de produto?Vitor Rangel: Então, igual eu comentei, a primeira coisa que projeto tem é início, meio e fim. Isso já muda um pouquinho de produto, porque é muito complicado isso, um time desenvolve um produto e depois entrega. Quem vai cuidar dele? E vira aquele negócio, projeto tem muita crise de departamentização: cada um faz a sua parte. Quando você tem essa divergência de quem constrói e quem mantém aquele produto, você já tem muito aquele negócio de quem está mantendo ele já está colocando a culpa em quem fez o projeto, e são tarefas muito bem definidas. Trazendo esse contexto das tarefas bem definidas, de escopo bem definido, de prazo bem definido, eu vou trazer um termo que é muito falado aqui nos Agilistas, que é mundo VUCA. Produto, ele trata o seu sistema como organismo vivo, flexível e adaptável, isso está em consonância bastante com o mundo VUCA. O mundo VUCA está sempre mudando, então trabalhar com produto, você já está trabalhando, focando em hipótese, é focar em trabalho em ciclo curto, em colaboração de todo mundo. Isso que a gente está falando não é que trabalhar com projeto é errado, é porque cada coisa tem o seu lugar. Quando você vai construir uma ponte – eu lembro que quando eu comecei a trabalhar, a entender sobre metodologia Ágil versus PMP, o Bruno, ele me deu um exemplo que eu não esqueço até hoje: quando você vai construir uma ponte, você sabe exatamente que tem umas pilastras, que tem duas pistas, você sabe exatamente o que você vai fazer, só que quando você vai construir um sistema, você não sabe, e por isso que vieram as metodologias Ágeis. A gestão de produto vem casando perfeitamente com a metodologia Ágil, porque a metodologia Ágil te mostra como entregar a (forma) [00:06:11] de forma ágil, entregar com ciclo curto, para estar sempre verificando com o cliente, e aqui, a gestão de produto está sempre verificando o valor, então você está validando a hipótese que o seu cliente vai ver valor naquilo, você vai entregar um ciclo curto então, ou seja, você vai sempre entregar rápido, não tem aquela expectativa de quando aquele projeto vai terminar, projetos intermináveis, toda semana está acabando a sprint, está acabando alguma coisa. E muito importante também: ele foca bastante em colaboração. Assim como metodologias Ágeis, gestão de produto foca em colaboração. Apesar de ter um Product Manager, um Product Owner, você está sempre falando de gestão de produto, são as pessoas que cuidam de produto.Schuster: Achei interessante porque acho que vai ser até assunto do próximo tópico. O Ágil, ele em tese garante uma equipe que reflete continuamente, que aprende continuamente. Mas aprende em relação ao quê? E a visão de produto, ela dá essa referência. Outra coisa que eu acho curiosa, que eu lembro, há muito tempo atrás, não sei se o Vinição vai lembrar disso, tinha um artigo, acho que até da InfoQ, eu não sei. Eu lembro que era um artigo que chamava Psicopatia corporativa, você pegar o time quando ele fica bom, você desmantela o time, sabe? Que é o que acontece na visão de projeto. Não sei se (Psicopatia) [00:07:36], é um termo bem dramático. Você vai lá, o time demora para aprender o domínio do negócio, demora para poder ficar trabalhando, igual você disse, super colaborativamente, de forma complementar, todo mundo se entendendo. Na hora que você está no ápice disso, você desmancha esse time porque o projeto acabou. Então, é claro – só deixar uma visão aqui: é claro que ainda tem muitas empreitadas que são projetos, e que se beneficiam de todas as disciplinas e da necessidade de executar aquilo com início, meio e fim bem claros. Mas a questão, acho que principal aqui, é que esses produtos na verdade são ativos que vão gerar valor em longo prazo, não é, Vitor? E ao gerar valor em longo prazo, a sua visão tem que ser de longo prazo e tem que ser de geração de valor contínua, e o projeto já é contraditório com isso, porque o projeto, ele já parte de um statement e já parte de você querer acabar ele, sabe? Você já parte querendo acabar. E o produto você parte querendo que ele dure.Vinícius: No último episódio eu citei aquele (inint) [00:08:43] do Infinite Game. Mas é exatamente isso, o produto é um Infinite Game e o projeto é um Finite Game, então você está tentando otimizar ali (no final) [00:08:54], então.Schuster: Excelente observação. Sabe por que eu acho importante isso? Porque eu gosto de tomar muito cuidado aqui no podcast, eu sempre brinco que eu gosto de falar para os céticos, porque eu sou um cara cético em geral. Tem muito cara que ouve e fala: cara, projeto é um negócio que existe há anos e etc., agora é moda falar que projeto não vale nada. Entende? Então a gente tem que saber o tipo de problema que a gente está lidando. Quando fala, não é que projeto não vale nada, o que nós estamos falando é o seguinte, nós estamos falando aqui é de um Infinite Game, de uma coisa contínua, que tem que gerar valor, que vai ser estratégico, sobre qual o negócio vai estar apoiado. Então igual certos times da organização não acabam nunca, eles vão estar apoiados nesses produtos que não acabam nunca, não é uma coisa que você faz uma vez e entrega, não é isso?Vitor Rangel: Não, e eu sou uma pessoa que quem conhece, eu sempre falo que sou da política do meio termo. Eu não acho que produto é bala de prata, funciona para tudo, que projeto é bala de prata e funciona para tudo. Eu fiz uma pós em gestão de projetos, tradicional, seguindo o PMP, e eu não falo que isso foi de jogar fora porque eu trago muitas coisas de lá. Eu acho que dá para aliar o melhor dos dois mundos e falar igual você falou: trabalhar com projeto não é errado, está aí há anos e funciona para muitas coisas. Só que a gente está vendo um mundo novo surgindo, de sistema, de produtos digitais que não devem acabar, então você precisa pensar na nova abordagem. E eu dou um testemunho meu mesmo, eu quando eu trabalhei com gestão de projetos tradicional, eu estava doido para o projeto acabar. Imagina, eu queria logo: não, pelo amor de Deus, que seja outro projeto cheio de problemas, mas são outros problemas. Eu estava doido para aquilo acabar. Hoje, trabalhando com produtos, não. Eu já quero é trabalhar contínuo: vamos fazer o negócio funcionar. Não é uma coisa só de (inint) [00:10:45].Schuster: Você falou um negócio engraçado, isso aqui, para mim, é aquela história que a gente fala que tem que entender a natureza humana, o Mariotti falou isso em um episódio. Cara, um projeto, você tem que acabar com ele, nem que seja na marra. A verdade é essa: ele tem que acabar. O que você quer fazer é acabar com ele mesmo, porque o sucesso é acabar. Ninguém tem sucesso falando assim; tem dez anos que eu estou nesse projeto aqui. Então já é impossível ser qualquer coisa contínua, de longo prazo, porque o projeto, já todo mundo fala: o seu projeto, ele tem uma duração finita, você tem uma meta bem clara. O produto, ele já muda o jogo e fala: cara, beleza, está em um jogo diferente – que é esse jogo mais infinito que o Vinição citou. E nesse jogo, o que você tem que procurar é o quê? Gerar valor continuamente. Eu queria então passar para esse segundo tópico nosso aqui, que é o seguinte: beleza, eu tenho o Ágil que vai me ajudando a aprender o tempo todo e vai me ajudando a diminuir risco e a gerar valor. Basicamente é sempre essa história, você está sempre diminuindo o risco e garantindo, entregando valor. Quais são os riscos inerentes à essa atividade, de se fazer um produto dessa natureza, um produto digital?Vitor Rangel: Quando a gente vai construir um produto, e aqui o que eu estou falando, a gente sempre fala sobre discovery, de descobrir o que eu tenho que fazer, como é o valor que eu vou entregar. Aqui eu só vou dar um alerta antes, que é assim: cuidado para não transformar a gestão de produto e o Ágil em Cascata disfarçada. Não é que tem que fazer isso aqui no começo, na sprint zero, e depois esquecer. A gente gosta muito de falar que isso é o discovery contínuo, então isso é algo que tem que estar no dia a dia das pessoas, todo mundo tem que estar atento a isso aqui. Mas então esse discovery, eu gosto de citar aqui o Marty Cagan, que é a principal referência de gestão de produto no mundo, ele escreveu o livro Inspired, e para quem está querendo começar a entender sobre gestão de produto, eu acho que é a primeira leitura e fácil de ler, apesar de grande, ele é fácil de ler. Infelizmente só tem ele em inglês por enquanto, mas eu acho que está saindo em português no início do ano agora, em 2021. Ele cita quatro riscos que você tem que analisar e antes de começar a desenvolver qualquer coisa, você tem que analisar esses quatro riscos, que é o risco de usabilidade, ou seja, o cliente vai conseguir usar aquilo? E é muito associado aos designers. O risco de valor: se o cliente vai comprar aquilo. E aqui eu vou trazer até um ponto até muito importante, que eu sei que tem muito cliente nosso, muito ouvinte dos Agilistas, que são pessoas que desenvolvem sistemas internamente, eles pensam: o meu cliente, o meu usuário, tem que usar isso aqui, é obrigatório, então não vou me preocupar com esse risco de valor. Mas não, quando o seu funcionário, o seu colaborador, usa um negócio porque é obrigado, ele não vai fazer aquilo com boa vontade, ele não vai entregar tudo o que ele pode. Então o risco de valor, ele tem que ser levado em consideração mesmo dentro, para sistemas que são utilizados dentro da empresa, porque você tem que fazer com que o usuário queira usar aquilo. É muito comum você ver, disponibilizar um sistema para um usuário e as pessoas acabam usando a planilha do Excel e depois usa só o que é obrigatório dentro do sistema. E isso você não está entregando o valor completo.Vinícius: Até porque você está fazendo um sistema interno para resolver algum tipo de problema, por exemplo produtividade. Você criou um sistema que é improdutivo.Vitor Rangel: Você duplica o trabalho, porque a pessoa vai ter o trabalho de fazer no Excel e depois copiar do Excel para o sistema. E isso é muito comum, eu já vi isso acontecer em muitos lugares.Schuster: Vou te falar, viu? Tem um aspecto também, só um comentário também, que a barra, a expectativa, são pessoas dentro da empresa, mas são pessoas que vivem em um mundo onde a barra vai ficando cada vez mais elevada. O cara usa Netflix e não sei o que, tudo sem fricção. Eu acho tão engraçado, só um comentário, eu comecei a pagar usando o meu celular, com um chipzinho, e é impressionante, umas coisas que você nunca usou na vida e quando você usa – hoje eu acho completamente absurdo quando eu tenho que tirar o meu cartão da carteira, o cartão de crédito, Sabe? Fala: putz, que trabalheira. Fiquei 47 anos fazendo – 47 não, fiquei muitos anos fazendo isso e acho isso absurdamente com muita fricção. Então o que eu estou querendo dizer é que até nesse jogo para engajar todo mundo, para trazer todo mundo, principalmente o jovem, que vai estar acostumado com isso, acho que fica mais claro que esse risco, tanto de usabilidade quanto de valor, não pode ser desprezado nem internamente.Vitor Rangel: Não pode. Não pode, de jeito. E é muito comum você ver…Vinícius: É o próprio…Vitor Rangel: … sistemas internos que desprezam ele completamente.Vinícius: O próprio Cagan fala muito disso, no próprio Inspired. Ele dá alguns exemplos, não vou lembrar dos exemplo especificamente não, mas, por exemplo, coisas do tipo: eu quero fazer um negócio para ouvir música. Você pode fazer o melhor negócio do mundo. Se a galera já usa o Spotify, você vai ter que fazer no mínimo alguma coisa que tenha alguma atratividade igual ao Spotify, então você vai ter que atacar esse risco de usabilidade, usando meio que com um risco de valor ali, porque tem o custo-benefício. Então é a mesma coisa a análise que você faz com um cenário interno, entendeu? Se eu vou fazer um sistema para resolver algum problema, ele vai ter que ser melhor em algum aspecto do que o outro, porque ou você vai obrigar uma troca forçada ali e vai perder a produtividade, por exemplo, que vocês está esperando, ou você poderia fazer um negócio que poderia ser até mais voluntário, que ali o pessoal vai usar (inint) [00:16:22].Schuster: Mas Vinição, sabe o que deve acontecer muito? Não sei se o Vitor concorda, só para (explicar) [00:16:26] esse assunto só mais um pouquinho, porque eu acho ele realmente importante. Eu acho que o cara, ainda mais as empresas que as estruturas são mais tradicionais e hierárquicas, ele pensa em resolver o problema do gestor. O cara pensa assim: se o pessoal estiver usando aqui, esse (troço) [00:16:42], eu vou ter informação para eu tomar a decisão, que é algo muito comum na estrutura hierárquica, e o cara tem que dar um jeito de usar. E a questão das personas, e não pensar no cara ali na ponta, como é que faz para, no meio da atividade dele, ele fazer aquilo sem fricção e poder também ajudar na gestão.Vitor Rangel: E tem um ponto também, que até o Cagan, ele fala muito no livro dele, que ele fala isso para os engenheiros, mas eu acho que isso server para todo mundo, que ele quer trabalhar com missionários e não com mercenários. Quando você trabalha com mercenário, ou seja, você só entrega ali o que ele tem que fazer, você força ele: você vai usar esse sistema. Você não está utilizando o total potencial dele. Quando você trabalha com missionários, ele vai não só utilizar como ele vai ajudar as pessoas em volta. É muito comum, quando você convence uma pessoa que é influente a utilizar o sistema, deixar o Excel de lado, utilizar um sistema, ele começa a convencer as pessoas em volta. Então ele começa: aqui, você já usou esse sistema aqui? Tem um exemplo até que já foi falado no podcast aqui, que é da PRODAP, que foi aquele vaqueiro lá, que inicialmente ele era contra e ele começou a gostar, e ele começou a incentivar a galera a utilizar. Então é transformar as pessoas em missionários e não mercenários.Schuster: É, o produto existe por um motivo e já que esse motivo é importante, melhor você ter os missionários. E os outros dois riscos aqui? O risco de negócio e de viabilidade técnica, o que você me diz?Vitor Rangel: Os outros dois riscos, a gente tem o primeiro, que é o risco de viabilidade técnica. Esse normalmente é muito direcionado para o arquiteto, para o DL. É basicamente: aquilo é possível? Eu posso querer fazer um produto que vai me transportar daqui para São Paulo em dois segundos. Mas é possível tecnicamente? Não é. Então você tem que ficar barrando.Vinícius: Mas do que possível, é até viável? Às vezes é até possível.Vitor Rangel: Isso.Vinícius: O custo é proibitivo?Vitor Rangel: Exatamente, se é viável em questão de dinheiro também. E está muito associado até à essa questão de dinheiro com risco de negócio. Principalmente quando surgiu essa questão de aplicativo, de sites, todo mundo quer ter um aplicativo, quer virar um Uber dos ônibus, quer virar um Netflix dos vídeos fitness. Só que você tem que ver se o que você quer está relacionado com o seu negócio, não é só criar um aplicativo que eu vou me transformar em um produto digital inovador. Então você tem que analisar se esse produto que você está desenvolvendo está alinhado com o negócio da sua empresa. Eu gosto muito de linkar com a missão da empresa, é muito legal quando a empresa tem um propósito. Quando você vê que esse produto está alinhado com esse propósito, então tudo se encaixa, aquele produto se encaixa perfeitamente, porque senão você vai criar simplesmente um anexo na sua empresa, aí não adianta de nada.Vinícius: Voltando um pouquinho à parte do valor, esse me chamou muito, me marcou, porque são (inint) [00:19:31] até bastante simples que ele propõe lá, por exemplo: valor. Mas como é que você testa valor? Eu achei muito legal isso, não sei se você lembra disso, então, por exemplo, o jeito mais fácil de testar valor é com dinheiro mesmo. Se você está ali, se você observa, por exemplo, que o usuário quase que tiraria o cartão de crédito para fazer uma transação no seu protótipo, na sua aplicação. Mas ele cita outras coisas que são simples e interessantes, do tipo você testa ali com o usuário se ele recomendaria realmente, vamos supor, o teste que vocês está fazendo com ele ali, se ele recomenda ele já está trocando algum ativo dele e aquilo ali tem uma implicação de geração de valor. Ele fala alguns outros legais também, por exemplo tempo: se você tenta marcar uma próxima reunião com o usuário para testar uma próxima feature, se ele está disponível ou não, porque se ele estiver realmente vendo valor naquilo ali, muito provavelmente ele vai conseguir arrumar o tempo. Eu lembro que ele fala até de credencial. Se ele, por exemplo, se ele fala assim: loga aqui com o seu Google, com o seu Facebook. Se ele te fornece as credenciais dele para fazer uma próxima transação significa que ele já está enxergando alguma coisa ali. Então basicamente é o seguinte, se ele troca alguma coisa. Eu achei isso muito legal, porque são formas de fato, a gente fala: valor, valor, valor. Às vezes é meio etéreo como você testa isso, e ele coloca de um ponto de vista mais prático e eu achei bem legal.Schuster: Então, mas eu queria fazer uma pergunta, acho que é a seguinte, cara. Beleza, eu estou entendendo o seguinte: quando eu vou fazer um produto, eu tenho que ter em mente que esses riscos têm que ser continuamente gerenciados, dirimidos, etc., eles estão ali presentes. Você falou do discovery contínuo, entendeu? Como é que isso acontece no dia a dia de fazer um produto? Ou seja, o que é? Isso tem a ver com o quê? Com formulação de hipóteses? Isso define os meus OKRs? Como é que se traduz no que acontece com o time que vai fazer aquele produto? Como é que eles pegam esses riscos, identificam eles continuamente e eles fazem isso virar algo que é combatido durante o dia a dia, entendeu?Vitor Rangel: O jeito mais fácil, que todo mundo pensa, é sempre a parte grande, que é quando eu vou fazer um discovery, fazer um (Lean) [00:21:53] Inception inicialmente, eu vou criar um aplicativo novo, vou criar um negócio novo, esses quatro riscos têm que ser, em uma design sprint esses quatro riscos são levados em consideração. Mas respondendo até do dia a dia, eu que trabalho com gerenciamento de produto, isso vai até às coisas pequenas. Quando eu vou escrever uma história de uma nova funcionalidade, de uma nova melhoria, eu tenho um template, que nesse template são coisas para me ajudar, para me guiar quando eu vou fazer o grooming, quando eu vou fazer a entrevista e, ao final dele, eu tenho algumas coisas para me lembrar para sempre levar em consideração. Um deles é essa Histórias INVEST, que é um acrônimo para saber se ela tem valor, é um acrônimo bem presente no Agilismo, mas é se ela INVEST e, falando mais especificamente dos riscos, eu sempre, quando eu vou fazer uma nova funcionalidade, de tudo, pode ser um botão que eu vou incluir, eu tenho que passar por esses quatro riscos. Quando eu passo por esses quatro riscos para um botão, às vezes eu gasto cinco minutos pensando sobre isso. Eu penso sobre isso ali, gastei cinco minutos, pronto, analisei o risco, já está bom, passo para desenvolvimento. Agora o tempo que você gasta com isso é proporcional à sua funcionalidade, ao que você está desenvolvendo. Quando eu vou criar um novo fluxo – recentemente a gente fez algumas coisas de novos processos de vendas, que vai mudar completamente a forma como o usuário vai navegar dentro do sistema, aí gasta mais tempo, você tem que usar esses testes que o Vinição comentou, você tem que validar as hipóteses. Validação de hipóteses nada mais é do que testar o risco de valor. Risco de usabilidade é o teste que você faz com o designer, que ele coloca um (inint) [00:23:29] frame e pede para o usuário navegar. O risco de viabilidade técnica é o grooming técnico, que os desenvolvedores fazem aquele grooming técnico para entender o que é aquilo, o que é possível. Eu gosto de trazer esse grooming técnico até para o início, sabe? Antes de eu chegar para o desenvolvedor: faz o grooming técnico disso aqui. Eu gosto de bater um papo com os desenvolvedores antes: aqui, eu estou querendo fazer isso aqui, fazer essa conexão com o banco de dados. E eu vou até falar um pouquinho mais para frente, a gente vai falar sobre as skills de quem trabalha com produto, é importante eu ter uma noçãozinha técnica para saber conversar com o desenvolvedor, para ver a viabilidade técnica daquilo. E o risco de negócios são…Schuster: Alguém faz um Spike, vai fazer uma experiência. Porque eu fiz essa pergunta? Eu tinha um fundo para tentar alertar quem escuta e acho que você já fez esse alerta, mas acho que a gente tem que falar o tempo todo, que é o que eles chamam em inglês de Waterfall in disguise, Waterfall disfarçada.Vitor Rangel: Exatamente.Schuster: Esse negócio, por algum motivo isso insiste em assombrar todo mundo. Então qual é a nossa tendência? A nossa tendência sempre é trabalhar como se fosse pegando o Snowden, sabe? Naquele quadrante analítico. Então o cara pensa: entendi, eu levanto todos os riscos, faço o meu plano, e depois é só fazer. E vai lá e faz, faz um Waterfall, entendeu? E nós não estamos falando disso.Vitor Rangel: Não.Schuster: Eu só queria deixar, ou seja, é dinâmico, eu estou o tempo todo revendo, eu estou fazendo hipóteses, eu estou aprendendo. Inclusive eu vou aprendendo os novos riscos que vão surgindo, esse tipo de coisa. Concorda?Vinícius: Só complementar um ponto, o jeito que eu enxergo isso é exatamente a combinação, você falou lá no início do Ágil com produtos. Aqui para mim, nesse momento é que mora essa pergunta que você fez, é que mora a junção do Ágil com as práticas de produtos digitais. As práticas de produtos digitais são essas, ou pelo menos os princípios, desses que foram citados, dessa questão do mapeamento de risco, várias técnicas que o Vitor citou ali. Isso, combinado com essa mentalidade de ir colocando tudo à prova sempre. E, principalmente, baseado no fato que você entende que você não sabe qual é a solução, por isso que a gente está falando em hipótese, o único jeito de você colocar isso à prova é ficar validando esses riscos o tempo todo, igual você colocou. Me marca muito um trecho que ele coloca no livro, que ele fala assim, o Eric Ries, quando escreveu o livro Startup, (criou) [00:26:04] o MVP. E o MVP, de Minimum Viable Product, ele fala assim: foi um momento muito legal, que esse conceito começou a se popularizar. Só que ao mesmo tempo ele faz uma certa ironia, do tipo: cara, o pessoal não entende que o P, eles acham que o produto é um produto que já é totalmente pronto, mesmo sendo viável – viável do ponto de vista de já ser uma coisa de deliver, uma coisa já entregue, que já funciona. Ele é muito mais radical em relação a isso, ele fala que o P deveria ser de protótipo, sabe?Schuster: Devia ser um T, Minimum Viable Thing.Vinícius: Ele fala assim, deveria ser uma proposta.Schuster: A coisa.Vinícius: Porque, na verdade, a intenção do protótipo é validar aquele conjunto de quatro riscos constantemente. Um monitora o investimento, então você só parte para uma próxima rodada de investimento a partir do momento que você já identificou, minimizou aqueles riscos ali. Só depois disso você faz mais investimento para que de fato aquilo ali realmente se torne um produto. Porque na cabeça dele, e eu acho que faz total sentido, um produto é uma coisa que realmente escala, é uma coisa que realmente está preparada para receber um conjunto já de usuários, para ser de fato utilizado para realmente funcionar.Vitor Rangel: E tem até um…Schuster: Então só, para a gente poder…Vitor Rangel: Tem até uma…Schuster: (Entendi, entendi) [00:27:26].Vitor Rangel: Eu acho que vou até já avançar, já pegar um pouquinho do próximo, mas uma forma que eu gosto muito de evitar essa Waterfall in disguise, porque assim, muita gente me pergunta: você trabalha com produto, você é um PM, você é um PO, você precisa saber desenvolver? Igual eu falei no começo, eu sou um engenheiro mecânico, não sei desenvolver. Só que o Gibson Biddle, que é outra referência que eu tenho muito em gestão de produto, ele era VP de produto da Netflix, ele fala que o gerente de produto, ele tem que saber um tanto de conhecimento: ele tem que ter conhecimento técnico a ponto de não torcer a cara quando um desenvolvedor vai conversar com ele. Eu reflito isso para o desenvolvedores também, o desenvolvedor, ele tem que saber de gestão de produto a ponto de não torcer a cara. Então o desenvolvedor, ele tem que saber o que é usabilidade, o que é entrega de valor, o que é persona e o que é jornada. Porque eu quero que quando eu entrego uma história de usuário para ele, ele critique aquela história. Eu acho a melhor coisa do mundo, eu já falei isso com o time que eu trabalho aqui na DTI, que é quando os desenvolvedores, eles viram para mim e falam: mas por que a gente vai fazer isso? Eu pensei em uma forma melhor, a gente pode mudar? Isso desde o começo até às vezes na hora do teste, a pessoa que está testando, a nossa QA, às vezes ela testa, ela vê uma opção melhor, não tem problema, vamos mudar, vamos adaptar. Então isso evita esse Waterfall in disguise, que é o que ele escreve.Schuster: Excelente comentário. Sabe por que? Uma coisa que a gente já falou aqui também, mas as coisas tem que ser repetidas exaustivamente porque realmente é difícil de mudar, existem razões, por exemplo: o PO, que é quem faz a gestão ali, o principal cara responsável pela gestão, hoje em dia ele tem quase poderes sobrenaturais aos olhos de todo mundo, já viu? Tipo, o negócio vira e fala: estou tranquilo porque tem o PO ali, que vai resolver, vai definir o que gera valor. O time também fala isso: estou tranquilo, porque eu não tenho que me preocupar com o que faço aqui não, porque o PO vai me falar. Então se gerou ou não gerou valor, a culpa é do PO, senão não (autorizou) [00:29:26], a culpa é do PO. Então o PO virou um cara que encapsula o time e que vai contra a essência de um time Ágil, que é todo mundo junto, no mesmo jogo. A gente fala isso direto, a Enzima que a gente fez essa semana é sobre isso: estamos todos jogando o mesmo jogo, mas uma pessoa ali tem muito mais visão de gestão de visão de produto, tem mais tempo a se dedicar naquilo, tem mais base teórica, tem um olhar diferente. Mas está todo mundo no mesmo jogo, todo mundo tem que ajudar na (autorização) [00:29:52], todo mundo tem que ajudar o tempo todo a entender esse risco. Eu gostei muito dessa definição que você disse, de não torcer a cara, porque ela é bem Agilista, isso incomoda muito quem não é Agilista, que é qual é a fronteira exata? Mas eu achei muito interessante, acho que isso aqui dá até uma Enzima, sabe? E o time, está todo mundo junto no jogo e o PO traz uma grande contribuição, mas ele não pode ser esse cara mágico, que sabe tudo, porque aí vira – eu acho tão engraçado como as coisas perdem a essência, sabe, Vitor? Vira um time que ele pode nem saber o que é o produto, sabe, o extremo, porque tem um PO falando para ele o que ele faz. E vira um negócio que também nem tem que estar junto ali, sabe? Junto porque o PO está tomando a decisão. Então imagina como é que você resolveu o problema do Ágil, o Ágil quer aproximar todo mundo, botar no mesmo barco, aí você criou um cara super poderoso no meio do caminho, que sabe tudo.Vitor: Não, e uma coisa…Schuster: É meio doido.Vitor Rangel: Para evitar isso, uma coisa que eu tenho que (inint) [00:30:52], principalmente nesse período de pandemia, às vezes o desenvolvedor me pergunta uma coisa, de um bug, de uma história, eu já falo que pode chamar a pessoa no chat e resolve com ele diretamente, não precisa passar por mim. Às vezes tem alguma dúvida, quer chamar a pessoa de negócios, a gente tem que começar a colocar os desenvolvedores mesmo, todo mundo para conversar. Eu estive conversando com a empresa, com os clientes, não é só o PO, não precisa ser uma ponte o PO com as pessoas.Schuster: Exatamente. Eu acho que o PO, um dos papéis dele é botar sempre, sempre criar esse ambiente com essas restrições que são importantes, mostrando: não esqueçamos dos riscos de usabilidade, não esquecemos disso. Mas ele não tem que tomar todas as decisões sozinho e é o que a gente sempre fala aqui, de que o líder, um dos tópicos é sobre essas skills de liderança, eu sempre falo: esse líder mais apropriado para esse tipo de empreendimento, ele é um líder que não quer ser tão protagonista, sabe? Que trabalha mais oblíquo e que bota o time mais em jogo. Você acabou de dar um exemplo disso, um líder tradicional, ele faz o contrário, ele fala: não, não conversa com o cara não, quem conversa sou eu. Você conversa e eu acho isso curiosíssimo. O exemplo que você deu é o contrário do que muito líder tradicional faria. Na verdade, alguém poderia estar contando: uma vez eu cheguei e o desenvolvedor tinha que conversar direto com o negócio, eu achei isso um absurdo. Eu falei: não, não faça isso, você sempre conversa comigo antes e eu converso com o negócio. Fala um pouquinho sobre essa liderança de produto, liderança desses times ágeis, na verdade.Vitor Rangel: Eu vou dar outro, vou trazer algumas coisas também, que eu também aprendi foi com o Gibson Biddle, eu ouvi uma palestra dele uma vez na Product School, ele e o Cagan, eu sigo eles, sempre que eles fazem alguma palestra, escrevem algum artigo. Ele falou muito, que é muito importante quem trabalha com produto ter skills não só técnicas de produto, que é igual isso que a gente falou, de usabilidade, valor, mas também skill de liderança. Eu fiquei muito feliz, eu voltei de férias agora, segunda-feira, em duas semanas de férias, o time conseguiu rodar tranquilo, não precisou de mim para nada. E eu fiquei feliz para caramba, porque eu deixei as coisas mais ou menos organizadas, passei algumas coisas, mas a galera conseguiu resolver sem depender de mim, ou seja, o time teve autonomia para isso. Eu gosto muito daquela analogia do líder servidor, então do líder jardineiro. Tem outro problema maior: eu, como PO, eu não sou o líder do time, eu não tenho a hierarquia para me ajudar, eu trabalho com influência. Tendo essas skills de liderança e preparando o terreno para todo mundo, para o time fazer com que o produto cresça, eu tive essa prova agora nas minhas férias, eu fiquei duas semanas fora, na praia, tranquilo, sem ser acionado com problemas.Schuster: É, isso é bonito, isso que eu falo, isso é um jeito de medir sucesso diferente, sabe? É quase que uma analogia com o que eu falei de projeto, sabe? No projeto tradicional, e não de forma errada, mas você tem que acabar ele. Uma liderança tradicional, ela tem que controlar as pessoas, ela é quase que medida por isso mesmo, o tanto que ela está controlando e tornando as pessoas eficientes sob determinados aspectos ali que podem ser medidos. Você está querendo destravar valor naquele time e destravar valor daquele time é botar todo mundo no jogo. Se está todo mundo no jogo é claro que, se você tirar duas semanas de férias, o jardim não acaba, que é na analogia do jardineiro, você chega lá e as plantinhas estão lá ainda e o negócio não acaba. Então eu queria lançar para um outro tópico agora, que é assim: beleza, nós já entendemos que nós temos uma visão contínua, que a gente sempre tem que ficar de olho em certos aspectos que podem comprometer tudo que nós estamos fazendo, que são essas quatro dimensões de risco, que a gente viu. Vimos que a gestão de produto é uma das disciplinas, mas não quer dizer que ela toma todas as decisões sozinha, e que tem que ser exercida nesse estilo de um líder jardineiro e todo mundo tem que estar no jogo. E em relação aos times em si, a gente gosta muito de falar na DTI, que até no nosso manifesto, as pessoas obviamente são vitais, mas elas existem em grandes times, a gente entrega valor em grandes times, não é sozinho, a gente faz as coisas colaborativamente em grandes times. Eu falo a gente o ser humano em geral, tudo é sempre assim, a gente adora procurar os heróis mas as coisas acontecem em times. Fala um pouquinho sobre esses times de produtos.Vitor Rangel: Eu vou citar novamente o Marty Cagan, eu cito ele praticamente todo dia, ele é uma referência mesmo. Teve uma palestra que ele deu, que foi em um evento do Matera, que é uma grande instituição de produto aqui no Brasil também, que ele fala sobre três tipos de times. Porque, beleza, é igual a gente falou, a gente entendeu como que funciona, a empresa vai lá e monta o time de produto. O outro é aquele time lá, que tem o PO, que tem o Scrum Master, que tem os desenvolvedores. Só isso não basta. Às vezes aquele time não é um time emponderado e não adianta de nada, então por isso que ele fala dos três times. Vou seguir a mesma lógica que ele seguiu, que é começar do pior para o melhor: o primeiro time é o time Feio, ele chama de time de entrega. Nada mais é do que o time que constrói código e entrega código, ou seja, é bem um exemplo de uma Cascata disfarçada, porque o time recebe a demanda, ele entrega aquela demanda e passa para a próxima. O Product Owner, ele é simplesmente um gerenciador de backlog, ele simplesmente fica ali organizando o que está entrando, o que está saindo, qual é a prioridade do negócio. Então, no final das contas, ele não está preocupado com valor, ele não está preocupado com quem é o usuário, como o usuário está usando, ele não sabe quem são as personas, não sabe métrica do usuário, ele é simplesmente um time que está entregando um código, só que na estrutura de Agilidade de produto, ele está disfarçado ali. Isso ele fala que é muito comum em empresas tradicionais e ele é bem rígido, ele fala que se você, pessoa de produto, está trabalhando em uma empresa dessa, ele fala até para pedir demissão. Eu acho que é um pouco rígido demais, nem sempre as coisas são tão fáceis assim, mas ele fala bem isso, que é aquele time ali que é o time feio mesmo, o negócio é difícil. Ele dá muito exemplo de…Schuster: Achei engraçado esse nome Feio, é engraçado, não é, cara? Se visualmente as coisas correspondessem aos nomes, já pensou? Você olha para aquele time lá, mas que time feio. Tem que mudar aquilo ali.Vitor Rangel: Não, e esse ele fala que é bem – por isso que ele chama de Feio. O outro, o segundo, já é o time Ruim. Ainda é um negócio ruim, o time Ruim, só que não é feio, pelo menos é um negócio que está no meio do caminho. O segundo time que ele já fala…Schuster: Só um negócio: você ia dar uns exemplos, não ia? Do time Feio, ou você não ia?Vitor Rangel: Não, o time Feio…Schuster: (inint) [00:37:51]. (Você falou que ia) [00:37:51] dar um exemplo…Vitor Rangel: … ele fala que é muito comum em empresas muito tradicionais e ele cita muito lá, no contexto dos Estados Unidos, que ele fala que é muito comum em bancos, porque banco já tem muita hierarquia, é muito rígida a regulamentação, e fala que esse time Feio é muito comum em banco. Só que ao mesmo tempo ele já fala que isso não precisa ser uma desculpa, porque tem bancos que ele conhece que funcionam muito bem. E o segundo time já é o time Ruim, que é o time que ele chama de time de funcionalidade, ele já é um time um pouco melhor. O primeiro é um time que existe para construir código, é o time Feio, existe para construir código. O time Ruim, ele já mudou um pouco, ele já existe para servir o negócio. Ele é um time que recebe o roadmap de funcionalidades e ele tem que pensar um pouquinho em como que ele vai entregar e resolver esses problemas. Só que ele até fala que esse time Ruim é aquele time que tem tudo para ser bom mas não é, então são aquelas empresas que muitas vezes estão em processo de transição, que estão adotando o Ágil, estão começando a entender o que é trabalhar com o Ágil. Ele parece que é um time de produto, só que o que é a diferença dele para o time Bom? A gente vai falar do time Bom, o time Bom é um time de produto emponderado, ele existe para servir o cliente, ele está em parceira com a área de negócio para servir o cliente. O time Ruim, ele serve o negócio, então ele não tem muito contato com o usuário final. O usuário final tem contato com o negócio, que tem contato com o time de TI.Schuster: O time Ruim na verdade não tem esse contato direto com a realidade, com o negócio que enfrenta.Vitor Rangel: Isso.Schuster: O negócio vira um proxy ali para ele, traduz para ele o que ele acha que é.Vitor Rangel: Exatamente.Schuster: Como se fosse isso, não é?Vitor Rangel: Só que…Schuster: E o time ainda fica meio encapsulado ali dento da organização, sem saber exatamente pegar um feedback direto.Vitor Rangel: Só que já é um pouco melhor do que o time Feio, porque o negócio já confia, dá mais autonomia para o time de produto desenvolver o que ele precisa, só que ainda não está com todo o potencial. O Cagan fala muito disso: às vezes o negócio até funciona, mas não está com todo o potencial que poderia estar. O time com todo o potencial é o time Bom, que é aquele time, é o time de produto emponderado. Ele trabalha junto com a área de negócios, então não tem mais aquela departamentalização de time de TI e time de negócio, é time de produto. Eu estou trabalhando todo mundo junto para entregar o produto para o meu cliente final e o produto é parte do negócio, ele não é algo que serve o negócio. Isso são os exemplos que são claros: é Airbnb, Google, Facebook, todos esses que tem grandes produtos no mundo inteiro, seguem esse time Bom. O Cagan até está lançando um livro novo, que é para ajudar lideranças a criarem uma estrutura boa para esse time Bom. O Inspired, ele é focado em quem trabalha com gestão de produto. O novo livro dele, que é o Empowered, emponderado, ele fala sobre como que a liderança – você já falou muito aqui, não é, Schuster? Como a liderança tem que apoiar essa transformação. Esse livro é focado nisso, de ajudar a liderança a apoiar essas pessoas, dar autonomia e emponderar, para que ela desperte todo o potencial dela. Novamente, o time Ruim não é de todo – ele entrega coisa, ele entrega valor, só que não está usando todo o potencial.Schuster: Sim. Interessante isso mesmo. Uma coisa que a gente comenta aqui: é claro que uma organização, ela vai fazendo essa transição gradual, sabe? Então a questão aqui não é simplesmente ridicularizar, vamos supor: mas organização tal. Mas seria importantíssimo que as organizações, os times, conseguissem fazer essas reflexões para saberem o que eles são para poderem, a partir daí, fazer uma ação, porque é muito comum…Vinicius: Pelo menos isso.Schuster: É. Porque imagina, ninguém em princípio ia querer isso. O cara está ali investindo uma grana em produto, está montando uma estrutura toda, etc., etc., mas de alguma forma a estrutura força o resultado a ser vários times Feios, entende? Ou seja, são vários times que a organização, no final do ano, olha que coisa frustrante, está gastando milhões, está fazendo todo o esforço que ela gostaria de fazer para ficar digital, entende que isso é super relevante, mas ela cria um exército de pessoas, que é até curioso quando você falou sobre time Feio, eu fiquei pensando: os caras dentro do time Feio e até o PO, nesse caso pegando desse jeito que o pessoal faz, encapsular o time, é quase como se eles não tivessem nem olhando para aqueles quatro riscos, porque aquilo quase que não é problema deles, porque eles pegam pedidos, igual o pessoal fala de pegar pastel, entregar. Eles ficam pegando pedidos e fazendo. Talvez o cara possa olhar para as técnicas, para garantir que está fazendo, talvez possa fazer com uma usabilidade um pouco mais restrita porque não tem acesso ao usuário, etc., etc. E esse time que está no meio do caminho, que é o Ruim, eu acho até interessante uma organização já estar nisso, ela já estar em um momento mais evoluído, mas a gente fala isso muito, aquela organização que é Customer Centric mesmo, ela diminui o caminho de feedback entre os times e o cliente final, para ela realmente são os (clientes) [00:43:26] que respondem rápido. Se você bota o time enfiado lá dentro de uma estrutura e bota um tanto de coisa no caminho, imagina, aquele time entrega alguma coisa, aquilo ali vai ter uma resposta de vários clientes, vai ser processado pelo negócio, sabe lá em que tempo, de que forma, e um dia já vai chegar no time como uma funcionalidade, sabe? Aquele time nunca ganha uma noção real, aquela organização não vira Customer Centric de verdade, ou no mínimo não vira tão rápido.Vitor Rangel: Só para complementar isso, esse ponto é muito importante sempre. Vou repetir o que eu falei do meio termo, às vezes o pessoal pode pensar: não, mas é impossível você colocar o desenvolvedor para ficar conversando com o cliente porque senão ele não vai trabalhar nunca. No meu dia a dia, tem dia que eu preciso blindar os meus desenvolvedores, que eu preciso dar uma segurada na onda da galera para não chegar neles. Mas tudo é um meio termo, tudo você tem que sentir ali. Tem dia que você tem que deixar o desenvolvedor ir falar com a galera e tem dia que você tem que segurar a onda, então você tem que sentir. O bom do time Ruim é justamente isso: é uma empresa que está querendo mudar. O Cagan fala até isso, que você, como gerente de produto, você é um dos principais responsáveis por ajudar essa empresa a chegar em um nível Bom. E eu expando isso até para o Feio também, eu acho que sempre que você está representando gestão de produto, você tem que tentar mudar. Eu concordo muito com isso que você falou: ninguém quer ser um time Feio. Você está ali, botando dinheiro, você quer que o negócio funcione.Schuster: Verdade. Cara, a gente está chegando ao final e você falou, isso é um tópico que é super debatido, qualquer livro que você ler sobre sistemas contrários e adaptativos mostram que as estruturas tradicionais tem um foco enorme em eficiência, que é isso que você falou, sabe: o cara tem que estar desenvolvendo. Ainda é uma visão totalmente mecanicista de não botar todo mundo no jogo, o cara acha no fundo que desenvolvedor desenvolve, quem é QA testa, PO prioriza, é a maquininha lá, o arquiteto arquiteta e é isso, se você olha para o cara…Vinícius: E talvez o pior de tudo ainda nem é isso, o pior de tudo é que um gerente, um diretor define o que tem que ser feito.Schuster: É, exatamente. Porque basta você ser eficiente. Cara, vamos fazer o seguinte, a gente tinha mais um tópico aqui, que dá outro episódio, que é um tópico que é super rico, que são principais erros na gestão de produto, isso vira um podcast por si, sabe? Então a gente pode fazer um episódio com o Vitor de novo e ainda convidar outras pessoas para trazerem histórias. Vitor, muito obrigado, eu gostei para caramba do episódio, eu acho que fica claro então um grande resumo, que nós estamos falando de um jogo infinito, um jogo de longo prazo, de um jogo onde a gente quer gerar valor contínuo, mas que para gerar esse valor nós não podemos perder de vista que a gente tem riscos super relevantes de usabilidade, de valor, de negócio, de viabilidade técnica e, que no fundo, a gente tem que fazer uma coisa super simples, mas que de alguma forma as organizações tornaram tão difícil, que é fazer o time todo estar no jogo, o tempo todo, combatendo esses riscos. É muito curioso, no fundo a gente quer isso, mas de alguma forma a gente cria incentivos que fazem com que cada um não entre no jogo e aquele time acabe sendo um time Feio, ou se tudo der certo, um time Ruim, e dificilmente um time Bom. Mas valeu demais, Vitor. Um abraço, cara, e a gente vai gravar outro episódio com certeza.Vitor Rangel: Isso aí, obrigadão Schuster, obrigadão Vinícius. E com certeza estou à disposição para outro episódio. Valeu galera, até mais.Vinícius: Falou, pessoal, muito bacana.Schuster: Vinição, abraço.Vinícius: Até mais, abraço.