ESTIMATIVAS: A Desculpa Perfeita que Alimenta o MICROGERENCIAMENTO

Imagina que você tá naquela reunião de planejamento da Sprint e estimou que levava dois dias para concluir uma tarefa simples. Só que aí quando você pegou a tarefa para fazer, acabou percebendo que tinham algumas coisas que não tinham sido previstas e que agora vai levar mais tempo do que você imaginou. E aí o que era para ser uma tarefa de dois dias acabou virando uma tarefa de três ou mais.

Só que quando a tarefa atrasou, você começou a ser cobrado como se tivesse assumido algum tipo de compromisso fixo de entrega. E isso acaba deixando muito claro que aqueles dois dias que você disse eram, na verdade, um prazo disfarçado que você precisava cumprir. E se isso te parece familiar, fica muito tranquilo, porque isso é mais comum do que você imagina.

No vídeo de hoje, eu vou te mostrar porque que todas as estimativas de software estão erradas, porque que elas nunca deveriam ser tratadas como prazo e porque que ambientes que fazem isso cometem um grande erro que prejudica não só o time de desenvolvimento, mas também a qualidade do código produzido. Fala pessoal, Renato Augusto aqui de novo e dessa vez para falar sobre estimativas de software sobre uma prática nociva de alguns gestores ou até da cultura da própria empresa de tratar essas estimativas como prazos ou compromissos que você tem que cumprir. Se você já trabalha com tecnologia há algum tempo, é bem provável que você já tenha participado daquelas reuniões de planejamento, onde o time se junta para estimar o esforço ou tempo necessário para concluir cada tarefa que precisa ser feita.

E geralmente essas tarefas são estimadas em pontos, em complexidade, em tamanho de camiseta ou até em quantas horas você acha que vai levar para terminar cada uma delas. Só que o problema começa quando em alguns ambientes se torna normal a distorção do significado da palavra estimativa e esses números começam a ser tratados como se fossem prazos fixos que você tem que cumprir. Então, por exemplo, imagina que você pegou uma tarefa de implementar um end point novo numa API da empresa e aí você foi lá e estimou que levava dois dias para finalizar ela.

No dia em que você estimou essa tarefa, tava tudo bem, era só uma estimativa. Só que no momento em que você inicia ela e começa a desenvolver, a gestão começa a tratar esses dois dias que eram apenas uma previsão, como se fosse um prazo que você se comprometeu a entregar. E o mais curioso disso tudo é que ninguém fala isso abertamente.

O discurso é quase sempre o mesmo, de que você não precisa se preocupar, de que as estimativas não são prazo, de que elas servem apenas pro planejamento e que tá tudo bem se você atrasar. Só que você já percebeu que tem algo errado nessa história, porque basta você atrasar uma tarefa para perceber que o clima muda. E mesmo que ninguém admita isso abertamente, fica claro que aqueles dois dias que você disse que levava para terminar a tarefa, virou sim um prazo que você precisava cumprir.

E aí agora, com a tarefa atrasada lá no board, bate aquela sensação de que tá todo mundo te observando e sem contar que agora toda a daily que você participa vem acompanhada daquele clima de cobrança velada. E se esse ambiente te parece familiar, fica muito tranquilo que eu já te falei que isso é mais normal do que tu imagina. E o problema disso tudo tá justamente na falsa sensação de controle que as estimativas trazem para quem tá na gestão, chegando ao ponto de alguns gestores usarem essas estimativas para medir a produtividade do time e até para responsabilizar alguém quando a entrega não acontece exatamente como tinha sido estimada.

E para alguns gestores, essa insanidade toda pode até fazer sentido, só que essa abordagem, no final das contas, é um baita tiro no pé que prejudica não só o time de desenvolvimento, mas também a qualidade do código produzido e ainda alimenta a cultura do microgerenciamento. Só que antes da gente entrar mais a fundo e entender todos os problemas e os impactos dessa abordagem e como que você tem que se posicionar em ambientes assim, a gente precisa primeiro entender o que são estimativas, principalmente as estimativas quando a gente fala de software, porque enquanto isso não ficar claro, essas distorções vão continuar acontecendo e o cenário vai ficando cada vez pior. Então, para início de conversa e pra coisa ficar um pouco mais clara, quando a gente fala de estimar alguma coisa, a gente tá basicamente tentando prever o futuro.

