Ajedrez - antoniomartel.com

Archivos por Etiqueta: Pareto

The 80/20 Rule

How can we avoid featuritis and concentrate just on the tasks that will make us more efficient? Many years ago, approximately a century ago, someone called Pareto realised that 20% of the pea pods in his garden amounted for 80% of his crop. The remaining 80% of his pea pods amounted to the other 20% of his pea crop. Intrigued by this ratio, he also checked that he could use this rule to other fields. He went on to discover that, back then, 20% of the population had 80% of the income. The remaining 20% of the wealth was in the hands of the poorest 80% of the population. This principle, based in empirical knowledge, has been in use since then. It helps improve efficiency and productivity in economics, commercial distribution, marketing, engineering, and, naturally, in software development.
For example, we start to develop our product with a huge list of requirements and features as a base. Yet we know that only 20% of those features will be used 80% of the time. A large chunk of the remaining features will only be used 20% of the time. We can apply this principle to development time. Using it, we can deduce that if it takes us about 10 months to build a product, in 2 of those months we will be able to develop 80% of the features. Thus it would take us about 8 months to solve the remaining 20% of the most complex and difficult features. This leads us to ponder: will people use these features? Are they really indispensable?

Say we manage to identify the most important features, and we keep them as simple as we can. Wouldn’t we be able to dispense with 8 months of work and deliver a highly effective product in 2 months only? We already know that 20% of our effort will produce 80% of our results. Wouldn’t it be worthwhile to sit for a moment and think for a bit about what we should devote our time to? I’m sure it would.

You can find texts like this and many other about how to manage agile projects in my book Agile 101: Practical Project Management (available on Amazon).

Book on Scrum: Agile 101, Practical Project Management
Agile 101 – Practical Project Management

Translation by Begoña Martínez. You can also find her on her LinkedIn profile. Proofreading by David Nesbitt.

Las cosas se hacen bien pero no demasiado bien

Esa es una frase que escuche en una ocasión a un médico cuando la enfermera le preguntaba si debía usar un tipo u otro de catéter. Lo que quería decir el médico era que no había necesidad de usar el catéter más caro, complejo o difícil de poner si con el más sencillo lográbamos lo mismo.

Es una regla útil para aplicarla en nuestros proyectos de trabajo o personales. Nos pasa cuando vamos a entregar una propuesta o un presupuesto, cuando simplemente debemos enviar un email o un informe o cuando tenemos que entregar una nueva versión de nuestro producto.

A veces lo hacemos por un perfeccionismo excesivo que nos hace pensar que nuestro producto debe tener las mejores características del mercado en todas y cada una de las funcionalidades. Cuando acabemos habremos terminado orgullosos de él pero, qué coste tiene el producto si tiene el Wifi más avanzado, el Bluetooth de mejor rendimiento y el mayor número de puertos USB ¿te lo comprarán a ese precio?

Y cuando por fin hayas decidido poner el producto en el mercado después de tantos meses de trabajo puestos en él ¿se seguirá usando el Bluetooth? ¿el número de puertos USB seguirá siendo una decisión relevante en la compra? Probablemente no.

Quizás era mejor haber planificado una fecha de lanzamiento, el próximo Black Monday por ejemplo, y calcular qué opciones nos da tiempo de construir para entonces. Seguro que en el mercado habrá productos más completos pero ¿serán tan económicos como el tuyo? ¿son tan fáciles de usar o pesan tan poco como tu producto? ¿tus competidores estarán teniendo tanto margen comercial como tendrías tú?

Cuando Google lanzó su Google Docs en la nube, los periodistas especializados fueron corriendo a preguntar a Microsoft por esta nueva amenaza a su MS Word. Google Docs era gratis y podía usarse desde cualquier ordenador sin instalación o licencia alguna. Steve Ballmer contestó de manera un tanto despectiva que Google Docs nunca a sustituir su clásica suite Office. En la nueva aplicación de Google ni siquiera era posible imprimir los documentos que escribías.

