Go back

Débito técnico não é culpa da engenharia

49m 30s

Débito técnico não é culpa da engenharia

A transcrição discute os desafios na relação entre produto e engenharia, destacando que a dívida técnica prevalente no mercado é sintoma de uma desconexão entre essas áreas, não de falhas técnicas isoladas. Argumenta-se que é necessário romper barreiras hierárquicas, estabelecendo uma parceria baseada em confiança, com foco conjunto na definição clara do problema, nos critérios de conclusão e nas métricas de sucesso. A falta de intencionalidade e alinhamento estratégico resulta em "entregas vazias", onde a produtividade é confundida com ocupação, sem gerar valor real para o cliente ou negócio. Enfatiza-se que a engenharia deve compreender profundamente as métricas de negócio e o impacto no usuário, usando dados para decisões mais racionais. Além disso, diferencia-se contextos como "construir para aprender" e "construir para gerar valor", requerendo abordagens de engenharia distintas. Por fim, critica-se a cultura de priorizar desejos em vez de resolver problemas reais, apontando que a clareza estratégica, e não apenas a velocidade, é fundamental para o sucesso, especialmente no cenário brasileiro.

Transcription

8679 Words, 46465 Characters

Portuguese
o primeiro problema que eu vou soltar é os débitos técnicos que a gente tem hoje no mercado, em todo o time de engenharia, ele não vem na engenharia, ele vem de uma onyamento entre produtos engenharia. Eu acho que a gente precisa quebrar muros, não é nem quebrar muros, acho que não deveria existir esse muro, esse muro tem que ser mais baixo possível, que a engenharia precisa entender das métricas de negócios, entender na raiz, porque o que é o sucesso para esse caro? Como é que a vida desse caro muda com o que a gente está fazendo? Eu acho que a gente precisa, e aí eu acho que trazer dados para conversar, ajuda um tanto, dá mais clareza para o time de engenharia, que é o time mais racional, vamos colocar assim. Então os dedos, os técnicos que a gente tem, não são mais destesão de engenharia, a engenharia só fez o trabalho que tinha que fazer, sem questionar, sem ser intencional, eu acho que falta intencionalidade, quando você me pergunta, posar a relação de engenharia para adultos, cara, simbiosos, não não existe ser um outro, eu acho que vocês têm que realiar as expectativas, realiar o relacionamento, tá? E aí eu já inicia, o Zara, quer você ter uma vasta experiência, né, em liderar equipes de engenharia em empresas de auto crescimento, né, crescimento acelerado, como que você vê essa relação ideal entre as áreas de engenharia e produto, para garantir o que está sendo construído realmente, já era valor para o cliente, para o negócio, tech fala que produto não sabe o que quer, e produto olha para tech fala, pô, demora para entregar. Cara, e avisar assim, o canto onde eu vi, as igrejas que eu vi, a gente tem no sucesso principal característica nessa relação, né, produto e tecnologia, quando eles se enxergavam como um coisa só, eu acho que aí é, é, é, a gente, primeira coisa é o lanço da confiança, tá Paulo? Eu acho que é, é uma base super necessária para você ter sucesso enquanto imiki entrega um produto. Deixa eu fazer um molde aqui bem rápido, digital, não é nada mais do que é um software rodando para atender, né, com a experiência adequada para atender um problema da sua cidade. Enfim, no dia ele é um software, a sua essência, um motor daquilo, funciona através de um software. Então, nada mais, justo que a gente chegar, produto e engenharia, dados e design, como um grupo só, sim, unidade, né, confiança num trabalho do outro, não é o lanço da hierarquia. E alguns lugares eu vi isso, não é da hierarquia muito forte, produto pede, engenharia faz meio que de parte da laria, tá, várias igrejas que eu já botei meu joelho no chão, esse mote era a base e o pior, as pessoas estavam confortáveis com esse modelo, as pessoas confundem isso com ter responsabilidades bem definidas, cara, e é um posto disso. Se você tem um ambiente, onde você não aproveita, a capacidade cognitiva dos teus engenheiros, se você tem um ambiente onde você, como engenheiro, não absorve as coisas de negócio, pode ser você vai fazer a negócio que daqui a pouco, ele vai capotar, ele vai capotar mais rapos que é uma relação de parceria e confiança, tá, menos e erarquia. Não é tipo, "Ah, não, eu vou fazer isso", porque o produto pediu, mas se perguntou o que o que a gente tá fazendo isso, tem que ter três aspectos que eu acho super fundamentais que fazem a liga dessa relação, que ela é o problem frame, e o quadramento do problema, o que é que é o problema, quais são as evidências que morzem que isso é um problema, a definição de danhas, a defensão de feito, uma vez que a gente vai resolver esse problema, o que é a defensão de feito, pra agiaria, pra dados, sabe, pra experiência, desar e pra produto, estudo estentar mônio, todo mundo tem que conhecer o que a defensão afundar pra todo mundo, e o terceiro é o que é o sucesso, uma vez que tá feito isso vai pro ar, uma vez que a gente vai medir o sucesso disso, o que é no fim do dia, eu confesso pra você, eu vi time se destruir em porque time de engenharia correu entregou, mas o sucesso não veio e ninguém sabia o que era, de fato, o que era o sucesso, ou o que eu gosto de chamar de entregas vazias, as pessoas estavam querendo estar muito mais ocupadas do que produtivas, isso assola o nosso mercado, o PTBR, de uma maneira insana, eu acho que a gente precisa quebrar muros, não é nem quebrar muros, acho que não deveria existir esse muro, esse muro tem que ser mais baixo possível, engenharia precisa entender das métricas de negócio, o que é que é que ele é o negócio assim, acho que ele é, você colocar o cliente no centro, mas mais bicho do que isso, não tem mais, entender na raiz, porque o que é o sucesso desse cara, o que a vida desse cara muda com o que a gente tá fazendo, sabe, acho que a gente precisa, e aí eu acho que trazê dados pra conversa, ajuda um tanto a dar mais clareza pro time de engenharia que é um time mais racional, vamos colocar assim, é um dia um time mais focado em em sequir números, e acompanhar o longo disso, muitas das coisas que a gente vê hoje, por exemplo, e essa é uma afirmação primeira, o primeiro problema que eu vou soltar é os débitos técnicos que a gente tem hoje no mercado, em todo o time de engenharia, ele não vai na engenharia, ele vem de uma olhamento entre produtos engenharia, assim, claro, claramente isso é o primeiro grande fato constatado, olha, eu passei em vários últimos 5 vezes que eu trabalhei tudo assim, só eram em corro assim, é insana, mesmo coisa, todo lugar, se eu assim, os débitos técnicos que a gente tem não são mais decisões de engenharia, a engenharia só faz o trabalho que tinha que fazer, sem questionar, sabe, sem ser intencional, acho que falta intencionalidade, quando você me pergunta, posar a relação de engenharia para adulto cara é simbiosa, não existe sem outro, e eu acho que a gente, se você tiver você que você que está ouvindo a gente aqui, tiver uma relação de commodo e controle, chama para a mesa, vamos com essa de novo, se você tem que realiar as expectativas, realiar o relacionamento, tá? A sua primeira resposta, ela abre várias outras perguntas, débito técnico, isso vai aumentar, dá duas empresas, estarem fazendo, vai bicol, não? Vai, vai, vai, vai, vai ficar pior, tá, assim, ó, eu acho que o mais horroroso é que a gente, a gente está vivendo, não, uma maneira de ruptura, sem igual, sem na indústria, e a gente está fazendo, tá vivendo, dois meses de ruptura mesmo tem pra não ser percebese, um ano da IA, como um catalizador de Output, tá, assim, nem vou chegar no método de, se é certo, se não, se tá bom, se não tá, eu acho que a gente ainda tá muito, pra dizer isso, do ponto de vista de maturidade e tecnologia, a gente tá curto, é tanto que a cada release novo, as coisas têm de melhorar um pouquinho, a gente tá curto, tá? Mas sim, um fato é, o Output agora ele tá apontacionalizado, você vê lá, métricos casidados sobre produção de conteúdo, por exemplo, é utilizando iase, caro, já ultrapassou o organico, né, assim, o sintético tá apontando o ultrapassino organico, assim, o Output de fato ele vai vencer, porque ele é muito agora baseado em processamento, né, então o medo é de ter muita coisa no mundo, isso vai levar a gente pro outro lugar, quando a gente fala de. débito, débito técnico na. na sua essência, a gente tá falando de uma tomada de decisão intencional pelo time de engenharia, pra acelerar, cheia o mercado, isso pra não débito técnico, e não, do tipo, você vou fazer aqui corrido acelerado, porque eu tenho que com o mercado, mas aí você nem entende o que que você tá comprando de débito técnico, isso foi assim, não tem intencionalidade, tá? E aí pra mim está muito mais perto, mais de bug do que é de débito técnico. No fim do dia, pessoal, eu tenho intenta colocar isso no mesmo balaio, eu tenho que separar, pra mim isso é muito mais um dedo de produto, e eu gostei, eu não sei se eu chegou a algum material que eu já escrevi, eu vou melhorar aí da agora, eu tô até. é tudo pra mim é dedo de produto, se é técnico, se é de experiências, se é de infraestrutura, tudo pra mim é um dedo de produto, porque o dia é um produto digital, entendeu? E eu acho que o último de produto precisa estar mais perto, pra ser intencional também nesse lugar de dizer, por isso galera, a gente tá comprando algum problema aqui que eu não sei, eu que eu preciso saber do tipo, isso escala no escala, e aí depois pode entrar em outros lugares que engenharia, pra aprender, engenharia, pra ganhar dinheiro, são duas coisas diferentes, aí a gente pode trair os buracos de miocas, se você precisa. Porque o qual você tava falando no dedo de técnico, isso foi, foi na minha cabeça, me parece muito mais um cascateamento, o dedo de técnico mais é do que o resultado de uma priorização ineficiente de produto, que, por sua vez, ela é ineficiente, porque não existe uma estratégia bem definida e alinhada. Aí eu pego, na sua vasta experiência, eu falo sobre isso, num linkadinho em alguns lugares que eu vou, e as pessoas me olham meio torto. E já criei algumas animaisagem, porque eu tenho a não bater tanto, não bater, eu tenho que não criticar tanto a parte de baixo da pirâmide, e eu começo a olhar também a parte do meio e a parte de cima, na sua visão, que poucas empresas do Brasil entendem o que é estratégia e entendem o jogo. Enquanto eu falo o jogo, eu estou falando de qual é o meu real momento, qual é o meu real contexto, e eu vou usar essas minhas fortalezas para eu criar uma estratégia tranquila. Porque eu me parece que todas as empresas aqui no Brasil vivem em 100 metros rasos, sendo que, dependendo do seu tamanho, você não está mais nesse. Nisso, você está numa maratona, independente se eu concorrente vou fazer, e tal, é uma maratona. Por quê, Ozara? Existe um. Não, a gente vive nessa sociedade totalmente ansiosa, tá? E ela é ansiosa do ponto de vista mercado e do ponto de vista pessoas, porque é pior, e pessoas controlam mercado, e pessoas são mercado, pessoas rodam mercado. Então, a gente tem uma ciadade omu, né, um fear of missing out, o medo de ficar de fora é absurdo. E para isso, a gente aperta laranja moendo a casca, vai ficar zedo? Moel laranja, aperta na casca, vai ficar zedo. E fica zedo, ficou horroroso de tomar. Então, assim, as pessoas que vocês entendem, que, uma mãe, você foi muito cirúrgico, onde é que você está? Você está no modo sobrevivência? Tudo ainda é o experimento, eu chamo esse de build to learn, né, construir para aprender. Você está no modo de construir para aprender, você está no modo de construir para ganhar dinheiro. Build to earn, né? Build to earn, build to earn, e eu acho que. Por que é que é importante, do ponto de vista de engenharia, a gente sabe disso? A engenharia que você aplica no build to learn, ela é diferente da engenharia que aplica no build to earn, porque a gente está no aqui, os mundos. Agora vamos lá, "Strange of Things", multiverso, um mundo divertido. A gente tem pessoas que estudaram para fazer build to earn, a academia para a pessoa vai fazer build to earn, mas não para a mentalidade dessa galera para operar no build to learn. E aí você tem, ó, que de mentalidade, geração, cara, e vai explodindo o produto, que o pior, isso pode na mão do usuário, assim, no fim do dia, o roi, ele deveria ser instantâneo ou próximo do mais rápido possível, e ele tem mora, ele vai e volta, ele sabe, ele é um roi que não se paga, se você fosse para pensar, a gente enquanto. Provedor de solução para o mercado, a gente engenharia como Provedor de solução para o mercado, o nosso custeltíssimo, o nosso custeltíssimo, é tanto que você vê iniciativas que não se pagam, mas porque você, às vezes, está usando o método errado, aí você está querendo usar um engenharia de build to earn, no momento de build to earn, e às vezes você vai ver se vessa, e eu vi se vessa o pior, porque eu vi se vessa, ele capota negócios, que é o pior, é você pegar um engenharia de build to earn, seja um engenharia, vamos dizer, quick and hurry, rápido e suja, e aplica na escala, então a questão é, tem aquele livro cross-tecaso, né, assim, o quanto você vai preparar para escalar, você precisa estar com a sua engenharia muito logazinho, e eu acho que esse é o maior desafio da engenharia de software mundial, como é que eu começo com a engenharia, que ela é experimental, mas ela é bom o suficiente, ela está no lugar o suficiente para escalar, se eu precisar, e eu acho que ninguém ainda tem essa resposta, existe, no detalhe, a gente tem eventualmente, meio que você vê isso, é uma abordagem para isso, modelitos modulares, é uma outra abordagem para isso, serve-les, foi uma abordagem para isso, mas eu acho que já quer dizer, tem várias técnicas do ponto de vista, e a toma tentou experimentar, mas que ainda não chegou, mas porque eu acho que o problema não está na tecnologia, está no processo, está no processo do produto e negócio identificar que putz, esse daqui, eu falei isso com, por exemplo, real agora, recentemente, a gente estava fazendo as coisas que ele não tinha que dar, falei que pô, galera, mas esse aqui é o produto final, a pessoa é do produto, não, e o time de engenharia já achava que era o produto final, olha que bizarro, e assim, a gente estava com a mentalidade de putz, que era o produto final, o time de produto estava conseguente, não estava experimentando, a gente não estava valendo a ideia, e eu falei, "É isso, é isso que está errado", então, engenharia o produto, vamos já, sabe, todo mundo trabalha, todo mundo se fala todo dia, Paulo, é inconcebível que esse time tivesse nessa situação, você entende que tipo, o problema está no método, então eu acho que vem essa, esse buraco, isso é endêmico, todo mercado, o PTBR sofre disso, eu acho que a gente acelerou muito a carreira das pessoas no período de covid, por questões óbias, e a gente não maturou as pessoas com elas precisavam ter sido maturadas, e eu acho que isso, de novo, pessoas fazem um mercado, e essas pessoas foram com a carreira de liderança, e claro, e claramente não conseguiram observar isso, porque quando a gente fala dessa, dessa forma, né, quando a gente aborda esse tema, e a gente fala, "Não, é, tem que ter foco, o estratégia é uma coisa, o objetivo é outra, tudo bem, não ter uma estratégia, mas se você tiver objetivos claros, bem definidos, tados ali, isso já vai fazer toda a diferença, para os Teams, parece que as pessoas, quando o alvei isso, faz assim, "Oh, mas eu tenho que executar muito o prazo, eu tenho que mostrar, resultado, eu sou fupressão, aí a minha leitura, os ara, você quer, decotivo, já passou por ele em empresas, cinco necornos, a pressão só é gerada, porque você gerou uma expectativa a quem, você deve resposta, e aí você prometeu "Ah, sem antes entender o seu contexto, e aí você olha para o seu contexto, você fala "I, não dava fazer o "Ah, não, e aí você começa jogos mortais, né, aí você começa a colocar pressão, e você começa aí no micro, que você não precisava ir, como um média, outra liderança, porque você prometeu, e aí você quer cumprir, e muitas vezes, a pessoa que está na apressão, colocando pressão, e você, ela sabe que você não vai entregar o "Ah", mas ela quer ver se você vai voltar e vai falar assim, então, não vou conseguir entregar o "Ah", não no tempo que eu falei, mas eu consigo o "Ah Minus", que vai gerar "X" e "Psono Z", eu estou sendo muito puletando, "Oh, tipo, se é um comedor, porque não é assim que funciona". Não, acho que está certo, é porque, em algum momento da história, a gente parou de resolver problemas para atender desejos, e assim, e aí eu acho que aí, aí a raiz de todo o mal, quando a gente desvirtou o lance de puts, eu estou olhando para o problema real, eu estou inventando aqui para me sentir ocupado, a coisa do produtivo da ocupada, que a gente falou mais ser assim. Eu estou sendo produtivo, ou seja, resolvendo problemas, entregando valor para o meu cliente na ponta, eu estou ocupado, se lá, tocando um desejo de alguém, o meu desejo, o time de produto, o time de negócio, o dia algum se leva, assim, que é um desejo que ele, "Ah, o cara viu e apô, beleza, vou trazer eapatudo para aqui". Para quê filha, não, que você quer trazer eapatudo, assim? Qual o problema que a gente está resolvendo? Daí a gente votando umas coisas dos três mãos, né? Qual o enquadramento do problema aqui? E aí, não tem, não é um desejo. O quando é desejo fica difícil, tá? E aí, quando fica quando é desejo, às vezes você vai falar "A gente cai no nosso de comprar o desejo dos outros", você nem entendeu qual é a intenção daquele desejo, né? Eu gosto muito da ideia de retrucar, talvez que ele vem com o desejo para mim, vai muito. Tá, mas qual é a sua intenção com isso? A gente quer chegar aonde, com isso? Às vezes, a pessoa migra, assim, se elas chorem um doutor para mim, elas me odeiam, assim. Eu tenho certeza disso, tá? Mas qual é a intenção? Você coloca uma intenção, vai, "Cara, olha o que a gente quer chegar com essa, assim, eu voto". Se a gente entregar o que tá me pedindo, como é que o mundo fica? Isso, pra mim, foi liberta a dor descobrir esse truque, porque sená, se é 170 ou 70% às vezes, as pessoas não têm ideia de como é que o mundo fica. É ver só um desejo pra sentir produtivos, sentir bem na rodinha de amigos que entregou-se lá. Agora a gente tem aí, você pergunta "Pô, mas ia, fez o quê?" Nada assim, sená. Foi mais um canal de atendimento que você teve. Eu gosto de pensar muito econômicamente, tá? Então, pô, pensa aqui no Instagram, "Aleimar eles custam uns 250 mil reais por mês". Se eu gastei quatro meses desse time, eu gastei um milhão de reais. Fala botar aí aí um bom fluxo, porque ele custou um milhão de reais. Se ninguém usa, foi um de um milhão de reais jogado no lixo. Mas zero é uma aposta. Você tá apostando um milhão de reais, filho? Como assim, enfim, não. Senta aqui. Senta aqui, Calde, vamos começar. Um milhão de reais, a aposta tava pra fazer uma aposta. Não era melhor ter colocado, sei lá, acho assim, um pouco mais inteligente. Eu acho que a gente parou de pensar, meu Deus, parou de pensar. A gente parou de. Como é que eu faço isso, custando menos? Eu acho que o low-code, o low-code veio tarde, nesse momento, tá? Sim, pô, eu acho que agora a gente tá vivendo uma renascença, tá? Sim, eu acho que a gente tá tentando, eu acho que a galera de produta ela vai mudar o papel. E aí, de novo, esse pode estar nesse buraco, mas eu acho que o produteiro, agora ele para de ser. Ele vai continuar sendo finca e analítico, mas ele começa a ser bioder também dessa história. Ele ajuda a construir esses pequenos experimentos, sabe? Precisam de menos engenharia heavy. Precisa mais de uma interação rápida, sabe? Para validar uma coisinha ou outra. Então, eu acho que, ferramentas como lova, ou salvia o cloud code, e sou um, eu acho que essas ferramentas vão catacultar o poder do a galera de produta. Isso é um tema que eu não vou entrar. Tema que, se a gente abrir esse buraco aqui. Eu acho que o nosso problema aqui no Brasil nunca foi velocidade. Foi mais clareza. E aí, quando a gente fala que a pessoa de produto vai começar a criar, buildar, né? Criar as coisas, cunhar. Eu acho que a gente está criando um novo problema. Porque a gente está saindo do criar qualquer coisa, com engenharia, para criar qualquer coisa com o produto. O que eu quero dizer é, se a gente não tem ainda, não estou falando todo mundo, está bom você, que está ouvindo e se acha. Mega, ok, não é sobre você, estou falando, estou generalizando e ao generalizar a gente pega algumas exceções, mas é isso, a exceção não é a regra. A gente vai sair da pressão de engenharia, ter que fazer, entregar rápido para o produto ter que buildar e jogar para o ar rápido. E aí, a gente perde, porque o problema nosso não é ferramental, porque a gente consegue, por exemplo, fazer um teste a B. O PM deveria saber mexer numa ferramenta de teste a B, junto com o PD, o PD faz a tela, ele sobe e faz o teste a B. Sozinho, eu preciso de engenharia. Então, eu acho que. Eu sou muito o lance do ferramenta e ferramenta legal, mas eu acho que o nosso problema, um área aqui no Brasil, o contexto brasileiro, é mais no pensamento e na estratégia. A gente não tem clareza do problema que a gente quer resolver, a gente não tem dados antes de lugares, a gente não tem dados. Em muitas vezes a gente pergunta para a nossa liderança, qual é o nosso objetivo? Não aparece. E cada reunião, a estratégia muda, igualzinho, viruta de aeroporto. Eu não sei se a maturidade da maioria das empresas brasileiras, aí eu não estou entrando com governança, segurança da informação, toda a parte mais técnica das empresas terem ferramentas para os time de produtos build-up. Eu só acho que a gente não alcançou uma maturidade que talvez o Vale do Silício tenha por eles terem cliente inovador que eles estão ali. Tentativo erro, tentativo erro, tentativo erro, tentativo erro. A nossa tentativa e erro, muitas empresas, gera feedback negativo, que era um porra, perdemos uma sprint para colocar algo no ar e não dar resultado, ao invés de olhar e fazer "não", a gente colocou algo no ar e o que aprendemos com isso? Exato, estou contigo, mas quando eu falo do produtero COD, eu não estou falando de ele fazer o produtio final, acho que é muito mais sobre como é que o produtero usa ferramentas para gerar, por exemplo, a tela do teste AB, qual é estar mais dado, qual é estar mais informação? Eu acho que está aí, acho que ele não é um build-up do produtio final, ele é um build-up de soluções rápidas para pegar mais informação. Eu acho que está aí, porque hoje o que acontece, hoje o que acontece é muito do time de produtio, demanda para engenharia, esse tipo de trabalho, e aí os cara vai fazer um negócio ali, que talvez agora com a ia, isso vai ficar um pouco mais rápido, mas claro, a mente leva em uma semana, pois às vezes, coisa de dias ou de horas, só você construir, vamos fazer tá a chave cede aqui, vamos usar o teatro de benda, a gente vai apetar seis versões diferentes, e o algoritmo vai escolher qual é a melhor ser. De acordo com o uso, eu acho que a gente está chegando, era que a gente vai testar mais, sabe, eu acho que a gente testar mais coisas, e eu acho que a, o produto agora, ele vai, ele vai ter que pensar um pouco mais sobre, qual são os testes que valem apenda, eu coloco a no ar? E aí, tipo, no final, eu vejo quem performou melhor, e aposto nisso, o encontro outro, o primeiro encontro segundo, e aí eu vejo quem performou melhor, sabe, o aprendo, onde é que está o mapa de calor do meu usuário naquele canal, e aí a gente tem que identificar, e a gente vai estar muito, muito comente agora também, que são os uso de canal e intencional. A gente, as pessoas vão declarar suas intenções num chat, num via voice, e tal, eu quero pedir, usando esse tal, de tal lugar, para a Alexa, Alexa como diga com a efo de a efo de quando a gente vai na sua casa. A gente está beirando esse evento, entendeu? E, cara, como é que você testa coisa nesse cenário? A gente está indo pro lugar legal agora, eu acho que tem, vai ser da hora aqui para frente. Ou, Zara, antes da gente seguir continuando nesse, nesse tema de build, o quanto uma pessoa de produto que não sabe fazer o famoso FDP, é fatiar, descartar e priorizar, gera de problema no time de engenharia. É porque eu fui ensinado a isso, né? Eu fui ensinado a, vai falar "PD", vai lá falar com "PD", e o "PD", a gente vai lá, entende o problema, ve o funil, ve a jornada, onde está a fricção, tal, seu quer, vamos melhorar a experiência. E o "PD" desenha a experiência, e a gente leva a experiência para o time tech. Lica, o "porque", o "número", o "guépe", o "que" que a gente pretende com aquilo, porém, eu não falo "vamos fazer isso", eu pergunto. Qual é a fatia disso daqui que a gente pode entregar rápido para gerar resultado rápido? Porque muitas das vezes tem um que nenhum brincava com os time tech, gente, vamos pensar assim, existe um, dois, três, quatro. Mas se vocês olharem para mim e falar "chode", eu consigo fazer, a gente consegue fazer um, um e um, três. E esse um e três, ele já vai entregar o objetivo, o quatro e o cinco, a gente deixa no paralelo, quando a gente entregar, a gente já puxa esse quatro para poder entregar. Falta isso, ou isso tá em todos os time que você já viu? Esse é meu sonho de princesa, meu sonho de princesa é que é eventualmente o time de engenharia e produto se enxerga como um coisa só para trocar nesse nível. É isso aqui que a gente pessoa, galera, como é que a gente vai pro, de primeira? Ou como é que a gente fatia isso? Ou pessoal, o que é que vocês têm para, o que vocês acham, o que é que você acredito que a gente consegue rápido e capturar mais informação? Eu acho que a gente não, de primeira gente não capta, nunca o captura é resultado, assim, eu acho que a gente captura informação que eventualmente vão te levar com isso e outras coisas que eventualmente vão te levar ao resultado. Eu acho que, de novo, é ansiedade, a gente pensar que o que a gente vai construir vai gerar resultado, e aí não vem um resultado, todo mundo sofre e às vezes o resultado vai chegar a um, oito meses depois, um ano depois. Se ainda tudo bem, eu acho que faz parte do jogo, nosso mercado é nesse ouro, as pessoas são ansiosas, então todo mundo quer o resultado. Mas eu acho que quando você supermuta, eu acho que o mercado anda longe de estar assim, isso não é uma norma, muito pelo contrário, se você encontrar lugares assim, esses são lugares de acessão, mas isso deveria ser norma. O que você, como produto, aproveita todo o potencial com a diminutivo do teu time, e eu acho que melhor ainda você entra no segundo nível da pirâmide de lição, que ele fala sobre você ter conflito de ideias, você, você capturar ideias do grupo. O crowd vai ser sempre maior do que eu indivíduo, do ponto de vista, de trabalhador, no fim de dia, uma tera prima ela é o conhecimento, né? Então a gente trabalha com o trabalhador do conhecimento, o trabalhador do conhecimento precisa de duas coisas para estar um track. Uma vez psicologicamente seguro, você se espou, você coloca o seu na mesa, é isso que você falou, é você ter essa abertura para colocar na mesa e se sentir bem. Tivem de alta performance, os que eu liderei tinham esses dois componentes muito fortes, era um ambiente onde você podia botar tudo na mesa e pensar que você estava falando deste tera. E tá tudo bem a gente aí, e a gente até se saber, a gente já estava aproveitando, se falou "merda", tá tudo bem. E pô, se você se sentiu bem, assim, acho que se sentiu bem do ponto de vista social, de acolhimento, sabe, de tessem, de semestre você podia colocar para fora, e se sentiu útil. Puts, eu falei um negócio que, pô, a gente pensou, e o shod falando que se pô, é verdade, se a gente for tipo, com passo 3 e 4 a gente vai fazer isso para entregar na segunda-feira, ou na próxima segunda-feira. E cara, a gente já começa a medir alguma coisa ali, e o tarroma, ele vai ficar falando assim, acho que é um jogo sem fim. O grande problema é que eu veio short, é a gente que querendo aplicar técnicas do mundo de projetos em produto. Isso, isso para mim, é o rânsito, ele dá uns cinco ou volta dentro de mim, é quando você fala lá de trazer puts, a gente, a gente faz a gente gosta muito de fremo, porque assim, o mercado PTBR de tecnologia lá, tanto no fremo, malemal, esse fremo que eles vieram, são as consultorias. A gente não vive um de consultoriente, vive um mundo de produto, assim, são técnicas de projeto que ele tá querendo aplicar em produto, não funciona, gente, desculpa. Sim, talvez você capta a intenção, o princípio e tal, beleza. Mas você tem que ir à parte que é diferente, então assim, "Ah, Zara quer dizer que o Scrum é horroroso para estar apto?" Não, mas só que eu acho que você precisa do seu sabor de Scrum, o sabor do que é que o Scrum entrega, como o Scrum no fim do dia ele, o princípio é entrega as pequenas e incrementais. Ninguém fala, "Ah, não, tem que ser de 12-12 semanas." Você pode fazer isso todo o dia, se você quiser, filho, mas a ideia que você entra aí pequena e incrementar, pode ser bloquinho, você vai me pegar no bloquinho, no produtão. E esse produtão, quando você fica pronto, não fica, esse é o ponto. E as pessoas ficam tentando encaixar coisas, caras, vezes é, aos princípios, as pessoas se apegam muito mais a fremo que você quer princípio, eu acho que a gente deveria mudar isso. Mas mais no fim do dia, é muito sobre isso, assim, você tá no mundo para a mesa, com essa mentalidade de questionar o que a gente tá fazendo, sabe? Tipo, isso a gente tá fazendo isso porque, com a abriza aqui, vamos fazer o pé dele, já que veio, sabe, um cado, sabe, o ruchado, vai entregar daqui a duas, três, quatro semanas. O que a gente vai fazer, é isso que você falou, "Vamos fazer xapa, vai entregar, mas vai entregar o valor de novo." A gente pega no nosso Scrum, é o pequeno e incremental, o 2 agora, depois vai entregar o 3, o 4, o 8, o 14, porque a gente priorizou aqui. Para a gente tem conforto e confiança, né, de que essa é uma estratégia melhor. E quando você tem um tipo de comprada nisso, ouça, é o sonho, isso vai me atrapalharmos. E aí entra, né, a gente começa a falar sobre isso. Esse seria o seu maior desafio liderando engenharia nos últimos tempos, de tentar alinhar a visão técnica com as demandas de negócio e produto. Qual é a sua abordagem? Acredito que cada empresa que você passou assim, foi a adaptaira só a abordagem. Se eu fosse uma liderança de tecnologia de engenharia, qual a abordagem que eu devo ter para alinhar as expectativas? Meiro, entender o que você está fazendo assim. Para quem você está fazendo, quem eu tenho os orfinal, acho que primeira coisa que você. Isso é primordial do ponto de vista de engenharia, outra coisa. E é engraçado, se você falou, que alguns lugares me deram carta branca total. E aí, eu acho que é um nosso que a gente tem que entender, também quer. Tem lugares que você vai trabalhar que vão te dar fua autonomia. E eu acho que esses são lugares onde pessoas que são mais questionadores como eu, mas para o vocativo, elas conseguem se dar melhor, porque elas vão desafiar o status quo, elas vão eventualmente comprar o barulho da empresa e sair do outro lado melhor. E tem empresa que eu fui totalmente tão lido, sabe? Essa é a sua caixinha, não estou dizendo que está errada, mas é. Escolha, isso acontece, mercada acontece, que ele é você ou não. E nesse lugar, eu me senti um pouco mais batedor de bumbo. Eu acho que o batedor de bumbo ele não consegue. E aí, de novo, vai desainta. Batedor de bumbo ele não consegue questionar as coisas, não consegue quebrar essas barreiras e fazer isso de maneira acertiva. Então, o ambiente tem que estar apropista para você primeiro, chegar e fazer um bom trabalho de quebrar essas coisas. Mas percorra-se aí, entender pra quem. Se eu vamos supor que eu tenho autonomia, eu posso fazer isso agora, e o ambiente me propõe isso. Cara, o que é meu usuário final? Qual são as donas desse cara? Eu gosto muito da tomo de design. A gente trabalha muito com pessoas. Quem é a pessoa? Quem é o usuário-médio? E quais são os outliers? Eu acho que você definir a pessoa na principal e dois a três outliers. A gente ajuda muito a identificar e ter em mente para quem está fazendo o que você está fazendo. #2 é. O que é que é a posta e o que é que é produto final? É isso muito bem mapado. Te ajuda a colocar o time também o time técnico muito de entender. Que tipo de engenharia a gente vai construir pra esses desafios? Eu acho que isso também é muito sharp, muito afiado, muito interessado. Pra que tipo de engenharia que a gente vai querer provocar? Porque isso no fim do dia influencia a moral do time técnico, tá? Às vezes é isso que eu te falei, a gente está mirando no negócio que é long journey, assim cara, construindo coisas pra ganhar dinheiro com a metodologia do GoRoss e vice-versas. Então isso destrói qualquer time. E o outro é comunicação. E aí eu acho que a comunicação é o negócio que é deficitário hoje. E sempre foi na iduxa de software, eu fiz meu. É graduação muito, muito tempo. Naquela época também o maior problema do mundo de software era comunicação. E ainda é. De novo, eu acho que no Brasil isso fica mais intensificado do que a gente já falou. Porque o mercado precisou maturar muito rápido por conta da covid. E aí você tem líderes de engenharia, a liderança de engenharia, não só de engenharia. Todos as lideranças de tech que não sabem se comunicar, que não sabem eventualmente trabalhar naquele modelo do Andy Groove, um modelo matricial, né? De missão e função. Esses não sabem trabalhar naquilo. Elas inventam assim. E às vezes fica muito defensor da sua função e menos da sua missão. Mas no fim do dia o que gera roi não é a sua função. É a missão que você tá. A sua missão tem que tragar roi pra companhia. A sua missão tem que se pagar. Se ela não se paga, ou se ela não traga dividendos, se ela não é maior do que um, fazer do filho. Às vezes não adianta querer fazer milha engenharia do mundo. Usar as melhores técnicas de três atores, martinho queira, porque é não. Se não dá, não tá dando roi. Esquece a função, foca na missão. A comunicação laxava pra fazer as missões funcionarem. E assim, baixar, adaptar, tudo isso, pessoas não sabem fazer. As leranças não sabem fazer no Brasil. Desculpa, cara, se você tá vendo isso, se você tá puto comigo, reflete assim. Será que eu estou seguindo um bairro de boca? Ou eu estou sendo inteligente e suficiente pra desafiar o status quo e sair do outro lado? A gente, eu não estou defendendo aqui, é uma narquia, tá? Pelo amor de Deus, que eu tenho que dizer. Ah, você é muito anarquista, não, não só anarquista. Eu só falava do pensamento crítico. Critiquem. Mas critiquem com respeito. Não é para você ser mal educado, sabe? Desorouzo com ninguém, desorouzo. Você não se desorouzo com ninguém. Quero que você critiquem. Entenda, por que você tá fazendo o que você tá fazendo? E se desafi? Será que não tem uma forma melhor de fazer isso? Será que. Será que eu mantei a engenharia como o comod de controle funciona? Não poderia ser melhor? Olha, as pessoas meio que tipo. Comprou esses usados americanos e, cara, e ficam confortáveis com isso. Ah, e se eu estou usando a empresa X, Y, também está usando a beleza? Eu estou certo. Estamos certo. Então assim, cara, todo mundo, todo mundo, e a impoa bater doiro. Mas estamos certo, estamos aqui, estamos todo mundo junto, cara. Ali tem, ali na frente, tem uma máquina de moe carne. Mas estamos todo mundo junto, vamos moe carne, estamos todo mundo junto. É o sério mesmo. Isso é que eu não acho comigo, né? Sim, cara, pelo amor de Deus, parem de ser bitolados, por que a cara se alenou, pauta. A cara se alenou, pauta. E aí pensando nisso, como que se constrói? E se mantém uma cultura de engenharia, é robusta, que formente isso que você falou agora de autonomia, experimentação, responsabilidade, ser anaquí a total, que você já mencionou aqui no episódio, menciona os contextos também. Boa, cara, para mim, eu acho que o primeiro coisa é contesto, claro. Vígula ou barra proposto, tá? Que é que a gente quer como proposto do que a gente está fazendo? A gente está fazendo pra quem? Porque sabe, acho que é diferente. Quando você tem montaço, claro, quando você não tem. Cara, eu já vi tímis que, caramente, os engenhos, eu não sabia por que eles estavam fazendo o que faziam. Mas você se entende como é que isso se conecta com o objetivo, né, gente? Mas você é como é que esse objetivo se distringe por as estratégias, caras, cara, não sabe? Eles são basicamente comprindo tabela, assim, sabe? O modo mesmo fabriu da coisa. Então eu acho que o primeiro coisa é aí. O outro coisa é guarde rei o mínimo, né, assim. A gente fala de autonomia, a diferença da autonomia da anarquia é os guarde rei, assim. Então, por, você vai até aqui, você tem uma decisão até aqui, sabe? Em cada nível de esfera, responsabilização e comprometimento. Eu acho que também é coisa que eu sinto muita falta, né? O inglês tem um palavra só pra isso que é vacar um tabelite, né? Mas eu chamo isso de apropriação, responsável de acessão e comprometimento. Cara, você é a proprinda dos desafios que vocês têm, sabe? Eu acho que é assim, pra montar um time de cultura de ingéria forte, as pessoas precisam comprar o barulho. Eu comprar o barulho na sua essência. Então, esse é a página pelo usuário ou mais piarigas que isso seja do ponto de vista de entender esse caro. O que é que ela precisa, quais são as dores dele, porque o que a gente vai resolver agora, é que está vendo mais, sabe? Monitorar, assim como a gente monitora saúde, de um paciente que está lá onde precisa. Monitorar também o nosso usuário, o uso do que a gente está fazendo, né? Mas princípios, claro, como putes, simplicidade no que faz, tá? Eu acho que tipo, uma cultura de ingéria não precisa ser complexa. Deu, putes, vou, vou estar aqui, sei lá, os 52 mandamentos da engenharia, pô, não, não esquece isso, assim. Tem que ter um uso do princípio, está na pô, a gente faz as coisas com qualidade, faz. Então, a gente faz, tipo, com qualidade de suficiente, eu chamo de engenharia suficiente, engenharia Renov, assim, cara. A gente faz coisas, engenharia Renov. Tá com a contexto, né? A contexto de experimentação é um, um contexto de hipocaust, oção de produto final é outro. Tá, beleza. Agora, como é que isso? Isso está citando de beleza. Ah, e aí, eu acho que tipo, a gente pode fazer um break down. Pra teste, a gente vai utilizar como x, y, x, x, y, x, x, y, x, y, a gente vai dar ferramenta, ab, c, sabe. E isso é permissivo, assim, se você se conhece, tá fácil de acessar, sabe? No outro lado, no outro aspecto é, pô, a gente não faz raque, a gente sabe, a gente não faz grâmbi. No ponto de vista de construir pra alguém é dinheiro, é uma outra parada, a gente observa de uma maneira mais tuturada, a gente tem o de. Então, eu acho que definir esse ponto é super importante. Quando a gente fala de experimentação, aí eu acho que experimentação negócio quer. Super importante, quer, não experimentar no produto principal, mas experimenta com um grupo controlado, que você fala, pô, um fítico todo, um. Um grupo de controle, um family friend, um próprio time usando a ferramenta, pra ver como é que ele se comporta. Eu acho que a gente tem que evitar muito as anticulturas, né, do tipo, cada um faz de seu jeito também, porque aí, devar alguns. Cara, eu já participei de start-up, só onde cada time tinha um stack de tecnologias diferente. Aí você vai normalizar as coisas, e você não consegue nem conversar. Porque uma fez em paz, ou outra fez em load, ou outra fez em Java, cara, difícil, assim. Eu sou adepto do boring tecnologias, tecnologias chatas, mas que todo mundo conhece, o que todo mundo domínio, que seja fácil, que as pessoas trocarem figurinhas ou intercambiar entre time e tá tudo bem, sabe? Eu sou desse time aí. Não, eu falei que você vai um pouquinho mais ser. Não sei se eu consegui trabalhar em bancões. Não é, porque tudo precisa de um comiteto, precisa de um gemúlio, acho que eu não sou esse cara. Mas eu acho que a gente precisa também de uma cultura que ela seja um pouco mais aderente ao business. Eu acho que a cultura tem que ser. A cultura de engenharia tem que ser aderente ao negócio, tipo, a minha escalota. Tem gente que vai estar super bem, ambientes mais caóticos e mais porradaria, e tá tudo bem. E tem gente que vai estar super bem também, ambientes mais conservador, ambientes mais registritas, sabe? Que seguem normas reguladas e tudo bem, também, sabe? Mas eu acho que essa cultura tem que conversar. Então, no fim do dia, eu acho que é isso, para você criar uma cultura boa de engenharia, acho que ela tá nesse lugar. Você que tá ouvindo esse episódio até aqui, o Zara vai voltar mais episódios. E antes da gente terminar esse episódio aqui com o Zara, tem a pergunta, que não tem como você conversar com Zara e não fazer para ele, que é. Qual é a sua verdade inconveniente sobre o mercado de produto ou engenharia, que pouca gente tem coragem de falar em voz alta? Eita, chefe, eu tenho alguns, tá? Eu tenho uma bolsa cheia desse negócio. Vamos lá, deixa eu ver um que casa é muito bem aqui com a audiência, que é, cara, o PM hoje, que não entende tecnologia, ainda mais com os adesventos de ar, tá? Ele é tão útil como quando um vendedor que não conhece o próprio produto, não conhece a qualidade do seu produto, não conhece as entrando do seu produto. Então, assim, hoje, ainda vejo, ainda vejo, e eu acho que eu fico triste quando eu vejo, o PM escreve são menos tecnológicos do que tiverem, e eu não tanto falo para ninguém fazer o custo de essência de computação, tá? Esse eu quero que as pessoas entendem com o build-in-block de tecnologia, como a qualidade do corpo da bolsa é, para me vender aquela bolsa. Tá aí, tá? Eu acho que ele precisa entender isso, o meu produto hoje, tá? Para escalar ou não? E eu acho que fato falta desse conhecimento ainda? Infelizmente, tá? Eu falo isso com um dono no coração. Mas isso é uma verdade de chat. É o famoso do tipo, você não precisa saber codar, mas você precisa saber como que uma API funciona. Sim. É, é. É um link para a Sheila que é maravilhoso, não sei se conhece a Sheila. Qual? A Sheila Sheng. Sim, sim, caro, livre-nos. maravilhoso, lembro dela, sim. Para mim, eu acho que todo mundo tem que mais ser exául, lembro da Sheila. O link do livro da Sheila Sheng, está na descrição para que você possa adquirir, ela é incrível, é maravilhosa, e ela explica de uma maneira tão sobre um assunto tão, né, plataforma e tal. E aí, para a gente terminar as áreas, sim. A gente vai terminar aqui para que a gente possa fazer usar a 2 aqui, daqui, até que você, até que eu convém, se você vim, quase toda semana aqui no podcast. Quer se? É mais importante, na sua visão hoje, nas empresas. Não seria mais importante. Project operation e um PM de plataforma do que um EIPM. Nossa. Conteço brasileiro. Conteço do PTBR, como certeza. A gente é muito ruim de operação de produto, tá? Eu acho que nossos produtivos estão muito mais hoje, focado de novo, em cima até ocupado o que é produtivo. Eu acho que o produtivo é mais produtivo. Na sua essência, ele já é mais produtivo. Eu. tem um tema que eu acho que é o Uberabirou, assim. Cara, tem uma galera de produto que vai pra um Uberabirou, assim, cara, narra, hein, assim. Eu falei, "Cara, vamos voltar, vamos voltar, voltar, voltar, voltar, fazendo o chão." E eu estou coxido, tá? O produtivo de plataforma hoje, ele é um bicho escasso no Brasil, assim. Ele é. eu chamo de golo, é o Coelho Dorado. Quem tem, deixa eu no quintal, não mostra pro vizinho, e cara, e cuida com o nosso medo do mundo. É o Coelho Dorado. Não tem. Eu trabalhei com o trabalho com o plataforma, assim. Desde. de. 20. em 2020. É de 5, 6, 9, 6, 9, 8. Eu conto nos dedos de um amão sem usar todos os dedos, os PMs, bons de plataforma que eu conheci, e trabalhei. É bizarro, falta. Falta, bastante, tá? E assim, eu fiz essa pergunta porque é assim que vai iniciar o segundo episódio, um zara, daqui a 1 semanas. Porque vai ser sobre plataforma. Porque a gente fala muito de ar, muito de ar, muito de ar, muito de ar. Só que as empresas que estão conseguindo usar a ar, como meio, para escalar e gerar resultados financeiros, são aquelas que entenderam que a ar, se se coloca na camada de plataforma, de estrutura. Não ali na ponta, numa featuring, coloca uma tag no marketing ali. Então, zara, muito obrigado. Você vai voltar. Você deixou essa porta aberta de plataforma, a gente vai voltar. Porque a pergunta que não quer calar, zara, é. Por que? Que plataforma não é tratada como negócio, muitas empresas. Mas não, não responde. Não vou responder essa agora, mas eu tenho uma boa resposta para isso. No próximo episódio, com o zara, que tudo indica que vai ser daqui a 1 semanas, 2 semanas, 3 semanas. Se beber, se eu quiser, porque eu sou dando um podcast, eu coloco três do outro, foda-se. Eu só estere que roda daqui. Eu tenho um desejo. Enfim, é isso. Zara, muito obrigado, meu. Obrigado também, obrigado. Pra mim, de novo, só de precisa estar aqui, tá? Eu acho que depois acompanho o trabalho, tem. Eu acho que um dia eu vou ser de produto, de verdade. Eu acho que a gente, no Brasil, a gente carece ainda de pessoas, de engenharia, pensando como produteira. E eu me vejo muito mais às vezes como produteiro do que. E não, pra mim, assim, biota. Eu não sei implementar. Eu deixo de ser engenheiro e vire o produteiro. Mas eu acho que o meu sonho precisa de um dia de trabalhar com produto. E quero você, pra mim, é uma referência que faz um trabalho aqui na comunidade do Brasil. Quer ver uma outra problema que quer dizer a abordada nos outros episódios, é. É mais importante, para as startups, estar em um produtor engenheiro, no que é um produtor mineral. Nossa, tu vai querer puxar isso mesmo? Minha leitura que produte engenheiro. A gente já tem muito, eles só não sabem que são. Exato. A gente pegou a nome clatura lá da gringa, colocou aqui, mas não trouxe o famoso Proud Hat. Porque quando saiu a polêmica de build, eu falei, "Pô, não é essa. O rolê não. O rolê é Proud de engenheir, pô. É estilo stripe. Você que está ouvindo até aqui, ficou curioso sobre Proud de engenheir e Proud Hat. Procure a história da stripe, que você vai entender que a stripe começou sem Proud de Menagers, ou Proud de engenheirs. Mesmo quando eles contrataram Proud de Menagers, eles manterem em sua cultura, em seus valores, o Proud Hat. Então, todo mundo engenheiros tinha que ter cabeça de produto. Fazer a parte do processo seletiva até deles continua sendo. Então, é isso, Zara. Se a gente ficar aqui, a gente vai ficar 5 horas com isso. Exato. Fica de boa. Mas muito obrigada. De verdade, de coração, fica super feliz com um convite. É legal saber que a gente consegue, hoje em dia, ter essa zé, ter Paulo como referência. Link do link é de Zara, está na descrição. Newsletter tem livro, né Zara? Tem livro. Tem o nosso cabelo no livro. O livro é o antes que seja tarde, basicamente é um resultado de alguns banautes. Onde eu antecipo muito das dores, muito desafios que a Thomas vai ter com liderasse em tecnologia. Eu tentei antecipar no livro. Cara, o livro é um montuado de relatos e contos meus, meus mentorados, meus lheirados, ao longo dos últimos 10 anos, liderando em tecnologia. Link do livro está na descrição. E a gente vai fazer esse livro ser o mais vendido, se não já não é o mais vendido, dá armas. Então é isso. Beijos. Tchau. Fui.