A gente tá tentando responder quanto esforço ou tempo alguma coisa deve levar para ficar pronto. Estimar é literalmente isso, é chutar uma previsão. E toda previsão por natureza é uma incerteza.

Não existe esse papo de estimativa precisa ou estimativa exata. Até porque estimativa não é uma medida de precisão, ela é uma medida de probabilidade. E as estimativas não são ruins, elas são muito boas em alguns cenários, principalmente os cenários onde o nível de incerteza é baixo e as variáveis estão sob controle.

Então, por exemplo, imagina que você resolveu sair de férias e comprou uma passagem aérea de São Paulo para Dubai. E aí, no momento em que você tá comprando essa passagem, você já consegue ver até a previsão de chegada, onde o sistema te diz que o voo deve durar mais ou menos 14:35. E essa previsão, na maioria esmagadora das vezes, acontece com uma precisão absurda.

Isso porque esse tipo de estimativa é feita com base em dados históricos, rotas fixas, condições monitoradas em tempo real e ainda conta com sistema de navegação que considera altitude, vento, tráfego aéreo e até a rotação da Terra no cálculo. E não, a Terra não é plana, ou seja, é literalmente um ambiente onde todas as variáveis já são conhecidas ou pelo menos são fáceis de controlar. Por isso que a estimativa é confiável e se não acontecer nenhum incidente no voo ou algum tipo de pouso de emergência, a previsão acaba quase que sendo precisa, tão precisa que dá até para você agendar um Uber no desembarque antes mesmo de entrar no voo.

E essa mesma linha de raciocínio também era muito usada nas linhas de produção industrial, especialmente com a chegada do Camban lá nas fábricas da Toyota, na década de 40 no Japão. Naquela época, o Camban foi uma baita revolução, porque ele permitia visualizar todo o fluxo de trabalho, ajudava a limitar o IP, ou seja, o trabalho em andamento ou em progresso, e ainda garantia que todas as peças fossem montadas na hora certa com o mínimo de desperdício possível. E isso fazia total sentido, porque ali você estava lidando com peças físicas, com processos repetitivos e tarefas que tinham começo, meio e fim, muito bem definidos.

Você sabia, por exemplo, que para montar uma roda você levava 3 minutos e que para soldar uma estrutura você levava cinco? Então era fácil a gente cravar um prazo, medir até otimizar toda a linha de produção. E isso só era possível porque o nível de incerteza no processo de montagem também era baixo, igual o do voo aéreo.

E aí mesmo quando alguma coisa dava errado na linha de produção, no processo de montagem, dava errado sempre do mesmo jeito e era sempre o mesmo problema que aparecia. Então você conseguia reagir com processos padronizados de solução. E para você que ainda não sabe, o camban que muita gente usa hoje em dia na engenharia de software é baseado exatamente nesse modelo da indústria automotiva.

Então veio de lá essa ideia de limitar o trabalho em progresso, mapear o fluxo, medir o lead time, visualizar o trabalho em andamento e por aí vai. E o Camban ajuda muito quando a gente fala de gestão de projetos. Só que o problema começa quando alguns pseudogestores começam a distorcer o significado de algumas coisas e passam a tratar desenvolvimento de software como linha de montagem de carros.

E é lógico que isso não vai dar certo. Isso porque na fábrica da Toyota e nas linhas de produção, o processo era físico, previsível e controlado. Quando a gente fala de software é algo completamente diferente.

E aí se você tenta aplicar esse mesmo raciocínio de linha de produção no desenvolvimento de software e espera que as estimativas tenham o mesmo nível de precisão, é óbvio que vai dar problema. E o primeiro motivo que justifica a afirmação de que todas as estimativas de software estão sempre erradas e nunca deveriam ser tratadas como prazo é que software é algo intangível. Software por natureza é diferente de hardware.

É algo que não segue as leis do mundo físico. Você não consegue pesar ou medir um software. Além disso, o software é algo que enquanto tá sendo construído, tá mudando como se fosse um organismo vivo.

E aí, se você soma isso com o fato de que o processo de desenvolvimento sempre leva em conta conhecimentos técnicos, habilidades e experiências diferentes de cada desenvolvedor, fica claro que software não é algo que dá para você botar numa linha de produção e dizer que quer 10 crudes e cinco end points feitos por hora. E qualquer gestor que leve engenharia de software a sério sabe disso e sabe muito bem que as estimativas nunca deveriam ser tratadas como compromisso. Já o segundo motivo do por você nunca deve confiar em estimativas de software ou esperar precisão delas é uma coisa chamada viés do otimismo ou falácia do planejamento.

