Índice
Início
/
Blog
/
20 desenvolvedores, cobrança por hora e nenhuma ideia de quanto o projeto realmente rendeu
248
5 min
02.07.2026
20 desenvolvedores, cobrança por hora e nenhuma ideia de quanto o projeto realmente rendeu
Oleksiy Bazyura
Especialista financeiro na Finmap
"Eu sabia o valor-hora de cada desenvolvedor. Sabia a taxa do contrato com o cliente. Subtraía um do outro e achava que conhecia a margem. Aí montei um DRE por projeto e percebi que eu vinha tocando a empresa em cima de uma ilusão havia quatro anos."
A fundadora de uma empresa de serviços e outstaffing de TI — 20 desenvolvedores, ₴36 milhões de receita anual, sete clientes ativos — contou o exercício que mudou a forma como ela precificava projetos e contratava pessoas.
Durante quatro anos, ela tocou o negócio do jeito que quase todo mundo no setor toca: fazendo conta de valor-hora. Cada desenvolvedor tinha um custo por hora (₴550/hora, em média). Cada cliente tinha uma taxa contratual (₴950/hora, média entre os clientes). Uma subtração simples mostrava ₴400/hora de margem bruta por desenvolvedor, cerca de 42% de margem. Projetando isso para o time inteiro: uma empresa confortável, lucrativa, em crescimento.
Então ela fez o exercício. Pegou um projeto. Não o número do tipo "faturamos ₴X por hora para o cliente". O DRE real do projeto. Receita do cliente no mês. Todos os custos diretamente atribuíveis àquele projeto. Todos os custos indiretamente atribuíveis. O que sobrava no fim.
Margem do projeto no seu principal cliente, considerando os 12 meses anteriores: 14%. Não 42%.
Vinte e oito pontos de margem tinham sumido em um conjunto de custos que a conta de valor-hora simplesmente não enxergava.
O que a conta de valor-hora realmente esconde
A conta de valor-hora parte do pressuposto de que um desenvolvedor está 100% alocado no projeto, é 100% produtivo durante esse tempo e que o projeto consome apenas o trabalho dele. Nenhuma dessas premissas é verdadeira em uma empresa de serviços de verdade.
Férias e licenças médicas (−4 pontos). Desenvolvedores assalariados recebem férias e afastamentos remunerados. A taxa contratual só é faturada quando eles trabalham. Essa diferença fica invisível até você colocar na conta.
Reuniões internas, processos e entrevistas de contratação (−6 pontos). Dailies, retrospectivas, planejamentos, entrevistas com candidatos, alinhamentos internos. Tudo pago, nada faturável. Em média, 4 a 6 horas por desenvolvedor por semana.
Ferramentas e licenças (−2 pontos). Licenças de IDE, infraestrutura em nuvem para ambientes internos, ferramentas de gestão de projetos, monitoramento, plataformas de comunicação. Pequeno individualmente; grande no acumulado.
Recrutamento e estrutura de gestão (−7 pontos). RH, delivery managers, gerentes de projeto, o tempo da própria fundadora. Todo mundo recebe. Quase nunca é faturável. Esse era o maior vazamento isolado.
Descontos e horas extras não faturadas (−4 pontos). O cliente pressionou a taxa na renovação e conseguiu 8% de desconto. Trabalhos emergenciais feitos no fim de semana nem sempre eram registrados. Estouro em partes de escopo fechado era absorvido pela empresa.
Vinte e oito pontos, seis categorias, nenhuma delas na conta de valor-hora.
A reconstrução — modelo de DRE por projeto
A fundadora montou o DRE por projeto em um fim de semana. Ele se tornou o documento mais importante da empresa. O modelo vale para qualquer negócio de serviços.
Dois — Custo direto dos desenvolvedores, com tudo incluído. Salário + impostos + benefícios + amortização de equipamentos + tempo remunerado sem trabalho, dividido pelas horas de utilização (não pelas horas de calendário). Se um desenvolvedor é faturável 65% do tempo, o custo-hora total dele é salário/(horas × 0,65).
Três — Alocação de custos de gestão de projeto, delivery e recrutamento. Uma divisão aproximada por tamanho de projeto ou por receita. Não precisa ser perfeita. Precisa ser consistente.
Quatro — Ferramentas e licenças atribuíveis ao projeto.
Cinco — Alocação de banco. Custo total de banco no ano, dividido entre os projetos ativos.
Seis — Alocação de reuniões internas e processos. Percentual de horas pagas dedicado a trabalho não relacionado a projetos × custo alocado.
Resultado — Margem real do projeto. No principal cliente dela: 14%. Em dois clientes menores: 21% e 8%. Em um cliente que ela achava ser o melhor: 3%.
O que ela fez com a verdade
O cliente de 3% teve uma conversa sobre aumento de taxa. Deu certo; a margem subiu para 12%. O cliente de 8% tinha problemas de disciplina de escopo (entregas além do combinado) que podiam ser corrigidos; a margem foi para 15%. O custo de recrutamento foi renegociado para um retainer mensal fixo, em vez de taxas por contratação. As reuniões internas passaram por auditoria — três reuniões recorrentes semanais foram eliminadas. A utilização de dois desenvolvedores sêniores saiu de 58% para 72% ao tirá-los de trabalhos internos com muito banco e realocá-los em projetos de clientes.
O modelo — o que acompanhar
Seis números, todo mês, por projeto:
- Horas realmente faturáveis (não horas contratadas; horas reais)
- Custo total dos desenvolvedores por projeto
- Overhead de gestão alocado (tempo de PM/DM/recrutador/fundador como % do mês)
- Alocação de banco (custo de banco do mês × participação do projeto na receita)
- Margem real do projeto (receita − tudo acima)
- Utilização por desenvolvedor, acompanhada separadamente da margem
Seis números, um dashboard, revisão mensal com o líder de delivery. Duas horas por mês para impedir que a ficção volte.
📌 Quer saber se seus projetos são realmente tão lucrativos quanto a sua conta de valor-hora sugere? Envie três meses de dados de faturamento e a abertura de custos do time — nós montamos o waterfall de margem real por projeto e mostramos tudo em 15 minutos. Solicite seu diagnóstico gratuito da Finmap →
Leia também
- Contabilidade gerencial para uma agência de TI: os três números que mostram tudo
- Como a Finmap ajuda empresas de TI a organizar a gestão financeira
Base do tema: Unit economics para pequenas empresas: você realmente ganha dinheiro em cada venda?
Compartilhe conteúdo valioso — torne-se uma fonte de insights
Perguntas frequentes
Utilização não é só um KPI, em vez de um fator de margem?
É as duas coisas. Uma utilização mais alta aumenta diretamente a margem completa, porque o custo do desenvolvedor é diluído em mais horas faturáveis. Uma utilização baixa corrói a margem em silêncio.
E se um desenvolvedor trabalhar em 3 projetos no mesmo mês?
Aloque o tempo dele pelas horas reais trabalhadas em cada projeto. O custo total dele é dividido na mesma proporção. É por isso que controlar horas, mesmo de forma simples, faz diferença.
Devemos acompanhar a ociosidade por desenvolvedor ou de forma agrupada?
Para empresas menores, a visão agrupada funciona bem (menos de 30 desenvolvedores). Acima disso, acompanhar por desenvolvedor é mais claro, porque a ociosidade de um sênior custa muito mais do que a de um júnior.
Projetos de preço fechado: como isso se aplica?
A conta é a mesma, mas a receita é a parcela mensal reconhecida (valor do contrato × % concluído). Assim, projetos que dão prejuízo aparecem muito antes do que na contabilidade por caixa.
O cliente não aceita aumento de valor. E agora?
Teste a alternativa: o projeto é lucrativo o suficiente para continuar com os valores atuais? Se a margem for negativa ou ficar abaixo de 10%, avalie reduzir escopo, ganhar eficiência na entrega ou fazer uma transição bem conduzida.
Qual é a diferença disso para o que meu contador entrega?
Seu contador entrega o DRE no nível da empresa. Aqui é um DRE por projeto, que exige alocações para as quais o contador normalmente não tem os dados operacionais necessários.
Ficou com alguma dúvida?
Estamos prontos para responder.
Finmap support