Podcast Summary

Key Points:

  1. A dívida técnica no mercado é resultado de uma desconexão entre produto e engenharia, não de decisões puramente técnicas.
  2. É essencial uma relação de parceria e confiança entre as áreas, com menos hierarquia e mais colaboração, focando em problem framing, definição de feito e métricas de sucesso.
  3. A falta de intencionalidade e clareza estratégica leva a "entregas vazias", onde times estão mais ocupados do que produtivos, sem gerar valor real.
  4. A engenharia deve entender profundamente as métricas de negócio e o impacto no cliente, utilizando dados para orientar decisões.
  5. É crucial diferenciar contextos como "build to learn" (construir para aprender) e "build to earn" (construir para gerar valor), aplicando abordagens de engenharia adequadas a cada um.
  6. O problema central no Brasil muitas vezes não é velocidade, mas clareza estratégica e alinhamento, com uma tendência a atender desejos em vez de resolver problemas reais.

Summary:

A transcrição discute os desafios na relação entre produto e engenharia, destacando que a dívida técnica prevalente no mercado é sintoma de uma desconexão entre essas áreas, não de falhas técnicas isoladas. Argumenta-se que é necessário romper barreiras hierárquicas, estabelecendo uma parceria baseada em confiança, com foco conjunto na definição clara do problema, nos critérios de conclusão e nas métricas de sucesso. A falta de intencionalidade e alinhamento estratégico resulta em "entregas vazias", onde a produtividade é confundida com ocupação, sem gerar valor real para o cliente ou negócio.

