Como escrever o escopo de um projeto de software

A maior causa de projeto de software atrasado ou mais caro do que o combinado não é código ruim. É escopo vago. "Um sistema para controlar os pedidos" pode virar uma semana ou seis meses de trabalho, e cada fornecedor imagina uma coisa diferente quando lê essa frase.

Você não precisa saber programar para escrever um bom escopo. Precisa descrever o problema e o trabalho do dia a dia com clareza. Este roteiro cabe em duas ou três páginas.

1. O problema, em uma frase

Comece pelo que dói hoje, não pela solução. "Perdemos pedidos porque eles chegam por WhatsApp, telefone e e-mail e ninguém sabe o status de cada um" diz muito mais que "queremos um sistema de pedidos".

Inclua um número se tiver: quantos pedidos por dia, quantas horas a equipe gasta, quanto se perde por mês. Isso ajuda o fornecedor a dimensionar e ajuda você a medir se o sistema deu certo.

2. Quem vai usar

Liste os tipos de usuário e quantos de cada um. Por exemplo: vendedores (8), financeiro (2), gerente (1) e clientes (cerca de 300, acessando pelo celular).

Para cada tipo, escreva o que essa pessoa precisa fazer. Use frases simples, no formato "o vendedor cadastra o pedido e vê se o cliente tem débito".

3. Os fluxos principais

Descreva o caminho de ponta a ponta das três ou quatro tarefas mais importantes. Por exemplo:

1. O cliente faz o pedido pelo site.
2. O vendedor confere e aprova.
3. O financeiro emite a nota.
4. A expedição separa e marca como enviado.
5. O cliente recebe um aviso com o rastreio.

Esse passo a passo revela quem faz o quê, em que ordem e quais avisos precisam existir. É o trecho mais útil do escopo inteiro.

4. Regras de negócio

Anote as regras que fogem do óbvio: desconto máximo por vendedor, aprovação acima de certo valor, prazo diferente por região, estoque mínimo. Se uma regra tem exceção, escreva a exceção também. Regra esquecida é a principal fonte de aditivo no meio do projeto, como contamos em quanto custa desenvolver um sistema sob medida.

5. Integrações

Liste os sistemas com que este precisa conversar: ERP, emissão de nota, meio de pagamento, WhatsApp, planilhas, outro sistema interno. Para cada um, diga o que entra e o que sai. Se o sistema atual tem API, ótimo; se não tem, diga também, porque isso muda o esforço.

6. O que fica de fora

Essa seção parece estranha, mas é a que mais evita briga. Escreva o que não faz parte desta fase: "não vamos ter app nas lojas agora", "o estoque continua no ERP", "relatórios avançados ficam para a fase 2".

7. Como saber que está pronto

Escreva critérios de aceite simples e verificáveis. "O vendedor consegue lançar um pedido em menos de dois minutos pelo celular." "Toda nota autorizada chega ao cliente por e-mail." Critério verificável transforma "acho que não está pronto" em uma conversa objetiva.

8. Restrições

Prazo, orçamento aproximado, onde o sistema deve rodar e exigências de segurança ou LGPD. Se o sistema guarda dados pessoais, vale ler LGPD no desenvolvimento de software antes de fechar o escopo.

Junte material de apoio

Prints do sistema atual, a planilha que a equipe usa hoje, fotos de formulários de papel e exemplos de sistemas que você gosta. Uma planilha real vale mais que muitas páginas de descrição, porque mostra os campos e os casos de verdade.

O escopo vai mudar, e tudo bem

Nenhum escopo prevê tudo. O objetivo é que as mudanças sejam conscientes: você sabe o que estava combinado, o que entrou depois e quanto isso custa. Combine com o fornecedor como mudanças serão tratadas antes de começar.

Com um documento assim em mãos, peça orçamento para dois ou três fornecedores. Como todos leram a mesma coisa, os preços ficam comparáveis, e a forma como cada um faz perguntas sobre o seu escopo já mostra quem entendeu o problema.