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!
O que é isso?
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. 🙂
No início do artigo você mencionou que o Scope Creep também pode acontecer com desenvolvedores autônomos. Como assim?
Sim, e eu tenho um exemplo real para apoiar essa afirmação!
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 deixavam ou esqueciam de reportá-lo
- A funcionalidade, de alguma forma, funcionava para eles
- 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.
Mas, nas suas dicas de desenvolvimento, você motiva a implementação dessas funcionalidades!
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. Afunal, não queremos que nossos projetos entrem nas estatísticas negativas do Chaos Report, não é? 🙂
2 Comentários
Artigo interessante, alguns comentarios:
– Obviamente que se voce adiciona mais funcionalidade ao software, ele fica maior, mas nao necessariamente mais lento ou suscetivel a falhas. O fato do escopo do software aumentar nao necessariamente justifica queda de qualidade, ou menos testes monitorarando o bom funcionamento das funcionalidades. O desenvolvimento de software e’ amparado em 4 fatores de controle: custo, prazos, requerimentos e qualidade. E’ possivel manter-se a qualidade desde que o cliente esteja satisfeito em rever os outros 3 fatores acima mencionados;
– Adicionar funcionalidades sem a requisicao do cliente (como no seu exemplo da exportacao para o Excel) me parece mais uma questao de gold plating do que Scope Creep. Gold plating (nao sei como voces chamam ai no Brasil) diz respeito a continuar trabalhando em uma tarefa/projeto alem do ponto onde o esforco extra justifica o valor. Scope Creep seria se na metade do projeto o cliente houvesse de fato solicitado essa funcionalidade sem jamais haver discutido o assunto durante o comeco do projeto;
– Eu tenho que discordar na analogia de que o desenvolvimento de software se assemelha a engenharia civil. No seu exemplo, todo o predio e’ pensado e desenhado muito antes do trabalho comecar, pratica essa que nao funciona em software e muito menos em termos de Agilidade, onde o sistema e’ desenvolvido em pequenos incrementos, tendo o cliente por perto para validar o que esta sendo entregue.
um abraco,
Olá, Murilo.
Em primeiro lugar, obrigado pelo comentário e por expor o seu ponto de vista.
A respeito de suas observações:
– Quando mais funcionalidades são adicionadas no software, naturalmente surgem novas dependências, heranças e refatorações. Mesmo com um sistema efetivo de testes, é provável que novas falhas ocorram oriundas desse crescimento constante. Custos, prazos e requerimentos são importantes, mas eu defendo que a confiabilidade, integridade e desempenho também são fatores essenciais para a qualidade.
Além disso, à medida que novas funcionalidades são acrescentadas, o tempo de compilação dos módulos se torna maior e, consequentemente, o tamanho do executável e o tempo de carga do software também são afetados. O tempo de compilação pode refletir no prazo, e o tempo de carga pode ser um elemento de qualidade para o cliente.
– Scop Creep e Gold Plating são, como diz Kareem Shaker, dois lados de uma mesma moeda. Embora os conceitos sejam bastante similares, mencionei o exemplo da exportação para o Excel como um Scope Creep por ter impactado tanto no tempo de entrega quanto na qualidade do software (já que resultava em erros ao executá-la), ou seja, prejudicou o escopo de prazo do projeto.
– Murilo, no artigo, é importante observar que utilizo a palavra “assemelha” justamente para não afirmar que é igual. De qualquer forma, respeito sua opinião, mas discordo com o seu ponto de que a prática de desenhar o projeto não funciona no desenvolvimento de software. Já trabalhei em vários projetos nos quais só foram entregues no prazo por terem sido devidamente planejados (ou “desenhados”) antes das atividades de implementação. Na empresa em que trabalho atualmente, utilizamos Agile e essa cultura também se aplica. Toda concepção de projetos passa por um forte levantamento de requisitos, modelagem em UML, reunião de Kick-off e Holdmaps para cada integrante da equipe. Mesmo que o software seja desenvolvido em incrementos, já existe um alinhamento de todas as funcionalidades que serão desenvolvidas para cada fase do projeto, acompanhado de métricas e estimativas.
Abraço!