Checklist de escopo para software sob medida

Resposta direta: um bom escopo precisa definir o problema de negócio, os usuários, os fluxos críticos, as integrações e os critérios de sucesso — antes de falar em telas ou tecnologia.

A maioria dos projetos que estouram prazo e orçamento não tem problema técnico. Tem problema de escopo: começaram sem clareza do que precisa ser construído (e por quê).

Antes de começar: perguntas fundacionais

Antes de listar funcionalidades, responda:

• Qual problema de negócio estamos resolvendo? (não "quero um sistema de X", mas "minha equipe perde Y horas por semana fazendo Z manualmente")
• Como saberemos que deu certo? (métrica: tempo reduzido, erros eliminados, receita gerada)
• Quem vai usar? (perfis de usuário, frequência, contexto)
• O que acontece se não fizermos nada? (custo da inação)

O checklist

1. Contexto do negócio

• [ ] Problema principal descrito em 2-3 frases
• [ ] Impacto mensurável do problema (horas perdidas, receita perdida, erros/mês)
• [ ] Métrica de sucesso definida (o que muda quando o sistema estiver rodando)
• [ ] Prazo ideal e prazo máximo aceitável
• [ ] Budget disponível (mesmo que aproximado)

2. Usuários e acessos

• [ ] Lista de perfis de usuário (admin, operador, cliente, etc.)
• [ ] Volume estimado de usuários simultâneos
• [ ] Requisitos de acesso (desktop, mobile, ambos)
• [ ] Regras de permissão por perfil
• [ ] Autenticação necessária (e-mail/senha, SSO, 2FA)

3. Fluxos críticos

• [ ] Top 3-5 processos que o sistema PRECISA fazer bem
• [ ] Para cada fluxo: passo a passo de como funciona hoje (mesmo que manual)
• [ ] Regras de negócio e exceções conhecidas
• [ ] O que acontece quando algo dá errado (fallback)

4. Dados e integrações

• [ ] Sistemas existentes que precisam se conectar (ERP, CRM, planilhas, APIs)
• [ ] Dados que precisam ser migrados do sistema/processo atual
• [ ] Formato e volume dos dados existentes
• [ ] Frequência de sincronização (tempo real, batch, manual)

5. Requisitos não-funcionais

• [ ] Disponibilidade esperada (99.9%? horário comercial?)
• [ ] Performance (tempo de resposta aceitável)
• [ ] Segurança (LGPD, dados sensíveis, auditoria)
• [ ] Compliance regulatório (se houver)
• [ ] Backup e recuperação de desastres

6. O que NÃO faz parte (tão importante quanto o que faz)

• [ ] Funcionalidades que podem ficar para uma fase futura
• [ ] Sistemas que NÃO serão integrados agora
• [ ] Perfis de usuário que não serão atendidos na v1
• [ ] Plataformas que não serão suportadas inicialmente

O que NÃO colocar no escopo

• Telas desenhadas no PowerPoint (isso é UX — vem depois de entender o fluxo)
• Lista de tecnologias desejadas (deixe o time técnico decidir)
• Features copiadas de concorrentes sem validar se seu usuário precisa
• "Seria legal ter..." — se não resolve o problema core, não é v1

Como usar este checklist

1. Preencha sozinho primeiro — force-se a escrever, mesmo que incompleto
2. Revise com stakeholders — quem opera o processo diariamente corrige suas suposições
3. Compartilhe com o fornecedor — isso vira a base para a proposta técnica e comercial
4. Aceite que vai mudar — o escopo se refina no discovery. O checklist é ponto de partida, não contrato final

O papel do Discovery

Se você chegou até aqui e percebeu que muitas respostas estão em branco — não se preocupe. É exatamente para isso que existe a fase de Discovery: um trabalho pago (1-2 semanas) onde o time técnico te ajuda a completar esse checklist, validar viabilidade e gerar uma estimativa confiável.

Conclusão

Escopo bem definido é o melhor seguro contra projeto fracassado. Não precisa ser perfeito — precisa ser honesto sobre o que você sabe, o que não sabe e o que precisa descobrir. O resto é processo.