Briefing de software: como descrever o que sua empresa precisa antes de pedir orçamento (e evitar surpresa no preço)
Rafael Oliveira · · 7 min de leitura
Você decide contratar um sistema, manda a mesma mensagem para três fornecedores e recebe de volta três propostas que não têm nada a ver uma com a outra. Uma custa R$ 25 mil, outra R$ 80 mil, a terceira nem tem preço, só "vamos marcar uma call". Aí vem a dúvida: os fornecedores são muito diferentes ou fui eu que expliquei mal?
Na maioria dos casos que chegam até a gente, foi a explicação. Quem já passou por um projeto travado sabe do que estou falando: quase sempre a raiz está em um briefing que cabia em três linhas de WhatsApp. O fornecedor preencheu as lacunas com suposição, o cliente assinou imaginando outra coisa, e a conta da diferença apareceu no meio do projeto, em forma de aditivo, atraso ou briga.
A boa notícia: escrever um briefing decente não exige conhecimento técnico. Exige responder um conjunto de perguntas sobre o seu próprio negócio. Este artigo é o roteiro.
Por que orçamentos variam tanto quando o briefing é vago
Quando você escreve "preciso de um sistema de gestão para minha operação", cada fornecedor lê uma coisa diferente. Um imagina três telas e um cadastro. Outro imagina controle de estoque, financeiro, emissão de nota e app para a equipe de campo. Os dois orçaram honestamente, mas orçaram projetos diferentes.
O barato que sai caro aqui é o seguinte: a proposta mais barata quase nunca é o fornecedor mais eficiente. É o fornecedor que entendeu menos escopo. Você fecha por R$ 25 mil, e cada funcionalidade que estava na sua cabeça mas não estava no papel vira uma cobrança extra. No fim, o projeto de R$ 25 mil custou R$ 70 mil e demorou o dobro, com a relação já desgastada.
Briefing não é burocracia. É a ferramenta que faz três propostas serem comparáveis entre si e protege você de pagar pela suposição errada.
O que um briefing de software precisa responder
Um bom briefing cabe em duas ou três páginas. Não precisa de diagrama, não precisa de termo técnico. Precisa responder oito perguntas.
1. Qual problema o sistema resolve, em uma frase
Não descreva o software, descreva a dor. "Hoje o fechamento do mês leva quatro dias porque três planilhas precisam ser conciliadas na mão" diz muito mais do que "quero um sistema financeiro". A dor bem descrita permite ao fornecedor sugerir soluções que você não tinha imaginado, inclusive soluções mais baratas.
2. Quem vai usar e quantas pessoas são
Um sistema para 5 usuários internos e um sistema para 5 mil clientes externos são projetos de porte completamente diferente, mesmo que as telas pareçam iguais. Liste os perfis: administrador, vendedor, cliente final, entregador. Cada perfil de usuário costuma significar um conjunto próprio de telas e permissões.
3. Como o processo funciona hoje, passo a passo
Descreva o fluxo atual, mesmo que ele seja feio. "O pedido chega por WhatsApp, a Ana digita na planilha, no fim do dia o Carlos confere e lança no financeiro." Esse parágrafo vale ouro para quem vai orçar, porque revela as integrações, as exceções e os gargalos reais. O sistema bom automatiza o processo que existe, não um processo idealizado.
4. O que é indispensável e o que é desejável
Separe em duas listas. A primeira: sem isso, o sistema não serve. A segunda: seria ótimo ter, mas pode vir depois. Essa separação sozinha pode cortar 30% a 50% do orçamento da primeira fase, porque permite ao fornecedor propor uma entrega em etapas em vez de um pacote fechado gigante.
5. Com quais sistemas ele precisa conversar
ERP, gateway de pagamento, WhatsApp, planilha do Google, sistema da transportadora, emissor de nota fiscal. Integrações são um dos itens que mais movem preço em software sob medida, e são o item que mais some dos briefings. Se você não listar, o fornecedor não orça, e a integração aparece depois como aditivo.
6. Volume e crescimento esperado
Quantos pedidos, cadastros ou transações por mês hoje? E daqui a dois anos, no cenário otimista? Não precisa acertar o número, precisa dar ordem de grandeza. Atender 200 pedidos por mês e atender 20 mil exigem decisões de arquitetura diferentes, e é bem mais barato tomar essa decisão no início.
7. Prazo e orçamento de referência
Muita gente esconde o orçamento achando que o fornecedor vai "gastar tudo". Na prática, esconder só gera propostas fora da sua realidade, para mais ou para menos. Dizer "tenho entre R$ 40 mil e R$ 60 mil para a primeira fase" permite ao fornecedor sério propor o melhor escopo possível dentro desse teto. Não existe resposta única, mas existe conta certa, e a conta só fecha quando os dois lados conhecem as restrições.
8. Quem decide e quem valida
Nomeie a pessoa da sua empresa que vai aprovar entregas e responder dúvidas. Projeto sem dono do lado do cliente atrasa tanto quanto projeto sem dono do lado do fornecedor. Se a resposta for "todo mundo opina", resolva isso antes de assinar qualquer contrato.
O que deixar fora do briefing
Tão importante quanto o que entra é o que fica de fora.
- Decisão de tecnologia. Não escreva "quero em Python" ou "tem que ser em tal framework" a menos que exista um motivo real, como integração com sistema existente ou time interno que vai dar manutenção. Amarrar tecnologia sem motivo elimina bons fornecedores e boas soluções.
- Desenho de telas. Referências visuais ajudam ("gosto de como o app X organiza isso"), mas telas desenhadas no PowerPoint costumam travar a conversa em detalhes de layout antes de o problema estar entendido.
- Lista de 80 funcionalidades. Se a lista de indispensáveis passou de 15 itens, ela virou lista de desejos. Volte à pergunta 1 e corte tudo que não ataca a dor principal.
Como usar o briefing para comparar propostas
Com o briefing pronto, mande o mesmo documento para todos os fornecedores. Aí a comparação muda de figura. Antes de assinar qualquer contrato, pergunta isso:
- A proposta responde ao meu briefing ponto a ponto, ou é um texto genérico que serviria para qualquer cliente?
- O fornecedor questionou algo do briefing? Quem orça sem fazer nenhuma pergunta provavelmente não leu com atenção ou vai supor demais.
- O escopo da proposta lista o que está incluído e o que está explicitamente fora?
- Existe previsão de custo de manutenção e hospedagem depois da entrega, ou o preço para no dia do lançamento?
- As entregas estão divididas em marcos que eu consigo validar, ou é um pacote fechado que só aparece no final?
Uma proposta que responde bem a essas cinco perguntas pode custar mais caro que as outras e ainda assim ser a mais barata no total do projeto. Diferença de preço entre propostas comparáveis é negociação. Diferença de preço entre propostas incomparáveis é loteria.
Um exemplo real de como isso muda a conversa
Na OCA, boa parte dos projetos que a gente constrói chega exatamente assim: uma operação que cresceu além da planilha e precisa de sistema. Foi o caso do sistema de gestão para imobiliárias que mantemos em produção: o briefing inicial descrevia o fluxo real de locação, quem usava, quais integrações existiam e qual era o gargalo. Com isso na mesa, a primeira fase foi desenhada para atacar o gargalo, não para reconstruir a operação inteira de uma vez. O cliente pagou por um sistema que entrou em produção e começou a se pagar, em vez de financiar seis meses de desenvolvimento às cegas.
Esse é o padrão que a gente vê se repetir: briefing claro na entrada, escopo honesto na proposta, entrega em fases. Nenhuma dessas três coisas depende de sorte.
Próximo passo: escreva o seu antes de pedir qualquer orçamento
Reserve uma hora, responda as oito perguntas acima em um documento simples e só então abra conversa com fornecedores. Você vai notar a diferença já na primeira resposta: as perguntas que voltarem serão melhores, e as propostas, comparáveis.
Se quiser, pode começar essa conversa com a gente. Mande o seu briefing, mesmo em rascunho, e a equipe da OCA devolve uma leitura honesta do escopo, incluindo o que dá para cortar da primeira fase.
