Como explicas os £20M gastos em engenharia?

Conheço bem a dor de tentar justificar os custos de engenharia de software. Seja a explicar derrapagens de projetos a diretores financeiros numa grande empresa, seja a projetar a taxa de consumo de caixa a investidores numa startup, a conversa é sempre a mesma.

O diretor financeiro ou o investidor pergunta: “Estamos a gastar £15 milhões em engenharia. O que recebemos em troca?”

Abres a tua folha de cálculo. Tens o número de pessoas. Tens as faixas salariais. Tens uma lista de projetos em curso. Mas quando te perguntam “Quanto custou, na verdade, a reconstrução do checkout?” ou “Qual é o retorno daquela migração de plataforma de seis meses?”, estás a adivinhar.

Liderei equipas de engenharia em startups e em organizações maiores, com no máximo 30 engenheiros de cada vez. A escala pode ser diferente, mas o problema é idêntico em todo o lado: ninguém consegue dizer-te quanto custa seja o que for.

Nem as funcionalidades. Nem os projetos. Nem as “iniciativas estratégicas” que consomem trimestres inteiros. O dinheiro desaparece num buraco negro chamado “Engenharia” e toda a gente espera que saia do outro lado em forma de receita.

E não são só os salários. Esses £15 milhões incluem pessoas, sim, mas também gastos com IA, licenças de software, infraestrutura cloud e hardware. A fatura completa da engenharia. Ainda assim, a maioria das organizações não consegue detalhar nenhuma parte dela.

A minha experiência cobre os dois mundos. Nas startups, tive de projetar custos para investidores que querem perceber a economia unitária antes da Série A. Em ambientes empresariais, tive de explicar a diretores financeiros porque é que um projeto de seis meses passou a doze. As desculpas mudam, mas o problema de fundo não: falta-nos a infraestrutura básica para medir quanto custa realmente o trabalho de engenharia.

O problema não é novo, mas está a piorar

Isto é o que ouço a quase todos os líderes de tecnologia com quem falo:

“Acabamos por agrupar os custos de forma centralizada porque não conseguimos fechar o ciclo dentro do mês.”

Tradução: não sabemos o que gastamos em quê, por isso atiramos tudo para um balde genérico e chamamos-lhe “Equipa de Plataforma T3”. As finanças detestam. A administração questiona. Mas que outra coisa se pode fazer?

“Se cortarmos 20% das pessoas ou mudarmos equipas de sítio, quero ver o impacto de imediato.”

Mas não consegues. Porque a tua “ferramenta de planeamento” é uma folha de cálculo com 47 separadores que se parte se apagares uma linha. Quando acabas de modelar o cenário, a administração já decidiu com base no instinto.

“Gastamos £20 milhões em pessoas e preciso de mostrar que o dinheiro está bem gasto.”

Este tira o sono aos CTO. Sabes que estás a gastar bem. Sabes que as tuas equipas são talentosas. Mas não consegues prová-lo com dados, porque os dados não existem.

“Temos de replanear de poucos em poucos meses, quando as prioridades ou as pessoas mudam.”

E cada replaneamento custa-te três dias de reuniões, mais uma ronda de folhas de cálculo e o mesmo processo doloroso do trimestre anterior.

Porque é que o planeamento morre no momento em que o entregas

A maioria das organizações de engenharia faz planeamento trimestral. Passas 4-6 semanas a construir o plano do trimestre seguinte. À sétima semana, alguém sai. À nona, uma “prioridade estratégica” aparece do nada. À décima segunda, o teu plano original é ficção histórica.

É assim que o tempo da liderança de engenharia se reparte na realidade:

Reuniões (planeamento, alocação, revisões): 17,9 horas por semana, mais 7 horas do que os contribuidores individuais
Tempo fragmentado: 7,1 horas por semana, o que causa uma penalização de 40% na produtividade
Tempo de concentração: 10,4 horas por semana, das quais só 2,6 horas sem interrupções

