Como você lida com requisitos em mudança?

Question

Accepted Answer

Requisitos mudam — mercados se movem, você aprende com usuários, prioridades mudam. O objetivo não é *evitar* mudança (isso é tanto impossível quanto indesejável) mas lidar com ela **deliberadamente** para que melhore o produto em vez de descarrilar o projeto.

## Embrace change, but control it

```text
✓ EXPECT change → build flexibility into plans (don't over-commit far ahead)
✓ ASSESS each change → impact on scope, timeline, cost, other work
✓ Make the TRADE-OFF visible → "yes, but it costs X or pushes Y"
✓ Let the stakeholder DECIDE with full information
✓ COMMUNICATE the new plan to everyone affected
```

A disciplina-chave é a mesma que na gestão de escopo: nunca absorva uma mudança silenciosamente. Toda mudança é um trade-off consciente que alguém possui.

## Por que Agile ajuda

Agile foi construído para requisitos em mudança: iterações curtas significam que você re-prioriza frequentemente, então uma mudança espera no máximo um sprint em vez de desorganizar um plano de um ano. Trabalhar em incrementos pequenos limita quanto retrabalho qualquer mudança única pode causar.

## Distinguir descoberta de churn

```text
HEALTHY change → new learning, better understanding of the problem
UNHEALTHY churn → indecision, unclear goals, no one owning priorities
```

Se requisitos mudam constantemente, o problema real está upstream — objetivos vagos ou priorização fraca — e é isso que você precisa corrigir.

## Um exemplo concreto

No meio do sprint, pesquisa com usuários revela que o fluxo planejado confunde as pessoas. Em vez de prosseguir, você avalia: refazer custa três dias e adia um item de menor prioridade. Você apresenta esse trade-off, o PM concorda, e você se ajusta — uma mudança que tornou o produto *melhor*, tratada sem caos.

## Um armadilha comum

Ou recusar rigidamente toda mudança (entregar algo que você *sabe* que está errado) ou aceitar toda mudança sem avaliação de impacto (atraso crônico e burnout).

## Por que isso importa

A capacidade de se adaptar é uma força — software que não pode mudar é software que está lentamente se tornando obsoleto.

Lidar bem com mudanças (avaliar, tornar trade-offs visíveis, comunicar, trabalhar em incrementos) permite que você permaneça responsivo à realidade sem perder o controle da entrega.