DevEx: O Desenvolvedor no Centro da Tempestade da IA
Convidados
Juliano Martins
Country Manager @ nullplatform
Armando de Vilhena Moraes Nogueira
CPTO @ Segura
Explore o episódio
A experiência do desenvolvedor nunca foi tão central quanto agora. No meio de toda a euforia em torno da inteligência artificial, das promessas de produtividade e das métricas que surgem a cada semana, existe um profissional tentando entender qual é o seu lugar nessa transformação. Será que o dev virou apenas um revisor de código gerado por máquina? Será que os departamentos de TI vão desaparecer como aconteceu com as gráficas das empresas nos anos 70? E, principalmente, como medir o valor de alguém que antes era avaliado por linhas de código e pull requests, num mundo onde isso virou commodity? O DevEx, ou experiência do desenvolvedor, está no centro de uma das discussões mais urgentes do mercado de tecnologia. E é exatamente sobre isso que esse episódio se debruça. Wellington Cruz recebe Juliano Martins, Country Manager na nullplatform e ex-arquiteto responsável pelo Fury, a plataforma interna do Mercado Livre, e Armando de Vilhena Moraes Nogueira, CPTO da Segura, líder de mercado em proteção de identidade no Brasil. Os três, todos engenheiros com trajetórias longas na área, colocam na mesa uma conversa honesta e sem filtro sobre o futuro da profissão. A conversa passa por temas como métricas de vaidade disfarçadas de produtividade, o absurdo das metas de consumo de tokens, a morte do "tradutor de português para Java", o papel crescente do harness e dos guardrails na geração de valor real, e por que a agilidade hoje mora na plataforma e não mais no sprint de duas semanas. Conceitos como Dora Metrics, context as a service, SLMs corporativos, arquitetura agêntica e a nova lógica do MVP em horas são debatidos com profundidade e sem jargão vazio. Tecnologias como Claude Code, MCP e frameworks de especificação para agentes aparecem não como buzzwords, mas como ferramentas que esses profissionais estão usando no dia a dia. Juliano e Armando têm décadas de construção em tecnologia e falam com a autoridade de quem está vivendo essa transformação de dentro das empresas, não de fora delas. A conclusão que emerge do episódio é poderosa: o desenvolvedor que sair do papel de vítima e assumir o de protagonista tem pela frente um dos momentos mais ricos da história da engenharia de software. Mas quem ficar parado esperando que a onda passe vai encontrar apenas o fundo do oceano. Se esse episódio mexeu com você, compartilha com quem precisa ouvir, manda no Slack da empresa, recomenda para quem ainda está em negação. E se quiser apoiar o PPT no Compila, se torna membro aqui no YouTube ou contribui via [email protected]. Cada apoio ajuda a levar esse tipo de conversa para mais profissionais.
- Abertura: O Desenvolvedor no Centro da Tempestade da IA
- Luto ou Evolução? O Impacto da IA na Identidade do Dev
- O Fim do 'Tradutor Português-Java': Quem Vai Sobrar Nessa Virada?
- Vibe Coding vs. Engenharia Real: Como Operar IA com Qualidade
- Context as a Service: O Próximo Grande Salto no Desenvolvimento com IA
- Métricas de Vaidade: Deploy, Linhas de Código e Consumo de Token Não Medem Nada
- Como Medir o Dev de Verdade: Da Métrica de Fluxo ao Valor de Negócio
- O Gargalo Está no Upstream: Por Que o Dev Sempre Paga o Pato
- IA em Pontas Não Funciona: Como Integrar o Fluxo Completo com Inteligência
- O Departamento de TI Vai Desaparecer? A Analogia com a Gráfica dos Anos 70
- Compliance, Segurança e Gates: Como o Harness Substitui o Comitê de Arquitetura
- O Cargo Mínimo Será Arquiteto: O Fim do Dev que Só Escreve Código
- Conselhos para Devs em Negação: Desconstrua Agora ou Fique para Trás
- Recado para Gestores: Seja Builder, Cuide da Saúde Mental e Aprenda a Surfar as Ondas
- Encerramento e Como Apoiar o PPT no Compila
Essa capacidade de você ter essa satisfação pela pela transformação, pela pela criação, ela inerente à nossa profissão e e tá dentro de cada um aqui. O departamento de TI aconteça a mesma coisa que aconteceu na década de 70 com a o departamento de gráfica das empresas. Eu acho que vai acontecer com TI, acho que vai desaparecer na maior parte das empresas.
A meta em dólar, né? Você tem 18 para usar diariamente. Se você não usar, eh, você pode ser demitido. Assim, é assustador o negócio. Onde é que tá a agilidade?
Tá, tá no, no tá no harness, cara. Onde é que tá arquitetura? Tá no harness.
Porque tem certas coisas que você não tem que discutir mais. Você já sabe como é que é. Muito bem. Muito bem, meus amigos do PPT não compilha. Estamos aqui para mais um episódio e hoje esse episódio é para você.
desenvolvedor, profissional de tecnologia, que está vivendo todo esse momento de transformação.
Hoje a gente vai falar aqui sobre a experiência do desenvolvedor, também popularmente chamado de Devx, né? E como que está a transformação desse momento de trabalho que a gente tá vivendo essa loucura de cada dia, uma coisa diferente? como a gente precisa ser avaliado, como a gente precisa ter comportamento no trabalho. Isso é uma coisa que a gente vai discutir aqui. Eu tô com dois caras aqui que são especialistas para falar do assunto.
Juliano Martins da New Plataform, já veio aqui algumas vezes, um cara monstro que tá sempre aqui com a gente. Dá um oi pra galera aí, Juliano.
E aí, galera, tudo bem?
E também aqui o Armando de Vilhena da Secur Security. Fala um pouquinho de você, Armando, e e dá um oi pra galera aí, fala da segura.
Oi, pessoal, tudo bem? Obrigado, obrigado pelo convite. Eh, bom, eu sou, meu nome é Armando, eu sou CPIT da Segura. Nós somos a líder de mercado no Brasil em proteção de identidade, uma das maiores empresas de cybersegurança do Brasil e e estamos nessa somos parte também dessa dessa transformação da da segurança da IA, dos agentes e tudo mais. Estamos fazendo parte disso e vivendo a transformação internamente, né? Eu particularmente sou engenheiro desde criança. Também tô vivendo e discutindo essa transformação que nós engenheiros e desenvolvedores estamos vivendo. E então é um prazer falar desse assunto porque é algo muito latente nas nossas vidas. Aí show de bola. Hoje a gente vai falar aqui sobre basicamente o futuro da nossa profissão, né? como que a gente tá vivendo esse momento, como que a gente precisa ter métricas para avaliar o nosso trabalho, qual que vai ser a nossa relação com as outras áreas da empresa?
Como que o nosso fluxo de trabalho melhora, qual que vai ser o nosso papel em TI daqui em diante, como que isso tudo vai funcionar daqui pra frente, né?
Quais são as melhores métricas para avaliar o trabalho, como que a gente vai trabalhar daqui em diante de uma forma mais coordenada com as outras áreas, será que a IA vai desaparecer? Será que a a IA vai fazer a TI desaparecer?
Que que vai ser daqui pra frente, né?
Então vamos discutir isso daqui porque é um assunto mega pertinente que envolve todos nós profissionais de tecnologia e é uma discussão que não termina aqui. É porque cada dia as coisas estão evoluindo de uma forma cada vez mais rápida, né?
Sim. Serão opiniões muito sinceras, honestas. A gente espera não ser cancelado no final.
É. Espero não ser cancelado, não eh eh não ser odiado, mas mas acho que é isso. Acho que a gente parte desse de desse ponto de partida que eu estou se pitiou, como em algumas outras vezes na vida, mas eu sou engenheiro e sou programador desde criança, então eu também sou parte disso. Aqui nós temos três devs engenheiros na mesa e cada um refletindo sobre o futuro da sua carreira, né? Então acompanha com a gente que é um papo muito honesto que vai fazer você refletir também. E se você acha que nós contribuímos pra sua vida profissional, você pode ser contribuidor do PPT no CPIL. Tem algumas formas de você ser contribuidor. Você pode ser membro do PPT no Cupila lá no YouTube, do lado do botão de inscreva-se vai ter o seja membro. Sendo membro, você vai ter acesso aos episódios de forma antecipada e vai ter algumas vantagens daqui em diante pro PPT no compila. E se você quiser fazer uma contribuição pontual, você pode fazer diretamente no [email protected].
Beleza? E sempre fica o nosso pedido para você deixar o seu like, para você compartilhar o episódio, mandar no slack da empresa, mandar no WhatsApp da família, mandar no na lista de spam que você tiver aí, manda só, manda, beleza?
Já ajuda muito a gente e segue a gente nas redes. Vamos lá que o papo hoje é mega importante e tá muito bom. Bora.
Eh, esse episódio para mim ele ele é muito importante porque a gente tá num momento de mudanças que a gente nunca sabe se acabou, se vai continuar, se amanhã vai ser diferente do que tá sendo hoje, se depois de amanhã vai ser diferente de amanhã, né?
E muito a gente fala sobre os resultados da inteligência artificial, a aceleração que a inteligência artificial traz, mas no meio de tudo, de toda essa transformação, tem uma pecinha chave ali no eh passando por toda essa transformação que é o desenvolvedor.
Então, eu quero discutir com vocês nesse episódio como tá sendo a experiência desse cara durante todo esse processo.
Era um cara que até poucos anos atrás tava acostumado a abrir gira, fechar gira, codar, fazer por request e esperar gemmud. Essa era a vida dele, tranquila, sossegata, fazendo o que ele gostava. E hoje a vida desse cara virou de cabeça para baixo, né? Então, quero discutir com vocês aqui sobre esse ponto de vista, né, a avaliação desse cara, como que esse cara eh tá vendo esse momento, né? Acho que esses pontos sobre a experiência dele é importante ser discutido, né? Eu queria começar com vocês falando sobre produtividade.
Como vocês estão vendo nesse momento os desenvolvedores lidando com tanta pressão por produtividade? Já vamos falar de métricas daqui a pouco, mas cada vez mais pressão para mais entrega e cada vez mais o dev sendo praticamente um revisor e não desenvolvedor, né? Como que vocês estão vendo isso?
Quer pegar?
Bom, eh, eu é interessante, eu acho, tem desenvolvedores e desenvolvedores, né? A gente que faz isso desde criancinha, né?
Eu costumo dizer e e é verdade, eu comecei a programar com 8 para 9 anos, mais ou menos. fiz isso a minha vida inteira, passei a vida inteira estudando isso.
E então eu sinto um pouco na pele e gosto de sentir isso, né? Essa essa dor e a delícia assim dessa transformação, porque a dor, por um lado, é deixar para trás o que a gente entendia como valor do que do nosso conhecimento, da nossa construção, né? Então tem um tem um luto aí, né? Aí tem um abandono para ser feito.
Mas a parte interessante é que isso traz uma clareza da da do valor do nosso talento, inteligência também, que e e também um pouco o tesão que a gente sempre teve sobre as coisas, que foi muito mais do que escrever numa língua diferente, que não era o português, né, mas mas tesão de materializar uma ideia, né?
E e para mim, eu tenho observado muitos diferentes eh eh perfis de de desenvolvedor e tenho tentado me aproximar mais e e valorizar mais o o os desenvolvedores que têm esse perfil, que eu acho que é o que faz sentido hoje, né?
eh eh de dessa desse desse mundo assim do que era um cara que era um tradutor de português para Java e o cara que é um construtor, que ele vive de materializar coisas, de transformar ideias em em artefatos que efetivamente geram valor, né? E então acho que boa parte do desconforto dos desenvolvedores hoje vem primeiro da má gestão, que é um problema, né, no geral, que que é uma gestão que parte de um lugar de baixo entendimento sobre a tecnologia, sobre o estado da tecnologia e os passos do estado da tecnologia.
Aliás, isso é um problema no mercado que parece que não se resolve nunca, né?
Como a gente tem gestor que não entende o que tá gerindo na TI. É impressionante.
E e isso é, enfim, só um parêntese aqui, mas é um problema que sempre existiu e parece que tá longe de acabar, né?
É, acho que dificilmente vai vai acabar isso, mas é isso, né? Então, então acho que tem uma coisa que vem parte da má gestão, esse parte do desconforto vem da magestão e essa coisa da das métricas malucas que não fazem sentido e e tudo mais. E parte também vem de uma falta de entendimento de do próprio valor sobre sobre o processo, né? e até da falta de entendimento de uma visão de futuro que aí ninguém tem mesmo. E e aí que nós como líderes de tecnologia também tem que trabalhar isso, né, de ó, vamos entender o valor junto, vamos entender onde tá e vamos tentar deixar isso mais claro, né? Mas, mas também tem uma grande massa de desenvolvedores que que não tem essa concepção mental e e que também partiram para ser desenvolvedores só porque tava dando muito dinheiro por muito tempo e que não tem esse tesão e que de repente nos próximos anos vão ter que se reposicionar, vão ter que ir para outro lugar porque nunca foi talvez o o o grande tesão da vida dele ou o o o que eh o que havia de valor intrínseco na personalidade e na intelectualidade, né?
Eh eh então eu eu acho que tem uma mistura, sabe, nesse desconforto entre essas coisas e e a e a minha busca hoje como como líder de desenvolvedores, né?
eh eh tentar identificar isso e ajudar essas pessoas a caminharem o bom caminho, seja para identificar seu lugar de valor, de potência, seja para de repente perceber que, pô, talvez seja a hora de mudar também, né? E e faz parte do jogo, né?
Sim. Uma coisa que você comentou aí, que foi uma palavra bem legal, foi desconstruir.
Eh, a gente precisa realmente desconstruir essa visão que a gente tem de valor, de eficiência. Você começou a pergunta, eh, como o desenvolvedor tá se sentindo nessa, pô, exigência de ser mais eficiente e etc. Mas o que é ser eficiente? também é outra desconstrução que a gente tem que fazer, porque hoje, como o Armando adiantou um pouquinho ali, eh, a visão de eficiência é entregar PR, entregar mais depósito, entregar linhas, não é isso, né? Então tá todo mundo aprendendo o que quer ser eficiente no final do dia é entregar o valor, que você falou várias vezes aí que é o que a gente precisa desconstruir a cabeça do desenvolvedor para ele entender, pô, que o que eu preciso entregar agora e no meio do caminho desconstruir o processo para isso, né?
E aí como me disso aí que vai ser com certeza as próximas perguntas, né?
É, pois é. E e um um ponto que você colocou, cara, que eu acho que ela ele é mega relevante, enquanto você falava, eu fiquei refletindo aqui sobre isso.
Eu quando eu aprendi a programar também muito precocemente com basic no ms também, o o que me atraiu nisso foi que eu copiava as os exemplos dos do help, colocava para funcionar.
E aí o que eu ia alterando, eu ia meio que desvendando aquele código, aquele enigma, eu começava a entender o que que eu mudava, que que refletia. Isso foi isso que me atraiu no desenvolvimento quando eu comecei. Então, essa capacidade de você ter essa satisfação pela pela transformação, pela criação, ela inerente à nossa profissão e e tá dentro de cada um aqui.
Isso sempre vai acontecer.
Eh, eu tô no momento e eu acho que os meus colegas de profissão de de arquitetura de TI tão num momento que é o momento de êxtase, porque eh como arquiteto você vê aquilo que você projetou se construir muito mais rápido e entregar valor ou falhar mais rápido, né? Então eu tô num momento que a arquitetura de TI para mim é fascinante o o momento que a gente tá vivendo. Mas aí o ponto que você colocou sobre o desenvolvedor ter essa sensação da da entrega da materialização, eu penso também muito naquele desenvolvedor que ele é tão ou era, né, antes do do que a gente tá vivendo agora, ele era aquele cara que fazia um trecho ali, abriu o gira, fechava num monolito ou num mainframe gigante e que ele tinha pouco acesso também de do que que ele tava gerando de valor. né? Isso porque muitas empresas não passaram nem pela etapa da transformação digital, da produtização, onde o cara tá envolvido naquilo que ele tá desenvolvendo. Eu acho que esse cara ele tá muito perdido agora.
Esse tá porque ele tá ele tava acostumado a ser feliz que [ __ ] hoje eu fechei cinco dias, fiz três PRs para quê? Eu não sei. Eu segui a regra de negócio, tava no gira e esse cara agora ele tá se vendo totalmente substituído.
Sim, né? E e cara, como e assim isso vai continuar existindo? Porque vai ter gente trabalhando em bancão codando pro mainframe, vai ter gente trabalhando com um monolitão e empresas estão adotando IA e nem passaram por transformação digital.
Esse cara, ele tá com perdão do francês, tá [ __ ] não? É, eu eu tenho dito assim em algumas quando quando eu tenho falado desse assunto, né, em até em algumas empresas e discutido e e para mim o desenvolvedor ou programador, né, batucador lá, né, batucador, o tradutor português Java, esse cara, ele para para mim é o é o novo acendedor de poste. pianista de cinema mudo, telefonista de mesa. É, acabou.
O digitador de códigos, né?
É, morreu. Acabou. E e a gente tem que assim, quem demorar muito para entender isso vai ter problema naturalmente, porque mesmo assim quando mesmo que a gente fala para entender esse valor ainda do que a gente tá pegado, né, de [ __ ] o engenheiro de software que é assim um papel importante, o cara que pensa na materialização de uma forma mais estruturada, mas mas às vezes mesmo quando a gente fala disso, a confunde o que é ser programador, se eh eh se a gente não abandonar essa percepção de valor eh eh e sobre a produtividade, né? Enquanto a gente ainda tiver preso a métricas de fluxo, né? Eh, e essas pessoas que estão nesse lugar, eu acho que vão ter mais dificuldade, vão ter uma transição dura, difícil, né?
E e de novo, né, a gente como líder tem uma certa obrigação de de dar amparo de saúde mental para essas pessoas nessa transição dela. A a pelo menos até que enquanto elas tiverem nossos times, né? Mas não vai ser fácil não para quem demorar demais para perceber.
Faz um ano, quase um ano, eu fiz um post no LinkedIn que no post, em resumo, eu falei: "Cara, em 5 anos não existiram mais programadores e me cancelaram.
Meu Deus!" E enfim, aí vem aqueles argumentos do tipo, mas i a é bolha, isso não vai se sustentar, etc. Eu acho que as pessoas estão se apegando a algo que não existe. É a esperança, né? O é a banda do Titanic lá. Não, não tem como.
Tem, tem aquelas fases, né? ligação, aceitação, eh, não sei, tem muita gente em negação ainda.
Sim. E os modelos vão continuar evoluindo e os erros que cometem hoje vão cometer menos e menos e menos. E e tem gente, você ainda vê no LinkedIn o cara dizendo: "Não, porque aí alucina, meu amigo, nada alucina mais que o ser humano, cara.
Nada mais que o ser humano. Então é uma coisa assim, cara, não é por aí, não é isso.
Quero falar com você agora que ainda não conhece a Clever. Clever é uma empresa que já tem mais de 3 milhões de usuários em 30 países com 30 idiomas diferentes, que tem trazido soluções em blockchain, criptomoedas e ativos digitais. O objetivo da Clever é te dar liberdade financeira para operar esse mercado de cripto. Então, se você acredita nisso, se você acredita nessa liberdade, você já pensa como a Clever, vai conhecer os caras, é clever.io, estão contratando também pessoal para trabalhar com cripto, com blockchain. Então, se você tem interesse, se você tem conhecimento nessa área, procura a Clever. Se você gosta de criptomoedas, se você opera no mercado, você precisa conhecer a Clever, precisa conhecer as soluções da Clever.
Então o endereço tá aqui embaixo no vídeo. Para quem não tá no YouTube é clever. Vai lá, vai conhecer que realmente é um mercado sensacional.
Vamos comparar quem alucina mais, o modelo ou você de ressa?
Vamos ver até o fim. Eu não tô bebendo, vocês estão.
Mas esse esse ponto é interessante porque assim, eu peguei toda essa parte da evolução dos modelos de 3 anos para cá.
Observando o código desde quando a gente fazia o vibe coding, copiando e colando o código direto do chatt.
Era realmente era lama ali. Ali era lama. Você falava: "Cara, como é que essa [ __ ] implementou isso desse jeito?" Agora, se você pegar um cloud code com um bom framework de especificação e você e e uma coisa muito importante que as pessoas não não levam não leva em consideração nesse processo, para operar bem a IA, você precisa ter pleno conhecimento do processo de desenvolvimento de software.
Uhum. Não é sentar na frente e faz, ah, muda o botão, é claro. Se você segue isso e usa i como se fosse o teu estagiário desenvolvedor, o resultado ele é infinitamente superior do que a gente faria manualmente. Sim, isso é fato. Você pode olhar, revisar o código assim, eh, o que você pede sai. O que o que o que o que depende é o que como você pede. Se você não for específico o suficiente, eh, hoje a gente tá num eu, eu vejo que a gente tá numa plenitude já. E como você disse, os modelos vão melhorar e melhorando isso tende a ficar ainda mais trivial, né? Sim.
Porque hoje, cara, você não não precisa nem falar de um Fable, um Opus, um Opus 5, cara, é incrível para desenvolver.
Inclusive, para mim, o modelo tá resolvido.
É, também acho.
Eh, o o a questão agora é o Harnes, é são os guardios e e principalmente o processo cultural da empresa, porque é o modelo é o eu acho ainda sobre o modelo, eu acho que tem um, talvez tem uma evolução ainda sobre, ah, desculpa, sobre a qualidade da base de treinamento.
Uhum. E e isso eu acho que tem espaço para evoluir ainda, porque se o Harness hoje é muito importante ainda, já foi mais ainda e e à medida que o modelo foi evoluindo, o Harness foi se tornando menos importante, mas ele ainda é muito importante para padronização, para trazer aspectos de arquitetura, para reusar os seus componentes SDKs e e frames corporativos para aplicação de políticas e tudo mais, né? Eh, eh, mas paraa questão arquitetural, eu acho que tem uma evolução ainda do modelo que tá talvez mais ligado a ao refino do treinamento ou talvez o SLM.
É, pode ser um modelo esmalo, para você.
E isso isso pode ser também, pode acabar acontecendo isso, mas que no fim é isso, né? é você especializar a base de treinamento do modelo. Uhum.
Né? Porque ainda se você for ver, né, a base de código sobre o qual ele foi treinado é ruim.
Sim.
Que foi gerado por humanos inclusive, né? E aí então gera código ruim porque teve uma base ruim também.
Sim, né? E e isso eu acho que tá evoluindo ainda. Eu acho que tem um caminho de evolução.
Sim. E e esse é um dos pontos que eu marquei que que eu queria tratar com vocês, que eu já li alguns papers muito incipientes ainda, mas muito interessantes sobre isso, do contest as context as a service, tá? que nós temos uma tendência de que você tem um harness, um modelo na mão do desenvolvedor e você vai ter um contexto corporativo sendo entrega sobre sobre demanda para aquele modelo, para aquele desenvolvimento. Então você vai ter contexto sobre outras aplicações, sobre regra de negócio, sobre processo empresarial e e cara, eu vejo isso como uma expansão no fluxo total de desenvolvimento de solução, não só na geração de código, mas no no todo, né?
Por exemplo, isso pode ajudar um executivo saber o impacto de uma decisão dentro das suas aplicações. Se eu consigo ter esse contexto geral de regra de negócio, de legislação, de regulação, de código, de infraestrutura. Se eu tiver de fato um contexto sendo servido como serviço para dentro do modelo na na hora de desenvolver, isso fica extremamente underfit para aquilo que tá sendo desenvolvido. E hoje isso ainda falha, né? Porque o contexto ele ainda morre dentro daquele repositório ou muitas vezes dentro da máquina do próprio desenvolvedor. E aí muito do que foi inferido ali dentro do próprio LLM não propaga sim pro pros outros, né? Então aí você tem pouca economia de tokens, né, porque você tem reprocessamento e você e todas essas inferências que em conjunto poderiam dar um resultado muito legal ainda não não não não se conversam, né? E eu acho que isso é um caminho que de fato tá tá incipiente, mas eu acho que é um eh eh é um caminho inevitável e que isso de fato vai trazer uma evolução absurda, né?
Sim. É só eu tô falando aqui se quiser.
Tranquilo. É tímido. Sou de casa.
Eh, cara, é assim, eu eu já vejo um movimento principalmente das bigtechs, ah, nesse sentido de fornecer contexto no ciclo de vida, agora todo mundo falando de LDC, né? E esse contexto corporativo, ele vem sendo trabalhado através de plataformas, através de equipes multidisciplinares que vem construindo esse contexto, que trocando em miúdos é uma pseudo wick que os grandes modelos, o Harnes vai consultar, certo?
Uhum.
E assim, o que que eu tô vendo falando com o pessoal, conversei com o pessoal da Stripe, é um pessoal que tá muito à frente, né, principalmente em codificação agêntica. Já tem um projetinho que eu falo para todo mundo, cara, pesquisa o Minions da Stripe, quem tá assistindo aí, pesquisa. É muito, é sensacional que os caras fizeram, mas enfim.
Eh, hoje ainda tá muito caro manter e compartilhar um contexto corporativo.
Então, quem resolver isso tá saindo na frente, mas eles estão quebrando e e eles estão especializando SLMs lá, os SM language models.
E aí esses modelos são consultados pelo Harness de acordo com a necessidade. meu sistema vai interagir com marketing, deixa eu consultar, pedir um um desempate, uma opinião pro modelo de marketing. Tem se mostrado um pouco mais eficiente, menos caro do que servir esse tal contexto corporativo, porque realmente ficou caro, assim, performático, a gente tem performance para isso, mas é caro assim, então esse é o dilema hoje. Eh, mas vem evoluindo, amanhã já não sei mais qual vai ser.
Sim. É. Eh, e tinha, acho que tem muito essa coisa de a as as empresas e e e os times de engenharia acabaram criando ao longo do tempo muitos silos de documentação, né?
E e essa os que têm documentação. Exatamente. E às vezes é ou se dependendo de como for, é melhor não ter e criar um mecanismo bom de engenheiro reverso para criar contexto, né? Porque assim, no fundo, o grande ponto é que e e aí acho que tá tá o desafio tá muito nessa integração, né, do contexto com o harness, porque a a coisa que o contexto tem que ser acionável.
Exato.
Mais do que acessível até, né? E mais do que disponível, ele tem que ser acionável.
Uhum. Então, o cara, o que você colocou lá na a documentação de API, mais a documentação técnica, mais a as histórias que estão no Gira, mais do que a documentação do SDLC, assim, [ __ ] como é que isso se torna histórico de incidente, como é que isso se torna acionável de dentro do Harners, né? E acho que é essa é a discussão que que a que as que as empresas que a gente tá tendo lá na segura e acho que todo mundo um pouco tá tendo, né? E realmente assim, não veio ainda um player pro jogo com esse problema resolvido para dizer, talvez esse seja o próximo grande player desse jogo, né? Quem quem chegar com esse problema na realidade a gente tem empresas que estão muito longe, né, de discutir esse nível. É verdade. Claro.
Sim, a maioria a maioria tá muito longe de discutir um contexto compartilhado, comparativo, sequer um MCP para trocar sobre áreas de negócio, sobre domínios, isso tá muito longe ainda de acontecer, né? E e voltando no ponto de produtividade, eu queria uma avaliação de vocês como líderes de mercado. Como que avalia esse cara o desenvolvedor hoje? Porque eh se vamos voltar aqui fazer um um fastback para 2016.
A gente falava muito sobre modelo Spotify de desenvolvimento. Vocês lembram disso? Sim.
E aí era um orgulho pro Spotify falar que fazia sei lá quantas centenas de deploys em produção por dia. Aí você olhava o produto, era a mesma [ __ ] tocava música igualzinho, não né? Não mudava [ __ ] nenhuma, tá?
Então se deploy geraram o qu de valor?
Uhum.
Né? E aí a gente fala um pouquinho mais sobre métricas de de vaidade, né?
Beleza, eu faço um monte de deploy, eu tenho um monte de PR, tô derrubando o GitHub com PR automatizado, com agentes, que nem o GitHub abriu o bico um tempo atrás, não tá insuportável, constantemente o GitHub tá tá morrendo porque é PR o tempo todo. Por que que essas PR estão entregando?
É, não é essa? É é interessante ver isso assim. Ah, legal.
faz, você faz 200 deploys por dia.
Legal. Mas isso é desejável porque até se criou e e obviamente em alguma medida é verdade assim, eh a gente não deve acumular o IP não deploiado, né?
E acho que é uma máxima verdadeira, com certeza e tal.
Mas qual a granularidade desse wip? Qual o valor? É porque você tá faz deploy, tá bom? Vai fazer deploy para quê também?
Vai, você vai experimentar alguma coisa?
Porque aí legal, faz deploy embaixo de uma feature flag que não dá para ligar ainda porque tem independência, tá? Que para que que você fez esse deploy?
Uhum.
Por que não esperar para fazer na semana que vem? Uhum.
Quando tem, quando faz algum sentido, né? Só e e um pouco por isso, né? a gente vai criando essas métricas no meio do caminho. Agora até a mais engraçada, para mim, a mais engraçada de todas história foi essa de consumo de tokens, assim.
Uhum.
Foi a coisa mais absurda assim, cara. Tinha tinha desenvolvedor com meta de de consumo de token.
É porque métrica de fluxo a gente sempre ouviu. Agora métrica de uso é nova, né?
Porque se pôra, sei lá, o cara termina, o cara termina o o desenvolvimento dele do dia, vai jogar RPG com, com, com robô, para consumir token, né, pois é.
Então, mas é, tem muitas empresas estão nessa, né, assim, não me entra na cabeça assim, acho que já desistiram, né? É dessa, não, ainda tem. É, é, tem sem nomes, mas tem várias assim.
Tem, mas tem dólar, né? Você tem 18 para usar. diariamente, se você não usar, eh, você pode ser demitido, assim, é assustador o negócio.
Pois é. E é, é a primeira é até parece até engraçado falar isso, mas é uma métrica de de gasto e não de entrega. E cara, como assim? Isso faz algum sentido? É dos criadores do clique do mouse.
Exato. Mas, mas e fazer uma reflexão aqui com vocês, nós da TI, não estou falando de nós aqui ou de nós gestores de TI, mas a TI como um todo, ela sempre foi muito ruim de medir e avaliar pro resultado.
Uhum. O home office é o exemplo disso. E eh a gestão de TI sempre foi muito ruim disso, tipo, não, o cara tem que tá ali tantas horas fazendo, não importa o que, se ele tá lá 8 horas e entregou um valor, ele é melhor do que o cara que ficou 4 horas e entregou três. Uhum.
Né? Então, eh, a gente sempre foi muito ruim de medir valor, né? pelo menos os gestores de de tecnologia.
E isso é um reflexo agora nesse momento, né? Porque a gente medir entrega por consumo de token, por quantidade de linhas de código. Aliás, cara, na minha época, quando a gente aprendia a programar, você resolveu o mesmo problema com menos linhas de código, era melhor do que você resolver com muitas.
Então, por que que a gente tem uma métrica de quantidade de linhas de código, né?
Eh, e e eu percebo que a gente tá num num momento em que tá meia salara me salário meia calabresa. Ela não sabe muito bem como medir o desempenho de um desenvolvedor.
Eu vejo casos que o cara tá com a xhibata nas costas tendo que entregar eh features.
E tem cara que tá aqui com meta de consumo de token. se ele tá jogando RPG ou desenvolvendo software, a empresa, né? E e como é que a gente como vocês entendem que deve ser essa avaliação daqui em diante?
Então é assim, primeiro eu acho que esse problema de medição, ele tá lincado com o que a gente falou agora a pouco de do líderes não saberem pedir e por não saberem pedir, não entender o ferramentar o processo, não sabe como especifica algo que é mensurável, algo que agrega valor ao negócio. Então você vê lá no no gira do cara coisas quebradas como implementar a função de incluir assim, qual o valor de negócio assim qual e aí então eh eu acho que a gente tem que primeiro repensar nas empresas o que a gente pede e como a gente pede para depois entender como medir. E e para mim o que que eu vou medir? É o valor de negócio. É aquilo que você falou, ele entregou um valor de negócio por dia, OK? Não que não importa se ele ficou 8 horas, 10 horas, enfim. Então, eu eu começo aí para uma coisa muito orientada a isso, a a negócio.
Eh, as famosas dorams e e tudo mais são importantes, mas são um fluxo que o Armando falou. Uhum.
Eh, e isso são métricas para nós enquanto TI importantes paraa gente entender coisa do tipo, ah, quanto tempo eu começo de de concepção até a produção e assim por diante. E aqui só um um gancho, uma coisa que a gente eu tava pensando no caminho para cá que a gente pede mede muito mal também.
A gente começa a medir a partir do momento que a gente tá especificando ali e o desenvolvedor sentou até tá em produção, mas na maioria das empresas eu vejo que o gargalo tá até aqui na frente ainda.
Isso. Ex. E como medir isso aqui também?
Eu eu eu acho isso isso é é interessante e eu acho que é a chave do da coisa assim, porque a deixa eu só te fazer um pedido antes, não perca o seu raciocínio, só pra gente não ficar com com algo no ar. Vocês podem explicar rapidinho para quem não conhece o que é o Dora Matrix?
Resumo.
Tá, eu tô lembrando o de Mas é mudou. Nem vale mais, né? Assim, mas é já provavelmente quando for pro ar já mudou. Basicamente são métricas de de truput e de estabilidade, né? Assim, são cinco métras que se dividem em tropo de estabilidade, basicamente.
Deixa eu ver se eu pego aqui as siglas rapidinho, só pra gente fazer um rossário.
Eh, frequência de deploy, que é o D.
Isso.
Lead time for changes que é o que é nada porque mudou tudo, mas é porque os os nomes mudaram aí sigla não faz sentido.
É, então então e agora não são mais quatro, são cinco.
Tempo de mudança. O o percentual de falha, né, que é o change fail ha rate, o fail deploy recovery time, tipo, caiu, quanto tempo você faz um fall, né? É isso. Então, me time to recovery. Aí tá mudando tudo. É, enfim, provavelmente quando você tiver ouvindo esse episódio, pode ser que tenha mudado novamente. Mas pesquisa em Dora Metal.
Isso. Continua até o raciocínio.
Perdeu o raciocínio. Calma lá.
É, vamos.
Perdi mesmo. R, [ __ ] consegui atrapalhar o cara.
Mas não, mas ah, mas bom, voltou aqui assim. Acho que a gente criou e eu eu acho de novo, né, e eu tenho falado isso muito para as pessoas, porque eu acho que é uma coisa que vai ajudar a gente nessa transformação, eh, abandonar essa carapaça que a gente criou da TI como uma coisa assim. E eu tenho até uma, tenho várias teorias sobre porque eu fico pensando no futuro. Eu acho que talvez a teoria, a TI, o departamento de TI aconteça a mesma coisa que aconteceu na década de 70 com a o departamento de gráfica das empresas. Eu acho que vai acontecer com TI, acho que vai desaparecer na maior parte das empresas.
E polêmico, isso vai ser um corte, você sabe, né?
Hã, isso é polêmico, vai virar um corte.
Não, mas eu acho que é um dos cenários que eu acho plausíveis. pro futuro, assim, porque da mesma forma que você precisava de um departamento de gráfica para eh eh para para desenhar um formulário, alguma coisa, e aí vieram os processadores de texto impressora.
Uhum.
Acabou. E o software é a mesma coisa e pode acontecer a mesma coisa nas empresas. É, é um cenário plausível sobre isso. E acho que o negócio tá codando com Cloud Cowork hoje.
É, acabou, cara. Esquece isso. Não, não tá aí a coisa, né? Eh, e acho acho que ainda vai haver empresas de TI criando essas coisas que as outras empresas adotam de forma muito mais simples.
Uhum.
Né? Então, a gente tá querendo viver disso por mais tempo, acho que tem um trabalho também de abandonar de alguma forma essas métricas, porque acho que Dora Métric é importante, principalmente, por exemplo, para você medir impacto de uma ação.
Uhum. Então você, talvez os times de plataforma deveriam estar mais olhando para isso, mas os outros pro todo, não, né, pro que eles estão fazendo, mas o o os times que produzem artefatos de negócio deveriam estar mesmo muito mais olhando para métricas de negócio. E métrica de negócio é métrica que mexe o ponteiro, não é assim, porque o valor não é não é quantas telas, quantas funcionalidades, quanto, porque isso não tem valor de negócio real. Mesmo você entregou uma iniciativa, você entregou um épico, não traduz o valor de negócio real.
E aí é é mesmo você traduzir a a estratégia em métricas de negócio que sejam observáveis de alguma forma.
Então, se eu olhar, por exemplo, para um produto de TI, eu tô olhando ou dependendo do que é relevante, ou eu tô olhando para adoção, ou taxa de conversão, carrinhos abandonados, carrinho, ou eu tô olhando para e eh tempo de dependendo, né, do do que for a coisa, tempo de uso, tempo de jornada de alguma coisa que faz diferença. ou eu tô olhando aí, você tá olhando porque é importante, porque ajuda a a mexer o ponteiro da empresa e a gente abandonar as nossas métricas e olhar, porque a gente se protegia com uma coisa assim que é outra coisa que eu também tenho batido muito, assim, se protegia atrás da qualidade da especificação, não é isso?
Exato.
E não, eu se nossa Então eu acho que a gente tem que ser mais dono disso.
Uhum.
proativamente e aí para poder ser efetivamente dono do indicador que mexe o ponteiro da empresa e e não tem outro jeito para mim de de passar a medir senão esse, né? Agora, porque assim, todo o resto é muito manipulável pelo volume de artefato que você consegue gerar.
Sim.
Se não mexe o ponteiro, esquece. Sim.
E e aí mais uma vez a gente vai para coisa assim, pô, avaliar, a gente já sabia disso desde do manifesto ágil, né, assim, que avaliar a performance individualmente por indicadores não era eficiente, agora é menos eficiente.
Então você e até porque as pessoas trabalham juntas agora, porque melhora o contexto trabalhar junto, né? Assim, o PO com o Techlid, com o Dev trabalhando junto, melhora a construção do contexto. Então, o que que é a performance individual?
Ela é difusa. Se aquele time funciona bem, provavelmente tem boas pessoas ali.
E um time que funciona bem historicamente, a gente que já também liderou muitos times, percebe que times que funcionam bem naturalmente expulsam pessoas que não trabalham bem, naturalmente.
Naturalmente fala assim: "Tira esse cara daqui pelo amor de Deus". Não é isso?
Ou ele mesmo se ou ele se sente isolado e e ele mesmo isso, isso é um fato, né? Agora, uma coisa interessante que que você colocou, Julian, é a forma que a gente mede isso, que a gente mede a partir do momento que tá sendo especificado, etc. Chegou o pacotinho para ter desenvolver. Eu vou dar um exemplo aqui que não acontece aqui no Brasil, deve acontecer só na Noruega, mas algumas pessoas pode ser que se identificam com esse caso. O conselho de uma empresa, né, o board define que vai criar um novo produto, vai ter um novo produto, vai ser desenvolvido e etc. E eles definem um prazo razoável para pra estreia desse produto, para pro pro time to market desse produto de um ano.
Beleza? Dá tempo de cumprir todas as fases aqui. Parece ser um prazo razoável pro Burd. Esse esse produto ele vai ficar três meses no jurídico e no compliance para análise.
Aí ele vai ficar mais 3 meses no financeiro para verificação de verba, não sei o que lá, etc, etc, etc.
Aí depois de 3s meses, ele cai pra área de negócio fazer a definição de de de de especificações, etc.
No fim, cai na diretoria de TI faltando 3 meses para desenvolver. A diretoria de TI fica um mês discutindo entre eles como é que vai ser o processo, né? cai na mão de arquitetura e segurança fazer análise em duas semanas de um produto que tá em um ano e coitado do do dev vai ter dois meses para desenvolver um produto que tá na casa sendo falado há um ano.
Cara, isso tem que ser medido diferente.
Total, né? Tem que ser medido diferente, né?
Quem aqui não nunca se identificou com isso, né? Quando cai na ponta e aí que que acontece? Pula teste, né?
homologação ficar mal feita, porque vai ter que desenvolver eh eh vai ter que entregar mais rápido. E aí o board lá de cima, olha o produto que fez um deploy, deploy tava com problema, não atendeu expectativa, o cara olha para baixo, fala: "Mas gente, se tiver um ano para fazer isso?
A gente viveu muito isso, não, não tem como, continua vivendo." Então, a a grande tristeza, que tristeza, né? dos debates, né? Ó o corte aí, meu Deus. Eh, enfim, eh, que isso é recorrente. Eu tô indo em muitas empresas agora, eh, porque agora eu também vendo, né? Enfim, e essa é a realidade. E por isso que eu trouxe esse ponto de porque os deves vem chorar comigo. Cara, esse projeto tá sendo discutido faz tanto tempo e é essa situação que você disse. E então assim, eu eu acho que o nosso papel aqui é além de trabalhar nas nossas empresas para que isso não aconteça, para criar um processo mais ágil, né? Eh, é provocar aí o o board, provocar essas empresas aí e dizer: "Cara, vocês vão perder, vão perder campo, assim, vocês vão vão vão perder pra concorrência, porque hoje em dia tá muito mais fácil produzir e principalmente com AI, quem quem quem já tá indo para uma linha de produzir software mais AI native, esse processo aí morreu, esse processo, OK? vai no começo lá, tem uma discussão de budget, de validação, etc. Mas o o PIO quando ele começa a desenhar no dia um, no com a LDC, no dia um, ele já tá do lado do desenvolvedor, já tá do lado do do arquiteto e e já tá colocando na esteira ali para já ser desenvolvido, já ter algo de valor no dia dois, assim, e todo esse processo que, pô, no modelo Spotify lá trabalhávamos com sprint, duas semanas, etc., acabou. Hoje em dia nas empresas pioneiras, isso é é chamado de bolt. Agora é o quê? Horas, dia, dois dias no máximo já ter um um mínimo incremento. Então o momento agora é de se refazer, desconstruir. Essa palavra ficou e vai até o fim. Desconstruir e e ir para um fluxo assim, senão você vai ficar para trás.
Sim, sim.
É essa essas discussões sobre a nova agilidade, né, eu acho que são são muito boas e certamente vai ter muita consultoria picareta ganhando milhões com isso, né? ainda e cometendo erros até.
Isso é um caso engraçado porque você falou, eu lembrei de um, quando eu desenvolvo cuá, eu uso um framework chamado BMED, que ele reproduz um squad ágil, né? Então tem o tem tem a persona do do produto do do Cromaster, do arquiteto, etc. E aí, cara, é, eu acho muito engraçado, isso, é muito emblemático, porque quando eu ponho uma fiture novo no produto, que eu falo: "Ó, vamos fazer um um épico novo, aí o o product manager fala: "Cara, esse épico aqui, previsão dele é de 3 meses, cada sprint e tal".
Falei: "Beleza, pode desenvolver dali 3 horas, tá pronto".
É isso aí. Ué, mas como assim? Por quê?
Porque foi treinado com as métricas humanas, né? Então ele é treinado para só que, né, são coisas diferentes, né?
É o o próprio modelo responde, se você perguntar a a previsão para ele, ele responde, né, como se fosse uma métrica humana, não o desenvolvimento dele mesmo.
E é, não é, é interessante isso. E, e tem por que que tem que mudar, porque não é só mudar a medição, é mudar a lógica, né? E e nesse contexto da nova agilidade, assim, é muito mais barato hoje testar duas, três hipóteses do que discutir sobre elas.
É, sim.
Por meses.
Exato.
Para ver para onde vai, não vai. Testa, cara. Vai, põe aí no ar, vamos ver o que é.
E, e, e, e vamos experimentar esse negócio. Vê que testa com o discurso com dois, três clientes para ver qual que funciona. Faz um teste AB do com com o produto funcionando e até é até a visão sobre MVP, assim, qual que é o tamanho do MVP?
Porque um MVP, do tamanho do MVP que a gente fazia tr 4 anos atrás, ele não atrai mais.
Sim. E e hoje a gente tá falando de horas, né? O MVP tem que sair horas. A realidade é que o código ele virou commodity e ele é efêmero.
Sim.
Já não precisa mais você porque antes e e isso é uma coisa que nós da arquitetura temos que rever muita muita coisa também eh dentro desse paradigma.
Muita coisa era não vamos vamos ser ter parcimônia para ter reuso pra gente poder não ter retrabalho, etc. Cara, agora o retrabalho ele já não é mais um problema, porque estamos falando de máquina trabalhando em algumas horas, minutos, né? Então, se deu errado, meu MVP deu errado, minha hipótese deu errado, eu jogo fora, faço outra. É questão de horas, não, não é mais questões, questão de meses, né? Então, a própria forma como a gente tem de olhar o produto e a entrega tem que ser diferente e tem que ser medida diferente, né?
Sem dúvida. Até, claro, né? Assim, também corre o risco da gente parar de pensar e começar a tirar para todo lado, que, né, não é isso e e nada pode levar pro extremo, né, mas também mudou a lógica, né? Então eu acho que talvez e e talvez de novo, né, aí esteja parte do nosso valor também, né, de já saber o que funciona, o que não funciona, de já ter vivido algumas situações e de entender. Então você não vai testar todas as hipóteses também vai testar, escolher, testar dois, três, duas, três. Isso é é importante, né? E aí é tem certas coisas que vão fazer menos sentido até, né? A gente tava falando de cod, pô, vai ter cod, tá bom? E a e aí não pode ser não, po tudo não pode ser extremo, né?
Acho que as métricas são importantes para medir e eh eh extremos, né? Assim, vamos ver quais são os outliers. Eu olho para 10 times aqui, tem dois que um tá, um tá aqui, outro tá aqui e todo o resto tá aqui. Então, deixa eu olhar para esses aqui, né?
Alguma coisa tem se alguma coisa tem de muito boa ou muito ruim, né, que eles estão fazendo, que talvez vha a pena como lição aprendida. E para isso que acho que servem um pouco essas métricas, né? Mas mas todo o resto a gente vai ter que entender que algumas coisas são do jogo agora assim, né? Como Sim.
Você que tá aí escutando esse episódio bacana e quer levar toda essa tecnologia, essas novidades pra sua empresa e não sabe como, chama o time da VemBS. A gente pode ajudar vocês com desenvolvimento de software, com arquitetura de soluções, a entender os problemas que vocês estão vivendo e sair do outro lado com uma solução bem bacana. E se você tá escutando o podcast para aprender coisas novas, faz o seguinte, manda um e-mail pra gente no [email protected] e você pode fazer parte também do nosso grupo de talentos. Valeu.
Agora o time do Relações Públicas vai gostar mais de mim.
Mas o o ponto que eu acho que muita empresa vai ter que se readaptar é como fazer essa medição para fora da TI de fato, porque fora esse caso que a gente citou que acontece na Noruega do do projeto que fica fora da ter 8 meses e o cara tem um um mês para desenvolver, outras empresas também que eu tenho tido contato que são pessoas que que têm mais conhecimento sobre o fluxo do processo de desenvolvimento, que estão lidando muito bem com a EA, estão tendo tempo de espera pro upstream.
Então, cara, downstream virou máquina de salsicha, velho. Uhum.
Vai embora, tá alinhado, tá tá rodando bem, tem governança, tem processo e aí vai para homologar, o cara demora mais para homologar, tomar uma tomada de decisão do que para poder do que de fato para desenvolver, né? Então, em algum momento, essas empresas vão ter que medir esse todo para pegar essaciosidade também no upstream e entender como é que a IA pode ajudar esse cara lá na frente, né? Porque não adianta o executivo demorar duas semanas para tomar uma decisão de um produto que é desenvolvido em dois dias, né? Então, em algum momento a gente vai ter que olhar pro todo, né?
Sim. Eh, essa decisão já teria que ter sido tomada, né? antes. Eh, assim, um erro que eu vejo sendo repetido aí eh nas empresas é que estão adotando AI em pontas. E qual a ponta que todo mundo começou? é onde se gera o código e aí, como você falou, acelera e vira a gargala em algum momento. Então essa não é adoção efetiva de a a AI tem que tá inserida em todos os momentos, construindo aquele contexto, alimentando aquele contexto para quando chegar o momento da decisão lá, ele já saber, ó, isso foi discutido lá, então é isso que eu tenho que fazer. Então, ah, é assim, a gente deveria falar sobre a a a DLC aqui algum dia para e baixar um pouco mais tecnicamente, mas assim, isso veio para responder muita coisa, porque a a a IA tá tá tá construindo esse mega contexto desde o começo até o fim e o processo é um loop, é é incremental e e tudo realmente tá funcionando, saindo de zero a a a Prod com decisões tomadas e documentadas. Então assim, você tem sempre um insumo para uma tomada de decisão, porque todos os papéis que estão a relacionados no processo de desenvolver software, papéis pessoas, personas, né, desde o PO, desde o business review, Qway, etc. Não, não, não chegam só lá no final para dar o carimbo, aprovar, eles estão desde o dia zero especificando lá quais os critérios de que, quais os critérios de perf test e assim por diante. Então, quando chega lá, tá tudo resolvido. Então, eh, meio que te te dando uma solução, quem tá resolvendo isso aí tá se adiantando a decisão que o cara tem que tomar lá, por inseriu o IA, inseriu os papéis lá no começo do fluxo, entendeu?
Sim. É, e acho que tem um peso que é interessante, né? Você a a muitas vezes demorava muito para sentir o peso de uma estratégia ruim e até dava tempo de, né, eh eh dava dava tempo de entender e mudar de rota, porque você o o tempo de execução, né, normalmente o gargalo tava na execução.
Uhum. E e aí você tinha tempo de rever estratégia, então será que ainda faz sentido rever estratégia anualmente nas empresas?
Não sei, porque o gargalo pode estar na estratégia. Uhum.
Né? Agora assim, com tudo isso, a gente na na segura, por exemplo, que é uma empresa de de segurança, a ameaça muda semanalmente, cara.
Acabou. Como é que você define estratégia para um ano? Uhum.
A estratégia tem que ser muito mais de alto nível e e e a coisa no no mais, né, assim, para aterrizar no no ainda não no não no na base da estratégia ali no início da da ação tática, você tem que rever em ciclos muito menores, cara. Exato.
E num nível de executivo mesmo, né?
assim, porque você não tem, então o gargalo em em certa medida passa a est na estratégia também de tá revendo, de est acompanhando o mercado, de sempre saber o que tá acontecendo e aí exatamente envolvendo quem vai envolvendo a produção, que nesse caso, né, é a gente ainda chama de TI por algum tempo, não sabe quanto tempo, não, porque eu acho interessante assim e e e as coisas mudam, porque não quer dizer que todo mundo de TI vai perder o emprego e que isso não vai fazer sentido mais, porque a a essa necessidade da materialização, né, do processo numa coisa que que é percebida e acontece no mundo digital, ele ela vai continuar em alguma medida Uhum existindo, acho que por muito tempo, Mas talvez ela esteja mais pulverizada e talvez a gente esteja olhando em alguma medida por algum tempo mais pra governança, pra estratégia disso, para uma estratégia de plataforma, né? E e por isso esse processo de de desconstrução, eu acho que tem uma possibilidade de de nos de nos manter e talvez aumentar até a relevância nesse processo de de transformação e e de uma forma muito mais perena e construtiva, né? Se a gente se agarrar à nossas métricas, a nossa forma de pensar as coisas, acho acho que vai ser um processo muito mais duro de de transformação dentro das empresas, né? E é isso que eu quero dizer no fim com com essa com essa provocação para assim abandona essa habilidade de transformar um rabisco num formulário de papel impresso, sabe? Que é o negócio da gráfica?
abandona essa essa essa percepção.
Isso já é um problema resolvido.
É, já foi preciso mais de você para resolver isso. Você acomode agora. E e o ponto que você colocou, ele é muito bom porque a gente tende a trabalhar com ciclos cada vez mais curtos.
Sim.
Porque a execução tá mais eficiente e muito mais rápida. Quando você define uma estratégia e um executivo coloca aquela estratégia para rodar, você tem um tempo de execução, um tempo de avaliação para retomada de decisão. Esse ciclo tá muito mais rápido, né? O processamento de execução e o processamento de análise, ele tá semiautomatizado.
Então, a demanda por revisão da decisão e da revisão da estratégia passa a ser muito maior, porque a informação chega muito mais rápido, né? Então, a gente tende a trabalhar com ciclos, seja quais eles, de estratégia, de média gestão ou até ciclos de desenvolvimento cada vez mais curtos. E a gente vai ter que se adaptar a isso e as nossas métricas vão ter que se adaptar a isso, né?
E e o interessante, eu não vou falar legal que a palavra é péssima, mas o interessante é que a gente vê na prática empresas que são mais ágeis, que estão se adaptando melhor, ah, se sobressaindo no mercado e as que não estão ah, se adaptando, falindo, pedindo ajuda, etc.
Se não puder citar nome, corta depois, mas é o exemplo das Casas Bahia agora.
Uhum. Casas Bahia, enfim, demorou para se eh adequar, depois começou a fazer um trabalho legal, mas chegou um pouco tarde. Aí você compara com outros outras empresas do mesmo segmento que estão mais à frente, já colhem os frutos disso, né? Agilidade na frente, dúvida que ainda acreditou, né? Sim, por tanto tempo que no varejo, o varejo físico não seria superado, né? e insistiu, insistiu, insistiu na tese, até que implodia quase uma blockbuster, né, assim, eh, eh, não. E, e, cara, insistiu tanto tempo no modelo que já era tarde quando foi, né? e um modelo que não se faz mais eh necessário.
Eu tava, quando saiu a notícia da da concordata da pedido de falência da das casas Bahia, o o várias pessoas dizendo que iam até a loja para olhar e sair com o produto, o vendedor sentava na frente do computador para fazer o pedido junto com o cliente, cara.
Ou seja, era uma [ __ ] da L House.
Não, mas não tem o produto. Não tem produto. Porque e antes, sabe por? A gente gostava do varejo físico antes.
Sabe quem tá fazendo muito isso também que eu tô ficando puto?
Eh, loja de carro. Você vai para ver a loja de carro, você já já viram, tipo, tem uns telão desse tamanho, você vai ser atendido pro cara, o cara tá em videoconferência com vocês, foi até a loja para olhar o carro, o carro tá lá e o vendedor tá em videoconferência. Eu falei: "Mas que [ __ ] é essa?" Oxe não, mas é porque assim, o custo da o custo do estoque parado nas lojas não faz sentido. Por, principalmente porque se for olhar hoje, né? Se se a gente tava acostumado com varejo físico nos na década de 90, no nos começo dos 2000, assim, quantos players tinham no mercado de TV? Quantos modelos tinham? Agora você tem assim 20 players, cada um com cinco modelos, o cara não vai ter esse estoque todo na loja. Não faz sentido.
Mas aí que tá.
E aí você nunca tem o modelo que você quer na loja, não é?
Sim. Então para que acabou esse negócio?
Então aí onde tá a verdadeira transformação. Se o estoque local físico não faz mais sentido, é porque não faz mais sentido loja.
É, você vai manter a loja pro cara sentar e fazer o pedido com você junto pela internet, entendeu? Aí a transformação tem que ser olhada fim a fim, né? Porque senão identifica no meio do caminho e aí você continua tendo o custo de ter uma de ter uma loja sem ter o resultado de ter uma loja.
Resultado.
Estamos vendo aí a a a experiência do varejo físico tem sido cada vez mais frustrante.
Uhum. Porque por porque é isso, você já estudou o problema antes, você achou 20 modelos que que fazem sentido. Você fechou em três que você fala: "Acho que esses são os melhores, quero ir lá na loja ver".
Não tem nenhum dos três.
Não tem.
Ou tem um? Tem um.
Então tá bom. Era melhor comprar pela internet.
Exato.
Tem um. E o vendedor não quer te vender aquele. Ele quer mostrar outro porque ele vai ter mais.
E não. E ele sabe menos que você. Exato.
Verdade.
Isso é de [ __ ] né?
Porque você estudou o problema. E e aí isso isso tudo e aí isso tem a ver também, voltando para pro nosso papo aqui do, né, para não virar um um papo de varejo, mas também tem essa essa coisa da informação e da gente como vendedor, né, ou entregador de TI, o nosso usuário também sabe muito mais sobre o nosso negócio hoje. Exato.
Ele sabe falar sobre aquilo e isso parece que ofende um pouco, né, a gente também. Não, mas isso não é aquilo.
Desenvolvedor tem ego inflada.
É porque o cara já pergunta.
Ah, você acha mesmo? Tem bichinho mais com ego inflada do que sai lá.
É. E até tem outra outra discussão que eu acho interessante, né? Porque a gente aprendeu a se defender disso ao longo do tempo. É por que que a área de negócio não pode escrever código?
Por que que não pode?
Uhum. Porque só eu sei.
É porque só eu sei. Só por isso. Porque se por outro motivo. Então será que eu sou posso, deveria como TI ser mais muito mais dono do Harners, né? E e dono dos Guardials e do que o entregador de código. Cara, quem que sabe escrever, quem que sabe desenvolver um sistema de RH melhor que o cara do RH que vai usar o sistema?
Aí você tocou no ponto chave. Se a única diferença entre um profissional de TI e um profissional de não TI é escrever código, acabou.
Acabou, acabou. Acabou, acabou.
Esquece, troca de profissão, vai fazer outra coisa, né? Então, TI não é isso. O código foi parte da TI por muito tempo, mas a engenharia da TI é outro assunto. E isso talvez o negócio não consiga fazer hoje. Mas escrever código é um problema superado.
Sim. E nós temos que que que, como você mesmo falou, se adaptar essa nova realidade, né?
Sim. Mas e mas aí é que eu acho assim que o processo de engenharia hoje, o grosso do valor do processo de engenharia de software, ele tá no harness e nos guardava, ele não tá na geração do código, não. Não. Eh, um ponto interessante da gente tocar é, a gente tá falando bastante aqui sobre o upstream, sobre o o negócio interagindo junto com a TI e a TI, né, com com essa nova realidade de desenvolvimento.
Tem algumas questões até que não são código, né? A gente tá falando de compliance, segurança, eh, políticas ali de desenvolvimento, etc. Como é que vocês veem isso hoje? que a gente tem algumas iniciativas aí, porque não adianta eu desenvolver um software em 2 horas, esperar dois dias para passar pelo comitê de arquitetura, uma semana de análise de segurança e isso criar uma gordura absurda também dentro do meu processo. A gente criticou o upstream pela pelo time para isso, mas também tem o waiting time dentro dos do do dos ritos que corporativamente a gente tem dentro da própria TI, né? Como é que vocês vem isso encaixando dentro desse processo com inteligência artificial e com esses novos papéis?
Perfeito. Bom, vamos lá, eu começo.
Bom, os processos ainda são aqueles processos de 1900 e bolinha, né? Gem, abre ticket, senta, 30 dias para provisionar a infraestrutura que o desenvolvedor precisa. Hum.
Depois X dias para promover para outro ambiente de dev para produção, etc.
E só um parênteses sobre Gemud, assim, que que Gemude atesta de qualidade, né?
A gente até falou com o Valmer esses dias atrás, é um carimbaço que alguém deu lá que Exato.
É, o cara vai alucinar mais que uma um LLM lá. É, é, é uma grande escala de, de, desculpa, uma grande escala de [ __ ] que o cara clica no Sim, sim, sim, sim. Sem ter a menor ideia do que que ele tá aprovando. Quando no fim, né, o que pessoas não sabem, a Gemmude, ela é necessária como um registro paraa auditoria.
Simplesmente um agente na sua esteira resolve o problema de Gemud. Exato. Mas enfim, como que eu vejo que as empresas que estão mais na frente estão resolvendo isso? Dinheiro e de plataforma, eh, que é exatamente o lugar a o tipo de tarefa que os desenvolvedores deveriam agregar valor nas empresas, que senão eles vão pro departamento de papéis lá, enfim, porque código é commodity, né? Então, os desenvolvedores deveriam estar trabalhando nesse tipo de coisa.
construir o harness, construir a base de conhecimento e e assim por diante. Então, como a gente garante que os guard rails vão funcionar? Como a gente garante que a gente vai ter um processo ah rápido e efetivo, construindo boas ferramentas, construindo boas plataformas, que aí você pode comprar, pode construir, enfim, mas é um movimento sem sem volta.
assim, o Gartner, muita gente odeia o Gartner, eu tenho prós e contras aí, enfim, mas tem muitas previsões que são interessantes. Uma delas é que até o final desse ano, 86% das grandes empresas vão ter a pessoas dedicadas em plataforma trabalhando justamente nisso aí, melhorando o fluxo, melhorando as coisas. Então, a minha resposta é bem curta, bem direta. Plataforma é, eu eu a eu acredito nisso também. Eu tô, a gente tá fazendo na, na segura um movimento muito eh de transformar áreas de controle em área em em times de plataforma.
E as pessoas têm que entender isso, né?
Como é que assim, esquece, a gente tava muito acostumado a controlar as coisas por gates, né?
Uhum.
E isso não funciona mais, porque o gate vira gargalo, você não tem jeito. Então não é no gate.
Danny for all. E aí sob demanda você dá o aluma. É. É exato. Não, e acho que tem assim tem uma coisa até a a gente assim a gente como empresa, né, tem investido muito, nossa principal área de investimento como produto é de controle de identidade agêntica e de workloads e tal. Esse é um problema, eu acho interessante que tá que é uma coisa do do momento. E a gente tá fazendo um trabalho muito legal eh eh nesse sentido e e avançando muito nessa área. Acho que é uma coisa que vai acontecer bastante nos próximos anos. A gente vai ter que pensar muito, mas todo o resto, agilidade para mim hoje em dia, né? Onde é que tá a agilidade?
Tá tá no no tá no Harness, cara. Onde é que tá? arquitetura até no harness, porque tem certas coisas que você não tem que discutir mais, você já sabe como é que é, né? e e eh então acho que tá aí assim, é bastante uma essa coisa do polic
e streams de plataforma de como é que você constrói isso dentro do harness, dentro dos guardrails e e é isso que vai garantir que a coisa aconteça até se aí, né, você pensar na na nas coisas que fazem efetivamente diferença no no que se muda e e a história do Dora como um todo, não só da das métricas, né? Você pensa, tá melhorando o quê?
Você tá diminuindo muito carga cognitiva.
Uhum. Porque tá dentro do raro. Você não precisa ninguém, você não precisa ensinar ninguém que precisa ser arquitetura daquele jeito. Não precisa explicar isso para ninguém. Eu costumo falar pro pras pessoas que oá é o é o dev dos sonhas do arquiteto. Ele não contesta, ele não reclama, ele não fala que vai dar mais trabalho, ele não fala que tem uma livre diferente que vai, ele só segue o que foi definido.
Isso é maravilhoso.
Então, quando a gente fala de ter um harness eficiente, a gente tá falando de ter pessoas qualificadas.
E aí não estamos falando só da inteligência do modelo, mas da cultura e da necessidade da empresa, porque o harness ele vai gerar o seu código.
Existem coisas da operação da tecnologia que não são determinísticas, depende de pessoas, de de processos, etc. E isso vai est embarcado dentro do seu harness, sua arquitetura de referência, suas políticas de segurança.
Então, no fim, vocês acham que a gente pode ter um modelo onde essas áreas estarão todas trabalhando colaborativamente dentro de um harness que vai gerar esses produtos, né? E e não terão mais essas iterações através de gates, né? Exato.
Fiz um desenho de arquitetura, o cara desenvolveu, depois vai pro comitê de arquitetura, o cara fez diferente e volta, joga tudo fora e aí o P fica puto, o Bord não sei lá, isso tende a acabar, né?
Sim, já temos isso assim hoje lá no Mercado Livre com o F, minha mês exempresa, ah, ah, já é assim. Eh, e onde eu trabalho hoje, sou meio suspeito para falar porque eu vendo plataforma hoje, mas o qual por favor fale da Eu trabalho na new platform, enfim, eu eu vendo dos criadores do F do Mercado Livre, enfim, tô meio lá ainda, né? Eh, qual é o end game aqui? Eh, quem pode fazer um software? Um agente, um desenvolvedor qualquer lá com VS Code, etc., uma pessoa de negócio, tá? Que que esses três caras vão fazer? Eu quero fazer um crude com que armazene os dados.
O Hares vai conhecer a sua infra e vai saber qual banco de dados criar. Ah, é um post. Opa, pera aí. É produção, é deve. Que Ah, que que é que você quer?
Ah, é deve. Ah, então o post seu vai serverless.
Ah, não é produção. Opa. Então vai ter aqui réplica, chard, multiaz, multi blá blá blá. E você que é de seja deve, seja um agente, seja uma pessoa de negócio, nem precis negócio, se preocupa em agregar o valor lá, algo que vai aumentar a conversão, enfim, melhorar a experiência do usuário e esse é o end game que a gente tem que chegar e plataforma ajuda nisso. E esses caras têm que estar trabalhando na plataforma, no harness, em todo o stack, certo?
Criando imagens précuradas, tem uma infinidade de coisa pra gente fazer, né? É assim, até quantos desenvolvedores ou qual percentual dos desenvolvedores sabe tomar uma boa decisão de quando usar um banco de dados relacional ou um no ciclo ou um KVS ou teorema de cap? Que é isso?
O cara não sabe. Então, e aí aí onde tá o problema do do desconforto, né?
Porque aí você começa a ter que tomar decisões e não escrever só código.
Sim. E e muito do desconforto nosso da categoria vem vem disso.
Eh, a gente deixa de ser um um escrevente de delegacia, né, para ser delegado.
Tradutor português Java.
Exatamente isso aí. Agora o cara tem que tomar decisões que geralmente ficavam a cargo do arquiteto e se desse merda é culpa do arquiteto. Agora isso é uma decisão compartilhada. A TI a minha visão, o cargo básico vai ser arquiteto.
O todo deve vai ter que ser um arquiteto, né? Acabou isso de ah não.
Então o arquiteto foi, arquiteto foi steco.
Exatamente. Tem o cara tem talvez tem que ser um cara de produto.
É exato. Exato.
Porque ou um par, um cara conhece muito de produto, cara que conhece tecnologia e vamos lá forças, né? Enfim, a gente não, quem vai ganhar mais? O cara que agrupar mais disciplinas. Ex que é o que a gente já fez no episódio aqui que é o high contribute high hp high individual high high hpque hpicque high personal individual contributor é uma coisa assim é o fodão, é o cara assim ó tá aqui ó o card foi a última vez que o nosso amigo esteve aqui conosco e foi um papo muito legal um dos episódios mais ouvidos do ano pô legal muito bom então, cara acho que eh E a o que o que a gente tá chegando à conclusão aqui é que a experiência do desenvolvedor tira tira ele do papel de vítima sim por um papel de protagonista.
Dá todos os subsídios para isso. Agora depende dele, né?
Exatamente. Exatamente. Então e e aí pra gente já caminhar pro pros finalmentes, eu queria que vocês dessem uma dica para esses caras.
Tem cara que tá ouvindo a gente agora e tá assim, pôra, realmente é isso. Essa é a postura que eu tô tendo e a postura que eu quero continuar. Tem cara que tá ouvindo e tá em negação. Falou: "Não, [ __ ] não sei o que nada". Que que você diria para esses caras?
O primeiro estágio é a negação, né? No final é a morte. Se ele continuar na negação, né? Enfim. É, cara, a nota, uma das primeiras palavras que o Armando falou aqui no começo, é desconstruir, é o momento. Então, eu tô muito empolgado com essa tal de AI. Eu sinto que eu posso sair melhor do que a gente chegou até aqui, certo? Isso pode me potencializar, pode me gerar mais oportunidades, pode fazer eu contribuir melhor pras empresas, empresas crescerem, etc. é questão de usar, é questão de ser inteligente, é questão de de de ir para cima, certo? Então, eh, se desconstrua, toma a decisão agora, porque o tempo é curto, mas cuidado com a cabecinha porque Exato, são tempos complexos pra cabeça também, né? É, eu eu acho eh é é uma coisa de base assim, para mim isso é central, desconstruir a percepção eh eh a nossa percepção antiga de valor, de como a gente gerava valor pro processo. A gente precisa abandonar isso. para abandonar. Você falou uma coisa muito importante, a gente precisa ter atenção à saúde mental, tanto nossa individualmente como das nossas equipes, né? vai ser um processo que isso vai ser muito eh eh muito necessário, mas e e as pessoas têm que se abrir para para essa transformação e e se abrir para e isso vai ser desconfortável porque vai mudar muitas vezes.
Uhum.
Toda vez que a gente achar que é um estado final, a gente errou e errou de novo. E errou de novo. E errou de novo.
É. E e uma coisa interessante sobre isso e essas pessoas que tão que eu vejo falando muito no LinkedIn, aí vem aquele daqueles estatísticas do menos de 19% que o cara vai não, porque ele acha que aumentou 20%, diminuiu 19. Você lembra dessa história, né? Todo mundo Mas assim, ah, tá bom com estatística do começo de 2025 já era, cara. Porque a gente tava aprendendo esse negócio e e mudando e e muda cada dois três meses tudo.
Uhum. de novo, né? E a gente vai aprendendo. Exemplo, é onde estão os vendedores de curso de N8N.
Acabou, né?
Sumiu. Sumiu. O LinkedIn era só isso há seis meses atrás. Era impressioná em todo mundo, né? Desvolvimento. Acabou.
E agora o N8 ele morreu já assim, né?
Pois é, porque agora você não precisa mais dele, né?
É, então que e e é isso. Então, se a gente e e o os as pessoas apegadas à reação, elas vão ter muito argumento por muito tempo ainda, porque vai dar errado muitas vezes e vai mudar muitas vezes de novo. Ah, tá vendo? Isso aí deu errado. Não é mais isso.
Como se não desse errado quando a gente fazia isso, mas humanamente, só que tá andando pra frente, tá? Não vai andar para trás.
Não vai andar para trás. Essa coisa de que ah, o modelo é insustentável porque é antrópico, porque a bolha, cara, esquece, velho. Ninguém vai deixar essas empresas quebrar. Pode custar assim, ó, cash bunny de 100 bi para um movimento de investimento em hardware, num ano de 3 trilhões de dólares, né?
100 B não é nada, cara. Esquece. Não, você pode cas B de 100 B hoje aqui no dia, hoje é dia 2, né?
A gente tavam cogitando nos últimos dois meses tava uma tensão no mercado pelo resultado da Nvidia, porque falaram que o resultado que a Nvidíia teve no último, na última divulgação era insustentável.
Uhum.
Ela repetiu e aumentou.
Aumentou. É. né? Ou seja, não é assim, tem muito capital e e o potencial ele é muito alto.
Sim.
E querendo ou não, é algo que não retrocede, porque a a gente tava até comentando aqui fora do ar, nas nossas iniciativas pessoais de uso de, etc., como assistente ou como repositório de informação, a nossa maneira de viver já mudou, cara. Não dá para fazer diferente mais. Não dá, não dá, né? E e isso a nas empresas ainda não enraizou tanto, mas quando isso tomar uma proporção e a gente tiver de fato uma um um sprint nisso, que as empresas verem esse potencial e estiverem adaptadas nisso, isso é irreversível.
Sim.
E o mercado vai se adaptar? Vai, não. E mesmo boa parte desse gastar a capacidade computacional necessária pro pro pros modelos e pro uso e tal, né? E a outra parte é consumo de energia elétrica que espero, né, que a gente seja inteligente. Acho que esse é o talvez o grande desafio da humanidade, resolver esse problema do consumo de energia elétrica, sim, né? e de fato encontrar eh fontes mais sustentáveis, seja por, enfim, por eh eh fusão nuclear, sejaão, que ela só sobrevive se ela ajudar a resolver o problema da energia elétrica.
Vai resolver, vai fazer isso fazer Matrix, não esse problema aí ferrou, né?
Eu acho que a gente só não tentou resolver com força nos últimos anos, porque ele era confortável. É. é que a gente tem um interesse do combustível fóssil, etc. Mas e isso isso não é um problema.
Vai resolver esse problema. Acho é um problema de interesse, não é um problema de capacidade, né?
E e eu eu tô nessa linha também. E eu queria que vocês deixassem um recado também, já que a gente falou sobre produtividade, métricas, etc., pro gestor que tá olhando para tudo isso e não tá sabendo como como lidar com o time, como medir, etc.
Que que vocês diriam para esse cara?
Até começar esse, né? Eu eu acho essa essa é essa é boa porque o gestor tem vários níveis assim, né? Primeiro, cuide da sua própria saúde mental porque você também é impactado no processo.
A gente tá num mundo que tudo que a gente deve de conselho tem que começar com essa frase, né, cara?
Não é, pô? Você, cara, assim, ó, tá muito louco.
É, mas é isso. Vista a sua máscara primeiro.
É isso.
Você tá bem, você tá aceitando bem a transformação e vivendo ela, né? Eh, eh, então essa é a primeira coisa.
Acho que por pelo menos uns dois ou três anos a gente vai ter que se acostumar com um ritmo de mudança frequente e vai ter que saber aceitar isso. Eh, eh, que o nosso, as ferramentas que a gente usa vão mudar, a forma como a gente trabalha vai mudar constantemente, com frequência pros próximos anos. a gente tem que se preparar para isso e aí a saúde mental de novo vem, porque vai acontecer e não achar que chegou num estado final antes da hora e fazer acho que um bom balanceamento entre não demorar, não embarcar em cada nova onda, porque se gasta muito tempo, energia e dinheiro embarcando em cada nova onda, porque muito vão surgir e também não demorar muito para para entrar quando te fica claro que que aquilo é sólido, porque, né, assim, meses podem podem ter uma e meses em em competitividade, em como as empresas vão evoluir nos próximos anos, pode fazer muita diferença, né, Você não precisa ser o early adopter, mas nunca deixe de ser o adopter.
É exato. É assim porque a quantidade de disruptores em cada um dos processos de cada um dos mercados nos últimos anos mostra isso, né? As a a as empresas que eram líderes de mercado e se tornaram relevantes e e meses de tempo de resposta vão fazer muita diferença.
Sim. Então a, eu acho que a gente tem que tá preparado para isso, assim, se desconstruir, cuidar da saúde mental, se preparar para um período longo de transformações frequentes e com uma periodicidade e e e constantes, né? E e saber medir bem, saber medir bem quando eu entrar nas tendências, né? Eu acho que vai ser um grande desafio. Acho que vai ser boa parte do valor que a gente vai gerar, né, como como líderes e e em cada um dos níveis aí. É é pelo menos é para isso que eu tô me preparando pros próximos anos. E acho que é o que eu diria.
Acho que as palavras são exiliência e flexibilidade.
É sim. E para não ser repetitivo, porque eu assino embaixo tudo que o Armando falou, eu adicionaria aí que para líderes agora não tem como também não ser mais técnico, tá? Principalmente com oai. Aí, claro, cada um no seu nível de hierarquia vai ter que avaliar o quão técnico vai ser, mas é um movimento que a gente vê aí em nas começa pelas bigte de por meta, ex, enfim, um um movimento de demissão em massa dos gerentões que sabe, tá pronto, tá pronto.
É, talvez, não sei nem se é ser ou não ser técnico, é ser ou não ser builder.
Exato, né? Assim, talvez, né? Não sei.
Talvez o conceito de técnico seja nessa porque qual a profundidade técnica, usar e como a o que a gente chama de técnico hoje em, mas é ser builder, cara. Ser perfeito, perfeito, perfeito.
Não vai, não precisa estudar com Bernito, não é isso, não é isso, mas é realmente boa, boa, boa.
É, é, é saber usar no seu nível ali, tá?
E para quê? prototipar rápido, ter como discutir, ter, enfim, eh, esse também é um movimento sem volta. Eu não vejo mais um líder que não não faça esse tipo de coisa.
Sim, é, não dá pro cara ser só um piemol mais, né?
Coisa vai ter que ser diferente.
Não, até até porque o o piemol é o agente, cara. Esse o piemô é mais um que foi embora pro agente. Esse foi porque não tem é o cara que fica olhando pro cronograma e alertando as pessoas. Acabou. Não, eu que eu falei para vocês fora do ar, eu tenho um pemol da minha vida agora a gente tá resolvendo e me ajudando demais, né?
Não, o PMO é uma área de, para mim é um, uma disciplina de plataformada agora o cara que tem que tá lá. É, eu concordo contigo. E e e é curioso, né, que eu já fiz, acho que eu já fiz esse comentário no podcast, essa questão sobre os líderes que não se envolvem, etc.
Se a gente faça um paralelo da do histórico da nossa área de líderes que que não tem formação, que não tem conhecimento técnico, você já viu algum diretor de hospital que não seja médico?
É, conheço não.
É, eu vi ministro da saúde alguns tempos atrás que não era médico, mas geralmente era.
Geralmente eram os bons eram, né?
Exatamente. Por que que na nossa área a gente ainda vivia isso? uma coisa pra gente refletir e talvez ter isso como um mindset daqui em diante nessa transformação, né?
Exatamente.
Meus amigos, que papo bacana, hein?
[ __ ] muito obrigado. Vocês vocês são uns caras do do assunto, cara.
A gente tá tentando, né?
A gente tá tentando, a gente tá aprendendo, né? É, e e eu tenho certeza que que muita gente que tá ouvindo a gente ainda não está nesse nível de discussão nas suas próprias empresas. O o espero, né, que o o nosso ouvinte ele esteja engajado nisso, tentando ser uma força de transformação onde ele esteja, né, porque a gente tem uma audiência muito qualificada e eu tenho certeza que o cara tá ouvindo aqui e vai levar para dentro da própria empresa para tá preparado e ser um agente de transformação pro pro caminho correto.
Então, tenho certeza que nós conseguimos aqui dar uma boa contribuição para essas pessoas lidarem com isso nesse momento, tanto do ponto de vista pessoal quanto do ponto de vista de negócio. Então, muito obrigado, agradecer vocês dois aqui pela presença.
Prazer é nosso.
Eu que agradeço pelo convite. Obrigado.
Bom, obrigado. E você que acompanhou a gente até agora, muito obrigado pela audiência de vocês. Se você curte o nosso trabalho, se você acha que a gente agrega valor na sua vida profissional, você pode ajudar o PPT no Compila. Tem algumas formas de você ajudar a gente.
Você pode ser membro do PPT no CPIL lá no no YouTube e aí você vai ter acesso antecipado aos episódios do PPT no compila. Você pode ir pelo pix@pptnocila, fazendo qualquer contribuição a qualquer momento, pô, pagando a cerveja nossa aqui. Qualquer contribuição já nos ajuda. E você, caso não consiga contribuir dessas formas, você pode contribuir ainda mais compartilhando o episódio, eh divulgando nas suas redes, mandando no grupo da empresa e recomendando o nosso canal para outros profissionais da área que ainda não nos conhecem. Isso ajuda muito a gente a crescer a comunidade e levar conhecimento para cada vez mais pessoas. Então, obrigado, meus amigos novamente.
Valeu,
Episódios Relacionados
1h 33minHigh-Impact IC: 3 Pilares para Sobreviver à Era dos Agentes
Juliano Martins, Valmir Justo
15 de jun. de 2026
1h 2minGestão de Produto com IA: O Upstream Ainda é o Gargalo?
Victor Gonçalves
1 de jun. de 2026
1h 20minDebate: Não precisamos mais da TI? Scrum Master é inútil?
Alexandre Del Rey, Renato Grau, Victor Gonçalves
17 de jul. de 2024
1h 29minOps, Devops E Cloud: A Tríade Tecnológica Do Mercado Livre
Juliano Martins, Pedro Chagas, Arthur Soave
17 de mai. de 2023
