archivo

Archivo de la etiqueta: principio de Pareto

En enero de 2001 en la revista IEEE Computer, Barry Boehm y Victor R. Basili publicaron un interesante artículo con el título: “Software Defect Reduction Top 10 List”.

En el mismo me llamó mucho la atención el siguiente dato (o estimación) que daban: “Entre el 40 y el 50% del esfuerzo en los proyectos se consume en retrabajo evitable”.

Es cierto que ha llovido mucho desde entonces pero también lo es que muchas malas prácticas siguen totalmente vigentes, entre otras cosas porque aunque el desarrollo de software trata de evolucionar conociendo y tratando los errores del pasado, el mensaje no llega en muchos casos ni en la etapa formativa ni en la laboral, ya que se enfocan las prioridades en otros objetivos.

Según los autores, este esfuerzo adicional es provocado por errores que se podían haber evitado desde el principio o que se deberían haber tratado lo más próximo posible a su origen.

En otra cita del mismo artículo, consideran que “aproximadamente el 80% del trabajo evitable proviene de un 20% de los defectos”. Como podéis ver es una aplicación del principio de Pareto a los defectos y al esfuerzo necesario para corregirlos.

Se trata por tanto, de trabajar con la detección de defectos cuanto antes, sabiendo que es prácticamente imposible detectarlos todos, prestando principal atención a los posibles defectos en áreas críticas del sistema tanto a nivel funcional como a nivel de arquitectura, y tratar de comenzar con su corrección lo antes posible, con el objeto de que su impacto sea el menor posible, no llegando a producción o no realizándose desarrollos sobre ellos que obliguen a rehacer o a retocar una mayor cantidad de código.

Muchos proyectos ven afectados su alcance final y su valor por el hecho de tener que invertir esfuerzo en actividades que perfectamente se podían haber evitado, seguro que personalmente conocéis muchos de ellos en los que llegado el momento habéis echado en falta algo más de presupuesto que os hubiera permitido darle a los mismos un mejor acabado.

La regla del 80-20 o principio de Pareto es peligrosa si nos dejamos contagiar por el optimismo que nos trae un progreso rápido en el desarrollo del producto.

No debemos olvidar que el avance es rápido porque no es necesario que se cierren todos los detalles y porque tareas problemáticas o que no terminan de salirnos se terminan dejando para más adelante.

Cuando crees que ya tienes casi todo y te olvidas de que todavía te queda mucho trabajo por hacer, corres el riesgo de caer en este antipatrón.

¿Cuándo surge? En el momento en que se pierde la tensión por parte del equipo (o del área usuaria) y/o cuando se decide dedicar menos esfuerzo al proyecto (porque, al fin y al cabo, está casi listo).

La consecuencia suele hacer mucho daño, porque ese 20% de ejecución restante se termina eternizando, requiriendo mucho más esfuerzo y afectando a las relaciones entre desarrolladores y usuarios, ya que la frustración será cada vez más evidente y las expectativas de cliente y proveedor cada vez estarán más lejos.

El principio de Pareto no suele fallar, el 80% del objetivo se consigue con el 20% del esfuerzo. Saber donde parar es importante, no solo por el ahorro económico sino también por la propia calidad del producto.

En cualquier caso, el producto final que satisface las expectativas del usuario estará por encima de ese 80% y ahí es donde el peso de los detalles crece exponencialmente.

Y si algo tiene el desarrollo de software son detalles, si algo marca la diferencia son los detalles. Un solo detalle, una sola instrucción mal codificada puede dar al traste con la implantación de un sistema en los plazos marcados y esto puede suponer mucho dinero y pérdida de confianza.

Charles Eames, en otro campo donde los detalles son importantes, como la arquitectura y el diseño, tuvo un gran acierto con la siguiente reflexión, perfectamente aplicable al desarrollo de software y a otros muchos ámbitos: “Los detalles son los detalles. Ellos hacen el producto”.

El principio de Pareto y los ciclos de vida iterativos e incrementales van de la mano.

Si con un 20% del esfuerzo se pueden alcanzar el 80% de los objetivos de un proyecto y se ha demostrado que funciona en numerosos casos, estamos ante la base para pensar que un sistema desarrollado siguiendo una metodología iterativa e incremental puede salir hacia adelante, ya que con las primeras iteraciones se podría llegar a tener un sistema donde sus principales y más críticos aspectos funcionales estén en funcionamiento y de forma aceptable. Después tocará ir añadiendo más utilidades e incluyendo mejoras a lo ya desarrollado.

