Quiero tener una aplicación web. ¿Qué modelo de contratación escojo?
“Ha llegado el día. Han definido el presupuesto que tendrá mi departamento para este semestre. ¡Y por fin puedo plantearme la constucción de la plataforma web con la que esperamos mejorar nuestros resultados!”
De forma frecuente suele darse esta situación en las empresas.
¿Cuál es el siguiente paso? Lo habitual es contactar con un proveedor de software, contarle la idea inicial del proyecto y cerrar un presupuesto.
El proveedor de software, al trabajar con un presupuesto cerrado previo al comienzo, suele aplicar el típico modelo en cascada. En él, se estructura el proyecto en fases separadas de análisis, diseño, codificación, pruebas y despliegue.
Pero, ¿es este el único modelo? ¿es el modelo ideal? Evidentemente no es el único modelo ni tiene por qué ser el modelo ideal.
En función de lo clara y completa que sea la idea inicial, este modelo en cascada puede encajar.
Sin embargo, la realidad nos dice que ningún proyecto está totalmente definido inicialmente bien por que no se tienen claros los objetivos de la aplicación o porque pueden cambiar en el transcurso del proyecto. Como consecuencia, provoca que haya que volver a analizar, diseñar y codificar el mismo acarreando costes en gestión, tiempo y dinero.
Pero, ¿y si queremos ser más dinámicos? ¿Y si queremos evolucionar la idea conforme vayamos avanzando en el proyecto? En este caso, estaríamos escogiendo un modelo incorrecto.
Un modelo en cascada nos estaría obligando a generar un exceso de documentación, renegociación de requisitos, creación de un diseño no ajustado a lo que finalmente se pretendía y obtención de un producto que no convence ni al proveedor ni al cliente. En definitiva, estaríamos gastando un tiempo precioso en labores de gestión cuando lo que queremos es creatividad y construcción.
¿Qué alternativas tenemos? La alternativa es buscar un modelo dinámico y flexible.
¿Cómo lo conseguimos? La rigidez del proyecto suele venir marcada por la idea inicial, que a su vez marca el presupuesto. Éste provoca que se controle de manera exhaustiva qué se hace y qué se deja de hacer por parte del proveedor de sofware.
Así que, ¿por qué definir el proyecto cuando todavía no tenemos claro cómo queremos nuestra aplicación final?
Como alternativa, se puede plantear el proyecto en pequeños objetivos e ir pagando por trabajo realizado. De este modo, el comienzo del trabajo es inmediato y permitirá al cliente ir modelando el proyecto poco a poco.
Con ello, el proveedor de software dedica a CREAR el tiempo que se iba a usar para gestionar el control de requisitos y estimaciones.
Desde el apartado económico, la primera impresión puede ser que con el modelo en cascada, todo está más controlado y es más económico. Pero la experiencia nos dice que no es así. Además de ser más caro, es más complicado conseguir el éxito del proyecto.
¿Qué sistema se ajusta más a tu empresa?
Qué razón tienes Nacho… cuanta frustración en cliente y proveedor se ahorraría, y cómo aumentaría la productividad y la competitividad de los proyectos si se hicieran siempre así.
Yo añadiría una ventaja más, y es que ese desglose en pequeñas fases u objetivos permite a la empresa cliente verificar que ha dado con el proveedor adecuado, y minimizar los daños si no es así y no le convencen los resultados que va obteniendo. Este es uno de los argumentos que más nos ha ayudado a nosotros a “vender” esta metodología enre nuestros clientes potenciales.