Segundo a psicologia, a neurociência, toda vez que a gente é exposto a uma situação onde a gente precisa fazer previsões, como é o caso de estimar tarefas, o nosso cérebro ativa automaticamente um processo chamado de simulação mental. O que o cérebro faz é basicamente construir uma espécie de filme mental de execução daquela tarefa que você tá tentando estimar. Só que o problema é que o filme que o cérebro cria é perfeito.

Ele não tem problemas, não tem atrasos, não aparece bug, não tem nenhum tipo de contratempo. Isso tudo porque, por natureza o cérebro humano é preguiçoso e ele tenta poupar o máximo de energia que ele puder. Então quando ele cria esse filme mental, ele acaba ignorando todas as incertezas ou coisas que podem dar errados durante o caminho.

E aí na tua mente tudo acaba fluindo perfeitamente. Você abre o código, faz a implementação e finaliza a tarefa. que durante esse processo não tem bug, a API responde, o processo colabora, ninguém te interrompe, o deploy passa e o P request vai ser aprovado de primeira.

E aí é em cima dessa imaginação que tá totalmente longe da realidade, que você estima que vai levar dois dias para terminar aquela tarefa. E é aí que tá o problema, porque no momento em que você estimou essa tarefa, você ainda não abriu o código, você não viu se tem dependência oculta lá dentro, você não viu se tem regra de negócio escondida, se tem problema no ambiente, você nem sabe se o que precisa alterar ou implementar tá de acordo com o que tá na descrição da tarefa. Só que mesmo assim você foi lá e soltou que levava dois dias para terminar.

E aí o que a tua gestão vai fazer é esperar os dois dias passar e aí quando a tarefa atrasar eles vão começar com aquela chuva de cobrança velada. E é nessa cobrança que mora o erro, porque esse valor que você chutou foi baseado num filme mental que tá distante da realidade. O teu cérebro não considerou nenhuma das incertezas ou problemas que você teria no caminho.

E é isso que a gente chama de falácia do planejamento, que prova que todas as estimativas estão sempre erradas, porque elas surgem de um processo cognitivo que simplifica a realidade, ignora o imprevisível e ainda te dá uma falsa sensação de controle. E aí você deve estar pensando assim agora: "Ah, Renato, mas isso aí é fácil de resolver, isso aí é mole, só botar uma gordurinha ali a mais na estimativa que resolve o problema. " E não, isso não resolve o problema porque além da natureza intangível do software e da falácia do planejamento que a gente acabou de ver, ainda existe uma série de leis e paradoxos que provam que qualquer tentativa de transformar estimativas em compromissos é um erro, mesmo se você adiciona um tempo extra quando for estimar.

E a primeira lei que rege essa afirmação é a lei de Hoffsteader. Essa lei foi criada por Douglas Hoffsteader, que era cientista cognitivo e da computação. E o que essa lei diz é basicamente o seguinte: sempre leva mais tempo do que você espera, mesmo quando você leva em conta a lei de Hofster.

Isso aqui a primeira vista parece só uma piadinha filosófica, só que na prática ela trata do caráter recursivo da incerteza. E basicamente o que essa lei quer dizer é que mesmo quando você sabe que a tarefa vai atrasar, mesmo quando você tenta ser realista, tenta adicionar uma gordurinha na estimativa e considerar os imprevistos, ainda assim vai demorar mais do que você previu. Isso porque o que atrasa uma tarefa nunca é o que você sabe.

É justamente aquilo que você nem sabe que ainda não sabe. É um bug que vai te pegar no meio do caminho de surpresa durante a tarefa. é o comportamento bizarro de um API de terceiro que você tá precisando consumir, é o tempo desperdiçado com reuniões inúteis e sem sentido, é a famosa alteração que o cliente pede em cima da hora.

Tudo isso faz parte do desconhecido que arrebenta a estimativa e que não tem como você prever. E é exatamente isso que a lei de Hoffste tenta nos alertar de que a incerteza é tão inerente ao processo que nem mesmo quando você tenta considerar adicionando uma gordurinha você consegue evitar o atraso e isso é a natureza do desenvolvimento de software. Então da próxima vez que alguém vier te cobrar uma tarefa atrasada perguntando por que você não considerou os imprevistos, você solta aquele sorriso amargo e responde que você considerou os imprevistos, mas a lei de Hoffster também.

