El Principio de Pareto, también conocido como la regla 80/20 es uno de los principios más universales que existen. Es fácil encontrar ejemplos en lo que esta regla rige aspectos de nuestra vida personal, social y laboral.
En su versión más simple, el principio de Pareto dice que, en muchas situaciones, alrededor del 80% de los efectos son debidos al 20% de las causas. Este principio lo describió Vilfredo Pareto (de ahí el nombre), quién observó que la distribución de la riqueza sigue muy a menudo esta proporción (e.j. Vilfredo calculó que, en su época, el 80% de las tierras de Italia eran propiedad de sólo el 20% de la población). En este post argumentaba que seguir los consejos de Pareto nos sería muy útil para el diseño de chatbots. Pero de hecho, convertirnos en discípulos de Pareto nos ayudará en muchas de las decisiones de cualquier proyecto de desarrollo software.
Empecemos con la “instanciación” de la regla más genérica y más evidente de todas, además aplicable a cualquier tipo de negocio:
80% de los ingresos de un software vienen de sólo el 20% de sus clientes
Asegúrate que detectas muy pronto estos “buenos clientes” y que evolucionas el software para hacerlo cada vez más atractivo a sus necesidades.
Pero encontrarás aplicaciones de Pareto en cada fase de la Ingeniería de Software. Por ejemplo, al decidir las funcionalidades de la aplicación:
El 80% de tus usuarios se conformarían con el 20% del total de funcionalidades que has implementado
Fíjate que el concepto de MVP (mínimum-viable-product) es, de hecho, una aplicación de este principio. El problema es que, por desgracia, después de validar el MVP normalmente nos dejamos llevar y empezamos a hincharlo con muchísimas nuevas funcionalidades, la mayoría de ellas que nadie ha pedido (o que sí ha pedido pero nunca va a utilizar).
¿Para qué perder el tiempo creando, y aún pero, manteniendo, funcionalidades que (casi) nadie quiere? Mejor centrarse en optimizar aquellas que se utilizan a diario. Para descubrir cuáles son las funcionalidades esenciales (si llegas tarde y ya has implementado demasiadas), asegúrate de tener un componente de monitorización que te permita analizar y conocer mejor como tus usuarios utilizan tu software.
Pareto recursivo: El 64% (80% del 80%) de tus usuarios se conformarían con el 4% (20% del 20%) del total de funcionalidades que has implementado
Pero la influencia de esta regla va mucho más allá. Afecta también el diseño de la interfaz de usuario. Sí has cometido el error de implementar demasiadas funcionalidades, no hagas el doble error de meterlas todas en la interfaz, generado menús y listas de opciones monstruosas. No “castigues” a tus usuarios con toneladas de confusión sólo para el “outlier” que quiere hacer algo fuera de lo común (ten algún tipo de API o blackbox genérica para ellos). Y así podríamos seguir dando más y más ejemplos (ej: el número de integraciones con otras plataformas, de nuevo, no hace falta que tu software pueda “hablar” con todo el mundo, mira primero qué plataformas utilizan tus clientes y concéntrate en ellas).
El señor Pareto describió este principio hace más de 100 años pero sigue siendo la clave para optimizar algo tan actual como el desarrollo de software. Cuando tengas dudas sobre si tienes que implementar algo, piensa qué haría Pareto en tu lugar. Y por si te quedara alguna duda, recuerda que el intentar acabar un software es casi misión imposible con lo que mejor que acabes la parte importante:
“The first 90% of the code accounts for the first 90% of the development time. The remaining 10% of the code accounts for the other 90% of the development time.” – Tom Cargill
Últimos comentarios