Essas 17,9 horas de reuniões por semana? Uma parte considerável tem a ver com planeamento: arranques de planeamento trimestral que se arrastam por 4-6 semanas, revisões a meio do trimestre, discussões de alocação de recursos, justificações de orçamento. Quando fazes as contas, os líderes de engenharia gastam cerca de um terço de cada trimestre a planear o seguinte. Estás permanentemente seis semanas atrasado em relação à realidade, porque quando acabas de planear o mundo já mudou.

E o que estás a planear? Segundo a investigação da McKinsey, as equipas de engenharia passam 40-60% do tempo em manutenção e operações em vez de novas capacidades¹. Mas consegues dizer-me quais são esses 40-60%? Consegues mostrar-me que engenheiros estão em que projetos, e se esses projetos são CapEx ou OpEx?

Claro que não. Porque acompanhar isso exige atualizar uma folha de cálculo todas as semanas, e todos sabemos que isso nunca acontece.

O ponto cego entre CapEx e OpEx

Aqui é que começa a doer. O teu diretor financeiro precisa de saber se o trabalho de engenharia está a criar capacidades novas (CapEx) ou a manter as existentes (OpEx). Isto não é preciosismo contabilístico, porque muda por completo a forma como o trabalho é financiado e medido.

A McKinsey concluiu que, em algumas organizações, os programadores gastam mais de 50 por cento do tempo só a lidar com dívida técnica ². É a diferença entre uma organização de engenharia estratégica e uma equipa que passa a vida a apagar fogos.

Em contraste, as empresas do quartil superior (segundo o Developer Velocity Index) gastam 33 por cento menos tempo em trabalho manual e indiferenciado, o que as liberta para inovar ³.

Mas o pior é isto: o problema é quase universal. Um inquérito de 2023 concluiu que 91% dos líderes de TI identificam a dívida técnica como o maior obstáculo à inovação ⁴. E, no entanto, muitas empresas só “reservam 15 a 20 por cento do orçamento de TI para tratar da dívida técnica”, uma verba que a McKinsey considera muitas vezes insuficiente ².

Consegues mostrar à tua administração em que balde cai cada engenheiro? Consegues demonstrar que estás a passar de 50% de peso da dívida técnica para 30%? Ou estás só a esperar que ninguém pergunte?

A pressão de panela de pressão da private equity

Eis porque é que isto importa mais do que nunca: as aquisições alavancadas de private equity recuperaram para $602 mil milhões em 2024, um aumento de 37% face ao ano anterior ⁵. O setor tecnológico foi o principal motor, com 33% de todas as aquisições por valor a nível global ⁵.

Mas o jogo mudou. Vê como as firmas de private equity criam valor ao longo do tempo:

A excelência operacional passou de 18% para 47% da criação de valor. A engenharia financeira, ou seja, alavancagem e expansão de múltiplos, caiu de 51% para 25%.

O que significa isto para ti? Se diriges a engenharia numa empresa detida por private equity, tens 90 dias para mostrar como gastas o dinheiro e 12-24 meses para mostrar melhorias de eficiência com significado.

“Vamos contratar mais engenheiros” não é um plano. “Vamos alocar 8,5 FTE a estes três projetos, com estes retornos esperados” é um plano.

E adivinha o que pedem os operating partners das firmas de private equity?

O custo real por projeto (não estimativas, não palpites)
A repartição entre OpEx e CapEx em toda a organização de engenharia
Taxas de utilização de recursos
Custos de desenvolvimento de funcionalidades, com números reais
Um roteiro de expansão de margem com os fatores de eficiência da engenharia

A maioria dos líderes de tecnologia não consegue responder a nada disto.

O imposto do erro na folha de cálculo

Isto devia assustar-te: revisões académicas, incluindo uma análise recente de 35 anos, concluem de forma consistente que 88-94% das folhas de cálculo usadas em decisões críticas de negócio contêm erros ⁶. Não é gralha. Quase todas as folhas de cálculo que sustentam o planeamento dos teus custos de engenharia têm erros.

