A resposta curta
Para definir o escopo de um software, comece pelo problema da operação, não pela lista de telas. Um bom escopo descreve o objetivo, quem usa, as rotinas que o sistema cobre, as regras de negócio, as integrações, o que fica de fora e como cada entrega será aceita. Tudo escrito, revisado com quem opera e aprovado por quem decide.
Você não precisa chegar com isso pronto. Transformar um problema da operação em escopo validado é parte do trabalho de quem desenvolve, e costuma acontecer numa fase de estudo antes de qualquer compromisso maior. O que ajuda muito é saber contar o que hoje dá trabalho, atrasa ou gera erro, e quem sente esse problema no dia a dia.
O que um bom escopo de software contém
Escopo não é uma lista de funcionalidades. É o acordo sobre o que o sistema precisa resolver e até onde ele vai. Sete partes aparecem em qualquer escopo que se sustenta:
- Objetivo. O problema que o sistema resolve, dito em uma ou duas frases, e como se vai saber que ele foi resolvido. "Acabar com a redigitação entre a recepção e o atendimento" orienta decisões; "modernizar o processo" não orienta nenhuma.
- Usuários e perfis. Quem usa, com que frequência e com que permissão. Um sistema como o Ágil Cidadão, nosso sistema de atendimento ao cidadão, tem três perfis (cidadão, atendente e gestão), e cada um usa a mesma informação de um jeito.
- Rotinas cobertas. Os processos que o sistema acompanha do começo ao fim, descritos como acontecem: quem inicia, por onde passa, onde termina. É aqui que aparecem as exceções que ninguém lembrou na primeira conversa.
- Regras de negócio. As condições que o sistema precisa respeitar: prazos, aprovações, cálculos, quem pode fazer o quê. Regra que só existe na cabeça de alguém vira defeito quando o sistema entra em uso.
- Integrações. Com quais sistemas o novo precisa conversar, em que direção e por qual meio, como uma API ou uma exportação estruturada. Vale confirmar cedo o que cada sistema permite, porque é nas integrações que costuma morar a surpresa.
- Exclusões. O que não faz parte desta etapa, escrito com a mesma clareza do que faz. A lista do que fica de fora evita boa parte das discussões do meio do projeto.
- Critério de aceite. Como cada entrega será considerada pronta. Uma frase como "o atendente consegue abrir a solicitação pelo cidadão e o histórico registra autor e data" pode ser testada; "funcionar bem" não pode.
Alguns requisitos entram mesmo que ninguém peça: quantas pessoas usam ao mesmo tempo, que dados pessoais o sistema guarda e o que a LGPD exige sobre eles, se há exigência de acessibilidade. Deixar isso para o fim costuma sair caro, porque mexe no desenho inteiro.
Checklist para revisar o escopo antes de contratar
Antes de aprovar um escopo, seja o que a sua equipe escreveu, seja o que um fornecedor entregou, confira se ele responde a estas perguntas:
- O problema está escrito? Dá para ler o objetivo e entender por que o sistema existe sem conhecer o projeto.
- Quem opera participou? As rotinas foram descritas por quem executa o processo, não só por quem gerencia.
- Cada perfil está listado? Com o que pode ver, cadastrar, aprovar e excluir.
- As regras têm dono? Cada regra de negócio tem alguém do seu lado que confirma se ela está certa.
- As integrações foram verificadas? Para cada sistema existente, sabe-se o que ele permite e quem responde por ele.
- Há uma lista do que fica de fora? Se não há, cada pessoa vai supor uma fronteira diferente.
- Os itens têm critério de aceite? Cada entrega diz como será testada e aprovada.
- O essencial está separado do desejável? O escopo mostra o que entra na primeira versão e o que vem depois.
- Dados e migração estão previstos? Se há informação em planilha ou em sistema antigo, o escopo diz o que será migrado e como.
Se várias respostas forem "não sei", isso não quer dizer que o projeto é ruim. Quer dizer que falta estudo antes de estimar. Explicamos essa fase em o que é discovery de produto.
Como priorizar o que é essencial agora e o que pode esperar
Todo escopo começa maior do que precisa. Cada setor traz a sua lista, e somar todas as listas é o caminho mais curto para um projeto longo que demora a gerar valor.
A pergunta que organiza a prioridade é simples: sem isto, a rotina principal funciona? Se a resposta é não, o item entra agora. Se a rotina funciona, mesmo com algum trabalho manual, o item pode ir para uma etapa seguinte.
- Essencial agora. O que resolve a dor principal e o que é obrigatório por lei ou por segurança, como controle de acesso e proteção de dados pessoais.
- Importante, mas pode esperar. Relatórios adicionais, automações de conveniência, telas para perfis que usam pouco o sistema.
- Desejável. Ideias que fazem sentido, mas que o uso real ainda precisa confirmar.
Uma primeira versão enxuta, focada na rotina que mais sofre, entra em uso enquanto o resto é construído. O que a equipe aprende usando muda a lista do que vem depois, e quase sempre para melhor. O raciocínio é o mesmo de um MVP bem definido.
Escopo fechado ou escopo evolutivo: qual escolher
Há duas formas de tratar o escopo num contrato, e as duas funcionam quando aplicadas ao caso certo.
| Critério | Escopo fechado | Escopo evolutivo |
|---|---|---|
| Quando serve | Problema claro, com começo, meio e fim | Produto que vai mudar com o uso |
| O que se define no início | Todas as entregas e seus critérios de aceite | O objetivo, a primeira versão e as prioridades |
| Como lida com mudança | Cada mudança é avaliada e aprovada à parte | A prioridade é revista a cada sprint |
| Previsibilidade | Prazo e investimento definidos desde o início | Ritmo previsível, com o escopo ajustado pelo que se aprende |
| Risco principal | Fixar cedo algo que o uso mostraria diferente | Perder o foco se ninguém decidir o que fica de fora |
Nós trabalhamos nos dois modelos, projeto fechado e time dedicado, e recomendamos um deles depois de entender o caso. Nos dois, mudança faz parte: avaliamos o impacto de cada pedido no prazo e no esforço, mostramos as opções e nada muda sem o aceite de quem contrata.
No setor público, a Lei 14.133/2021 prevê o estudo técnico preliminar e o termo de referência antes da contratação, e esses documentos já cumprem parte do papel do escopo. Quanto mais o termo de referência descreve o problema e os critérios de aceite, e menos uma lista de telas, mais espaço sobra para a solução certa.
Erros comuns ao definir o escopo de um sistema
- Começar pelas telas. Desenhar a interface antes de entender a rotina leva a um sistema bonito que não encaixa no trabalho.
- Ouvir só quem gerencia. Quem decide conhece o objetivo; quem opera conhece as exceções. Um escopo sem as duas visões falha em uma delas.
- Copiar o sistema antigo. Reproduzir tela por tela o que existe hoje carrega junto os atalhos que a equipe criou para contornar as limitações.
- Deixar as integrações para depois. Descobrir no meio do projeto que o outro sistema não oferece API muda o prazo e às vezes a própria solução.
- Usar termos vagos. "Intuitivo", "rápido" e "completo" não se testam. Cada um precisa virar um critério de aceite.
- Não escrever o que fica de fora. O silêncio vira expectativa, e expectativa não atendida vira conflito no fim do projeto.
Como o escopo vira cronograma
Com o escopo aprovado, cada item vira uma entrada do backlog, a lista priorizada do que será construído. Itens grandes são quebrados em partes que cabem numa sprint, e cada parte recebe o seu critério de aceite.
O cronograma sai da combinação de três coisas: o tamanho de cada item, a ordem de prioridade e as dependências, como a integração que precisa existir antes do relatório que usa os dados dela. Design, desenvolvimento e infraestrutura se sobrepõem, então o cronograma não é uma fila. Detalhamos o que mais pesa no prazo em quanto tempo leva para desenvolver um sistema sob medida.
No nosso método de trabalho, escopo, premissas, riscos e cronograma ficam registrados na reunião de abertura, e o escopo é aprovado formalmente antes do design. Depois, cada sprint começa com o planejamento das prioridades e termina com a demonstração do que foi construído. É assim que, no desenvolvimento de software sob medida, o acordo escrito vira sistema em uso.