Hay que tener en cuenta que lo comentado en el párrafo anterior requiere de situaciones ideales: que no existan contratiempos, proyecto bien dirigido, equipo de proyecto con actitud y aptitud, usuarios que colaboren y se impliquen, pocos errores y detectados lo antes posible, unos buenos procesos de acompañamiento al desarrollo, la selección de una metodología adecuada, etc…, no obstante y aún sabiendo que pocos proyectos de desarrollo se realizan en circunstancias ideales, el camino a seguir para que los proyectos salgan cada vez mejor y alejemos el fantasma de la crisis del software es la utilización de metodologías donde el desarrollo sea iterativo e incremental.

La Ley de Parkinson enuncia que: “el trabajo se expande hasta llenar todo el espacio de tiempo disponible para completarlo”.

Me parece muy interesante reflexionar sobre esto porque esta forma de actuar que es muy común en todos nosotros repercute directamente sobre nuestra productividad.

Esta Ley está intimamente ligada al Principio de Pareto, pese a que no habla de proporciones entre esfuerzo y resultado, ya que viene a decir que cuando no se dispone de fecha de fin para realizar una tarea o esta es superior a la que realmente necesitaría para realizarse, ésta tiende a dilatarse buscando conseguir mejoras que realmente aportan muy poco para el esfuerzo que requieren.

Por este motivo, es muy importante plantearse plazos realistas (no sobredimensionar) para realizar las tareas, si bien no todas, sí aquellas que sean repetitivas y aquellas otras que sean más urgentes o prioritarias en cada momento, de lo contrario, como nos sobra tiempo, terminaremos perdiéndolo, sacándole brillo a algo a lo que no le hace falta, revisando aspectos que no requieren revisión y en general, realizando actividades que no suelen servir para nada y que si bien nos puede hacer sentir activos, la realidad es que hubiéramos aprovechado mejor ese tiempo con otra tarea o simplemente viendo en la tele nuestra serie de televisión favorita.

Y lo peor de todo es que nos damos cuenta de que estamos perdiendo el tiempo y no le ponemos solución (¿o no hemos tenido esa sensación cuando por ejemplo estamos revisando una presentación y empezamos a añadirle o a cambiarle imágenes, a mirar si el texto está perfectamente alineado, si es mejor dividir una diapositiva en varias (o al revés), etc…?.

Es muy importante comprender que el esfuerzo por alcanzar la perfección no merece la pena, por un lado porque nunca vamos a llegar a conseguirla y por otro porque llegado un punto, para avanzar muy poquito hay que invertir un esfuerzo que no se corresponde con los logros que se van a obtener.

Otra aplicación del principio de Pareto lo tenemos en la Revelación de Sturgeon, derivado de una cita del autor de Ciencia Ficción americano Theodore Sturgeon que viene a decir: “Nada es absolutamente de esa forma”. A partir de ahí se generó la Revelación de Sturgeon cuyo enunciado es: “El noventa por ciento de la Ciencia Ficción es basura, bueno entonces, el noventa por ciento de todo es basura”.

Así de golpe la Revelación de Sturgeon puede parecer muy fuerte, porque de cumplirse vendría a afirmar por ejemplo que el 90% de los canales de la TDT son basura, que el 90% de la programación de televisión es basura, que el 90% de la política es basura o que el 90% de este blog es basura, este…, mejor no seguir dando ejemplos.

Este guiño que nos da la Revelación de Sturgeon como podemos apreciar no es más que una extensión más del Principio de Pareto y si bien podría considerarse como una curiosidad más, no está de más reflexionar un poco con ella teniendo en cuenta como afrontamos determinadas cosas, como también conviene reflexionar de vez en cuando teniendo en cuenta el Principio de Pareto.

El principio de Cargill también conocido como regla del noventa-noventa, se puede considerar como una aplicación de principio de Pareto y viene a expresar básicamente que es imposible el cumplimiento de la planificación de un proyecto o por lo menos las previsiones económicas y de esfuerzo del mismo ya que enuncia (y no hay ningún tipo de error al poner los porcentajes) que “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”.

Digo que no es ningún error porque el hecho de que el tiempo de desarrollo no sume 100% está hecho a posta. Este principio viene a indicar que poner a totalmente a punto una determinada aplicación llegado a un determinado grado de avance en el proyecto es treméndamente costoso y una de las principales causas de que no se cumplan las planificaciones en todos los sentidos (tiempo, esfuerzo, etc…).

Como en el caso del principio de Pareto, aqui la clave es saber cuándo se llega a ese 90% “mágico”, ya que a partir de ese momento el proyecto se pone muy cuesta arriba. También, como sucede con el principio de Pareto la habilidad, experiencia y metodología (además de as circunstancias del proyecto) de los responsables y del equipo de proyecto tienen mucho que ver en las posibles desviaciones que ocurran en el mismo.