Roteiro do briefing
| Tópico | O que responder |
|---|---|
| Problema | O que dá errado hoje e quanto isso custa |
| Objetivo | Como você vai saber que o sistema deu certo |
| Usuários | Quem usa, quantos são e o que cada perfil faz |
| Processo atual | Passo a passo de como o trabalho é feito hoje |
| Regras | Cálculos, aprovações, prazos e exceções |
| Integrações | Sistemas que já existem e precisam conversar com o novo |
| Dados | O que existe hoje (planilhas, sistema antigo) e precisa ser migrado |
| Prioridades | O que é indispensável na primeira versão e o que pode esperar |
| Restrições | Prazo, orçamento, regras legais do setor |
Leve exemplos reais
Planilhas, formulários, relatórios e prints dos sistemas usados hoje valem mais do que longas descrições. Se possível, mostre um caso real do começo ao fim, incluindo uma exceção (“e quando o cliente cancela no meio?”).
Erros comuns no briefing
- Descrever a solução (“quero um sistema com cinco abas”) em vez do problema
- Deixar de fora as exceções, que são justamente as partes mais trabalhosas
- Não envolver quem usa o processo no dia a dia
- Tratar tudo como prioridade
O briefing não precisa estar completo
Parte do trabalho de uma boa empresa de desenvolvimento é fazer as perguntas certas no levantamento. O briefing é o ponto de partida, não o contrato. Mas quanto mais claro ele for, mais precisas e comparáveis serão as propostas: veja como escolher uma empresa de desenvolvimento de software e quanto custa um software sob medida.
Com o briefing em mãos, conte o seu caso para a gente no desenvolvimento de software sob medida.