Marcelo: Bom dia, boa tarde, boa noite. Vamos começar mais um episódio Os Agilistas, mais uma vez aqui com o Vinição. E aí, Vinição?
Vinícius: E aí, tudo bem, pessoal? Vamos lá.
Marcelo: Então hoje nós vamos tratar de um tema que acredito que seja extremamente relevante, e ele acontece em muitos contextos, em muitos desses contextos onde isso que eu vou falar agora acontece, existe uma enorme dúvida sobre como lidar com isso. Eu estou falando de que, gente? Estou falando de contextos em que você tem o que a gente gosta de chamar aqui de uma data forte, de uma meta muito forte (com) determinada funcionalidade, um determinado módulo, é alguma coisa assim, esteja em produção, pode ser desde algo legal, alguma coisa regulatória que é requerido por uma legislação, como pode ser porque tem um lançamento importante de um produto, porque pode ser uma data tipo um Black Friday, que é um negócio extremamente assustador, porque para determinadas empresas, se você fracassar no lançamento de algo na Black Friday, você simplesmente pode estar jogando fora um ano daquela empresa, então existem datas, que a gente chama de datas fortes, que são marcos extremamente significativos, que tem uma característica de tudo ou nada, do tipo assim, ou o negócio deu certo, ou não deu, quando chega naquele marco, e isso aí é um pouco contra a essência do ágil, no sentido em que no ágil você procura gerar uma cadência, e ao gerar essa cadência e entregar continuamente, é como se você tornasse desnecessário esse conceito de ter uma data forte ter um dia do tudo ou nada. Por outro lado, no mundo real, de vez em quando isso vai acontecer, como eu disse, seja por ter uma data ali tipo um Black Friday. Então a gente trouxe dois convidados, aqui da DTI, para discutir sobre esse tema, vou pedir para eles se apresentarem agora, e depois nós vamos entrar diretamente aqui no tema. Então, primeiramente, a Mari. Tudo bem, Mari?
Mari: Tudo bem? Eu sou a Mari, sou líder aqui da (Aquários) , uma das tribos da DTI. Estou na DTI há quase seis anos, e já passei por algumas situações aí relacionadas a datas fortes, eu acho que eu consigo .
Marcelo: Sobreviveu às datas fortes?
Mari: Sobrevivi. Estou passando por uma agora, inclusive, (mas estou sobrevivendo) .
Marcelo: (Cuidado, você) está passando por uma, depois nós vamos ver se deu certo.
Mari: Está bom.
Vinícius: (Declaro aqui o Fourquest) .
Marcelo: Estamos aqui também com o Gustavo. Tudo bom, Gustavo?
Gustavo: E aí, pessoal. Bom dia, boa tarde, boa noite. Tudo bem com vocês? Falando um pouquinho aqui da minha trajetória, eu venho da área de tecnologia mesmo, sou formado em sistema de formação, pela UFLA, tenho também MBA em gestão de projetos, atuo no mercado já há cerca de uns oito anos já, caminhando para oito anos, sempre nesse contexto de tecnologia, gestão de produtos. Hoje, especificamente, eu estou aqui a DTI, como (productioner) , então já estou caminhando para dois anos de casa, já. Prazerão estar aí com vocês hoje.
Marcelo: Então você que chega para o time e fala que tem uma data forte, então? A culpa é sua. Então a culpa a sua, não é?
Gustavo: (Difícil) . A culpa geralmente é do PO, só que o PO coloca a culpa no cliente. Então
Marcelo: O PO tem que ser milagreiro, já viu? O PO sabe tudo, não é? Então, a primeira, eu já falei um pouquinho sobre isso na introdução, mas eu queria que vocês falassem, na verdade, pode ter uma data forte ou não? Se alguém falar que tem uma data forte, fala: “Não, no ágil não podemos ter uma data forte”.
Mari: Eu acho que não tem muito como fugir da data forte, porque em algumas situações, como você falou, faz parte, é a necessidade do contexto ou do cliente, ou do produto, então tem situações em que a gente tem que saber lidar com ela, não tem muito como fugir dessa data, por exemplo, a Black Friday que você falou, ou uma campanha, sei lá, de natal, dia das mães, ou uma legislação, então são situações que fazem parte do processo ou do produto, e a gente tem que saber lidar com elas.
Marcelo: Mas, assim, só complementando, Gustavo, tem datas fortes de verdade, tem datas fortes de mentira, concorda?
Gustavo: Com certeza. Com certeza. Sempre vai ter aquela data imposta, que muitas vezes o pessoal acha que é uma data forte, mas quando a gente vai analisar aí, acaba não sendo muito bem uma data forte. Até nessa pergunta, eu acho que de forma bem direta mesmo, eu também concordo com a Mari aí, acho que existe sim, no nosso contexto de agilidade, esse assunto da data forte, e eu acho bem interessante essa discussão, pois eu vejo, assim, muitos times tratando essa questão da data forte quase como se fosse um tabu mesmo a ser quebrado, uma forma (de, sei lá, às vezes projetizar) o produto que está sendo construído, por isso alguns times acham até que não deveria existir data forte no ágil, nesse contexto ágil. Então, assim, a gente vê muitas vezes , você brincou aí que às vezes o PO que traz, a hora que a gente traz o anúncio de uma demanda com data forte aí, o time já começa a desesperar, falar que não dá, ou que a data vai pressionar o time, que diminui a capacidade criativa do time, isso tudo porque eles estão enraizados naquele pensamento de que é um bicho de sete cabeças.
Marcelo: Sabe um comentário? Eu falei brincando, claro, na pergunta do tipo, assim, pode ter ou não pode ter, porque, assim, você tem que ter uma abordagem pragmática, você está inserido no mundo, você não decide (o que o mundo) , então a gente tem que falar aqui, se tem, como é que a gente lida com isso, mas ao mesmo tempo, tem que evitar ter datas fortes artificiais, a verdade é essa, porque a gente sabe (que tem) . Na verdade, uma data forte artificial é um sintoma de um não entendimento do método ou de uma falta de confiança no time. Quando eu falo não entendimento do método, normalmente é um sintoma de que é um time que não gera valor continuamente, porque se o time gera valor continuamente ele vai diminuindo a ansiedade do negócio, e o negócio vai sentindo o progresso, vai vendo que é possível fazer, vai aprendendo, e eu diria que esse é o ágil na sua essência. Mas se o negócio não está vendo progresso, ele começa artificialmente definir as coisas, (porque fala assim, e é compreensível também) .
Vinícius: (É o jeito dele meio de cobrar, não é) ?
Marcelo: É, porque, assim, poxa, então vou fixar uma data aqui e vou ver o quê que tem, só que muitas vezes, a gente já falou isso em vários outros podcasts, (pode ter outros episódios) , que muitas vezes também o negócio não está vendo progresso por causa dele mesmo, porque ele mesmo não está fazendo MVP, não está fazendo experimentação, não está dando autonomia para o time, mas, enfim, pode ser um sintoma desse. Mas partindo do princípio que é uma data forte real, digamos assim, seja por causa de um lançamento importante, por causa de uma legislação, o que muda então em um time que tem que encarar? Em vez do time entrar em pânico, e ficar com raiva do PO ou do cliente, o que um time maduro deveria fazer (fácil uma data forte) ?
Vinícius: Szuster, rapidinho, só um comentário ainda prévio sobre a discussão de data forte, vocês já falaram isso, de certa forma, mas só para enfatizar de um outro jeito, que eu acho que é interessante, é o seguinte, a pergunta é: “Pode ter ou não pode ter? Se aplica ?”, para mim, assim, até a pergunta, se for uma data forte de verdade, ela nem faz muito sentido, porque, assim, não é se pode ou se não pode, é simplesmente é, seria quase que uma negação do mundo, entendeu? (Tipo assim, é algo) .
Marcelo: tem time que nega, igual o Gustavo falou, tem time que é tão apaixonado pelo método que é essa negação mesmo. Assim, a gente não pode se apaixonar pelo método a ponto de um time falar assim: “Não, você não está entendendo, no ágil não existe data forte”, eu tenho certeza que tem time que fala isso: “(Você não está entendendo) .
Vinícius: É, isso é uma falta de compreensão.
Marcelo: Falta de maturidade, não é?
Vinícius: É. Porque, assim, tem várias coisas no mundo que elas são porque são, igual da Black Friday, se for uma coisa que acontece lá no final do ano, qualquer coisa, que na verdade não está sob o controle do time, então não tem como ele definir, (seria até meio loucura) , é tipo um negacionismo da realidade.
Marcelo: Pega a Copa do Mundo agora, alguém fala: “Tem a Copa do Mundo agora”. “Não, não. Não vem me encher o saco, não, porque (é o método nosso) ”.
Vinícius: Mas beleza, assim, só voltando a pergunta.
Gustavo: .
Vinícius: Diga.
Gustavo: Perdão. Eu acho que uma entrega com data forte eu acho que é justamente uma oportunidade de o time demonstrar mesmo a sua agilidade, a adaptabilidade, o poder que o time tem ali de se adaptar a essa característica, até a própria eficiência, a qualidade do time ali, então acho que não só pode, como deve ter essas datas fortes aí de vez em quando para tirar o pessoal da zona de conforto.
Marcelo: Então, mas aí que está, (posto que) tem a data forte, tem uma pegadinha muito grande, que para mim é o principal tema aqui, que é muito fácil, todo mundo, ao se deparar com a data forte, partir (para um mini waterfull) , sabe? Porque você fala: “Já que tem uma data forte, então eu chaveio, vou do ágil (para um waterfull) , planejo detalhadamente tudo que tem que ser feito (e o que pode dar errado) . Aí eu pergunto, mas a gente está aqui para falar de como seguir usando abordagem ágil, e ainda assim trabalhar com uma data forte, certo?
Mari: Certo. Você está falando, eu lembrei. Ontem mesmo eu estava em uma reunião com o cliente, ele comentou assim: “Olha, se tem uma coisa que eu acho que pode dar certo para a gente conseguir atingir a data é o ágil, o método tradicional com certeza não vai fazer com que eu consiga atingir essa data. Então aí é, na verdade, até o contrário, assim, eu acho que a única alternativa que a gente tem para conseguir entregar alguma coisa com agilidade que a gente (precisa, e ágil) , no sentido de velocidade, é o ágil mesmo, o método tradicional com certeza não vai entregar.
Marcelo: E sabe o que é engraçado? Esse negócio é muito engraçado, porque, filosoficamente, se alguém acreditar que para a data forte basta eu planejar e detalhar, e vai dar certo, por que eu não faço isso sempre então? Não é? Assim, é só eu chamar toda data de data forte, e vai dar sempre certo. Então, assim, é muito engraçado, existe um motivo pelo qual o ágil começou ser adotado, esse motivo é porque desenvolver softwares é um processo de aprendizado contínuo e você só garante a convergência enfrentando a realidade. Então você não pode chegar em um momento que você tem uma data forte e jogar isso tudo fora, e imaginar que agora eu consigo sim não fazer ágil, (é um negócio, é um contrassenso) . Assim, dá para não fazer ágil, até para deixar claro, (porque não é uma coisa questão só) , dá para não ser ágil quando você tem exatamente certeza total do que fazer. Total, total, total. Não só do que fazer, mas como dos riscos técnicos, (aí você pode falar assim) , aí não tem muito por que não planejar e detalhar. Mas como a gente sabe que isso quase nunca acontece, porque uma data dessas, a pessoa quer fazer o lançamento no Black Friday, tem uma ideia, uma ideia de negócio, por exemplo, coisas legais talvez caia um pouco mais no que a gente falou aqui, mas mesmo essas, a gente sabe que a solução também vai ser cheia de nuances e que é bom ir testando e convergindo o tempo todo, não é? Porque eu estou até adiantando um pouco, mas eu diria que o grande caminho é garantir que está convergindo o tempo todo, para que tenha o mínimo que funcione antes de chegar à data forte. É isso que seria a abordagem geral?
Mari: Eu acho, o que a gente tem tentado fazer é focar muito nas necessidades que precisam ser atendidas para aquela data forte. Então acho o primeiro passo você chegou a perguntar, o que fazer, então eu acho que é a gente tentar entender quais são as necessidades ou dores, dependendo do contexto, que precisam ser atendidas até uma determinada data, e aí a partir disso começar a pensar em soluções, tanto de negócio, quanto técnicas, para tentar resolver.
Marcelo: Uma necessidade de negócio, não é?
Mari: Necessidade de negócio.
Marcelo E não as funcionalidades, não é?
Mari: É, eu acho que as funcionalidades vêm depois, como uma possível solução, mas até as funcionalidades eu acho que a gente tem espaço para usar ferramentas e métodos ágeis para descobrir quais são essas necessidades, mesmo em uma data forte, mesmo em um projeto com a data certo.
Marcelo: Sim. Quer complementar algo aí, Gustavo?
Gustavo: Eu concordo bem com a Mari aí também. Eu acho até, assim, que antes mesmo de já passar para essa ideia de criar uma funcionalidade, de já partir para a solução, eu acho que é bem importante a gente entender até o tipo dessa data forte, qual é o objetivo que está sendo imposto com essa data forte também. Então vocês até já comentaram um pouquinho da Black Friday e tal, eu até enxergo, assim, acho que tem três grandes tipos, assim, sabe, de data forte. Uma primeira, assim, que eu vejo, é aquela data forte relacionada à janela de oportunidade, então acho que está bem atrelada à questão da Black Friday, que vocês comentaram aí também, então é aquela janela de oportunidade ali que a gente tem, se a gente não lançar essa solução a gente vai acabar perdendo (esse time) , e aí já era. Um exemplo legal também, vocês começaram falar da copa, aí me veio esse exemplo aqui agora também, é o álbum de figurinhas da copa, acho que é bem clara essa janela de oportunidades do álbum de figurinhas da copa, se ele não for lançado nesse período de uns três meses antes da copa, até o final da copa, não adianta nada ele ser lançado, porque se for lançado antes a galera ainda não está naquele (hype) , assim, de comprar as figurinhas, de consumir esse produto, e depois também acho que a mesma coisa, tipo assim, o pessoal já passou (o hype) , ninguém está interessado mais em consumir esse produto. Então, assim, eu vejo esse como um primeiro tipo de data forte. Um segundo, que eu acredito até que no contexto de tecnologia, vários times aí (acredito que) já passaram por eles também, que é aquela data forte que pode parar alguma operação, ou que vai ficar com o produto, ou uma solução ali impactada, então esses casos estão geralmente relacionados a uma descontinuação de algum produto utilizado por uma empresa, ou o fim de uma licença de uso, por exemplo. É um exemplo bem legal aí, recente, que eu acho que (esteve no) contexto de bastante empresa também, é a descontinuação, por exemplo, do Internet Explorer, a gente sabe aí que ainda tinha diversas empresas que utilizavam como base tecnológica, seus sistemas rodando tudo em cima do Internet Explorer, então quando a Microsoft veio e falou: “Vocês têm até tal data aí, porque o Internet Explorer vai ser lançado”, ela impôs uma data forte para diversas empresas, diversas pessoas, que ainda utilizavam Internet Explorer. E um terceiro tipo que eu vejo, que aquela data forte que pode gerar sanções ou multas ali para a empresa, para pessoa. Então aí entra muito na legislação que você comentou aí, Szuster, a própria LGPD é um exemplo bem claro aí, acho que foi criado lá em 2019, que foi uma lei que impôs para bastante empresa aí também, para não falar todas, praticamente, essa data forte aí, se eu não me engano as empresas tinham um ano para se adaptar com relação a esse uso de dados aí, que senão poderiam sofrer essas sanções, essas multas. Então eu vejo esses três tipos de data forte (em um item, assim) , um ponto bem interessante, bem legal, que eu acho, que é um ponto que permeia esses três tipos, é a questão da geração de valor, que é um tópico bem comentado aqui no Os Agilistas, acho que o pessoal sempre comenta da geração de valor. Esses três tipos, se a gente for ver, tem impacto direto na geração de valor do produto, ou do produto que está sendo lançado, do produto que já está em produção, de algo que já está sendo utilizado, ou então uma sanção, que não adianta nada você estar gerando valor para algum produto ali, mas vem, por exemplo, a Lei Geral de Proteção de Dados e te dá uma multa depois, que anula esse valor gerado ali.
Marcelo: (Então, mas eu queria ser advogado do diabo, porque, assim, ok) , nós temos que olhar as necessidades, mas não é só isso, nós vamos entrar em um modo diferente de operação, porque uma coisa é eu saber que eu tenho que ir, eu olho as necessidades e garanto que eu vou convergindo gradualmente essa abordagem ágil, mas beleza, eu não tenho, chegou no dia lá, se eu não convergi, cara, eu vou convergir mais dois (sprints) , qual o problema? Aqui, não. Aqui, assim, olha, se não chegou no Black Friday, não vou usar a palavra aqui, senão teria que botar (um pi) , assim, deu tudo errado. Então, assim, a pergunta é, que tipo, eu parto das necessidades, ok, que tipo de cuidado adicional eu vou tomar, até para poder gerar plano B no meio do caminho, , nós estamos aceitando o fato de que aquela data não pode falhar, e nós estamos falando para o cliente confiar em um método que fale: “Olha, essa data não vai falhar, (o que nós vamos fazer depois disso: “Desculpa, foi mal, ano que vem) , mas ano que vem vai ficar ótimo no Black Friday”.
Vinícius: .
Marcelo: (Então, assim) , quais são as mudanças no método, na operação? (Sabe? O que se faz diferente) ?
Vinícius: Assim, até inaugurar aqui, aí cada um pode falar alguma coisa, mas, assim, primeiro assim, até o que você falou antes, a questão de existir uma data forte muda a natureza do problema? Não. Pelo menos, assim, grande parte, não. Na verdade, o produto continua devendo ser colocado à prova da realidade, ou seja, pode ter um comportamento meio inesperado, tem os problemas de convergência, então, assim, não mudamos a natureza do problema, ou seja, o método ágil, a princípio, ele é aplicado, mas temos uma grande restrição no caminho. Eu acho que deveria ser encarado assim, temos uma restrição, (posso, por exemplo, posso ter uma restrição de custo, uma série de coisas) , eu tenho uma restrição de janela de tempo, de precisão. Então, de cara, a gente precisa ter precisão, acho que é um ponto bem importante que tem que ter um acompanhamento de precisão, igual o Szuster falou, se eu não tiver essa restrição, se eu durar mais um pouco de tempo e tiver dentro das restrições orçamentárias e tal, ok, eu posso entregar um mês antes, um ano antes, aí depende da temporalidade da coisa, então isso eu acho que um controle de precisão é super importante. O outro tipo de coisa que tem que ter, o Szuster até me falou ali um pouco, que tipo assim, eu tenho que ter planos B, então, assim, do ponto de vista de gestão do produto, todas as funcionalidades, ou maior parte delas, deveriam já considerar versões simplificadas, por exemplo.
Marcelo: Contingência.
Vinícius: (É, contingência) . Se eu não conseguir atingir determinada coisa, o que, na verdade, ainda hipoteticamente, tem o potencial de gerar valor, mas de forma mais simplificada, por exemplo. Então acho que do ponto de vista de gestão de produto, (para tudo precisa ter versões simplificadas já meio que, mais ou menos, pensado, nem que seja de hipótese, então acho que isso são coisas que acho que mudam) .
Marcelo: Mas sabe por que eu estou rindo? Que parece que a data forte faz com que o time (devesse) na essência do ágil mesmo, que é simplificar, entende? Porque, assim, concordam? Você tem que simplificar absurdamente a solução para garantir que você tem uma solução, sabe? Assim, antes da data, porque seu negócio é esse, assim, a gente tem que ter uma solução antes da data, único jeito de você garantir a data é você ter uma solução antes da data, se você deixar pra ter uma solução na data, (assim) , para mim não tem outra coisa, você tem que ter uma solução antes, e um jeito de ter a solução antes é simplificar absurdamente as coisas e depois (bordar) o que precisar mais para frente. .
Mari: Eu ia falar dessa ideia de simplificação, eu acho que é essencial mesmo, e é importante que a gente tenha isso em mente o tempo todo, porque a tendência é, ao longo do tempo, a gente ir tentando fazer uma solução talvez mais adequada, mais robusta, mais completa, então a gente ficar o tempo todo, a cada (sprint) , a cada novo refinamento, voltando e entendendo, isso é o mínimo que precisa ser feito, dá para simplificar mais? Qual é a dor que eu estou tentando resolver com isso? E voltando sempre nessa necessidade, nessa dor, para garantir que a gente está simples, o mais simples possível, tem que ser feito constantemente, durante o tempo todo.
Marcelo: Tem que ter uma paranoia maior ainda, não é?
Mari: Tem. (Tem que ser bem focado) .
Marcelo: Você como PO, Gustavo, como é que você faz isso aí? .
Gustavo: (Cara, eu gosto de brincar aqui. Perdão, Szuster) .
Marcelo: (Não, não, só ia falar, porque) é engraçado, porque, assim, eu só fiquei pensando na cabeça aqui que o certo, se eu fosse de um cliente agora, eu ia botar uma data forte para o MVP, sabe? Do tipo, assim, se não tiver MVP no dia tal, acabou, sabe? Porque é o único jeito, talvez, de fazer todo mundo simplificar tudo é você ter uma data forte mesmo, não é? Porque todo mundo quer complicar.
Gustavo: . É isso aí. E eu gosto até de brincar, é o que eu ia comentar agora pouco, que o PO tem que ser bom com a faca, tipo assim, ele tem que saber fatiar as coisas o mínimo possível para alcançar justamente essa simplicidade aí que você comentou, que eu acho que se o PO não (conseguir, não tiver esse skill de) simplificação mesmo, e não só o PO, ele tem que conseguir transpassar isso aí para o time também, então o time também tem que ter essa ideia de simplificação, de conseguir diminuir a quantidade de trabalho desnecessário, e priorizar somente o que é indispensável, prezando principalmente por essa questão da simplicidade aí. E esse é um dos (anos de atuação de um productioner, seja customer, data forte) , nesse contexto ágil a gente sempre tem que pensar nisso, e com a data forte eu acho que é uma boa gestão de produto, só se torna ainda mais necessário mesmo. (Pois, assim) , é preciso utilizar essas ferramentas de gestão de produto com muito mais constância, muito mais consistência, é necessário realizar um processo de (discovery) para definir muito bem os objetivos, as necessidades, negócios que vão gerar valor, (que é algo que a gente já vem falando aqui um pouquinho) . É necessário também ter uma gestão do backlog muito eficiente, para que não seja priorizados e feito demandas desnecessárias, então o time precisa realmente estar comprometido com o objetivo e não com uma lista ali de requisitos. E a própria criação do (roadmap) também, e a gestão do roadmap eu acho que precisar ser muito eficiente também, precisa mostrar um caminho real para você alcançar aquela entrega ali, então nesse contexto de data forte, eu vejo muito importante, assim, a elaboração de um roadmap mais (tático, que consiga traçar os objetivos a cada sprint) , em vez de um roadmap mais estratégico, mais amplo, assim, que apresenta somente os marcos principais, de forma mais ampla, até a entrega final.
Marcelo: É engraçado, , o que me vem à cabeça muito é isso, cara, você tem que ser muito mais paranoico e muito mais pragmático, sabe?
Vinícius: Igual você falou, você tem que ir na essência mais ainda, não é?
Marcelo: (É. Você tem que ser, imagina, porque aí até, não sei o que o Vinição vai falar) , tem um outro assunto também, Vinição, você podia também, além dessa paranoia do ágil, tem uma outra paranoia que a gente sempre fala isso aqui também, por mais que a gente acredite no ágil, esse produto está sendo criado dentro de uma organização que é mais ampla. Quer dizer o que? Tem dependências que estão além do alcance do ágil, sabe? Então, por exemplo, (você pega uma coisa) que vai ser lançada no Black Friday, às vezes você vai estar integrando com outras coisas, às vezes vai ter uma campanha de (marketing) , que depende de não sei o que, eu estou querendo dizer o seguinte, você também tem que ter uma paranoia enorme na comunicação de tudo que está acontecendo, sabe? Você não pode deixar ninguém da organização ter dúvidas sobre o que está acontecendo. Mais ainda, imagina que você fez o produto certo, mas alguém não fez uma outra coisa, que faz parte do programa, sabe? Entende o que eu estou falando? Isso também joga tudo por água baixo. Então, assim, no fundo, a paranoia aumenta muito mais, porque já que é tudo ou nada, você não pode se deixar o luxo de supor que vai dar certo, é como se a gestão de risco fosse muito mais, porque o risco aumentou muito.
Vinícius: No fundo, assim, àquela hora que eu falei da restrição, acho que acaba que isso se transforma em um risco, tipo assim, então tem que ter várias facetas (da gestão dele) .
Marcelo: O impacto do risco é gigante.
Vinícius: É gigantesco, (exatamente) .
Marcelo: O risco do atraso, (imagina, a gestão disso, se eu atrasar o impacto, perdi meu ano, que nem uma empresa de varejo) .
Mari: Essa parte de comunicação é uma das mais importantes, na verdade sempre é, mas aqui se torna mais relevante ainda, e eu acho que a principal questão é a transparência nessa comunicação, para conseguir disparar os planos alternativos o quanto antes, que é o que você estava falando, de sempre ter o plano B, C, outras opções, mas a gente tem que ser transparente e rápido para conseguir acionar esses planos, quando necessário, de uma forma mais rápida. (Então acho que a comunicação) .
Vinícius: É assim, igual o Szuster falou, parece que você tem que ir na essência, você tem que ser mais, tipo assim, você tem que ser verdadeiramente ágil.
Marcelo: É. Sabe outra coisa também que eu vejo que tem que ser muito, muito, muito paranoico, é em ter testes verdadeiros, entendeu? Porque, assim, a gente sabe, já cansou de falar aqui no podcast, que o negócio, existe aquela história, gente, todo mundo quer otimizar os recursos, e essa otimização sempre é gastar mais , só que muitas vezes o mais certo, vamos supor, em uma coisa que vai ser lançada em uma Black Friday, uma vez você tem uma versão X, você ter certeza (que aquilo escala no Black Friday) , e aí isso gasta dinheiro, gasta esforço, sabe? Então eu falo assim, é fácil cair em vários (pecadinhos) , sabe? Assim, você tem que tomar cuidado para não ficar concentrado em um aspecto só, e pensar como é que eu vou ter progresso concreto antes de lançar o negócio, sabe? Porque, assim, isso é um outro aspecto, concorda? A gente é a favor do progresso concreto, mas o progresso concreto mesmo é rodar na Black Friday, mas tem que rodar.
Vinícius: É, esse ponto é bem bom mesmo. Porque, por exemplo, igual aqueles outros exemplos que a gente falou que poderia atrasar um ou dois (sprints) , tipo assim, você ainda vai ter novas chances, entendeu? Tipo assim, de convergência e testar hipótese, nesse caso (você não tem) outra chance. Então o que você falou, por exemplo, é muito importante realmente, tipo assim, você tem uma data forte, você tem que terminar muito antes, ou pelo menos você tem que ter validado alguns aspectos da hipótese muito antes. Por exemplo, se é uma Black Friday, você deveria provocar alguma coisa que parece com a Black Friday antes.
Marcelo: Sim.
Vinícius: Tipo assim, você teria que, sei lá, ter o esquenta da Black Friday, você tinha que tentar, mesmo que fosse de forma meio artificial, tentar o máximo possível se aproximar de uma Black Friday, não é?
Mari: E esse ponto que você falou do progresso concreto, eu já ouvi isso muito do time mesmo, quando a gente fala que tem uma data forte, que a gente tem que entregar um determinado escopo em uma data específica, eles entendem que a gente só vai entregar lá na frente, que a gente não vai fazer essas entregas e fazer essa evolução, esse progresso concreto, ao longo do tempo, e eu acho que é muito importante a gente ter essa paranoia de ter o progresso concreto acontecendo efetivamente ali.
Marcelo: Sim.
Mari: Não só realmente simular o que a gente está falando, mas ter efetivamente as entregas sendo feitas ao longo do tempo, e não estocar tudo para entregar no final.
Marcelo: Mas sabe uma última paranoia que eu me lembro aqui, que eu teria se eu fosse cuidar de uma data forte, a paranoia (do devops) , sabe? A paranoia dos indicadores lá, sempre esqueço o nome.
Vinícius: Do Doria, não é?
Marcelo: Do Doria. Porque eu falo, assim, imagina, ok, vamos pegar um exemplo real, seis meses antes do Black Friday, eu falo: “Vou ter uma primeira versão de uma coisa, porque eu não vou perder essa oportunidade”. Como fazer isso com segurança? É tendo muito teste automatizado, é tendo o jeito de eu voltar para uma versão rápido, entende? Assim, o que eu falo, esse negócio parece que coloca no estresse toda essência mesmo, sabe? Porque, assim, nós estamos aqui falando muito de eu chegar lá (e não dar) errado, não é? Mas quando chegar lá também, se eu, por acaso der errado, além de eu ter plano B, eu posso ter que conseguir voltar para uma versão anterior, sabe? Então, assim, você tem que ter outras possibilidades também, sabe? (Você não apostar a ficha toda só em uma coisa) . Então eu só insisto nesse ponto porque eu acho que existe aquele, a gente já falou muito do podcast também, como o negócio, isso não é crítica, gente, a gente sempre fala, o negócio não é especialista em TI, a área de negócio de uma empresa, algumas empresas acabam (ficando mais tecnológicas e evolui) nesse sentido, mas a maioria não é, e aí enxerga esse desenvolvimento de um produto digital como uma caixa preta, e não consegue entender, por exemplo, a importância de investir (em devops, e às vezes o investimento em devops) é o que viabiliza, na verdade, você ter segurança de falar o seguinte, no Black Friday eu parto com uma versão, em alguns lugares, um pouquinho mais sofisticada, parto com umas mais simples aqui, a sofisticada está funcionando ali, das outras, entende? E aí eu consegui o sucesso e pude arriscar mais. Do que eu ter uma versão só no Black Friday vai funcionar no Brasil inteiro.
Vinícius: Assim, esse é um ponto. O outro ponto que eu acabei não falei àquela hora, mas eu acho que cabe aqui estar colocando mais pontos, não é? Aí eu não estou estendendo o que o Szuster está falando, não, só complementando com mais exemplos. Um outro exemplo que eu vejo até naquelas categorias que o Gustavo descreveu ali, que eu já vi várias vezes em clientes, a gente fazendo, que é bem importante, é você desdobrar um pouco os aspectos da solução que você está dando em relação a data forte. Por exemplo, o que eu quero dizer com isso? Igual ele falou lá da licença de software, um exemplar de penalização que você pode ter, muitas vezes aquela data é forte só para determinados aspectos, ou o impacto, a penalização, é muito mais forte para algumas coisas do que outras, então muitas vezes não é um evento único, assim. Na verdade, quando você vai colocar uma (lupa) , dá para desmembrar aquele evento único em vários outros eventos. Então, por exemplo, a penalização de uma licença de software pode ser muito forte para três (fitwers) e quase nada para outras, entendeu? Então você vai criando alternativas se caso você precisar de ganhar espaço em termos de tempo, em termos de opções. Outra coisa também, por exemplo, a gente já fez também em clientes nossos, às vezes a data é forte para primeiro evento que vai acontecer, mas não para outros eventos que acontece como consequência. Por exemplo, imagina a Black Friday um bom exemplo disso, é claro que você tem que ter uma gestão de risco muito boa, mas, por exemplo, eu posso vender e eu não preciso faturar imediatamente, hipoteticamente falando, eu posso faturar, sei lá, um mês depois, então pode ser que eu entregue uma solução (que tem algumas fitwers) de faturamento incompletas, entendeu? Então eu acho que isso é importante na hora que você está tentando otimizar um pouco essa gestão daquele evento em si, entendeu? , eu já vi muitas vezes, voltando ao exemplo aí do negócio da licença, o cliente está desesperado lá, e na hora que você vai ver, tipo assim, tem 80% das funcionalidades, por exemplo, que você tem que migrar, que são usadas muito, mas muito raramente, que daria para ter soluções de contingência manuais, por exemplo. Então, sabe, na verdade você tem que estar lidando com 20%, na verdade, em um problema que na hora que ele aparece (de cara, aparece 100%, entendeu) ?
Marcelo: Vinição, isso é legal, assim, sem querer ser repetitivo nesse episódio, mas isso mais uma vez provoca a essência do ágil, que é mais dado o desafio ao time, e o time, claro, tem que provar que está lidando bem com aquele desafio, sabe? E mostrar progresso. Mas é fácil, (tipo o que você falou, alguém concluir que se isso saiu de linha, então eu migro tudo) , aí vira um mega projeto ali, sendo que se você às vezes der o desafio para o time, o time faz um teste aqui, um teste ali, bola uma contingência, e simplificou tudo, não é? É a essência de simplificar, no final das contas.
Mari: E eu acho que é por isso que é importante o time entender o objetivo daquilo ali, o porquê, o que a gente quer fazer? A gente quer vender? A gente quer faturar? A gente quer entregar? Tipo, até que momento do processo a gente precisa ir, porque aí acho que eles conseguem dar soluções mais assertivas e dentro da necessidade.
Marcelo: Sim.
Gustavo: Até pegando um gancho aí no que o Szuster comentou, eu já tive até uma experiência bem bacana nesse sentido, assim, eu tive um cliente que demandou, era uma campanha de vendas, então a gente vai lançar essa campanha de vendas aqui em tal data, a gente precisa da funcionalidade para conseguir lançar essa campanha de vendas, então em um primeiro momento, assim, a gente até entenderia isso aí como uma data forte, porque fica aquele sentimento ali, a gente precisa cumprir essa data para ele não perder essa janela de vendas ali, essa janela de oportunidades, aí até fazendo justamente isso que você comentou, Szuster, tipo assim, de a gente entrar no cliente, começar entender o objetivo ali, por que foi solicitado essa demanda, aí a gente foi descobrir que era porque o cliente estava desesperado para vender, para cumprir a meta de mercado (ali do trimestre) , então já começou com essa ideia, até hoje eu me pergunto se realmente é uma data forte, porque até hoje tem essa carinha assim, de que foi uma demanda bem (pop down) , da diretoria, que eles inventaram isso da cabeça deles lá, para vender mais, para conseguir vender mais e cumprir essa meta de mercado ali do trimestre. Mas aí fizemos, entendemos a necessidade, realmente tinha essa dor lá com o cliente, então começamos a fatiar mesmo, a entender, a quebrar as demandas, ver o mínimo possível. No final das contas, assim, a gente conseguiu uma negociação lá com a parte de negócios, com o comercial a empresa, que o nosso time, especificamente, nem precisou desenvolver nada, ficou só para um time parceiro desenvolver, mas era realmente o mínimo viável mesmo, e aí o ponto que a gente refletiu bastante depois, foi justamente nessa questão de tipo assim, conseguimos lançar, cumprimos a meta, cumprimos a data forte aí do que foi solicitado pela diretoria, para não perder essa janela de vendas aí, mas alcançou o objetivo que era o que a gente precisou um pouquinho mais ali, que era cumprir essa meta de vendas ali para o trimestre? Infelizmente não cumpriu. Então, tipo assim, eu acho que faltou realmente um discovery bem feito, faltou um tempo até para a gente conseguir entender se o mercado reagiria bem a essa funcionalidade, a essa campanha aí, porque talvez se isso aí tivesse sido mais bem feito, a gente conseguiria identificar que não adiantaria nada aquela demanda ali, talvez a gente precisasse fazer uma outra demanda, de alguma outra forma tentar aumentar essas vendas aí.
Marcelo: (Isso aí é assim, até traz um tema filosófico) para mim que é assim, com uma data forte arbitrária, não digo nem arbitrária, mesmo essa data Black Friday, por mais que a gente vincule a uma necessidade, ela vai ser uma data forte de uma funcionalidade, sabe? Porque é o jeito que você tem de diminuir o grau de liberdade ali. O que eu falo é assim, você pode deixar só com uma necessidade quanto você tem vários (sprints) para ir testando aquilo. É claro que você vai deixar só com uma necessidade e vai tentar antes ir convergindo aquilo, mas supondo que só vai saber mesmo no Black Friday, no fundo você continua apostando em uma funcionalidade, entende? Porque você pode chegar no Black Friday, não que vai dar (bug) , não, mas o que você imaginava que ia acontecer não aconteceu, entendeu? Tipo assim.
Vinícius: (No fundo, é uma hipótese) .
Marcelo: É, porque você tinha uma hipótese. No mundo ideal que não tem, porque a gente insiste tanto que a data forte não pode ser arbitrária? Porque no mundo ideal é melhor você ir testando aquela hipótese aos pouquinhos para saber se está no caminho certo, mas se você fala: “Não, eu tenho essa, eu vou fazer isso para o Black Friday”, no mundo ideal ainda era bom testar esse negócio de alguma forma, não é? A ideia. Se você não consegue testar, é uma aposta naquela funcionalidade, e deve acontecer isso volta e meia, sim, não tem jeito, faz parte também do mundo, a verdade é que você acaba sendo uma data forte de funcionalidade mesmo, sabe? O que você está garantindo é que você tem aquela funcionalidade pronta antes, mas se vai dar resultado mesmo, vai ser só depois, porque é uma aposta, entendeu? Não sei se eu fui claro.
Vinícius: Sim.
Marcelo: É diferente no ágil tradicional você sempre tem jeito de ter a convergência, porque você não tinha esse dia do tudo ou nada, mas se você tem o dia do tudo ou nada, você é obrigado a apostar em uma funcionalidade mais simplificada, que você arbitrariamente aceitou que é com aquela que você vai, não é? Digamos assim. Beleza, pessoal, acho que já exploramos bastante esse tema, gostei bastante do episódio, acho que deu para dar exemplos bons, exemplos concretos, então grande abraço para todos.
Vinícius: Valeu, pessoal.
Mari: Até mais, pessoal.
Gustavo: Valeu, pessoal. Um abraço.
Marcelo: Abraço.
