Rodrigo Quintana, Gerente de Mejora Continua
Muchas veces aparecen las dudas acerca de cuál abordaje es mejor para un proyecto en particular. Incluso a veces es el cliente quien impulsa determinado método por moda o costumbre, sin suficientes argumentos o análisis de situación. Es aquí donde el asesoramiento de los gestores del proyecto se vuelve esencial.
Tanto la teoría como la práctica han demostrado que la elección del método no está cerrada a la naturaleza del producto, sino a otras variables que definen características del proyecto. Estas variables, conocidas como el “Triángulo de hierro”, van a ser las responsables de que el proyecto tenga éxito o fracase: Alcance, Tiempo, Costo.
El triángulo establece una triple restricción a través de sus variables. Esto significa que las restricciones se equilibran cuando la combinación de costo y tiempo es igual al alcance. Dicho de otra manera, este equilibrio asegura que el proyecto no se frena por carencias en una de las variables. Para entender esto podemos verlo como una balanza:
Si aumenta el alcance, hay que balancear agregando recursos (costo) y/o tiempo (atrasar el deadline). Si disminuye el costo (inversión disponible) o el tiempo (adelantar el deadline), forzosamente hay que achicar el alcance. Si no se mantiene este equilibrio, alguien saldrá perjudicado con el resultado final (cliente y/o proveedor) y el proyecto no será exitoso por no cumplir las expectativas de las partes. Es importante resaltar que, en un proyecto exitoso, tanto proveedor como cliente obtienen los beneficios esperados (retorno económico, funcionalidades esperadas).
El método tradicional o “de cascada”, se basa en un alcance fijo, que permite seguir un plan determinado. En contrapunto, un método ágil trabaja sobre el concepto de mínimo producto viable, donde el alcance es variable. En ambos se intentará llegar al mismo resultado, pero partiendo de niveles de riesgo diferentes, lo que condiciona el nivel de visibilidad que hay que darle al cliente acerca del valor que se va generando en la construcción de la solución.
Imaginemos una implementación de un servicio de correo electrónico basado en Microsoft 365. El alcance es fácil de determinar, como la cantidad de casillas a migrar, las reglas actuales, el almacenamiento requerido. El resultado esperado es sencillo de alinear con el cliente desde el kick-off. En este escenario, la aplicación de un método de cascada es lo más eficiente.
Supongamos ahora una implementación de IA para una mesa de servicios tradicional. El cliente sabe que la IA le traerá beneficios, pero no se imagina cómo. Sólo sabe que tiene el presupuesto asignado para este período para encontrar una solución viable. Aquí la incertidumbre es tan alta, que seguir un plan predeterminado es sumamente riesgoso. La probabilidad de que lo que imaginan los implementadores coincida con lo que imagina el cliente es baja. El problema de aplicar en este escenario un método de cascada, es que esa diferencia de visión se va a ver al final del proyecto, lo cual es una excelente receta para el fracaso. Sin embargo, un abordaje ágil asegura la constante revisión del alcance en base a lo que se va construyendo y validando con el cliente.
Podría pensarse que este proceso iterativo de revisar continuamente, lejos de ser ágil, es más lento. El problema aquí es asumir que “ágil” significa “rápido”. El término agilidad en el contexto de metodologías, refiere a la capacidad de adaptación. El proyecto es ágil porque tuvo la capacidad de adaptarse a los cambios con un impacto mínimo, no porque se hizo en tiempo record.
En definitiva, cada método es muy bueno si es elegido de acuerdo a las condiciones iniciales que se nos plantean. Es más, hasta podrían combinarse artefactos de ambos métodos si las condiciones de negocio y cultura organizacional lo ameritan.
Como comentario adicional, los conceptos que son pilares de los métodos llamados ágiles, ni siquiera surgen en la industria de TI, sino en la industria automovilística hacia fines de la segunda guerra mundial. Pero esa ya es otra historia.