Partindo agora paraa segunda lei que garante que estimativas nunca são confiáveis e que sempre estão erradas, é a lei de Parkson, que diz o seguinte: "O trabalho se expande até preencher todo o tempo disponível para sua realização". Essa frase foi criada por um historiador e escritor britânico chamado Parkinson, que observou esse fenômeno pela primeira vez na burocracia do serviço público britânico. E o que ele percebeu foi que mesmo quando tinha pouco trabalho para ser feito, o tempo gasto era sempre o mesmo.

Isso porque o trabalho se esticava de forma artificial para preencher o tempo disponível. E para você entender isso, vamos fazer uma analogia simples aqui. Vamos imaginar que tem uma tarefa que tranquilamente dava para você terminar ela em dois dias.

Só que aí, por algum motivo milagroso, a gestão resolveu te dar cinco dias para você terminar essa tarefa. E isso, a princípio, parece muito bom, porque agora você vai ter mais tempo disponível para finalizar a demanda. Só que o que vai acabar acontecendo é que ao invés de você terminar a tarefa em dois dias e entregar, você vai começar a procrastinar, deixando para investir tempo nessa tarefa perto do último dia, seja procrastinando, gastando mais tempo com refinamento técnico desnecessário ou refatorando coisa que nem precisava ser mexida agora.

E aí, o que era para ser uma entrega de dois dias vira uma entrega de cinco, não porque a tarefa exigia mais esforço, mas porque o tempo extra virou desculpa para você burocratizar e criar perfeccionismo desnecessário. E isso é literalmente o seu cérebro mais uma vez arrumando desculpa barata para economizar energia. E para fazer isso, ele preenche todo o tempo disponível da tarefa com coisas triviais até que aquilo tenha um senso de urgência.

E para ilustrar isso, é só você lembrar da época da escola ou da faculdade, de quando você deixava para fazer os trabalhos sempre na última semana, mesmo tendo dois meses de prazo. Só que o mais curioso dessa história toda é que quando a gestão transforma as estimativas em prazos, ela traz uma série de problemas. Só que, por outro lado, quando não existe prazo nenhum ou ele é folgado demais, o desempenho do time sempre cai.

Ou seja, quando você tenta tratar a estimativa de software como compromisso, o cenário sempre vai ser ruim, seja para mais, seja para menos. Partindo agora pra terceira lei, que diz que nunca devemos confiar em estimativas, é a lei da trivialidade, mais conhecida como Bike Sharing. Essa lei também foi criada pelo mesmo criador da lei de Parkson e ela parte de uma observação baseada em um comportamento humano que diz o seguinte: "Quanto mais simples e fácil de entender for um problema, mais tempo e energia as pessoas vão gastar discutindo sobre ele.

" Então, por exemplo, vamos imaginar que uma equipe precisa construir uma usina nuclear que tem uma planta monstruosa, cheia de complexidade técnica, risco, cálculo, engenharia, arquitetura e por aí vai. Segundo a lei da trivialidade, na hora que o time se reunir para discutir o projeto, eles vão passar a maior parte do tempo discutindo a cor do bicicletário do que de fato encarando os problemas mais difíceis e complexos do projeto. Isso acontece porque escolher a cor do bicicletário é uma tarefa simples e fácil.

que ali todo mundo se sente confortável para discutir e para dar opinião. Se a gente for trazer isso pro universo do software, o bike shading aparece de um jeito bem claro. As pessoas passam mais tempo discutindo e brigando por besteira do que pensando nas implicações técnicas de uma funcionalidade complexa.

Então, por exemplo, se a tarefa for criar um crude simples de usuário ou um end point simples no API, todo mundo fica debatendo, perdendo tempo e brigando até para escolher qual que é o padrão de projeto que vai ser usado. Agora, se o problema for implementar uma solução que precisa de jobs assíncronos, cash, evento, mensageria ou alguma tese com nível de complexidade alto e que não dê para ser quebrada em partes menores, você vai ver que essa tarefa vai ser votada com a menor discussão e atrito possível. E é isso que acaba criando uma distorção na estimativa geral da sprint, porque as tarefas pequenas acabam ganhando uma falsa sensação de controle e as tarefas mais complexas são estimadas de qualquer jeito.

