Pessoal, sejam muito bem-vindos ao nosso encontro de hoje. Hoje eu fico mega feliz de poder trazer o Gustavo, ele vai se apresentar melhor para vocês. E é muito interessante como é que a vida acaba trazendo umas surpresas mega felizes e inusitadas. Porque um dia eu fui em um evento na área de marketing, tá? Em Phoenix, no Arizona. E daí, na hora do almoço, eu tava tipo numa cantina, num restaurante. E na hora que eu fui passar o meu cartão de crédito, na hora que eu fui passar o meu cartão, e naquela época eu usava o cartão de crédito Banco do Brasil Américas, né? E daí alguém atrás falou, nossa, esse cartão aí do Brasil, falou meio que em português. E daí foi quando eu conheci o Gustavo e o Alê, inclusive, né? O Alê tava junto lá, eu falo com ele um dia, ele me deu um tour em Brasília e tudo mais. E quando eu cheguei em casa, eu cheguei e falei assim pra minha mulher, amor, eu acho que eu conheci um dos caras mais inteligentes que eu falei na minha vida, porque esse cara, ele consegue falar absolutamente de tudo, desde uma forma técnica, de uma forma política, de uma forma com alto grau de relacionamento, de uma forma marketeada, sem marketeada, em todos os aspectos de tudo quanto é assunto. E eu fico mega feliz de poder falar com pessoas assim, porque você consegue aprender pra caramba, né? E desde lá, eu e o Gustavo, a gente, inclusive esses tempos atrás, a gente tava trocando, inclusive, algumas figurinhas, falando, inclusive, bastante coisa de IA, né? Mas, galera, eu não sei quantos diplomatas vocês já conheceram na vida de vocês, tá? Mas hoje não sei se vai ser o primeiro, se você já conhece algum, mas eu queria apresentar aqui que a gente tem um diplomata que também trabalha com computação, com IT de forma geral, né? E que vai dar um show aqui de aula pra gente, desse bate-papo, trazendo um pouco a experiência dele, e eu acredito que baseado nisso, vai dar pra gente aprender pra caramba diversas lições de como que a gente pode seguir na nossa carreira e ver como que a gente acaba, inclusive, tudo que a gente faz acaba gerando uma consequência, né, então acho que decisões muito bem pensadas em momentos críticos, elas vão fazer uma diferença muito grande aonde quer que a gente vá. Então, pessoal, né, sem mais delongas, Gustavo, apresente-se agora formalmente, tá, pra galera poder conhecer um pouquinho mais de você, da sua história, e pra bater esse papo aí com a gente. Valeu por ter vindo, viu, cara? Pô, vamos lá. Boa noite a todos. Cara, pô, Wesley, eu fico assim muito... Primeiro essa introdução aí super elogiosa, assim. Obrigado. E, pô, foi muito maneiro te conhecer também. Assim, te conhecer, já tem quantos anos isso? Já tem vários, uns 3, 4 anos, não sei. Não, cara, eu acho que faz uns quase uns 10. Foi antes da pandemia. Foi antes da pandemia. Foi antes da pandemia, é verdade. É verdade, então. E, pô, volta e meia a gente se fala, né, agora eu tenho te pedido aí umas dicas sobre IAR, que, pô, tô interessado em me atualizar também sobre isso. Então, é muito bacana. Eu gostei dessa sua introdução. Que realmente, na vida, você vai encontrando... Algumas coisas vão acontecendo e, no final, os pontos vão se conectando. E, cara, fico muito feliz de estar aqui e poder conversar com o pessoal. E, como eu te falei, eu vou fazer uma conversa bem aberta. Vou iniciando aqui. O que você achar que tem que puxar mais, que é mais no interesse do pessoal a gente vai seguindo eu comecei a minha vida na área de TI na verdade e até hoje, apesar de eu ter ido para a diplomacia, depois eu vou contar isso até hoje eu me considero a informática e a TI como minha carreira principal Se eu tivesse que definir Que uma coisa é a sua carreira Outra coisa é o job, o emprego, o trabalho Que você tem hoje Aliás De vez em quando eu vou pular uns assuntos e voltando Vamos abrir uns parênteses Abrindo umas abas do Chrome Se eu abrir aba demais e travar Você me fala Eu vou abrindo umas abas do Chrome se eu abrir aba demais e travar você me fala, mas assim, eu vou abrindo mais abas aqui e vou fechando, mas assim uma coisa que tem a ver com isso já, e era uma coisa que no meu trabalho de tech lead e de liderança eu sempre enfatizei pro pessoal é que assim, a carreira é sua, a carreira não é da empresa onde você está, quem constrói a sua carreira é sua. A carreira não é da empresa onde você está. Quem constrói a sua carreira, quem constrói a sua trajetória é você. Então, eu lembro de uma vez lidar com o funcionário insatisfeito porque a empresa não pagou um treinamento que ele queria. E eu falei, pô, não, tudo bem. Você queria esse treinamento, até acho que é importante, mas é importante para você? É importante para a sua carreira? Então assim, você tem que avaliar isso também. A carreira é sua. A carreira não é da sua empresa. Você vai sobreviver. A sua carreira vai sobreviver quando você sair dessa empresa também. Então assim, eu sempre pensei assim. E eu comecei a minha vida na TI. Curiosamente, eu comecei a aprender a programar muito cedo, porque na minha escola tinha um curso de logo. muito cedo, porque na minha escola tinha um curso de logo. Não sei quem lembra aquele jogo da tartaruguinha, que era um jogo que basicamente você controlava uma tartaruga para desenhar umas coisas. É muito parecido com o que existe hoje, que é o chamado Coding Hobby. Quem não conhece, quem tem filho, eu tenho aqui em casa para as minhas filhas. Esse Coding Hobby é uma ferramenta incrível para a criança começar a entender o, vamos dizer, o pensamento algorítmico. Então, essa coisa de você começar a pegar um problema e quebrar ele em passos a serem realizados é uma coisa que a gente faz na programação, é uma coisa que isso começa a ensinar para a criança. E aí, quando eu fui fazer um segundo grau técnico, eu fui fazer um segundo grau técnico em eletrônica. Nesse segundo grau técnico em eletrônica, foi que eu peguei a base da programação, porque uma das principais matérias que a gente tinha era assemble para 8086. Ou seja, todos os algoritmos básicos de árvore, de busca, de... Nem lembro os nomes todos, mas todos esses algoritmos básicos de programação, você tinha que fazer em assembly para 8086 e controlando a pilha, controlando tudo, porque você tinha que controlar o overflow, tudo isso, na mão. A coisa hoje é um pouquinho mais fácil, né mão. Coisa hoje é um pouquinho mais fácil não é? Não, é um pouquinho mais fácil e aí a partir disso a partir disso isso me deu, aí claro na minha escola tinha outras aulas, tinha aula de robótica era muito Pascal, mas aí você você tendo um fundamento bom nesses algoritmos básicos depois você vai pegar a manha da arquitetura de cada coisa. Você vai pegar desenvolvimento web. Desenvolvimento web é outra coisa. Tem uma arquitetura que é cliente e servidor. Tem a parte de alguma coisa de protocolo e tal. Depois você vai pegando isso. Eu comecei a programar, mesmo de verdade, foi aí no segundo grau. Isso eu estou falando de 1995, 96. O meu primeiro emprego foi antes da internet no Brasil. Meu primeiro emprego foi numa BBS. Não sei nem se o pessoal lembra o que é BBS. Eu usava, cara. Você usava? Eu usava. Chamava Solve BBS. Eu não lembro nem como, mas eu lembro que eu usava. Não sei se alguém da galera aí que tá na aula já chegou a usar naquelas épocas. Esse povo muito jovem é fogo. É foda. E aí, a BBS, as primeiras BBSs, nas BBSs daquela época, muitas delas viraram provedor de internet de escada. Então, eu trabalhei nos primeiros provedores no Rio de Janeiro. Os primeiros provedores de internet eu trabalhava lá. E, porra, eu lembro quando o meu provedor lá, a Ponto Conde, eu trabalhei, a gente contratou um link de 2 mega. O link do provedor inteiro de 2 mega era uma sensação. Era um dos maiores links do Brasil. Então, assim, e aí eu comecei a trabalhar nos provedores e aí claro, começou a parte de internet hospedagem, hosting de site aí começou a internet mesmo muito parecido com o que a gente conhece hoje com toda a diferença tecnológica mas assim a gente tinha muita coisa em Unix, em DSD, em Solaris algumas máquinas da Sun tinha muita coisa em Unix, em BSD, em Solaris, algumas máquinas da Sun. Você tinha muita coisa, acho que em FreeBSD. Na época, a distribuição mais conhecida do Linux era Slack, era a mais conhecida. Então, assim, e aí, muito do que a gente fazia naquela época era programação para automatizar tarefas de administração e aí foi quando eu comecei a programar Perl no Brasil a gente chamava de PEL mas é Perl e é muito interessante pessoal porque assim, o que se fala hoje de infraestrutura como código, de automação de infra isso era o que a gente fazia na época claro que sem as ferramentas fala hoje de infraestrutura como código, de automação, de infra, isso era o que a gente fazia na época. Claro que sem as ferramentas que havia, sem as ferramentas que existem hoje, mas era o que a gente fazia na época. Então, assim, olha, a gente precisa automatizar uma criação de um site básico, uma espécie de scaffolding aqui. A gente tem que automatizar uma criação de usuário. Então, tudo isso que a gente fazia, na verdade, era muita coisa que tem a ver com os princípios que a gente tem hoje. E tem muita coisa que vai voltando. Então, por exemplo, outro dia eu estava vendo sobre uns frameworks que você publica um conteúdo, por exemplo, vamos supor, você tem um CMS e você quer publicar ele estático para você ter uma alta performance. Então, você como se fosse pré-compila o que o banco geraria, só que você publica ele estático. Isso a gente fazia na época também. Tem muita coisa de ondas que vão e voltam. E uma coisa interessante que eu estava comentando com o Wesley é é que assim, você, era muito difícil você começar a programar sem aparecer alguma coisa do Zoom. Mas acho que é a tela de alguém, né? Alguém compartilha a tela aí. Algum Fabrício aí, por favor, não compartilha a tela, Leandro, bloqueia a galera pra não, às vezes compartilha sem querer e acaba aparecendo aí. Tá, não, tranquilo. E aí, assim, o que é muito interessante é que, assim, estava comentando isso com o Wesley, que era muito difícil você começar a programar, a desenvolver, sem ter esses fundamentos. Assim, a primeira coisa que você chegava é o seguinte, cara, você sabe instalar uma... Na verdade, era até antes. Você sabe montar um micro? Você sabe montar um computador? Esse era o básico do básico. Agora que você sabe montar, você sabe instalar um sistema operacional? Você sabe controlar o permissionamento? Você sabe, a partir do momento que você instalou o Linux, você sabe agora tornar ele seguro, fechar as portas, configurar os hosts, não sei o quê. Então, assim, você tinha todo um processo até você chegar e falar, tá, agora eu vou começar a programar. Isso era uma coisa que eu tentei explicar também para o pessoal desenvolvedor mais novo, que eu fui conhecendo ao longo da minha carreira, que eu já vou contar mais. Eu não vou contar todos os anos não, tá pessoal? Vou pular uma coisa, mas só pra vocês entenderem onde eu quero chegar por exemplo, uma das conversas que eu tive uma vez, já no ministério, né, onde eu tô hoje, uma das conversas que eu tive uma vez com um desenvolvedor, foi que ele tava tendo um problema na máquina dele e ele chamou o suporte e eu tive que conversar com ele, dar um coaching. Ele falou assim, cara, você é o seu suporte. Você é um desenvolvedor. O controle da sua ferramenta, afiar a sua faca, é parte do seu trabalho. Um cozinheiro, ele aprende a afiar a faca para poder cozinhar, isso é parte do treinamento dele, manter a faca afiada é parte do treinamento dele tudo bem, de vez em quando, de repente uma vez por ano ele pode ir em um afiador especial, mas manter as ferramentas de trabalho conhecer as ferramentas de trabalho, manter isso atualizado e manter isso funcionando é parte de qualquer craft esse é um dos princípios do software craftsmanship, desse movimento de artesania de software. Você entender... Ah, tem alguém falando aí que é tudo bloqueado. É, mas lá a gente liberava para os desenvolvedores. É verdade. Tem isso também, mas lá não era. Porque os próprios desenvolvedores pediram e a gente falou, não, beleza. Não pode ser mesmo. Você tem que ter liberdade para instalar, gente falou, não, beleza. Não pode ser mesmo, você tem que ter liberdade pra instalar, vai instalar algo. Se não, realmente, aí tem um problema, você vai instalar uma biblioteca, aí você tem que pedir autorização pro cara da infra. Isso aí, cara, olha, esse... Essa história de relacionamento de infra com desenho, com desenvolvimento, isso aí, cara, tem muita história pra falar, eu vou chegar nisso. Então, assim, daí pessoal, eu fui avançando na área de TI, aí obviamente eu estava programando muito em PEL, aí logo me chamaram para desenvolver aplicação web e tal, comecei a desenvolver aplicação web, montei uma startup com um amigo meu, a gente fez uma startup de educação, e a gente fez até uma coisa legal na época. Isso deve ter sido em 98, 99. A gente fez um simulado, era uma startup de educação, né? Então, a gente fez um simulado online. Olha isso, todo mundo tinha que conectar ao mesmo tempo, fazer a prova online e terminar naquele prazo de tempo, né? E os cinco primeiros ganhavam um prêmio. A gente teve patrocínio da América Online na época. Aol.com, né? Aol, exatamente. Recebi o CD verdinho em casa, né? Recebi um CD verdinho em casa. Um CD que foi... Navegador. Que foi um fracasso. Na verdade, a entrada da América Online no Brasil foi um fracasso. Na verdade, a entrada da América Online no Brasil foi um fracasso, foi um case do que fazer de errado. Deu muito errado o marketing deles, eles não conseguiram emplacar no Brasil. Nem sei como é que está, se ainda existe essa empresa hoje. Mas na época, então, e aí, cara, foi um... Deu um problema, porque veio bastante gente fazer o simulado online. Obviamente que o nosso servidor crashou totalmente. Então, assim, a gente teve que atualizar a coisa ao vivo ali, avisar o pessoal, conseguir publicar um aviso na página. Tenta de novo, se não conseguir e tal. Mas olha, só para vocês verem, esse servidor onde rodava essa aplicação foi um PC que a gente montou, que a gente instalou, que a gente configurou inteiro. A gente levou o PC de baixo do braço e botou num provedor em co-location. Isso era a nuvem da época. Você tinha que montar o seu PC e levar. E isso de você ter um co-location já era uma modernidade. Já era uma coisa super moderna. Você conseguir botar um PC dentro de um provedor e acessar remoto. Já era, né? Enfim, mas aí eu continuei trabalhando no mercado, trabalhei em uma outra startup, trabalhei em outras empresas. E aí chegou uma hora que é o seguinte. Naquela época, principalmente do início da internet no Brasil, e no mundo também, havia uma discussão muito grande do impacto da tecnologia nas outras áreas. Que nem hoje tem, o que a IA vai fazer? Como é que a IA vai mudar o mundo e tal? E na época era a mesma coisa, só que a internet era uma coisa assim, acho que até mais revolucionária, talvez igual, porque a IA hoje também é uma coisa bem surpreendente, mas enfim, estava todo mundo falando muito, qual é o impacto da internet na política, não sei o que, eu comecei a ler isso e comecei a me interessar um pouco mais sobre isso, mais sobre essa parte de política e tal, não sei o que. E aí, resumindo a história, eu acabei trocando de faculdade, eu estava na engenharia na época, larguei a engenharia fui fazer direito fui fazer um intercâmbio no Japão, que eu já gostava de línguas, eu já estudava japonês eu acho que linguagem, programação e língua essa questão da sintaxe, da gramática da abstração, são duas coisas muito parecidas na verdade a diferença é que o idioma falado ele é vamos dizer, não verdade? A diferença é que o idioma falado, ele é, vamos dizer, não é strongly typed, não é, como é que você fala? Não é estrito. É uma coisa muito mais solta. Mas se você pensar bem, o PHP e o PEL, como você fazia antigamente, era super solto também. Era uma bagunça. Mas todos têm ponto e vírgula no final. Esse que é o negócio. Esse que é o grande ponto não sei se ainda se chama assim, mas antigamente se chamava código macarrão que era aquele tudo misturado como é que é? espaguete que era aquele HTML misturado com mas na verdade era só, olha que interessante os primeiros projetos que a gente fez que a gente percebeu, naquela época, isso em 98, sei lá, 99, a gente percebeu, caraca, peraí, esse negócio de misturar código com HTML, isso aqui vai dar totalmente errado. E tipo assim, sem ler em lugar nenhum, a gente já começou a separar, não, peraí, eu tenho que ter um template, e aí a gente mesmo escreveu uma engine do template que parciava o texto todo com regular expression e depois substituía ali os marcadores por um negócio assim. O MVC não se chamava MVC, não tinha esse nome, mas a gente já fazia na época, entendeu? Já tinha um protótipo, porque é óbvio, os primeiros projetos você começa a ver, você fala, cara, isso aqui está uma zona, eu preciso organizar isso aqui, deixa eu separar a visualização do meu modelo então assim, muita coisa de conceito você tinha que criar por si próprio, vamos lembrar pessoal isso é antes do Google isso é antes do Stack Overflow se eu tinha uma dúvida de programação, não tinha onde procurar, você tinha que abrir um livro a gente tinha aquelas coleções lá da O'Reilly, o livro do Camille. Não sei o que, em 21 dias, né? Não sei o que, em 21 dias. É, ou aqueles livros Programming, Programming não sei o que, época do Netscape, isso mesmo. Entendeu? Então assim, você tinha que meio que desenrolar tudo isso. Mas aí, enfim, continuando a história. Eu acabei indo fazer esse intercâmbio no Japão e aí eu comecei a gostar também dessa área de... Morei um ano no Japão, comecei a gostar dessa área de relações internacionais. E quando eu voltei, eu decidi que eu ia fazer mesmo o concurso do Itamaraty para a diplomacia. E aí, beleza. Aí isso foi já em 2008. Eu entrei para o Itamaraty. Quando eu entrei para o Itamaraty, eu falei, cara, não quero mais trabalhar com informática, isso aí já passou, agora eu estou em outra... Só que aí eu sempre brinco, cara, informática é uma maldição. Se você um dia trabalhou com informática, você sempre será o cara da informática, o cara da TI. E aí, cara, só que é bom também isso. Eu falo isso brincando, obviamente, eu gosto. E aí, assim que eu entrei no Itamaraty, cara, alguém deve ter visto o meu currículo lá, sei lá. Cara, sem brincadeira, dois meses depois, o chefe lá da TI veio falar comigo, que é tipo o CIO, né? Meu, cara, você não quer trabalhar comigo? Você tem você tem, pô, quase ninguém aqui tem background em TI, você tem, vem trabalhar comigo. Eu falei, cara, não vou. Porra, eu fiz esse concurso aqui para sair da TI, eu não quero mais TI. E aí, cara, depois eu comecei a ver o seguinte, aí passaram uns meses, eu comecei a ver o seguinte, que, pô, uma das coisas que mais me frustrava na informática, eu gostava bastante, mas uma das coisas que me frustravam, era que muitas vezes, principalmente nas organizações grandes, em startup é diferente, mas nas organizações grandes, os caras que tinham cargo alto, que eram liderança, que eram gerentes, que eram CIO, que eram CTO, o que seja, geralmente eram os engravatados que não entendiam nada da parte técnica. Era um pessoal que entendia talvez mais do networking e da parte de se vender do que necessariamente de tocar a parte técnica. E aí eu falei, cara, esses são caras que nunca programaram nada. Então o cara vinha lá com uma ideia estapafúrdia e botava. Tem gente falando aí, até hoje é assim. Até hoje é assim. Nada mudou, né? Mas olha só, aí o cara vinha botando o prazo, empurrando o prazo pra equipe E você olhava assim, meu irmão, você tá totalmente fora da realidade Não é assim que a coisa funciona E não é você Que vai programar Pra impor prazo pros outros E vinha com Aliás, tinha até uma brincadeira disso de antigamente Que se chamava isso de Tem essas coisas de metodologia Rupi, waterfall ágil, kamban. Aí o pessoal uma vez fez uma brincadeira. Eles tinham até botado online isso, não sei se ainda está. Go horse. Extreme go horse, exatamente. O pessoal mais novo conhece isso ainda, Wesley? Do extreme go horse? O go horse é... XGH. Acontece até ainda, Wesley, do Extreme Go Horse? O Go Horse é... XGH. Acontece até hoje, meu amigo. Essa metodologia ficou mais que... mais forte ainda depois que nasceu as metodologias ágeis. É que às vezes eu não sei o que da minha época ainda é conhecido, o que não é, mas isso já é antigo, pessoal. Esse XGH aí já é a metodologia mais usada no mundo e o Brasil é um dos líderes nessa adoção. A gente está ouvindo um cara de relações internacionais, pessoal. Enfim. E aí, cara, eu penso o seguinte. Peraí, eu vou lá para a TI? Como eu passei de um concurso e estou em um cargo alto, eu vou entrar para a TI pra chefiar a TI. Né? Eu comecei como subchefe e depois virei chefe. Então eu falei, cara, pô, eu vou poder fazer na informática a transformação que eu nunca tive autoridade pra fazer, nunca tive moral pra fazer nos outros lugares, entendeu? Eu vou poder cara, fazer o negócio do jeito que eu acho que tem que ser feito, entendeu? Do jeito que desenvolvimento de software tem que ser. E aí, cara, eu entrei, eu resolvi aceitar o desafio e aí vou contar só rapidamente como é que é e aí a gente vai puxando os ganchos, que é o seguinte. Cara, o Itamaraty é uma organização muito grande, são pelo menos 5 mil pessoas, em 215, mais ou menos 220 localizações no mundo inteiro, em 150 países diferentes. E a TI é uma TI razoavelmente grande, acho que até menor do que deveria ser, mas são mais de 100 pessoas. Coloca aí, sei lá, uns 30 de desenvolvimento, mais uns 20 ou 30 de infra mais um pessoal de gestão de gerente de projeto, de produto, mais uns 15 mais um pessoal de suporte, de vários níveis mais pessoal de NOC, mais pessoal de segurança você coloca todo mundo, isso aí dá mais de 100 pessoas. E, cara, vocês acham que organizações grandes já têm um problema de serem muito amarradas em metodologia e tal? O governo, muitas vezes, é ainda pior. Porque você tem toda a parte de regulamentação de TCU, de compra pública, de concorrência. Você não pode contratar quem você quiser, você tem que contratar o mais barato. Então, assim, a chance de dar problema é muito maior, né? Os riscos são muito maiores. E aí, o que a gente viu quando eu cheguei lá, é que, cara, da infra, do metal, até a camada mais alta de abstração, estava tudo caindo aos pedaços. Para vocês terem uma ideia, tinha uma goteira no data center. O pessoal uma vez teve que mover o rack para não molhar. Isso é outra coisa que estava conversando com o Wesley, essa questão da nuvem, por exemplo. Isso facilitou muito. AWS e exemplo, isso facilitou muito, a AWS e tal, isso facilitou muito. Na nossa época não tinha isso e recentemente no Ministério já tinha, mas aí por uma questão de regulação e de material sigiloso, a gente tem que tocar a própria infra. Então, você tem que ter a sala-cofre, você tem que controlar a parte civil pô, civil, a parte elétrica, a parte de ar-condicionado e tal. Isso eu acho que é... Eu sei que é muito... Claro, pô, cara, você está preocupado em adicionar valor, então, assim, você tem que produzir aquilo que for mais fácil, obviamente. Aquilo que for mais rápido, melhor custo-benefício, melhor risco, benefício, essas coisas todas. Mas você ter que tocar a própria infra também é uma habilidade legal. Você conseguir tocar a própria... Porque hoje praticamente, eu imagino que na maior parte dos lugares, só quem saiba tocar a infra é quem trabalha em cloud. É quem trabalha do lado de lá. Porque, às vezes, quem trabalha do lado de cá é tudo uma operação digital de subir instância, baixar instância e configurar tudo lá, vamos dizer, numa camada de abstração mais alta e não no hardware diretamente. Então, você operar o hardware, por exemplo, você vai fazer uma operação de, sei lá, acabou a vida útil do seu storage. Agora você tem que trocar o seu storage, agora você tem que trocar o seu storage inteiro. Como é que você faz isso garantindo, pô, sem perda de dado, garantindo a confiabilidade e tal? Então, esse tipo de tocar a infra é uma coisa que é parte da Tegui também, né? E é uma parte do nosso trabalho lá. Então, assim, uma das primeiras coisas que a gente teve que fazer foi isso, foi um projeto de um, dois anos só para poder resolver goteira, história de novo ar-condicionado resolver a parte de infra mesmo e aí a parte que talvez seja mais interessante é o seguinte a parte de desenvolvimento é que eu acho que era e aí eu não sei, de repente o Wesley pode comentar também, vocês podem comentar a parte de desenvolvimento é que era um negócio assim, cara, que era uma mistura de Go Horse com pô, nem sei, cara uma mistura de Go Horse com com Visão do Inferno com assim, sabe, imagina você ter uma equipe grande com pastelaria na verdade, pastelaria é um bom exemplo, a gente até brincava lá de pizzaria porque basicamente era a TI como tirador de pedido você fala assim, o que você quer? eu quero um sistema sabe aquela coisa? qual sistema você quer? eu quero um sistema que faça isso isso, isso, isso e aí a TI sem crítica nenhuma passava isso para os desenvolvedores e aí era um Deus nos acuda obviamente todos os projetos estavam atrasados. Obviamente, não havia controle nenhum. Obviamente, todas as entregas eram péssimas. E aí isso começa a gerar também um problema de cultura, porque aí, pô, se as entregas são ruins, mas também o relacionamento com as áreas de negócio e com a TI é ruim. Se eu começo a ter uma cultura de também, cara, vou entregar o mínimo vou entregar o mínimo possível, dane-se. Ou se está atrasado o que o pessoal fazia? Passava para o tester. Não, manda para o tester. Aí se estava atrasado o tester mandava para homologação. Aí, quer dizer, aí o cara o cara que era o owner é que virava o tester. Só que aí o owner também já estava de saco cheio e mandava para o negócio. Aí vinha o reporte do negócio com 40 bugs. E eu não estou zoando, não. 40 bugs é um número normal da entrega da época. Entendeu? Quem testa é o cliente. Era isso mesmo. Era isso mesmo. Era assim, desespero total. E eu vi aquilo e falei, cara, está tudo errado aqui. Está errada a cultura. Primeira coisa que está errada. Está errada a cultura, o approach de desenvolvimento. Obviamente, era muito baseado na engenharia de software de waterfall de cascata muito baseado em metodologia muito controlada que eu acho que cara, eu até acho que toda metodologia tem o seu valor, mas se você não está fazendo coisa embarcada eu tive uma base de eletrônica. Se você está fazendo software embarcado, tipo assim, você vai programar o software que vai rodar dentro do marca-passo. Irmão, eu vou pegar o teu software e vou botar dentro do peito de um cara. Eu vou abrir o peito do cara e vou botar ele lá dentro. Pô, isso aí não dá pra você fazer um... É totalmente ágil ágil vou botar para dizer que eu sou ágil não dá, não dá para você fazer um continuous improvement, olha vem aqui que eu preciso atualizar o firmware do seu do seu marca passo, não dá para não dá para fazer isso, você vai ter que fazer realmente uma metodologia mais formal controlada, você vai escrever para cacete, é outra abordagem vai testar de um jeito absurdo de um outro nível de complexidade, de teste, de formalização vai passar por várias camadas provavelmente você vai ter duas equipes escrevendo a mesma coisa porque vamos lembrar que em toda prática humana sujeita a riscos, idealmente você quer fazer ela duas vezes, só que escrita de forma diferente. Então, por exemplo, se é a mesma coisa que aquele double entry accounting, quer dizer, o princípio da contabilidade de você escrever em duas carteiras, uma de entrada e outra de saída. Então você está escrevendo a mesma informação duas vezes. Esse conceito é do é, cara, do século, sei lá, 15 ou 16. E os caras já tinham sacado. Não, espera aí, cara. Se a gente deixar um cara só escrevendo os números e ele errar, vai dar problema. Então, espera aí. Você escreve saída de um lado, você escreve entrada do outro e no final tem que conciliar isso aqui, senão a gente sabe que deu um problema. A ideia de um teste automatizado, a ideia de um TDD é um pouco isso também, você está escrevendo a mesma coisa duas vezes, só que obviamente, de jeito diferente mas a ideia é isso, é você repetir a mesma coisa para você garantir, então provavelmente se você fosse fazer um software embarcado, seria isso mil vezes mais mas não é o caso, a aplicação corporativa geralmente não é esse o caso você pode fazer uma coisa mais ágil e tal. Então, cara, assim, estava tudo completamente, assim, atraso, basicamente, cara, se eu te falar que entregou 5% do que deveria, é muito, entendeu? Eu estou estimando para cima. E aí, cara, a gente chegou à conclusão que havia alguns problemas principais no modelo. O primeiro problema era a questão realmente da metodologia waterfall, cascata, com muita documentação, muito paralisada, muito formalizada, como eu comentei. E é interessantíssimo porque isso tem uma razão, às vezes, financeira para isso também. Então, olha só o que acontece Muitas dessas empresas Faziam contratos assim Você entregava, por exemplo Você abre um projeto desse Cascata com sei lá, um documento de visão Do projeto, né Aí você fala assim, não, mas você entrega um documento de visão Que é só assim delineando e ele ia gerar o que é o projeto Aí o cara te paga 10% do valor estimado do projeto. Então, se você tem um projeto estimado em um bilhão de reais, você escreve um documento de algumas páginas e você já ganhou 100 mil. Tá? Aí, daqui a pouco, você escreve... Isso eu não estou exagerando não, tá, pessoal. Isso é o jeito que é mesmo. Você escreve casos de uso ou escreve a análise? Você não programou nada ainda, mas você está entregando a análise com os casos de uso e tal, não sei o quê? Tinha que fazer ponto de função. Nossa, cara. Ponto de função. Exatamente. Com essas métricas de ponto de função e tal, você já ganha mais uns 20% ou 30%. Então, quando chega na hora de programar, já não vale mais nem a pena. Pô, já ganhei 50% do projeto sem fazer nada. Entrega qualquer coisa, deixa atrasar. E aí tem um outro fator, que é o seguinte. Como o negócio muda tão rápido também, se o projeto atrasa um, dois, três anos, a própria necessidade dele já caducou. Então, assim, era um fracasso total a metodologia. Esse é o primeiro ponto. O segundo fracasso foi o que o Ed comentou agora, da métrica. Da métrica de ponto de função. Que é uma métrica que não te permite entender o esforço da sua equipe então se ela não te permite entender o esforço da sua equipe ela não te permite alocar e controlar sua capacidade foi um dos princípios fundamentais do camban é visibilidade do trabalho tem que saber em que cada um tá trabalhando e qual o esforço que cada um está tendo. Isso é um princípio básico. Se vocês, eu vi que o pessoal aí falando que quer ser líder, tech lead, gerente e tal. Cara, uma das primeiras coisas, a primeira coisa que você tem que ter da sua equipe, visibilidade do trabalho. O quanto, em que e o quanto cada um está trabalhando. o que e o quanto cada um está trabalhando. Isso é a primeira coisa. E aí vamos lembrar que quando você anda, por exemplo, quando você anda numa fábrica, por exemplo, você vai dar uma volta numa fábrica, você tem mais ou menos uma noção do que está acontecendo. Ah, eu vou dar uma volta numa fábrica aqui de chocolate, de bombom. Pô, estou vendo, olha só, aquele cara ali faz a caixa, aquele cara ali faz o chocolate, aquele cara ali faz a caixa, aquele cara ali faz o chocolate, aquele cara ali embrulha o chocolate. E tem um monte de bombom parado aqui. Eu pergunto para o cara, vem cá, por que esse bombom está parado aqui? Ah, porque eu não recebi a embalagem. Opa, já identifiquei um gargalo. Você vê que só andando na fábrica, você consegue identificar alguns problemas no seu flow, no seu pipeline. Em produção de coisas abstratas ou digitais, como é o software, você vai dar uma volta e você não vai ver nada. Você precisa de ferramental, você precisa ativamente buscar essa visibilidade. E para isso... Gustavo, deixa eu te cortar num ponto. Galera, todo mundo aí, nota mental pra todo mundo nesse momento, tá? Independente se hoje você trabalha em qualquer parte de liderança ou não, né? Toda vez que você quer saber como o software que você tá desenvolvendo, o produto que você tá desenvolvendo, ou como as coisas estão, lembre-se sempre, se você estiver numa fábrica de chocolate andando, tem bombom parado, você sabe onde está o gargalo e a questão que eu quero que todo mundo pense agora é de cara, vocês conseguem imaginar alguns bombom parados no projeto que você está fazendo, né? Ou o quão intencionalmente que a gente acaba fazendo isso, né? Ou o quão intencionalmente que a gente acaba fazendo isso, né? Porque o grande problema, Gustavo, inclusive, que a gente passa no dia a dia em... Principalmente quem eu acho que tá muito em cargo de liderança é você fica tocando o bumbo todo dia pra fazer com que as coisas estejam andando, mas você acaba parando, às vezes, pra olhar, poxa, tem uns gargalos, umas coisas tão básicas aqui que não estão funcionando, e que aquele bendito elefante na sala que tá ali, todo mundo finge que não tá vendo, mas, no final das contas, ele tá acontecendo. E eu acho que não ter intencionalidade pra resolver esses problemas é o que vai fazendo com que o software ou qualquer tipo de projeto não é nem que vá atrasando, ele vai chegando muito nesse ponto que você falou, vai afetando principalmente a cultura da empresa, né? E qualquer pessoa que é líder em qualquer coisa, se você não tem aquela cultura de que as pessoas confiem que aquilo que você está fazendo tem que sair com uma determinada qualidade, que tem que sair no prazo, simplesmente as coisas vão sair de qualquer jeito. Eu tenho um caso, cara, que é engraçado. Engraçado. Pelo menos para mim, na época, foi. Os caras dividiam duas equipes na área de desenvolvimento. Era uma equipe que só construía nova feature e uma equipe que só dava manutenção do software. Adivinha o que acontecia? Um cara que desenvolvia software, o cara falou assim pra mim, meu amigo, hoje eu fiz um commit que eu tenho até dó daquele que vai dar manutenção. Porque a métrica dele era entregar a feature. Entendeu? E a métrica dos caras é manter o software funcionando mas a empresa entre aço valorizava mais quem? O cara que mais entregava, então o cara já entregava e falava, já tô com dó daquela pessoa que vai pegar porque uma vez que eu entreguei essa feature eu nunca mais vou relar nela acabou a tarefa eu já vou pra outra feature. E daí aquela história, né? Dança quem vai ter que dar manutenção. Isso aí, de uma forma geral, é cultural. O cara fala, eu tô recebendo mais pra criar feature. Dane-se como é que eu vou entregar, porque não sou eu que vou lidar com esse legado aqui que vai girar, né? Então, é cultural, cara. Então, então qualquer coisa que está acontecendo na sua equipe hoje ela reflete exatamente a cultura que o líder está trabalhando ali provavelmente o Gustavo deve ter tido um trabalhinho aí cultural para fazer com que as pessoas voltassem para uma realidade diferente exatamente e foi ótimo você falar isso porque isso já introduz o terceiro ponto, quer dizer, o primeiro ponto então é a questão da metodologia, que eu falei que era um problema. O segundo ponto é a questão da métrica. E o terceiro ponto é a filosofia de desenvolvimento de software. Então, qual é a filosofia que a gente tem a respeito do desenvolvimento de software e qual é a cultura que a gente quer estabelecer. E a filosofia que muita gente tinha, eu acho que hoje com o movimento ágil, eu sei que tem muita discussão dentro do movimento ágil também, mas eu acho que até melhorou um pouco, porque na nossa época ainda tinha muito uma discussão de que o software era como se fosse um produto fabril, como se fosse uma fábrica. Tudo que a pessoa fala, fábrica de software. E, cara, a questão é que é muito interessante isso, porque o próprio conceito de fábrica, então as pessoas dizem assim, então o que é uma fábrica? Eu vou dividir as pessoas emem assim, não, então o que é uma fábrica? eu vou ter eu vou dividir as pessoas em tarefas bem definidas, não é isso? você é analista você é programador eu não sei como é que um cara pode ser geralmente o cara que era só analista não era programador, às vezes era um cara que nunca programou como é que um cara que nunca programou vai fazer uma análise para um programador programar? Isso é muito difícil. Isso é muito difícil. Mas tudo bem. Ou então um arquiteto. O cara tem que passar por aquilo, mas tudo bem. Mas enfim, então você tinha essa separação muito grande entre todas as atividades. Ah, você vai fazer análise, você vai fazer programação, você é um tester, você vai fazer programação você é um teste você quer e você não sai da sua função então se eu peguei coisa peguei coisas absurdas que por exemplo um analista escrever um caso de uso aí sei lá o cara coloca láador vai lá e implementa e implementa com 10 porque estava no caso de uso o cara vê uma coisa que é claramente errada mas é o conceito de fábrica você faz aquilo que te mandaram segundo a linha de produção o problema pessoal é que esse conceito de fábrica ele nem é o conceito de fábrica moderna nem é um conceito de fábrica moderna. Ele é um conceito de fábrica fordista de mais de 100 anos atrás. Porque é o seguinte, o Ford, quando ele criou, quando ele pegou as ideias da administração científica, do Taylor, de dividir a produção em pacotes pequenos, porque a ideia de você dividir uma tarefa em pedaços pequenos é que, em teoria, qualquer leigo pode executar. Então, assim, eu não sei construir um carro inteiro, mas apertar um parafuso eu sei. Então, se me dá um parafuso para apertar, você dá outro para outro cara. Então, se cada um decorar um parafuso, a gente consegue. Decorar todos os parafusos eu não vou conseguir então a ideia era você baratear e simplificar a produção a partir desse que se chamou de estudos de tempos e movimentos você pegava cada tarefa dessa desenvolver uma ferramenta um novo método para fazê-la mais rápido se não você conseguir produzir um carro muito mais muito mais rápido nem muito menos tempo então essa é era a ideia do Ford. Ele pegou as ideias do Taylor e a única coisa que ele botou era uma linha de produção, uma linha móvel que o carro ia passando e cada um ia fazendo a sua parte. Ótimo. A questão é que o problema que o Ford queria resolver era um outro problema. O problema que ele queria resolver era como construir o mesmo carro em massa. Então ele fazia a mesma coisa todo dia. O desenvolvimento de software não é a mesma coisa todo dia. É o contrário. O desenvolvimento de software, ele não é a fábrica, ele é a criação do produto. É o que vem antes da fábrica. Isso é o desenvolvimento de software. A gente está desenvolvendo uma coisa que ninguém nunca fez antes né então como a gente, então na verdade se você quiser fazer uma analogia com a fábrica quem é a fábrica na verdade é o compilador, o compilador sim está só compilando, ele é a fábrica ele é a parte fordista mas o desenvolvedor de software não é o Fordismo o desenvolvedor de software é a parte anterior e na verdade eu falei que isso ainda é um conceito antigo, é uma analogia com um conceito antigo de fábrica porque se você olhar para uma fábrica moderna como o da Toyota onde se criou o conceito de Kanban ela não trabalha assim porque o problema da Toyota era diferente o Tahiti Ono, que era o cara que trabalhava na Toyota, que desenvolveu o conceito de Kanban ele falava, cara, a Toyota não quer produzir o mesmo carro sempre, eu quero ter uma linha de produção que é o seguinte, olha, agora vem um Corolla azul, o próximo vai ser um, sei lá, um outro não sei o que, o próximo, cada hora é um carro diferente então é sei lá, um outro não sei o quê, o próximo... Cada hora é um carro diferente. Então é o seguinte, como é que eu construo uma fábrica para desenvolver carros diferentes? Aí ele fala, pô, primeira coisa é o seguinte, não dá para achar que você vai fazer isso com gente pouco qualificada. Você precisa aumentar a qualificação do pessoal. Segunda coisa, não dá para achar que eu não vou ter problema. Então, eu preciso estabelecer métodos para controlar problemas. Então, ele criou aquela ideia do stop the line, que isso existe em TI também. O stop the line, está com algum problema no pipeline, vamos parar, não sei o quê, vamos consertar. Quer dizer, é o controle do próprio pipeline. Então, você tem essa coisa de que a equipe controla o seu próprio processo. Isso tudo que a gente fala hoje de Lincoln Band, de Flow Continuous Improvement, você lê o livro do Taichi Ono chamado O Sistema Toyota de Produção. Isso está tudo lá. Claro que é aplicado a carro, mas as ideias são as mesmas. A autonomia da equipe e assim por diante. Então, essa filosofia do desenvolvimento de software, como na verdade a criação de um produto, como na verdade um processo criativo que precisa ser desenvolvido por uma equipe autônoma, é uma filosofia que eu acho que é a filosofia mais próxima do que é a realidade do desenvolvimento de software. E isso também era uma coisa que, para mim, como programador, sempre foi o que eu quis. Eu quero ter mais autonomia para definir com o meu trabalho. Eu acho que é importante quem vai programar participar do processo de definir o processo de trabalho também, de definir como a gente vai trabalhar, qual esforço necessário. Então, sim, muita coisa que depois o ágil acabou trazendo. Então, a gente trouxe essa filosofia também. Então, essas foram as três grandes mudanças que a gente fez. Primeira de metodologia, sair do waterfall e começar a trabalhar com uma perspectiva de Lincoln Ban. A segunda, sair do ponto de função e trabalhar com uma métrica de esforço. A gente trabalhou com uma coisa chamada unidade de serviço técnico, UST, mas que basicamente é uma hora, hora homem. Então, por exemplo, quanto tempo você leva para fazer um crew de back-end, em PHP ou em .NET, sei lá. E, cara, surpreendentemente, a gente consegue, mesmo com toda a incerteza de desenvolvimento de software, que a gente sabe que tem incertezas, dá para a gente estimar algumas coisas. E a terceira mudança foi a mudança de filosofia, de sair dessa mentalidade de fábrica, de que o método formal é mais importante do que as pessoas, e sair para uma filosofia do... Que aí a gente usou essa ideia do software craftsmanship, da artesania de software, de que a qualificação e a busca pela qualidade de uma equipe autônoma é o centro, é o segredo do desenvolvimento de software então a comparação que a gente fazia era o seguinte, por exemplo você vai comprar um móvel, você pode comprar uma mesa dessas baratas que você vai montar e um ano depois ela já está toda bamba e tal, ou você pode comprar aquela mesa feita por um artesão. Sabe aquela mesa que você vai passar para o seu neto, que ela vai durar 50, 60 anos? Então, essas são as duas... É a mudança de paradigma, né? E isso... Houve uma mudança pô, eu ia bem falar isso aí, o pessoal falando de resistência à adoção. Eu ia bem entrar nisso agora, que é o seguinte, que foi a mudança cultural. Porque a principal, uma das mudanças mais difíceis foi a mudança cultural. Então, por exemplo, muita gente não conhecia a ideia do Lincoln Band de trabalhar com pacotes pequenos O pessoal queria trabalhar com sprint Então a gente começou trabalhando com sprint Só que logo depois até O negócio começou a ficar tão eficiente Começou a funcionar tão bem Que a gente pensou o seguinte Se eu terminei uma feature aqui, por exemplo, no segundo dia da sprint, por que eu tenho que esperar até o final da sprint para subir? Pô, eu acabei essa sprint aqui e sobe. Aí o pessoal falou, não, mas é porque eu deploy, sabe aquela coisa, pessoal, assim, que você chega no, quando você chega no trabalho, assim, que você chega no... Quando você chega no trabalho e, assim, o pessoal está com, sei lá, jarra de café, encomendou pizza, comprou açúcar, doce, não sei o quê. O que houve? Tem deploy hoje, né? Você sabe que, assim, tem uma operação de guerra por causa de deploy. Isso é porque, exatamente, deploy é um evento se o deploy é um evento é porque tem um problema no seu pipeline tem alguma coisa errada no seu pipeline, então uma das coisas que eu falava com a pessoa é o seguinte, deploy não pode ser um evento se você está com receio de apertar o botão, a gente lá implementou a suite do Atlassia o Jira, Bitbuck implementou a suíte do Atlassia, né? O Gira, Bitbucket, o Bamboo para deploy automático. E a gente falou, você está com receio de apertar? Cara, se você estiver com receio de apertar, então o que você tem que fazer? Reúne a equipe e descobre o seguinte, por que estamos com receio de apertar? Você tem medo de quê? Ah Descobre o seguinte, por que estamos com receio de apertar? Você tem medo de quê? Ah, eu tenho medo de que a mudança que eu fiz não vai fazer o que eu estou esperando. Ué, cadê o teste unitário? Cadê o teste de integração? Cadê a atualização do Selenium testando essa parte? Vamos embora. Ah, eu estou com medo de que vai quebrar uma dependência de não sei o que, não sei o que. Cara, teste automatizado, teste unitário. Cadê? Qual é a cobertura que você fez? Então vamos... Ah, está baixa? Vamos tentar trabalhar com 100% de cobertura? Vamos tentar chegar... Claro, nunca vai ser 100%, mas vamos tentar chegar no máximo que der? Entendeu? Então assim, você tem que ir eliminando os medos. E aí chegou uma hora, eu não vou pular lá para frente não, porque tem uma outra coisa importante que eu quero contar, mas a gente alcançou isso. Chegou uma hora que a gente tinha deploy o tempo inteiro. Para você ter uma ideia, o deploy no início era tão raro que eu sabia de todos o que acontecia. Ah, amanhã vai ter um deploy depois chegou uma hora que eu mesmo como chefe lá não acompanhava mais entendeu? algumas coisas eu acompanhava como usuário, eu ia usar uma aplicação lá corporativa e via caramba, bacana, já subiu aquilo que me disseram que estava no backlog, eu nem sabia que estavam fazendo, entendeu? e isso é o flow isso é exatamente o flow do link and bunker, quando você começa é ah, o flow, né? Isso é exatamente o flow do Lincoln Bank, é quando você começa a... É... Ah, o... O pessoal tá perguntando uma definição. Cara, eu não sei se eu tenho uma definição pro que que seria o deploy. Eu só acho que o deploy, ele tem que ser uma atividade normal do seu processo de trabalho, entendeu? Atualizar a aplicação na produção, ela tem que ser um processo normal do seu trabalho. Então, por exemplo, deixa eu te dar um exemplo. A gente tinha muito legado e muita dependência, muita codependência. O que a gente fez? Cara, a gente precisa testar mais na homologação, no staging. A gente precisa de um staging melhor. Cara, sabe o que a gente fez? no staging, pode, precisa de um staging melhor. Cara, sabe o que a gente fez? A gente botou todo o staging integrado com o deploy em container. Então, por exemplo, cara, você vai subir uma feature nova, você subia a aplicação, você subia o container com a aplicação de autenticação, ou seja, para a homologação de cada feature, a gente subia quase que uma réplica da nossa infra inteira em container no ambiente de homologação. Então a gente conseguia, inclusive, homologar duas features contraditórias ao mesmo tempo. Uma poderia quebrar a outra que a gente conseguiria testar as duas ao mesmo tempo. Testa aqui duas opções, qual que você quer? Não estou dizendo que a gente fazia isso não, mas assim, a gente conseguiu automatizar todo o nosso ambiente de homologação, então foi mais uma coisa que a equipe propôs para a gente ter tranquilidade na hora de subir e saber que não ia quebrar nada, entendeu? É exatamente isso aí, continuous deployment. Enfim, mas uma outra coisa da mudança cultural, pessoal, que eu acho importante dizer é que quando a gente implementou essa ideia do craftsmanship, a gente estava com a cultura muito quebrada lá. Tinha muita gente boa, mas a cultura estava quebrada. Então, por exemplo, vou te dar um exemplo. O cara, quem fala isso, aliás, quem fala muito isso também é o Sandro Mancuso, que é um cara que escreveu um livro sobre software craftsmanship. Ele fala sobre isso também, que é o seguinte. Isso acontecia exatamente lá. O cara tinha lá um formulário que, sei lá, vamos supor um crude, você tem um formulário lá, aí você clica no botão salvar e ele salva. E aí os caras vinham apresentar isso, a equipe técnica, os desenvolvedores e tal, vinham apresentar isso como se fosse uma grande vitória. Olha, maneiro, a gente fez aqui um formulário, você clica em salva e está lá no banco. Mostra aí, dá um select na tabela. Eu falei, meu irmão, qual está a profissão? Você é desenvolvedor? Cara, se você é desenvolvedor, você fazer um formulário, você clicar em salvar e ele salvar, não é mais do que a sua obrigação, cara. Não tem nada de especial nisso. Isso é o básico, isso é o mínimo. Entendeu? Isso é o mínimo. Entendeu? Então assim, o que a gente quer aqui com o Craftsmanship não é isso não. O que a gente quer aqui é o pixel perfect. O que a gente quer é a perfeição até o pixel. Eu vou minimizar o meu browser aqui 200 vezes e quero ver como é que fica a aplicação. Eu vou entrar aqui, entendeu? Eu vou tentar quebrar a sua aplicação e eu quero que ela seja perfeita eu quero a qualidade perfeita então assim, aí teve uma vez que o pessoal fez uma sprint, essa história é engraçada teve uma vez que a gente fez uma sprint lá e, cara foi um desafio técnico até difícil não lembro se era alguma coisa de Com autenticação Alguma coisa nova no React lá Não lembro, tinha uma coisa que era um desafio técnico difícil Eu não lembro exatamente o que era, tá? E aí o pessoal fez a sprint, entregou e funcionou bem Só que, cara, a entrega Tava muito boa tecnicamente, assim, o back-end e tal Só que o front tava quebrado A entrega estava muito boa tecnicamente, o back-end e tal, só que o front estava quebrado. Ele tinha alguns desalinhamentos, entendeu? Você vê que não estava 100%. E aí, cara, a gente devolveu a sprint. Isso na época que a gente ainda trabalhava com sprint, antes de trabalhar com a ideia de pacote pequeno do Lincoln Ban, né? Cara, a gente devolveu o sprint. E aí, quem perguntou aí sobre a mudança cultural, eu sempre fui, assim, também muito aberto, tá? Isso é uma coisa que acho que é importante da liderança, tá? Você ter uma abertura muito horizontal e ter espaço para as pessoas criticarem o seu trabalho também e aí cara, quando eu devolvi esse sprint, foi quase que um motim lá na minha sala vieram uns 4 desenvolvedores sem brincadeira a gente não gostou que você devolveu esse sprint não a gente fez um negócio aqui porra assim, assim, a gente fez um negócio super porra aqui, explicou tudo, eu falei cara, olha só todo mundo aqui, vocês estão aqui porque vocês são excelentes desenvolvedores a gente contratou aqui os melhores e a gente não tem dúvida de que vocês vão fazer funcionar só que cara, funcionar é o mínimo esse aqui é o nosso lema, funcionar é o mínimo, o que a gente quer aqui é a qualidade extra, então assim não vai passar, se não. Então assim, não vai passar. Se não estiver perfeito, não vai passar. E o pessoal não gostou, mas deu certo, porque eles entenderam a ideia. Então aqui eu vou dizer para vocês, pessoal, o segredo, eu acho, do que é a mudança cultural. O segredo da mudança cultural é o seguinte, você tem que trabalhar em duas frentes ao mesmo tempo. Uma frente é os incentivos. O que a sua organização e você como chefe, o que você recompensa e o que você pune? Claro, recompensa e pune estou falando aqui no sentido de metáfora. Punir pode ser só você falar, isso aqui não está legal, refaz isso aqui, nesse sentido. Estou falando no sentido de metáfora. Primeiro, você tem que controlar os incentivos. Por exemplo, devolver esse sprint. Isso é como se fosse uma punição, entre aspas. Não vou aceitar. Então, você tem que controlar os incentivos positivos e os negativos. Esse é um lado o outro lado é o lado do sermão é o lado do discurso, é o lado da comunicação uma das principais funções do chefe e da liderança, você tem que estar o tempo inteiro explicando a visão, cara qual é a nossa visão? Eu falei pra eles, cara, a gente quer ser a referência da TI no governo brasileiro. Aí chegou uma hora que eu falei para eles, olha só, eu não quero ser... Quando começou a vir visitar, muitos órgãos foram visitar a gente para aprender lá como é que a gente estava fazendo, 20, 30 órgãos. Aí comecei a falar para eles, olha só, agora é o seguinte, eu não quero mais só o governo vindo visitar a gente não. Eu quero que empresa comece a vir aqui. Vamos melhorar isso aqui, vamos trabalhar assim. E realmente aconteceu. Vieram algumas empresas, até o setor privado veio ver o que a gente estava fazendo. Então, assim, a gente teve aquela coisa assim, cara, a gente quer fazer software de maior qualidade, com maior não sei o quê. E assim, a gente foi desenvolvendo assim, do jeito mais, vamos dizer, mostrando para eles que a gente queria a mais alta qualidade com a mais alta tecnologia possível. Então, você está controlando os incentivos, positivo e negativo, recompensa e punição, e ao mesmo tempo você explicar a visão, explicar para onde você está indo, o efeito que você tem disso é o seguinte, na hora o cara fica pé da vida ou feliz com a recompensa e com a punição. Mas você explicando a visão também, uma hora aquilo que vem de fora pro cara, começa a vir de dentro dele também. Uma hora o cara começa a falar o seguinte, não, cara, a gente faz aqui assim pra disso. Quando isso aconteceu com o Sênio, aí quando o Júnior reclamar, ele vai falar, você não vai nem ouvir isso, mas ele vai falar pro Júnior, não, cara, tua entrega foi devolvida porque aqui não é onde você trabalhava antes, não. Que era só salvo. Que você entregava, que você vinha fazer bug durante o dia e você era pago. Não, agora aqui tem que não é só funcionar, aqui tem que funcionar e tá perfeita a entrega. Entendeu? Então, isso foi um trabalho muito grande que a gente fez de mudança e fora, assim, uma série de conflitozinhos ao longo do dia que você tem que ter a visão o chefe, a liderança tem que ter a visão de aonde você quer chegar pra você poder explicar pro pessoal e dizer pra ele por que eu preciso que você mude? olha, eu preciso que você faça isso aqui, porque a gente quer chegar ali entendeu? então por exemplo, deixa eu te dar um outro exemplo antes, eu não sei nem se tem lugares que ainda se trabalha assim, mas quando eu cheguei lá, quem fazia deploy na produção era só a infra. Não sei se ainda existe esse conceito. Mas assim, era só... Espero que ninguém que esteja nesse momento esteja nessa situação e se você estiver, por favor, não levante a mão pra você não ficar envergonhado tá bom? Tô brincando, tá galera? Mas tinha isso só operação, só a infra aí quando eu falei, não como assim infra? O que é isso, cara? Primeira coisa o pior da infra o pior disso é se você tiver ainda o formulário de mudança, em que um monte de gente tem que assinar o formulário. Novamente, eu até acho que se você... Os GMood e etc. É, exatamente, FMood, sei lá. Se você estiver trabalhando com software embarcado dentro de um marca passo, eu até acho que você tem que adotar alguma coisa nesse tipo mesmo. Mas se não... E aí, olha só que interessante, cara. O desenvolvedor veio reclamar e a infra também. Então, ninguém gostou. Falei assim, ué, como assim a infra não é mais dona da produção? Falei, cara, olha só, vem cá. Quando o desenvolvedor te manda uma aplicação O que você faz com ela Antes de botar na produção Você verifica o que, cara Você é programador Você corrige o código do cara Você lê o código, você não faz nada Então que fantasia é essa que a gente está criando Entendeu Ah não, mas veja bem, mas e se isso impactar Não sei o que, não sei o que? Ué, vamos, vamos, qual é o seu receio? Ah, isso pode não sei o que, não sei o que. Ué, controla lá no balanceador. Ah, mas isso pode afetar não sei o que, não sei o que. Ué, subrede. Entendeu? Isola cada aplicação então, libera só um determinado caminho, não sei o constrói aí o que você... E aí surgiu o DevOps, galera. Isso é... O dono do DevOps do lado de você. Isso é o conceito de DevOps. Isso é o conceito de DevOps, cara. Assim, o desenvolvimento é você trazer a operação para dentro do negócio. Isso é que é o interessante. Então, por exemplo, antigamente você pedia um recurso para infra como você pede um recurso para AWS. Olha, eu quero um computador assim, um computador assim, um computador assim e tal. Tanto de memória, tanto de não sei o quê. Só que chegou no momento que eu falei pra infra, olha, isso tá errado pelo seguinte eu não entendo de infra quem tem que entender de infra é você então quem tem que dizer qual o computador que precisa é você olha, eu tenho que dizer o seguinte olha, eu tenho aqui uma aplicação que vai subir você vai me dizer qual é a infra que eu preciso, aí o cara falou pô, mas eu não sei nada da aplicação. Ótimo, quer vir na reunião com a gente? O que você precisa? Então, o cara da infra, ele começou a ir no negócio, ele começou a participar das reuniões com desenvolvedores, porque ele vai planejar a capacidade. Ele também tem que estudar essa parte. Ele tem que saber os recursos que a gente tem. Claro, no caso, quem trabalha com cloud é diferente disso, é outro conceito. Bom, mesmo quem trabalha com cloud tem que saber se a sua aplicação é intensiva em banco, você precisa de uma coisa, se a sua aplicação é intensiva em outra coisa, você precisa de outra coisa. Você também tem que saber isso para poder subir a instância lá. Mas, de qualquer maneira, essa foi uma mudança cultural muito grande. O pessoal não tinha esse hábito de subir direto e nem a infra tinha o hábito de participar, de estar mais próximo disso. E outra coisa, só para concluir essa parte, uma outra coisa que a gente implementou lá, que é um conceito até novo, mas a gente começou a implementar lá isso, que agora o pessoal tem falado de Analytics Development Lifecycle, ADLC e tal, que é você trazer o banco e o Analytics para esse mesmo conceito. A gente começou a trabalhar com isso lá também. A gente chamou, a gente tinha uma equipe separada de banco e de análise, a gente chamou o pessoal e falou, vem cá como é que você como é que você faz essas extrações aí, esses ETLs essas buscas? Eu nem sei como é que é, sabe? Tem uns scripts lá em TXT na máquina o cara deve dar um ctrl-c, ctrl-v no terminal, não sei, a gente falou e a gente falou, não, olha, isso tem que estar versionado também entendeu? Isso tem que estar versionado também, tem que ter o mesmo pipeline de rastreabilidade que a gente tem no desenvolvimento, a gente tem que ter no analytics também, analytics também é código também tem que estar junto, então assim a gente começou a trabalhar com isso também, foi outra mudança cultural também com o banco mas eu acho que é muito nisso, assim. Você pegar também... Eu acho que tem um fator também, pessoal, que a gente que é da área, assim, existe uma questão de brilho também, né? O ATI tem uma coisa de brilho também. Você quer estar na vanguarda. Você quer estar com o seu currículo atualizado. Você quer estar trabalhando com as melhores práticas e não as piores práticas. Então isso também foi uma coisa que a gente vendeu muito lá. Cara, isso aí é muito importante. Galera, quem aqui já pediu a conta em uma empresa simplesmente porque você não aguentava mais trabalhar só com a tecnologia velha? E o ponto não é esse. Trabalhar com tecnologia mais antiga é uma coisa não ver perspectiva que você vai fazer parte do processo pra mudar isso é outra, porque não tem coisa mais louca nesse mundo é você pegar uma aplicação, um sistema uma coisa que tá o caos né? E você fazer aos poucos esse negócio chegar até onde você tava querendo isso é muito louco. Eu já passei por várias vezes por esse processo. Fora que você sente o super-homem, né? Porque pior que não está, não fica. E daí, tudo que você fizer é lucro, mas o ponto é você falar até onde, nesse momento, eu quero chegar. Agora, Gustavo, uma coisa que você estava falando, e eu acho que um dos pontos mais importantes, inclusive, desse bate-papo, que é o que você está falando, é essa mudança cultural. Porque isso acontece. Para quem é tech lead, para quem é desenvolvedor não interessa. Qualquer pessoa que você vai mentorar, que está abaixo ou do teu lado em algum momento, as ordens elas não funcionam mais faz porque é daquela forma as coisas elas tem que ter uma razão mais lógica para que a pessoa entenda naquele momento o porquê que aquilo está acontecendo e obviamente nem sempre as pessoas vão gostar por N motivos agora o ponto é assim Gust Gustavo, duas perguntas. Você fala dessa visão. O que acontece se eu estou hoje na minha squad, sei lá, com oito desenvolvedores embaixo de mim, ou se eu tenho algumas squads embaixo de mim, e essa visão, por algum motivo, eu tenho uma falha no lado da empresa. Ou seja, quem está acima de mim não me passou essa visão, por algum motivo, eu tenho uma falha no lado da empresa. Ou seja, quem tá acima de mim não me passou essa visão. E daí, nesse ponto, eu vou ter que, de alguma forma, entender o que eu quero dessa minha equipe. Então, a minha pergunta é como que você acha que... Porque eu acho muito difícil, tá, galera? Tem empresas que são tão grandes, tão grandes, tão grandes, que a visão, missão, valores da empresa, elas acabam ficando tão descoladas da realidade de onde você está, entendeu? Às vezes você está num banco enorme, gigante naquele momento, e você quer que, sei lá, a pessoa que está trocando o cabo de rede entenda que a gente está trocando aquele cabo para ter a maior conectividade. Cara, esse tipo de história jamais vai colar dependendo de quão descolado você vai estar da realidade. Qual que é a forma que você conseguiria dizer de uma forma assim, poxa se isso não tá claro pra mim como que eu crio algo pra deixar claro pra minha equipe e o segundo ponto aqui e esse eu acho que é um ponto que a pessoa tem que ter muito traquejo e é difícil quando você é um recém líder conseguir fazer isso que é, você vai ter que enfrentar um monte de gente que, mesmo você explicando por diversas formas, diversas formas, a pessoa vai falar eu não concordo com você e começa a bater o pé e começa a gerar aqueles conflitos que vai gerando aquela laranja podre dentro do time e começa a descoordenar um pouco o passo daquilo. E provavelmente, no meio de toda essa história, vocês já devem ter encarado isso. Tanto em TI, cara, você diplomata, entendeu? Dá um exemplo de diplomacia nesses casos, inclusive que não sejam de TI. Como que lida com essas situações? Porque, cara, uma pessoa que lida com diversas culturas, com diversos países, né? Teve uma época, a gente tava conversando, você tava em Washington, né? E ficava em Washington, na Embraxada Brasileira e não sei o que. Como que lida com esses conflitos que são difíceis, cara? Porque tem situações que parece que não tem jeito, parece que você vai falar, poxa, você vai sair da minha equipe, você cara cara cara, você acabou de abrir umas 15 abas na minha cabeça que é o seguinte vai travar o browser aqui mas é o seguinte é olha, tem várias coisas aí pra gente falar, muito interessantes que é o seguinte Cara, a primeira coisa Se você é um líder de uma equipe Um chefe de uma equipe e tal E Você acaba sendo O O firewall Entre a sua equipe e a organização Esse firewall Ele Tem que deixar passar Algumas coisas e não deixar passar entre a sua equipe e a organização. Esse firewall, ele tem que deixar passar algumas coisas e não deixar passar outras. Inclusive tem um cara, que é o Alistair Coburn, eu gosto muito dele, que fala sobre metodologia e tal. Ele fez talk aqui para a gente na nossa pós, cara. É mesmo? É, cara. Cara, eu sou fã desse cara. Inclusive, a parte de metodologia ágil, ele que fez tudo, cara. Foi muito bacana. Uma experiência legal. Porra, ele é muito bom, cara. Um dia eu quero conhecer ele, assim, pessoalmente. Ele é um dos caras que eu acho, assim... Ele fala uma coisa que a gente adotou lá, né? Que Que a gente adotou lá, que é essa ideia de uma metodologia por projeto, que é a seguinte, depois que você vai avançando no desenvolvimento de software e você consegue se desprender da metodologia e não ficar preso ao método, você vê que, na verdade, cada feature, não só cada projeto, cada feature vai exigir uma metodologia diferente. não só cada projeto, cada feature vai exigir uma metodologia diferente, né? Tem uma coisa mais complexa que você precisa fazer, de repente um requerimento maior, tem coisa mais simples que você não precisa, tem coisa que você vai precisar fazer um estudo antes, tem coisa que você não vai precisar, você começa a ver que no fundo, no fundo, cada coisa tem a sua diferença, e o Alistair Cobran chama isso de uma metodologia por projeto. Ele fala, cara, na verdade a ideia é essa. Mas tem uma outra coisa que ele falou, que eu ia citar, que é o seguinte. Ele falou assim, cara, se o chefe da TI... Ele falou do chefe da TI, mas isso vale para todo mundo. Se o chefe da TI não fizer nada e só ficar de firewall do time, protegendo o time cara, já é coisa pra cacete entendeu? porque só de você evitar que a bullshitagem e o gol horse da organização entre e afete o trabalho da sua equipe isso já é, cara já é o trabalho isso é a função do chefe entendeu? E aí o seguinte você fazendo isso você vai segurar várias, aos vezes você vai ter que abrir um pouco a panela de pressão pra soltar a pressão, você vai ter que entubar alguma coisa você não vai ganhar todas mas se você tiver, pelo menos, protegendo a sua equipe, e a equipe souber disso, né? Chega uma hora, chega uma hora que você vai falar com a sua equipe na boa. Você vai falar assim, galera, olha só, tô com uma buchitagem aqui pra vocês, que, olha, essa não deu pra segurar. A galera vai estar do seu lado, porque eles sabem que você segurou as últimas 10, entendeu? Então esse é o primeiro ponto, assim. O primeiro ponto é isso, é proteção da sua equipe. Você está ali para segurar, proteger a sua equipe da organização, e deixar passar o que é bom, obviamente, e segurar a onda da buchitagem, defender o seu trabalho, defender a sua equipe. Uma outra coisa que eu acho que é importante é que, muitas vezes, a liderança da instituição não vai ter uma visão clara do que ela quer. E muitas vezes, o negócio também não vai ter uma visão clara do que ele quer. Não é assim que funciona. Repara que, olha só, se eu sou desenvolvedor e eu estou querendo a visão pronta do negócio, repara como eu já caí sem querer no conceito de fábrica. Eu voltei para a fábrica. Sem perceber, eu voltei para a fábrica. Eu estou dizendo o seguinte, não, eu só executo. Você me manda aí as ordens me manda aí o negócio, a área de negócio, o que eles querem o produto, o manager o product owner, sei lá, me manda aí o que vocês querem e eu só vou executar mas peraí muitas vezes a oportunidade de alguma coisa ela não é só um negócio, você precisa fazer um match, você precisa fazer um casamento, uma interseção entre o negócio e aquilo que é possível tecnicamente, e aquilo que dá para você operacionalizar no tempo possível. Isso, quem tem que participar disso é a parte técnica. Então, assim, inclusive uma das coisas que eu comentava lá com o pessoal é o seguinte, olha, aqui a gente tem júnior, pleno e sênior. A diferença entre pleno e sênior não é técnica. Pelo menos lá no nosso conceito, tá, pessoal? Eu sei que cada organização aí vai ter a sua visão. A diferença entre pleno e sênior, para a gente aqui, é o seguinte. O sênior, ele é o cara que pensa o negócio. Ele é o cara que consegue, além de ser técnico, ele consegue casar a parte técnica e a execução com as ideias da organização. Porque se eu tiver que ditar para você o que tem que ser feito, se eu tiver que te explicar em detalhe o que precisa ser feito e você não puder desenvolver isso, isso significa que você não está pronto para fazer essa conexão entre a parte técnica e o negócio. Então, parte do trabalho do líder, parte do trabalho da liderança, e novamente, depende, tem projeto que é, claro, super intensivo tecnicamente, então o líder não vai ser um cara de negócios, é um cara mais técnico. Vocês, por favor, dão a... Eu sei que TI é muito diferente, então não tomem o que eu estou falando como uma coisa universal. Nada é universal. Tem que ser adaptada a cada realidade. Mas o que eu estou querendo dizer é o seguinte, é que parte do trabalho da liderança é você desenvolver uma visão do seu time e para o seu time e para a sua área que case com a visão da organização. E aí você vai dizer assim, mas a organização não está nem aí, os caras não têm visão nenhuma, a missão não tem nada a ver. Então, o que você acaba tendo que fazer é meio que perscrutar, penetrar a mente da liderança organizacional para descobrir o que eles pensariam se eles estivessem pensando em alguma coisa. Então, assim, o que é que eles quereriam querer se eles estivessem pensando no que eles querem? Quer dizer, não estão pensando em nada, mas você tem que chegar e falar, cara, olha só, vocês acham que num ministério do governo, o chefe lá do ministério O ministro vai chegar e falar Olha, eu tenho uma grande visão pra informática do ministério Eu acho que a informática tem que apoiar Não tem, não existe isso A informática é minha obrigação Se não, olha só gente Se não eu tô transformando a minha TI Eu tô falando isso pra TI como um todo Mas isso vale Vocês tem que fazer a analogia disso para equipes menores, isso vale para a equipe menor também. Que é o seguinte, se não eu estou dizendo que a minha TI é um garçom. Voltamos para o modelo da pizzaria. Eu fico parado, você me diz o que você quer e eu faço. Mas a TI não é uma... Inclusive, olha só que interessante. Olha só que interessante. Tem muita empresa grande que fala assim, precisamos alinhar a TI com o negócio. Já ouviram isso? Alinhar a TI com o negócio. Olha só como é que essa frase é esquisita. Porra, a TI não é parte do negócio? Ninguém fala assim, precisamos alinhar as vendas com o negócio ou precisamos alinhar as áreas de negócio, quais as vendas com o negócio, ou precisamos aliar as áreas de negócio, quaisquer que sejam os nomes delas, precisamos aliar a engenharia com o negócio. Ninguém fala isso, então por que a TI tem que ser alinhada? A própria frase dá a entender como se a TI fosse separada da organização. Isso aí, gente, é o modelo antigo de TI. Quando eu era criança, eu lembro que as empresas, elas ainda tinham uma área de organização OIM, lembra disso? Organização em Métodos, que definia processo. E aí você tinha uma área de informática lá, naquela época dos computadores que ocupavam o andar inteiro. Aí você tinha uma área de informática que ficava completamente isolada. A informática ficava como se fosse do lado do almoxarifado, entendeu? Você tem o almoxarifado e a informática. Então, a TI era o garçom. Aí a TI ficava afastada da organização e a pessoa começou com esse papo de alinhar a TI com o negócio. Mas, gente, não é alinhar. A TI é parte do negócio. E se a TI não é chamada para o negócio, claro, porque provavelmente já tem um problema cultural, falta de confiança, a TI não entrega muito bem, o pessoal já não convida mais, aí é um ciclo vicioso. Mas o correto é a TI ter uma visão para o negócio. Não, eu tenho uma visão de para onde a minha organização tem que ir e eu tenho uma visão de como a TI pode ajudar nisso. Ah onde a minha organização tem que ir e eu tenho uma visão de como a TI pode ajudar nisso. Ah, mas pô, é difícil eu desenvolver essa visão de negócio, porque eu sou um cara da informática, sou desenvolvimento... Beleza. Pô, começa aí nas reuniões, pede para ir em reunião, participa do negócio, entendeu? Participa de reunião com o usuário. O trabalho da chefia e da liderança, ela é um trabalho que está mais preocupado com a eficácia do que com a eficiência. Você está preocupado mais com a entrega de valor do que com executar o negócio bem feito. Então, se você está liderando uma equipe, pensa o seguinte, olha, você lidera uma equipe de oito pessoas. Oito pessoas, Como o Wesley falou Cara, quanto isso custa num mês? Quantos milhares? Aqui todo mundo ganha bem Vocês que ganham bem pra caramba Pelo menos 50 por mês Então Então você tem que pensar assim Cara, eu sou responsável Coloca aí, sei lá, 300 mil reais Coloca aí 300 mil reais, não sei quanto é que é, coloca aí, pô, 300 mil reais por mês, você é responsável por isso. Então imagina se você conhecendo o negócio, você falou assim, cara, olha só, na verdade, eu acho que essas 10 features que vocês estão pedindo aí, não é isso que o cliente quer. Eu acho que, na verdade, o que o cliente, o que o usuário final quer, é uma outra coisa. Eu acho que se a gente for por aqui, a gente faz uma feature só em um décimo do tempo e não sei o que. Esse também é o trabalho da liderança. Esse match do negócio com a capacidade operacional. Isso também é liderança. Então assim, resumindo o que eu falei, eu até anotei aqui, eu acho que o que eu falei, eu até anotei aqui, eu acho que o trabalho da liderança são quatro coisas. Primeiro, a questão de visão e cultura que eu mencionei. Você está passando uma visão e a cultura e tal. Segundo é a questão da gestão operacional. Claro, você tem que gerir ali o operacional. O pessoal tem que saber entregar o trabalho técnico, isso é óbvio. E você tem que trabalhar com uma metodologia que funcione, tem que ser satisfatório pessoal, motivação do pessoal, tem que ser uma coisa tecnologias novas e tal. Tudo isso é uma parte operacional. Segunda coisa. Terceira coisa que eu falei é proteger a equipe, o firewall da equipe. E a quarta coisa é a integração com o negócio, é entender o negócio. Então, mesmo que você esteja numa organização, como o Wesley falou, que não esteja nem aí para isso, cara, você tem que achar uma maneira como líder de conectar a visão da organização com uma visão que faça sentido para você e para a sua equipe, entendeu? Então, é o que eu estou te falando, que é o que a gente encontrou lá. Porque, assim, havia muita demanda por informatização, por produto no Ministério, mas ninguém me passou o que era. Ninguém me passou quais eram os projetos principais, ninguém me passou nada disso. Entendeu? Mas a demanda existe, claro, em qualquer lugar vai ter demanda. Então, assim, você tem que casar isso com o seguinte, olha, a única maneira de eu fazer isso é elevando o nível da TI. Eu nunca vou alcançar a demanda que eu acho que o Ministério precisa com essa TI, com goteira e waterfall. A gente até brincava com isso a gente falou assim, a gente está tão avançado que a gente teve chuva antes do cloud né e começou a chover no nosso data center antes de ter cloud mas assim essa coisa da nuvem mesmo, por exemplo mesmo a gente não podendo implementar AWS e tal, toda a nossa arquitetura é cloud native, é toda a ideia de infraestrutura como código, continuous deployment, pipeline automatizado, TDD, muito teste unitário, toda a estrutura foi feita uma estrutura moderna, entendeu? Então, assim, isso foi uma forma de casar o anseio da equipe com a visão da organização e esse é o jeito. Quer dizer, pô, o que que... Tem você estar lá abraçado com o ministro falando. Qual é a visão? Não. Não tem para ninguém isso. Entendeu? Aí vem o seguinte, aí olha só, você falou uma coisa importante, que é o seguinte, é claro A TI tem que... Aí vem o seguinte, aí olha só, você falou um ponto importante, que é o seguinte, é claro que você tem que prestar contas das coisas, algumas organizações vão ter, se você de repente é líder de um squad, sei lá, você vai ter uma reunião com o seu chefe semanal, não sei como é que é, eu tinha uma reunião com um comitê estratégico de TI, então eu tinha que prestar contas. E tudo isso, aí já entra num tema que a gente chama de governança. Governança tem a ver com como é que as decisões são tomadas e como é que eu explico e comunico essas decisões. Então é uma mistura de decisão com stakeholder management, sabe? Então assim, quando você entra na área de governança, aí você tem outras técnicas e coisas que você tem que fazer, que é o seguinte, quando você começa a ser líder de uma equipe grande, boa parte do seu trabalho não é mais com a sua equipe, boa parte do seu trabalho é se comunicando para fora. E boa parte do seu trabalho é se comunicando para fora e boa parte do seu trabalho é explicar é que explicar o que você faz é explicar porque a TI não pode atender uma coisa que foi pedida é explicar porque a sua equipe técnica acha melhor uma coisa que não outra e aí o Wesley mencionou de diplomacia, cara, a coisa que eu mais uso, e como os principais stakeholders de um ministério não entendem de TI, a principal coisa que você tem que usar nesse caso é a analogia. Entendeu? É tudo analogia. Então, por exemplo, uma vez o pessoal não entendia por que a nossa capacidade, por que 20% ou 30% da nossa capacidade era praticamente para manter a TI funcionando. Eu não tinha 100% da capacidade para projetos, porque eu tenho que manter meu pipeline, eu tenho que atualizar as coisas, eu tenho só manutenção, só sustentação. Então, quando eu ia explicar isso, eu tenho um monte de só manutenção, só sustentação só então quando eu ia explicar isso eu falei assim, cara, olha só, você tem um carro você não tem que dar manutenção no seu carro, você não tem que fazer uma revisão você não tem que lavar ele o seu carro ele não está disponível para você 100% do tempo ele tem que ficar disponível ali 90% porque 10% ou 5% dele você está gastando com manutenção. Agora, você imagina se seu carro fosse um produto novo que foi lançado ontem, que é uma coisa muito mais nova, muito mais moderna, muito mais sujeito à falha. Seu carro ficaria uns 20% do tempo na manutenção. Então, era o tempo inteiro, pessoal, usando esse tipo de analogia, entendeu? Então, por exemplo, quando a gente foi falar sobre acabar com a TI como garçom, a TI como pizzaria, o pessoal também estiou algumas áreas de negócio, porque eles estavam acostumados a ficar mandando pedido lá de projeto para a TI. Uma coisa que eu conversei com eles é o seguinte, vem cá, aí a analogia que eu usei é o seguinte Quando você vai no médico Você diz o remédio que você quer tomar Você já pede o remédio? Não, você não pede o remédio Você diz o diagnóstico que você tem? Estou com a doença tal e tal Não, eu não disse O que você diz? Você diz os sintomas, a dor. Então, a informática é a mesma coisa. A informática é um trabalho técnico, você vai dizer a dor que você tem. Você vai dizer os sintomas, qual é o problema que você tem aqui na sua unidade. E aí, a gente vai fazer o diagnóstico e a gente vai dizer se você precisa de um sistema ou não, porque a resposta para você pode não ser um sistema. Por exemplo, em TI corporativaativa pessoal, é muito comum é muito comum cara, eu gosto muito de, eu gostei muito de trabalhar com startup, mas eu gosto de TI corporativa também, porque tem parte política tem outras coisas, empresa grande organizações grandes, você tem outros fatores o cara às vezes quer um sistema pessoal, que não tem utilidade muito grande, mas é porque isso é importante para ele fazer o currículo dele dentro da organização. Vocês estão entendendo? O cara quer fazer um sistema novo porque aí ele vai dizer que fez. Ele vai ter uma história para contar dentro da organização. Tem todos esses fatores aí a ser promovido. Então tem todos esses fatores que você está TI, você está ali também para zelar pelo bom uso dos seus recursos. Você como líder, você está zelando pelo bom uso dos seus recursos. Você está protegendo o financeiro da organização, inclusive. Então é o seguinte, cara, isso aqui você não precisa disso. Isso aqui você talvez, cara, eu acho que, pô, de repente um Excel resolve para você aqui. O que você quer, o Excel resolve. Aí você descobre que, na verdade, o cara quer um sistema porque ele não sabe usar o Excel. Aí você, como TI, você vai lá e dá um apoio. Te ajuda a desenvolver a planilha. Entendeu? Vambora. Entendeu? Você também tem que dar esse tipo de apoio também Como uma TI corporativa Manda um cara do N1 lá Do N2, sei lá Para ensinar o cara a usar o Excel E tal Tem o contrário também Tem mesmo, o cara que não sabe usar o sistema E faz o Excel, tem também Então assim, você tem de tudo Então essa é uma outra analogia Que eu usava bastante, entendeu? Olha, informática é um trabalho técnico, você não dá o diagnóstico, muito menos o remédio. Você vai dizer a dor que você sente, quais são os problemas que você tem. Então, boa parte do trabalho da liderança é essa... Em vez de firewall, talvez eu devesse dizer tipo interface, entendeu? É um firewall barra interface. Você está o tempo inteiro ali, cara, se comunicando, tentando blindar a sua equipe para dentro e explicar o que a sua equipe faz para fora, entendeu? Cara, isso é... Faz muito sentido, principalmente nesses tipos de caso, porque no seu caso aí acabou mudando completamente o processo, mas o processo que você mudou foi o processo de desenvolvimento da porta pra dentro, mas que forçou com que a porta para fora seja mudada completamente também. E provavelmente um monte desses conflitos acabam acontecendo. Como que você também, Gustavo, independente se é TI, se é software, eu fico imaginando a quantidade de coisas que de dia a dia, independente informático ou não, uma pessoa que acaba lidando com um monte de país diferente, uma cultura diferente, uma hora tá nos Estados Unidos, tem hora que tá na República Dominicana, e esses tipos de coisa. Como é que você, pessoalmente, olha formas de resolver conflitos que acabam sendo conflitos que acabam tirando o sono, cara. Porque eu acho que esse tipo de coisa é o que mais faz dar burnout na vida de todo mundo, né? O cara não fica em paz por conta que ele tá com aquele determinado conflito. Pode ser com a equipe dele, pode ser com o chefe dele, pode ser com uma situação fora, mas que acaba afetando ele no trabalho. Como que esses tipos de cara, o resumo é o seguinte Gustavo, quando você assiste esses filmes tipo da Netflix Madame Secretária The Lincoln Lawyer meu Deus do céu o famoso lá do presidente com o Space eu sei qual é O famoso lá, o... Do presidente, cara, com o Space, lá com o Kevin... É... Eu sei qual é. É. Bom, vocês sabem de qual que eu tô falando. Cara, esses tipos de coisa acontecem... Como que resolve esses tipos de coisa, cara? Cara... Ou é só Netflix? É, House of Cards, pessoal. House of Cards. Olha... Eu acho que, assim, tudo depende também... É porque, assim... House of Cards. Olha, eu acho que assim, tudo depende também. É porque assim, a forma como você aborda o conflito, ela depende. Isso vale até para o país, isso vale para indivíduos, isso depende assim, do quanto de autoridade e poder você tem sobre aquela situação. Às vezes, se você é dono da empresa, às vezes você tem um jeito rápido de resolver um conflito. Talvez não seja... Você pode mandar alguém embora. Talvez não seja a forma ideal, porque aquilo pode ter uma consequência para a cultura. Aí você tem que medir isso. Mas você tem, pelo menos,, mas você tem pelo menos autoridade de resolver o conflito se você não é o dono da empresa dependendo da posição que você tá, você vai ter formas variadas de resolver o conflito cara, uma das coisas que eu sempre falei assim eu sempre falei assim, olha, toda vez que eu conversava com alguém tinha algum problema de conflito com outra pessoa e tal, e vinha me pedir conselho, eu sempre falei assim, cara, olha, eu acho que sinceramente eu acho que eu sou muito novo pra dar conselho pra qualquer pessoa, eu sempre falei isso, até eu fazer 40 anos, depois que eu fiz 40 anos eu falei, cara, não, acho que com 40 anos. Depois que eu fiz 40 anos, eu falei, cara, não, acho que com 40 anos já dá pra você começar a dar conselho, a falar algumas coisas. Então, por exemplo, eu lembro de uma vez que teve um desenvolvedor júnior, um cara muito bom e informática tem uma coisa tem uma característica que eu acho muito legal muito interessante, que é o seguinte geralmente é muita gente nova trabalhando desenvolvedora e tal, muita gente nova e isso é uma coisa que o Sandro Mancuso fala muito também que é o seguinte, toda vez que você tem muita competência misturada com juventude, você em geral vai ter arrogância e brilho como resultado, quando você tem muita juventude, então assim, às vezes o cara é um júnior excepcional mas pô, falta uma experiência então ele fica cara, quantas vezes a gente já não viu isso o cara fica pé da vida porque o sênior criticou a ideia de arquitetura dele entendeu? falei, cara, mas isso aqui é o que? isso é o normal, pô primeiro que assim, o debate está aberto segundo, deixa eu te falar uma coisa. Eu, como chefe, eu, para mim, o fundamental não é o cara que deu a ideia. O fundamental, para mim, é o cara que ouve as ideias e que tem o discernimento para fazer a melhor decisão. Você ter o discernimento para fazer a melhor decisão. Você ter o discernimento para tomar a melhor decisão é muito mais importante do que gerar as ideias. A não ser, claro, que seja uma ideia super mirabolante de uma coisa tecnicamente inovadora. Quando a gente está falando de arquitetura de sistema, e a gente está falando de papel de liderança, acaba que a questão da capacidade de discernimento é muito mais importante. Então, por exemplo, alguém teve uma ideia de arquitetura, disse assim, peraí cara, essa ideia de arquitetura aí, cara, muito ponto de falha, muita coisa desacoplada, não vai dar certo isso aí. Outra coisa, o cara bate o olho e fala assim, pô, essa arquitetura aí, cara por que que vocês estão me sugerindo que eu crie uma dependência em cima de um produto aí particular pô, o que isso vai me gerar de dívida técnica no futuro entendeu? Então você começa você tem que ter esse tipo de olhar, esse tipo de discernimento isso é muito mais importante do que... Cara, tem uma coisa engraçada, cara. Eu ia muito naquela QCon... Vocês conhecem a conferência QCon, né? Eu fui várias vezes lá em São Francisco, lá na conferência em São Francisco. Cara, eu vi o cara do Uber, acho que ele era o CTO, sei lá, falando sobre a arquitetura de microserviços da Uber. Cara, hoje em dia, muita gente está falando que microserviço está morto, tem todo um debate sobre contrário a microserviço. Cara, na época, os caras estavam apresentando isso, eu falei, cara, o Uber tinha milhares de microserviços, era uma descentralização muito, muito, muito exagerada, cara. Muito exagerada. Então, assim, eu quero um cara... Eu não quero um cara que tenha uma paixão por microserviço, nem um ódio por microserviço. Eu quero um cara que conheça o que é e que vá olhar o meu negócio, a minha necessidade de negócio e vai casar melhor que arquitetura para isso. De repente aqui vai ser uma coisa mais monolítica, de repente aqui vai ser uma coisa mais descentralizada em microserviço e com um acoplamento mais flexível, vamos dizer. Então, tudo isso tem que ser analisado. E eu confio mais num cara que vai ter discernimento do que nisso quando eu expliquei isso pro cara você explicar isso dirime um pouco o conflito porque o pessoal entende da onde você está vindo deixa eu dar um segundo exemplo eu tinha um outro desenvolvedor excepcional que também ficou pé da vida porque criticaram lá o código dele alguma coisa assim e aí ele veio conversar comigo e falou assim, olha eu vim só dizer pra você que eu tô saindo da equipe, tô indo embora aí eu pensei, bom, se o cara veio me avisar, é porque não está saindo ainda. Porque se estivesse saindo, mesmo, se a decisão estivesse 100% tomada, ele não viria me falar. Ou ele me falaria depois só, me dizeria dá. A forma como ele falou foi que assim, foi mais estou querendo sair. Eu falei para ele, cara, vem cá, olha só quais são as coisas boas que tem aqui você trabalha com a tecnologia que você quer você tem isso, tem isso você desenvolve, outra coisa, você está aqui você cresceu pra caramba nesses dois anos você está aqui, não sei o que outra coisa que é uma das maiores lições que eu já tive na minha vida profissional, que eu vou falar para o pessoal aí para vocês. Uma das maiores lições que eu tive na minha vida profissional é o seguinte, não existe emprego perfeito, cara. Você tem que medir muito bem a sua insatisfação. Não existe emprego perfeito. Você acha que vai trocar e necessariamente será melhor? Então assim, pensa bem, faz uma análise racional, mede os benefícios e os custos e se avisa. O cara não saiu, entendeu? Então assim, eu acho que existe esse tipo de conflito, que são conflitos que eles não são conflitos reais, eles são percepções equivocadas da realidade. Então, isso é muito importante, pessoal, que é o seguinte, alguns conflitos ou muitos conflitos, eles têm mais a ver com a percepção e com a linguagem do que com qualquer outra coisa. Por exemplo, se eu perguntar aqui para vocês agora, quem acha que hidroavião é avião ou é barco? De repente, metade vai dizer que é avião e metade vai dizer que é barco. Aí, de repente, alguns vão dizer, não, mas pô, não é barco, eu não uso ele para navegar. Não, tudo bem, mas você não para ele num porto? Você paga a taxa portuária como se fosse um barco, você está assistindo ele como se fosse um barco, então assim, ele é um pouquinho o barco ele é, então assim aí vai ter uma discussão aqui gigantesca aí avião é barco, avião é barco e na verdade o que a gente vai estar discutindo não é a realidade de fato não é uma discussão de realidade, a gente para na água. A gente concorda. Só que quando a gente transforma isso para uma discussão de... Quando a gente joga isso no âmbito da linguagem e da percepção, às vezes a gente vai ficar discutindo se uma coisa é uma coisa, se outra coisa é outra coisa, e perdendo um tempo gigantesco por causa disso. Então, é muito importante, na primeira coisa, quando você sentir um conflito Essa é a primeira coisa a ser feita Isso é um desentendimento real Ou é um desentendimento De percepção e de linguagem Por exemplo Uma coisa que eu já vi muito acontecer Vocês devem ter visto também Ah, isso aqui é ágil ou não é? Ah, isso é Scrum ou não é? Irmão, não estou preocupado com Scrum Estou preocupado com entregar software Entendeu? Então assim, se não é Scrum Mas estiver funcionando Tudo bem, não precisa chamar de Scrum Te incomoda se chamar de Scrum? Então assim, não chama de Scrum Chama de outra coisa Mas não interessa, não estou preocupado com o nome, entendeu? Então você vê que esse é um exemplo real, pessoal. Ah, se isso aqui é Scrum, se isso não é, mas isso é o que, claro, não interessa, não estamos querendo certificação de nada, o objetivo não é esse aqui. Então, às vezes, esse é o primeiro fator do conflito. O segundo ponto de conflito eu acho é que às vezes ele não é um conflito também, como é que eu posso dizer não é um conflito grave mas ele é um conflito de como é que eu posso dizer? De, às vezes, mau jeito das pessoas, entendeu? Isso eu vejo muito na TI também. O pessoal ter... Tipo assim... O cara vê um código... Porra, quem é que fez isso aqui? Então, assim... Tem coisas que quando você trabalha em equipe, você tem que ter um certo cuidado na forma de falar. Então, eu já vi também muito conflito por causa disso. E aí, eu acho que é uma questão de fazer um coaching com o cara, entendeu? Chegar e falar, cara, olha só, o que você falou pode estar até certo, mas, pô, o outro cara é um profissional também, se ele não falou da melhor forma possível, se você não fala de uma forma respeitosa e tal, você vai gerar um conflito à toa e aí você tem que explicar. Aí, pô, eu tenho que interceder, vai perder um tempo, mas tudo não perde tempo, isso é uma droga. Então você pode quebrar essa pra mim, ter um pouco mais de cuidado, entendeu? Você tem que também ter um jeito você não pode fazer o rabo do cara também ali o que você é é um mal educado na real é assim também não de jeito nenhum vai fazer igual o cara mas assim então assim e que eu me lembro de ter passado eu não lembro eu acho que tem me lembre de ter passado, cara, eu não lembro de ter... Eu acho que tem um outro tipo de conflito, que aí sim é um conflito que eu nunca tive na minha equipe, tá, pessoal? Eu nunca tive na minha equipe, mas eu já tive que lidar com isso com outras áreas. Que é você lidar com um cara meio assim, picareta mesmo, entendeu? Tipo, mau caráter. Isso eu nunca tive na minha equipe, isso. Mas é tipo assim, um cara que você fala uma coisa e o cara numa reunião diz que você falou outra. Entendeu o que eu quero dizer? E aí, cara, é uma coisa que é difícil de lidar. E aí depende muito da personalidade de cada um, do poder que você acha que você tem, de como você articula isso com outras pessoas. Aí já entra numa outra coisa que é articulação de networking e poder dentro da organização, entendeu? Já é uma outra questão. Mas eu nunca tive que lidar com isso na minha equipe e eu acho que se isso acontecesse dentro da minha equipe, eu acho que aí teria que encaminhar uma coisa mais drástica mesmo, de demissão, desligamento, alguma coisa assim, entendeu? Mas no geral, cara, a maior parte dos conflitos que eu tive, a gente tinha uma equipe muito boa. Então, o conflitos que eu tive, assim, a gente tinha uma equipe muito boa. Então, assim, o conflito que dava era mais porque na informática a gente tem muito brilho, cara. Eu acho que isso é quase que uma doença ocupacional da informática. Entendeu? Porra, você criticar, assim, e não à toa, cara. Se vocês forem ver essas vagas aí, o que mais o pessoal quer saber é se você se comunica bem, se você consegue se comunicar com o pessoal técnico, com o não técnico, se você tem cross-functional team leadership. Por que o cara quer o cross-functional? Porque existe esse problema na informática. Então, o que eu mais tive de conflito foi isso, foi coisa de brilho, de brigarem. Cara, teve uma vez, vou terminar com essa história, teve uma vez que a gente tinha lá um sistema de... A gente tinha muita coisa sigilosa, muita coisa bacana, de coisa de criptografia que não tem em outros lugares, coisa de criptografia baseada em hardware, coisa bem bacana com integração com hardware coisa que dificilmente tem em outros lugares e cara, tinha uma implementação lá que a gente tinha que fazer que poderia ser feita tanto com criptografia com chave simétrica e assimétrica, ou assimétrica cara, eu tive que uma vez praticamente apartar uma briga uma discussão em voz alta, um gritando com o outro sobre se o ideal era simétrico ou assimétrico. Entendeu? Então assim, discussão pesada. Então eu apartei os dois e tal, e depois chamei os dois e falei, cara, isso aqui é um ambiente profissional, isso não pode acontecer. Não é assim que a gente resolve as coisas. Entendeu? Cara, não pode ter paixão por uma solução o objetivo não é a solução técnica o objetivo é atender o negócio o objetivo é gerar valor então se você está apaixonado por uma decisão técnica, você está errado o médico vai estar apaixonado por um remédio? Não é assim que funciona ele tem que estar apaixonado pelo cliente curado essa é a paixão do médico então assim, a maior parte dos conflitos que eu tive foram desse tipo, entendeu, pessoal? Mais dessa coisa de ou conflitos inexistentes, que era mais uma discussão simbólica sobre percepção errada, ou esses conflitos de mais choque por crítica, crítica às vezes muito ácida, e aí o cara recebeu bem e às vezes também alguém não está num dia bom, o cara já brigou com a esposa em casa com conta, tem todos esses fatores também, o líder tem que estar entendendo que assim, todo mundo tem dia bom e tem dia ruim também show de bola. Galera, eu não sei vocês, tá? Mas, caras, eu acho que... Essa pegada de blindar a buchitagem da empresa e conseguir fazer com que o seu time trabalhe de verdade de uma forma mais protegida, eu acho que pra mim foi um dos pontos assim bem altos honestamente falando, porque uma das coisas que eu percebo muito é o líder ele acaba se isentando de ter que tomar uns posicionamentos exatamente pra dizer olha, a culpa não é minha. Então é como se não tivesse o líder. Começa a passar tudo já direto pro desenvolvedor. Acaba passando tudo pra equipe. Então eu acho que esses tipos de coisa, essa forma de... essas percepções de o importante é resolver o problema, é importante você... não interessa se é o hidroavião, se é avião, se é isso, se é aquilo. Eu acho que esses detalhes, galera, eu acho que são um dos pontos mais importantes para todo mundo que, de uma forma geral, ou já é líder hoje, ou pretende se tornar um. Eu não acredito que aqui todo mundo queira ser programador para sempre e ficar somente... Não digo somente, tá? Porque tem gente que gosta e vai querer programar o resto da vida e provavelmente isso não vai acontecer por conta de, ah, isso aí é uma outra história, mas o ponto principal é que esses tipos de relação, essas formas de como que você vai lidar o dia a dia eu acho que são essas dicas, assim, elas são muito importantes, porque o Gustavo, ele já tem mais que 40 anos, e ele, acredito que ele já passou por bastante coisa. Não é fácil, realmente, você conseguir, né, mudar o comportamento cultural, tanto de uma organização onde você está assumindo mas ao mesmo tempo também mudar o comportamento cultural de pessoas de outros lados que tem que começar a saber, olha eu não sou mais garçom você estava acostumado a fazer o pedido online, agora você vai ter que conversar comigo e ver se eu vou querer te servir. Esse tipo de coisa é uma mudança muito forte, pessoal. E antes de eu fechar e agradecer o Gustavo aqui, eu queria que todo mundo realmente pensasse o quanto de garçom você está hoje na sua empresa, o quanto você consegue realmente proteger o time que você está hoje aí na sua empresa, né? O quanto você consegue realmente proteger o time que você está? Ou o quanto realmente o seu líder hoje está te protegendo, entre aspas, e que eventualmente você pode conversar com ele e falar assim, cara, será que esse tipo de informação, esse tipo de coisa vai ajudar muito mais a nossa equipe a entregar isso mais rápido? O que será que a gente poderia fazer para a gente conseguir ter algumas diretrizes muito mais claras pra gente conseguir trabalhar e acredito também que tudo é alinhamento de expectativa, né Gustavo onde todo mundo tem essa ideia do que é esperado dele no final do dia né? Sim, é isso aí por isso que tem que estar sempre explicando, né, sempre conversando pra fora e isso que você falou, cara de deixar passar é, cara, isso é o o que mais me incomodava era aquele cara que é como é que o pessoal chamava? no RUP lá, é o analista de requisitos, sei lá, engenharia de requisito aí o cara ia lá coletar, estou indo coletar requisitos. Aí o cara vai lá conversar com o usuário para coletar, olha o nome já é meio assim, coletar requisitos, como se o cara fosse te passar o que ele quer. Não, eu quero um sistema assim, assim, assim. Como se o usuário pudesse dizer o remédio que ele quer, como se ele soubesse também, porque o cara não sabe, não sabe o que dá para ser feito, qual o custo, qual o orçamento que a gente tem, o cara não tem essa noção, não sabe quantas coisas custam. Então, hoje o pessoal chama de entrevista, mas a entrevista como uma forma de você, ou a observação e tal, como uma forma de pesquisa qualitativa, pra você conhecer o negócio, eu acho, isso é válido. Entender a dor do paciente, né? Entender a dor do paciente, exatamente. A questão é que antigamente o cara coletava requisito e o requisito virava a lei. Não, ó, o cliente pediu assim, então tem que ser assim. Ou a área de negócio pediu assim, então tem que ser assim. Ou a área de negócio pediu assim, então tem que ser assim. Então você vê que mesmo isso, e aí você tinha o PO ou o Product Manager, ou o que seja, que o cara era tipo aquele roteador pass-through, sabe? Quando você configura o bridge lá, o roteador pass-through, eu passava tudo. Manda tudo. Manda tudo, entendeu? Então é realmente assim esse trabalho é do cara entender o negócio e começar a sugerir e pensar. E quando esse trabalho é bem feito, você vai estar na entrevista e nas coisas, às vezes você vai ficar mais quieto do que o cliente. Você vai ouvir muito mais. Mas vai chegar uma hora que se esse trabalho estiver sendo bem feito, você vai começar a ter uma visão do que deve ser o produto também e vai virar um diálogo com o negócio, vai virar um diálogo com o usuário você vai começar a propor muito mais do que simplesmente ouvir show de bola galera queria aqui na frente de todo mundo obviamente, agradecer demais o papo fantástico aí com o Gustavo galera queria aqui na frente de todo mundo, obviamente agradecer demais o papo fantástico aí com o Gustavo, o Gustavo sabe que eu admiro ele pra caramba, é um cara mega inteligente isso porque vocês ouviram só os casos dele de TI, galera você tem que escutar as outras as outras as outras linhas de pensamento também que o Gustavo tá um cara 100%, Gustavo, obrigado mesmo, cara por ter cedido aí seu tempo eu que agradeço eu que agradeço, cara e pô, vou te falar uma coisa eu ficaria mais umas 5 horas aqui conversando porque é muito bom e cara, vou te falar aí parabéns aí para o pessoal, porque rapidamente aqui vai passando aqui a janela aqui, o pop-up do Zoom aqui, mostrando os comentários. Cara, muita pergunta boa, pô. Muito comentário bom, assim. Acho que vocês aí estão refletindo e indo no caminho certo, sabe? Da TI... Vamos dizer, da TI sentada à mesa, entendeu? sentada à mesa junto com o negócio, entendeu? isso é uma coisa importante ser construída e uma última coisa, Wesley, que você falou da questão da liderança e da programação eu acho, cara, que é muito bom você ter um construir esse background técnico, entendeu? É muito bom isso. Muito bom. E mesmo o cara, assim que mesmo a pessoa que é muito boa de produto e pô, só trabalha com produto e nunca programou muito o PO e tal, cara, vale muito a pena pelo menos um pouco de programação, entendeu? Pelo menos aprender um pouco pra você ter esse background técnico, entendeu? Então, quando você chegar na posição de liderança, isso também te dá uma certa moral, entendeu? Porque você consegue ter um diálogo mais de igual para igual com a sua equipe você sabe o que elas estão passando e você consegue até de uma maneira claro, de uma maneira muito jeitosa você consegue dar uns sinais também entendeu? tipo assim cara, você quer dar uns sinais também, entendeu? Não me enrola não. É, tipo assim, cara, você quer que eu faça isso aí pra você em quatro horas? Você tá me falando que vai levar dois dias, você quer que eu faça isso aí em quatro horas? Entendeu? Você consegue de um jeito brincando, você tá falando o que você falou, né? Não enrola não. Então, tudo isso te dá uma autoridade. Então, o pessoal aí que está começando, que quer atingir a posição de liderança e tal, o que eu estou querendo dizer com isso é o seguinte, não pense que você está perdendo tempo. Mesmo que você esteja pronto para a liderança, você não está perdendo tempo, porque essa bagagem técnica, você vai usar ela toda no futuro, entendeu? Ela vai te servir pra muita coisa. Você vai usar ela com certeza. E aos poucos você pode também começar a sabe aquela coisa de você tem que se vestir pro cargo que você quer? Você começa também a agir com cargo que você quer, você começa também a agir com aquilo que você quer. Cara, deixa eu entender essa fit aqui que você pediu. Qual é exatamente o objetivo de negócio dela? Começa a entender. Começa a entender aquilo que você está fazendo, aonde aquilo vai. É meio que uma coisa de agir como uma liderança na organização antes mesmo de você ter o cargo. Deixa eu entender isso aqui. Que negócio é esse? Por que a gente está fazendo isso assim e não desse jeito? Ah, beleza, tudo bem. As suas primeiras perguntas, elas vão ser... Você não vai saber muito bem. Você vai ter que aprender a perguntar até. Se você está muito só na área técnica. Você tem que até aprender a perguntar. Mas você começa a aprender a pergunt perguntas vão fazendo mais sentido, daqui a pouco as suas perguntas vão ser ideias de melhoria, daqui a pouco, entendeu? Então tem isso muito também, assim, de você começar a... isso eu converso às vezes com amigos, parentes, assim, dando sobre dica profissional, é um pouco isso, assim, você começar a agir de acordo com o cargo que você quer obter, entendeu? E aí a própria organização,ação começa a ver, pô, espera aí, esse cara aqui já... Isso que a gente está querendo, esse cara aqui já está fazendo, entendeu? E a gente já tem um cara que de repente dá para puxar e tal. E como eu comentei com vocês, para mim, lá na minha organização, a diferença entre Plano e Sênero era essa. Era quando o cara começava, meu irmão, deixa comigo que o negócio, cara, isso aqui tá difícil de entender o objetivo de negócio aqui, não, deixa comigo que eu vou entendeu? Então você começa a ver que essa era a marca, então fica esse recado aí Wesley, muito obrigado cara, tô, fico feliz, acho que dá pra ver que eu fico empolgado aqui discutindo esse tema e já tô aberto aí para quando você quiser de novo, você me convida aí que a gente volta a conversar. Demorou, demorou. Super valeu aí, Gustavo. Galera, muito boa noite, espero que vocês tenham curtido bastante. Eu aprendi coisa para caramba, me botou para pensar um monte de coisa, que eu estou até, não sei, eu vou dar uma corridinha agora pra internalizar todas essas coisas, e valeu demais aí, galera, valeu Gustavão, muito obrigado aí mesmo, pessoal, até mais. Até pessoal, boa noite, obrigado. Até mais, tchau, tchau.