Desarrollo de software. Exceso de frentes abiertos

Uno de los problemas de los desarrollos siguiendo el ciclo de vida clásico o en cascada es que se tiende a entregar versiones completas de un sistema de información invirtiendo prácticamente todo el presupuesto del proyecto en conseguirla.

¿Problema? Tenemos una aplicación con muchas funcionalidades (cuando no muchos subsistemas) y sobre la cual el usuario empezará a reportar mejoras y correcciones, con el objeto de adaptar el sistema a sus expectativas. Esto no sería problema si estuviera contemplado en el presupuesto, pero lo más normal es que no lo esté y estaremos en una situación de poner en marcha un sistema casi sin recursos, lo que imposibilitará materializar el feedback del usuario.

Esta situación la tendremos incluso con un análisis óptimo del sistema y esto es así porque la naturaleza del software no es predictiva sino adaptativa o evolutiva. Un buen analista conseguirá reducir el margen de error entre la predicción y lo que el usuario realmente quiere (teniendo en cuenta además las contingencias propias de cualquier desarrollo, como que por ejemplo a mitad de la partida cambien las reglas del juego).

Por ese motivo lo mejor es aplicar un enfoque ágil, con una visión iterativa e incremental del sistema, de esa forma un buen trabajo de análisis es más efectivo, se reduce el tiempo en el que pueden ocurrir circunstancias que afecten al desarrollo y permite enfocar los esfuerzos en aspectos concretos del sistema. Es más, soy partidario de que incluso si se prevé que la primera versión del producto se extienda demasiado, se entreguen esqueletos andantes, sobre todo si existe voluntad de los usuarios en participar activamente en el proceso de desarrollo.

De esta forma, con la puesta en marcha paulatina de funcionalidades se puede controlar la existencia de muchos frentes abiertos, ya que la prioridad debe ser que cada módulo liberado del sistema esté acorde a las expectativas del usuario.

Cuando existen muchos frentes abiertos la sensación (y la realidad) es que las circunstancias controlan el proyecto en lugar de ser tú quien lo maneja. Apagar fuegos soluciona problemas a muy corto plazo, pero difícilmente ofrece una solución a futuro.

1 comentario

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión /  Cambiar )

Google photo

Estás comentando usando tu cuenta de Google. Cerrar sesión /  Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión /  Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión /  Cambiar )

Conectando a %s

A %d blogueros les gusta esto: