Mas queridos, eu vou passar reto aqui Primeira coisa que eu quero trazer pra vocês é o seguinte E aqui eu falo de forma muito enfática E eu vou falar sem dar muitas voltas Meu objetivo aqui, como eu tô falando com esse grupo E é um encontro de mentoria Eu vou falar de uma forma mais direta Cara, por que que pagam teu salário? Qual é Vou dar uma outra dica importante Como é que você vai eventualmente Pleitear um aumento de salário, né? Porque eu acho que todo mundo quer ganhar mais, como é que você vai pleitear um aumento de salário? Eu vou dizer o seguinte, cara, independente de onde você trabalhe, independente do que você faça, se você trabalha numa big tech, numa empresa pequena, numa empresa, numa startup, numa empresa com modelo consolidado, o trabalho do arquiteto, o barra de arquitetura, na prática, é sobre reduzir o risco e o custo de fazer mudança. E esse é o grande ponto. O Google dá uma boa definição de engenharia de software, para mim, uma das que eu mais gosto, o Google diz que engenharia de software é desenvolvimento de software onde você agrega a variável de tempo. Cara, por que você, eventualmente, faz CICD? Por que você precisa manter código no tempo, você tem que distribuir mais fácil, porque você tem um controle de versão, você tem que manter um histórico dessas versões, porque você faz teste, porque você quer reduzir eventualmente o risco, a proteção contra regressão. E eu vou usar, e o Ezer, vou botar o tal balde com terminologia, não vou me preocupar muito em fazer tradução, mas você tem que ter a vontade para fazer as questões de vocês. Eu vou tratar esse mas cara, na prática é o seguinte toda prática de arquitetura de software toda prática de arquitetura de software que você todo padrão de arquitetura ele visa ajudar você a reduzir o custo e o risco de fazer mudança é um ponto importante, a definição original de dívida técnica, pra quem não sabe ela fala da relação da defasagem entre o que o negócio precisa e o que o software entrega a definição original de dívida técnica, quando foi proposta, falava sobre isso. Tipo, cara, o negócio sempre está precisando de alguma coisa que o software ainda não faz. E essa distância, a proposta é que fosse dívida técnica. Depois, a gente mudou o conceito de dívida técnica para toda vez que um desenvolvedor, eventualmente um time de desenvolvimento, toma a decisão de, eventualmente, sacrificar o que supostamente seria o jeito certo de fazer para conseguir entregar em menos tempo. Então, poxa, a gente quer entregar em menos tempo. Só que, toda vez que a gente reduz, esse é um trade-off importante, importante a arquitetura, é a arte de resolver trade-off, toda decisão de arquitetura tem um lado bom e um lado ruim, se você não sabe qual é o lado ruim de uma decisão arquitetural, você não está preparado para tomar essa decisão ainda. Então, tipo, esse é um ponto importante. Toda decisão arquitetural vai ter um lado ruim, e você está basicamente escolhendo aquele lado que a princípio parece ser o mais favorável. Então, assim, nosso objetivo é reduzir custo e risco de mudança. Mudar software tem que ser mais barato e menos arriscado. Um software com uma boa arquitetura, o que é um software com uma boa arquitetura? Um software com uma boa arquitetura é aquele software que custa menos pra mudar e que é menos arriscado de mudar. Um software que tem uma má arquitetura, vai ser um software que a mudança vai custar muito caro e o risco de mudar é muito alto. Sabe aquele software? Sabe, Wesley, na minha juventude e, menos humilde, melhor dizendo, cara, o meu chefe dizia que o software que eu fazia parecia a versão Kinder Ovo, cada novo lançamento é uma surpresa, tipo, e aí, pô, não é legal isso, a gente quer ter previsibilidade, a gente precisa ter previsibilidade, cara, de muitas formas o trabalho do arquiteto é reduzir custo e risco de mudança, é nisso que vocês são valorados. É legal ter, eventualmente, currículo, é legal ter uma boa formação, é legal ter experiência, mas, cara, o que eu aprendi já há bastante tempo, gente, que o que fala de verdade é resultado. Resultado. E, cara, qual o resultado do teu trabalho? O resultado do teu trabalho, se for bem feito, vai ser um software que é mais barato e menos arriscado de mudar. Esse é o primeiro ponto. A segunda coisa, cara, é como é que você faz, eventualmente, um software ficar mais barato pra mudar, né? Mais barato ou menos arriscado. E aqui, eu tenho esse outro mantra, cara. Eu acho que a gente precisa tornar mais aquilo que é feito todo dia, algo mais barato e mais fácil. Se aquilo que é feito todo dia ficar mais barato e mais fácil, cara, isso vai eventualmente reduzir o custo e o risco de fazer mudança. Então, eu sou obcecado, né? A gente está falando sobre a adoção da inteligência artificial, por exemplo, cara, e eu acho que qualquer coisa que me ajude a fazer aquilo que eu faço todo dia ser um pouco mais fácil e um pouco mais barato, enfaticamente, cara, isso vem para me ajudar. Então, esse ponto é um ponto importante. Você tem que tornar mais fácil, mais barato aquilo que você faz todo dia. É sobre facilidade. E facilidade é diferente de complexidade. Facilidade fala sobre o esforço que você tem que fazer para fazer uma tarefa. Eu vou passando rapidinho aqui, gente, para a gente poder ter mais espaço para discussão. Outro ponto interessante é que, primeiro, cara, provocação. Você sabe que arquitetura de software, essa é uma discussão interessante, porque aí vem outra coisa, eu participo de grupos de discussão sobre arquitetura de software, não só no Brasil, no mundo inteiro há muitos anos, eu acho que talvez a pergunta mais forte sempre de qualquer fórum sobre arquitetura de software é o que é arquitetura de software as pessoas não tem necessariamente um acordo sobre isso, por exemplo eu gosto muito do Uncle Bob, Uncle Bob é um amigo, sabe? Mas, por exemplo, a forma como ele vê a arquitetura de software é diferente da forma como eu vejo a arquitetura de software. E, cara, a gente não precisa necessariamente concordar. Aliás, outro ponto importante sobre liderança, tá? Você tem que aprender a concordar e discordar. Tipo, as pessoas, um time não precisa concordar em tudo, e tem que estar tudo bem. Assim, esse ponto é um ponto importante, você só consegue progredir convivendo com o dissonante, convivendo com aquilo que você não concorda. Mas eu tenho que propor para vocês uma definição de arquitetura, para a gente poder ter uma base, que talvez não esteja totalmente alinhada, inclusive, com a base que o Wesley passa para vocês. Mas eu acho que sim, porque a gente deve estar mais próximo do que afastado. Primeira coisa é a seguinte, cara, é importante lembrar que a arquitetura é sempre sobre design e design nem sempre é sobre arquitetura. A primeira coisa, vamos lá, o que é design, antes de mais nada? Quando você fala sobre design, você está falando sobre três coisas, você está falando sobre componentes, responsabilidades e relacionamentos. Quando você pensa no sistema, como é que você pensa ele em termos de componentes, as responsabilidades desses componentes e como que eles se relacionam, como eles conversam. Sempre que você fala sobre design, design sobre isso. Você pode pensar em design em nível de código. Você pode, agora, o que é o design arquitetural? O que é o design que se converte em arquitetura? O design que se converte em arquitetura é aquele em que, enfaticamente, você vai afetar as tuas condições, vai aplicar as condições, vai aplicar as condições de você atender ou não os objetivos de negócio. Então, por exemplo, cara, você utilizar ou não utilizar repositórios de DDD não é arquitetura. Na minha perspectiva, pelo menos não. Tem um impacto pequeno. Você utilizar ou não utilizar um servidor de cache, isso é arquitetura. Entende? Porque está diretamente relacionado com a sua capacidade de atender ou não os objetivos do negócio. Então, esse ponto é um ponto importante. O nome de uma classe não é arquitetura. Pode ser um concern, pode ser uma preocupação arquitetural, mas não é arquitetura. Agora, eventualmente, se você pensar na organização dos componentes, se você usar, por exemplo, uma BFF ou não, isso é arquitetura. Esse é um ponto importante. Agora, é óbvio que tem uma tremenda área de sobreposição. Cara, deixa eu dizer uma coisa para vocês. Na dúvida, não perde tempo tentando responder o que é arquitetura. Vai e faz um bom trabalho. Esse é o ponto de essência, independente de ser arquitetural ou não. Outro ponto importante, qual é o papel do arquiteto de software? Eu sempre digo que para perguntas difíceis, a resposta sempre depende. Depende muito da realidade da tua organização, depende muito do momento em que você está. As pessoas têm uma certa fixação por cargos, né? Uma vez eu fui nos Estados Unidos, passei uma temporada grande nos Estados Unidos, morava lá do lado da Google, quase, e o que eu mais encontrava na rua eram CTOs, né? CTOs de empresa com duas pessoas, do CTO e do CEO, os dois founders, só tinham os dois caras, né? O cara que era o CTO escrevia o código e fazia, pô, então, o que é o CTO? Eu não dou muita essa fixação de papel do arquiteto, o que o arquiteto faz ou não deixa de fazer, mas tem algumas coisas que eu acho que a gente precisa concordar, tá? Primeira coisa que eu vejo é o seguinte, a primeira coisa, a gente precisa de um arquiteto, né? Pô, minha empresa não tem a função de arquiteto marcar de forma direta, né? Então, pô, tem algumas formações aqui que eu acho que a gente pode considerar, algumas variáveis, e as empresas, os senhores, talvez estejam em uma dessas quatro posições. Primeira posição, cara, o arquiteto, sua posição de ditador benevolente, cara, o arquiteto é o cara que decide e o time executa. E reparem que eu coloquei uma exclamação amarela ali, tá? Essa exclamação amarela não vem dizer que eu discordo necessariamente dessa necessidade de posição. Como desafio, até pra gente poder perceber. Repara, você tá dizendo, você tá falando de um cara que é ditador benevolente e você não discorda disso. Em que cenário vocês acham que o arquiteto precisa ser um ditador benevolente? Pergunta, assim, lancei pro universo, vocês podem responder um de cada vez não precisa ficar nervoso um responde eu acho que eu acho que quando o time é muito inexperiente não tem condições de tomar decisões, a gente acaba tendo que tomar decisões e ser mentor acaba tendo que tomar as decisões e ser mentor, na verdade, ser coach do time, né? Pra eles entenderem também, né, Laird? Esse ponto que você trouxe é exatamente o ponto que eu defendo, tá? Tem cenários em que você tá trabalhando com um time que é absolutamente inexperiente. Gente, assim, a coisa mais ingrata, a coisa mais cruel que você pode fazer com alguém que não tem um nível bom de senioridade é pressionar a pessoa para que a pessoa participe. Tipo, num determinado momento as pessoas precisam de direção e esse é um cenário a ser reconhecido. Então você precisa reconhecer a posição de, cara, preciso ser quem toma a decisão. Você não pode transferir a decisão para quem não tem capacidade de tomar determinada decisão. Isso não é delegação, isso é delargação. E delargação não é exercício de liderança. Então, em determinado cenário, você precisa reconhecer que, poxa, o meu time não tem a senualidade necessária para contribuir com as decisões arquiteturais. Nesse cenário, e somente nesse cenário, eu entendo que o ditador benevolente faz sentido. Mas, Demonti mas Demonte rapaz, que nomezinho complicado Demonte meu nome é Elemar, eu fico falando que o teu nome é complicado eu chamo ele de Dinamite às vezes então vai lá, quem diga a questão que essa questão, essa primeira aí o ditador benevolente, já aconteceu comigo eu trabalhei em uma empresa muito grande certo? e todos os projetos seguiam a mesma arquitetura. Isso seria um ditador benevolente, porque tinha coisas específicas no nosso projeto que a gente queria implementar, só que o pessoal de arquitetura não deixava, porque tinha que seguir o padrão da empresa. Isso eu chamo de arquitetura do Monte Sinai. O cara que vem com uma pedra e diz assim, está aqui a arquitetura, cumpra-se. Não é exatamente isso. Gente, eu entendo, e esse é um ponto importante, eu entendo que alguns cenários de arquitetura de referência faz sentido, quando você tem aplicações que são muito semelhantes, mas no geral a arquitetura de referência é uma ofensa é uma ofensa à efetividade arquitetural de maneira geral existem cenários de defesa antes que vocês venham querer bater em mim mas eu entendo que o ditador benevolente só tem papel se eventualmente se entende que o time não tem condições de contribuir com o arquitetura e essa é a pergunta para ser feita com relação ao teu time, É uma empresa muito grande, muito diversa, então provavelmente ali você tinha pessoas que tinham condições de contribuir e não estavam contribuindo. E isso gera frustração. Um ditador benevolente, um arquiteto ditador benevolente num time que tem condições de contribuir gera frustração. E aí você começa a ter baixas no time. Não e gera frustração. E aí você começa a ter baixas no time. Não é legal. Por isso que eu boto o ponto exclamação, cara. Ditador benevolente é uma coisa de sazonalidade. Até porque, de certa forma, com o tempo o time se desenvolve. E aí fica cruel você não ouvir o time. Esse ponto é um ponto importante. Eu vou chamando as pessoas aqui, Wesley, conforme estão com as mãozinhas levantadas, pra gente dar agilidade aqui. Pode ser? Claro, claro, manda ver. Tá bom. Denis, vai lá, querido. Olá, tudo bem, Neymar? Beleza? Então, eu acho que aí tem muito a ver não só com a senioridade, mas também com a liberdade que você dá para o time. Então, quando você tem um time que aceita mais a liberdade e tem aquela questão de estar progredindo junto, eu acho que você até consegue. E uma questão de arquitetura que a pessoa falou um pouco antes de mim, que eu não consigo lembrar o nome, eu acho que é mais a questão de governança. Então, vamos dizer que a gente que é mais a questão de governança, tá? Então, vamos dizer que a gente tem uma arquitetura de governança pra seguir, algumas ferramentas pra seguir, e com isso você acaba tendo que editar, onde tem alguns times que tem cada uma uma squad, e daí você tem um time que só faz a governança de todas as aplicações. Então, acho que daí seria uma boa ideia, não sei. Aqui, Denis, a primeira coisa que é importante, não sei se está para ler direito o slide aqui, mas assim, não dá para confundir liberdade com libertinagem. Você só dá liberdade para quem tem condições de exercer essa liberdade. Se um time não tem maturidade para receber liberdade, eu entendo esse time com pouca senioridade mesmo, sabe? A senioridade tem a ver com essa capacidade de trabalhar sombriamente livre. Sobre o aspecto de governança que você trouxe para a gente, eu gosto de perceber que quando você faz o design arquitetural, você tem que responder quatro perguntas. Eu avancei aqui os olhos para poder achar essas quatro perguntas a primeira pergunta é, cara, a arquitetura que está sendo proposta, ela atende ou não aos objetivos do negócio? é a primeira questão as demandas do negócio, elas foram satisfeitas sim ou não? a segunda restrição a segunda questão é ela cumpre ou não as restrições o que é restrição? quando você pensa em arquitetura em grandes organizações, existe o conceito de guidelines e guardrails arquiteturais. Cara, guidelines são as recomendações de como você faz. Os guardrails são, cara, você tem liberdade desde que você não trapace esse ponto. Por exemplo, você pode ter uma lista de tecnologias autorizadas e você só pode eventualmente fazer a tua arquitetura levando em consideração aquele conjunto de tecnologias autorizadas. Eu trabalhei, por exemplo, num projeto bastante complexo, onde segurança era o atributo de qualidade mais importante. E, cara, poxa, eu tinha que escolher, eventualmente, lá entre disponibilidade, se eu tivesse que escolher entre disponibilidade no conceito mais simples de segurança, porque um sistema indisponível é um sistema inseguro, mas, enfim, se eu tivesse que tratar de disponibilidade de segurança, eu tivesse que escolher entre as duas, eu teria que optar por segurança. Então, cara, muitas vezes eu acabei sacrificando disponibilidade de segurança, e essa não seria uma decisão minha, tá? Mas era um guardrail imposto pela própria companhia, que no caso era uma organização do governo, né? Com dados ultra sensíveis. Então, esse é o segundo cenário. Então, restrições, atributos de qualidade. E a quarta variável fala sobre achar um jeito mais barato ou menos arriscado de fazer. E aí, cara, eu acho que quando você tem uma empresa que tem um conjunto forte de guidelines e guardrails, cara, isso não é necessariamente ditadura benevolente, cara. Isso aí são restrições que eventualmente o ambiente impõe para você. E, cara, o bom arquiteto é aquele arquiteto que vai fazer uma boa arquitetura mesmo sob restrições. Então, poxa, se o ambiente me impõe restrições, eu tenho que respeitar. Agora, é importante deixar claro que as restrições elas ajudam a moldar a arquitetura, mas não dão a forma da arquitetura. Quando você tem uma arquitetura imposta, daí você não está falando sobre necessariamente impor restrições. Não, você está falando sobre uma arquitetura de referência ou uma arquitetura padrão. Nesse cenário, eu entendo que esse cenário só faz sentido quando você entende eventualmente que o teu time não tem maturidade suficiente para conduzir o processo de arquitetura. Ok? Entendi, obrigado. E só fazer um merchan aí, pessoal. Faço mentoria também Com o Elemar Eu super indico pra vocês aí, tá? Isso aí, galera Agora que eu te conhecia Rapaz Essa telinha do Wesley Tá com tanta gente que você tá pequenininho É, tô até magro, né, cara Rapaz, você afinou, brother É, não que nem o Wesley Assim, né, cara? Rapaz, você afinou, brother! É, não que nem o Wesley assim, né, mas... Um dia chega lá. Obrigado, obrigado pelo feedback, Denis. Assim, obrigado pelo jabá também. Valeu, cara. É nóis. Lembra que eu tenho dois filhos? Então, papai ficou com o papai. Mais fácil, né? Bora lá. Boa. É nóis, cara. Obrigado, querido. Diga, Marlon. Marlon, Marlon. Bom, Marlon. Marlon, beleza. É, eu, a minha dúvida acabou sendo respondida aí pelo questionamento do pessoal anterior, só quero agradecer mesmo e dizer que acompanho teu conteúdo aí também, é um prazer estar aí fazendo parte aí da mentoria. Vou deixar pro Flávio aí a próxima. Hoje o meu objetivo é estourar todos os recordes de tempo desse grupo porque o Wesley falou, vou ficar cinco horas aqui. Enfim, olha e respeita o dono da casa, cadê aqui, né? Mas obrigado, Malon. Diga, o Flávio desistiu, acho, vamos com ela. Desistiu, desistiu. Eu abaixei a mão porque achei isso de chamado então tá bom, então bora lá falando sobre o cenário do ditador benevolente, eu só queria trazer uma experiência eu sempre acreditei muito em autonomia eu acho que o líder é o cara que desenvolve o time, mas eu era muito inexperiente também, tem essa questão a gente é alçado, a gente é um cargo de liderança a gente não sabe cargo de liderança, a gente não sabe liderar, né? Então eu caí num time e eu fui, como agilista e tudo mais, eu caí naquela história vamos autonomia, vamos ajudar a fazer coisas, só que o time não queria isso. Então uma coisa que e essa história do ditador benevolente, olha o André aí também tem a ver com eu acho que também tem um ponto que é o seguinte, o que o time demanda de você sabe? porque às vezes você quer que o time seja uma coisa que ele não tem como ser entendeu? e vai ser todo mundo ficar infeliz né? deixa eu compartilhar com vocês um frame que mudou minha vida aqui, tá? De novo, gente, o tema, o Wesley trouxe essa discussão sobre liderança e arquitetura, tá? Esse framework aqui, gente, foi proposto por um cara chamado Kent Blanchard nos anos 70. É num livro chamado Psicologia para Administradores. E depois o Kent Blanchard ficou famoso escrevendo um outro livro que o pessoal não leva tão a sério, que chama-se Gerente Minuto. Se você tiver acesso... Foi o primeiro livro que o meu chefe me deu quando eu virei gerente. Leio o Gerente Minuto. Exatamente, cara. O Gerente Minuto compartilha esse framework que eu vou compartilhar com vocês, tá? É um livro pra você ler em meia hora, gente, mas assim, que tem um impacto gigantesco. O gerente minuto fala que você deve praticar liderança situacional. Cara, você deve considerar a tua liderança, ela deve estar ajustada à situação. Então, por exemplo, no gerente minuto, ele fala que você tem duas dimensões, uma dimensão de comportamento diretivo e outra dimensão de comportamento de apoio. Cara, e aí ele propõe o seguinte, tá? Você vai ter comportamento diretivo alto e comportamento de apoio baixo, quando eventualmente você está encontrando alguém que não está desenvolvido ainda. Você está encontrando alguém, por exemplo, que está começando na profissão, você está encontrando alguém que é mais júnior. Aquele caso lá que eu apontei para você sobre a gente ter o time que demanda um arquiteto que seja um ditador benevolente. Cara, nesse cenário, você precisa dar direção, ou seja, mais orientação sobre o que fazer e pedir menos opinião. À medida que o time avança e a tendência a esse ciclo, essa onda ao contrário que vocês estão vendo, cara, à medida que o time avança, a princípio ele vai para esse segundo estágio, que seria o S2, que é o nível de orientação. No nível de orientação, o que você faz? Você diz para a pessoa o que tem que ser feito e pede a opinião dela. Segundo nível. Terceiro nível, quando a pessoa, a princípio, mostra qualidade, desempenho, bem, você promove o nível de apoio. No nível de apoio você inverte, tá? O comportamento diretivo é baixo e o comportamento de apoio é alto. Nesse nível, você pede para a pessoa, ou pergunta para a pessoa, como que ela resolveria o problema e você dá opinião. Acontece uma inversão entre o nível 2 e o nível 3. Antes você falava e pedia opinião, agora você deixa a pessoa falar e você deixa ela dar opinião. Quando eventualmente essa pessoa manda muito bem no trabalho, você promove ela ao nível S4. Promove entre aspas aqui, tá? Mas S4 é o nível de delegação. Delegação é o seguinte, cara, é comportamento diretivo baixo de apoio baixo. É aquele cara para quem você passa o problema e assume que se ele pegou aquele problema para resolver, ele vai conseguir resolver. A coisa que gera mais frustração é quando você vai executar a liderança, é quando você eventualmente trata a pessoa por um nível de maturidade que não é ajustado ao nível de maturidade dela. Por exemplo, se você tentar praticar delegação com alguém que é júnior, isso vai gerar frustração nessa pessoa. Por outro lado, se você tentar trabalhar com direção com alguém que eventualmente já está em nível de delegação, essa pessoa também vai ficar frustrada. Então, é importante você ter a sensibilidade de reconhecer qual o nível de maturidade da pessoa que está trabalhando com você e tratar ela de acordo. Ponto importante agora, tá? E outra coisa que também é um erro comum em gestores. O pessoal, às vezes, assume... Tem muito arquiteto que eu chamo de arquiteto bipolar, ou líder bipolar, sabe? A assume, tem muito arquiteto que eu chamo de arquitetura, arquiteto bipolar, ou líder bipolar, sabe, aquele cara que quando está tudo bem, ele trabalha com delegação, aí vai numa reunião, leva um aperto do chefe, deu um bug, alguma coisa, e o cara pula direto a delegação para a direção, né, e aí o cara passa a ser ditatorial, sabe, faz assim, faz assim, faz assim, porque estamos sobre crise, as coisas mais ou menos se resolve, o cara volta para a delegação. Ou seja, ele aperta tudo ou solta tudo. Cara, isso é amadorismo, sabe? Aliás, um ponto importante, gente, executar gestão, tem técnica para gestão com muito mais tempo do que a gente encontra em arquitetura de software. Basta você ter interesse em conhecer as técnicas. Agora, um ponto importante aqui, tá? Como é que funciona quando você precisa, eventualmente, o movimento para desligar alguém, imagina que o Wesley trabalha comigo, o Wesley trabalha comigo, o cara é fera eu trabalho com ele em nível de delegação cara, eu passo o problema para o Wesley o Wesley manda bem pra caramba não é preocupação para mim cara, só que eu dei uma tarefa, temos uma tarefa um trabalho que o Wesley precisa executar e o Wesley não está conseguindo entregar. O que eu deveria fazer? Bom, eu tenho duas opções. Ou eu assumo que o Wesley é um cara muito diferenciado e eu confio que ele está fazendo o máximo, ou eu trago ele para o nível de apoio. Wesley, fala para mim, cara, como é que você está pensando em resolver o problema? Wesley vai dizer, ah, Alemar, estou pensando em fazer isso dessa forma. E aí, eventualmente, eu vou usar com ele, vou dar sugestão, porque eu estou no nível de apoio. Ou seja, ele continua dizendo como é que vai ser feito e eu dou sugestão. Digamos que passe mais um tempo e, cara, a tarefa não está rodando porque, sei lá, o Wesley não está performando, não está conseguindo entregar. Cara, nesse momento eu trago ele para o nível de orientação. Olha só, Wesley, o g assim, assim, assim, dessa, dessa, dessa forma. O que você acha? Cara, repara, eu desci para a orientação. Cara, o Wesley concordou e tudo mais, né? Tipo, está tudo certo, somos bons amigos. Passa mais um tempo, o Wesley continua não entregando. Cara, se o Wesley continuar não entregando, eu desço aqui embaixo para o nível de direção. Wesley Wesley, o bicho tá pegando mesmo, irmão então dessa vez, você deu que as opiniões eram super legais mas cara, não dá, agora vai ser dessa e dessa forma até essa data, feito desse jeito se o Wesley eventualmente continuar entregando, cara, filosofia americana promove o mercado de trabalho só que percebe o seguinte percebe que você faz todo um ciclo de evolução então assim a liderança estacional, ela serve para você acender alguém e também para você perceber que a pessoa parou de funcionar, certo? E aí é sobre ajustar comportamento. Então, olha só, o nível do ditador benevolente, ele funciona geralmente num time que precisa de direção. É um time que está fundamentalmente em direção e orientação. Cara, você não tem dentro do time gente que está com condições de dar orientação e você dar opinião, e muito menos gente que você possa delegar, então nesse cenário, o ditadura benevolente é interessante, agora, diga-se passagem não é sustentável, porque naturalmente as pessoas evoluem para um nível onde elas podem opinar, e você não dá essa autonomia, faz com que as pessoas tenham raiva de você, né, porque isso não é liderança, isso é ditadura, né, lembra, ditador benevolente, você não tem que ser ditadura o tempo todo, né, é um ponto fundamental, mas enfim, não sei se vocês conheciam o Framework de Vida Nascitacional, o Wesley conhecia com certeza, foi o primeiro livro que gerente dele mandou ele ler, gerente minuto e cara, se você não leu, cara você lê em 30 minutos, tá? É um livrinho muito bobo, mas cara, ele é muito bom É, e olha que engraçado Wesley, assim ó, ele foi escrito por Kent Blanchard, né, que é o mesmo autor de Psicologia para Administradores Psicologia para Administradores quase ninguém leu Gerente minuto se transformou num bestseller e ele influencia gestores no mundo inteiro até hoje. Veja a importância de você escrever as coisas de uma forma simples e acessível para ter alcance. Não é sobre escrever da forma mais rebuscada, é escrever da forma mais acessível, lembra disso. Enfim, é o decreto. Diga-lhes. Voltando nessa imagem, estava com uma dúvida, um cenário, e eu queria só ver o só ver se era um ditador benevolente nesse caso. Então, imagina um cenário que é um espaço para as pessoas contribuírem na construção do processo de ideias. Elas vão lançando ideias, elas estão nessa posição de conseguir contribuir, não são tão inexperientes assim, mas por elas conseguirem contribuir e terem experiências diferentes, elas chegam no impasse. Cada um dá uma ideia e essa ideia é um impasse, você não consegue avançar. A pessoa que está direcionando isso como o ditador benevolente, a pergunta é, ele seria um ditador benevolente se ele batesse o martelo numa ideia? Não, vamos seguir por aqui. As duas são boas, mas vou seguir por aqui. Eu geralmente estou tentando utilizar alguns crivos. Baseado nos crivos, a gente pode tomar uma decisão, mas assim, será que a pessoa bateu o martelo? Não. A ideia é essa. Deixei vocês criarem a ideia, mas não saiu do canto, então a ideia vai ser essa. O ditador benevolente é um ditador. Então, tipo, se ele deixa o time contribuir, já não está mais na fase do ditador benevolente. O ditador benevolente, ele apresenta a arquitetura e impõe, em algum cenário, se necessário. Da forma que você está escrevendo, não é, na minha visão, o seguro do ditador benevolente. Mas aqui tem algumas observações importantes, tá? Especialista é alguém que sabe cada vez mais sobre cada vez menos. Você lembra, né, você já desenvolve software há um certo tempo também, cara, início dos anos 2000, como é que você fazia software? Você pegava um analista de sistemas, que ia até o cara do negócio, o cara do negócio dizia quais eram os relatórios e as consultas que ele queria, o analista tomava a nota das consultas e dos relatórios, com base nas consultas e relatórios e fazia um modelo ER para pensar num banco de dados que conseguisse responder aquilo. Cara, com esse modelo ER entregado, esse modelo ER para o time, que passava um tempão fazendo tela de CRUD para poder abastecer as tabelas e daqui a pouco você gerava consulta e relatório. Cara, esses temas eram isso, no início dos anos 2000. Graças a Deus, a gente, por padrão, hoje as coisas são bem mais interessantes do que era naquela época, se espera muito mais da gente, ainda bem. Só que tem um ponto importante, tá? Cara, houve um tempo em que você conseguia dominar desenvolvimento de software de ponta a ponta, aliás, eu montava computador e escrevia software, era uma cura. Cara, hoje em dia, pô, eu vou mexer com front-end, eu sou um cara de back-end, cara você fazer front-end hoje nível alto é tão complexo quanto fazer back-end é óbvio também é muito fácil fazer front-end mal feito, mas enfim, vocês todos aqui são arquitetos vocês estão entendendo qual é o meu desafio então cara, não dá pra uma pessoa só saber sobre tudo e você precisa de gente agora, essas pessoas são especialistas e especialistas são pessoas que sabem cada vez mais sobre cada vez menos. Isso traz para mim o que eu entendo que é papel do arquiteto. O arquiteto é, acima de tudo, um orquestrador. O arquiteto é aquela pessoa que traz as pessoas para a discussão. Tem um slide meu, inclusive, em que eu falo sobre isso, mas eu falo o seguinte, eu digo que o arquiteto, ele não tem que... O arquiteto, não cabe o arquiteto decidir, mas cabe garantir que a decisão seja tomada. Não cabe o arquiteto documentar, mas garantir que seja documentado. Não cabe impor a respeito a arquitetura, mas garantir que a arquitetura seja respeitada. Sabe, tipo, ele não precisa ser o cara que é o ator, mas ele garante que a coisa aconteça. E tem um ponto, só que é o seguinte, tá? Cara, se o cara vai ser responsabilizado pelo problema, ele tem que ter a prerrogativa de decidir o caminho. Repara, se na minha empresa, eu sou arquiteto, e cara, cada lugar é um lugar nisso, tá? Se na minha empresa problemas de arquitetura são responsabilidade e consequentemente culpa do arquiteto, se o Thiago falha, o arquiteto tem que ter a última palavra. Volta de Minerva. Agora, de novo, é curto caminho longo e longo caminho curto. Se você adotar por prática fazer imposição de regra, você não vai ser um bom arquiteto. Dificilmente você vai conseguir fazer a coisa funcionar. Desenvolver software é cada vez mais difícil, gente. Eu trabalhei, vou falar de três projetos meus. Na época que eu estava ainda em time escrevendo código para a produção, eu fiz um otimizador de plano de corte, eu trabalhei no projeto de banco de dados, e eu trabalhei no projeto de banco de dados e eu trabalhei no RavenDB, ajudei a fazer o RavenDB e eu ajudei no compilador de C Sharp três projetos por base em que eu atuei cara, em todos os projetos os arquitetos não tinham domínio pra poder dar a solução sempre, entendeu mas, de novo poxa eventualmente você tem que dizer poder dar a solução sempre, entendeu? Mas, de novo, eventualmente você tem que dizer, cara, pondera para isso. Deixa eu dar um exemplo prático para pegar esse exemplo alta questão do orquestrador, tá? Precisa de um papel do arquiteto como orquestrador. Eu estava atendendo um cliente uma vez que estava de um grande varejista e os caras estavam em passe danado. Parte do time queria fazer o front-end com o Angular. Parte do time queria fazer com o React. E tinha um cidadão isolado que queria fazer com o Vue. Cara, estava lá um gestor e ele estava com uma data-muro ferrada e tinha que fazer tomar a decisão de fazer a coisa avançar. E o time estava com dois sectos, um secto do React, um secto do Angular e tinha o cara sozinho do Vue. E aí, pô, eu cheguei lá e eu precisava falar muito com aquele gestor. Eu disse, cara, eu vou ter que atuar como arquiteto, ter que, tipo, super poder de arquiteto ativar. E aí eu fui lá falar com os caras. Aí eu perguntei, queridões, seguinte, Se eventualmente nós optarmos por Angular, tem alguma coisa do que o negócio precisa que não vai ser atendida se nós optarmos por Angular? Meu amigo do React. O cara, não, vai ficar mais difícil. Não, não, a pergunta não vai ficar mais difícil. A pergunta é, tem alguma coisa que o negócio pede que a gente não consegue entregar com Angular? Não. Tá bom, muito bom. Essa é muito boa. Vamos para a segunda. Angular tá na lista de, tem alguma restrição que nos impõe? Não, não, então tá bom. Enquanto isso, o cara do outro lado, o cara do Angular dando risadinha, mas, calma, virei pro cara do Angular assim, cara, e aí, meu amigo do Angular, tem alguma coisa que você vê que não dá pra fazer por causa que você react, e ele quis argumentar, ó, véio, né, não, né, vamos sério. Ah, não, tá, mas vai ser, tem algum desrespeito, alguma restrição? Não, não. Vai ser mais caro? É muito questionável isso, tá, tá bom. Eu perguntei, qual dos dois, daí o cara do Viu e eu não vou falar assim, cara, você tá sozinho, velho infelizmente não deu, vamos ficar nesse ponto aqui aí eu perguntei, vamos lá, qual dos dois times, qual dos dois vai ser líder dessa iniciativa? daí o cara do React fez a mão, levantou a mão assim, ah, vai ser eu, daí eu perguntei pro cara do concorda que como ele vai ter que fazer a entrega e como você não vê restrição nenhuma pra ser React é só coisa de preferência não é coisa você não conseguiu sustentar como diferença o cara concorda, então vamos dar o sagrado direito do cara que vai implementar a tecnologia que ele quer porque você não conseguiu bater contra o cara, é cara, argumentação, soft skills esse é o grande ponto, você precisa eventualmente questionar as pessoas, e cara, quais são as quatro perguntas? Quatro perguntas, e assim, soft skills para arquiteto é quatro perguntas, atende os objetivos do negócio? Ah, atende, respeita as nossas restrições, restrições de arquitetura? Ah, respeita, tá, vai ofender os nossos atributos de qualidade? A gente vai conseguir entregar? Vai. Tá, então, tem um jeito mais barato ou menos arriscado? Ah, não posso dizer que nem mais barato ou menos arriscado. Então, tá bom, cara. Então, é uma solução candidata viável. E aí a gente registra a decisão e avança. Porque deixa eu dizer uma coisa Ou seja, gente, ansiedade é excesso de futuro. Toda vez que você, como arquiteto, não faz com que o time decida, tem a coisa de você postergar para o último muito responsável. Mas entenda que toda decisão que você não toma gera excesso de futuro. E excesso de futuro gera time ansioso. E time ansioso procrastina. O que eu encontro de caras que ficam anos tentando fazer a arquitetura perfeita que não para de pé e não sai nada. Os caras não entregam nada, porque fica aquela loucura de tentar achar o melhor jeito e o cara nem terminou de fazer a primeira entrega e começa de novo. Cara, ansiedade, assim, depressão é excesso de passado. O cara que só fala do passado é deprimido. O cara que só fala do passado é deprimido. O cara que só fala de futuro é ansioso. Todo ansioso é procrastinador. Todo ansioso é procrastinador. E como é que você combate a ansiedade? Tomando decisão para diminuir o futuro. Como é que o arquiteto contribui com o time, reduzindo o custo e o risco de fazer mudança? Garantindo que decisões sejam tomadas. garantindo que decisões sejam tomadas, sim, no último momento responsável, mas não mais do que isso, tá? A gente precisa ter aquele efeito horizonte, sabe? Não sei se você joga um xadrez com o computador, mas você sempre pode forçar o computador a fazer a melhor jogada daquele momento. E tem garantia de que é a melhor jogada? Não, mas naquele momento é efeito horizonte, naquele momento é a melhor jogada, sabe? Então, por exemplo, um arquiteto sempre tem que ter a capacidade de responder, cara, qual vai ser, por exemplo, o banco de dados que nós vamos usar? Cara, baseado nas informações que eu tenho, se eu tiver que decidir agora, seria esse. Mas a gente ainda pode decidir um pouco mais tarde, então eu vou postergar a decisão. Mas você sempre tem que ter a tua solução candidata. Se você apresentar a solução candidata, você diminui a ansiedade do time. Esse é um ponto importante. De novo, time ansioso é time que procrastina. E time que procrastina não entrega. E aí, é o contrário de reduzir custo e risco de mudança. Enfim, diga, Fernando, esse gotcha aí é Game of Thrones? Não, é inicial do meu nome. É o... Vamos olhá-lo na penteadeira, na verdade. E vamos lá. Você já falou uma parte, acho que foi mais ou menos esse diálogo que você teve com esse time aí, mas eu vi, eu passo por isso, acho que eu vi muita gente comentando aí também, que é aquela coisa, o arquiteto decidiu isso. No meu caso, normalmente é o chefe, o gerente, o CTO, o CEO, decidiu alguma coisa. Mas como é que fica essa questão de, tudo bem, o arquiteto tomou a melhor decisão, às vezes nem cabe a mim questionar isso, mas não teria que ter uma comunicação, não faria parte do papel do arquiteto explicar o porquê daquela decisão para o time, porque uma coisa é você falar, por exemplo, nós vamos usar esse banco. Outra coisa é você chegar e falar, nós vamos usar esse banco por esse motivo. Às vezes ninguém nem perguntou, mas a gente vai usar por esse motivo, tanto para o pessoal já saber, tanto para já educando o pessoal, para o pessoal ter esse conhecimento pro futuro. Sim. Deixa eu te mostrar um exemplo aqui, tá? Deixa eu te falar uma coisa, só pra poder te apoiar com a fala. Cara, quando você fala sobre documentação arquitetural, eu digo o seguinte, cara, documentação mais código tem que custar mais barato que só código. Lembra que o nosso objetivo é reduzir custo e risco de mudança? Então, cara, documentação boa é aquela que reduz o custo do projeto. Se a documentação está aumentando o custo do projeto, você está fazendo a documentação errada. De todas as documentações que eu considero essenciais para a arquitetura, cara, para mim, a mais essencial se chama Architecture Decision Record. O que é o Architecture Decision Record? É um documentozinho simples que basicamente expõe cara, qual é a decisão? Cara, a decisão é essa. Qual é o contexto dessa decisão? Qual foi a decisão? Quais foram as alternativas consideradas? Quais são as consequências positivas e negativas? E, eventualmente, algum tipo de atualização. Toda decisão arquitetural, Fernando, esse é um ponto importante que você trouxe para mim, eu acho que é interessante a gente destacar aqui, tá? Toda decisão arquitetural tem um lado bom e um lado ruim. Você sempre tem um ônus e um bônus de qualquer decisão que você tome com relação à arquitetura. Então, não cabe somente ao arquiteto a responsabilidade de garantir que as decisões sejam tomadas, mas elas precisam ser justificadas. E essa justificativa de decis que a decisão precisa ser documentada. Por quê? Porque em algum tempo no futuro, cara, alguém vai questionar por que aquilo foi feito daquele jeito. E esse é um ponto crítico no projeto. Por quê? Porque, cara, se você não tem um registro do porquê que a decisão foi aquela e daquele jeito, quem vai tomar uma nova decisão para potencialmente mudar, tem dois caminhos a seguir. Ou ele muda sem entender quais são as consequências, isso aumenta o risco, ou ele deixa como está, por medo de quebrar alguma coisa. E isso aumenta o custo, deixa o time parado. Então, de todas as documentações de arquitetura, a mais fundamental acaba sendo a ADR, para que você tenha esse ponto tratado. Qual é a utilidade no arquiteto na discussão da arquitetura? É você garantir que as decisões sejam pautadas, sejam justificadas em algo que vai além da preferência. Cara, a solução que você está propondo como design, ela tem que atender os objetivos do negócio, tem que respeitar as restrições e ao encontro os atributos de qualidade e principalmente ser demonstrada como a mais barata e a menos arriscada. Você precisa conseguir argumentar dessa forma. Senão, você está usando preferência. E a arquitetura baseada em preferência daí não é arquitetura. Cara, se você quer fazer as coisas da forma como você faz, você faz em casa. Especificamente quando você atende para um negócio como um profissional, se você é um arquiteto profissional e não um amador remunerado, porque também tem isso, né? O cara pode se enxergar como profissional, mas na prática é só ser um amador sendo pago. Se você é profissional de verdade, cara, você passa a entender que você tem que ter critérios para tomar a decisão e o teu papel como arquiteto é isso. Então você explicita isso. E esse passa a ser um outro ponto importante também, Fernando, porque assim, eu tenho que admitir num cenário, eventualmente até onde eu entendo que para mim é o melhor, que é do primeiro entre os iguais, para mim o arquiteto é membro do time, não é acima do time, não é chefe necessariamente, não tem posição de gestão, ele tem posição de liderança sim, mas liderança de pares. Cara, para você poder executar bem esse papel, você precisa justificar as decisões. E esse é um grande ponto, que eu vejo que é motivo de falha de boa parte das soluções que eu vou encontrar no mercado que estão em problema. As decisões foram tomadas, mas não foram justificadas. Talvez até houvesse ali uma boa justificativa no passado, mas, cara, é desconhecido de todo mundo, então não funciona. Até porque, assim, a escala destrói sonhos. A medida... Assim, não existe arquitetura que você vá conseguir planejar que vai resistir ao tempo, à medida que você tiver mudanças de escala. Seja quantidade de usuários, seja, eventualmente, quantidade de processamento. Cara, a escala destrói sonhos. Então, a escala destrói sonhos, então a arquitetura que você planejou lindamente agora, vai ser destruída com a escala, e sobre a escala você vai ter que conseguir mudar ela e de uma forma barata, e de uma forma menos arriscada, sabe? Então, cara se você não tiver boas decisões pra peitar a tua visão senão você vira o cara que vai clonar o Netflix ah, por que você faz isso? Porque o Netflix faz deixa eu dizer, querido, assim em 2018, que foi quando o Netflix ainda publicava os números deles eles tinham um milhão de requests por segundo cara, eu conheço aplicação que não tem um milhão de requests em todo seu ciclo de vida quanto mais por segundo, tá ligado? então eu digo, nossa nós fizemos o nosso próprio sistema de log. Por quê? Porque o Netflix também fez. Cara, tu não é o Netflix, querido. Pelo amor de Deus. Tu não tem essa escala. Mas enfim, Fernando, é só pra trazer pra... Ela tem que ser justificada, entendeu? O Wesley sempre dá... O Wesley sempre dá o exemplo do Kafka, né? Porque usar o Kafka e não uma outra fila. É... Se pelo menos as pessoas que propusessem Kafka soubessem... Justificar? É a mesma coisa que em .NET, para quem é de .NET, a galera tem uma fixação em mediator, mediator e CQRS, eu não sei de onde vem essa coisa de todo mundo querer usar CQRS e mediator. Quando você adiciona complexidade, assim, complexidade necessária, é sempre custo. Quando você adiciona complexidade no teu projeto, irmão, você está adicionando custo. E se esse custo não é justificado, você está fazendo um péssimo trabalho como arquiteto. E aqui eu estou falando sem filtro, sabe gente? Assim, arquitetura baseada em preferência é algo que só funciona quando você faz o seu próprio projeto em casa, na sua empresa. Só que aí você não faz, porque aí você vai quebrar se você só atuar naquilo que você acha que é mais bonito, né? Você tem que fazer aquilo que é certo. De novo, uma dívida técnica, só dívida técnica se cobra juros, gente. Assim, tal coisa é uma dívida técnica o que é cobrar juros, cara? como que essa dívida, dívida técnica vai contribuir para aumentar o custo e risco do projeto? ah, não consigo apontar então, cara, não é essa dívida técnica é um ego ferido do arquiteto ou do time e o arquiteto não é só o papel dele anotar eu entendo que ele tem que ser, tipo, um evangelista. Então, além de anotar, explicar também, né? Ir lá pra frente e explicar pra todo mundo o porquê daquela. Não é só tá lá anotado, se alguém quiser, vai lá e checa, né? E esse é o grande ponto, né, cara? Até porque, assim, a habilidade de tratar com o time, soft skills, eles são são fundamentais. Cara, o arquiteto precisa gostar de gente. Aliás, cara, é difícil você liderar sem gostar de gente. E tem dias que é difícil. Gostar de gente é difícil. Mas eu falo sempre o seguinte, alguém aqui é do Rio Grande do Sul? Bom, eu vou dar um ponto. O Eliverto é do Rio Grande do Sul. Eliverto, você já fez uma viagem de Porto Alegre até Florianópolis, não? De carro? De Caxias, inclusive, onde você está aí. Sou conterrâneo aí. Olha que maravilha. Devemos tomar uma sopa de aeolino em qualquer hora dessa. Bora, bora. Eu morei 20 anos em Caxias. De Caxias a Floripa. Se eu perguntasse para você, Liberto, como é que era ir de carro de Caxias até Floripa, no início dos anos 2000. Você tem esse legítimo? Nossa, era uma tragédia, uma epopeia, né? Uma epopeia, porque você não sabia onde é que você ia parar, onde é que você ia cruzar, onde é que ia ter barreira na 101, era horrível. Muito caminhão. Muito caminhão, não estava duplicada. Quando chegaram lá, todo mundo parava tudo, porque a ponte era travada certo? agora me fala como é de Caxias a Floripa hoje? 5h bem tranquilo, parando algumas vezes isso, como é que é ali em Laguna? a ponte tranquilo, é só cruzar e agora tem uma ponte estalhada lá, certo? pessoal, quero trazer, isso aqui é um ponto importante pra você estar aqui e Fernando, responde diretamente o que você está pedindo cara, muitas vezes, a gente... Se eu conversasse com o Eliverto, o Eliverto, por alguma razão, foi morar na China e ficou muitos anos sem voltar pra cá. Eu disse assim, Eliverto, vamos pra Floripa? O Eliverto ia dizer pra mim assim, bah, cara, não quero ir. Porque a memória dele é de 20 anos atrás. Entende? Cara, como é que eu faço pra eventualmente o Oliverto querer viajar comigo? Cara, eu tenho que botar ele no carro e ir junto com ele. Certo? E, cara, eu tenho que inventar uma história pra convencer que vale a pena. E vai ser difícil, tá? Cara, quando alguém não concorda com você e não tem uma justificativa razoável, às vezes não é porque a pessoa não é mais inteligente ou porque a pessoa não é tão capaz quanto você é. Isso é de uma arrogância inacreditável. Às vezes é só estar com o mapa desatualizado. Como alegoria, entende? Cara, tem muita gente, por exemplo, quando você pega alguém que seja de old school, por exemplo, você vai falar para ele sobre alguma coisa nova, você encontra, às vezes, dentro do time, gente com resistência ao novo. E aí, cara, você pensa, pô, mas esse cara não pode ser, esse cara não estuda, não se atualiza, ele não é comprometido. Não, cara. Ele só tá com o mapa desatualizado. Você, como arquiteto, nem como arquiteto, você como liderança técnica, melhor, você como líder, melhor, você como ser humano, cara, você deveria se comprometer a ajudar as pessoas a atualizarem o mapa delas, né? Cara, se alguém não tá vendo uma coisa que é óbvia que você tá vendo, é porque provavelmente o mapa dela tá desatualizado, irmão. E aí você precisa trabalhar pra atualizar o mapa das pessoas. Assim, e tem um ponto importante, esse ponto precisa ser dito para vocês. O difícil, gente, está associado ao esforço. Tudo aquilo que eu tenho que fazer muito esforço é difícil. E tudo aquilo que é difícil eu resisto. Eu tenho resistência. Eu não quero fazer. Certo? Então, a dificuldade vem da falta do tamanho do esforço. E a dificuldade está muitas vezes associada com a pouca familiaridade. Tudo aquilo que não é familiar parece mais difícil. A dificuldade vai embora quando a familiaridade chega. Como é que você faz para baixar a resistência do time frente ao novo? Frente, por exemplo, à inteligência artificial? Frente a um framework mais moderno? Vocês estão aprendendo uma pancada de coisas com o Ezio aqui. Como é que você faz para reduzir a resistência do time? Cara, você precisa trabalhar na familiaridade das pessoas. E mais do que trabalhar a familiaridade, você precisa facilitar as primeiras incursões. Porque o ser humano, e isso é natural, todo mundo faz a mesma coisa aqui, tá? Sempre que você encontra uma coisa que é nova, cara, você tem dois caminhos comuns, tá? Ou você foge, evita falar sobre o assunto, ou você fala mal. Tem uma galera, quantas pessoas, Wesley, ficam dizendo que, ah, porque a IA escreve código muito mal, claro, o problema não é do cara que está pilotando a IA, né? O problema não é do piloto, o problema é a IA. Cara, sabe o que é isso? Isso é um atestado de falta de familiaridade. Cara, é natural, é humano demasiado humano. Se você não entender essa característica, você não vai conseguir virar o teu time e fazer nada que seja relevante. Você precisa aprender a atualizar o mapa das pessoas. E o engraçado é que pra algumas coisas o mapa vai estar atualizado, pra outras não. O arquiteto precisa ter essa sensibilidade. Quando você escreve, quando você justifica, você precisa ter esse ponto como referência. Faz sentido, Fernando? Obrigado. Só pedi para você depois passar o link para a gente, esses links que você está... A galera botou aí no chat, tá, Fernando? Botou? Obrigado. Está no chat. Segue a bola aí, Elemar. Segue a bola aí para a gente... para a gente mandar ver. Taque o pau. Não, beleza. Então, gente, assim, então, gente, assim, as outras três formações, tá? A primeira, cara, é o arquiteto como sendo membro do time, é o que eu mais gosto, tá? Aliás, eu sempre uso outra analogia aqui, né, Wesley, você tem dois tipos de arquiteto na alegoria do café da manhã, né? Tem o arquiteto porquinho e o arquiteto galinha. Sabe a diferença entre o arquiteto porquinho e o arquiteto galinha, Wesley? Um faz parte do processo skin in the game e o outro só produz ali, né? O arquiteto galinha, cara. O arquiteto galinha é aquele bicho que vem... Não sei se você já viu uma galinha pondo ovo, gente. É um processo sofrido. Olha o tamanho da galinha, olha o tamanho do ovo. Se você ver uma galinha pondo o ovo, você vai ver que o bicho faz uma gritaria, faz um... Cara, eu nunca na vida imaginei que eu ia ficar imitando galinha. Enfim, é um sofrimento. Mas depois que pôs o ovo, a galinha vai embora. Então, a contribuição da galinha é sofrida, mas ela termina e vai embora. Cara, o arquiteto porquinho, ele fornece o bacon. Cara, ele frita junto. Assim, de maneira geral, cara, se você quer fazer boa arquitetura, é bom ser arquiteto porquinho, arquiteto que frita junto. Ser arquiteto galinha, aquele cara que vem, sabe aquele... Eu brinco, Wesley, que é porque o pessoal... A pomba com lordose, sabe? Pês-to que é ir pro sol com a pomba com lordose, sabe? Peito estufado e bumbum pra trás. O cara chega no quadro e começa a desenhar. Não, porque tal, tal, tal, tal, tal, tal, tal, tal, bota quatro cá, fica aquela coisa toda e vai embora e agora tá com vocês. Se não der certo, é vocês que conseguiram a arquitetura. O galinho, né? Tipo, eu gosto do arquiteto no time, ele precisa ser o primeiro entre os iguais, né, tipo, como referência, né, eu acho que é uma segunda formação. A terceira, cara, acontece quando eventualmente a arquitetura é feita pelos membros do time. Eu vou dizer um exemplo pra vocês, tá, cara? A Red Hat é uma empresa que se destaca sempre por ter times com uma base técnica muito sólida e eles não têm a posição da arquitetura. Eu tenho o Portieri, que trabalhava até outro dia lá, a gente falava sobre arquitetura, e ele dizia, pá, Alemario, eu não acredito na figura do arquiteto. Eu, cara, pô, com um time que nem o teu, assim, eu até entendo. Dá tudo certo, realmente. Quando você tem um time que de todo mundo é monstro e que os caras têm um nível de maturidade gigantesco pra trabalhar junto até funciona eu acredito nisso o problema, cara, é que é a mesma coisa que jogo de vôlei quando o cara joga a bola no meio de dois jogadores quando o cara joga a bola no meio de dois jogadores um deixa pro outro e ninguém faz eu digo sempre que cara, quando a responsabilidade de todos é a de ninguém veja, por exemplo, o caso dos banheiros públicos todo mundo teve que cuidar, mas ninguém cuida então, tipo, é perigoso quando você pega uma coisa que é tão importante e você relega ela pra todo mundo é meio perigoso, mas enfim eu entendo que existem cenários em que isso é viável também e finalmente, cara, tem a ideia da arquitetura implícita e essa ideia da arquitetura implícita é o problema, que é esse cenário daquela arquitetura que vai sendo sabe, arquitetura, eu chamo arquitetura implícita, da arquitetura zaga apagadinho, sabe aquela, deixa a vida me levar, a vida leva eu, sabe você vai avançando, a medida que você vai fazendo você vai puxando aqui de um lado pro outro, a tendência é que com o tempo você vai ter um aumento de custo e um aumento de risco no teu projeto só aumentando, se por acaso você está vendo essa situação, vai no teu repositório e pede no Git lá a quantidade de commits. Eu sei que a quantidade de commits não revela necessariamente a quantidade de trabalho, mas pega a quantidade de commits mês a mês e pega a folha do pessoal e divide para a quantidade de commits. Você vai perceber que se não tem uma arquitetura bem feita, um trabalho de arquitetura bem feito sendo feito, cara, o custo do comitê só aumenta. Todo mês fica mais caro. Todo mês você vai ver, cara, o comitê agora está mais caro. Tipo, o salário da galera está aumentando, tem mais gente, e cara, o custo de comitê não está aumentando, às vezes até está diminuindo. Esse ponto é importante. A gente precisa ser sustentado em fato. Eu vou dar um exemplo prático pra vocês, tá? Eu gosto de arquitetura quantitativa. O que é arquitetura quantitativa? Vou dar um número interessante aqui pra vocês, tá? 5% dos arquivos que vocês têm no repositório de vocês, recebem mais de 90% das modificações. Não é nem pareto, tá? É 5% dos arquivos recebem mais de 90% das modificações. Cara, teste de unidade tem importância pra todo projeto. Mas segur tem importância para todo projeto, mas seguramente tem mais importância nesse 5% que recebe 90% das modificações. Certo? Então, cara, 5% do teu projeto recebe 90% das modificações e, cara, isso é uma coisa que você tem que considerar. Se você não considerar isso, cara, você não está fazendo um bom trabalho de arquitetura, porque, cara, onde é que você tem que colocar ênfase? Outro ponto interessante, tá? Estuda Microsoft Quanto mais autores, quanto mais pessoas mexem num arquivo, maiores são as chances de aquele arquivo ter um código que vai gerar bug em produção. Qual dos arquivos dos repositórios dos senhores tem o maior número de contribuidores? Agora, imagina se aqueles que têm o maior número de contribuidores também são aqueles mais modificados. Aí você tem certeza de problema em produção. Onde é que a arquitetura trabalha com isso? Primeiro você vai entender o seguinte. O grande vilão da arquitetura, a razão por trás de todo bom padrão de design é o tal do acoplamento. Cara, o arquiteto é um cara que vai buscar soluções pra reduzir acoplamento, né, sobre redução de acoplamento o tempo inteiro. Mas enfim, senhores, esse é um ponto importante, né, e de novo, são responsabilidades do arquiteto que garantir que as decisões sejam tomadas que elas sejam justificadas que elas sejam lembradas, que elas sejam respeitadas mas repara, é garantir que não é tomar as decisões não é justificar as decisões, não é lembrar as decisões, não é necessariamente respeitar a forma como você vai fazer isso vai depender do cenário da empresa onde você está trabalhando ponto importante lei de Conway, vocês conhecem a lei de Conway, certo? A lei de Conway é isso para a gente é o seguinte, é quando a estrutura de uma empresa que desenvolve o sistema, uma organização que desenvolve o sistema vai replicar na arquitetura do sistema a estrutura de comunicação da empresa. Cara, você não consegue fazer um sistema baseado em micro-serviços numa empresa que tenha um time monolítico. Não dá pra fazer. Você tentar fazer um projeto de uma arquitetura baseada em micro-serviços com um time que é monolítico, vai implicar em você ter um monolitão distribuído. E aí, pesadelo. Né? Pesadelo. Cara, então, por exemplo, se o arquiteto não tem influência sobre a organização dos times, é bem provável que ele fica restrito, e a restrição quanto às opções de design que ele pode utilizar. Se eu estou trabalhando com um time que é um monolitão distribuído, ou, eventualmente, um time monolítico, cara, você não tem como fazer micro serviço, não tem como. Então, você precisa eventualmente desenvolver a habilidade de conversar com as tuas lideranças para poder fazer as suas decisões. E como é que você convence a liderança? Senhores, não tem atalho. É falando sobre custo e risco. Porque assim, é custo e risco. Porque é o seguinte, senhores, olha só, existe uma coisa importante, Wesley, que eu falo sempre que é a seguinte, é custo de oportunidade. O que é custo de oportunidade? O que você está deixando de fazer para fazer o que você está deixando de fazer para fazer o que você está fazendo agora. Então, se eu vou tomar uma decisão, por exemplo, uma decisão arquitetural, cara, o que é o custo de oportunidade? O que eu estou deixando de fazer para fazer as coisas do jeito que a gente está fazendo agora? Cara, eventualmente isso inviabiliza as suas decisões. Se você não conseguir mostrar economicamente que a tua decisão supera a oportunidade, o custo da oportunidade, cara, a tua solução não para de pé. A não ser justifica, não vai avançar. E aí o pessoal fala, poxa, mas Leymar, eu tenho que fazer refactoring arquitetural versus eventualmente introduzir feature, que é aquela demanda, nossa, vai na empresa, o pessoal não deixa de fazer ajuste de arquitetura, é só feature, feature, feature, feature. Por quê, cara? Porque o pessoal de negócio compara. Quanto que isso aqui vai mexer no meu ponteiro? Esse efeito arquitetural, quanto que ele vai ajudar a mexer no meu ponteiro? Ou a gastar menos ou ganhar mais? Cara, se eventualmente você não conseguir colocar em termos de custo e risco, você vai perder sempre para o cara de negócio. E bem feito para você, porque você não está fazendo bem o seu trabalho. De novo, isso aqui é mentoria, tá? Tipo, se você quer eventualmente ter sucesso, você tem que ter habilidade para falar com o time de negócio e também com o time técnico. E aí você vai entender que essas são as responsabilidades do arquiteto. Mais um ponto importante, tá gente? Você tem cenários de vida de arquitetura, você tem momentos... E arquitetura, por definição, é um processo de descoberta. É PDCA. PDCA é quando você está inovando, enquanto você está fazendo alguma coisa nova. É SDCA quando eventualmente você está em estágio de manutenção. quando eventualmente você está em estágio de manutenção. São dois momentos, cara. Hora de fazer coisa nova, hora de fazer eventualmente manutenção. A atuação do arquiteto muda. Aqui, você está achando formas de atender as demandas de negócio. Aqui, você está reduzindo o custo. E, cara, o arquiteto é obcecado. Um arquiteto é obcecado em fazer soluções que reduzem em custo. Poxa, esse é um ponto importante. Ah, cara, eu vou melhorar toda vez que você não presta atenção no código, você paga na lata. Gosto dessas frases, né? Toda vez que você não presta atenção no código, você paga na lata. Ah, ele é mais, o que é pagar na lata? Pagar na lata, tá bom, Elemar, mas então nós vamos fazer o refactoring e a gente vai baixar o custo da lata, tá bom. O custo de fazer o refactoring é maior do que a economia na lata? Não, então como é que você justifica? Lembra, em última instância, é sobre redução de custo e de risco. Cara, se a tua solução não tem custo e risco mais baixo, a gente precisa entender sobre o custo e o risco das decisões que a gente toma. Porque senão, de novo, a gente está tomando preferência baseada em alguma coisa, mas não o que defende o negócio. Não é fácil, né? E exatamente por não ser fácil, eu digo, cara, as habilidades do arquiteto às vezes... Por isso que eu ficava até um ano atrás, um pé atrás, quanto o arquiteto, que dizia, pô, o arquiteto tem que programar o tempo todo. Eu, cara, se você codar o tempo inteiro, poxa, como é que tu vai fazer, vai cumprir as tuas responsabilidades de garantir que as decisões sejam tomadas, documentadas, justificadas, respeitadas, falar sobre custo e risco,, alguma coisa você vai deixar de fazer. Provavelmente você vai deixar de fazer o teu trabalho de arquiteto. Aí você vai ser um excelente líder técnico, mas, sei lá, ser líder técnico, às vezes você vira escravo do próprio time. Porque eu encontro de gente que assume a responsabilidade de fazer uma implementação que era pro time fazer, mas que o time não consegue, e aí você encontra o cara na sexta-feira saindo de uma última reunião exaurida e o time cobrando, ó chefe, ou chefe, ou se você for gestor, ou líder, enfim, alguma coisa. Cara, pô, aquele negócio que você ficou de fazer e você não fez, não se travou essa semana. Você tem como entregar isso na segunda-feira? E aí o time vai passar o final de semana, durante... Aqui é o famoso, né? Tipo, eu vou trabalhar no sábado porque da semana não consigo trabalhar, fico só em reunião. Pois é. Né? E se você acha isso normal, cara, isso mostra que você não tá olhando bem o teu trabalho, você não tá entendendo bem suas responsabilidades. Mas, cara, tem uma coisa que mudou, tá? Com o advento da IA, né? Tipo, ficou mais fácil provar conceito ficou mais fácil escrever código ficou mais fácil, então por exemplo na nova versão da minha mentoria eu já volto a dizer que cara, o arquiteto volta a trabalhar com código sim volta a trabalhar com código sim sem sombra de dúvidas, porque cara, nós estamos vivendo um movimento que pede isso cara, uma das minhas grandes frustrações às vezes era ter que explicar pro povo lá o que tinha que ser feito dois dias depois de uma implementação não gostar do que eu vi pedir uma alteração e o povo ainda ficar magoado cara, como a minha vida fica mais fácil pedindo uma implementação para um modelo de A que me entrega em alguns segundos eu não gosto, peço para ela fazer de novo e ela nem fica magoada olha que loucura e não é só isso inclusive o Lemar quando você mostrou tava falando de ADRs cara, eu tava trabalhando tenho trabalhado nisso faz 3 meses organizando toda a parte da IA com ADRs peguei aquele software mas software, o cara fez o shell script baseado nas ADRs e vários modelos de ADR e vários modelos de ADR e tudo mais e quando a gente fala em arquitetura e o que o arquiteto tem que fazer, você sempre coloca muito ali no garantir eu penso muito também, e acaba sendo eventualmente quase que a mesma coisa reenforçar que aquelas coisas sejam cumpridas. Hoje, com o IA, isso acaba ficando até um pouco, um pouco não, muito mais fácil. Eu consigo pegar uma DR e falar assim, olha, baseado nessa DR, tem alguma coisa nesse software, nesse módulo, nesse tipo de componente que não está seguindo essas diretrizes? O que está acontecendo nesse momento no meu software que baseado na documentação que eu tenho, há uma discrepancia grande. Esses tipos de coisa mudou o jogo completamente, inclusive para manter a documentação cada vez mais viva, porque a documentação é aquela coisa que todo mundo sofre pra fazer, ninguém gosta de fazer e quando precisa mudar, tá sempre desatualizada. Com a IA do jeito que tá hoje, cara, ela vira algo fundamental pra um, o mapa sempre tá atualizado independente de quem tá chegando no time. Esse mapa é mais fácil de ser atualizado do que antes e o mapa fica mais bonito ainda, porque hoje em dia a Iala acaba escrevendo muito melhor ainda que a gente. Então, o papel do arquiteto, do desenvolvedor, agora com a história de Iala, assim, muda completamente. Porque antes, quando eu via, e eu pensava muito claramente, cara, eu tenho um arquiteto de software, e esse cara tá passando 50% do tempo codando, eu estou gastando dinheiro com ele. Eu prefiro contratar mais desenvolvedor sênior e fazer com que esse cara mentore esses caras, eles consigam tomar mais decisões e etc. do que ficar pagando um arquiteto para ser desenvolvedor apenas. Porque se o cara está desenvolvendo muito, ele não consegue fazer o papel, que é o que você estava falando, ele não consegue fazer o papel que é o que você estava falando, ele não consegue fazer bem o papel que ele estava ali fazendo hoje em dia fazer esse papel se você tiver conhecimentos cada vez mais sólidos, acaba sendo um pouco mais fácil porque você tem mais ferramenta hoje para conseguir validar isso esse é um ponto importante talvez, e até para trazer para a gente o seguinte, de novo boa parte das pessoas que utilizam a definição de arquitetura de maneira inapropriada, fazem isso porque, pô, às vezes até o RH das empresas compromete, né, você tem o júnior, pleno e sênior, e o que que vem depois? Ah, depois é o arquiteto. Cara, pô, arquiteto não é dev sênior, s Senior, cara, nunca foi. Só que as pessoas, por alguma razão, elas gostam desse nome, né? Eu sou arquiteto. Talvez porque eu olhava Matrix, sei lá, e aí fica pensando que é aquilo, né? Cara, o arquiteto é bem mais do que isso. Tem um conjunto de responsabilidades que diferenciam. É a mesma coisa, ah, o CTO tem que codar. Ah, tá bom, cara. Então vai falar sobre CAPEX, sobre OPEX, sobre o modelo de contratação, estabelecer parceria, vai manter, como eu tive, por exemplo, um time com 700 pessoas e vai responder sobre 700 pessoas, passando o teu dia codando, queridão. Cara, assim, faça o seu trabalho, né? De novo, o que se espera de você? E isso, gente, precisa ser dinâmico, você tem que entender que essa configuração muda conforme a empresa em que você está trabalhando. Uma coisa é você ser CTO de uma empresa em que você está montando você e seu colega founder, que é o CEO. E aí a empresa são vocês dois. Então você é o CTO que programa. Se bobear, o CEO está programando também. E está tudo bem, tá ligado? Agora, cara, outra coisa, eventualmente você está trabalhando com como é que você trabalha nesse contexto, né? Como é que a coisa funciona nesse contexto? Você tem atribuições. Gente, um ponto importante, tem um livro muito bom chamado Pipeline da Viderança. Pipeline da Viderança foi escrito por um cara de gestão chamado Han Charan. Cara, Pipeline da Viderança, eu lembro pra mim muito o livro de Domain Dream Design do Eric Evans. Por quê? Porque os dois são livros absolutamente chatos de se ler. Sabe, cara, quem leu o livro do Evans e gostou, cara, você tem um problema. Brincadeira, tá, gente? Eu gosto do Evans, mas, cara, o livro do Evans é um livro chato. O livro do Hancharan também é um livro chato. Mas são dois livros essenciais, tá? E o Hacharan, Wesley, faz uma provocação. Ele fala o seguinte, ó. Numa estrutura hierárquica, que é como funciona basicamente tudo no mundo, né? Cara, se você eventualmente está numa posição hierárquica e você executa papel de duas posições, a sua e a de baixo. Por exemplo, o diretor, que é ao mesmo tempo diretor e gerente. Cara, se você ocupa duas posições, você está condenado a fazer só a função da posição de baixo você não vai executar a função de cima sabe, então se você é diretor de gerente você vai ser só gerente, se você é arquiteto não que arquiteto e deve tem aqui uma hierarquia, vocês entendem o que eu quero dizer mas cara, se você gastar o seu dia escrevendo código, dificilmente você vai gastar o seu dia sendo arquiteto não dá para fazer as duas coisas de uma forma eficiente uma coisa você fazer como complementaridade agora, o ponto importante é com a chegada com o advento da IA o código voltou a fazer parte da vida do arquiteto mas não da mesma forma que é da vida do TED esse é outro ponto importante a relação com o código o arquiteto voltou a ser mais ínt com o código, o arquiteto voltou a ser mais íntimo de código, mas não é a mesma intimidade que existe para a vida do dev. O impacto da IA na vida do arquiteto não é o impacto da IA na vida do dev. São impactos diferentes. A gente precisa entender essas diferenças, mas isso sozinho já rende conversa para outra live. Estou vendo aqui que a gente precisa entender essas diferenças, mas isso sozinho já rende conversa pra outra pra outra live. Tô vendo aqui que a gente tá estourando já o tempo, já tá estourando o tempo que você tinha pedido pra gente tentar respeitar, mas vamos tentar seguir. Pedro, dia querido. Você tá no mudo ainda, Pedro. Opa, opa. Foi agora? Boa noite. Elemar, você me falou uma coisa aí, acho que opa, opa foi agora? boa noite Elemar, você me falou uma coisa aí, acho que pegou firme aqui em mim, eu tava até refletindo é que quando você não consegue justificar suas ações, você não tá fazendo seu trabalho direito hoje eu sou tech manager na empresa que eu trabalho eu acho que eu tô com essa dificuldade, e é nisso que eu tô errando que eu tenho muita dificuldade de chegar na mesa, que tem um time de negócio e conseguir justificar algumas tomadas de ações. Trazendo um case real aqui para vocês, a empresa que eu trabalho, ela tem pessoas que trabalharam por muito tempo com monolito e a gente foi para o serverless. E aconteceu justamente o que você comentou, a gente tem um monolito serverless, então criamos grandes problemas para a gente. Só que para então criamos grandes problemas pra gente só que pra explicar isso na mesa que tem só pessoas de negócio eu sou a única pessoa técnica, é muito complicado e a maioria das vezes eu saio perdendo e quando eu consigo ganhar alguma coisa é porque eu tive um case muito grande de insucesso, ou seja, o sistema caiu ou tive uma perca de performance muito grande ali, ou a conta da AWS subiu muito rápido, e aí eu consigo alguma coisa, mas fora esses momentos eu não consigo. Uma dica, sugestão aí, ou até um case que você possa me dar pra me inspirar aqui nos momentos? Vou te dar sim, vou te dizer uma coisa, meu querido. A primeira coisa que você tem que entender é a seguinte, você como todo mundo, cara, qual é a principal habilidade que vocês têm que desenvolver? A principal habilidade que vocês têm que desenvolver? A principal habilidade. Sem sombra de dúvidas, a principal habilidade que vocês têm que desenvolver para a vida de vocês se chama vender. Vender. E vender, eu não estou falando em trocar coisas por dinheiros, tá? Especificamente, vender uma ideia. É importante você entender o seguinte, Pedro. Toda uma hora, uma venda é feita. Ou você é eficiente para vender uma ideia para o time de negócio, ou o time de negócio é eficiente em te vender a ideia de que o que você está falando não é importante. Mas toda hora uma venda acontece. E aí eu quero te mostrar, eu estava tentando achar aqui, acho que eu vou conseguir trazer, aqui, achei, muito bom. Cara, eu quero mostrar pra você eu uso muito, Pedro, lembra que eu falo que eu tenho frameworks, tá? eu gosto de usar framework thinking, eu gosto de pensar em termos de frameworks pra tomar as minhas decisões, um dos frameworks que mais me ajuda, cara, eu quero que você Pedro, tente colocar isso em prática já amanhã, se chama OSIR. O que é OSIR, tá? É acrônimo pra Outcome, Situação, Implicação, Recomendação. O que a gente faz como técnico com muita frequência? A gente vai até uma reunião de negócios e a gente faz só a recomendação. Certo? E, cara, se você faz só a recomendação, as chances são grandes de que o time de negócio não te escute, certo? Até porque eu vou falar uma coisa dura pra você daqui agora, tá? Pra quase todos vocês. Eu tenho certeza que a maioria de vocês tem como chefe e por chefe eu tô definindo alguém que define o quanto você ganha que não tem capacidade técnica de te avaliar tecnicamente. Cara, as pessoas não tem capacidade técnica para te avaliar. Então, entenda o seguinte, a grana que você vai fazer, não vai estar relacionada necessariamente com você se transformar num técnico melhor. Porque, cara, o teu chefe não consegue te avaliar tecnicamente, certo? Então, assumindo que isso é um ponto importante, aonde que está o seu diferencial a partir de agora? Está em você aprender a vender as suas ideias. Você ter um trabalho de construção de venda, isso implica uma construção de uma reputação favorável, implica num monte de coisas que te ajudam eventualmente a ser mais incisivo. Mas o Osirio ajuda nisso. Qual é o ponto, tá gente? Primeira coisa, quando você for se preparar, Pedro, pra próxima reunião, pra justificar, primeira coisa que você tem que tentar botar no papel é o Outcome. Por isso o nome Osirio aqui, tá? Primeira coisa é o Outcome. O que é o Outcome? Outcome é o teu... Tem um joguinho de palavras até que é complicado. A diferença entre Output e Outcome. Output é o que você quer fazer. O Outcome é o benefício que você quer gerar. Então a primeira questão é a seguinte, ó. Na perspectiva do negócio, qual é o benefício que a tua recomendação está trazendo para o negócio é a primeira coisa, assim, a tua argumentação deve começar com o outcome e lembrando, tá, no ambiente corporativo, o outcome está sempre associado com custo e com risco se você não falar sobre custo e risco, você está falando blá blá blá blá blá blá blá o isca sachê, ninguém está falando blá, blá, blá, blá, blá, blá, blá, blá, blá, o isca sachê. Ninguém te entende. Então, cara, primeira coisa é o benefício. Entenda o seguinte, senhores. Dor latente, desejo ardente. Ninguém compra solução para problema. As pessoas compram alívio para dor. Eu sou um cara gordinho. Quer dizer, eu vivo com o problema de engorda, emagrece, engorda, emagrece, engorda, emagrece. Agora eu tô na minha fase de emagrece, tá? Perdi sete quilos aí no último mês. Legal. Só que eu sou um gordinho profissional, cara. Eu sei tudo que eu tenho que fazer pra ser magrinho. Mas eução? Sei. Por que eu não faço? Porque não dói. Cara, entenda, se você não conseguir relacionar alguma coisa que você quer convencer o negócio a fazer com uma dor, acabou, você não vai vender. Então, dor latente, desejo ardente. O outcome é, qual é a dor que você está aliviando? Primeira pergunta. O Outcome é qual é a dor que você está aliviando. Primeira pergunta. Se você não consegue reconhecer isso, você não está preparado para vender a ideia. Você não fez o seu trabalho, Pedro. Reconheça qual é a dor que você está aliviando. É o Outcome a primeira coisa. Segunda coisa do Osir é a situação. Cara, qual é a situação? Ah, cara, os nossos servidores... olha só, nós estamos perdendo vendas. Situação. Cara, nossos servidores estão topando memória e estão aumentando o tempo de resposta. E, cara, qual é a implicação? Que é a segunda parte. Qual é a implicação? A gente sabe que no mercado de varejo, cada segunda a mais para você renderizar uma página, corresponde a 7% a perda de conversão. Você vai converter 7% menos para cada segunda a mais que você demora para renderizar. Certo? Então, a minha recomendação é investir, fazer X, que eventualmente vai reduzir esse tempo de resposta. Mudar para React. Oi? É. Estou tirando o sábado, mudar para React. Mas o ponto importante aqui, senhores, é o seguinte, tá? Oze, outcome, situação, implicação, recomendação. Se você chegar só com a recomendação, você não vai ser entendido. Se você falar sobre a situação e a implicação, cara, talvez o cara te ouça, que é o CIR. Agora, se você começar com outcome, cara, talvez o cara te ouça, que é o Ciro. Agora, se você começar com a Outcome, cara, as chances são grandes do cara te comprar só na Outcome. Você não precisa nem explicar o resto. Se você conseguir bater num ponto de dor, meu irmão, você fez a venda. Imagina você chegar na sua reunião e falar, pessoal, hoje eu vou trazer aqui pra vocês uma forma que a gente tem de aumentar em 7% as nossas vendas. Isso vai dar em tantos milhões agora a partir de aqui. Todo mundo vai ficar com a boca fechada e vai falar, me fala como que a gente faz isso. Qual é a situação? Nossa página de produto hoje está demorando cerca de dois segundos para renderizar. As implicações disso é que a gente sabe que a cada segundo, tem estudos que apontam que a cada segundo para renderizar uma página são 7% de conversão. Nós vamos reduzir esse tempo para um segundo. E isso vai aumentar em 7% a nossa conversão. Como é que a gente faz isso? Fazendo tal coisa. Mas como é que a gente faz isso, cara? Você entende? É sobre bater na dor. Agora, Você entende? É sobre bater na dor. Agora é claro, né, irmão? Tipo, olha a diferença de postura que você como arquiteto precisa ter. Você está parando de falar sobre o desenho, o chat, desculpa, chat não, o desenho, o LLM, o cache, o banco de dados. E você está falando sobre dor de negócio, cara. Tem um livro maravilhoso, senhor, chamado The Software Architect Elevator, que é do nosso amigo Greg Hope, que é o cara que inventou o Enterprise Integration Patterns, um dos melhores livros já escritos sobre padrões de integração de negócios. E, cara, basicamente todos os patterns que você conhece para poder usar Kafka certo, vem do Enterprise Integration Patterns do Greg Hope. E lá o Greg Hope usa essa alegoria do Software Architect Elevator, porque ele fala que cara, o arquiteto tem que falar tanto no porão, ou seja, com quem tá falando sobre bit-byte, quanto lá no rooftop, com quem eventualmente tá falando sobre sobre negócio, né? Você tem que conseguir falar bem na cobertura. Por isso que o arquiteto é orquestrador, cara. Você faz a ponte. Tecnologia é algo importante demais pra ser resolvido só dentro da área técnica. Né? Esse é um ponto importante. Enquanto eu vou respondendo aqui, até porque a gente já ultrapassou a hora, deixa eu fazer um micro jabá, né? Assim, micro jabá autorizado, assim, Nico Jabá autorizado combinado com o Wesley, não estou traindo ninguém aqui não tá gente, assim, eu tenho uma mentoria de arquitetura e software, gente, que vai falar agora sobre, enfim, são 16 encontros, blá blá blá não quero consumir tempo com isso, mas só aqui fica essa imagem, porque eu combinei com o Wesley que eu tinha que, eventualmente se eu vou dar jabá esse cara, tem que Elemar, galera, o lance é o seguinte, o Elemar tem uma mentoria top pra caramba, tá? Eu já fiz a mentoria e agora provavelmente vai estar até melhor, principalmente porque são momentos diferentes que a gente tá vivendo e o ponto que eu conversei com o Elemar, eu falei assim, Elemar, participa aqui com a gente também. Cara, eu vou ter um mega prazer, inclusive, de mega te apoiar pra que a galera possa também fazer a mentoria do Elemar. E eu falei, cara, Elemar, dá um desconto pra galera aqui também. Pratico que, de alguma forma, esse pessoal, eles tenham mais condições também pra conseguir trabalhar. Então, galera, mais do que recomendo, entendeu? Escaneiem aí o QR Code, fala com o Elemar, chama no LinkedIn, ele tem pessoal também na área comercial que pode te atender, que pode tirar suas dúvidas e etc. Tá? Então, mais do que recomendo, eu estou conversando, eu estou tentando organizar o meu tempo para conseguir fazer, tá? Então, pessoal, super recomendo, acessem, escaneiem essa parada aí, acessem, escaneiem essa parada aí, porque já dá pra perceber eu confero, Elemar, é e não tenho dúvidas nenhuma que, cara essa mentoria vai ajudar você pra caramba profissionalmente Obrigado, obrigado, mas assim tava todo cheio de dedos, né, mas enfim feito o jabá e a princípio já escaneado vou até mudar o slide, porque a princípio quem queria já escaneou, quem não queria pede de novo, depois. Depois manda o link, Elemar, a gente cola aqui no chat. Aí, o Lucas já colocou aí. E ser estratégico, gente, é experimental. É estratégico ser experimental. A gente precisa falar sobre isso, mas enfim, essa é uma discussão grande. Outro ponto que eu vou aproveitar enquanto eu respondo as perguntas e depois a gente fica variando, cara, aqui estão os meus contatos sociais, cara, você encontra eu como Elemar Júnior em todos os lugares, tá? Sou ativo pra caramba no Instagram, tô tentando manter um canal no YouTube, tem um canal no YouTube da Zimia, que é a minha empresa, e tem o meu, sabe? Falo sobre programação funcional, um monte de coisa, enfim. Vamos bater papo, vamos continuar Cara, eu não sei qual foi a sequência, então vou chamar pela sequência que as mãozinhas estão aparecendo levantadas aqui, tá? Maxwell, querido, tudo bem? Tudo bom, Elemar. Primeiro... Bota o seu vídeo aí, Maxwell. Eu tô com um problema na câmera que deu aquela... Elemar, você acredita que nos dias de hoje o cara fala, minha câmera, você acredita? É, eu deu aquela tela verde da morte aqui, tô com uma tela menos, a câmera não tá funcionando. Eu só acredito, porque a minha faz parecer que eu não tenho cabelo, cara, eu já tentei resolver de qualquer jeito, então, Maxwell, eu sou sensível à sua dor, essas câmeras realmente não funcionam, porque eu, assim, não tô mostrando as minhas madeixas aqui, cara bora lá, Maxão, diga-lhes tudo, prazer em te ver novamente a primeira vez que eu te conheci foi lá em Goiânia, num evento que a gente tava organizando lá, você palestrou algumas vezes lá, no DevFest Goiânia, lá, lembro, a gente conversou, bateu um papo legal lá, e a pergunta minha é, aquele framework que você mostrou lá sobre a parte da narrativa. Necessariamente aquilo lá precisa estar tudo no mesmo slide para causar mais impacto e efeito, ou aquilo pode ser uma construção verbal, tipo assim, como eu crio uma apresentação ou alguma coisa? Eu viciei, cara, em usar esse tipo... Tipo, eu tenho mais de um framework, tá? Tipo, o Osira é para você poder vender ideia para pessoas, para quem você precisa convencer. Tipo, você quer passar uma recomendação. Cara Para pessoas, para quem você precisa convencer, tipo, você quer passar uma recomendação. Cara, eu utilizo isso o tempo todo. Às vezes até sem slide, em conversa de elevador e tal. O que acontece é que se tem uma coisa que eu sei que não funciona, eu dou uma recomendação direta. Quanto a slide, cara, tipo, se você tiver tempo de fazer uma apresentação, avalia a cultura da tua empresa. Algumas empresas têm cultura de, cara, informação condensada, tal, para você poder entregar. Mas eu, Elemar, particularmente, de, cara, que slides é de graça, tá? Então, se a tua empresa, eventualmente, não tem restrição com esse tipo de coisa, cultura, não prega contra, cara, slides é de graça. Bota um bom slide para garantir o autocama, outro bom slide pra trabalhar com a situação, outro bom slide pra trabalhar com a implicação, e aí finalmente a recomendação. Mas, ponto importante, tá? Reconheça o teu público. Mais uma vez, lembra que o objetivo é se fazer entender. Alguns gostam de uma conversa um pouco mais envolvida, outros dizem, tá, tá bom, pelo amor de Deus, me dá aquilo que você quer e bora avançar. Eu aquilo que você quer e bora avançar. Eu disse alguma coisa pra você, Maxwell, aliás, é importante pra todo mundo, tá? Eu sou consultor, senhores, há alguns anos, me transformei naquilo que eu mais odiava, Maxwell, virei consultor. Consultor com frequência é engenheiro de obra pronta. Não sei se vocês já trabalharam com um consultor que é o cara que chega pra botar defeito no teu trabalho, né diretora, cara, Elemar, eu tenho 15 minutos pra você. Eu digo, tá bom. Aí eu falo em oito. E o cara fica comigo duas horas. Entende? Mas ele faz a opção de ficar. Entende? Cara, o tempo que eu tenho, eu faço questão de gastar metade. Exceto quando eu sou convidado pras aulas do Wesley, daí eu gasto o dobro. Mas, por exemplo, em reunião com a liderança, cara, eu faço questão de, cara, eu tenho uma hora, eu vou terminar em meia hora. Eu vou dizer, cara, eu respeito teu tempo, tô te mostrando aqui o que é importante, se você tiver curiosidade, pensa eu quero que você pense, Maxwell muito menos como um framework de narrativa, mas muito mais como um framework pra te ajudar a estruturar a ideia que você tá vendendo o fato de você pensar nos quatro elementos, vai te dar muito mais capacidade pra defender a tua recomendação o problema, sabe aquela coisa gente isso é importante tá quando você tá sob pressão você é sempre reduzido ao teu nível de treino cara, quanto que você treinou sob pressão você vai performar como você treinou tipo, o Oscar Schmidt acertava pra caramba, porque ele treinava pra caramba remexos de 3 o Cobray falava, cara, eu não erro no jogo porque eu acertava pra caramba, porque ele treinava pra caramba remexos de três, o Cobray falava, cara, eu não erro no jogo porque eu treinei pra caramba, ninguém treinou mais que eu sob pressão, você é reduzido ao nível de treino cara, não dá mais não dá mais, vocês são alunos mentorados do Wesley e fizeram uma sessão comigo não dá mais pra o ano da graça de 2025 você sair de uma reunião com aquela sensação de putz, se eu tivesse me dado conta, eu poderia ter falado tal coisa que mudaria a reunião. Cara, isso se chama despreparo, velho. Você tem que ser profissional, você tem que se preparar. Agora, a dica que eu dou é como é que você se prepara. Pô, então vai lá, pensa no anticano, pensa na situação, pensa a implicação, pensa a recomendação, estrutura um elemento, estrutura a tua fala, repassa, e aí você faz. E vai dar pra lá. E às vezes, cara, eu vou até mais longe, viu, Leomar? Bom, de forma geral, eu sou um vendedor, né? Se alguém tá aqui nessa sala, de alguma forma, vocês compraram, inclusive, de mim. E, cara, tudo que você faz, né, E, cara, tudo que você faz, que o Elemar falou, é uma venda. E toda vez que você faz uma venda, cara, você não treina para fazer código, você não testa um monte de coisa para a venda, cara. Porque no final das contas, o que o Elemar está falando aí é você tem que vender aquela ideia e as pessoas têm que comprar aquela ideia. O ponto é que para você vender algo, você tem que praticar, cara. Às vezes eu vou fazer abertura de matrículas de um curso. Cara, eu faço essa abertura de matrículas sem fazer pra ninguém. Eu treinando, somente eu, eu consigo ver quanto tempo eu demorei pra falar, o que eu falei, o que eu não falei, o que eu esqueci. Eu tomo nota. Por quê? eu falei, o que eu não falei, o que eu esqueci, eu tomo nota. Por quê? Porque na hora que chegar e tiver todo mundo ao vivo lá, eu sei o tempo máximo que eu vou levar pra conseguir explicar, pra conseguir tirar dúvida, pra conseguir fazer isso. No final das contas, é tudo treino. Então, se você tem uma reunião que é importante, cara, dependendo da situação, cara, faz você mesmo o seu pitch pra você mesmo, entendeu? Grava você falando, vê o como que o que que você poderia ter feito. Pode parecer aquelas técnicas bobinhas, fala na frente do espelho. Eu fiz muitos anos teatro. Eu fiz muitos anos teatro. Cara, esse tipo de coisa muda o jogo, porque é preparação. Isso aí é preparação. Então, se é o que o Leomrão falou, em momentos de pressão, você é reduzido ao treino. Você treinou quanto para aquela reunião? Se aquela reunião é importante, você não quer sair com aquela cara, putz. Novamente, a galera de produto me enrolou, eu vim aqui para refatorar 20% do sistema, eu vou sair com 20% de features a mais que eu vou ter que desenvolver. Você sai com uma derrota na reunião. Cara, tem que ser preparado. Você não pode chegar lá e cair de uma forma inocente. Prepara, treina, fala no espelho, grava, faz uma live com você mesmo, assiste você falando. Pode parecer besteira, cara, mas faz muita diferença. Eu vou pesquisar um pouco mais como funciona esse framework e tentar aplicar, porque eu tenho trabalhado num projeto global que é bem difícil, sabe? Eu tenho trabalhado num projeto global que é bem difícil, sabe? Eu tenho uma resistência muito grande por causa de nacionalidade, esse tipo de coisa. E eu tenho ganhado deles, mas cansa muito ficar ganhando deles. Eu quero ganhar eles, entendeu? Tipo assim, conseguir ganhar eles e ganhar eles. Aí você falou a palavra correta. Isso é o ponto, cara. Ganhar eles, não deles. Esse, ó, você falou tudo, cara. Assim, ó, a cultura do nós e eles, cara, é algo tremendamente tanoso, sabe? Tipo, a cultura de nós, negócio, eles, tecnologia, ou nós, tecnologia, eles, negócio, enfim, cara, essa cultura de nós e eles não leva ninguém a lugar nenhum. Sabe uma pergunta que eu me faço com frequência, cara? Eu desmonto, cara, você não tem ideia da quantidade de gente que eu desmonto em consultoria quando o cara vem reclamar que fulano está complicando a vida, blá blá blá blá blá blá, eu disse assim, cara diz pra mim uma coisa, meu amiguinho você acha que hoje de manhã fulano foi na frente do espelho se olhou e disse, cara hoje eu vou transformar a vida do Maxwell no inferno hoje tudo que ele apresentar eu vou dar contra e eu vou complicar com a vida dele. Esse cara até existe? Existe, existe. Mas é exceção, cara. No geral, no geral, é gente bem intencionada, com um tipo de pressão diferente do teu, que está lá correndo para conseguir gerar a entrega. Sabe, tipo, e aí é objetivo conflitante. E aí, eventualmente, a sua falta de sensibilidade, às vezes, em perceber o custo de oportunidade. Cara, se você ignorar a dor do outro, cara, se você não se importa com a dor do outro, por que o outro vai se importar com a tua dor? Saca? Esse é um ponto, sabe? E outra coisa importante para quem tem problema com a área comercial. Duas coisas para você lembrar, tá? Primeiro, o time comercial nunca conta mentiras, ele só antecipa verdades. Isso aqui eu ouvi de um comercial muito bom, viu Wesley? Uma vez o cara tava numa reunião e o cliente perguntava, ah, o sopro faz isso? Faz isso? Faz também. Eu, caramba bicho, sai da reunião nervoso, o cara se prometeu que faz um monte de coisa que não faz ele não faz hoje, daqui dois anos quando vai ser feita essa implantação vai estar fazendo não menti, eu só antecipei verdade esse mesmo cara eventualmente usou outra pra mim numa empresa tem três tipos de pessoa tem quem vende, quem ajuda a vender e quem atrapalha a venda você não pode ser a terceira pessoa nunca é assim, é dar um tiro ajuda a vender e quem atrapalha a venda. Você não pode ser a terceira pessoa nunca. Assim, é dar um tiro no próprio pé. Você ser o cara que vai entrar numa reunião deliberadamente falando que você vai ser um cara que está levantando a bandeira de atrapalhar a venda. Cara, não é sobre ganhar deles, é ganhar eles. Eu gostei dessa frase melhor que as minhas. Assim, eu gostei tanto, Maxwell, vou te contar uma coisa eu sou muito bom em pegar a ideia dos outros a partir de agora você quer a minha mas você tem que ganhar na próxima live que o Lemar estiver na Full Cycle o Lemar vai soltar uma dessa, o Maxwell vai falar sem vergonha nem ganhei os créditos nada, nada, nada eu vou botar assim, ó. Vai, Maxwell. Vai, Maxwell. Enfim. Diga, Sérgio. Opa, beleza? Tá me ouvindo? Muito bem, muito bem. Excelente, tá? Primeiro de tudo, parabéns, Leimar. Conteúdo excelente, como sempre. Realmente é um ponto fora da curva no bom sentido. Minha pergunta é com relação a risco. O arquiteto sempre deve considerar custo e risco. Ótimo, mas existe uma forma de você mensurar de forma efetiva o risco como sendo um número absoluto? E dentro dessa ótica, você tendo numa equipe, o que você considera como limite de risco para uma equipe que quer adotar uma tecnologia alguma tendência que você considera que a área de formagem considera imatura uma coisa que seja por entusiasmo ou talvez um buzzword como é que você trata o risco nessas situações obrigado obrigado pelo agil me sinto lisonjado bacana nessas situações. Obrigado. Por nada, Sérgio. Obrigado pelo elogio, me sinto lisonjado, poxa, bacana. Muito obrigado. Eu posso dizer pra você o seguinte também, Sérgio, mais uma dica de venda. Houve um tempo da minha vida que eu achava que em toda apresentação eu tinha que ter um conteúdo totalmente inédito. E aí, cara, eu gastava um tempão. Eu acho que eu sou o maior recordista em número de palestras em TDC num evento individual. Eu fiz 14 palestras uma vez no TDC Floripa. 14, cara. Eu fiz 14 palestras diferentes. Aí eu descobri, por exemplo, Sérgio, que mais de 60% do público que vai no TDC todo ano vai me interesse pela primeira vez, tá? E, cara, a outra parte seguramente corre o risco de não lembrar do que eu falei, tá? Então, eu resolvi perder essa obsessão por fazer conteúdo novo toda vez e achar formas melhores de apresentar conteúdos que eu já apresentei. Cara, tem muita coisa que eu mostrei pra vocês aqui hoje que o Wesley me vê falando desde a época que ele fez mentoria comigo há quatro anos atrás. Então, você repetir e qualificar o que você está repetindo é algo importante. Respondendo a tua pergunta, que eu não fugi dela, cara, eu acho que tem algumas coisas que são perceptíveis de risco. Por exemplo, quando você analisa, por exemplo, o histórico de modificações num release e você verifica, por exemplo, que esse histórico, que essas modificações foram feitas sobretudo naqueles arquivos que tem maior número de contribuidores ou naqueles arquivos que tem a maior quantidade de comites, especificamente em concentração, ali você tem um aumento potencial de risco. Quando você tem, por exemplo, uma mudança que é feita por um autor que está fazendo essa mudança pela primeira vez no determinado componente, você tem aumento de risco. Quando você tem um decréscimo do índice de cobertura, mais ou menos a saber, você não tem garantias que o software está funcionando se o percentual de cobertura mais a saber, né? Tipo, você não tem garantias que um software está funcionando se o percentual de cobertura é alto, de cobertura por testes. Mas você tem certeza que você tem problema se a cobertura é baixa. Então, cara, baixou a cobertura, pô, você tem aumento de risco. Então, você tem vários indicativos de potenciais riscos que você utiliza observando dinamicamente o teu repositório, tá? Acho que esse é o primeiro ponto. Sobre a variação para o negócio, cara, existem algumas atividades dentro de um software, falando sobre DDD, tá? Para quem gosta também de design, o pessoal fala sobre subdomínio core, subdomínio de apoio e subdomínio genérico. Cara, lembra os três tipos de subdomínio? Core, de apoio e o genérico. Cara, lembra os três tipos de subdomínio? Core, depois e o genérico? Cara, se você traduzir isso para o negócio do jeito que alguém de negócio entende, lembra? A gente tem que vender para eles. Eu digo, cara, o subdomínio core é onde a empresa ganha o jogo. O subdomínio de apoio é aquele que ajuda a empresa a fazer aquilo em que ela ganha o jogo. E o subdomínio gen porque você é obrigado. Cara, se você vai fazer um lançamento de uma versão que vai ter alteração no core, você tem um percentual de risco que é maior do que se essa alteração, se essa versão só fizer modificações em coisas que sejam genéricas. Cara, pareto, tá? 80%, 20% das features são usadas 80% do tempo. Cara, 80%, isso quer dizer o seguinte, quer dizer que, poxa, os outros 80% não tem 20% do valor. Se você faz uma alteração numa feature que é dessas features também mensura risco, entende? Cara, o ser humano resiste a tudo, até acostuma a tudo, até viver mal. Cara, se você vai adotar, por exemplo, um novo framework, ou uma nova interface, uma nova proposição de interface, mesmo que a interface tenha melhorado. Cara, assim, quando a Microsoft propôs a Ribbon, que é a interface lá do Office, cara, a primeira sensação que eu tive quando eu vi a Ribbon é de não querer usar. Sabe, cara, eu queria o Office antigo, não gostava da Ribbon, por quê? Porque hoje eu reconheço que a interface é muito melhor, e a Microsoft tomou a decisão de maneira acertada, mas inicialmente eu achava que um horror, cara assim, a gente não pode subestimar o impacto da modificação para os usuários mesmo que seja para melhor e aqui tem uma última dica também sobre risco ainda e cara, você percebe que o tema risco ele é sazonal, ele tem algumas implicações pra você poder verificar, mas algumas dicas interessantes. Se você não tá familiarizado com DoraMetrics, tá, tipo, recomendo que você dê uma olhada, não vai dar tempo pra falar sobre Dora aqui hoje, mas enfaticamente se você tem uma deterioração das métricas do hora, você tem um aumento também do risco. Isso de maneira geral. Para quem gosta, eventualmente, de DevOps, associado com o cara DevOps, você fala sobre... Tem conteúdo aí no MBA, tem conteúdo, inclusive, de semana de arquiteto que a gente já passou e a galera tem gravação, galera. Então, se vocês falarem, não sei, nunca ouvi falar, vocês não estão assistindo as aulas, pelo amor de Deus é, é, e aí pô assim, gente, de novo o recurso não percebido é custo, né tipo, se você pagou pra fazer e não tá fazendo você gosta de gastar dinheiro, né mas vai saber, né, tipo pessoas, né, mas essas são todas variáveis de risco, tá Sérgio, mas o tema risco é um tema importante. Agora, uma coisa fundamental, tá? Nas empresas, no negócio, você geralmente encontra aqui um trade-off, tá? Então, tem empresas que vão ser tremendamente, negócios, áreas, subdomínios, enfim, onde as pessoas vão ser tremendamente focadas em custo geralmente quando o povo é muito focado em custo, eles tem uma tolerância maior ao risco e geralmente quando você está lidando com uma área que é absolutamente preocupada com risco, você tem uma tolerância maior ao custo e aí é importante você reconhecer onde você está, por exemplo, cara, provavelmente num grande banco poxa, o risco de você lançar um problema com uma atualização de segurança, eu fiz um patch de um pacote. Cara, por que que gemude é tão complicado em empresa financeira, cara? Porque, pô, nós estamos vendo, veja lá o Log4J, por exemplo, né, tipo, que depois de não sei quantos anos mostrou vulnerabilidade. Então, cara, é complicado. A pessoa fala, não posso atualizar para a versão última do framework. É o bicho. Eu entendo. Então, perceba isso. Você tem que perceber o que pesa mais para o negócio. Se é risco ou se é custo. Nada pior do que um arquiteto que fica defendendo a redução de custo pra um time que é preocupado com risco. E nada pior do que um cara defendendo risco quando o time só é preocupado com custo. Você tem que estar sintonizado com o lugar onde você tá. Tá bom? Muito bom. André Diniz, tá pegando fogo, André. Isso aqui é a nossa vida padrão. Assim, sempre que você não faz algo enquanto é importante, você faz quando é urgente, né? Eu entro nas deles do meu trabalho com esse fundo aqui, sempre. É bom. Vou te fazer uma provocação, André. Cara, já foi esperando o tempão e agora eu fico te pegando isso. Uma das definições de software legado que eu mais gosto é a que fala que software legado é aquele software que está dando problema e segundo não foi você que fez. Sim. Nessa perspectiva, cara, o time de sustentação está sempre lidando com legado. Mas enfim, diga lá, André. Bom, primeiramente queria agradecer, né, já vai dar, daqui a pouco tá duas da manhã aqui, pela que a sinal foi muito boa. Mas assim, na verdade não é uma pergunta, eu só queria adicionar uma coisa no que você tinha falado sobre vendas. Antes de ser desenvolvedor eu fui bancário, durante alguns anos, fui gerente, tudo. E trabalhava diretamente com empresas. Então, tem uma coisa que eu aprendi, que basicamente além das vendas, que é algo extremamente importante, é a comunicação. E uma coisa que eu aprendi é, se você tem uma boa comunicação, você consegue vender antes de você entrar na sala de reunião. Então, eu acho que é muito importante, e eu já vi experiências minhas também como desenvolvedor, em salas de reunião, que as pessoas às vezes falam, elas conseguem falar, conseguem usar frameworks, seja lá o que for, para tentar passar a fazer a venda em si, mas elas pecam na forma como elas se comunicam. E elas não vendem. Não dá pra vender se comunicando mal, André. Esse é um ponto importante. Você não faz venda se comunicando mal. E não confunda comunicar bem com falar bonito, tá? Exatamente. Não, bicho, assim, Dr. House. Dr. House fazia, tipo, cara, Dr. House era horrível tipo, eu vi o cara, era chato tipo, eu não sei se eu queria ser tratado por Dr. House, na verdade eu sei se eu quisesse viver, eu queria, se não eu ia ser tratado por Dr. Wilson, que estava lá sentado não sei se vocês olharam a série, mas Dr. Wilson o cara que estava lá tratando o cara doente que estava morrendo, né? Cara, se for pra entrar o médico na minha sala, que seja o House, né? E se não for o House, seja a Cameron, tá? E aí, é a discussão. Mas eu concordo com você. E é exatamente isso. Então, eu acho que é importante sim ter a ideia de frameworks de venda e tal. Eu não sabia, acho que foi uma novidade e o Wesley falou que fez teatro, isso pra mim foi uma novidade grande. Eu fui quase profissional, cara, por incrível que pareça. Ver o Wesley na Globo não ia dar certo não, mas tudo bem. Já pensou? Vocês acham que é todo esse processo que ele faz? É. Novela mexicana. Eu fui fantasminha pluft, tá? Por três anos mas enfim eu acho que é importante as pessoas também darem uma atenção muito grande a essa parte da comunicação porque é um, pelo menos também também não quero pegar muito tempo mas também é uma outra questão que é muito comum na nossa área pessoas mais introvertidas isso melhorou bastante com os anos. Muito. Melhorou muito com o passar dos anos. Mas. É importante saber falar. E se comunicar bem. Para poder conseguir isso. E daí eu sempre recomendo. Tem alguns livros como. Comunicação não violenta. Tem a arte da comunicação de impacto. Que é muito bom também. E bom. E é isso. Muito bom, cara. Muito bom as suas dicas. Mas, ó, tem um ponto importante não para você, gente. Assim, ó. A comunicação é essencial para você conseguir vender, para você poder tornar comum. Agora, deixa eu fazer um desafio. E aqui eu não vou me prolongar muito, tá? Porque essa explicação demoraria um horror para eu conseguir dar toda a fomentação filosófica para isso. Mas vamos fazer juntos um exercício aqui? Vamos fazer um exercício todo mundo? Preste atenção, vai ser facinho o exercício. Eu vou falar para você, eu quero que você internalize o que eu vou dizer agora. Para alguns pode ser dolorido o que eu vou falar agora. Mas são só três palavras. Cuida do teu pai. Todo mundo ouviu? Vou repetir. Cuida do teu pai. São quatro palavras. Quatro palavras. Cuida do teu pai. Cara, olha que coisa doida. Se tem uma coisa que eu tenho certeza, é que cada um de vocês ouviu e internalizou essa frase de uma maneira diferente. Porque cada um de vocês tem uma relação diferente e potencial com o pai. Alguns ainda tem o pai, alguns perderam o pai, alguns eventualmente acreditam em Deus e percebem Deus como pai. Pô, tem várias interpretações pra pai. Cara, quando você pensa em cuida, então, Deus o livre, cara. Tem gente que pensa que cuida tá junto, cuida falar, tem gente que pensa que cuida estar junto, cuida falar, tem gente que pensa que cuida dar dinheiro. Cara, cuida do teu pai, certo? Cuida do teu pai. Cara, é uma frase simples, com quatro palavras. E, cara, cada um de vocês, seguramente, eu tenho certeza, é que nenhum de vocês sentiu o cuida do teu pai da forma como eu senti ao falar cuida do teu pai. Percebbe isso? Cara, se com quatro palavras a gente tem sensações completamente distintas, imagina para grandes textos. O normal não é que as pessoas te entendam, o normal é que as pessoas não te entendam. Porque cada pessoa atribui um significado diferente para palavras tão simples quanto cuida e vai. Então, você precisa admitir essa ideia. De muitas formas, Wittgenstein ensina que, cara, todos nós estamos condenados a viver sozinhos porque ninguém consegue perceber o mundo da forma como você percebe. A única forma de você ter uma sensação de que as pessoas estão te entendendo é quando tem alguém que convive com você há tanto tempo, de forma tão intensa, a ponto de você compartilhar o mesmo contexto. A esse contexto compartilhado, você pode entender como intimidade. Cara, você precisa, a comunicação para ser mais efetiva demanda intimidade tem gente na tua vida que você não precisa falar uma palavra, a pessoa já entende o que você quer dizer certo? tem gente que você passa o dia inteiro falando e a pessoa não entende uma palavra que você falou, entende? então cara, demanda intimidade e intimidade demanda construção, cara tem gente que diz que a confiança é a base do relacionamento. Eu concordo com isso. Mas antes da confiança ser a base do relacionamento, o relacionamento é a base da confiança. Você precisa construir relacionamento com as pessoas. Aí, cara, quando você constrói relacionamento, que você desenvolve intimidade, que você desenvolve, eventual, que você desenvolve eventualmente um contexto compartilhado, aí a comunicação naturalmente acontece de forma mais qualificada. Se você quer comunicar melhor, você precisa ter interesse genuíno em desenvolver intimidade com as pessoas. Como é que você faz isso? Seguindo uma regra simples. Tentando ser interessante no que você fala. Resolvendo a dor do outro. Tentando ser interessado quando você ouve. E nunca sendo interesseiro. Interessante, interessado, nunca interesseiro se você sistematicamente desenvolver essa conduta de ser interessante, interessado e nunca interesseiro e manter próximo de vocês gente que seja interessante, interessada e não interesseira, cara, você vai construir relações mais sólidas e você vai ter uma comunicação mais efetiva não precisa ter aula de teatro como eu e Wesley, o problema que eu e Wesley precis mais efetiva. Não precisa ter aula de teatro, como eu e o Wesley. O problema que eu e o Wesley precisamos... E, cara, eu fui fazer aula de teatro, Wesley, porque de tanto apanhar em casa e ter TDAH, eu era tímido, tá? E, cara, eu tive a sorte de ser uma professora na quinta série, que disse, cara, vai fazer uma aula ser teatral a um ponto que eu não sei hoje se eu superei a timidez ou se eu internalizei a técnica. E eu fico com essa dúvida ainda mais forte, cara, quando eu vou dar evento. Eu já fiz palestra pra 3 mil pessoas. E pra mim é tranquilo. Mas sabe o que é difícil pra mim?, eventualmente receber as pessoas depois da palestra. Sabe, quando vem no one-on-one conversar comigo, ali eu fico, tipo, tremendo, sabe? Meio bobo isso. Mas, vai mesmo que doa, né? Então, com o tempo também desenvolve técnica pra poder... Uma coisa que eu posso dizer pra vocês, tá? Eu faço brincadeiras com alguma frequência. Toda vez que eu faço uma piada engraçaralha, ou seja, aquela piada que não tem muita graça, mas que deu contexto e fica ok, toda vez que eu faço isso é eu tentando contornar a minha timidez, o meu medo eu estou encabulado, por estar com medo eu brinco cara, eu já cheguei em reunião com diretora cara, diretora de uma empresa grande, bicho Wesley, olha só, direttor de uma empresa grande, bicho. Wesley, olha só, diretor de uma empresa grande, a mulher ligou para mim pedindo, Leymar, preciso da tua ajuda. E a mulher é super séria. E é uma senhora já dos seus 50 e muitos, né? Cara, e eu fui falar com ela, disse, fala, Lorão, o que é que tu me pede rindo que eu não te atendo, nem que esteja chorando? Cara, como é que você chega pra uma mulher comando uma empresa que fatura alguns milhões de reais por hora pra dizer assim, cara, fala, Lorão caramba, velho, o que eu fiz? eu fiz isso, entende? mas assim, por quê? porque eu, toda vez que eu fico nervoso eu solto uma piada sem graça toda vez toda vez e aí vocês vão conhecendo detalhes do Elemar enfim, diga, meu amigo Rodolfo. Opa, boa noite. Eu cheguei aqui na parte quando vocês estavam comentando que o arquiteto de software com a evolução do IA, ele está se aproximando mais ali do código. E a minha dúvida é a seguinte, com essa evolução e com o elevado número de conteúdos com o título arquitetura de software que nós estamos vendo hoje, eu por exemplo, estou vendo bastante cursos, alguns conteúdos com o título arquitetura de software na sua opinião você acha que essa profissão está sendo um novo boom do mercado? como era até uns dois anos atrás ali de desenvolvedor ou não? até porque a IA parece que está essa profissão está sendo um novo boom do mercado, como era até uns dois anos atrás ali, de desenvolvedor ou não? Não. Até porque a IA parece que está... Possivelmente vai substituir ou com certeza diminuir ali o número de cargo de desenvolvedor. Irmão, eu acho que não. Eu acho que, de novo, é o ego. Técnico é o cara com o ego inflado o povo adora botar arquiteto, porque acho que eventualmente tem muita gente que bota arquiteto porque acha que infla sabe e geralmente não, cara, acho que aqui não e é importante você tomar cuidado com as fontes eu vou te dar um exemplo prático sobre essa questão da arquitetura eu conheço um cara chamado Roy Fielding é um miguxo que hoje trabalha na Adobe vocês sabem quem é Roy Fielding. É um miguxo que hoje trabalha na Adobe. Vocês sabem quem é o Roy Fielding, não? Não. O Roy Fielding é o cara que criou REST. Da tese pós-doutorado dele, ele criou REST. E uma vez perguntaram na internet se o verbo option, ele era RESTful ou não? Perguntaram na internet. E o Roy Fielding respondeu que sim, era restful. E aí a pessoa, como vocês que supostamente... Acho que foi no Twitter, inclusive, não foi? No Twitter. Perguntaram, cara, mas por que você disse que o Option é restful? E ele falou, olha, que interessante. O Roy Fielding trabalhou durante muitos anos no comitê que define o HTTP ele é um cara que ajudou a definir o HTTP e o REST na verdade era uma forma de impor restrições ao HTTP que o pessoal estava utilizando o HTTP de uma forma uma das palavras do próprio Rayfielding explicar REST REST é igual a HTTP com restrições e aí ele respondeu, olha baseado na minha experiência criando o option e baseado na minha experiência definindo o REST eu acho que eu posso dizer que sim o option é compatível com a ideia do REST ele falou de uma forma bem humorada mas cara, a internet caiu de pau dizendo que ele tava usando a... como é que era? A... o argumento, né? Da autoridade. A falácia da autoridade, né? Cara, o que falácia da autoridade, cara? O cara criou o raio do Rush, criou o raio do... Tudo bem, começou a responder e na sequência daria uma resposta baseada em argumento pra poder sustentar, mas cara aí o povo vai discutir com ele sobre o que é REST, ele fala, cara, não tem problema nenhum você fazer uma API que tem get, put, post, delete e que seja HTTP né, HTTP-like cara, só não chama de REST porque não é dessa forma que você tá fazendo, pô, se você não usa, se você não usa por exemplo, o HFAS se você não sabe o que é o HFAS, recomendo que você vá dar uma olhada, cara, se você não usa o HFAS, você não está fazendo o RASH simples assim ah, mas tem o Richardson que fez um modelo de maturidade de Richardson para poder definir o que é RASH o Orville disse, cara na prática, o modelo de maturidade do Richardson não é algo que eu concordo com. Então, poxa, eu entendo que você pode estar mais aderente ou menos aderente a RASH, mas, cara, RATIOUS é, para mim, obrigatório. Pelo cara que definiu. E repara, ele não está dizendo que você deve fazer RATIOUS. Ele está dizendo que se você quer dizer que você faz RASH, você deve fazer RATIOUS. E, cara, tem um cara que publicou o suposto arquiteto que foi falar que, pô, Rachel's é um anti-pattern em Rush. Ah, gente. Ah, sabe. Assim, eu já dei um monte de opinião furada. Né? Toda vez que você se posiciona, essa é outra dica importante pra você, ó. Toda vez que você se posiciona, outra dica importante para você, toda vez que você se posiciona, você corre o risco de ofender alguém. Toda vez que você se posiciona, você corre o risco de ofender alguém. E não tem nem nada de relevante que você faça na vida sem se posicionar. Então, você tem que correr o risco de ofender alguém. Esse é um ponto. Escolhe quem você vai ofar. Então, você tem que correr o risco de ofender alguém. Esse é um ponto. Escolhe quem você vai ofender. Mas, especificamente, gente, assim, a gente precisa ter senso de ridículo, cara. Quando eu tenho na minha frente um cara que definiu o REST e que definiu, eventualmente, o próprio parte do HTTP, eu vou sentar e vou ouvir o que o cara fala, bicho. Eu não vou tentar acusar o cara da falácia da autoridade. Na verdade, eu que estou usando a falácia. Ele criou o negócio. Sabe? Então, pô, para e ouve, cara. Então, respondendo a sua pergunta, cara, eu acho que o mercado é muito orientado a buzzword, cara. Eu acho que o mercado é muito orientado a buzzword, cara. O mercado é muito orientado a buzzword. E tem muito dev que quer ser chamado de arquiteto porque acha que isso é mais chique. Mas não sabe escrever nada sobre arquitetura. É um bom exemplo de um desculpa, mas um amador remunerado e cara e incompetente, porque competência indica prontidão, cara, nada pior para uma organização do que o incompetente motivado essa é uma boa frase essa é da cancelamento da internet nada pior do que o incompetente motivado Leandro, querido, você deve estar com a sua mãozinha virtual cansada aí, cara, desculpa pelo tempo que eu tenho essa mania de estourar os tempos sempre. E galera, só pra vocês saberem, o Leandro vai ser o último participante de hoje, porque senão o Elemar e todos nós aqui vamos ficar eternamente aqui nessa sala, porque a vontade que eu tenho nesse momento é sair perguntando e sabe quando você fica com comichão de querer fazer e perguntar e falar, mas tem galera na Europa, tem galera nos lugares, então manda aí, doutor Leandro. E eu proponho o seguinte, se for o caso, você pode mandar pra você uma compilação das perguntas, eventualmente a gente daqui a pouco faz uma sessão para responder só as perguntas que não foram respondidas. A gente pode marcar uma sessão de Q&A aberto, total, sem PowerPoint do Elemar, e saca que o Elemar pergunta e que ele responde. É, cara, você vai tirar meu PowerPoint. Ai, meu Deus. Exatamente. Vai tirar minha bengala, cara, onde é que eu me apoio? Tá bom. Diga, Leandro. Bom, legal. Primeiro, prazer, pessoal, essa mentoria aqui com vocês. Está sendo muito, muito gratificante mesmo. Obrigado. Minha pergunta é em relação a um framework que é um dos mais famosos em relação à arquitetura, o Togaf. Gostaria de saber se por onde você passou, claro, pequenas empresas dificilmente vão usar, médias também, eu tenho focado nas maiores, eu gostaria de saber qual foi o contato que você viu do pessoal da arquitetura tendo ali no dia a dia, se você conseguir falar também das fases mais usadas, porque tem uma questão também de arquiteto corporativo que já é um pouco diferente do que a nossa visão aqui. Esse é um ponto importante, cara. Obrigado. É importante a gente fazer uma distinção aqui, tá? Entre arquitetura de software e arquitetura corporativa. A arquitetura corporativa, ela versa sobre quatro dimensões. Design de negócios, porque por alguma razão, quando traduziram em português, não traduziram como arquitetura de negócios, então o certo é design de negócios embora em inglês seja business architecture, você tem design de arquitetura de software e soluções, arquitetura de dados e arquitetura de infraestrutura a arquitetura corporativa ela cobra essas quatro dimensões embora ela tenha esse nome de arquitetura e tenha três dos quatro associados forte com TI, ela não é uma disciplina de TI, tá? tipo, arquitetura corporativa não é uma disciplina de TI, é uma disciplina que inclui TI, Leandro, mas ela não é específica da área de TI deixa eu te mostrar um exemplo prático pra deixar claro o que eu tô falando aqui, tá? eu vou pegar aqui na ontologia da Exímia, que é a minha empresa, e eu tive um vídeo, inclusive, no meu canal, que é um vídeo que eu falo exatamente sobre esse cara aqui. Esse aqui é um exemplo, cara. Aqui está o vídeo que eu fiz. Arquitetura cooperativa, modelando, tal, tal, tal. Cara, esse aqui é um modelo, Leandro, feito em Archimate, que é uma linguagem de modelagem desenvolvida para suportar autógrafo entre outras funções, tá? E aqui o que você percebe, por exemplo, que eu estou modelando? Cara, eu estou modelando uma série de etapas de maturidade de uma empresa, que são platôs, gaps, enfim, esse diagrama, o que eu quero destacar para esse diagrama aqui, é que esse diagrama tem pouco ou nada a ver com tecnologia. Entende? Pouco ou nada a ver com tecnologia. Ele fala sobre essa modelagem aqui, é uma modelagem sobre um processo de transformação numa empresa onde você tem os platôs, que são os estágios de implantação, você tem eventualmente os gaps, que é o que mudou entre uma fase e outra, você tem eventualmente ali uma série de entregáveis que não são necessariamente entregáveis técnicos e você tem uma série de atividades. Quando você pega eventualmente o Toga, o Toga vai falar, por exemplo, sobre como você modela dentro de uma organização os principais stakeholders, os interessados, os drivers estratégicos e mais uma pancada de coisas. Tudo isso é importante sob a perspectiva de arquitetura corporativa e não sob a perspectiva de arquitetura corporativa e não sob a perspectiva de arquitetura de software. Sobre teoria dos conjuntos, dá para dizer que a arquitetura de software é uma parte da arquitetura corporativa, mas a arquitetura corporativa é, sem sombra de dúvidas, maior do que a arquitetura de software. É importante a gente conseguir diferenciar as duas coisas. Dito isso, Leandro, o TOGAF, especificamente, ele é um framework que normatiza a arquitetura corporativa e não necessariamente a arquitetura de software. Entende? Então, quando você vai passar nas organizações, existem gente com mais aderência ou com menos aderência à arquitetura corporativa. no Brasil especificamente eu sou super defensor de arquitetura corporativa é uma das minhas áreas de especialidade mas isso como eu disse, transcende a área de tecnologia mas cara, o maior case que nós temos no Brasil de arquitetura corporativa talvez seja a Petrobras e o Segunda Gerdau, são grandes empresas o TOGAF de maneira geral ele te descreve um processo você pode procurar por exemplo ADM TOGAF procurar, por exemplo, ADM Tógaf, ADM diz, por exemplo, sobre os ciclos de implantação do Tógaf, e aí você tem essas fases, acho que é essas fases que você estava mencionando aqui. Cara, percebe o seguinte, ele fala sobre transformação dentro da organização. Então, simplificando a coisa para você, o Tógaf, a arquitetura corporativa ainda não é uma prática tão comum e tão conhecida nas empresas brasileiras, é algo que está crescendo em abrangência, em empresa gringa é super conhecido, mas o Tógaf como framework, ele é o principal framework, tem dois frameworks hoje que são dominantes em arquitetura corporativa um é o Togaf e o outro é o Zachman, o Zachman foi o cara que idealizou a ideia de arquitetura corporativa lá atrás no passado também, tem um framework que também é super influente são frameworks densos pesados e que precisam ser tropicalizados se você tentar implementar o Togaf as is, cara, você mata 90% de qualquer iniciativa de arquitetura para a maior parte das empresas, porque não precisa de tudo aquilo, certo? Então, respondendo a tua pergunta, adesão no Brasil ainda é baixa, no estrangeiro é mais fácil, e eu comecei uma cruzada com o último vídeo que eu botei no meu canal, é o primeiro vídeo em que eu começo a explicar fundamentos de arquitetura corporativa que eu entendo que acabam extrapolando. Agora, importante, você não precisa saber TOGAF para fazer arquitetura de software. O TOGAF é sobre arquitetura corporativa que inclui a arquitetura de software, mas não é premissa para arquitetura de software, mas não é premissa para a arquitetura e software por si. Cara, eu já... Podido, porque você vê assim até onde vai impactar, até mesmo na organização, né? Você consegue fazer esse mapeamento. É que para as empresas que eu estou atualmente procurando um trabalho como arquiteto de soluções e mirando em algumas empresas, eu sou do segmento bancário e elas estão exigindo o Togaf. É, mas é normal, porque perceba, você tem aí um mapeamento que é mais corporativo e aí aproveitamos para fazer outra distinção, a distinção entre arquitetura de solução e arquitetura de software. Arquitetura de solução, quando fazer outra distinção, a distinção entre arquitetura de solução e arquitetura de software. Arquitetura de solução, quando você pega, por exemplo, os providers de nuvem, você vê que o pessoal da AWS, da Microsoft, enfim, fala muito sobre arquitetura de solução. Arquitetura de solução é sobre você fazer composição de componentes. Na maior parte dos casos, você compõe e reorganiza o componente para conseguir entregar uma solução nova, não necessariamente implicando o desenvolvimento de um componente novo. A ênfase na arquitetura de solução não é na construção de componentes novos, é especificamente na reutilização dos componentes. Já na arquitetura de software, a ênfase é na elaboração do sistema novo, ou pelo menos gerenciar o ciclo de vida de um componente. A dimensão da arquitetura que você está considerando é um pouco diferente. Por que é mais natural que você fale sobre Togas quando você fala sobre arquitetura de solução? Porque, cara, você precisa conhecer bem o repositório das soluções ou dos componentes que já estão disponíveis dentro da organização. Então, existe essa intimidade. Agora, lembra que eu te falei sobre o RH das empresas não saber como chamar o senior senior e chamar o senior senior de arquiteto, cara, a mesma coisa acontece aqui, cara, tipo alguém ouve falar sobre framework de arquitetura e bota lá, da mesma forma como se pede inglês obrigatório pra uma empresa onde ninguém fala inglês, entendeu? Isso é, infelizmente, mais comum tipo, a pluralidade de gente se colocando à disposição, caraição eventualmente esse tipo de know-how diferencia, mas pra mim deveria ser elemento qualificador se você é um arquiteto de solução que conhece qualifica, te diferencia mas não deveria ser critério de filtro e aqui fica mais uma dica importante pra carreira, tá Leandro? todo processo de seleção é sempre um processo de duas vias lembra a empresa está te selecionando mas você também está selecionando a empresa tenha muito cuidado ao ingressar numa empresa que não sabe o que pedir quando vai contratar um profissional talvez você tenha um favor no sendo contratado por essa empresa talvez mesmo e essa bagunça entre as nomenclaturas existe a rodo mesmo. Tenho visto muito, muito, muito isso. Bom, obrigado. Obrigado e boa sorte para você, cara. Acompanha lá no canal, porque eu fiz um primeiro vídeo sobre arquitetura corporativa e a minha promessa é gravar uma pancada de vídeos novos para falar sobre esse tema. Tentando fazer de uma forma que seja leve, descontrole de novo, né? Se for difícil, eu não entendo. E esse é o problema do Togaf, aliás, tá? Cara, você estudar Togaf, se você tentar estudar Arquimate, em cima das referências que tem na internet, cara, você... Meu Deus. Ah, não dá. Eu instalei um software aqui que ajuda nesse processo e comecei a estudar em cima dele, porque ele mostra processo por processo, entregas por entregas e tudo mais. Parabéns, mas deixa eu dizer uma coisa para você, lembra que o teu tempo é curto. Cara, uma última, o Wesley, eu fico quieto e você faz a conclusão. Eu já usei esse exemplo algumas vezes, acho que é importante deixar claro pra você sobre a questão de liderança, carreira e tudo mais eu gosto muito de usar uma alegoria que eu falo que é a alegoria da rosa você não encontra uma rosa bonita na natureza porque a roseira estruturalmente, eu sou um cara que acredita em Deus mas acho que ali nós temos um problema de design a roseira não é uma planta muito inteligente a roseira não consegue diferenciar, por exemplo, um botão de rosa que está bonitão e que vai dar uma rosa bonita do botão de rosa que está morto. Enquanto está o galho preso na roseira, ela manda energia para os dois. Consequentemente, cara, a roseira também não consegue diferenciar um botão de rosa que está bonitão e outro que vai ser meco-meco. Imagina, você manda energia para o que está morto, imagina para a rosa meco-meco. O segredo da rosa bonita, meu amigo Leandro, o segredo da rosa bonita é o podador. Cara, na floricultura tem um cara que vai lá e verifica se esse botão está morto, vai lá e corta fora. Esse botão está vivo, mas não vai dar grande coisa, que reconhece quais são as iniciativas que eventualmente vão ter capacidade de gerar algo bonito, entende? De certa forma, você precisa ser o podador da sua vida, irmão. Cuidado, porque a sua quantidade de energia é limitada. Daqui a pouco você está gastando energia boa com o botão de rosa morto. Você está gastando energia boa com o botão de rosa meco-meco. Daqui a pouco você pode usar esse tempo que você está usando para aprender sobre a Kimate, por exemplo, para aprender alguma coisa que pode te ajudar a fazer uma rosa mais bonita. Enfim, hashtag fica a dica, né? Assim, você pode ignorar o que eu estou falando e talvez essa até seja a coisa mais razoável a fazer, mas eu daria essa recomendação. Curso de jardinagem. Tivemos até curso de jardinagem hoje aqui acho que eu captei gratidão galera, aqui a gente tem curso de jardinagem quem um dia pensou que numa pós-graduação você ia aprender mais sobre jardinagem então, aqui temos de tudo, galera. Pessoal, Elemar, cara, queria agradecer demais aí a sua presença. Cara, foi um papo assim muito bom, um papo super descontraído. Deu pra aprender muito. Teve muita gente questionando, teve interação. Eu acho assim que foi fantástico. Cara, queria agradecer demais. Novamente, galera, deem uma olhada na mentoria do Elemar, porque realmente vale a pena. É um investimento que vale a pena, vai ajudar vocês também ao longo da carreira. Então, super recomendo. E Elemar, novamente, muito obrigado por ter estado aqui com a gente e obviamente, pessoal, valeu aí por vocês estarem aqui a gente já passou um bom tempo ainda, tem 230 pessoas aqui batendo um papo num Zoom, né? Então valeu mesmo por vocês estarem aqui, prestigiando até o final quem não pôde ver até o fim, a gente vai compilar isso de uma fim, a gente vai compilar isso de uma forma, a gente coloca na plataforma pra quem perdeu na metade, quem não pôde participar. Mas, Elemar, suas palavras de despedida, por favor. Despedida de até breve, na realidade, né? É até breve mesmo, gente. Assim, fica o convite. Mais uma vez, Wesley, é um privilégio, uma honra. Eu tenho o privilégio de gostar muito do que eu faço. E, assim, como padrão da minha vida, eu com frequência sacrifico qualidade de vida pra qualificar a vida. Poxa, tá aqui até as nove e meia da noite, gente da Europa que eventualmente tá nos acompanhando, tá entrando madrugada dentro, cara, você tá sacrificando qualidade de vida, mas eventualmente esse esforço serve pra qualificar a vida. Eu faço isso de maneira recorrente. Hoje, de certa forma, tá em Caxias, num hotel, longe da minha família, até tarde com vocês, po longe da minha família, até tarde com vocês, poxa, isso é de certa forma uma decisão que implica em sacrificar a qualidade de vida. Mas eu entendo que, pô, é sobre qualificar a vida. E conversar com vocês foi uma oportunidade de qualificar a vida pra mim, tá? De verdade. Então, fico esperando o contato de vocês, vocês me encontram como elemarjr em todas as redes. Se você tá no seu momento pra uma mentoria comigo, as redes, se você tá no seu momento pra mentoria comigo vai ser muito bem-vindo, se você não tiver no seu momento, tá tudo certo, vocês estão em excelentes mãos, tá cara, assim, não eu conheço muita gente que trabalha com capacitação mas pouca gente que leva capacitação tão a sério quanto o Wesley a minha empresa a Exímia, né, o Wesley já falou sobre isso a Exímia é uma empresa de consultoria, assessoria eu tenho mentoria pra executivos o mundo inteiro a coisa está funcionando e pra mim, cara, capacitação é algo super importante, mas tem um cara que eu percebo e que eu tenho a sensação que leva capacitação como uma coisa muito mais séria até do que eu levo é o Wesley, vocês são excelentes, irmãos. Se por acaso for momento pra gente conversar mais, participar da mentoria, que bom. Eu também tenho um clube de estudos, se você quiser participar, tem um monte de coisa lá sobre algoritmos, mais discussão pesada, vai ser legal também. Mas, cara, se não der, tá tudo certo. E fica aqui minha gratidão. E mais uma vez que eu falei, cara, pra me posicionar, Wesley, eventualmente eu corro o risco de ofender alguém. Então, se durante a minha fala hoje em algum momento eu ofendi alguém, peço desculpas, mas eu também digo o seguinte, eu acho que aprender a lidar com o dissonante é fundamental pra que você cresça. O cérebro que cresce é aquele cérebro que encontra alguma coisa diferente se você só vê o mesmo você fica sempre igual e a gente não pode ficar assim então Wesley, mais uma vez obrigado obrigado a vocês e a gente bate papo no Instagram, bate papo no Twitter minha rede social mais presente é Instagram e LinkedIn Twitter eu tenho usado bem menos do que eu deveria mas enfim vai ser bacana conversar mais com vocês, que seja o início, né, de, poxa, né Wesley, tipo, a gente ouve, cara, uma coisa interessante, Wesley, você não tem ideia da quantidade de gente que fala pra mim, pô, Alemar, comecei a conversar ou acompanhar mais o que você faz, desde uma live sua que eu vi lá no Full Cycle, sabe? Eu digo, caramba, que legal, é sobre construir pontes, né, é sobre construir pontes. Show de bola! Lemar novamente, cara, muito obrigado, valeu aí pelo tempo, demais, e pessoal, valeu aí pra vocês estarem, muito boa noite, fiquem com Deus, que vocês tenham aí uma noite abençoada, um dia maravilhoso