Desarrollo de software. Antipatrón. Factor de improbabilidad

Este antipatrón se produce cuando conociendo la existencia de un error en el sistema no se le presta atención o no se considera prioritaria su corrección al asumirse que la ocurrencia del mismo no ocasiona perjuicio al sistema, los usuarios, el servicio que se ofrece y/o la continuidad del negocio, sin haber realizado previamente un análisis del riesgo objetivo del mismo.

Los desarrolladores podemos considerar una incidencia como intrascendente y sin embargo para los usuarios y/o el negocio ser muy negativa. Hay que tener en cuenta que el producto no es para nosotros sino para un tercero y para unos propósitos concretos, por lo que nuestra opinión no es la única que vale a la hora de analizar el impacto e importancia de un error.

Si para el usuario todas las incidencias son urgentes y además también lo son los evolutivos a realizar, toca hacerlo bajar a la realidad de los recursos disponibles y de la metodología utilizada, no será fácil que lo entienda, pero no tendrá más remedio que priorizar.

Desarrollo de software. Antipatrón. Migración de coste

Antipatrón que hace mucho daño desarrollo de software, a las relaciones cliente/proveedor, a la gestión de una organización, a la gestión de proyectos y a las relaciones entre diferentes gestores dentro de una organización.

Pese a todo lo anterior, es un antipatrón ampliamente extendido y como tal seguro que lo hemos vivido en primera persona en alguna que otra ocasión.

Se trata básicamente en desviar los costes de una tarea de un proyecto o los costes de un proyecto a otro, con el objeto de que cuadren las cuentas en el caso de que las pérdidas o las ganancias resulten exageradas.

Aunque pueda parecer que al fin y al cabo, se trata de restar dos de aquí, para sumar dos allí y que el orden de los factores no altera el producto, ya que al fin y al cabo la suma de las pérdidas y las ganancias será la misma y que, por tanto, no pasa nada, sí que pasa.

¿Por qué tiene trascendencia? Pues porque se están manipulando los datos reales de los proyectos y de esta manera, cualquier análisis y conclusión se quiera hacer de los mismos será incorrecto. De esta forma no se podrán establecer planes correctivos o de mejora continua que produzcan resultados positivos, ya que parten de hipótesis incorrectas.

Hay que tener en cuenta que ese análisis puede ser realizado tanto dentro de tu propia organización como por parte del cliente, por lo que si se realiza en ambas partes, el daño es doble.

Y en cualquier caso, el problema que tiene la migración de costes es que resulta complicado (y requiere mucho esfuerzo) mantener la mentira durante etapas prolongadas de tiempo, hasta tal punto que lo más probable es que se termine descubriendo el pastel o por lo menos que se cree la sospecha de que algo raro está pasando y se empiece a resquebrajar la confianza existente (y eso es el principio del fin).

En otras ocasiones la migración de costes no se realiza entre tareas y proyectos de un mismo gestor, sino que la migración se realiza a proyectos de carácter horizontal en una organización, a centros de costes comunes o incluso a proyectos de otros compañeros, por lo que el daño adquiere un efecto multiplicador.