Briefing de software: como escrever um documento que evita retrabalho e surpresa no orçamento

A cena se repete: a empresa pede orçamento para três fornecedores e recebe três propostas que não se comparam. Uma diz R$ 40 mil, outra R$ 120 mil, a terceira pede "mais detalhes para estimar". O projeto começa com a proposta do meio e, três meses depois, aparece a primeira frase que ninguém quer ouvir: "isso não estava no escopo". Aí vem o aditivo de contrato, o prazo estoura e a relação azeda antes do sistema entrar no ar.

Quem já passou por um projeto travado sabe do que estou falando. E a origem do problema quase nunca está no fornecedor nem no cliente. Está no documento que deveria existir antes de qualquer proposta: o briefing.

Por que orçamentos de software variam tanto

Quando o pedido chega como "preciso de um sistema para gerenciar minha operação", cada fornecedor preenche as lacunas de um jeito. Um imagina três telas e um cadastro. Outro imagina integração com ERP, controle de permissões e app mobile. Os dois orçaram coisas diferentes com o mesmo nome.

O barato que sai caro aqui é o seguinte: a proposta mais barata geralmente é a que imaginou menos. Não porque o fornecedor quis enganar, mas porque ele estimou o que conseguiu enxergar. Tudo o que não estava escrito vira discussão depois, e discussão em projeto rodando custa muito mais do que uma linha a mais no briefing.

Na prática, cada ambiguidade no briefing vira uma de três coisas: um aditivo de preço, um atraso ou uma funcionalidade entregue diferente do que você esperava. Não existe quarta opção.

O que um briefing de software precisa responder

Briefing não é documento técnico. Você não precisa saber o que é API, banco de dados ou arquitetura. Precisa descrever o problema com precisão suficiente para que duas pessoas diferentes leiam e imaginem o mesmo sistema. Seis blocos resolvem isso.

1. O problema, não a solução

Comece pelo que dói hoje. "O fechamento do mês depende de uma planilha que só uma pessoa sabe mexer e leva quatro dias" diz mais do que "quero um dashboard financeiro". Quando você descreve o problema, o fornecedor pode propor a solução mais barata que resolve. Quando você descreve a solução, ele orça exatamente o que você pediu, mesmo que exista caminho melhor.

2. Quem usa e quanto usa

Um sistema para 5 usuários internos e um sistema para 5 mil clientes têm custos muito diferentes, mesmo com as mesmas telas. Escreva: quantas pessoas usam, com que frequência, em desktop ou celular, dentro ou fora da empresa. Esse bloco sozinho pode mover um orçamento em 50%.

3. Os fluxos principais, passo a passo

Escolha os 3 a 5 processos que o sistema precisa cobrir e descreva cada um em linguagem de gente: "o vendedor cadastra o pedido, o financeiro aprova, o estoque separa, o cliente recebe um aviso". Cada passo desses é trabalho de desenvolvimento. Fluxo não escrito é fluxo não orçado.

4. O que o sistema NÃO precisa fazer

Esse bloco quase ninguém escreve, e é o que mais protege o orçamento. "Não precisa de app mobile na primeira versão", "não precisa emitir nota fiscal, usamos outro sistema para isso", "relatórios em Excel exportado bastam". Cortar no papel é grátis. Cortar depois do contrato assinado custa reunião, renegociação e ressentimento.

5. Integrações e sistemas que já existem

Liste tudo com que o sistema novo precisa conversar: ERP, planilhas, WhatsApp, meio de pagamento, sistema do contador. Integração é onde mora a maior parte das surpresas de preço, porque depende de fatores fora do controle do fornecedor. Quanto antes ela aparece no papel, mais realista fica a proposta.

6. Restrições de prazo e orçamento

Dizer a faixa de investimento não enfraquece sua negociação, ao contrário. Um bom fornecedor usa esse número para propor o recorte de escopo que cabe nele. "Tenho até R$ 80 mil e preciso rodando em 4 meses" gera uma proposta útil. Esconder o número gera uma proposta que talvez custe o dobro do que você pode pagar, e todo mundo perdeu tempo.

O checklist antes de enviar o briefing

Antes de mandar o documento para qualquer fornecedor, pergunta isso:

• Uma pessoa de fora da empresa entenderia o problema lendo só o documento?
• Cada fluxo importante está descrito em passos, do início ao fim?
• Está escrito o que fica de fora da primeira versão?
• Todas as integrações estão listadas, mesmo as "óbvias"?
• Tem número de usuários e volume de uso esperado?
• Tem faixa de orçamento e prazo desejado?
• Alguém que opera o processo hoje revisou e confirmou que é assim que funciona?

O último item merece atenção. É comum o briefing ser escrito pelo dono ou pelo gestor, e o processo real, aquele que a equipe executa todo dia, ter etapas que ninguém no comando conhece. Quinze minutos com quem opera evita semanas de retrabalho.

Erros de briefing que custam caro

Pedir "tudo que o concorrente tem". O sistema do concorrente foi construído ao longo de anos. Orçar uma cópia completa infla o projeto e atrasa o que realmente resolve seu problema. Comece pelo recorte que destrava sua operação.

Tratar o briefing como contrato. Ele é ponto de partida, não documento jurídico. Um bom fornecedor vai fazer perguntas, sugerir cortes e propor mudanças. Se a proposta voltar sem nenhuma pergunta, desconfie: ou o fornecedor não leu com atenção, ou vai descobrir as dúvidas com o projeto rodando, no seu bolso.

Detalhar telas antes de fechar fluxos. Cor de botão e layout são decisões de design, resolvidas durante o projeto. Gastar o briefing descrevendo telas e esquecer de descrever o processo é priorizar o que muda fácil em vez do que custa caro mudar.

Enviar briefings diferentes para cada fornecedor. Se cada empresa recebe uma versão da história, as propostas não se comparam. Um documento único, enviado igual para todos, é a única forma de comparar preço com preço.

Como o fornecedor certo reage a um bom briefing

Não existe resposta única, mas existe conta certa. E a conta começa na primeira reação do fornecedor ao seu documento. Quem trabalha bem responde com perguntas específicas, aponta ambiguidades que você não viu e, muitas vezes, sugere tirar coisas do escopo. Na OCA, é comum a primeira conversa terminar com o escopo menor do que o cliente trouxe, porque parte do que foi pedido não precisava ser software sob medida, ou não precisava estar na primeira versão.

Esse é o tipo de projeto que a gente constrói: sistemas que substituem a planilha crítica, conectam o que já existe e entram em produção com escopo honesto. Foi assim com o sistema de gestão para imobiliárias que mantemos em produção, que começou cobrindo o fluxo de locação de ponta a ponta antes de crescer para o resto da operação. A gente também opera produto próprio, o Revo App, com mais de 40 mil usuários, então cada recomendação de escopo vem de quem paga a conta de manutenção do próprio sistema.

O próximo passo

A ação gratuita: abra um documento em branco e escreva os seis blocos acima. Não precisa ficar bonito, precisa ficar claro. Duas páginas bem escritas valem mais do que vinte páginas de requisitos vagos, e o exercício de escrever costuma revelar decisões que você ainda não tinha tomado.

Se quiser uma leitura crítica desse briefing antes de pedir orçamentos, ou se preferir construir o documento junto com quem faz isso toda semana, a conversa começa aqui: Converse com a OCA sobre o seu sistema.