Briefing de software: como escrever o documento que evita retrabalho e surpresa no preço (com as 10 perguntas que o fornecedor precisa ver)

Você descreveu o sistema em quatro parágrafos no WhatsApp, mandou para três fornecedores e recebeu três propostas que parecem de projetos diferentes. Uma prevê seis semanas, outra prevê cinco meses. Você escolheu a do meio, assinou e, no segundo mês, ouviu a frase que ninguém quer ouvir: "isso não estava no escopo". O relatório de comissão, a permissão do gerente, a exportação para o contador. Para você, tudo isso era óbvio. Só que nada estava escrito.

Esse é o roteiro mais comum de projeto que estoura prazo e orçamento, e quase nunca começa no código. Começa no briefing. A boa notícia é que um bom briefing não exige conhecimento técnico. Ele exige que você descreva a sua operação, e não só a sua ideia. Este artigo traz as 10 perguntas que o documento precisa responder antes de você pedir qualquer orçamento.

Por que um briefing vago vira retrabalho e aumento de preço

Quem faz orçamento de software precisa transformar texto em horas. Quando o texto diz "um sistema para controlar pedidos", cada fornecedor preenche as lacunas com suposições. Um imagina três telas e um cadastro. Outro imagina estoque, nota fiscal e app para o entregador. Os dois estão orçando com honestidade. Só estão orçando coisas diferentes.

O problema aparece depois. Toda lacuna que o fornecedor preencheu com a suposição mais barata volta como pedido de mudança. E um pedido de mudança no meio do projeto custa mais do que a mesma funcionalidade planejada desde o início, porque mexe em coisa já construída e testada.

O barato que sai caro aqui é o seguinte: um fluxo esquecido no briefing costuma virar de 40 a 80 horas de desenvolvimento. Com a hora de um profissional sênior entre R$ 150 e R$ 250, são de R$ 6 mil a R$ 20 mil que não estavam no seu orçamento, mais duas a quatro semanas de atraso. Bastam três esquecimentos desses para o projeto de R$ 60 mil virar um de R$ 100 mil.

Não é má-fé de ninguém. É informação que estava só na sua cabeça.

Três caminhos para definir o escopo (e quando cada um faz sentido)

Escrever o briefing sozinho

Custa o seu tempo: de 4 a 8 horas bem gastas. Funciona bem para sistemas com até quatro fluxos principais e quando você conhece a operação de perto. É o caminho que este artigo ensina. O limite é que você não sabe o que não sabe. Integração com ERP, volume de dados e regras fiscais podem passar batido.

Discovery pago com o fornecedor

É uma fase de 1 a 4 semanas em que o time entrevista quem usa, mapeia os fluxos e entrega escopo detalhado, protótipo e estimativa. Costuma custar de R$ 5 mil a R$ 25 mil, dependendo do tamanho. Vale a pena para sistemas com muitas regras de negócio, várias áreas envolvidas ou integrações críticas. E um briefing bem escrito reduz o tempo e o preço do discovery.

Começar sem escopo e "ajustar no caminho"

Só funciona com contrato por hora e um orçamento que aguente a variação. Em contrato de preço fechado, é a receita do projeto travado. Quem já passou por um projeto travado sabe do que estou falando.

Talvez você nem precise de um briefing de software

Antes de escrever qualquer coisa, faça um teste: procure três SaaS do seu segmento e anote o que eles não resolvem. Se a lista couber em duas linhas e nenhum desses itens for o que diferencia o seu negócio, assine o SaaS. Você economiza meses e dezenas de milhares de reais. O software sob medida compensa quando o processo que você quer automatizar é justamente a sua vantagem competitiva, ou quando você já paga três ferramentas que não conversam entre si.

Modelo de briefing de software: as 10 perguntas que o documento precisa responder

Antes de assinar qualquer contrato, pergunta isso: um fornecedor conseguiria orçar o meu sistema só com o que está escrito? Se a resposta for não, falta responder a alguma destas perguntas.

