archivo

Archivos diarios: noviembre 18, 2011

Sistema desarrollado. En producción. Usuarios que no les gusta el resultado final o que no les parece adecuado el resultado que se obtiene como consecuencia de las directrices funcionales que dieron otros antes. Sistema de gran tamaño. Capacidad muy limitada a nivel presupuestario para poder ejecutar varias líneas de trabajo en paralelo. Usuarios que no quieren utilizar el sistema.

¿Os suena? Es el resultado típico de un proyecto desarrollado en cascada. Admito, ya lo he hecho en otros artículos, que estoy generalizando y que cada cual cuenta la historia tal como la ha vivido y/o puede observar en su entorno. Esta es mi visión sobre este tipo de desarrollo y no es teoría, os lo puedo asegurar.

Ante la situación descrita anteriormente hay dos alternativas posibles: renunciar al sistema de información (tirarlo a la basura) o que todas las partes (área usuaria, dirección usuaria y área informática) asuman lo desarrollado como propio y que tiren hacia adelante, teniendo en cuenta y muy presente, que lo que viene a continuación es una larga travesía en el desierto, donde habrá personas bastante descontentas y donde el uso del sistema será incómodo.

Asumir eso no es fácil, pero es lo que queda si se quiere salvar el sistema de información, ya que no se tendrá el mismo dinero para mantener que para desarrollar y el mantenimiento es sobre el conjunto del sistema (salvo que haya módulos que se prioricen sobre otros).

Michael Anthony Jackson y el autor y profesor universitario Daniel McCracken realizaban la siguiente reflexión en el año 1982: “Los requisitos del sistema no siempre se puede afirmar totalmente de antemano porque el usuario no los conoce de antemano.

Afirmar lo contrario es ignorar el hecho de que el propio proceso de desarrollo cambia la percepción del usuario de lo que es posible, aumenta sus conocimientos del entorno de la aplicación e incluso a menudo cambia el entorno por sí mismo”.

Cerca de treinta años nos separan de esta cita y en igual, jugando a predecir lo que realmente quiere el usuario y construyendo grandes sistemas que después requieren ser ajustados y no existe ni tiempo ni presupuesto para poder hacerlo de manera adecuada.

Las metodologías clásicas pueden ser más cómodas, no tienen la intensidad de las basadas en desarrollos iterativos e incrementales de ciclos cortos, pero no son efectivas y la comodidad se convierte en desgaste cuando el usuario empieza a cambiar requisitos en fases tardías del desarrollo o tras la entrega.