Las ventajas de las peticiones de funcionalidades o cómo dejar de pagar por cosas que no usas

Imagina una navaja suiza en la que los fabricantes han añadido el máximo número de herramientas, desde limas de uñas hasta alicates en la blockchain.
¿Cuántas de ellas se utilizarán en la realidad? ¿Están dispuestos los clientes a pagar por otras herramientas cuya única función es ocupar espacio y robarles el bolsillo? En este sentido, algunas aplicaciones de nivel empresarial son como navajas suizas en un cubo. Los fabricantes las llenan de todas las funciones posibles con una redundancia demencial, sin tener en cuenta las necesidades reales de los clientes. En este artículo, contaremos por qué la funcionalidad redundante es desventajosa para los usuarios y cómo evitarla.

El 90% de los consumidores de soluciones empresariales sólo utilizan el 5% de sus capacidades

El problema de los productos de nivel empresarial es la gran cantidad de funcionalidades redundantes que los desarrolladores les añaden. Y como cualquier solución necesita actualizaciones periódicas, añaden más y más funciones dirigidas a una pequeña parte del público objetivo.

Al mismo tiempo, los productos de nivel empresarial se caracterizan por una base de código compleja, elevados requisitos de fiabilidad, largo tiempo de desarrollo y largo periodo de explotación. Por ello, sus fabricantes no se esfuerzan por seguir las tendencias actuales de desarrollo, sino que apuestan por la estabilidad. A menudo, los desarrolladores de este tipo de productos desconocen las necesidades reales de los usuarios, porque no tienen en cuenta las peticiones de funcionalidad añadida de los consumidores reales.

Como resultado, no sólo hay funcionalidades redundantes, sino un conjunto de características que sólo necesita el 1-5% de los usuarios. Por ejemplo, la solución del gigante estadounidense VMware es un enorme constructor de funcionalidades, la mayoría de las cuales no son utilizadas por los consumidores de a pie. Y alrededor del 90% de los usuarios sólo necesitan el 5% de las características de la plataforma.

La ley de Parkinson más la ley de Moore

La ley de Parkinson establece que cualquier actividad lleva todo el tiempo que lleva. Del mismo modo, el software de nivel empresarial puede aumentar las funciones hasta ocupar todos los recursos disponibles.

Durante mucho tiempo, la Ley de Moore fue paralela a la Ley de Parkinson. Según la Ley de Moore, cada dos años se duplica el número de transistores en los chips. Esto significaba que los fabricantes de software no tenían que pensar si había suficiente rendimiento para ello. Así que añadían más y más funciones sin tener en cuenta las capacidades del hardware. Sin embargo, la Ley de Moore ya no funciona. Mientras tanto, los principales fabricantes siguen lanzando software con funciones redundantes. Esto puede deberse a varias razones:

• debido a la falta de gestión de las solicitudes de funcionalidad añadida de los clientes, el desarrollador no conoce las necesidades reales de la mayoría de sus clientes;
• los clientes son demasiado diferentes y cada uno de ellos necesita funciones distintas;
• es importante que el vendedor lance actualizaciones periódicas, añadiendo cualquier funcionalidad que no estuviera ya en la aplicación.

Qué hay de malo en la funcionalidad redundante

Parece que mucho no es poco. Qué hay de malo en que un producto contenga alguna funcionalidad redundante que pueda ser necesaria en el futuro? Hay varias razones para evitar la funcionalidad redundante.

En primer lugar, este tipo de productos son más difíciles de usar y de entender. Se necesitan varios especialistas de alto nivel para trabajar con un gran número de funciones. Además, un programa con funciones redundantes pierde ligereza. Es más difícil de manejar, necesita más recursos y el precio de una solución de este tipo será superior al de sus análogos. Al mismo tiempo, los clientes pagan dinero por funciones que nunca o casi nunca utilizarán.

La solución es YAGNI y pide añadir nuevas funcionalidades

«Implemente sólo las funciones que realmente necesita, no las que necesitará en el futuro».
Ron Jeffries, coautor de Programación Extrema y el Manifiesto Ágil.

En respuesta al problema de implementar funcionalidad redundante, nació el concepto de YAGNI. El acrónimo significa You ain’t gonna need it (No lo vas a necesitar) o «You won’t need it» (No lo necesitarás). En el núcleo del principio YAGNI está el rechazo de la funcionalidad redundante en el desarrollo de software como uno de los valores fundamentales del producto. El desarrollador sólo añade al producto las funcionalidades que son realmente necesarias.

Una forma sencilla de entender qué funcionalidad será relevante para los consumidores es procesar sus peticiones de añadir nuevas funciones.

Por ejemplo, en nuestro proyecto apostamos por la sencillez y ligereza de la solución. Los usuarios deciden por sí mismos si necesitan tal o cual funcionalidad. Se activan las funcionalidades que necesitan y las que no. Sólo se les cobrará por lo que realmente utilicen, no por todo el paquete. Si un cliente necesita alguna funcionalidad extra, puede hacer una solicitud para añadir una nueva funcionalidad y obtenerla individualmente.

Este enfoque permite a la empresa ahorrar dinero en funciones no utilizadas y seguir obteniendo toda la funcionalidad que necesita.