Olá, estudante da Alura. É um prazer ter você aqui em mais um curso. Nesta ocasião, nós vamos ver como a função de TechLead (liderança técnica) se integra à camada de custos, tanto em pessoas quanto em engenharia, arquitetura e ferramentas.
Antes disso, vou me apresentar. Eu me chamo Henrique Lamontanha. Sou engenheiro de software especialista, atualmente TechLead no Grupo Boticário, também sou instrutor aqui na Alura e arquiteto de soluções. Estou há mais de 14 anos no mercado de TI, construindo soluções de software. Já atuei em alguns projetos relevantes, como a implementação do Pix em algumas operações, decisões relacionadas a cartão de crédito e transações, sempre nos setores de varejo, fintech e bancos. Já desenvolvi diversas arquiteturas evolutivas. Atualmente, também lidero um produto de IA chamado PopCult, no qual atuo como CTO em sociedade com outras pessoas sócias. Também produzo conteúdo de tecnologia para a internet, YouTube e outras redes, e faço mentoria de equipes de engenharia.
Primeiro, vamos percorrer a camada de fundamentos do curso: o custo de engenharia para TechLeads (lideranças técnicas), como isso se conecta com as pessoas, e vamos trazer um modelo mental e um canvas (quadro) para tornar esse conteúdo mais acionável no dia a dia.
Segundo, abordaremos o custo de capacidade. Vamos entender como as métricas operacionais revelam o custo real da entrega.
Na Aula 3, vamos entender como as decisões têm impacto financeiro — se nós construímos, alugamos e usamos IA assistida — sempre com critério estruturado.
Quarto, veremos IA na Squad (equipe): eficiência de custo, governança e observabilidade.
Por último, mas não menos importante, vamos sair com um plano de 3 meses (90 dias) para você, como pessoa em liderança técnica, atuar na sua empresa.
Este plano será adaptável e construído em conjunto com você. Recomendamos levar isso para a sua vida profissional e colocar em prática na empresa em que você trabalha.
Teremos um fio condutor: uma squad (equipe) de produto SaaS (software como serviço) B2B (empresa para empresa), com custo crescente, baixa previsibilidade de entrega e pressão constante para adotar IA sem perder o controle financeiro.
Nessa squad, você exercerá o papel de Tech Lead (pessoa líder técnica). Esse será o papel que vamos assumir ao longo de todo o curso. Ao longo das aulas, tomaremos decisões reais para essa squad sobre custo, capacidade e IA, usando um cenário que reflete a realidade do mercado para pequenas e médias empresas.
Por que focar em pequenas e médias empresas? Em grandes empresas, esse papel geralmente não fica com a pessoa Tech Lead, mas sim com pessoas em cargos mais altos na área de tecnologia, como pessoas arquitetas, pessoas engenheiras em nível de Principal (engenharia principal) ou Staff (engenharia de staff). Em pequenas e médias empresas, a pessoa Tech Lead costuma acumular responsabilidades, cuidando também do produto e da área, com fronteiras menos segregadas. Em muitos casos, essa pessoa fala diretamente com os C-levels (altos cargos executivos).
Ao final desta aula, seremos capazes de:
Nos vemos no próximo vídeo. [♪]
Olá, assinante da Alura, é um prazer te ver aqui em mais um vídeo do curso.
Agora, vamos entender o cenário e o que queremos medir de fato. É possível que você já tenha passado por isso, mesmo não sendo a pessoa em liderança técnica, isto é, a ou o responsável por Tech Lead (liderança técnica), sendo membro de squad (equipe).
Nessa squad de um SaaS B2B (software como serviço para empresas) que estamos construindo, no último mês entregamos três features (funcionalidades), mas o custo em nuvem subiu 40%. É comum que a área de negócios cobre previsibilidade, porque deseja medir resultados e valor. A área financeira também vai acompanhar isso, não no sentido de cobrança punitiva, mas para entender se está realmente funcionando e gerando valor e lucro na ponta.
Surge então a pergunta que tanto assusta: por que nós gastamos tanto? O time olha para o FinOps (gestão financeira de custos em nuvem), o FinOps olha para o time, finanças olha para o time, o time olha para o FinOps e ninguém tem a resposta. Essa é a questão: ninguém se atentou a isso. Muitas decisões são tomadas durante a construção, principalmente quando o produto está em ramp up (fase de crescimento).
Nesse cenário, decisões técnicas são decisões financeiras — e isso é frequentemente negligenciado. Não há espaço para clubismo de tecnologias ou ferramentas. Ainda assim, essas decisões muitas vezes são tomadas sem visão financeira.
Alguns exemplos concretos que podemos trazer hoje:
Esse tempo de retrabalho é o mais fácil de endereçarmos, porque geralmente indica problemas de processos e da forma como as coisas estão acontecendo; dentro da squad, é mais fácil mudar isso.
O modelo mental de custo de engenharia que comentamos será: pessoas, plataforma e retrabalho. Ao unir esses pilares, vamos obter um baseline (linha de base) claro para chegar do outro lado com o plano de ação.
Sobre o pilar de pessoas, vamos considerar o custo total da squad (equipe), de forma agregada e não individual, por questão de segurança. Esse número virá da gestão ou de uma área de FinOps (gestão financeira de nuvem). Em alguns contextos, o ou a Tech Lead também é gestor, mas aqui trabalharemos com papéis separados. Portanto, pedimos esse número à nossa gestão ou à área de finanças; uma pessoa de FinOps (gestão financeira de nuvem) frequentemente terá esse dado. Reforçando: será um custo agregado — a squad (equipe) tem um custo — e não o custo de uma pessoa individual.
Somaremos esse valor ao custo de plataforma, que inclui o custo de cloud (nuvem), o custo de SaaS (software como serviço) que faz a empresa operar, modelos GA, e tudo que é computado por uso: compute (computação), storage (armazenamento), banco de dados, licenças de plataforma, entre outros. Tudo isso compõe esse outro pilar.
Há ainda o pilar mais “invisível”, que é o de retrabalho. Nele, avaliamos quanto tempo foi gasto em bugs, quanto tempo ficamos fazendo rework (retrabalho) porque algo não foi bem especificado — seja no código, seja no requisito — e quanto tempo passamos lidando com incidentes. Lembramos que incidentes geram desgaste não só de tempo, mas também emocional; War Room (sala de crise) não é um ambiente agradável. Portanto, quanto menor a incidência em nossa squad (equipe), melhor.
Esse tempo comprometido em correções representa capacidade que poderíamos ter convertido em entrega de valor, mas que foi consumida em ajustes. A partir daí, aplicamos FinOps (gestão financeira de nuvem) à engenharia. Em vez de analisar apenas o custo total da fatura — por exemplo, 100 mil ou 50 mil — passamos a olhar o custo por unidade de valor entregue. Ou seja, quanto custa entregar valor para o cliente. Essa é uma mudança importante de mentalidade.
Arquitetura, capacidade e custo de ar serão alavancas de custo para nós. Quem aciona essas alavancas é a engenharia, e não a área de finanças. A pessoa Tech Lead (liderança técnica) será a ponte entre a decisão técnica e o impacto financeiro. Essa pessoa precisa ter uma comunicação muito boa, traduzindo o que as áreas de negócio querem — ou acham que querem — para o que realmente faz sentido no contexto, e apresentando esses resultados para a gestão, tomando decisões em conjunto.
Antes, nós focávamos no custo total da fatura: “Estamos gastando 100 mil? 50 mil?”. Essa é uma pergunta genérica — “Quanto nós gastamos?” — e não é acionável; não nos leva a lugar nenhum.
Depois, teremos foco em custo por feature (recurso), por fluxo e por squad (equipe). Isso nos leva a uma pergunta mais estratégica: “Quanto custa entregar uma unidade de valor para o cliente?”. A partir daí, o cenário começa a mudar.
Agora, o alerta prometido neste vídeo: custo por pessoa não é uma métrica. Por quê? Porque, ao extrair custo por pessoa, geramos distrações e ruídos, e isso frequentemente vira ferramenta de cobrança. As pessoas tendem a relacionar o custo individual com a entrega daquela pessoa: “Está custando muito; talvez eu pudesse contratar alguém por...”. Esse não é o objetivo. Não se trata de fator de cobrança individual, mas de desempenho do time. É isso que vamos tratar aqui no curso, para não deixar ambígua a questão do custo.
Quando tratarmos do custo da squad (equipe), estaremos falando de custo por unidade de entrega. O custo total do time será um dos números utilizados para chegar a esse custo por entrega de valor. Portanto, o custo que vamos definir da squad (equipe) e o custo por fluxo nunca serão o custo de uma pessoa específica. Tenha isso em mente para não cair nessa armadilha.
Te vejo no próximo vídeo. [♪]
Olá, pessoa estudante da Alura! É um prazer ter você aqui em mais um vídeo do curso.
Nesta aula, vamos aprofundar o uso do Canvas (quadro) que comentamos nos vídeos anteriores. Como montá-lo? Nós vamos trazer uma sugestão, sem necessidade de prender-se estritamente a ela. Pode ser um documento ou uma planilha. Aqui vamos apresentar um modelo mais visual para que você possa adaptar ao seu contexto.
Geralmente, as squads (equipes) recebem a pergunta: Onde está indo o nosso dinheiro? Em que estamos gastando? É uma pergunta simples, mas, em geral, ninguém tem a resposta pronta porque não há acompanhamento, não existe um mapa, não há um norte. A conversa acaba virando um debate baseado em achismos, o que é desgastante e improdutivo. Alguém afirma: “Achamos que é a Cloud (nuvem), achamos que é a Yacht que implantamos no último mês, achamos que o time está superinflado, com pessoas demais”. Nesse cenário, atacamos o que parece caro, mas não necessariamente o que realmente é caro — uma armadilha comum.
Listar apenas o custo de Cloud não basta. Precisamos considerar pessoas, ferramentas, SaaS (software como serviço), Cloud (nuvem), IA e retrabalho. Se colocarmos tudo em uma única linha, vamos nos perder e não saber para onde ir. Portanto, vamos separar por pilares, algo que a maioria dos canvas por aí não faz, e, principalmente, não ignora o retrabalho. Este é, muitas vezes, o maior desperdício, geralmente invisível para a C-suite (alta liderança). Quando passamos muito tempo em uma demanda refatorando algo que deveria ter sido definido anteriormente por processo, estamos diante desse custo invisível.
Vamos, então, separar por pilares, entender quais são os custos invisíveis, formular perguntas diretamente no canvas e torná-lo acionável: com números, com perguntas que devemos nos fazer no nosso contexto e com ações mapeadas.
Um breve exemplo de engenharia de valor: baixo custo versus alto custo. Por exemplo, alta responsabilidade e alto custo. Temos custos atribuíveis por componente, algo que conseguimos marcar com tags (etiquetas). Excelente.
Como vai funcionar o canvas nesta aula? Teremos seis pilares: Pessoas, Ferramentas, SaaS (software como serviço), Cloud (nuvem), IA e Retrabalho.
Sempre que não houver visibilidade sobre algo, vamos colocar uma interrogação. Cada ponto cego mapeado se tornará uma ação explícita adiante. Não é necessário prender-se a este modelo; trata-se de um exemplo de como montar esse canvas. Ele pode assumir diversos formatos, como planilha ou documento. Aqui, utilizaremos o Miro para deixá-lo mais visual e permitir que registremos as ações de forma verdadeiramente acionável.
Como comentamos, vamos entender o custo total da squad alocado por fluxo crítico — e não por pessoa. O seu fluxo crítico pode ser único para a squad inteira, e a squad pode atuar em vários âmbitos; isso varia conforme o contexto. Vamos imaginar um exemplo com 8 pessoas, que representam um custo em reais. Para ilustrar, vamos considerar 50 mil. Depois, traremos um exemplo mais real nos slides, nas próximas aulas; por ora, é apenas para entendermos a dinâmica.
Essas 8 pessoas representam 50 mil, alocadas entre as responsabilidades da squad: features (funcionalidades) de onboarding (integração inicial), billing (faturamento) e notificações. Certo. Aqui, você vai preencher o custo total por mês e a alocação por fluxo, caso haja múltiplas responsabilidades. Se as squads forem separadas por domínio, geralmente aqui constará o custo da própria squad.
Uma pergunta de ponto cego para fazermos a nós mesmos: Onde não há visibilidade de custo de pessoas na minha squad? Aqui, retiramos a questão do retrabalho, pois haverá um pilar específico para isso ao final.
Nas ferramentas, o que podemos listar? Licenças, CI/CD, observabilidade e ferramentas de gestão, por exemplo, Jira e Kanbanize, caso esses custos pertençam à sua squad. Podemos incluir como exemplos GitHub, Datadog, New Relic e outros. Vamos preencher essas ferramentas e seus custos por mês. Quantos usuários temos por ferramenta? Em alguns casos, o acesso pode ser segregado. Nem sempre toda a squad precisa ter acesso. Não é necessário pagar 200 dólares por mês por pessoa se podemos conceder acesso a uma pessoa específica para algo usado uma vez a cada três meses. Talvez seja uma ferramenta mais de negócio: podemos deixar com a pessoa PM. Talvez seja uma ferramenta mais de acompanhamento de métricas tecnológicas: podemos centralizar com a pessoa Tech Lead.
Há ferramentas sem responsável? Algo cujo histórico ou finalidade não estão claros? Aqui, vamos mapear o que está sem visibilidade no momento.
O terceiro pilar é a Cloud (nuvem). O que entra aqui? Custos com AWS, Azure e GCP: quanto gastamos em instâncias, bancos de dados e custo de rede. Isso está devidamente marcado com tags (etiquetas)? Qual é o ponto cego aqui? Em geral, as empresas demoram para marcar bem os recursos; esse processo pode levar anos, principalmente quanto maior for a organização. Devemos atacar isso desde o início. Se temos uma aplicação rodando em AWS EC2, por exemplo, vamos marcar: isto pertence ao Value Stream (fluxo de valor) tal, da squad X e ao fluxo Y. Com isso, podemos filtrar amplamente: no próprio console da nuvem, extrair para planilha, criar painéis no Tableau ou no Power BI, cruzar dados e tomar decisões mais acionáveis. Ter esses componentes marcados com tags é uma das partes mais importantes do fluxo; por isso, a ênfase. E isso não vale apenas para o time, mas para toda a corporação. Se isso se torna padrão, já teremos percorrido metade do caminho.
O custo de IA vem crescendo muito nos últimos anos. O que geralmente entra aqui? Tokens (unidades de contagem de uso).
Tokens não são palavras. Uma palavra pode corresponder a 3, 4 ou 5 tokens, dependendo do caso.
Se utilizarmos um Gateway (porta de entrada) próprio ou um Gateway (porta de entrada) de terceiros, precisamos decidir por onde vamos acompanhar o uso. Quais modelos utilizamos? Qual é o provedor — OpenAI, Anthropic, Amazon Bedrock? Podemos utilizar um Gateway (porta de entrada) de terceiros ou um serviço que faça o roteamento para nós e, nesse caso, qual é a taxa cobrada, como, por exemplo, o OpenRouter?
Qual é o ponto cego que podemos nos perguntar para extrair informações úteis? Qual é o custo de IA por fluxo que temos, caso já exista algo implementado?
A partir de agora, vamos considerar o cenário em que não temos IA implementada em nossa squad. Nesse caso, não vamos preencher esse bloco. Mas, se precisarmos implementar — e o exemplo que temos aqui segue nessa direção —, vamos inserir IA de forma útil, que agregue valor com custo controlado, no nosso SaaS (software como serviço) B2B (empresa para empresa). Assim, estimaremos o custo mensal da IA, já que ainda não existe um custo real recorrente, e também o custo estimado por fluxo. Podemos fazer essa estimativa por requisição ou por token; em geral, as plataformas cobram por token, por ser mais granular e, portanto, mais justa para quem cobra e para quem consome.
Por fim, mas não menos importante — e já falamos bastante sobre isso —, precisamos contabilizar horas de debugs (depuração), rework (retrabalho) de especificação e incidentes: quantas horas por semana gastamos que poderíamos evitar. Vamos preencher, por exemplo: 12 horas por semana em correção de bugs, 6 horas por semana em retrabalho e 10 horas por semana em incidentes (esperamos que não). Vamos levantar esses números.
Se estivermos trabalhando com um fluxo de Kanban, com cards (cartões) acompanhados por coluna corretamente, será fácil levantar esses dados, desde que a equipe mova os itens de forma adequada. Se a equipe não movimentar corretamente, identificamos mais um gap: o fluxo não está sendo seguido e o processo não ocorre de forma fluida. Isso exige ação imediata. Vamos conversar com a liderança para trabalharmos esse ponto em uma retrospectiva, caso estejamos utilizando metodologias ágeis — o que é comum. Ainda assim, é um gap e precisamos mapeá-lo aqui.
Vamos preencher horas por semana em retrabalho e identificar o tipo predominante. Qual é o nosso 80-20? Onde estamos gastando mais retrabalho? Frequentemente, o maior volume está na parte de especificações mal elaboradas.
Este é o modelo que deixamos como sugestão para preenchimento. Podemos importá-lo para o Miro ou criar uma planilha por pilares com os campos a preencher. Observamos que são os mesmos cartões para cada bloco. Essa visualização no Miro tende a ficar mais clara; preferimos assim. No entanto, é possível fazer em tabela, no Google Docs ou em um modelo com o qual já estejamos acostumados.
Com isso, o papel do/a* Tech Lead* (liderança técnica) ficará muito mais voltado para o bloco de pessoas, pois será necessária uma atenção maior aqui, dados os alertas apresentados nas aulas anteriores. Não vamos calcular salário individual, comparar débito por produtividade versus valor ou usar isso como justificativa para cortes. Vamos solicitar o custo total da squad para a liderança ou obter com o time de FinOps, conforme a estrutura da empresa, e utilizar esse valor como denominador dos nossos cálculos de Unit Economics (economia unitária).
Como vamos chegar nisso para, finalmente, calcular o custo por funcionalidade? Vamos pegar o custo total da squad e dividir pelas features (funcionalidades) entregues no mês. À primeira vista, isso pode não parecer tão acionável porque ainda é um baseline (linha de base), um ponto de partida. Quando tivermos mais adiante algo para comparar, esse número se tornará fator de decisão. Se o nosso custo por feature (funcionalidade) diminuir, mesmo com mais pessoas na equipe, teremos evidência de ganho de eficiência. Antecipamos esse ponto apenas para evidenciar o valor desse dado que vamos utilizar mais à frente.
Se, por política interna, não for possível obter o número real, mesmo de forma agregada (e não por pessoa), vamos utilizar um proxy: o custo médio de uma pessoa engenheira no mercado para o nível da empresa. Com esse benchmark (referência), multiplicamos pelo headcount (tamanho da equipe) e obtemos um custo aproximado. Também podemos utilizar alguns magic numbers (números arbitrários) como pesos (por exemplo, “esta pessoa vale 1”, “esta pessoa vale 2”). Não é o ideal, pois a acurácia diminui, e não é algo a ser compartilhado com a squad inteira. É uma informação para a tomada de decisão pela liderança. Ainda assim, isso nos permitirá tornar a squad mais eficaz ao atacar pontos específicos de gaps.
Por que separar o retrabalho? Um bug que consome 8 horas de duas pessoas — que podem estar em pair programming (programação em dupla) ou investigando um problema — não aparece, em geral, na fatura e, portanto, não tem visibilidade. Esse esforço pode ser equivalente a uma funcionalidade não entregue: poderíamos ter entregue quatro funcionalidades, mas entregamos três porque gastamos tempo em retrabalho. Assim, ao separar tags (etiquetas) por fluxo crítico em nossas ferramentas de produtividade e agilidade, estabelecemos o pré-requisito para o baseline (linha de base). Sem tags (etiquetas), não conseguimos definir custo por unidade de entrega de valor; sem drill-down (detalhamento), não conseguimos analisar por fluxo crítico. Não saberemos, por exemplo, se a conta de billing (faturamento) custa mais do que o onboarding (integração), qual fluxo gera mais retrabalho, qual demanda mais manutenção, qual gera mais dúvidas ou em qual a equipe tem menos expertise. Tudo fica invisível e vago. Portanto, a primeira ação é organizar a casa, começar a etiquetar e separar, para conseguirmos chegar aos números e preencher corretamente o canvas (quadro).
Entendemos que o canvas (quadro) é o ponto de partida. Uma vez estruturado, teremos alguns números para analisar. Ele vai evoluir ao longo do curso; não em formato, mas nas informações que extraímos, as quais se tornarão insumos para decisões acionáveis adiante.
A Aula 1 será o canvas (quadro) de custos — o que tratamos até agora e ainda trataremos. É a foto inicial, o snapshot (instantâneo), um baseline (linha de base). O importante agora é ter essa foto inicial: onde está o dinheiro? Onde estão os pontos cegos? O que podemos melhorar? Algum ponto certamente ficará evidente; podemos ter confiança nisso.
Nas próximas aulas, vamos transformar isso em um painel operacional, construir uma matriz de trade-off (compensação) técnica, passar pela observabilidade de IA e chegar ao plano desejado.
Eu me despeço deste vídeo e até a próxima aula.
O curso Custo de Engenharia: conectar decisões técnicas ao impacto financeiro possui 278 minutos de vídeos, em um total de 37 atividades. Gostou? Conheça nossos outros cursos de Liderança Técnica em Gestão & Negócios, ou leia nossos artigos de Gestão & Negócios.
Matricule-se e comece a estudar com a gente hoje! Conheça outros tópicos abordados durante o curso:
O Plano Plus evoluiu: agora com Luri para impulsionar sua carreira com os melhores cursos e acesso à maior comunidade tech.
2 anos de Alura
Matricule-se no plano PLUS 24 e garanta:
Jornada de estudos progressiva que te guia desde os fundamentos até a atuação prática. Você acompanha sua evolução, entende os próximos passos e se aprofunda nos conteúdos com quem é referência no mercado.
Back-end, Dados, Front-end, DevOps, Mobile, Gestão & Negócios, UX & Design, Cibersegurança, Cloud, Inteligência Artificial
Formações com mais de 1500 cursos atualizados e novos lançamentos semanais, em Programação, Inteligência Artificial, Front-end, UX & Design, Data Science, Mobile, DevOps e Inovação & Gestão.
A cada curso ou formação concluído, um novo certificado para turbinar seu currículo e LinkedIn.
Acesso à inteligência artificial da Alura.
No Discord, você participa de eventos exclusivos, pode tirar dúvidas em estudos colaborativos e ainda conta com mentorias em grupo com especialistas de diversas áreas.
Catálogo de tecnologia para quem é da área de Marketing
Faça parte da maior comunidade Dev do país e crie conexões com mais de 120 mil pessoas no Discord.
Acesso ilimitado ao catálogo de Imersões da Alura para praticar conhecimentos em diferentes áreas.
Explore um universo de possibilidades na palma da sua mão. Baixe as aulas para assistir offline, onde e quando quiser.
20% de desconto na Pós Tech
Luri Vision chegou no Plano Pro: a IA da Alura que enxerga suas dúvidas, acelera seu aprendizado e conta também com o Alura Língua que prepara você para competir no mercado internacional.
2 anos de Alura
Todos os benefícios do PLUS 24 e mais vantagens exclusivas:
Acesso ao catálogo da Casa do Código e leitura dentro da plataforma
Chat, busca, exercícios abertos, revisão de aula, geração de legenda para certificado.
Modo entrevista - Pratique situações reais e evolua com feedback personalizado
Envie imagens para a Luri e ela te ajuda a solucionar problemas, identificar erros, esclarecer gráficos, analisar design e muito mais.
Aprenda um novo idioma e expanda seus horizontes profissionais. Cursos de Inglês, Espanhol e Inglês para Devs, 100% focado em tecnologia.
Para quem quer atingir seus objetivos mais rápido: Luri Vision ilimitado, vagas de emprego exclusivas e mentorias para acelerar cada etapa da jornada.
2 anos de Alura
Todos os benefícios do PRO 24 e mais vantagens exclusivas:
Lives CareerUp: eventos exclusivos com foco em empregabilidade e carreira
Mentorias de carreira: 2 encontros individuais com mentores do Talent Lab
Conecte-se ao mercado com mentoria individual personalizada, vagas exclusivas e networking estratégico que impulsionam sua carreira tech para o próximo nível.
