Cara, eu acho isso fantástico. Eu adoro ouvir essas histórias. Por quê? Porque acontece o seguinte. Eu acho que a grande sacada disso é você conseguir lidar com esses trade-offs e esses tipos de decisão realmente... O profissional que toma esse tipo de decisão é um profissional que, de forma geral, O profissional que toma esse tipo de decisão é um profissional que, de forma geral, ele já é mais maduro pelo fato de saber que esse negócio é temporário, saber tentar evitar os níveis de acoplamento. Por exemplo, a história do BFF. Cara, sem colocar BFF numa história dessa, ia dar muito trabalho, porque você ia estar acoplado o tempo inteiro. O sistema novo não ia conseguir, mas no meio dessa história, provavelmente, você teve muita definição de contrato de API, né, você ao mesmo tempo que você estava pensando em integrar com o sistema de lá você já estava preparando a integração para o sistema daqui, né e o mais louco é, nossa, eu tenho uma API que está demorando 14 segundos, eu vou fazer isso, vai piorar esse negócio momentaneamente, mas enquanto eu pioro algo, o que eu consigo melhorar? E às vezes a gente acaba não pensando numa coisa assim que eu demorei, eu assumo que isso eu demorei para aprender na minha vida. Eu tinha a impressão que as coisas tinham que doer em mim pra elas terem valor. Então eu falava, nossa, essa funcionalidade, esse negócio do painel, que trabalho. E eu lembro até hoje, que quando eu tive uma reunião com um chefe meu, nossa, cara, eu gastei ali um mês fazendo o negócio. Eu mostrei e falei, nossa, cara, mas ficou ruim pra caramba isso. Eu gostava do jeito que estava antes, entendeu? E, cara, eu ficava bravo, daí você ficava a pé da vida, daí voltava e falou assim, cara, não tem sentido e não sei o quê. E, às vezes, o que mais deixa o cliente feliz é um bendito de um crude que você faria em cinco minutos, mas está resolvendo uma dor. Às vezes, mudar uma label no menu vai gerar uma melhora na comunicação de uma equipe de 100 pessoas que estão usando aquele sistema na equipe e todo mundo ficava perguntando. Então, provavelmente, a mudança que você fez no front-end provavelmente não era a coisa mais difícil do mundo de se fazer, mas já gerava valor para o cara meio que no dia 1 dessa transição e o cara já falava, caraca, está valendo a pena esse projeto. Porque ao mesmo tempo que você faz isso, um projeto desse custa caro, demora tempo, e o seu stakeholder não tem que saber o que é complexo e o que não tem. Ele tem que saber em relação ao ponto do tempo e o tempo de projeto. Mas no final do dia ele quer saber o que esse cara já está me entregando. E vender nisso é muito difícil. Então, não necessariamente, a funcionalidade mais difícil que tira o seu suor é a funcionalidade que mais gera valor para o cliente e às vezes a funcionalidade que gera mais valor no cliente é um campo de busca que o cara colocava ali e já parecia para ele um resultado que ele tinha que fazer toda uma história. Eu vou te dar um exemplo. Eu gosto de pegar muitos exemplos do dia a dia, porque eu acho que tecnologia, no fim do dia, a gente entrega um produto assim como um restaurante entrega. E no dia a dia eu penso em algumas coisas. Vou dar um exemplo bem besta de uma coisa que eu olho aqui. Eu peço pizza em dois lugares. Um deles sempre me mandava um panfletinho falando um monte de coisa que eu nunca li, que é panfleto. O panfleto, quando chega, você já não lê. Um panfleto com um monte de coisa falando para baixar o app deles e que tinha desconto, mas eu nunca li. E eu sempre pegava essa pizza, bem colada assim, colocava a pizza, comia e vambora. Pedia lá pelo iFood e já, vamos em frente. Tem uma outra história que eu peço, que eles tiveram a mesma ideia, só que eles colocaram um post-it escrito à mão. Oi, tem uma ótima noite, que sua pizza seja bacana, baixa nosso app e uma carinha feliz. Era um post-it pequeno, com pouca coisa escrita, baixo o app e tal, à mão. Quando você vê uma mensagem à mão, normalmente você lê, né? Porque você fala, alguém quer falar comigo. É diferente de um panfleto, que é e-mail, é como se fosse um e-mail marketing lá. Você fala, putz, é alguém querendo falar comigo. Eu bati o olho ali e ler, eu falei, o que será que eles estão falando também? Mas olha só que doideira um cara foi, gastou em gráfica, gastou um monte de coisa pra fazer a melhor imagem e tentar me impactar e teve alguém que lançou uma feature que era um post-it escrito a mão pra testar porque no fim do dia, o que ele precisa? Ele precisa saber será que alguém vai ler esse post-it e vai baixar o app ou não vai mudar nada? Às vezes a gente vai muito para o supra-sumo e esquece que, putz, enquanto você está fazendo toda essa visão, você pode brincar, testar, fazer diferente, fazer experiências mais simples e que vão gerar mais valor ou que podem não gerar valor nenhum. Quantas vezes eu tive uma sacada que eu falei, putz, isso aqui é uma baita de uma sacada, vai ajudar demais o cliente o cliente olhava e não gostava porque eu não tenho a visão de todos os clientes eu tenho a visão de um cliente que sou eu você tem que testar, senão você não vai saber quantas vezes a gente faz coisas, o jeito que você faz as coisas no dia a dia não são igual ao jeito que eu faço é totalmente diferente, a nossa cabeça é diferente a gente tem a resposta para todas as dores. A gente tem que entender e treinar para tentar chegar no melhor possível e o melhor para a maior parte dos clientes, porque você não vai conseguir atender a todos. Às vezes você vai falar, puta, 80% da galera prefere desse jeito, 20% do outro, mas 80% prefere desse. Eu vou fazer o quê? Eu estou nos 20, mas vou fazer o quê? 80% prefere do outro jeito. Então isso também é muito importante, a gente ir pensando ali no dia a dia para a gente se adaptar. Cara, olha só o que aconteceu uma vez comigo. E essa, eu acho que foi nesse dia que eu tive esse estalo e que mudou realmente a forma de como eu pensava as coisas, de como desenvolver. Eu acho que era 2006, aí você começa a mostrar a idade um pouco. desenvolver. Eu acho que era 2006, aí você começa a mostrar a idade um pouco. A gente fechou um contrato com uma grande empresa de eletrodomésticos, provavelmente todo mundo aí que está ouvindo esse vídeo agora tem alguma coisa dessa empresa aí na sua casa. E naquela época, cara, não tinha esses sistemas de BI, não tinha esses negócios aí, Data Lake, Spark, não tinha sistemas, muitos sistemas que mostrava cubo, pivô, Power BI, etc. E um dia esse cara queria chegar assim, ele falava o seguinte, olha, eu quero conseguir mudar o plano de contas da empresa pra eu fazer simulações de forma diferente e beleza eu falei, tudo bem eles deram acesso ao RP deles 1500 tabelas com nome tudo bizarro nas tabelas a gente teve que estudar a contabilidade os dados tinham que bater nos centavos e ele ia mudando o plano de contas cara, a gente sofreu muito para fazer. Foi um projeto assim eu demorei três meses só para entender o banco de dados do cara. E daí, o sistema era feito em C Sharp com .NET e coisas desse tipo e finalmente a gente fez depois de, sei lá, seis meses cinco meses, vamos lá entregamos para o cliente o sistema. O cara fazia os filtros, gerava o plano de contas, ele olhava e tudo mais. Aí, fomos lá para entregar, dá vontade de chorar, né? Chegou lá para entregar, todo feliz com o sistema, batendo tudo nos centavos. O cara falou, poxa, é legal, vamos lá. O cara selecionou, escolheu as mudanças, fez o filtro, clicou assim, daí listou todos os dados, ele falou, poxa, legal. E daqui a pouco, cara, ele começou a clicar assim na tela, nas células da tabela, assim, arrastava e falava assim, ué, mas eu não consigo editar? Eu falei, não, cara, isso aqui é um relatório. Não! Eu quero isso aqui que nem um Excel, que eu mudo e não sei o quê. Em 2006, a gente nem tinha tecnologia pra isso, né? Não sei nem se o Query existia nessa época, devia estar mais ou menos. Falei assim, como assim editar? tinha nessa época, devia estar mais ou menos. Falei assim, como assim editar? Não, eu quero, que nem um Excel. Daí ele virou assim, eu quero um Excel. Eu falei assim, como você quer um Excel, cara? E era assim, era um contrato gigante. Ele falou assim, olha, eu tô te pagando, daí ele falou assim, eu pago até mais se precisar. Eu tô te pagando tanto pra você me entregar um Excel. O cara falou isso. Eu falei assim, daí, cara, eu voltei assim, cara, eu não tô acreditando, cara. A gente gastou seis meses, sei lá de quanto tempo. Resumo da história. Três, quatro meses depois, a gente foi lá, sem brincadeira, a gente entregou um Excel pro cliente. Ele apertava uma macro, sincronizava, as planilhas do Excel saiam pulando. Era bizarro. Ele ia pulando tudo e daí ele fazia as mudanças. Ele falou assim, agora sim, foi a melhor planilha que eu já podia contratar. Então, se você perceber, o cliente, ele criou um Excel no final do dia. Era um Excel difícil? Era. Mas a gente criou sistema de autenticação, login, recuperação, relatório, combo, você selecionava, abria outro, que abria outro, o negócio tudo em Ajax, naquela época Ajax era um negócio muito difícil de fazer, dava trabalho, e no final do dia o cara queria um bendito de um Excel. Então, é complicado, né, cara? A forma de... O que está gerando valor para o cliente no dia a dia não é o que você pensa que está gerando, né? Por isso que é muito importante conseguir entender de como você gera o valor. O outro problema que a gente teve nessa abordagem é, o cliente ficou, pagou e ficou seis meses sem ter nenhuma informação. Ele não recebeu nada naquela época. E quando a gente entregou tudo, e daí ele ficou sem nada. Então, assim, o cliente ficou nove meses, pelo menos pra receber ter um retorno, as vezes se a gente tivesse entregado uma lista de categorias ali das contas dele, já estaria gerando valor, né, então é muito complicado esses tipos de coisa quem vê a gente falando agora parece que fala assim, nossa Wesley, mas cara que vacilo de você, cara Wesley, mas cara, que vacilo cara pensa isso aí cara, 20 anos atrás era assim que a gente fazia era assim que a gente fazia então é realmente puxado esses tipos de coisa mas Wesley, eu acho que assim, era assim que a gente fazia só que eu também vejo hoje tem pessoas, tem times que tem a dificuldade de voltar e pedir feedback do que tá fazendo. Até hoje a galera faz isso. A galera, a gente fala muito do projeto, então, putz, você joga lá na mão do PM pra ele fazer esse tipo de coisa e tal, mas e da sua atividade? O quanto que você tá indo lá, às vezes tá com atividade menor, o quanto que você tá indo lá e vendo se aquilo está fazendo sentido mesmo. Quando você está compartilhando com os times, pegando ideias de outros times, falando com os stakeholders que a gente fala, com a galera que está envolvida, que está interessada naquele assunto para ver se é aquilo que você tem que fazer mesmo. Isso é cultural, não é só para o cliente, é para todo mundo que você tem que conversar ali no dia a dia. Quando você está compartilhando a sua ideia e vendo, isso aqui não vai parar de pé. Se você só fechar aqui no seu dia e ficar codando o dia inteiro, você não sabe se no final do dia aquilo que você gerou vai ser realmente no caminho. Eu sou a favor de quanto mais informação, quanto mais co-criar, mais chances de dar certo. Quanto mais gente dando pitaco participando, mais chances de dar certo. Se você só se enfiar ali num buraco e sair fazendo igual a gente fazia antigamente, é muito difícil de dar certo. E outra coisa que eu queria falar é para fazer essas arquiteturas de transição eu não comentei, mas é extremamente importante você ter alguns conceitos muito bons ali no dia a dia. Primeiro, você tem que ter feature toggle. Se você não tiver feature toggle, dificilmente você vai conseguir. Trabalhar com conceito de testes mocados. Você precisa ter teste mocado, você precisa começar a virtualizar para fazer teste, não dá para você só sair fazendo marqueteira de transição e querer fazer teste normalzinho, que nem a gente faz quando a gente está na marqueteira já bem pronta. Você tem que pensar em resiliência, porque você vai ter uma peça a mais ali normalmente, você vai ter que conversar de um lugar para o outro, você vai ter um ponto de fala mais complicadinho e tem que ter, por mais que você não tenha, sendo bem honesto, pensando em observabilidade, se você não for atacar o melhor painel, o melhor alerta, você tem que ter a melhor informação para fazer troubleshooting, você tem que logar bem, se você não estiver logando bem e der algum problema no meio de uma arquitetura de transição, é muito mais difícil de você achar. Então, são três coisas que eu acho bem importantes. São três que eu falei, feature toggle... Exatamente. Explica pra galera que não sabe direito o que é feature toggle, qual que é o grande benefício e como é que essa história funciona. Cara, eu vou te falar do jeito mais simples possível. Eu vou usar o exemplo que eu estava falando. Imagina que eu tenho o meu sistema antigo que estava lá na Azure, estava rodando, não estava legal, etc. Eu vim aqui construir meu front-end aqui na AWS, São Paulo. Estou com esse cara aqui e o meu BFF que vai apontar lá para a Azure dos Estados Unidos. Cara, o primeiro momento eu tenho que conseguir fazer esse BFF apontar para a Azure dos Estados Unidos e apontar para o meu microserviço que eu construí aqui dentro da minha AWS de São Paulo. Se o meu microserviço daqui da AWS de São Paulo não estiver bacana, eu continuo apontando para a Azure dos Estados Unidos. Ou seja, tem vários jeitos que você consegue trabalhar com Tumble, mas o principal é que você consiga chavear de experiências ou de duas coisas que você construiu diferentes, duas ou mais, até tem gente que trabalha com mais. Mas se você tiver duas coisas ali pra se conversarem no dia a dia, que você consiga chavear entre elas. Você pode fazer uma abertura, também tem, você consegue fazer, por exemplo, construir uma coisa diferente, eu quero levar 5% dos meus clientes para essa experiência diferente e deixar segui-los. Você pode usar um toggle para fazer isso, para fazer um pouco mais devagar, para sentir carga, ver se não vai cair nada, etc. Você pode fazer isso, jogar 5% no balance para a sua experiência nova. Eu falo, principalmente usuários dessa categoria vão testar esse negócio e os usuários, sei lá, normais vão voltar com a versão antiga. Eu acho importante, a gente consegue entrar no detalhe do feature toggle para falar do conceito, mas o principal que eu acho é ter na sua cabeça que você consiga chavear entre experiências, tanto se uma estiver dando errado, ou até para experimentar mais uma do que outra, é ter algum jeito de ficar chaveando ali. Então, isso é muito importante quando você está fazendo uma mudança dessa magnitude, quando você está fazendo, você está indo para um sistema legado, indo para um sistema novo. Se você fizer um boom, construir o novo, joga todo mundo pra cá e eu não tenho como voltar é bom você ter acertado e acertado em primeiro a gente sabe que é difícil, né cara, é isso que é o negócio uma coisa muito importante, em todos esses, a gente fez teste de carga, a gente fez teste de estresse a gente viu quanto que o sistema aguentava mas na hora que a gente estava executando a gente usou Tangle pra ir descendo suavemente, colocando os clientes novos pra lá, porque se a gente tivesse virado tudo, cara, eu tenho quase certeza que a gente não teria atuado a aplicação do jeito certo, ia estar com coisa errada. Por mais que a gente tenha feito um bom trabalho, a gente entregou, eu lembro que pra essa de salto, a gente entregou, ela estava com na primeira entrega era 200 milissegundos aí a gente olhou e falou, puta, tem alguma coisa aqui que dá para melhorar, aí melhorou máquina, subida, etc, baixou para 80 então sempre tem um refinamentinho ali na hora que você está colocando em produção então eu acho importante você ter um Tango para fazer isso