Como definir o escopo de um projeto de software

Comece pelo resultado, em linguagem do negócio

O escopo descreve o que precisa funcionar, para quem e em quais condições. Você não precisa escolher linguagens de programação para iniciar essa conversa. Precisa explicar o problema atual e como reconhecer uma solução útil.

‘Queremos um sistema’ deixa muitas perguntas abertas. ‘Queremos que clientes acompanhem pedidos sem ligar para a equipe’ identifica uma tarefa e um resultado a investigar.

Um roteiro para o primeiro briefing

Responda com o que já sabe. Quando uma informação não estiver disponível, registre a dúvida em vez de tratá-la como uma certeza.

• Problema: o que acontece hoje e qual dificuldade precisa ser resolvida?
• Pessoas: quem usa e quem administra a solução?
• Jornada: qual tarefa deve ser possível concluir do início ao fim?
• Regras: quem pode ver, criar, aprovar ou alterar informações?
• Integrações: quais ferramentas e dados já existem?
• Prioridade: o que é necessário primeiro e o que pode esperar?
• Aceite: como sua equipe demonstrará que a entrega funciona?

Transforme uma ideia em critério de aceite

Exemplo hipotético: ‘O cliente deve acompanhar pedidos’. Um critério mais verificável seria: ‘Ao entrar, o cliente visualiza apenas seus pedidos, identifica o status de cada um e recebe uma mensagem clara quando não há pedidos disponíveis’.

Também descreva situações de erro relevantes, como indisponibilidade do sistema de origem. O objetivo não é escrever todos os detalhes antes de conversar, mas tornar visíveis as decisões que afetam a entrega.

Separe primeira entrega, evolução e dúvidas

Organize três listas: o que precisa funcionar primeiro, o que pode vir depois e o que depende de investigação. Uma primeira entrega deve permitir uma tarefa completa e útil, mesmo que tenha menos recursos.

Para um portal, consulta de pedidos pode vir antes de relatórios avançados. Porém, identificação do cliente e controle de acesso podem ser necessários desde o começo. A divisão precisa respeitar as dependências da solução.

Não envie credenciais ou dados de produção ao estimador. Descreva o contexto e use exemplos sem informações confidenciais. O resultado será uma faixa preliminar, a ser validada com a DevTrue.