Como fazer o briefing do seu sistema para o desenvolvedor entender exatamente o que você quer

Seu novo sistema nao vai funcionar porque o desenvolvedor nao entendeu sua ideia. A causa raiz de 90% dos projetos de software que entregam errado nao e a tecnologia, e sim o briefing mal feito. Voce descreveu o que queria, mas o desenvolvedor construiu outra coisa. Este guia mostra exatamente como estruturar um briefing que elimina essa lacuna de comunicacao.

O problema: voce descreveu a solucao, nao o problema

Quando voce diz "quero um sistema com tela de login, cadastro de clientes e um relatorio de vendas", esta descrevendo a solucao que imagina, nao o problema que precisa resolver. O desenvolvedor vai construir exatamente o que voce pediu, mas pode ser que isso nao resolva seu problema real. Um briefing eficaz comeca com a descricao do problema, nao da solucao tecnica.

Por exemplo, em vez de dizer "quero um sistema que envie e-mail automatico para clientes inadimplentes", diga "perco R$ 50 mil por mes porque 30% dos meus clientes atrasam o pagamento e minha equipe nao consegue cobrar todos manualmente". A diferenca e que o desenvolvedor agora entende o objetivo de negocio e pode sugerir a melhor solucao tecnica, que pode ser muito diferente do que voce imaginou.

O que um briefing completo deve conter: 6 elementos essenciais

Um briefing que funciona e composto por seis partes. Cada uma delas elimina uma fonte comum de erro na comunicacao com o desenvolvedor. Vamos a cada uma com exemplos concretos.

1. Descreva o problema que o sistema vai resolver

Nao diga "quero um CRM". Diga: "Minha equipe de vendas tem 5 vendedores que atendem 200 leads por mes. Hoje eles usam planilhas individuais, e 40% dos leads se perdem porque ninguem sabe quem ja ligou ou qual o status. Perco cerca de R$ 30 mil em vendas por mes por causa disso."

Com essa descricao, o desenvolvedor sabe que o objetivo nao e ter um CRM, e sim nao perder leads. A solucao pode ser um CRM simples, um kanban no Trello, ou ate uma automacao com planilhas compartilhadas. O problema guia a decisao, nao o nome do sistema.

2. Liste os usuarios que vao usar o sistema

Seja especifico sobre quantas pessoas, qual o papel de cada uma e o que cada uma precisa fazer no sistema. Exemplo:

• 3 vendedores: cadastram leads, registram contatos, fecham vendas
• 1 gerente: ve relatorios, aprova descontos, redistribui leads
• 1 administrador: cadastra produtos, define metas, gerencia usuarios
• 200 clientes ativos: acessam o portal para ver pedidos e historico (so leitura)

Isso evita que o desenvolvedor crie permissoes genericas ou funcionalidades que ninguem vai usar. Cada tipo de usuario tem necessidades diferentes, e o briefing precisa refletir isso.

3. Descreva o fluxo principal passo a passo

Nao descreva telas. Descreva o que acontece no dia a dia, em ordem. Exemplo de um sistema de controle de ordens de servico:

1. Cliente liga pedindo um orcamento. Atendente abre o sistema, cadastra o cliente (se novo) e registra a solicitacao com descricao do problema e dados de contato.
2. Sistema notifica o tecnico disponivel (por WhatsApp ou e-mail) com os detalhes da solicitacao.
3. Tecnico aceita a ordem, vai ao local, executa o servico e registra no sistema: servico realizado, pecas usadas, valor da mao de obra.
4. Sistema calcula o valor total (pecas + mao de obra) e gera um PDF de orcamento que o tecnico envia para o cliente.
5. Cliente aprova ou recusa. Se aprovar, o sistema gera a nota fiscal (integrado com o sistema de NF-e).
6. Faturamento registra o pagamento (dinheiro, cartao, boleto) e o sistema atualiza o status da ordem para "concluida".
7. Gerente ve no final do dia um relatorio com ordens concluidas, faturamento e tecnicos mais produtivos.

Cada passo desse fluxo pode esconder dezenas de decisoes de implementacao. Se voce nao descrever o fluxo, o desenvolvedor vai inventar um, e provavelmente nao sera o que voce espera.

