O que é scope creep e como evitá-lo em um projeto de software?

Scope creep é a expansão progressiva do escopo de um projeto de software além do que foi combinado originalmente, sem ajustar o prazo, o custo ou os recursos disponíveis. Acontece quando novos requisitos vão sendo somados —mais uma função, um ajuste "pequeno"— sem passar por um processo formal de aprovação, e cada adição isolada parece pequena demais para justificar renegociar o plano inteiro.

Não é a mesma coisa que uma mudança de escopo bem gerenciada: a diferença não está em se o escopo muda —quase sempre muda, em qualquer projeto real—, mas em se essa mudança fica documentada, tem seu impacto em prazo e recursos avaliado, e é aprovada pelas duas partes antes de ser executada. O scope creep é exatamente a mudança que entra sem passar por essa etapa.

Por que o scope creep aparece mesmo em projetos bem planejados?

A causa mais comum geralmente não é um pedido fora de lugar no meio do projeto —é o escopo nunca ter ficado totalmente fechado desde o início. O Pulse of the Profession 2018 do Project Management Institute (PMI), uma pesquisa com 5.402 organizações, encontrou que as três causas mais citadas de projetos que não cumprem seu objetivo são uma mudança nas prioridades do negócio (39%), uma mudança nos objetivos do projeto (37%) e uma coleta incorreta de requisitos no início (35%). Nenhuma das três é um capricho de última hora: são falhas de definição inicial que deixam a porta aberta para o escopo se esticar sem que ninguém registre isso como uma decisão.

Quanto custa o scope creep na prática?

Segundo esse mesmo levantamento do PMI, 52% dos projetos concluídos nos 12 meses anteriores tiveram scope creep —um salto expressivo frente aos 43% que a mesma pesquisa havia medido cinco anos antes. Não é um problema marginal nem exclusivo de projetos mal gerenciados: segundo esses dados, é o cenário mais comum, não a exceção.

Documentar o escopo no início é suficiente para evitá-lo?

Documentar o escopo no início ajuda, mas não basta sozinho. Os novos pedidos quase nunca chegam como uma proposta formal de mudança —chegam como um comentário solto numa call, um "já que você está aí, dá pra somar isso?"—, e sem um processo explícito para avaliá-los, cada um entra aos poucos sem que ninguém meça o efeito acumulado. O que funciona de forma consistente combina três elementos: um documento de escopo que deixa tão claro o que fica de fora quanto o que fica dentro, um processo de controle de mudanças em que cada pedido é avaliado antes de ser aceito —não depois—, e uma autoridade clara que aprova ou rejeita cada mudança em vez de deixá-la passar por consenso tácito.

O que muda com um critério de aceitação assinado por milestone?

Na Zenit, cada milestone começa com um critério de aceitação assinado pela empresa e pelo squad antes de a primeira linha de código ser escrita: o que aquele marco inclui, o que fica de fora, e qual evidência comprova que ele está pronto. Esse acordo cumpre, na prática, o papel do controle de mudanças que a maioria dos projetos improvisa no meio do caminho —se algo novo surge no meio de um milestone, não entra aos poucos: vira uma decisão explícita sobre se ele entra no milestone atual, com custo e prazo ajustados, ou no próximo.

Esse mecanismo ataca o sintoma —os pedidos que entram sem avaliação—, mas a causa de fundo, segundo os dados do PMI citados acima, costuma estar antes: em requisitos que nunca ficaram totalmente claros. O Kaizen entra justamente aí, no discovery anterior ao match: em vez de partir de um formulário que cada empresa preenche como consegue, ele acompanha as reuniões do time e monta um brief com escopo, milestones e decisões já documentadas antes de o squad começar a trabalhar —o mesmo tipo de definição antecipada que, segundo o PMI, é o que mais reduz o risco de o escopo se esticar sem controle.

O objetivo não é que o escopo nunca mude —quase todo projeto de software real aprende algo pelo caminho, e fingir que isso não vai acontecer é a forma mais rápida de acabar renegociando tudo de novo depois—, e sim que cada mudança seja uma decisão visível, avaliada, e não um acúmulo silencioso que ninguém decidiu de propósito.