Os benefícios das solicitações de recursos ou como parar de pagar por coisas que você não usa

Imagine um canivete suíço no qual os fabricantes adicionaram o número máximo de ferramentas, de lixas de unha a alicates, no blockchain.
Quantas delas serão usadas na realidade? Os clientes estão dispostos a pagar por outras ferramentas cuja única função é ocupar espaço e tirar seus bolsos? Nesse sentido, alguns aplicativos de nível empresarial são como canivetes suíços em um cubo. Os fabricantes os preenchem com todas as funções possíveis e com uma redundância insana, sem levar em conta as necessidades reais dos clientes. Neste artigo, explicaremos por que a funcionalidade redundante é desvantajosa para os usuários e como evitá-la.

90% dos consumidores de soluções empresariais usam apenas 5% de seus recursos

O problema dos produtos de nível empresarial é o grande número de recursos redundantes que os desenvolvedores adicionam a eles. E como qualquer solução precisa de atualizações regulares, eles adicionam cada vez mais recursos destinados a uma pequena parte do público-alvo.

Ao mesmo tempo, os produtos de nível empresarial são caracterizados por uma base de código complexa, requisitos de alta confiabilidade, longo tempo de desenvolvimento e longo período de exploração. Portanto, seus fabricantes não se esforçam para acompanhar as tendências atuais de desenvolvimento, mas confiam na estabilidade. Muitas vezes, os desenvolvedores desses produtos não conhecem as necessidades reais dos usuários, pois não levam em conta as solicitações de funcionalidade adicional dos consumidores reais.

Como resultado, não há apenas funcionalidade redundante, mas um conjunto de recursos que apenas 1-5% dos usuários precisam. Por exemplo, a solução da gigante americana VMware é um enorme construtor de recursos, a maioria dos quais não é usada por consumidores comuns. E cerca de 90% dos usuários precisam de apenas 5% dos recursos da plataforma.

Lei de Parkinson mais a lei de Moore

A Lei de Parkinson afirma que qualquer atividade leva todo o tempo necessário. Da mesma forma, o software de nível empresarial pode aumentar os recursos até que eles ocupem todos os recursos fornecidos.

Durante muito tempo, a Lei de Moore foi paralela à Lei de Parkinson. De acordo com a Lei de Moore, a cada dois anos, o número de transistores nos chips dobra. Isso significava que os fabricantes de software não precisavam pensar se havia desempenho suficiente para isso. Assim, eles adicionavam cada vez mais recursos sem levar em conta os recursos do hardware. No entanto, a Lei de Moore não funciona mais. Enquanto isso, os principais fornecedores continuam a lançar softwares com funcionalidades redundantes. Pode haver vários motivos para isso:

• devido à falta de tratamento das solicitações de funcionalidade adicional dos clientes, o desenvolvedor não conhece as necessidades reais da maioria de seus clientes;
• os clientes são muito diferentes e cada um deles precisa de funções diferentes;
• é importante que o fornecedor lance atualizações regulares, adicionando qualquer funcionalidade que ainda não esteja no aplicativo.

O que há de errado com a funcionalidade redundante

Parece que muito não é pouco. O que há de errado em um produto que contém alguma funcionalidade redundante que pode ser necessária no futuro? Há vários motivos para evitar a funcionalidade redundante.

Primeiro, esses produtos são mais difíceis de usar e de entender. São necessários vários especialistas de alto nível para trabalhar com um grande número de funções. Além disso, um programa com funções redundantes perde sua leveza. Ele é mais difícil de operar, precisa de mais recursos e o preço dessa solução será mais alto do que o dos análogos. Ao mesmo tempo, os clientes pagam por recursos que nunca ou quase nunca usarão.

A solução é YAGNI e solicita a adição de novos recursos

“Implemente somente os recursos de que você realmente precisa, não os que você precisará no futuro.”
Ron Jeffries, coautor de Extreme Programming and the Agile Manifesto

Em resposta ao problema da implementação de funcionalidades redundantes, nasceu o conceito de YAGNI. O acrônimo significa You ain’t gonna need it (Você não vai precisar disso) ou “You won’t need it” (Você não vai precisar disso). No centro do princípio YAGNI está a rejeição da funcionalidade redundante no desenvolvimento de software como um dos principais valores do produto. O desenvolvedor só adiciona ao produto os recursos que são realmente necessários.

Uma maneira simples de entender qual funcionalidade será relevante para os consumidores é processar suas solicitações para adicionar novos recursos.

Por exemplo, em nosso projeto, apostamos na simplicidade e na leveza da solução. Os usuários decidem por si mesmos se precisam deste ou daquele recurso. Os recursos de que precisam podem ser ativados e os que não precisam podem ser ativados. Você só será cobrado pelo que realmente usar, não pelo pacote inteiro. Se um cliente precisar de alguma funcionalidade extra, ele poderá fazer uma solicitação para adicionar uma nova funcionalidade e obtê-la individualmente.

Essa abordagem permite que a empresa economize dinheiro em recursos não utilizados e ainda obtenha todas as funcionalidades de que precisa.