E, mesmo assim, a PwC refere que 80% das organizações ainda dependem de folhas de cálculo para o planeamento e a análise financeira (FP&A) ⁷.

Isto não é um problema técnico. É uma crise organizacional. Quando o teu diretor financeiro não confia nos teus números por estarem feitos em Excel, perdes credibilidade. Quando pede uma análise de cenários e precisas de três dias para copiar separadores, perdes influência.

Este desalinhamento é endémico. A Workday descobriu que só 30% dos diretores financeiros dizem estar muito alinhados com os seus diretores de sistemas de informação quanto ao roteiro digital e tecnológico das empresas ⁸. Como é que se alinha quando se fala línguas diferentes? As finanças falam de centros de custo e previsões trimestrais. A engenharia fala de story points e velocidade de sprint.

O que nos falta: uma unidade mínima viável

O problema não é precisarmos de melhores diagramas de Gantt. É não termos uma unidade mínima viável para medir o trabalho de engenharia.

As finanças têm uma hierarquia clara:

Linhas de custo → Centros de custo → Departamentos → Gasto total

A indústria transformadora tem:

Componentes → Produtos → Linhas de produção → Produção

E o software?

Story points (sem significado fora da tua equipa)
Funcionalidades (demasiado granulares)
Produtos (demasiado amplos)
“Investimento em plataforma” (pode querer dizer qualquer coisa)

As startups são particularmente cegas. Pergunta a qualquer fundador quanto custou construir o novo fluxo de checkout, não em story points, mas em dinheiro gasto em salários, custos gerais e custo de oportunidade, e vais receber um encolher de ombros.

É isto que estamos a resolver na flowstate. Comecei a chamar a esta disciplina Workforce Engineering, ou seja, desenhar de forma deliberada como uma organização aplica o seu trabalho para produzir resultados. Mais sobre isto em breve.

O método flowstate: Workforce Engineering na prática

Não estamos a construir mais uma ferramenta de gestão de projetos. Estamos a construir um enquadramento para a forma como as organizações de engenharia devem planear, acompanhar e medir o trabalho.

Pensa nisto assim:

O Agile foi para a metodologia de desenvolvimento de software
O Linear Method foi para o acompanhamento de tarefas e o fluxo de produto
O método flowstate é para a economia da engenharia e a visibilidade dos custos

O princípio central: o investimento em engenharia deve estruturar-se em apostas, não em backlogs.

Projetos como Apostas Mínimas Viáveis

Aqui temos opinião. No método flowstate, um projeto é:

No mínimo 1,0 FTE da capacidade mensal de uma equipa
No máximo 4 projetos em simultâneo por equipa e por trimestre
Pertencente a uma só equipa, sempre que possível
Alinhado com um centro de custo, para as finanças o poderem acompanhar
Ajustado às competências, para garantir que as equipas têm as capacidades certas

Porquê um mínimo de 1,0 FTE? Porque tudo o que seja menor não é uma aposta, é uma tarefa disfarçada de estratégia. Se não estás disposto a dedicar pelo menos uma pessoa-mês a uma coisa, não estás a levá-la a sério.

Porquê um máximo de 4 por trimestre? Porque o foco é um recurso escasso. Uma equipa que tenta fazer mais de quatro coisas relevantes em simultâneo não está a fazer bem nenhuma.

Esta estrutura dá-te:

Visibilidade real dos custos: sabes quanto custou “reconstruir o checkout” porque vês os projetos que o compõem e a respetiva alocação de FTE
Planeamento de cenários que funciona: mudaste uma equipa de sítio? Vês logo que projetos perdem capacidade
Acompanhamento de ROI a sério: consegues medir se a aposta compensou, porque sabes o que apostaste
Equilíbrio de competências: ajustas os requisitos do projeto às capacidades da equipa, não só ao número de pessoas, mas às competências reais

As pessoas são mais do que FTE

Aqui é que a maioria das ferramentas de planeamento de engenharia falha: tratam toda a gente como recursos intermutáveis. A flowstate não.

