Jean Pierre Lessa e Santos Ferreira, CTO com experiência em viradas de ERP e integração de aquisições, avalia que escopo malfeito raramente é escopo curto: é escopo detalhado no que não decide nada. Quarenta páginas de especificação convivem bem com um projeto que perde o rumo no segundo mês.
O caso a seguir é fictício e reúne situações comuns a projetos de porte médio. Uma rede com loja física e comércio eletrônico aprova a substituição do sistema de precificação, com prazo de sete meses e time de vinte pessoas entre desenvolvimento, dados e negócio.
A frase que abre o documento de abertura parece inofensiva: modernizar a precificação. Ela sobrevive a todas as aprovações justamente porque ninguém discorda dela, e o desacordo real só aparece quando o time precisa escolher o que construir primeiro.
Onde o escopo do projeto começou a escorregar?
No segundo mês, marketing pede que o sistema também calcule preço promocional por região. O pedido é razoável, cabe tecnicamente e entra sem discussão, porque nada no documento dizia que estava fora. Três semanas de trabalho mudam de lugar sem revisão de prazo.
O deslize não foi a inclusão, foi a ausência de critério para recusar. Quando o escopo é um enunciado de intenção, todo pedido compatível com a intenção parece pertencer ao projeto, e a fila cresce por adição silenciosa.
Jean Pierre Lessa e Santos Ferreira mostra que o sintoma aparece antes do atraso: o time passa a discutir prioridade em toda reunião semanal, sinal de que a fronteira do trabalho está sendo negociada de novo a cada ciclo, em vez de já ter sido acordada.
Definir escopo por resultado, não por lista de funcionalidades
Lista de funcionalidades responde o que será construído e nada diz sobre por que aquilo basta. Resultado observável faz o contrário: publicar alteração de preço em até cinco minutos em todos os canais, com registro de quem alterou, é um enunciado que alguém consegue verificar.
Por esse motivo, Jean Pierre Lessa e Santos Ferreira explica que o critério muda a conversa sobre pedidos novos: a pergunta deixa de ser se a funcionalidade é útil e passa a ser se ela aproxima ou afasta do resultado combinado. Preço promocional por região pode ser ótimo e não pertencer a este projeto.
Cada resultado precisa de uma condição de pronto escrita antes do início. Sem isso, a entrega vira questão de opinião no fim do prazo, quando o custo de discordar já é alto e a única saída disponível é adiar.
Escrever o que fica de fora vale mais do que listar o que fica dentro
A parte mais útil de um escopo costuma ser a lista de exclusões. Registrar que a integração com o sistema fiscal antigo não será refeita, que relatórios permanecem na ferramenta atual e que a migração de histórico entra em outra fase, encerrando dezenas de conversas futuras.
Do mesmo modo, premissas e dependências precisam de data e dono. Depender de um contrato com fornecedor, de dados de outra área ou de uma equipe compartilhada não é detalhe operacional: é risco de prazo com nome, e o escopo é o lugar onde isso fica visível.
Sobre o caso da rede, Jean Pierre Lessa e Santos Ferreira sugere um teste simples para o documento: se nenhum pedido plausível puder ser recusado com base no texto, o texto ainda não é escopo. Ele descreve uma vontade, não um limite.
Escopo é acordo de troca, não documento de abertura
Nenhum projeto de tecnologia atravessa meses sem mudança de contexto, e fingir o contrário produz documento que ninguém consulta depois da segunda semana. O que sustenta o escopo não é rigidez, é a regra de troca: cada inclusão aprovada retira algo equivalente ou move o prazo.
Essa regra converte discussão de vontade em decisão explícita. Quem pede passa a escolher o que sai, e a escolha volta ao patrocinador do projeto, não ao time técnico, que raramente tem autoridade para negar sozinho.
Um escopo bem escrito, ao final, protege menos o cronograma e mais a confiança entre áreas. Projeto que termina no prazo combinado com metade do prometido gera mais desgaste do que projeto que renegociou em voz alta na primeira mudança relevante.