1. Que problema o sistema resolve e quanto esse problema custa hoje? Responda em horas ou em reais. "A equipe gasta 30 horas por mês consolidando pedidos em planilha" orienta muito mais que "queremos ganhar eficiência". Esse número também mostra quanto faz sentido investir.
2. Quem vai usar e com quais permissões? Liste os perfis: administrador, gerente, atendente, cliente final. Cada perfil com um acesso diferente é uma regra de permissão a ser construída. Informe quantas pessoas usam cada perfil.
3. O que o sistema substitui? Planilha, papel, WhatsApp ou outro software. Se existir um sistema antigo, diga se os dados precisam ser migrados. Migração mal planejada é uma das maiores fontes de surpresa no preço.
4. Quais são os 3 a 5 fluxos que precisam funcionar no primeiro dia? Descreva passo a passo, como uma história: "o corretor cadastra o imóvel, o gerente aprova e o anúncio vai para o site". Um fluxo descrito assim vira uma estimativa confiável.
5. O que fica de fora da primeira versão? A lista do que não entra protege o seu orçamento tanto quanto a lista do que entra. Escreva de forma explícita: "relatórios avançados ficam para a fase 2".
6. Com quais sistemas ele precisa conversar? ERP, gateway de pagamento, emissor de nota fiscal, CRM, WhatsApp. Para cada um, informe se a ferramenta tem API (o fornecedor dela sabe responder). Integrar com um sistema que não tem API documentada pode custar mais que o resto do projeto.
7. Qual é o volume esperado? Usuários simultâneos, registros por mês, arquivos enviados. Receber 50 pedidos por dia ou 5 mil pedidos por dia exige arquiteturas diferentes, com custos de infraestrutura diferentes.
8. Onde o sistema vai rodar? No navegador do computador, no celular, como app instalado ou também sem internet? Um app nativo publicado nas lojas pode dobrar o custo em relação a um sistema web responsivo.
9. Qual é o prazo real e o que acontece se ele não for cumprido? Separe o prazo desejado do prazo que tem consequência (uma temporada de vendas, um contrato, uma obrigação legal). Um prazo com motivo ajuda o fornecedor a sugerir o que cortar.
10. Qual é a faixa de orçamento e quem cuida do sistema depois? Informar uma faixa não enfraquece a sua negociação. Ela permite que o fornecedor proponha a solução que cabe no seu bolso. Inclua a conta mensal: hospedagem, manutenção e pequenas evoluções costumam somar de 15% a 25% do valor do projeto por ano.

Um bom briefing tem de 2 a 5 páginas. Se passar disso, provavelmente você está desenhando telas em vez de descrever a operação. Deixe que o fornecedor proponha as telas.

Os erros que fazem o briefing atrapalhar em vez de ajudar

• Descrever a solução em vez do problema. "Quero um botão que exporte para Excel" esconde a pergunta real: quem precisa desse dado e para quê? Às vezes a resposta é um painel, e não um arquivo.
• Copiar o concorrente. "Igual ao app X" não é escopo. O app X tem anos de desenvolvimento e um time inteiro por trás. Diga quais três funções do app X você realmente precisa.
• Escrever sem ouvir quem opera. O dono descreve o processo como ele deveria ser. O atendente sabe como ele é de verdade. Converse com duas ou três pessoas da linha de frente antes de fechar o documento.
• Não definir quem decide. Se três sócios precisam aprovar cada tela, o projeto anda na velocidade da reunião mais difícil de marcar. Escolha uma pessoa com autoridade para aprovar as entregas e escreva o nome dela no briefing.
• Tratar o briefing como contrato final. Ele é o ponto de partida. Um fornecedor sério vai fazer perguntas sobre ele. Desconfie de quem orça sem perguntar nada.

Esse último ponto também serve como filtro de fornecedor. Mande o mesmo briefing para três empresas e compare as perguntas que voltam, não só o preço. Quem pergunta sobre volume, migração e integração está orçando o seu sistema. Quem responde em uma hora com um número redondo está orçando um sistema genérico.

Como a OCA usa o briefing para orçar um sistema sob medida

Esse é o tipo de projeto que a gente constrói. O sistema de Gestão para Imobiliárias, hoje em produção, cobre a operação de locação de ponta a ponta. Em um sistema desse porte, a primeira conversa é sempre a mesma: quais fluxos precisam funcionar no primeiro dia e quais podem esperar a segunda fase. Seguimos a mesma regra no nosso próprio produto, o Revo App, que tem mais de 40 mil usuários cadastrados: cada funcionalidade nova entra com escopo escrito e uma lista explícita do que fica de fora.

Quando um briefing chega, quem lê é o mesmo time sênior que vai escrever o código. A gente devolve as perguntas que faltam e diz o que não vale construir, inclusive quando a resposta é "assine um SaaS". Você pode conferir os sistemas que já entregamos no nosso portfólio de projetos em produção.

Próximo passo: escreva o seu briefing esta semana

Separe duas horas, abra um documento e responda às 10 perguntas acima. Não precisa ficar bonito, precisa ficar completo. Depois mostre o texto a duas pessoas que operam o processo e ajuste o que elas corrigirem.

Com esse documento em mãos, você consegue pedir orçamentos comparáveis a qualquer fornecedor. Se quiser que a gente leia e devolva as perguntas que faltam, mande para a OCA. A resposta vem com o que entraria na primeira versão, uma faixa de prazo e de custo e o que deixaríamos de fora.

Converse com a OCA sobre o seu sistema