Acompanhamos:

A função (Frontend Engineer, Backend Engineer, DevOps, etc.)
O nível (Júnior, Intermédio, Sénior, Staff, Principal)
As competências (React, Python, AWS, PostgreSQL, etc.)

Isto quer dizer que, ao planear um projeto novo, podes perguntar: “Temos as competências certas disponíveis?” E não apenas: “Temos capacidade?”

Podes ver que a tua equipa tem 4,0 FTE disponíveis, mas só 1,5 FTE com as competências de React necessárias para o trabalho de frontend. Isso muda o teu planeamento. Talvez precises de contratar de outra forma. Talvez precises de ajustar o âmbito do projeto. Talvez precises de formar alguém.

Mas pelo menos ficas a saber. E isso é melhor do que descobrir a falta de competências seis semanas depois de o projeto começar.

As iniciativas decompõem-se para baixo, não para cima

O trabalho estratégico de grande dimensão, as iniciativas, não existe como bloco monolítico na flowstate. Decompõe-se em projetos, cada um pertencente a uma só equipa e com uma alocação de FTE clara.

Isto significa que, quando o diretor financeiro pergunta “Quanto custou a reconstrução do checkout?”, podes responder:

“Três projetos, num total de 12,5 FTE entre o T2 e o T3. Aproximadamente £340k em custos totais. Entregue dentro do prazo. Estamos a ver uma melhoria de 15% na conversão, o que se traduz em £2,1M de receita anual adicional.”

Isso não é palpite. São dados.

A Estrutura da Aposta

Cada projeto na flowstate corresponde a:

Valor de negócio: impacto na receita, poupança de custos ou posicionamento estratégico
Centro de custo: onde a despesa é contabilizada
Cadeia de valor: que parte do negócio beneficia
Alocação de FTE: o compromisso exato de recursos ao longo do tempo
Competências necessárias: que capacidades o projeto exige

Quando estruturas o trabalho assim, a conversa sobre CapEx e OpEx torna-se simples:

Tipo de projeto	Alocação típica	Impacto no negócio	Tratamento contabilístico
Novas capacidades	20-30% da capacidade	Crescimento da receita	CapEx
Modernização da plataforma	15-20%	Eficiência e escala	Misto
Redução da dívida técnica	15-20%	Velocidade a longo prazo	OpEx
Manutenção e suporte	20-30%	KTLO	OpEx
Experiências de inovação	10-15%	Valor de opção	CapEx

Alocação recomendada pelo método flowstate para uma organização de engenharia equilibrada

Não estás só a acompanhar tempo. Estás a acompanhar investimento e retorno.

Como isto se vê na prática

Estamos a trabalhar com empresas como a RAC no planeamento dos custos de engenharia. Assim muda a conversa:

Antes da flowstate:

“Precisamos de mais cinco engenheiros para a equipa de plataforma.”

Depois da flowstate:

“Vamos alocar 8,5 FTE a três projetos este trimestre:

Migração para a API v3 (4,0 FTE, £110k, com expectativa de desbloquear £2M em poupanças operacionais)

Infraestrutura de observabilidade (3,0 FTE, £82k, reduz o MTTR dos incidentes em 40%)

Reforço de segurança (1,5 FTE, £41k, requisito mínimo para o nível enterprise)

Custo total neste trimestre: £233k. Capacidade atual: totalmente alocada.

Se acrescentarmos cinco engenheiros (£150k por trimestre com todos os encargos), podemos assumir o projeto de modernização de pagamentos no T4. Projeta-se um impacto de £5M de receita anual, vindo da redução do abandono de carrinhos e de novos métodos de pagamento.

No entanto, precisamos de 2,0 FTE com experiência em processamento de pagamentos e de 1,5 FTE com conhecimento de conformidade PCI. O nosso pipeline de contratação ainda não cobre essas competências.”

Vês a diferença? Não estás a discutir número de pessoas. Estás a discutir investimento, retorno e lacunas de capacidade.

