archivo

Archivos diarios: enero 18, 2012

Este antipatrón va de imposiciones: imposición de utilizar un determinado componente o backend sobre el que tenemos serias dudas sobre su funcionamiento, rendimiento y/o mantenibilidad y que compromete en gran medida el producto que se va a desarrollar (la fuerza de una cadena coincide con la de su eslabón más débil).

¿Que circunstancias nos pueden llevar a este antipatrón? Aquí os pongo algunas de ellas:

– El equipo de desarrollo no comunica al responsable de imponer la solución, los problemas que piensa que se pueden producir o los expone sin argumentos (lo que puede dar lugar a pensar que se trata de una excusa para utilizar otra solución).

– El responsable de imponer la solución quiere una uniformidad tecnológica en los desarrollos y antepone eso a la idoneidad de aplicar la solución al proyecto.

– El componente es una caja negra que proporciona una funcionalidad compleja de reimplementar.

– El comportamiento anómalo del componente se detecta a posteriori y no existe posibilidad a corto plazo de sustituirlo por otra solución, no existen medios para realizar la misma y/o existe temor de sustituirlo por otra que todavía tenga un funcionamiento peor cuando un aspecto funcional de la aplicación importante depende de ella.

Pensaba que la creencia de meter más gente en un equipo de proyecto para intentar acortar plazos (o cumplirlos) cuando el mismo se encuentra muy avanzada daba buenos resultados estaba superada pero no es así, sobre todo dentro del área usuaria.

No somos como máquinas dentro de una factoría y que solo con meter más personas en el proyecto se va a incrementar la producción total. Cuando entra alguien nuevo en el proyecto existe durante un tiempo un productiva neta negativa del mismo, es decir, genera más trabajo que el que puede resolver (ese tiempo dependerá de si ya ha participado antes en alguna fase del mismo o no, de sus conocimientos, de su experiencia, de la carga de trabajo existente y de los plazos para realizarlo, etc…) y esto es algo que no solo existe en nuestro negocio, sino también en la mayor parte de las profesiones, por ese motivo, incluso cuando es el área usuaria quien piensa esto, no termino de entenderlo porque en casi todos los casos en su trabajo habitual les pasaría exactamente lo mismo (en mayor o menor medida).

Este antipatrón, además, se asocia a situaciones en las que los equipos de proyecto tienen un importante nivel de rotación, entran y salen técnicos, como si el proyecto no se viera afectado, como si efectivamente, fuéramos las máquinas a las que hice referencia en el párrafo anterior. El intento de maximizar beneficios o de evitar pérdidas en proyectos mal vendidos o mal estimados se convierte en proyectos donde generalmente la calidad del producto deja mucho que desear (por decirlo suavemente) y en donde el avance de la ejecución no es tan fluido, requiriéndose más esfuerzo y salvo que el personal que esté trabajando tengan sueldos muy bajos y/o tengan overtime continuo en la mayoría de los casos el coste final es mayor que el que se pretende ahorrar.