Un chiste clásico sobre los proyectos que puebla los corchos y paredes cubiculares de oficinas de medio mundo desde hace años… Aprovecho para un par de reflexiones:
- La importancia de la toma de requisitos: con demasiada frecuencia los proyectos “empiezan” y ya está. Parece que se trata de ponerse manos a la obra cuanto antes y ya veremos lo que va ocurriendo por el camino. Cuando se habla de documentos formales de requisitos visados por el cliente, muchos te miran como si te hubieras escapado de una tira de dilbert. Y cuando llamas la atención a una organización acerca de los sobrecostes en los que incurre por las continuas modificaciones y cambios que se producen en el proyecto a petición del cliente, suelen encogerse en hombros y decir “este mercado es así”. Por otra parte, y tal como ilustra perfectamente el gráfico, lo que el cliente explica, lo que entiende el integrador y lo que realmente necesita el cliente rara vez coinciden. Ser consciente de este hecho otorga una importante ventaja estratégica
- La documentación de los proyectos: a las empresas les suele preocupar perder a sus empleados cuando ya están formados y adaptados a la forma de trabajar de la organización, pero sin embargo no muestran una fracción de dicha preocupación respecto a la documentación del trabajo que desempeñan. Esto conlleva que no hay lecciones aprendidas, mejores prácticas ni un repositorio de información sobre el desempeño de los proyectos que nos permita medir y evaluar el desarrollo de la organización en este campo
Totalmente de acuerdo con lo de la documentación. Afortunadamente hay una tendencia a tomarse estas cosas cada vez más en serio, derivadas de las iniciativas encaminadas a mejorar el nivel de madurez en las operaciones.
En el caso concreto de los proyectos de software existe una metodología llamada “Extreme Programming” o Programación Extrema . La verdad es que no la he usado nunca, pero sé que hay empresas que la usan y me llama la atención, entre otras cosas, que se programe en parejas. Comento esta metodología porque asume que el cambio de requisitos es algo “natural, inevitable, e incluso deseable”.
A ver si alguien por aquí la ha empleado y nos dice si realmente funciona y si es mejor que otras (tanto desde el punto de vista del cliente como de la empresa)
Antonio, conozco XP (aunque me gusta más el enfoque de Scrum, lo de programar por parejas no acabo de verlo) pero lamentablemente en algunos casos, con metodología y todo, la prisa y los defectos en la preventa hacen que el enfoque del proyecto sea “tu ve haciendo algo que ya lo iremos corrigiendo”. Eso provoca grandes desviaciones de tiempo y coste y, en algunos casos, la imposibilidad absoluto de adecuarse a los requisitos reales del cliente. Un buen proceso de identificación de requisitos al principio de los proyectos es, junto con un kick-off meeting efectivo y un plan de proyecto, de las cosas que más pueden mejorar el éxito de los proyectos.