Enfatiza-se que a engenharia deve compreender profundamente as métricas de negócio e o impacto no usuário, usando dados para decisões mais racionais. Além disso, diferencia-se contextos como "construir para aprender" e "construir para gerar valor", requerendo abordagens de engenharia distintas. Por fim, critica-se a cultura de priorizar desejos em vez de resolver problemas reais, apontando que a clareza estratégica, e não apenas a velocidade, é fundamental para o sucesso, especialmente no cenário brasileiro.

FAQs

Os débitos técnicos geralmente surgem de uma desconexão entre produto e engenharia, onde a engenharia executa tarefas sem questionar ou entender o propósito, falta intencionalidade e alinhamento estratégico.

Deve ser uma relação de parceria e confiança, não hierárquica. As equipes devem se enxergar como uma unidade, com comunicação transparente e objetivos compartilhados.

1) Enquadramento do problema (definição clara e evidências). 2) Definição de feito (critérios claros de conclusão). 3) Definição de sucesso (métricas para medir resultados após a entrega).

Para que o trabalho seja intencional e gere valor real. A engenharia precisa compreender como o sucesso do cliente e as mudanças em sua vida estão ligadas ao que está sendo construído.

'Build to learn' é um modo experimental para validar hipóteses, enquanto 'build to earn' foca em gerar receita. A abordagem de engenharia aplicada deve ser diferente em cada contexto.

Focando em resolver problemas reais do cliente e entregar valor, em vez de apenas atender desejos ou demandas internas sem propósito claro. É crucial questionar a intenção por trás de cada pedido.

Chat with AI

Loading...

Pro features

Go deeper with this episode

Unlock creator-grade tools that turn any transcript into show notes and subtitle files.