Desarrollo de software. Ciclo de vida en cascada. Puertas abiertas o cerradas

En el ciclo de vida en cascada, por su naturaleza, por el hecho de que el usuario empieza a ver las funcionalidades implementadas muy tarde (poco antes de la entrega) existe la tendencia a querer abrir puertas que ya se consideraban cerradas, es decir, a retocar especificaciones, en algunos casos serán cosas menores e incluso asumibles y en otros casos, se requerirá un trabajo muy importante realizar su implementación.

Y eso sucederá por muchos prototipos con los que hayas trabajado con el usuario. Es cierto, que el uso de prototipos disminuye el riesgo de posibles discrepancias entre el producto final y las expectativas del usuario, pero también lo es que durante el proceso de desarrollo pueden pasar muchas cosas que hagan que algunas (siendo generoso) especificaciones iniciales ya no valgan, que el usuario que te las haya definido se haya ido de la organización o se haya cambiado de departamento y sobre todo que hasta que no se trabaja con el producto el usuario no termina de ver claro lo que necesita (e incluso requerirá varias iteraciones hasta alcanzar con una solución que empiece a satisfacerle).

¿Qué hacemos entonces?, ¿dejamos las puertas abiertas o cerradas?. Probablemente si se dejan cerradas el producto desarrollado fracase porque por muy bien que se haya hecho, no hará o funcionará como el usuario quiere que lo haga.

Ahora bien, lo que no puede ser es que el proveedor asuma con la carga. ¿Se han desarrollado todas las funcionalidades pactadas de la manera en que está recogida en los diferentes items documentales del proyecto que a su vez ya han sido aprobados por sus responsables? Sí, pues entonces el proveedor no puede, ni debe asumir esa carga.

Debe asumir lo que no haya hecho y los errores de lo que haya hecho, pero no debe asumir errores de terceros.

El problema de todo esto es que cuando esto ocurre, en lugar de asumir lo que hay, de responsabilizarse de lo hecho y de aplicar un mayor presupuesto al proyecto, se recurre al desgaste cliente (área técnica)/proveedor para intentar que esas funcionalidades se hagan, mientras que el área usuaria, suele salir impune, actuando como un espectador que ve una película en la mejor localidad, con palomitas y refresco gratis y que actúa como un crítico implacable.

Estas situaciones son demasiado frecuentes y dan lugar a proyectos que no dejan satisfechos a nadie, que no producen buenos resultados económicos y que han originado un gran desgaste entre las partes. Por motivos como este, es necesario huir de las cascadas como metodología y por otro hace necesario un proceso de educación importante en el área usuaria antes de iniciar el proyecto para que entiendan cuál es su papel en el mismo y la responsabilidad de las decisiones que toman.

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: