Para muchos esta regla del 80-20 o Ley de Pareto, será una vieja conocida. Es un principio natural de distribución de recursos, que se puede aplicar a prácticamente todos los ámbitos profesionales y de la vida en general. El propio Wilfredo Pareto la enunció en 1906 para dar un soporte teórico a sus comprobaciones empíricas según las cuales el mundo se dividía entre los “pocos de mucho” y los “muchos de poco”, haciendo referencia a que en una sociedad se establecía un reparto natural según el cual el 20% de la población ostentaba el 80% de la riqueza y el 80% restante sólo poseía el 20% de esa riqueza.  Aquí tenéis buenos ejemplos de este principio de Pareto aplicado a la vida real.

Este principio del 80-20 ha sido de gran ayuda a lo largo del siglo XX en ámbitos sociológicos y económicos, a destacar: logística (distribución de mercancías), control de calidad, macro y micro-economía, time-planning, labores comerciales (¿a que a todos os pasa que el 20% de los clientes os genera en torno al 80% de vuestra facturación?). Es un principio natural, no hay que darle más vueltas. Pero sí hay que conocerlo para poder ser más eficientes. No tiene sentido en una empresa dedicar el mismo esfuerzo a todos los clientes, siempre hay unos pocos clientes que te generan gran parte de tu facturación y, obviamente, es a esos a los que debes prestar atención. Por cierto, que esta ley empírica se cumple aunque trates de eliminar ese 20%, pues entonces, se producirá una redistribución que volverá a hacer que se cumpla este principio.

Obviamente, debemos quedarnos con la idea subyacente y no buscar la diferencia numérica de si en tu empresa el reparto es 77-23% o si en la de un conocido es 82-18%. Desde que el bueno de Wilfredo Pareto enunció su teoría, se ha demostrado ser muy aproximada a la realidad.

Y hasta aquí la teoría común al Principio de Pareto. Una auténtica joya. Pero ahora, vamos a aplicarlo al mundo móvil que es el que a nosotros nos preocupa. Desde los principios de la informática se ha venido observando el cumplimiento de esta ley, estos podrían ser algunos de sus enunciados:

– el 80% del tráfico es generado por el 20% de las pantallas

– el 80% de los fallos es generado por el 20% del código fuente

– el 80% del esfuerzo de desarrollo (en tiempo y recursos) produce el 20% del código, mientras que el 80% restante es producido con tan sólo un 20% del esfuerzo

Pero como todo en el mundo de la informática y las nuevas tecnologías, tiene sus particularidades. Así, al último enunciado le ha salido un corolario, en tono cómico, pero que con frecuencia tiende a cumplirse. Se le conoce como la regla del 90-90 y dice así: “el primer 90% del código ocupa el 90% del tiempo de desarrollo. El 10% restante del código ocupa el otro 90% de tiempo de desarrollo”. Obviamente la suma sobrepasa el 100%, pero es que existe otra ley empírica que dice que en entornos de programación, cualquier planificación de tiempo y recursos nace condenada a no cumplirse. Y esto último sí que tengo observado que se cumple en el 100% de los casos. Es muy difícil hacer un planning ajustado de tiempo y recursos para un proyecto, pues todos tienden a extenderse. Más cuanto menos definido tiene el cliente sus necesidades y objetivos.

Conociendo toda esta teoría que se soporta en un análisis empírico de la realidad, vamos a ver cómo podemos luchar contra esto:

– Lo primero es analizar vuestra situación y definir una estrategia. No sólo vale con intentar salir atropelladamente de una mala experiencia. Así que sentaros con calma y pensad en cómo revertir la situación dados vuestros propios condicionantes. Nadie va a conocer vuestro negocio mejor que vosotros mismos. Al menos, ¡no debería!

– Si vuestro problema está en cómo presupuestar correctamente, es posible que tengáis que cambiar la forma de presupuestar, y pasar a métodos más ágiles y abiertos. Presupuestar por horas trabajadas, puede ser la fórmula mágica para ti, pero claro, habrá muchas empresas, sobre todo los pequeños proyectos, que no quieran afrontar una propuesta (obviamente es porque saben que te van a exprimir dentro de un presupuesto cerrado, pero esto puede llevarte incluso a perder dinero si dedicas excesivas horas extra a ese proyecto). Y aquí, es donde hay que tomar decisiones: presupuesto cerrado a riesgo de perder dinero, o presupuesto por horas a riesgo de perder clientes. O quizá seas capaz de hacer un híbrido, cerrando una funcionalidad básica, y a partir de ahí, trabajar según horas o bolsas de horas consumidas.

Así que tendréis que arriesgar un poco, para que todos salgáis beneficiados: el método lean. Se está empezando a consolidar esta forma de trabajo, por la cual se establecen unas metas en la forma de trabajo, con objetivos a corto plazo, por ejemplo, metas semanales. Se organizan en forma de sprints, y en el caso de desarrollo de aplicaciones móviles puede ser que en una semana queráis desarrollar la pantalla de Home. Se desarrolla, se entrega al cliente para que la valide, la prueba (si ya es funcional) y ve los cambios que quiere realizar. A medida que avanza el proyecto, el cliente puede probar funcionalidades e iterar sobre ellas, hacer casos prácticos de uso, programar cambios en base a feedback, etc. Y todo ello de una forma más ágil y con mejores resultados prácticos. Y lo que es mejor, como desarrollador, estarás cobrando por el trabajo realizado, así que por lo menos, podrás obviar la regla del 90-90…

– Si vuestro problema está en la comercialización, tened muy en cuenta la Ley de Pareto. Si de verdad vuestro trabajo es bueno pero no da fruto, es posible que estéis centrando vuestros esfuerzos comerciales en ese 80% de clientes que sólo reporta el 20% de los beneficios. Así que os toca analizar muy bien el mercado y tratar de identificar ese 20% que os reportará mayores beneficios. Nadie dijo que fuera fácil…

– Si tenéis problemas de errores en el código o con el testing, tendréis que prestar mucha atención a Pareto y tratar de identificar en qué punto está fallando el código. Si detectáis que un porcentaje pequeño de código o de pantallas son los que os están trayendo problemas, entonces tendréis que pararos a pensar si ese 20% de pantallas/código es prescindible porque está empeorando la experiencia de los usuarios y os está haciendo perder mucho tiempo.

Y como todo en la vida, siempre hay alguien que opina lo contrario y dice que el principio de Pareto ha muerto.

Share this post: on Twitter on Facebook on Google+