archivo

Archivo de la etiqueta: Ley de Parkinson

Este antipatrón surge cuando se ha llegado a un punto en el que la mejoras a realizar en un determinado producto software o tarea requieren un esfuerzo mucho mayor que el valor que se obtiene con las mismas.

Las causas que pueden dar lugar a esto son muy variadas:

– Tareas sobreestimadas en las que los desarrolladores deciden ocupar todo el tiempo disponible en la misma (ver Ley de Parkinson).

– El intento de mejorar ciertos aspectos del producto o de los entregables del proceso que tienen un buen nivel de acabado y en donde introducir mejoras resulta complejo (ver Ley de Pareto).

– Inclusión de funcionalidades por parte de los desarrolladores o perfeccionamiento de las ya existentes, sin haber consultado con el área usuaria y que lo mismo no resultan necesarias o tienen un efecto negativo sobre las ya desarrolladas.

– Tratar de seguir realizando tareas sobre el proyecto para continuar facturando o para demostrar que se está ocupado: creación de necesidades inexistentes, inclusión de funcionalidades que se utilizan en muy contadas ocasiones y por un grupo reducido de usuarios, refactorización sin efecto o prácticamente sin efecto sobre la deuda técnica, etc…

Los efectos de este antipatrón no solo se centran en un mal aprovechamiento de los recursos disponibles (que de por sí ya es importante), sino en la inclusión de una mayor complejidad en el sistema, de nuevos posibles errores, de la modificación o creación de elementos documentales, etc…, cada uno de los cuales añade un coste adicional innecesario al sistema.

Que la naturaleza del desarrollo de software y su incertidumbre aconseje la aplicación de enfoques iterativos e incrementales no quiere decir que no se deba planificar, evaluar y controlar el trabajo que se hace, es más, es fundamental que estas actividades se realicen si se quiere llevar adelante el proyecto.

Pero, ¿es eso ágil? Puede serlo, como también puede no ser ágil no hacerlo. La agilidad es primero actitud, no lo olvidemos.

Cuando se desarrollo no se dispone de un presupuesto ilimitado, es más, desde mi punto de vista no es aconsejable (ley de Parkinson) tener un presupuesto excesivo (aunque sí holgado) sobre la base del trabajo previsto realizar (siempre habrá tiempo después de hacer ampliaciones si fuera necesario y estuviera justificado).

Por tanto, como es limitado se tiene que tener valorado lo que cuesta cada funcionalidad, requisito o historia de usuario que se quiera realizar y que los responsables funcionales aprueben de manera explícita cada uno de esos trabajos individuales con ese coste.

Es fundamental que eso se haga de esa manera, ya que siendo el feedback esencial para obtener un producto que satisfaga las expectativas del usuario, tiene un coste y el usuario debe ser consciente de él, para que sepa que la aproximación sucesiva al producto final tiene un coste y sus errores y falta de atención, también.

En todo este contexto, resulta esencial planificar, en primer lugar para que el desarrollo del software se realice con intención y se centre siempre en lo que resulte más prioritario e importante en cada momento y en segundo lugar para conocer cuándo va a estar disponible tal o cual funcionalidad o corregido tal o cual error.

Mi recomendación es que exista una planificación a alto nivel (bastaría con una priorización de dichas tareas, sin entrar en excesivo detalle) y que solo existiera una planificación detallada para las actuaciones a realizar a corto plazo. De lo contrario, el peso de mantener una planificación detallada más amplia requeriría un esfuerzo importante que habría que evaluar si compensa y si se disponen medios adecuados para tenerla actualizada.

Siempre estaré en contra de proyectos de desarrollo de software donde el presupuesto para realizarlo sea claramente inferior al necesario. Esto ha hecho mucho daño a nuestra profesión como también lo ha hecho proponer sistemáticamente ofertas muy por debajo del precio de mercado.

Mientras exista mayoritariamente crisis del software, con el máximo exponente en los Death March Project, nos costará darle a nuestro trabajo el valor que realmente tiene.

Los presupuestos en los proyectos deben ser holgados y esa holgura depende de la propia naturaleza de las tareas a realizar y del contexto en el que se desarrollen las mismas.

Al fin y al cabo los proyectos tienen siempre un coste de mantenimiento, la holgura es simplemente deslizar parte de ese presupuesto de mantenimiento al propio de desarrollo de manera que se pueda evolucionar el producto de manera adecuada, adaptándolo paulatinamente a las necesidades del usuario.

Pero, ¿cuándo un presupuesto es excesivo? Cuando la cantidad de trabajo que se realiza con él es inferior al acabado y calidad que debería tener el proyecto software en el contexto en que se ha realizado. Esto implica que podemos tener presupuestos excesivos incluso en proyectos donde el mismo es muy ajustado o incluso por debajo de lo necesario.

Más dinero no implica hacer las cosas mejor, la Ley de Parkinson es una muestra reveladora de lo que pasa cuando existe mucho presupuesto y no se enfoca adecuadamente el trabajo a realizar.

Son muchos autores los que consideran que la búsqueda de la solución perfecta en el desarrollo de software requiere de un esfuerzo exponencialmente superior al necesario para conseguir una buena solución, teniendo en cuenta además que la perfección es un concepto abstracto y que no se va a terminar de conseguir nunca.

En los proyectos desarrollo de software hay que buscar lo práctico, la Ley de Pareto es una regla muy útil y que debemos tener siempre en cuenta.

Otra regla muy interesante es la Ley de Parkinson en la que se indica que siempre que el proyecto esté abierto se tenderán a hacer tareas independientemente de la utilidad real de las mismas.

Otra referencia, la tenemos en el Principio 90-90 o de Cargill que al fin y al cabo es una versión de la Ley de Pareto adaptada al desarrollo de software.

Una solución “perfecta” requiere en muchos casos la introducción de una complejidad técnica y o funcional en el software que provocará precisamente el efecto contrario al que se está buscando. Es necesario huir de la complejidad o por lo menos de toda aquella que no sea necesaria para conseguir un producto que satisfaga las expectativas del usuario. David Gelernter define muy bien esta situación cuando comenta que: “La belleza es la última defensa contra la complejidad”.

La ingeniería del software no busca desarrollos perfectos sino que busca proyectos bien ejecutados. Los principios y metodologías ágiles persiguen lo mismo.

Bjarne Däcker, es un profesional que se merece todos mis respectos, empezó como programador en Ericsson en 1966, por lo que lleva 45 años en este negocio y es por ejemplo miembro de la Real Academia Sueca de Ciencias de la Ingeniría, sin embargo no estoy de acuerdo con su siguiente cita: “Un sistema software debería ser como una sinfonía de Mozart: Perfección en todos los niveles”.

Tal vez la ejecución final deseable de un sistema de información debería ser esa e incluso hay aplicaciones que gestionan sistemas críticos (aquellos en los que un fallo puede provocar pérdida de vidas o poner en peligro la continuidad de una organización) donde la calidad exigible a los resultados es muy alta.

Sin embargo, la búsqueda de esa perfección por sistema puede provocar que el proyecto entre en una espiral donde no salga beneficiado nadie.

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.