A interface de planeamento que quererias mesmo usar

As ferramentas de planeamento tradicionais foram feitas para gestores de projeto em 2005. Precisas de um curso de MS Project para as perceber.

A flowstate é diferente:

Arrastar e largar membros da equipa entre projetos
Cálculo instantâneo de custos à medida que alocas pessoas
Vistas de capacidade em tempo real que mostram o que é realmente possível
Correspondência de competências para ver se tens as capacidades certas
Planeamento de cenários que não exige copiar folhas de cálculo
Registo de auditoria automático de cada alteração e do motivo

Podes modelar “e se contratássemos três engenheiros seniores no próximo trimestre?” em cerca de 30 segundos. Comparar cenários lado a lado. Ver o impacto nas datas de entrega, nos custos e na capacidade.

Daqui a seis meses, quando alguém perguntar “Porque é que tirámos aqueles engenheiros da equipa de pagamentos?”, podes mostrar:

A alocação original e o plano do projeto
Quem a alterou e quando
O comentário que explica o motivo de negócio
Que impacto teve nos projetos seguintes
Se a aposta compensou

Planeamento colaborativo que funciona a sério

Aqui a coisa fica interessante. O planeamento de cenários na flowstate é colaborativo e em direto.

Pensa nisto como Git para o teu plano de engenharia.

Podes:

Criar tantos rascunhos de cenário quantos quiseres
Partilhar cenários com as partes interessadas para revisão
Receber feedback e iterar
Aprovar um cenário e ele passa a ser o novo plano
Os rascunhos de toda a gente atualizam-se automaticamente com as alterações aprovadas

É colaborativo. Atualiza-se em direto para quem estiver a ver. Podes deitar fora tantos rascunhos quantos quiseres. Mas há uma única fonte de verdade atualizada, e ela atualiza como por magia os rascunhos de cada pessoa com as alterações aprovadas, para trabalhares sempre sobre a versão mais recente.

Chega de “que versão do plano estamos a ver?”. Chega de andar a enviar folhas de cálculo por e-mail. Chega de descobrir que as finanças trabalharam com os números da semana passada.

Commit. Merge. Rebase. Mas mais mágico.

Replaneamento dinâmico sem dor

O mercado de software muda depressa. Há viragens estratégicas. Pessoas-chave saem. As prioridades mudam.

No método flowstate, replanear não significa recomeçar do zero. Significa:

Arrastar projetos para ajustar o calendário
Ver o impacto instantâneo nos custos e nas entregas
Comparar cenários antes de avançar
Documentar o porquê para consulta futura
Publicar o novo plano para as partes interessadas de forma automática

O que antes levava três dias leva agora trinta minutos.

E como tudo fica devidamente registado, podes responder a “Porque é que este projeto derrapou?” com dados reais:

“Realocámos 2,0 FTE para o incidente de segurança na semana 3”
“A migração da API demorou 6 semanas a mais por causa de problemas de qualidade de dados que descobrimos”
“Acrescentámos âmbito na semana 7 com base no feedback dos clientes, aqui está a alteração aprovada”

Não são palpites. São factos.

O método comanda o produto (e não o contrário)

Não estamos só a construir software. Estamos a codificar as melhores práticas de líderes de tecnologia de várias indústrias.

O método flowstate é a nossa resposta a:

Como deve o trabalho de engenharia ser estruturado para ter visibilidade?
Qual é a unidade mínima viável de planeamento que equilibra granularidade e custos de gestão?
Como se equilibra o foco (poucos projetos) com a flexibilidade (prioridades que mudam)?
Como se ligam as apostas de engenharia aos resultados financeiros que as finanças realmente valorizam?
Como se torna o planeamento de cenários rápido o suficiente para ser útil?
Como se acompanham competências e capacidades, e não apenas o número de pessoas?

Estamos a falar com:

