¿Le habéis hecho esa pregunta a algún responsable de proyecto? Yo sí, muchas veces y, además, obviamente, no soy el único que lo ha hecho y hay quien hasta tiene estadísticas sobre la respuesta más frecuente.
“-¿Qué es más importante para ti? ¿Poder cambiar los requisitos en cualquier momento o saber coste, tiempo y requisitos antes de empezar el proyecto?-“
¿Cuál crees que es la respuesta más frecuente? ¡Acertaste! “-Prefiero saber coste, tiempo y requisitos antes de empezar el proyecto-“. Y eso es predictibilidad, es decir, cierre de requisitos, cascada, etc.
Quien ya hicieron este estudio y publicaron los resultados hablan de que 8 de cada 10 que fueron preguntados respondió aquello de “-Prefiero saber coste, tiempo y requisitos antes de empezar el proyecto-“. El estudio lo hizo McConnell, también Moseman 2002, y Putnam -Myers 2003, etc. Y a mí, lo de 8 de cada 10 me cuadra.
La agilidad apuesta más por la flexibilidad, la posibilidad de cambiar requisitos, etc., ya no te cuento ideas como el #NoEstimates, o sobre que la estimación no sea la pieza central de un proyecto.
Lo más curioso de todo este tema es que si en vez preguntar al responsable del proyecto preguntásemos al usuario, no al comercial del usuario, al usuario de verdad, a aquel que sólo hace uso de nuestra aplicación software, que desconoce los entresijos de los proyectos, probablemente 8 de cada 10 contestarían que lo más importante para ellos es “-Poder cambiar, añadir, jugar con los requisitos en cualquier momento-”
Con los años, el mundo del software se ha centrado en aportar soluciones (como es la agilidad) que reduzcan el “time to market”, que den funcionalidades rápidamente a los usuarios, que permitan el cambio, etc., sin embargo, no debemos olvidar que en el fondo el objetivo de muchas de las personas que deciden sobre los proyectos no es ese, es lograr la seguridad de una supuesta (ya sabes que rara vez real) predictibilidad.
Primera vez que me tocó hacer una gestión Ágil en una empresa... año 2001. Desde entonces he trabajado en, o para, más de 90. Y he formado a más de 2000 alumnos.
También soy profe de la Universidad Rey Juan Carlos.
- Más allá del Management 3.0: 12 prácticas (de muchas) que no están en M 3.0 - 25 enero, 2024
- Más allá del Management 3.0: Otros muchos patrones para equipos Ágiles - 18 enero, 2024
- Años 30, Ohio (EE.UU.) y el Agile Product Management - 11 enero, 2024
Hola Javier. En primer lugar gracias por el trabajo de divulgación que realizas con este blog. Es realmente motivador ver la pasión que tenéis por transmitir cómo hacer software correctamente.
Al leer este post me ha surgido la duda trascendental de si la gestión ágil de proyectos en general tiene sentido aplicarla en una empresa que no se dedica a hacer software para un usuario final sino a software de integración de procesos de negocio muy específicos dentro de una gran empresa, por ejemplo integración de las ventas de una empresa en un país A, en una base de datos de un país B, para que la oficina de un país C haga sus operaciones. Y luego el mantenimiento correctivo y evolutivo sobre esos sistemas desarrollados. ¿Tiene sentido plantearse la agilidad en este contexto donde cambiar requisitos a medio desarrollo ni es una prioridad ni suele pasar? Gracias por tu opinión.
De las tres variables Coste, Tiempo y Requisitos me da la sensación que las metodologías ágiles se centran en manejar de forma muy eficiente esta última (requisitos) y que con las otras dos mira un poco para otro lado.
Desde luego el desarrollo software es un proceso singular en el que no se deben aplicar de forma sistemática técnicas de «antiguas ingenierías». Pero de ahí a darle un valor secundario a la estimación de requisitos, plazos y costes hay mucho trecho.
Si bien es realista enfocar el desarrollo software de forma que se pueda adaptar lo mejor posible a los cambios en los requisitos esto no es algo exclusivo en el software. Y permítaseme una mala analogía (como lo son todas) con la obra pública, que entiendo que también se debe enfocarse como un proceso que sepa manejar los cambios de requisitos: ¿acaso al hacer una carretera no se encuentra muchas veces un río subterraneo con el que no se contaba?, ¿no se dan causas por los que se tenga que hacer un cambio en el trazado?
¿Asumir la buena gestión en los cambios de requisitos justifica que los costes y plazos hayan de tener una importancia secundaria frente a una satisfacción del usuario? Representando esto último en la máxima «el auténtico objetivo es crear valor añadido al usuario»
Surge un argumento de forma inmediata inmediata: tanto en el software como en la obra pública la estimación de costes y plazos acostumbra a fallar muy por encima de lo deseable. ¿y siendo verdadad se justifica que alguien se permita cambiar el software de control aereo sin saber costes requisitos y plazos?, ¿y eso justificaría que se licitase obra pública sin fijar costes y requisitos de manera previa? ¿Justifican estos fracasos que deba abandonarse la lucha por hacer estimaciones «fiables»?
En la empresa moderna las inversiónes se hacen con un ojo puesto en el ROI (Return of Investment)* Y pongamos un ejemplo: una empresa tiene por política no entrar en una inversión con ROI < 11% y se plantea una inversión con penalizaciones importantes por retraso de entrega en el que el software tiene un peso importante. ¿Debe/puede el proveedor software explicar al cliente que no deposite mucha esperanza en las estimaciones que se le proporcionen?, ¿o lo que debemos es zanjarlo con un "este proyecto no es apto para metodologías ágiles"?
En muchos casos los plazos y tiempos no son simples variables del problema sino que son una restricción capaz de habilitar o deshabilitar la ejecución de todo el negocio.
Permítaseme acabar con una cita del gran Lord Kelvin: «Cuando puedes medir aquello de lo que estás hablando y expresarlo en números, puede decirse que sabes algo acerca de ello; pero, cuando no puedes medirlo, cuando no puedes expresarlo en números, tu conocimiento es muy deficiente y poco satisfactorio.»
*In a survey of nearly 200 senior marketing managers, 77 percent responded that they found the «return on investment» metric very useful. [ http://en.wikipedia.org/wiki/Return_on_investment ]
Hola Javier, interesante el post. Me gustaría saber como es que se maneja un proyecto ágil con respecto al tema de tiempos y costos en la etapa de Inicio de la gestión de proyectos. No se si habrá alguna guía o algo que ayude a entender este tema.
Saludos