Briefing de software sob medida: como escrever o documento que evita retrabalho e surpresa no preço (com o modelo que a OCA usa)
Rafael Oliveira · · 8 min de leitura
A conversa costuma começar assim: “Preciso de um sistema para controlar os pedidos, o estoque e as entregas. Quanto custa?” Vem uma proposta com um número redondo, o projeto começa e, na terceira semana, aparece a pergunta que ninguém fez antes: “e quando o pedido é entregue pela metade?”. Aquele “detalhe” muda o modelo de dados, três telas e a integração com o financeiro. O orçamento sobe, o prazo estica e os dois lados saem com a sensação de que foram enganados. Quem já passou por um projeto travado sabe do que estou falando.
Na maioria dos casos, o problema não estava no código nem no fornecedor. Estava no documento que deveria ter existido antes da proposta: o briefing.
Por que o briefing decide o preço antes de qualquer linha de código
Uma proposta de software sob medida é uma lista de premissas com um número no final. Tudo o que você não escreveu, o desenvolvedor preencheu com uma suposição. Se ele for otimista, subestima e o projeto estoura. Se for cauteloso, coloca uma gordura de 30% a 50% para se proteger do que não sabe. Nos dois cenários, você paga pela ambiguidade.
A conta é simples. Cada premissa errada descoberta em produção vira um change request. Em sistemas web de porte médio, um ajuste desse tipo custa entre R$ 3 mil e R$ 15 mil, dependendo de quantas partes do sistema ele toca. Cinco premissas erradas em um projeto de R$ 80 mil representam um estouro de 20% a 60%, sem contar o atraso.
O briefing não elimina a incerteza. Ele transfere a descoberta do meio do projeto, onde ela é cara, para antes da assinatura, onde ela é quase de graça.
O erro mais comum: descrever a solução em vez do problema
O briefing típico que chega para a gente é uma lista de telas e funcionalidades: “tela de login, cadastro de clientes, dashboard com gráficos, relatório em PDF, app para o vendedor”. Parece completo. Não é.
Ele descreve o que a pessoa imagina que o sistema terá, não o que a operação precisa que ele resolva. Imaginar telas é trabalho da fase de design, não do briefing. Quando o cliente já vem com a solução pronta, dois problemas aparecem:
- O fornecedor orça exatamente aquilo, mesmo quando metade não é necessária na primeira versão.
- O que realmente importa (o fluxo de trabalho, as exceções, quem aprova o quê) fica de fora, porque não parece “funcionalidade”.
A regra que uso: o briefing descreve a operação de hoje, a dor e o resultado esperado. A solução é a resposta do fornecedor, e é justamente ela que você vai comparar entre propostas.
O que um briefing de software sob medida precisa ter
O modelo abaixo é o que pedimos para todo cliente antes de estimar. Cabe em duas a quatro páginas. Mais que isso costuma ser especificação, não briefing.
1. Contexto do negócio
O que a empresa faz, quantas pessoas trabalham na operação afetada e qual o volume que passa por ela: pedidos por dia, contratos por mês, atendimentos por semana. Volume muda arquitetura e preço. Um sistema para 200 pedidos por dia e outro para 20 mil não são o mesmo projeto.
2. O problema em uma frase, com sintoma
Não “quero um sistema de gestão”. Sim: “o fechamento do mês leva quatro dias porque três planilhas precisam ser conciliadas na mão e só uma pessoa sabe fazer isso”. O sintoma mostra onde está a dor real e ajuda o fornecedor a priorizar.
3. Como o processo funciona hoje
Passo a passo, do início ao fim, incluindo as gambiarras. Quem faz o quê, em que ferramenta, e o que acontece quando algo sai do normal. As exceções são a parte mais importante desta seção: “pedido cancelado depois de faturado”, “cliente que paga em duas contas diferentes”, “contrato que muda de titular no meio”. Cada exceção não escrita é um change request futuro.
4. Quem vai usar
Perfis, quantidade e contexto. Vendedor na rua pelo celular é um requisito diferente de analista no escritório com dois monitores. Se existe um usuário externo (cliente final, fornecedor, parceiro), diga. Acesso externo puxa autenticação, permissões e LGPD, e isso pesa no orçamento.
5. Integrações obrigatórias
Liste todo sistema que já existe e precisa conversar com o novo: ERP, emissor de nota fiscal, gateway de pagamento, a planilha que o financeiro não vai abandonar. Para cada um, informe se tem API documentada ou se ninguém sabe. Integração é o item que mais faz orçamento variar. Uma integração com API pública e boa documentação costuma custar entre R$ 4 mil e R$ 12 mil. Uma com sistema legado sem API pode passar de R$ 30 mil ou se mostrar inviável.
6. O que é obrigatório na primeira versão e o que fica para depois
Duas listas separadas. A primeira, curta. Se tudo é prioridade, nada é, e o fornecedor vai orçar tudo. Um bom teste: “se essa funcionalidade não existir no dia do lançamento, a operação para?”. Se a resposta for não, vai para a segunda lista.
7. Restrições
Prazo com motivo (evento, fim de contrato com o fornecedor atual, alta temporada), teto de investimento, exigências regulatórias, dados sensíveis, necessidade de funcionar sem internet. Dizer o orçamento disponível não te enfraquece na negociação. Ele permite que o fornecedor proponha um escopo que cabe no valor, em vez de um que não cabe.
8. O que NÃO deve ser construído
Essa seção quase nunca aparece e é a que mais economiza. “Não precisa de app nas lojas, web responsivo resolve.” “Não vamos substituir o ERP, só integrar.” “Relatórios continuam no Power BI.” Cada frase dessas corta semanas do cronograma.
9. Como você vai saber que deu certo
Uma ou duas métricas. “Fechamento do mês em um dia em vez de quatro.” “Zero pedido perdido entre venda e expedição.” Isso alinha o fornecedor com o resultado, não com a lista de telas, e vira o critério de aceite no fim do projeto.
O que deixar fora do briefing
- Escolha de tecnologia. A não ser que sua empresa tenha um time interno que vai manter o sistema em uma stack específica, deixe a decisão para quem vai construir. Exigir uma linguagem por ter lido sobre ela costuma encarecer sem motivo.
- Telas desenhadas em detalhe. Rascunhos ajudam a comunicar o fluxo. Protótipo pixel a pixel antes de entender o problema é retrabalho garantido.
- “Igual ao sistema X”. Referências são úteis, mas diga o que do sistema X você quer. O fornecedor não sabe se é o fluxo de checkout ou a cor do botão.
- Funcionalidades para o futuro distante. “Um dia vamos vender para o exterior.” Anote em uma seção de visão, separada, para o fornecedor não orçar multimoeda hoje.
Como o briefing muda o orçamento na prática
Não existe resposta única, mas existe conta certa. Com um briefing de meia página, uma software house séria vai responder com uma de duas coisas: uma fase de descoberta paga (normalmente entre R$ 5 mil e R$ 20 mil) para levantar o que falta, ou uma proposta com margem de segurança alta e uma lista longa de premissas. Nenhuma das duas é má-fé. É a única forma responsável de precificar o que não está claro.
Com um briefing completo, a fase de descoberta encolhe ou desaparece, a margem de contingência cai para algo entre 10% e 15%, e as propostas passam a ser comparáveis entre si, porque todos os fornecedores estão orçando o mesmo problema. Para um sistema web de porte médio, que em 2026 costuma ficar entre R$ 60 mil e R$ 200 mil, essa diferença de contingência sozinha representa de R$ 15 mil a R$ 60 mil.
O barato que sai caro aqui é o seguinte: economizar as oito horas de escrever o briefing para gastar oitenta em reuniões de alinhamento e change requests.
Checklist antes de pedir o orçamento
Antes de assinar qualquer contrato, e antes até de pedir a proposta, pergunta isso para você mesmo:
- Uma pessoa de fora da minha empresa consegue entender como o processo funciona hoje só lendo o documento?
- Listei as exceções, não só o caminho feliz?
- A lista de “obrigatório na primeira versão” cabe em dez itens?
- Todos os sistemas que precisam se integrar estão nomeados, com o status da API?
- Existe uma seção do que não deve ser construído?
- Escrevi o prazo e o motivo do prazo?
- Defini como vou medir se deu certo?
- Quem opera o processo no dia a dia leu e concordou? Não só o gestor.
Se três ou mais respostas forem “não”, o documento ainda não está pronto para virar orçamento.
Como a gente usa o briefing na OCA
Esse é o tipo de projeto que a gente constrói, e o briefing é a primeira coisa que pedimos. No sistema de gestão para imobiliárias que mantemos em produção, o trabalho começou mapeando a operação de locação de ponta a ponta: captação do imóvel, contrato, repasse ao proprietário, cobrança e inadimplência. As exceções, como contrato com fiador, reajuste fora do índice e repasse parcial, apareceram no briefing, não em produção. O resultado foi um escopo de primeira versão enxuto e um orçamento que se sustentou até a entrega.
Fazemos isso porque também somos clientes de nós mesmos. O Revo App, nossa plataforma de eventos com mais de 40 mil usuários, passa pelo mesmo processo a cada funcionalidade nova. Se a gente não consegue escrever o problema em uma página, não começamos a construir. Outros projetos que seguiram esse caminho estão em nosso portfólio.
Próximo passo
Pegue as nove seções acima e escreva o seu briefing. Não precisa ficar bonito. Precisa ser honesto sobre como a operação funciona hoje e sobre o que você realmente precisa na primeira versão. Peça para quem opera o processo revisar.
Quando estiver pronto, manda para a gente. A leitura do briefing e a conversa inicial não custam nada, e você sai dela sabendo se o projeto faz sentido como software sob medida ou se um SaaS pronto resolve por uma fração do valor. As duas respostas são boas, desde que venham antes da assinatura.
