Planejamento, Cronograma e Custos
Escopo de projeto de software: como definir e documentar
O escopo do projeto de software costuma ser o documento mais otimista do planejamento. Uma linha diz "integração com o sistema financeiro", outra diz "painel de indicadores", e cada pessoa preenche o resto com o que imagina. Como o produto é intangível, ninguém percebe a diferença entre as versões até a homologação, quando o cliente pergunta onde está o relatório que ele considerava óbvio.
Software tem três armadilhas próprias. A primeira é que pedir "só mais um campo" parece barato, e por isso os pedidos se acumulam. A segunda é que boa parte do trabalho não aparece na tela: integrações, migração de dados, segurança, ambientes, implantação. A terceira é que muitos requisitos só ficam claros quando o usuário usa a primeira versão. Um bom escopo trata as três: deixa os limites explícitos, inclui o trabalho invisível e diz como o detalhe será refinado.
O conceito geral de escopo, válido para qualquer projeto, está no artigo sobre o que é escopo do projeto. Abaixo está a aplicação em software, passo a passo, com um exemplo que acompanha cada etapa e um modelo de declaração para copiar.
Formação relacionada
Microsoft Project Professional
Cronogramas confiáveis, linha de base, controle de desvio e relatórios que sustentam decisão de diretoria.
O que o escopo de um projeto de software precisa responder
Duas camadas costumam ser misturadas. O escopo do produto descreve o que o software faz e como deve se comportar. O escopo do projeto descreve todo o trabalho para chegar lá, incluindo o que não é código. Para software, isso se traduz em seis perguntas:
| Pergunta | O que entra na resposta |
|---|---|
| Para que o software existe? | Objetivo de negócio com número e prazo |
| O que ele faz? | Requisitos funcionais, priorizados |
| Como ele precisa se comportar? | Requisitos não funcionais: desempenho, segurança, disponibilidade, acessibilidade |
| Com o que ele conversa? | Integrações, com sistema, sentido e frequência |
| O que vem junto? | Migração de dados, ambientes, treinamento, documentação, suporte inicial |
| O que não será feito? | Lista explícita do que fica fora do escopo |
Se alguma dessas respostas estiver em branco, o escopo ainda não está definido, por mais páginas que o documento tenha.
O exemplo que acompanha os passos
O exemplo é ilustrativo: uma rede de seis clínicas de fisioterapia quer um sistema de agendamento online. Hoje os pacientes marcam por telefone, as recepcionistas passam boa parte do dia ao telefone e a taxa de faltas é alta porque não há lembrete. O projeto foi autorizado por um termo de abertura (o mesmo projeto aparece comentado no artigo sobre termo de abertura de projeto de software), com orçamento, marcos e um fornecedor contratado para o desenvolvimento.
Como definir o escopo do projeto de software em sete passos
Passo 1: parta do objetivo, não da lista de telas
O termo de abertura traz o objetivo: reduzir as ligações de agendamento e as faltas. Escreva esse objetivo no topo do escopo, porque ele é o critério para decidir tudo o que vem depois. Uma funcionalidade que não ajuda a reduzir ligações ou faltas precisa de outra justificativa para entrar.
Passo 2: levante os requisitos funcionais
Requisitos funcionais descrevem o que o sistema faz. Escreva cada um como uma capacidade verificável, não como uma tela:
- RF01: o paciente vê os horários livres por clínica, profissional e tipo de sessão.
- RF02: o paciente agenda, remarca e cancela sem ligar para a clínica.
- RF03: o sistema envia lembrete 24 horas antes da sessão, com opção de confirmar ou cancelar.
- RF04: a recepção vê a agenda do dia e marca presença ou falta.
- RF05: a coordenação define a grade de horários de cada profissional.
- RF06: o gestor vê a taxa de faltas por clínica e por mês.
Passo 3: escreva os requisitos não funcionais com número
É aqui que muitos escopos de software falham. "O sistema deve ser rápido e seguro" não é requisito, é desejo. No exemplo:
- RNF01: a página de horários carrega em até 3 segundos numa conexão móvel comum.
- RNF02: o sistema funciona no navegador do celular, sem aplicativo instalado.
- RNF03: dados de saúde dos pacientes ficam acessíveis só a perfis autorizados, com registro de quem consultou.
- RNF04: disponibilidade no horário de funcionamento das clínicas, com janela de manutenção fora desse horário.
Cada número é uma decisão de custo: exigir disponibilidade de 24 horas muda a arquitetura e o contrato de suporte. Por isso os não funcionais se discutem com o patrocinador, e não ficam a critério do fornecedor.
Passo 4: corte o escopo do MVP
Com a lista na mão, separe o que precisa existir na primeira versão em produção. O escopo do MVP (produto mínimo viável) é o menor conjunto que já entrega valor e permite aprender com uso real. Uma forma prática é classificar cada requisito em quatro grupos, no estilo da priorização MoSCoW: precisa ter, deveria ter, poderia ter e não terá agora.
| Requisito | Prioridade | Entra no MVP? |
|---|---|---|
| RF01, RF02, RF04, RF05 | Precisa ter | Sim, piloto em uma clínica |
| RF03 (lembrete) | Precisa ter | Sim, por e-mail; mensagem por aplicativo na versão 2 |
| RF06 (indicadores) | Deveria ter | Não, versão 2 |
| Pagamento online da sessão | Não terá agora | Fora do escopo do projeto |
O que muda no MVP é a ordem, não o compromisso: os itens "deveria ter" continuam no escopo do projeto, numa entrega posterior. Já os itens "não terá agora" vão para a lista de exclusões.
Passo 5: escreva o que fica fora do escopo
A lista "fora do escopo" é a seção que mais evita discussão no aceite, porque registra o que alguém poderia razoavelmente supor que estava incluído. No exemplo:
- Pagamento online e emissão de nota fiscal.
- Aplicativo nativo para iOS e Android.
- Prontuário eletrônico e evolução clínica.
- Integração com operadoras de planos de saúde.
- Migração do histórico de agendamentos anteriores a janeiro de 2027.
Cada item excluído pode virar projeto futuro ou pedido de mudança. Estar fora não significa "nunca", significa "não com este prazo e este orçamento".
Passo 6: defina os critérios de aceite
Critérios de aceite dizem como cada entrega será aprovada. Para software, o formato contexto, ação e resultado funciona bem:
- RF02: dado um paciente com sessão marcada para daqui a 48 horas, quando ele cancela pelo link, o horário volta a aparecer como livre para outros pacientes em até 1 minuto e a recepção vê o cancelamento na agenda.
- RF03: dado um agendamento confirmado, o lembrete chega por e-mail entre 24 e 23 horas antes da sessão; em teste com 50 agendamentos, todos os lembretes são enviados.
Além dos critérios por requisito, defina o aceite de cada marco: quem homologa, em qual ambiente, com quais dados de teste e quantos dias tem para responder.
Passo 7: registre premissas, restrições e o trabalho invisível
Feche o escopo com o que não é funcionalidade, mas consome prazo e dinheiro:
- Premissas: cada clínica indica uma recepcionista para o piloto; a grade de horários de todos os profissionais é enviada pela coordenação até o início da construção.
- Restrições: o sistema roda na nuvem já contratada pela rede; o tratamento de dados pessoais segue a política de privacidade da empresa e a Lei Geral de Proteção de Dados (LGPD).
- Entregas não funcionais: ambiente de homologação, carga inicial de profissionais e horários, treinamento das recepcionistas, manual de uso de uma página para pacientes e 30 dias de suporte após a entrada em produção de cada clínica.
Esse trabalho invisível depois vira pacote na Estrutura Analítica do Projeto (EAP). O exemplo completo de uma EAP de produto digital, com o ramo de implantação e o de sustentação, está em EAP de projeto de software.
Modelo de declaração de escopo de software para copiar
DECLARAÇÃO DE ESCOPO DO PROJETO DE SOFTWARE
Projeto: [nome] Versão: [nº] Data: [dd/mm/aaaa]
Patrocinador: [nome] Gerente: [nome] Product Owner: [nome, se houver]
1. OBJETIVO DE NEGÓCIO
[resultado medível, prazo, referência ao termo de abertura]
2. REQUISITOS FUNCIONAIS (priorizados)
RF01 [capacidade] | prioridade | entrega (MVP, versão 2...)
3. REQUISITOS NÃO FUNCIONAIS (com número)
RNF01 [desempenho, segurança, disponibilidade, acessibilidade]
4. INTEGRAÇÕES
[sistema] | sentido dos dados | frequência | responsável pelo outro lado
5. ESCOPO DO MVP E DAS ENTREGAS SEGUINTES
[o que entra em cada versão e onde será implantado]
6. ENTREGAS QUE NÃO SÃO CÓDIGO
[migração, ambientes, treinamento, documentação, suporte inicial]
7. FORA DO ESCOPO
[lista explícita]
8. CRITÉRIOS DE ACEITE
[por requisito e por marco: quem homologa, onde, prazo de resposta]
9. PREMISSAS E RESTRIÇÕES
10. COMO O ESCOPO MUDA
[quem aprova mudança, onde se registra, como se trata o backlog]
Aprovação: [patrocinador] [gerente] [representante do fornecedor]
A seção 10 é a que os modelos genéricos esquecem. Em software, pedidos novos chegam toda semana, e combinar antes como serão tratados evita que cada um vire negociação.
Escopo fechado ou escopo que evolui?
Nem todo projeto de software pode fixar o detalhe no início. A escolha depende do contrato e da incerteza:
| Situação | Como tratar o escopo |
|---|---|
| Contrato de preço fixo, requisitos estáveis | Escopo detalhado e aprovado antes da construção; qualquer acréscimo passa por mudança formal |
| Produto novo, muita incerteza sobre o uso | Limites, objetivo e exclusões fixos; funcionalidades no backlog, refinadas a cada sprint |
| Contrato por hora ou por equipe alocada | Orçamento e prazo fixos, escopo priorizado continuamente pelo dono do produto |
O Guia do Scrum admite que o escopo da sprint seja esclarecido e renegociado com o Product Owner à medida que se aprende mais, sem comprometer a meta da sprint. Isso não dispensa o documento: mesmo num projeto ágil, alguém precisa ter escrito o objetivo, os limites e o que fica fora, ou o backlog cresce sem fim.
Erros que fazem o escopo de software estourar
- Integração descrita numa palavra. "Integrar com o ERP" pode ser um arquivo diário ou uma interface em tempo real nos dois sentidos. Escreva o sentido, a frequência e quem responde pelo outro sistema.
- Migração de dados esquecida. Quase todo sistema novo substitui alguma coisa. Decida o que migra, de que período e quem limpa os dados.
- Não funcionais deixados para depois. Desempenho e segurança definidos na homologação viram retrabalho.
- Funcionalidade a mais por iniciativa da equipe. Entregar o que ninguém pediu parece generosidade, mas consome horas do que foi pedido. O tema está em gold plating em projetos.
Documente o escopo do seu software
Pegue o termo de abertura do seu projeto e preencha primeiro três seções do modelo: objetivo, fora do escopo e critérios de aceite do MVP. São as que mais geram conflito quando ficam em branco, e preenchê-las com o patrocinador costuma revelar decisões que ainda não foram tomadas. Depois, ligue o escopo ao resto do planejamento com a ferramenta gratuita de plano do projeto da Projeto Diário, que junta num documento só o termo de abertura, a EAP, o cronograma, os riscos e os demais artefatos do projeto. Para ver como o escopo se encaixa no restante do planejamento, siga o guia completo de planejamento de projetos.
