Scope Creep

Você sabia que, em uma pesquisa realizada há alguns anos, as estatísticas mostraram que 64% do software não é utilizado pelos usuários? O artigo de hoje discute justamente sobre esse fato e apresenta um termo que, mesmo não muito conhecido no jargão de TI, ocorre bastante nas empresas e também com desenvolvedores autônomos: Scope Creep!

Definição

Scope Creep é o termo utilizado para definir alterações incontroláveis em um projeto, como a implementação de funcionalidades desnecessárias ou que não foram solicitadas pelo cliente. Tais funcionalidades podem levar ao aumento do tamanho do software, tornando-o mais lento, como também deixá-lo suscetível a erros ou inconsistências. Acredito que muitos clientes já se depararam com erros no software produzidos indiretamente por funcionalidades que eles não usam!

O Scope Creep surge quando há uma falha na documentação de requisitos, comunicação entre os membros da equipe ou falta de experiência do gestor de projetos. Em determinado momento, o projeto sai dos trilhos e muitas funcionalidades passam a ser desenvolvidas sem justificativa. Na verdade, ninguém saberá afirmar se as funcionalidades foram, de fato, solicitadas pelo cliente, já que a documentação estará escassa. Nestes casos, o Scope Creep pode resultar no cancelamento do projeto ou na quebra de contrato.

Na minha opinião, as especificações iniciais do projeto são tão importantes quanto o produto final. Aliás, o produto final depende (muito) de como o projeto foi documentando inicialmente.

Imagine, por exemplo, que a planta de um edifício tenha sido projetada incorretamente, mas mesmo assim os operários começaram a construí-lo. Durante a construção, os trabalhadores e o chefe de obras encontraram vários problemas que não haviam sido identificados, causando mudanças repentinas na planta e na arquitetura do edifício. A partir desse momento, pouca coisa estará sendo feita como foi planejado no início, enquanto outras atividades, cujas não foram documentadas, serão realizadas, produzindo um Scope Creep. No final das contas, haverá uma possibilidade do cancelamento da construção ou, caso fique pronto, não será da forma como os investidores esperavam.

É curioso a forma como a engenharia civil se assemelha com o desenvolvimento de software. 🙂

Scope Creep no desenvolvimento de software

Certa vez, ao desenvolver um software de representação comercial, decidi implementar, por conta própria, uma funcionalidade de exportação do catálogo de produtos para o Excel. “Talvez um dia será útil para os usuários”, pensei. A questão é que, além de essa funcionalidade não ter sido solicitada pelo cliente, demorou um tempo considerável para ficar pronta, já que foi necessário estudar os métodos de exportação, formatar as células conforme os tipos de dados, tratar as exceções e fazer vários testes.

Pois bem, após 1 ano que o software estava em produção, dediquei um tempo para fazer um Code Review e algumas refatorações no código. Para minha surpresa, ao testar a exportação do catálogo de produtos, ela não estava funcionando! Um erro de Access Violation era exibido na tela ao clicar no botão de exportação. Logo me perguntei: “Como os usuários nunca me reportaram isso?”.
Bom, havia três possibilidades:

• O erro ocorria, mas eles ignoravam ou esqueciam de reportá-lo
• A funcionalidade funcionava para eles, talvez seguindo outra sequência de passos
• Eles nunca utilizavam essa tela

Para chegar à uma dessas conclusões, inseri um contador de acesso (hit count) na tela, ou seja, a cada vez que ela fosse aberta, o contador era incrementado e armazenado em um arquivo de log. Três meses depois, ao recolher o arquivo, me surpreendi ao ver que o contador estava ZERO! Os usuários realmente nem passavam perto dessa tela!

Portanto, removi essa funcionalidade do software, resultando em três vantagens: redução no tamanho do executável, redução na quantidade de classes e remoção do menu de exportação. Na realidade, essa funcionalidade nem deveria ter sido desenvolvida, já que não era contemplada no escopo do projeto, então, pode-se dizer que “desfigurei” o escopo, ou seja, causei um Scope Creep.

Conclusão

Para concluir: implementar funcionalidades desnecessárias é uma coisa. Aprimorar a experiência de usabilidade do usuário é outra. No meu caso, se os usuários utilizassem a exportação com bastante frequência, essa funcionalidade seria um grande diferencial. Algumas vezes, não precisamos necessariamente esperar a solicitação de determinadas funcionalidades no software, visto que o usuário não compartilha da mesma visão técnica que a equipe de desenvolvimento. Por outro lado, sugiro que, antes de implementar uma funcionalidade dessa natureza correndo o risco de provocar um Scope Creep, o usuário deve ser consultado. Para isso, existem técnicas como prototipação, brainstorming ou até mesmo entrevistas com o cliente.

Enfim, pessoal, Scope Creep é mais um problema recorrente no cenário de desenvolvimento de software e deve ser evitado com documentações bem definidas e um bom gerenciamento de projetos. Afinal, não queremos que nossos projetos entrem nas estatísticas negativas do Chaos Report, não é? 🙂

Até a próxima semana, leitores!