CTO de empresas detidas por private equity sob escrutínio operacional
Scale-ups em crescimento rápido, com vários ciclos de planeamento por ano
Empresas de média dimensão que tentam controlar pela primeira vez a despesa em engenharia
Líderes de engenharia fartos do inferno das folhas de cálculo

Os problemas são consistentes. As soluções não deviam ser feitas à medida.

Para onde vamos a partir daqui

O escrutínio da despesa em engenharia nunca foi tão grande. As firmas de private equity exigem excelência operacional. As administrações pressionam por expansão de margem. Os diretores financeiros querem visibilidade em tempo real sobre para onde vai o dinheiro.

Ao mesmo tempo, a natureza do trabalho de engenharia está a mudar. As bases de produtividade estão a mexer. Os modelos históricos de custos de engenharia ficarão obsoletos em poucos meses.

As organizações que perceberem isto, que conseguirem planear de forma dinâmica, medir com rigor e adaptar-se depressa, vão ter uma vantagem enorme. As que continuarem a copiar separadores de folhas de cálculo vão ficar para trás.

Construímos a flowstate porque eu estava farto de não ter respostas. Farto de folhas de cálculo que se partem. Farto de planeamento de cenários que demora três dias. Farto de explicar a administrações porque não conseguimos dizer-lhes quanto custam as coisas.

O método flowstate é a nossa tentativa de resolver isto como deve ser. Não com mais um gestor de tarefas. Não com mais um substituto de folhas de cálculo. Mas com um enquadramento a sério para a forma como as organizações de engenharia devem planear e medir o trabalho em 2025 e depois.

Ajuda-nos a refinar isto

Ainda estamos no início. O software funciona, a RAC e outras empresas já o usam hoje, mas estamos a refinar o método através de conversas com líderes de tecnologia.

Se lidas com algum destes problemas, quero falar contigo:

Como fazes atualmente o planeamento de cenários? Quando o teu diretor financeiro pergunta “e se cortássemos 20%?”, qual é o teu processo? Folhas de cálculo? Instinto? Três dias de reuniões?

Como acompanhas o custo das funcionalidades? Consegues dizer-me agora mesmo quanto custou construir as tuas últimas três funcionalidades importantes? Não estimativas. Custos reais.

Como justificas os pedidos de contratação? Qual é a tua narrativa? “Precisamos de mais pessoas” ou “Precisamos de 3,0 FTE durante seis meses para construir [coisa], que vai gerar [valor]”?

Como lidas com replaneamentos frequentes? Quando as prioridades mudam todos os meses, como manténs os planos atualizados sem gastar semanas em administração?

Como ajustas as competências aos projetos? Consegues ver de relance se a capacidade de que dispões tem as competências certas para o trabalho que aí vem?

As melhores estruturas nascem da sabedoria coletiva, não da experiência individual. Estamos a construir a flowstate para resolver problemas que vivi, mas quero ter a certeza de que resolvemos também os problemas que tu vives.

Se isto te diz alguma coisa, entra em contacto: flowstate.inc

Referências

McKinsey & Company, How high performers optimize IT productivity for revenue growth: A leader’s guide ↩
McKinsey & Company, Breaking technical debt’s vicious cycle to modernize your business ↩ ↩²
McKinsey & Company, Developer Velocity: How software excellence fuels business performance ↩
OutSystems, Driving IT innovation forward: 3 imperatives for success ↩
Bain & Company, Global Private Equity Report 2025 ↩ ↩²
Panko, R. R. (2008). “What We Know About Spreadsheet Errors” & Poon, J., et al. (2024). “A review of spreadsheet errors: 35 years of research.” (Os artigos académicos de referência.) A ligação original para a publicação de Panko deixou de funcionar, mas deixo-a aqui para referência: panko.shidler.hawaii.edu/SSR/Mypapers/whatknow.htm ↩
PwC (2023). “FP&A Survey Results” ↩
Bruno J. Navarro, Workday (2022). “CFO-CIO Alignment Can Help Drive Digital Finance Transformation Goals, Global Research Finds.” ↩