Como você gerencia scope creep em um projeto?

Question

Accepted Answer

**Scope creep**, o acúmulo constante de "só mais uma coisa", é como projetos no caminho certo deslizam silenciosamente. A solução não é dizer não a tudo; é tornar **cada adição uma compensação visível e explícita** contra tempo, em vez de uma absorção silenciosa.

## Como controlar o escopo

```text
✓ Define DONE up front — written, agreed scope
✓ Make the cost of every addition VISIBLE ("yes, and that pushes us a week")
✓ Track changes — a changelog of what got added/cut
✓ Protect a core MVP — defend the must-haves fiercely
✓ Use a PARKING LOT — capture good ideas for "later," don't reject them
✓ Escalate trade-offs to whoever owns priority — let them choose
```

## O movimento chave

Não recuse novas solicitações abertamente, isso o torna o bloqueador. Em vez disso, coloque a compensação em evidência: "Podemos adicionar isso. Significa que ou o prazo se move uma semana ou descartamos a funcionalidade X. O que você quer?" Agora é uma decisão *empresarial*, tomada pela pessoa certa, de olhos abertos.

## Um exemplo concreto

No meio do projeto, o PM continua adicionando pequenos ajustes. Você inicia um registro de mudança de escopo compartilhado. De repente, todos veem que o projeto original de duas semanas absorveu três semanas de adições, e a conversa sobre o prazo se torna óbvia e fácil.

## Por que isso importa

Scope creep não gerenciado é o assassino silencioso de prazos; nenhuma mudança única se sente grande, mas elas se somam em um fracasso.

Tornar as compensações explícitas mantém o time protegido, os stakeholders informados, e a culpa afastada da engenharia quando o escopo, não o esforço, foi a causa.