E o resultado disso é que a sprint vai começar e as tarefas que eram triviais vão ser entregues logo de cara e isso vai acabar gerando aquela sensação de produtividade geral. Só que quando chega nas tarefas mais difíceis, os problemas começam a aparecer e a coisa acaba empacando. E geralmente são elas que afundam os resultados da sprint.

E isso acontece porque enquanto estava todo mundo discutindo a cor do bicicletário, o difícil estava sendo ignorado mais uma vez porque o cérebro humano tende a economizar energia. E todas essas leis que eu te mostrei e mencionei até agora, elas sempre apontam pra mesma coisa. Tentar tratar a estimativa de software como compromisso fixo é um grande erro.

E toda vez que alguém fizer isso, o resultado vai ser sempre o mesmo. Um time cansado de cobranças absurdas e um projeto sempre atrasado. Só que além de tudo isso que a gente falou, ainda tem um cenário que é pior do que esse, porque até então a gente tá falando de um cenário onde o time de desenvolvimento faz as estimativas e a gestão distorce e transforma isso em prazo.

Só que tem um cenário que vai além disso e que você provavelmente achou que eu ia esquecer de mencionar, que é quando a tarefa já chega estimada pro time de desenvolvimento. Então imagina que você tá lá tranquilo, focado em terminar suas demandas e de repente chega uma nova tarefa com um prazo já cravado e aí o gestor vira e fala que essa tarefa é para ficar pronta até sexta-feira. Só que até então ninguém te perguntou nada, ninguém estimou nada, ninguém refinou nada e muita das vezes quem decidiu esse prazo foi alguém que nem sequer entende o que tá pedindo e que provavelmente não escreve uma linha de código há mais de uma década.

E é nesse momento que o desenvolvedor acaba deixando de ser parte do planejamento e vira só o executor da sentença. Não tem conversa, não tem negociação, não tem discussão de viabilidade, você só tá ali para entregar e ponto final. E é justamente para mostrar porque que isso é completamente insano, que entra um conceito chamado triângulo de ferro ou tríplice restrição.

O triângulo de ferro é um modelo clássico da gestão de projetos que mostra que todo projeto é condicionado por três variáveis que são escopo, prazo e orçamento. E dessas três variáveis tem uma regra simples. Você só pode fixar duas num projeto porque a terceira vai ter que ceder.

Então, por exemplo, se você quer um projeto com escopo grande dentro de um prazo determinado, você escolheu escopo e tempo. Então, você vai ter que abrir mão do custo do projeto e elevar o orçamento, seja gastando com mais pessoas, com hora extra ou até com infraestrutura, tanto faz. O custo vai ter que ceder.

Agora, se você quiser manter o custo do projeto e o escopo do que você precisa entregar, você vai ter que abrir mão do tempo, ou seja, você vai ter que dar mais tempo pro time entregar. Já se você quiser manter o prazo de entregue e o custo do projeto, quem vai ter que ceder é o escopo e ele vai ter que ser reduzido, seja indo para uma abordagem mais MVP ou literalmente diminuindo o número de funcionalidades que precisam ser feitas. E isso aqui é ensinado em qualquer UNISKina ou MBA da vida.

Qualquer gestor que estuda sobre gestão de projetos sabe disso e sabe que não tem negociação com triângulo de ferro. Só que ainda assim parece que tem muita gente que ignora tudo isso e prefere seguir pelo caminho tortuoso, porque na prática o que a gente mais vê por aí é exatamente o oposto, que são as três variáveis travadas onde o gestor te coloca para abraçar um projeto com escopo, prazo e orçamento fixado. E quando isso acontece, só tem uma coisa que sobra para ser sacrificada, que é a quarta variável do projeto e que fica no centro do triângulo, que é a qualidade.

Se o tempo não muda, o escopo não muda e o time não aumenta, o que que acontece? O time começa a abrir mão da qualidade e produzir código lixo. É literalmente teste unitário sendo deixado de lado, refaturação sendo empurrada para depois, arquitetura ficando mais frágil, código gerado por IA sem o mínimo de revisão e um sistema completamente instável sendo colocado em produção.

E aí quando o bug aparece, o sistema quebra gerando retrabalho que vai consumir o dobro do tempo, ninguém lembra do triângulo, mas todo mundo lembra de apontar o dedo pro time de desenvolvimento. E que fique claro aqui que eu não tô dizendo que não tem que ter gestão de projeto. Todo projeto precisa de uma boa gestão e de um bom gestor.

