Antipatrones: aprendiendo de los errores de otros (y III) #bdc11

Tras el de desarrollo y el de arquitectura, en este tercer y último post sobre antipatrones nos vamos a centrar en los referentes a gestión de proyectos. Tal vez se traten de los más dañinos para el buen resultado de un proyecto. Una aplicación llena de código spaghetti o con una arquitectura mal diseñada, seguramente es capaz de funcionar de una manera más o menos decente, al menos durante un periodo corto de tiempo.

Pero un proyecto mal gestionado tiene muchos números para ser un fracaso, e incluso no llegar a ver nunca la luz. Según varios estudios casi el 70% de los proyectos de software son un fracaso, provocando sobrecostes de cientos de billones de euros al año. De estos, entre el 60 y el 80% son atribuibles directamente a una pobre toma de requerimientos, mala planificación y gestión deficiente.

Veamos algunos ejemplos de antipatrones de gestión de proyectos que están bastante relacionados entre sí:

Smoke and Mirrors (Humo y espejos)

El nombre de este antipatrón viene de los trucos que usan los ilusionistas para hacernos ver cosas que no existen (quien haya visto la película El Ilusionista tendrá una imagen muy clara de lo que hablo. El que no la haya visto, se la recomiendo). Se trata de vender como acabado un producto o funcionalidad que no está implementado o ni tan siquiera diseñado. El cliente asumirá que está finalizado y, lógicamente, querrá tenerlo lo antes posible. Otro nombre para este antipatrón sería: “Los powerpoints no compilan”.

 

Fire Drill (Simulacro de incendios)

Fire Drill

Los gestores esperan hasta el último momento para permitir que los desarrolladores empiezen con el diseño y la implementación de la aplicación. Una vez empezado solicitan resultados inmediatos.

 

 

 

 

 

Mushroom Management (Gestión Champiñón)

Mushroom

Sucede cuando se tiene a los desarrolladores como champiñones, en la oscuridad y alimentados con fertilizante. Cuando están listos, se cuecen y enlatan. La interacción con los clientes o usuarios finales está prohibida, no sólo todos los requerimientos llegan a través del jefe de proyecto o analista de turno, sino que cualquier duda tiene que pasar también por ellos. Esto provoca que la comunicación sea un factor que retrasa la toma de decisiones y la realización de acciones.

 

 

Hero Cult (Cultura del héroe)

Hero Cult

Siempre hay un “héroe” que haciendo infinitas horas de más es capaz de sacar un proyecto adelante. El problema es cuando estas horas de más se entienden como lo normal y se requiere que todo el equipo las haga.Hay que entrar antes que el jefe y salir después que él. Por supuesto, cuando se acercan las fechas de entrega se pide otro esfuerzo más. Los desarrolladores se quedan hasta altas horas de la madrugada. La aplicación se llena de errores por las prisas y la falta de sueño y empiezan los roces entre compañeros.

 

 

 

¿Qué provocan estos antipatrones?

Desarrolladores cansados, haciendo horas para intentar llegar a un plazo imposible, peleándose entre sí y sin conocer los requisitos reales del cliente, lo que van a provocar son otros anitpatrones:

  • Código de copia y pega para interntar salir del paso (Copy-Paste Programming y Spaghetti Code)
  • Arquitecturas sin definición porque no hay tiempo para acabarlas (Big Ball of Mud)
  • Uso de la primera solución que tengamos a mano aunque no sea la más adecuada (Golden Hammer)

Estoy seguro que muchos de los que estáis leyendo estas líneas habréis vivido algún proyecto de este tipo porque, para nuestra desgracia, es la forma “normal” en que muchas empresas de software gestionan sus proyectos. Este tipo de proyectos no sólo acarrea sobrecostes para el cliente, que se quedará con una aplicación hecha con prisas y llena de errores, mala imagen de la empresa que la ha desarrollado. Además, tendrá un alto precio para el equipo de desarrolladores ya que perderá a alguno de sus componentes porque se habrá “quemado” en el camino. Se podría decir que se trata de un fracaso en todos los aspectos.

¿Cómo evitar llegar a este punto?

La solución a estos antipatrones tiene que surgir de la implicación de los desarrolladores desde las primeras fases de los proyectos. Incluso en las pre-ventas tendría que haber un experto en tecnología para dar su opinión sobre si lo que solicita el cliente es viable desde el punto de vista técnico y contando con las habilidades de los desarrolladores que se tiene en plantilla.

Una vez que ese experto diese el visto bueno, existen varias opciones para continuar:

  • que un equipo pequeño de desarrolladores monte un prototipo, y a partir de éste fijar el diseño e implementación y estimar la duración del proyecto sobre ese prototipo.
  • utilizar SCRUM para hacer un desarrollo basado en entregables periódicos y con el cliente implicado desde el principio y dando feedback.

Pero para poder llevar un proyecto a buen termino es necesario un buen EQUIPO de desarrolladores. Ese equipo tiene que estar equilibrado, cohesionado y debe poder trabajar en un buen ambiente. Con esto me refiero a que la carga de trabajo sea razonable y respetando los horarios de los trabajadores.

Tal vez las soluciones parezcan utópicas o poco realistas, pero si la forma de hacerlo no sirve, habrá que probar otra. Como dijo una vez Albert Einstein: “Locura es hacer la misma cosa una y otra vez esperando obtener diferentes resultados”.

Nota: No me gustaría acabar el post sin mencionar el blog de jummp, en el que, entre otras cosas, se habla mucho y muy bien sobre antipatrones. Os lo recomiendo :)

deja tu comentario