Escopo de projeto: como definir e controlar

Escopo de projeto é a fronteira entre o que será feito e o que não será. A segunda metade dessa frase é a que decide o resultado, e é justamente a que quase ninguém escreve: quase todo projeto tem uma lista do que entra, e quase nenhum tem a lista do que fica de fora.

Este texto mostra as duas partes que um escopo precisa ter, o método para defini-lo, o que faz ele crescer sem ninguém decidir, como tratar mudança sem virar briga e os sinais de escopo mal definido.

O que é escopo, e as duas partes

Um escopo completo tem duas listas, e uma sem a outra não serve:

• O que será entregue, descrito pelo resultado e não pela tarefa. “Cliente consegue emitir a segunda via sozinho” é escopo; “desenvolver tela de segunda via” é tarefa, e as duas não são a mesma coisa.
• O que não será entregue, com o motivo e o momento em que aquilo pode voltar a ser discutido. Essa é a lista que evita a mesma conversa acontecer seis vezes.

Existe ainda um terceiro item que vive fora das duas listas e resolve muita discussão: o critério de pronto. Sem ele, “está pronto” vira opinião, e a entrega termina em uma reunião sobre percepção em vez de sobre fato.

Por que definir é difícil

1. O pedido muda quando a pessoa vê a tela. Não é falha de ninguém: requisito se descobre usando. Escopo que ignora isso apenas empurra a surpresa para o fim.
2. Quem pede não sabe o custo. Um item que parece pequeno pode ser o mais caro do projeto, e quem pede não tem como saber sem alguém dizer.
3. Cortar parece perda. Culturalmente, tirar item do escopo é lido como reduzir ambição, quando quase sempre é aumentar chance de entregar.
4. Existem muitos donos. Cada área acrescenta o que precisa e ninguém tem autoridade para remover.
5. A exceção é invisível. A regra principal leva um dia; as sete exceções que a empresa aplica levam duas semanas, e elas só aparecem no meio do trabalho.

O método em cinco passos

1. Comece pelo problema, não pela solução. Escreva em uma frase o que precisa parar de acontecer, com um número ao lado. Se ninguém consegue escrever essa frase, o escopo vai ser uma lista de desejos.
2. Escolha um único fluxo principal, do início ao fim. Um caminho completo vale mais que cinco pela metade, porque só o completo entra em uso.
3. Liste os cenários de exceção e decida um a um: entra agora, entra depois, ou é resolvido à mão. Decidir “resolvido à mão” é uma escolha legítima e barata.
4. Escreva o critério de pronto para cada item, no formato de algo observável. “O usuário conclui sem ajuda” é observável; “funcionando bem” não.
5. Estime em faixa e mostre o custo de cada item, porque escopo só é decidido de verdade quando quem pede vê o preço do que pediu.

Quando o projeto é a primeira versão de um produto, o recorte tem uma lógica adicional, que é responder uma dúvida com o mínimo, tratada em o que é MVP. E a conta de quanto cada recorte custa está em quanto custa desenvolver um produto digital.

A lista de exclusões

É a parte mais barata de escrever e a que mais economiza depois. Um exemplo de como ela se parece em um projeto de sistema:

Repare na terceira coluna. Ela transforma “não vamos fazer” em “vamos fazer quando”, o que muda a conversa de negativa para plano e reduz a resistência de quem pediu.

O que faz o escopo crescer

• Pedido pequeno sem custo declarado. “Já que estamos mexendo, coloca também” é a frase que transforma três meses em dezoito, um item por vez.
• Aprovação por comitê, em que cada rodada acrescenta e ninguém remove.
• Ausência de dono único com autoridade para dizer não.
• Contrato por hora, em que crescer o escopo não dói para quem executa.
• Descoberta legítima ignorada. Às vezes o escopo precisa mudar porque algo importante foi descoberto; o problema não é a mudança, é ela entrar sem trocar nada de lugar.

Como tratar mudança de escopo

Mudança não é problema; mudança sem contrapartida é. Uma regra simples resolve quase todos os casos:

1. Todo item novo entra com preço e prazo, ditos na hora do pedido e não no fim.
2. Entrou um, sai um, se o prazo não pode mudar. A escolha do que sai é de quem pediu, e essa devolução de responsabilidade encerra a maior parte das discussões.
3. Registre a decisão, em uma linha, com data e quem decidiu.
4. Revise o combinado a cada entrega, em vez de acumular mudanças para o final.

A dinâmica semanal saudável que sustenta isso, com algo navegável para ver toda semana, está em desenvolvimento de software. E do lado de quem executa, a responsabilidade sobre escopo é um dos critérios que separa fornecedores, em software house: o que faz e quando contratar.

Sinais de escopo mal definido

• Ninguém consegue dizer o que fica de fora. É o sinal mais confiável de todos.
• A estimativa é um número cravado, em vez de faixa com as variáveis que a alargam.
• O documento descreve telas, e não resultados esperados.
• Existe a palavra “etc.” na lista de entregas.
• Não há critério de pronto, então cada entrega termina em discussão de percepção.
• As exceções ainda não foram levantadas, e alguém vai descobri-las na terceira semana.

O escopo bem definido não é o mais detalhado: é o que deixa claro o que não será feito e o que conta como pronto. Esses dois itens custam uma tarde para escrever e evitam a maior parte dos conflitos de um projeto. Os critérios para avaliar quem vai executar dentro desse escopo estão em empresa de programação: 7 critérios para contratar, e o teste que antecede a construção em como validar um MVP.

Perguntas frequentes