La respuesta de Google fue rápida. Al día siguiente Google Docs tenía implementado un botón Imprimir en su barra de herramientas ¿Cómo pudo haber hecho esto Google tan rápido? Sencillo, Google Docs no tiene funcionalidades complejas. Sólo hay 5 ó 6 funcionalidades en un único menú. Son justo las funcionalidades que necesitan el 90% de los documentos que escribimos.

No había mucho que desarrollar tampoco había mucho que probar. Debieron usar una librería de exportación a PDF estándar que recoge las características básicas y listo. No hay complicadas opciones de numeración, viñetas, estilos, fuentes o formatos. Sería una librería muy probada para esas pocas opciones por lo que no había mucho donde fallar.

En tu trabajo diario te puede pasar lo mismo. Puedes estar días y días buscando una diferencia de 1 céntimo entre el Debe y el Haber, pero mientras, el informe de pérdidas y ganancias está sin hacer.

Puedes hacer un versión de tu software para iPad, para tablets, para smartphones, para Chrome, Firefox Internet Explorer y Safari. Mientras tanto alguien está ganando dinero ya con su app para el iPhone pero sobre todo sabrá ya a estas alturas si merece la pena sacar una versión para Android o si estará tirando su tiempo y su dinero si lo hace.

Evita la procastinación, el miedo a fallar o a las críticas si tu producto no es el mejor de todos los que hay en el mercado o no se vende bien. Si eso pasa, bueno, por lo menos no invertiste demasiado en ello. Ve a por el siguiente o trata de mejorarlo en una siguiente versión (Kaizen lo llamaría yo). Ahora ya sabes qué es lo que no funciona y podrás probar de nuevo.

Regla del 80/20

¿Podemos ser más productivos? ¿Cómo podemos centrarnos en las tareas que nos harán más eficientes? Hace muchos años, aproximadamente un siglo, un tal Pareto comprobó de forma casual que sólo el 20% de las vainas que tenía plantadas en el campo producían el 80% de los guisantes de su cosecha y que el 80% restante producían tan solo el 20% restante de los guisantes. Curioso por esta relación comprobó también que podía aplicar esta regla a otros campos descubriendo, por ejemplo, que en su época el 20% de la población disponía del 80% de la riqueza y que tan solo quedaba un 20% de la riqueza total para el 80% más pobre de la población.

Este principio, basado en el conocimiento empírico, es usado desde entonces para mejorar la eficiencia y la  productividad en la economía, en la distribución comercial, en el marketing, en las ingenierías y, como no, también en el desarrollo de software.

Cuando comenzamos a desarrollar nuestro producto basándonos en una lista enorme de requisitos y funcionalidades a desarrollar, sabemos que sólo el 20% de esas funcionalidades serán usadas por el 80% de los usuarios y que una cantidad enorme del resto de las funcionalidades que desarrollemos sólo será usada en un 20% de las ocasiones.

Aplicando también este principio al tiempo de desarrollo podemos deducir que si tardásemos alrededor de 10 meses en la construcción de un producto, en tan solo 2 de esos meses conseguiríamos desarrollar el 80% de las funcionalidades requeridas y que, por tanto, nos llevaría unos 8 meses resolver el 20% de las funcionalidades más complejas y difíciles. Esto nos lleva a preguntarnos ¿serán usadas esas funcionalidades? ¿son realmente imprescindibles?

Si lográsemos identificar las funcionalidades más importantes y las mantuviésemos los más simple que nos fuera posible (otro principio: KISS) ¿no lograríamos quitarnos de encima 8 meses de trabajo y entregar un producto muy efectivo en tan solo 2 meses?

Ya sabemos que el 20% por ciento de nuestro esfuerzo producirá el 80% de los resultados ¿no sería bueno sentarnos por un momento para pensar a qué le vamos a dedicar nuestro tiempo? Merecerá la pena, seguro.

Suscríbete