Todo projeto de software começa com um escopo. Conforme o diretor de tecnologia, Jean Pierre Lessa e Santos Ferreira, em algum momento entre o kick-off e a entrega, esse escopo começa a crescer. Às vezes de forma declarada, com uma solicitação formal de mudança que passa por aprovação e ajuste de prazo. Na maioria das vezes, de forma silenciosa, com pequenas adições que individualmente parecem razoáveis e que coletivamente transformam um projeto de três meses em uma entrega que completa um ano sem previsão de conclusão. Esse fenômeno tem nome técnico, feature creep, e tem um traço característico: quando se torna evidente que o escopo saiu do controle, o dano já está feito.
Se você já terminou um projeto com o dobro do prazo original sem conseguir explicar exatamente o que aconteceu, ou se está no meio de uma entrega que parece não ter fim à vista, este artigo oferece o diagnóstico e o conjunto de ferramentas que faltaram na conversa que deveria ter acontecido antes.
Por que o escopo de projetos de software cresce e por que esse crescimento raramente é reconhecido a tempo?
De acordo com Jean Pierre Lessa e Santos Ferreira, o crescimento não controlado de escopo tem origens múltiplas que frequentemente atuam de forma simultânea, tornando difícil atribuir a responsabilidade a um único fator. Do lado do cliente ou do stakeholder, existe uma tendência natural a refinar a visão do produto à medida que o desenvolvimento avança e as primeiras versões se tornam tangíveis. O que era uma ideia abstrata no início do projeto ganha contornos concretos nas demos de sprint, e esses contornos frequentemente revelam gaps, oportunidades e melhorias que não eram visíveis quando o escopo foi originalmente definido. Essa dinâmica é saudável quando gerenciada, mas tóxica quando as solicitações de mudança são absorvidas sem ajuste correspondente no prazo ou no orçamento.
Do lado do time de desenvolvimento, o crescimento de escopo frequentemente começa com decisões de implementação que parecem pequenas, mas que criam precedentes. Um desenvolvedor que adiciona uma funcionalidade de log mais detalhada porque parece óbvio que vai ser necessário, ou que implementa um sistema de cache porque a performance vai precisar disso eventualmente, está tomando decisões de escopo sem processo formal. Multiplicadas ao longo de um projeto por vários membros do time, essas decisões individuais e bem-intencionadas podem representar semanas de trabalho não planejado que nunca aparecem em nenhum relatório de variação de escopo.
Segundo Jean Pierre Lessa e Santos Ferreira, o fator que torna esse problema especialmente difícil de diagnosticar é que cada adição individual de escopo parece justificável no momento em que é feita. É apenas quando se olha para o projeto de forma agregada, comparando o escopo atual com o escopo original, que o crescimento se torna visível. E esse olhar agregado raramente acontece com a frequência necessária para que as correções de curso sejam feitas enquanto ainda são viáveis. Quando alguém finalmente compara o que foi acordado com o que está sendo desenvolvido, o delta é tão grande que a discussão sobre o que fazer com ele é inevitavelmente difícil e frequentemente conflituosa.
Quais são os sinais precoces de que o escopo saiu do controle e como identificá-los antes do ponto de não retorno?
Como expõe Jean Pierre Lessa e Santos Ferreira, o primeiro sinal de alerta é a mudança no perfil das histórias de usuário que estão entrando no backlog. Quando a maioria dos itens adicionados ao backlog depois do planejamento inicial começa a vir de conversas informais, de e-mails sem formalização em ferramenta de gestão, ou de decisões tomadas em reuniões sem registro de impacto no escopo, o processo de controle de mudança está falhando. Um backlog saudável em um projeto com escopo controlado tem itens que são claramente rastreáveis ao escopo original ou a decisões formais de mudança com impacto documentado. Quando essa rastreabilidade se perde, o crescimento de escopo já começou.
O segundo sinal é a degradação progressiva da velocidade do time sem causa técnica identificável. Quando um time que entregava consistentemente uma certa quantidade de trabalho por sprint começa a entregar menos sem que haja mudança na composição do time, aumento de débito técnico óbvio ou problemas de infraestrutura, uma das explicações mais prováveis é que o trabalho real que está sendo feito é mais do que o que está sendo contado nas métricas de sprint. Itens que começam pequenos e crescem durante a implementação, retrabalho causado por requisitos que mudaram depois de começar o desenvolvimento, e trabalho não planejado absorvido informalmente são causas frequentes dessa degradação silenciosa.
O terceiro sinal é o desalinhamento crescente entre o que o gerente de projeto acredita que está no escopo e o que o time de desenvolvimento está efetivamente construindo. Quando, em uma reunião de status, o time menciona funcionalidades ou integrações que o gerente de projeto não tem no seu plano, e quando a resposta é que isso foi combinado em uma conversa com o cliente, o processo formal de controle de escopo está sendo contornado de forma sistemática. Esse desalinhamento, quando identificado cedo, pode ser corrigido com reforço de processo. Quando é identificado tarde, representa frequentemente semanas de trabalho não planejado que precisam ser reconciliadas com um prazo que não foi ajustado.
Quais práticas de gestão transformam o controle de escopo em ferramenta real de proteção da viabilidade do projeto?
A prática mais eficaz de controle de escopo é também a mais simples e a mais frequentemente negligenciada: manter uma definição de escopo documentada, acessível a todos os membros do time e do lado do cliente, e revisá-la explicitamente a cada vez que uma nova solicitação é apresentada. Essa revisão não precisa ser burocrática, mas precisa ser deliberada. A pergunta que precisa ser respondida para cada nova solicitação é direta: isso está dentro do escopo acordado, está fora e será feito com ajuste de prazo e custo, ou está fora e não será feito neste projeto? A ausência de um processo que force essa pergunta é o que cria o ambiente em que o escopo cresce sem ser percebido.
O diretor de tecnologia, Jean Pierre Lessa e Santos Ferreira, destaca que o uso de uma matriz de impacto de mudança é uma ferramenta prática que transforma a discussão sobre novas funcionalidades de uma negociação informal em uma análise objetiva. Para cada solicitação de mudança, a matriz documenta o esforço estimado de implementação, o impacto no prazo geral do projeto, o impacto no custo e as funcionalidades do escopo original que precisariam ser removidas ou postergadas para acomodar a mudança sem ajuste de prazo. Apresentar essa análise para o cliente ou stakeholder que solicita a mudança frequentemente muda a conversa de “pode adicionar isso” para “qual dessas coisas originais você prefere remover para que isso caiba no prazo”.
Autor: Diego Rodríguez Velázquez