Ir para o conteúdo 
Resposta direta: o custo de pular o Discovery se calcula somando cinco categorias: retrabalho direto (horas refeitas × custo por hora), custo do atraso (meses × receita esperada), Dívida Técnica (capacidade de engenharia presa em correção), receita perdida por baixa adoção e churn, e suporte inflado por confusão de interface. Este artigo entrega a régua de cada uma.
Todo orçamento de projeto digital tem linha para design, desenvolvimento, infraestrutura e licenças. Nenhum tem linha para "refazer o que construímos errado". E é exatamente essa linha invisível que costuma ser a maior de todas.
O problema não é falta de honestidade. É falta de método. Ninguém sabe colocar número no que ainda não deu errado. Então a decisão de pular o Discovery, que parece uma economia de algumas semanas e algumas dezenas de milhares de reais, entra no orçamento como ganho. O custo real entra depois, diluído em sprints estouradas, features abandonadas e clientes que sumiram sem reclamar.
Este artigo não vai contar mais uma história de projeto que afundou. Já fizemos essa autópsia em o erro de R$ 1 milhão que começou com uma tela. Aqui o objetivo é outro: te ensinar a montar a conta. Cinco categorias de Custos Invisíveis, uma régua de estimativa para cada uma, um exemplo numérico plugado. No fim, você fecha o artigo sabendo calcular o número da sua operação.
Por que essa conta nunca aparece no orçamento
Três razões, todas estruturais:
- O custo é distribuído. Retrabalho aparece como "velocity baixa". Churn aparece como "problema comercial". Suporte inflado aparece como "custo de operação". Ninguém consolida.
- O custo é defasado. A decisão de pular o Discovery acontece no mês 1. A fatura chega do mês 6 em diante, quando já ninguém conecta efeito à causa.
- O contrafactual é invisível. Não existe relatório de "quanto teríamos economizado". Então o vácuo é preenchido com otimismo.
O Standish Group documenta há décadas, no CHAOS Report, que a maioria dos projetos de software estoura prazo e orçamento ou é cancelada antes de entregar valor, e que requisitos mal compreendidos estão consistentemente entre as causas principais. Não é azar. É padrão. E padrão se quantifica.
Vamos às cinco categorias.
Categoria 1: retrabalho direto
A mais óbvia e, ainda assim, a menos medida. Retrabalho de software é todo esforço gasto reconstruindo algo que já foi construído: fluxo redesenhado depois de pronto, feature refeita porque o usuário não entendeu, integração reescrita porque a premissa estava errada.
A régua:
Custo de retrabalho = custo mensal do time × % do esforço gasto refazendo × meses
O insumo que você precisa é um só: que fração das entregas do time foi refazer coisa que já existia. Pergunte ao Head de Engenharia. Se ele não souber, olhe o backlog: conte quantos itens dos últimos 3 meses têm as palavras "ajustar", "corrigir fluxo", "refazer", "v2 de".
Exemplo plugado: squad de 8 pessoas a um custo carregado de R$ 150.000/mês. Auditoria do backlog mostra 30% do esforço em retrabalho ao longo de 4 meses. Conta: 150.000 × 0,30 × 4 = R$ 180.000. Isso é mais do que custa a maioria dos Discoveries completos, e é só a primeira categoria.
Categoria 2: custo de oportunidade do atraso
Retrabalho não consome só dinheiro. Consome calendário. E calendário tem preço: cada mês que a feature não está no ar é um mês da receita que ela existia para gerar.
A régua:
Custo do atraso = receita mensal esperada da entrega × meses de atraso
Se você não tem projeção de receita para a entrega, esse é um problema anterior à conta: significa que o projeto foi aprovado sem business case. Use então a alternativa conservadora: o custo mensal do time parado naquele escopo, porque no mínimo esse capital ficou imobilizado sem retorno.
Exemplo plugado: um novo fluxo de checkout foi aprovado com projeção de R$ 100.000/mês em receita incremental. O retrabalho empurrou o go-live em 3 meses. Conta: 100.000 × 3 = R$ 300.000 que não se recuperam. Atraso não adia receita. Elimina receita.
Categoria 3: Dívida Técnica gerada
Construir sem entender gera atalhos. Atalho vira gambiarra, gambiarra vira arquitetura, e a arquitetura errada passa a cobrar juros: cada evolução futura fica mais cara e mais lenta. Estudos de mercado apontam que a Dívida Técnica chega a consumir até 40% do orçamento de TI. A pergunta é quanto do SEU orçamento ela consome.
A régua:
Custo da Dívida Técnica = orçamento anual de engenharia × (% da capacidade em correção e manutenção − % que o seu plano previa)
O delta entre o planejado e o real é a dívida cobrando juros. Se o seu roadmap previa 20% da capacidade em manutenção e a realidade é 40%, um quinto de todo o orçamento de engenharia está pagando decisões passadas em vez de construir futuro.
Exemplo plugado: engenharia de R$ 4 milhões/ano, plano previa 20% em manutenção, realidade mostra 40%. Conta: 4.000.000 × (0,40 − 0,20) = R$ 800.000/ano drenados. A anatomia completa desse dreno está em quanto custa a Dívida Técnica que ninguém contabiliza.
Categoria 4: receita perdida por adoção e churn
Esta é a categoria que o CFO mais sente e menos enxerga. Produto construído sem Discovery erra a jornada, e jornada errada não gera reclamação: gera abandono silencioso. 88% dos usuários não voltam depois de uma experiência ruim. Eles não abrem ticket. Somem.
A régua tem duas pontas:
Perda por adoção = usuários que entram × (ativação projetada − ativação real) × valor por usuário ativo
>
Perda por churn = clientes da base × pontos de churn acima da meta × ticket × meses de vida esperados
Exemplo plugado: SaaS com 500 clientes a R$ 300/mês. O produto roda com churn mensal 1 ponto acima da meta. Conta: 500 × 0,01 × 300 × 12 = R$ 18.000/ano por ponto de churn. Parece pouco? Multiplique pelos pontos reais do seu funil e some o desperdício de aquisição: cada usuário que a interface expulsa levou CAC junto, um vazamento que detalhamos em o ralo entre o marketing e a interface. E o mecanismo completo de como design ruim vira prejuízo está em o custo do design ruim no resultado financeiro.
Categoria 5: custo de suporte inflado
Quando a interface não responde, o usuário pergunta. Cada dúvida de uso é uma decisão de design que não foi tomada, cobrada em salário de atendente. Produto na direção de Fricção Zero atende sozinho. Produto construído no chute transfere o custo da confusão para a folha do suporte.
A régua:
Custo de suporte inflado = volume mensal de tickets × % causado por confusão de uso × custo por ticket × 12
O insumo sai de uma tarde de trabalho: classifique uma amostra de 100 tickets. Separe "problema real" de "não encontrei", "não entendi", "como faço para". A segunda pilha é design não resolvido.
Exemplo plugado: operação com 2.000 tickets/mês, amostragem mostra 30% de dúvida de uso, custo de R$ 15 por ticket. Conta: 2.000 × 0,30 × 15 × 12 = R$ 108.000/ano pagando para explicar por telefone o que a tela deveria explicar sozinha.
A conta consolidada
Somando os exemplos das cinco categorias:
| Categoria | Valor |
|---|---|
| Retrabalho direto | R$ 180.000 |
| Custo do atraso | R$ 300.000 |
| Dívida Técnica (anual) | R$ 800.000 |
| Churn acima da meta (anual, 1 ponto) | R$ 18.000 |
| Suporte inflado (anual) | R$ 108.000 |
| Total | R$ 1.406.000 |
Números ilustrativos, plugados nas réguas acima. O ponto não é o total: é a assimetria. Um Discovery estratégico custa uma fração disso e ataca as cinco categorias na raiz, antes de virarem fatura. É por isso que o ROI de UX chega a 100:1. Não é mágica de design. É Eficiência de Capital: cada real gasto entendendo o problema evita dezenas de reais reconstruindo a solução.
FAQ
Preciso de dados perfeitos para fazer essa conta?
Não. Precisa de ordem de grandeza. Estimativa conservadora com insumos do seu próprio backlog, financeiro e suporte já muda a qualidade da decisão. A conta imperfeita feita hoje vale mais que a conta perfeita que nunca sai.
Discovery não atrasa o projeto?
Discovery desloca semanas para o início para não perder meses no fim. Compare o custo das semanas de imersão com a categoria 2 da sua conta. Se o atraso evitado supera o tempo investido, e quase sempre supera, o Discovery acelera o projeto no total.
E se o time já conhece bem o produto e o usuário?
Então o Discovery confirma rápido e barato o que o time acha que sabe. O cenário caro é o outro: o time ter certeza e estar errado. A conta deste artigo mede exatamente o preço dessa certeza.
Essa conta serve para projeto que já está em andamento?
Serve, e é onde ela mais dói. Rode as cinco categorias sobre os últimos 6 meses. Se o número consolidado for relevante, o projeto está pagando em silêncio por um entendimento que nunca foi construído. Ainda dá tempo de parar a sangria.
Conclusão: monte a sua conta em 5 passos
- Retrabalho: peça ao Head de Engenharia a fração do esforço dos últimos 3 meses gasta refazendo entregas. Multiplique pelo custo mensal do time.
- Atraso: liste as entregas que escorregaram e a receita mensal que cada uma deveria gerar. Multiplique pelos meses perdidos.
- Dívida Técnica: compare o % de capacidade em manutenção corretiva com o que o plano previa. Aplique o delta sobre o orçamento anual de engenharia.
- Adoção e churn: meça ativação real contra a projetada e pontos de churn acima da meta. Converta em receita/ano.
- Suporte: classifique 100 tickets. O % de "não entendi" vezes o volume anual vezes o custo por ticket é a sua última linha.
Some as cinco. Esse é o custo de pular o Discovery na sua operação, com os seus números, não com os de um artigo. Um Ativo Digital construído sobre entendimento não paga essa conta. Um produto construído sobre suposição paga todas as cinco, todo ano.
Se o total te incomodou, o caminho não é construir mais rápido. É entender antes de construir. É exatamente isso que o Discovery estratégico da UX Agency faz: reduzir risco antes que ele vire orçamento queimado. Fale com a gente e traga a sua conta. A conversa começa por ela.