4. Liste o que precisa ser registrado (quais dados)

Para cada entidade do sistema, liste os campos que precisa armazenar. Exemplo para um sistema de gestao de estoque:

• Produto: nome, codigo de barras, categoria, fornecedor, preco de custo, preco de venda, quantidade minima em estoque, localizacao no deposito (corredor, prateleira)
• Movimentacao: tipo (entrada/saida), data, quantidade, motivo, usuario responsavel, numero da nota fiscal
• Fornecedor: razao social, CNPJ, endereco, telefone, prazo medio de entrega, condicoes de pagamento

Nao presuma que o desenvolvedor sabe o que voce precisa registrar. Se voce nao listar "localizacao no deposito", ele pode criar um sistema que nao permite saber onde cada produto esta fisicamente, e voce vai ter que pagar um upgrade depois.

5. Liste os relatorios ou visoes que precisa

Relatorios sao o que voce realmente usa para tomar decisoes. Liste cada um com detalhes do que deve conter. Exemplo:

• Relatorio de vendas por vendedor (mes atual): nome do vendedor, total de vendas, comissao calculada, comparativo com meta
• Relatorio de produtos mais vendidos (ultimos 30 dias): nome do produto, quantidade vendida, receita gerada, margem de lucro
• Painel do gerente: grafico de vendas diarias, alerta de estoque baixo, ordens de servico em andamento, faturamento do dia comparado com ontem

Seja especifico sobre periodos, filtros e formatos. "Um relatorio de vendas" pode significar 10 coisas diferentes. "Relatorio de vendas por vendedor no mes atual, com total, comissao e comparativo com a meta, exportavel em PDF e Excel" e um briefing claro.

6. Diga o que ja existe e precisa continuar funcionando

Muitos empresarios ignoram essa parte e depois descobrem que o sistema novo nao conversa com o que ja existe. Liste todos os sistemas, planilhas e processos que precisam ser integrados ou mantidos. Exemplo:

• Planilha de controle de clientes no Google Sheets (300 clientes ativos, atualizada manualmente)
• Sistema de nota fiscal eletronica da Prefeitura (API REST que ja usamos)
• Gateway de pagamento da Stone (integracao via API)
• Planilha de precos de fornecedores (atualizada semanalmente, precisa ser importada)

Isso evita surpresas. O desenvolvedor pode descobrir que a API da prefeitura so aceita XML em um formato especifico, ou que a planilha de clientes tem 2 mil linhas com dados inconsistentes. Sabendo disso antes, ele pode planejar a migracao e a integracao corretamente.

Como tomar a decisao certa: template de briefing para preencher

Use este template para estruturar seu briefing. Preencha cada secao com o maximo de detalhes possivel. Quanto mais especifico, menor a chance de erro.

**1. Problema que o sistema vai resolver**
(Descreva o que acontece hoje que e ineficiente, quanto custa em tempo ou dinheiro, e o que voce espera melhorar)

**2. Usuarios do sistema**
- Tipo 1: [cargo/funcao], quantos usuarios, o que fazem no sistema
- Tipo 2: [cargo/funcao], quantos usuarios, o que fazem no sistema
- (adicione quantos tipos forem necessarios)

**3. Fluxo principal (passo a passo do dia a dia)**
1. [primeiro passo]
2. [segundo passo]
3. (continue ate o final do processo principal)

**4. Dados que precisam ser registrados**
- Entidade 1 (ex: Cliente): campos necessarios
- Entidade 2 (ex: Produto): campos necessarios
- (liste todas as entidades)

**5. Relatorios e visoes necessarios**
- Relatorio 1: descricao, periodo, filtros, formato de saida
- Relatorio 2: descricao, periodo, filtros, formato de saida

**6. Sistemas e processos existentes que continuam**
- Sistema/planilha 1: o que faz, como se integra
- Sistema/planilha 2: o que faz, como se integra

Preencha esse template e envie para pelo menos 3 desenvolvedores diferentes. Compare as propostas que receber. Se as propostas forem muito diferentes, e sinal de que seu briefing ainda tem ambiguidades. Refine ate que as propostas sejam equivalentes em escopo, variando apenas em tecnologia e preco.

Perguntas frequentes