archivo

Archivos diarios: enero 21, 2012

En una empresa de servicios, y las de desarrollo de software lo son, las horas de trabajo de los técnicos que no se han podido encajar en un proyecto facturable son horas de trabajo que no se pueden recuperar, no es posible tenerlas en stock, como sucedería en el caso de productos físicos.

Por tanto, tiene lógica que estas empresas intenten optimizar al máximo las horas facturables de los empleados de manera que se consiga una aproximación al objetivo del 100% (desgraciadamente, para muchos el objetivo del 100% tampoco resulta suficiente).

Hasta ahí podemos estar de acuerdo, sin embargo, lo que da lugar a este antipatrón es que una estrategia que se suele aplicar para conseguir este aprovechamiento al máximo de las horas de los técnicos es considerar a la organización como una fábrica en las que todos dominan las máquinas que utilizan y, por tanto, pueden cambiar su proyecto asignado sin el más mínimo problema.

Esto en la mayoría de los casos no es posible (tal vez, podamos exceptuar a empresas de desarrollo muy especializadas que tratan con un grupo de clientes muy concreto y estable) ya que será necesaria una adaptación al proyecto en la cual es posible, en función de su naturaleza, que tengamos un programador (o un técnico en general) con productividad neta negativa.

Existen otros caminos para llegar a este antipatrón, más allá del deseo de optimizar las horas facturables de los empleados. Un ejemplo lo tenemos en otro deseo de optimización, el del coste, ya sea para maximizar beneficios o para paliar pérdidas, en el cual, sigue sin importar la especialización y experiencia ya adquirida en el proyecto y lo único que importa es que el coste por día de trabajo invertido en el mismo se reduzca. Por ese motivo se sustituye parte del personal (cuando no todo) por otro menos cualificado y que cobra menos.

Pese al riesgo que entraña esa práctica, muchas organizaciones o más bien los gestores de las mismas la siguen aplicando ignorando que la productividad y el nivel de calidad de los trabajos no puede ser el mismo, lo que llevará a que en muchos casos el coste final sea superior al que se hubiera tenido con el equipo que inicialmente estaba asignado al proyecto (y si el coste no es superior desde el punto de vista tangible, si que lo será cuando al mismo se le sume el intangible de un cliente perdido).

Tal vez sea más conocido por “Esto no es la NASA”.

Alcanzar el justo medio en el análisis de una solución (ya sean requisitos, modelado de datos, arquitectura, etc…) no es sencillo, tanto es así que lo más normal es que en la mayoría de los casos nos aproximemos al mismo y exista una desviación en defecto o en exceso.

Este antipatrón se produce cuando ante una situación que requiere un análisis y en la que hay que dedicar un tiempo y esfuerzo para realizarla de manera adecuada se decide prescindir del mismo, ya que al fin y al cabo “esto no es la NASA” y tampoco es necesario una solución prácticamente perfecta.

Tan malo es intentar alcanzar algo que no se puede conseguir (la perfección) como prescindir del estudio de un problema, asumiendo que las diferentes contingencias que nos vayamos encontrando las iremos superando y que cualquier aspecto que no se haya definido tendremos conocimientos y bagaje suficiente como para completarlos por nosotros mismos (aplicando por ejemplo otros antipatrones como “el martillo de oro“, “bala de plata” o “introducción de dificultad por analogía“).

Nos encontramos con este antipatrón cuando ante un sistema de información de complejidad y tamaño medio/alto, con una deuda técnica alta, se solicita la realización de tareas de mantenimiento, generalmente evolutivo, de cierta envergadura, las cuáles deberían ejecutarse en un plazo de tiempo muy ajustado y se centran los esfuerzos en intentar conseguir ese objetivo, independientemente de que el producto vea incrementada su deuda técnica y complejidad.

El primer problema que nos encontramos es la existencia de una restricción temporal que condiciona los trabajos, lo que hace que se enfoquen los esfuerzos en “apagar el incendio”, dejando de lado la aplicación de determinadas buenas prácticas y controles de calidad del software si estos pudieran frenar el avance de la ejecución de las tareas.

Esto hace que el plan de proyecto se centre en dar una respuesta a la situación, dejando para el final la realización de tareas que mitiguen la deuda técnica y la simplificación de funcionalidades eliminando funcionalidades o código que no ya no tienen utilidad (ver antipatrones lava seca y ancla de barco). ¿Qué es lo que suele pasar? Pues que al final no haya tiempo para realizar esos ajustes, ya sea porque nos hemos quedado sin presupuesto y/o aparecen nuevos fuegos que ir mitigando.

Esa restricción temporal puede estar justificada ante la necesidad de adaptar un sistema de información a una normativa o para adaptar el sistema a un cambio en procesos o a un nuevo proceso que resultan esenciales para el funcionamiento de la organización y que de no estar en los plazos fijados podría suponer un importante perjuicio económico que podría incluso afectar seriamente no solo a los balances, sino incluso a la propia viabilidad de la compañía.

Otras veces la restricción temporal, pese a que pueda estar sustentada por ciertos criterios objetivos, no deja de ser un capricho de cierto personal directivo a los que un día en un “alarde de creatividad” deciden que es necesario realizar ajustes en un sistema o incluirle nuevos módulos.

El siguiente problema es la realización de cambios de cierta magnitud en un sistema con una deuda técnica elevada, que implican que cualquier tarea de desarrollo sobre el mismo (sobre todo aquellas que supongan modificaciones en módulos ya implementados) cueste muchísimo más esfuerzo (como correr con un vendaval de viento en contra, con carga en una mochila y con pegamento en la suela de las zapatillas), además de incrementarse la probabilidad de errores, tanto por posibles efectos colaterales como por la presión de ejecutar trabajo rápidamente, dejando de lado la realización de determinadas prácticas de aseguramiento de la calidad del software.

Al final, en el caso de que cumplamos el hito temporal (algo que en aquellos casos donde los plazos sean muy ajustados solo será posible priorizando tareas, teniendo a todos los stakeholders muy implicados y acertando mucho), tendremos un producto más complejo, más costoso de mantener (si cabe) y bastante más inestable.

Caro es no cumplir las expectativas del usuario y barato todo lo contrario.

Es tanto el dinero gastado en sistema de información que no han producido resultados satisfactorios y tanto los problemas que esto ocasiona a un cliente (crisis del software), que realmente cualquier de ellos estaría dispuesto a pagar lo que fuese (dentro de unos límites razonables) con tal de que el producto que se obtenga tuviera éxito.

Precisamente, la no consecución de esos objetivos ha sido una de las causas del abaratamiento progresivo de los presupuestos en los proyectos, es decir, falta de confianza de los clientes = peores condiciones.

Esta situación la ha creado nuestro sector. Somos los principales culpables y en nuestra mano está dar la vuelta a esto. Sin embargo, no se termina de mirar de más allá y sigue sin importar lo que le pase al sector, solo importa conseguir negocio a corto plazo a costa de lo que sea.

Otros artículos relacionados:

El precio hora y el triunfo de la mediocridad: I y II.