Waterfall

Waterfall — ou modelo em cascata — é uma abordagem de gestão de projetos em que o trabalho avança em fases sequenciais, cada uma completada antes da próxima começar. Levantamento de requisitos, design, desenvolvimento, testes, implantação: cada etapa tem entradas definidas, saídas definidas e uma transição formal antes de seguir adiante.

É a forma mais antiga e mais criticada de gerenciar projetos de tecnologia. Também é, dependendo do contexto, a mais adequada. O debate entre Waterfall e metodologias ágeis produz mais calor do que luz — porque a escolha certa depende do projeto, não da moda.

Waterfall nasceu num contexto onde fazer errado custava muito. Em construção civil, manufatura e engenharia de hardware, os custos de mudança aumentam dramaticamente conforme o projeto avança. Mudar a planta depois que as fundações foram concretadas não é apenas difícil — é caro a ponto de comprometer o projeto inteiro.

Nesse contexto, a lógica sequencial faz sentido: investir tempo na fase de planejamento reduz o custo de erro nas fases subsequentes. Se os requisitos foram levantados com rigor, o design foi revisado antes da execução e os testes foram planejados antes da construção, a probabilidade de retrabalho caro é menor.

O modelo pressupõe que os requisitos são estáveis — que é possível saber, no início do projeto, o que o resultado final precisa ser. Essa é a premissa que limita sua aplicabilidade em projetos onde o entendimento do que é necessário evolui ao longo do processo.

Funciona bem quando: O escopo é fixo e bem compreendido desde o início. Os requisitos não vão mudar significativamente durante o projeto. O custo de mudança tardia é alto — como em projetos de infraestrutura, hardware, ou integrações complexas de sistemas. A equipe está distribuída geograficamente e a coordenação exige documentação formal. Há exigências regulatórias ou contratuais que requerem rastreabilidade de cada etapa.

Funciona mal quando: O cliente não sabe exatamente o que quer no início — o que é comum em produtos digitais e projetos de inovação. O ambiente muda durante a execução, tornando requisitos iniciais obsoletos. O feedback do usuário final é necessário para refinar o produto. A equipe precisa de flexibilidade para aprender e adaptar ao longo do caminho.

O problema histórico com Waterfall em projetos de software não é a sequência em si — é a consequência de descobrir, na fase de testes ou implantação, que os requisitos levantados no início não refletiam o que o usuário realmente precisava. A correção nesse ponto custa múltiplas vezes mais do que teria custado no início.

A narrativa de que Waterfall é obsoleto e metodologias ágeis são sempre superiores é uma simplificação que causa problemas reais.

Agile funciona bem quando a equipe tem autonomia, os requisitos são emergentes e o cliente pode dar feedback contínuo. Quando essas condições não existem — cliente que só pode ser consultado formalmente, equipe terceirizada com contrato por entrega, requisitos regulatórios que precisam ser documentados — Agile cria ambiguidade onde Waterfall criaria clareza.

Muitos projetos que "falharam com Waterfall" na verdade falharam porque os requisitos foram mal levantados, não porque a sequência era errada. E muitos projetos que "falharam com Agile" falharam porque não havia product owner com disponibilidade real para dar direção contínua.

A metodologia é um instrumento. O resultado depende de como o instrumento é usado, não apenas de qual instrumento foi escolhido.

Uma vantagem concreta do Waterfall que raramente aparece nos debates é a qualidade da documentação que o modelo gera.

Por exigir que cada fase seja formalmente completada antes da próxima, Waterfall produz artefatos — especificações, designs aprovados, casos de teste, manuais — que ficam como registro do que foi construído e por quê. Em projetos onde a equipe de desenvolvimento não é a mesma que vai manter o sistema, essa documentação tem valor operacional real.

Em contrapartida, projetos ágeis frequentemente geram produto funcional com documentação mínima — o que cria dívida técnica quando o time original sai e alguém precisa entender o que foi construído.

Em PMEs e empresas familiares, projetos internos raramente têm a disciplina de escolher metodologia com consciência. O que acontece, na prática, é uma variação informal de Waterfall: define-se o que se quer, executa-se, e o feedback vem tarde — quando o resultado já está pronto e difícil de mudar.

O que falta não é necessariamente Agile. É estrutura de projeto em qualquer metodologia: escopo claro, responsabilidades definidas, pontos de validação ao longo do caminho. Projetos que falham em PMEs quase nunca falham por escolha errada de metodologia — falham por ausência de método, independente do nome que se dê a ele.

A escolha entre Waterfall e Agile é secundária à disciplina de gerenciar projeto com rigor. E rigor, aqui, significa: saber o que você está construindo, quem é responsável por cada parte, como você vai saber que está no caminho certo e o que você vai fazer quando não estiver.