Llamamos gestión de proyectos tradicional a la gestión que se realiza en los proyectos que tienen las siguientes características: Conjunto de requisitos cerrado o presupuesto cerrado. Este tipo de proyectos tienen un alto grado de fracaso las razones para el fracaso son variadas:
El conjunto de requisitos no está realmente cerrado. El cliente no es capaz de enumerar con suficiente detalle todas las necesidades que tiene y el proveedor no es capaz de prever correctamente la magnitud del problema a resolver. Esto provoca que las expectativas del cliente no se cumplan, que los plazos y costes se desvíen mucho más de lo razonable, etc. Generalmente el cliente termina teniendo que pagar más o el proveedor perdiendo dinero para conseguir que el cliente acepte lo que se le entrega.
El desarrollo de software no es construcción sino diseño. Se han devastado bosques enteros fabricando libros que hablan de la ingeniería del software, de la construcción de software y del software factory. Nombres pomposos para unas teorías formuladas por personas que nunca han desarrollado software en la vida real. El desarrollo de software carece de la repetitividad, medibilidad y predictibilidad que tiene la construcción. No la tiene porque desarrollar software es diseñarlo (equivalente al diseño y planos técnicos de la construcción, solo que de mucha mayor magnitud), mientras que construir software es compilarlo y/o instalarlo. Programar es diseñar, da igual el detalle de diseño previo que se haya generado. Siempre se están tomando decisiones de diseño cuando se programa algo. Esto implica que el tiempo necesario para realizar un desarrollo es altamente impredecible, sobre todo cuando no se cuentan con unos requisitos detallados, pero incluso cuando se cuentan con estos, puesto que realizar un análisis suficientemente exhaustivo de los requisitos, equivale a diseñar la solución.
Se crean expectativas que no se pueden cumplir en el cliente. Siempre le decimos al cliente que vamos a cumplir los plazos y que el sistema va a hacer todo lo que él quiera (¡Y además que va a ser muy barato!). Nunca se cumplen los plazos y el sistema nunca hace todo lo que quiere el cliente, porque el cliente según ve la aplicación, se le ocurren nuevas cosas que debería hacer. El cliente no tiene un control sobre los costes del proyecto: lo que tiene el cliente es un cheque en blanco, porque ha obtenido una cifra fría, sencilla y clara de lo que le va a costar el proyecto y va a demandar que la aplicación haga lo que él cree que tiene que hacer hasta en el último detalle. El cliente no recibe la información de que un detalle puede ser muy costoso; por el bien de los proyectos, siempre debe ponderarse la funcionalidad frente al coste.
Las necesidades del cliente cambian. Las necesidades del cliente han podido cambiar porque la empresa o el entorno han cambiado o porque se han visto otras posibilidades más interesantes.
En Binovo suscribimos el Manifiesto de Desarrollo de Software Ágil, de forma que valoramos a las personas y sus relaciones frente a los procesos y las herramientas. Al software que funciona frente a documentación exhaustiva, a la colaboración con los clientes frente a la negociación de contratos, respondiendo al cambio frente a seguir un plan.
Aunque las segundas partes de las sentencias tienen valor, creemos que la primera parte tiene mucho más. Para ello, seguimos los siguientes principios: