Como escrever um briefing de software que evita retrabalho

Um briefing de software bem escrito reduz o orçamento antes de reduzir o retrabalho. Fornecedor que recebe um documento claro precifica o trabalho; fornecedor que recebe "preciso de um sistema de gestão" precifica o trabalho mais a incerteza. Essa margem de incerteza costuma ser de 20% a 40% do valor, e ela é sua para eliminar.

Seção 1: o problema, não a solução

Comece pelo que está quebrado hoje. Descreva o processo atual como ele realmente acontece, incluindo as planilhas paralelas e os grupos de WhatsApp que ninguém admite usar.

Escreva assim:

Hoje os pedidos chegam por WhatsApp e são anotados numa planilha. Três pessoas mexem nessa planilha e ela é sobrescrita cerca de duas vezes por semana. Cada retrabalho custa em média uma hora e já perdemos dois pedidos por isso no último trimestre.

Não escreva "preciso de um CRM". A primeira versão dá ao fornecedor o problema e o custo dele. A segunda dá um nome de categoria que cada pessoa interpreta de um jeito.

Seção 2: quem usa e o que cada um pode fazer

Liste os perfis de usuário, não as pessoas. Para cada perfil, escreva o que ele precisa fazer e o que ele não pode ver.

Essa tabela sozinha responde uma dúzia de perguntas que o fornecedor faria depois, e permissão é uma das áreas que mais gera retrabalho quando é descoberta tarde.

Seção 3: os fluxos principais, em passos

Descreva de três a seis fluxos completos, do início ao fim, em frases numeradas. Um exemplo:

1. O vendedor cria o pedido com cliente, itens e prazo.
2. Se o desconto passa de 10%, o pedido vai para aprovação do supervisor.
3. Aprovado, o pedido vira ordem e o estoque é reservado.
4. O financeiro registra o pagamento.
5. Registrado o pagamento, o pedido é liberado para expedição.

Depois de cada fluxo, liste o que pode dar errado: cliente sem cadastro, item sem estoque, pagamento parcial, cancelamento após reserva. As exceções são onde mora a maior parte do custo de desenvolvimento, descrevê-las agora é o que impede a surpresa depois.

Seção 4: as regras de negócio, em frases testáveis

Regra de negócio é qualquer decisão automática que o sistema toma. Escreva cada uma em uma frase que possa ser verificada como verdadeira ou falsa:

• Desconto acima de 10% exige aprovação do supervisor.
• Pedido com pagamento pendente há mais de 15 dias bloqueia novos pedidos do mesmo cliente.
• Comissão é 3% sobre o valor líquido, paga apenas após confirmação do pagamento.
• Item sem estoque pode entrar no pedido, mas o pedido fica com status "aguardando reposição".

Evite adjetivos. "O sistema deve ser rápido" não é regra; "a busca de clientes deve retornar em menos de 2 segundos com 50 mil registros" é.

Seção 5: integrações e origem dos dados

Para cada sistema externo, informe:

• Nome e versão do sistema.
• Direção: você envia, recebe ou os dois.
• O que trafega: quais dados, com que frequência.
• Se existe API e se você tem a documentação em mãos.
• Quem é o contato do outro lado.

Esse último item economiza semanas. Integração trava muito mais por falta de interlocutor no fornecedor terceiro do que por dificuldade técnica.

Inclua também a migração: quantos registros existem hoje, em que formato estão e quem responde por decidir o que migra e o que fica no histórico.

Seção 6: o que está fora do escopo

A seção mais curta e a que mais economiza dinheiro. Liste explicitamente o que não faz parte desta versão:

• Aplicativo mobile nativo (será usado pelo navegador do celular)
• Integração com o ERP (fase 2)
• Emissão de nota fiscal
• Relatórios gerenciais além dos três listados
• Login por conta Google

Sem essa lista, cada item vira uma discussão de "eu achei que estava incluso" no meio do projeto. Com ela, vira um pedido de mudança tratado com preço e prazo, o que é uma conversa muito melhor.

Seção 7: como saber se deu certo

Defina de dois a quatro critérios verificáveis de sucesso. Não "melhorar a gestão", mas:

• Nenhum pedido perdido por sobrescrita de planilha em 60 dias de uso.
• O fechamento do mês passa de dois dias para menos de quatro horas.
• Todo vendedor consegue emitir um pedido sem consultar o supervisor sobre o processo.

Esses critérios servem para três coisas: alinhar o fornecedor no que importa, decidir prioridade quando o tempo apertar e avaliar honestamente o projeto depois.

O que deixar de fora do briefing

Alguns conteúdos atrapalham mais do que ajudam:

• Escolhas técnicas. Especificar linguagem, banco ou framework sem motivo restringe soluções melhores. Exceção legítima: quando sua equipe interna vai manter o sistema e já domina uma stack.
• Desenho de telas. Descreva o que precisa ser feito na tela, não onde fica cada botão. Layout é trabalho da fase de projeto.
• Prazo tirado do nada. Diga qual é a data que importa e por quê (uma feira, um contrato, uma obrigação legal). Isso permite negociar escopo em vez de negociar o impossível.

O formato que funciona

Três a cinco páginas, em documento de texto, com as sete seções na ordem acima. Uma pessoa responsável por consolidar. Uma rodada de leitura com quem executa o processo no dia a dia, não só com quem gerencia, porque quem executa conhece as exceções.

Depois de escrito, mande o mesmo documento para todos os fornecedores que vão orçar. É a única forma de receber propostas que dá para comparar.