Um gestor que seja organizado, que faça uso das metodologias da forma correta e que, acima de tudo, respeite seus colaboradores. O problema que eu tô trazendo aqui é de uma pseudogestão que costuma tratar estimativas como compromissos assumidos e acabam criando esse ciclo vicioso que se repete infinitamente e acaba fazendo parecer de forma proposital que o problema é o desenvolvedor. quando a tarefa estoura, e sim, é proposital em alguns ambientes.

Só que agora que você tá mais esperto e já entendeu que é impossível tratar previsões como compromissos e que isso é um erro que só os amadores cometem, a pergunta que fica é: o que que dá para fazer dentro desse tipo de ambiente e como que você tem que se posicionar quando a cultura da empresa insiste em tratar estimativa como contrato e prazo como profecia. Porque não adianta nada você só entender o problema se você continuar se culpando toda vez que uma estimativa estoura ou continuar aceitando calado quando joga essa culpa no teu colo. Então, indo bem direto ao ponto, a primeira coisa que você precisa fazer é mudar a tua percepção das coisas e saber que não é teu trabalho para ver o futuro.

Você não é mãe de e nem tem bola de cristal. Você não tá ali para fazer papel de astrólogo. Você tá ali para criar soluções e resolver problemas.

E isso, por natureza, exige margem de erro. Então, da próxima vez que você tiver num ambiente assim, você tem que reposicionar a forma como você se comunica. Não no grito, não confronto direto, mas com uma mudança na forma como você estima as coisas.

Então, da próxima vez que alguém te pedir uma estimativa, você tem que deixar claro que aquilo é só uma aproximação, não compromisso. Se possível, usa até uma linguagem que reforce a incerteza, tipo, com base no que eu sei até agora, acho que isso pode levar uns dois ou três dias para ficar pronto. Ou então, se não tiver surpresa nenhuma no código, se não tiver problema nenhum, eu acho que até sexta-feira dá para entregar.

Só essa mudança na forma de se comunicar já vai te ajudar aí muito a reduzir aquela velha cobrança velada, porque você começa a plantar a semente da dúvida e isso por natureza já vai aliviar a pressão depois. Outra coisa que você precisa aprender é a recusar escopo com prazo fechado, principalmente quando você não participou da estimativa. Então, se alguém vier jogar uma demanda no teu colo com tudo definido, a resposta não precisa ser agressiva.

Você pode simplesmente mencionar o triângulo de ferro que eu acabei de te ensinar aqui e perguntar qual é a vértice que vai ser reajustada, prazo, tempo ou escopo. E se ninguém quiser abrir mão de nada, você avisa que quem vai dançar é a qualidade. Só isso já muda o jogo, porque você mostra que entende o processo e sabe do que tá falando e não vai mais ficar sendo empurrado pr dentro de uma armadilha calado.

E aí tu deve est pensando: "Ah, Renato, mas aí eu vou ficar sem emprego, vou me mandar embora por questionar demais". E é por pensar dessa forma que tem muita gente emprego ruim por aí. O que você precisa entender é que esse não é o último emprego da tua vida e não vai ser o fim da vida se você sair dele.

Tem muita empresa bacana por aí aa que ainda valoriza as coisas sendo feitas do jeito certo e que principalmente respeita você como profissional. Porque no final das contas, a única coisa pior do que ser cobrado por uma previsão que você nunca teve como garantir é não ter alegria naquilo que você se propõe a fazer diariamente. Bom, e agora que tu aprendeu tudo sobre as estimativas, como que elas funcionam, como que elas são distorcidas dentro de alguns ambientes por aí, principalmente como que você tem que se portar em situações como essa para evitar e lutar contra essa cultura do microgerenciamento.

Deixa teu like aí, se inscreve no canal, ativa o sininho para tu não perder nenhuma notificação. Se esse vídeo te ajudou de alguma forma, eu te convido a se tornar um membro oficial desse canal e apoiar essa produção exclusivaça de conteúdos que eu trago pra você semanalmente. Vou deixar alguns links importantes na descrição, então não deixa de conferir, dá uma olhada lá depois.

Se ficou qualquer dúvida, deixa nos comentários abaixo que eu prometo que eu tire um tempo para te responder. Por fim, eu vou ficando por aqui. Um forte abraço para você e nos vemos em breve.

Yeah.