Este uso indiscriminado del término Proyecto probablemente está detrás de la confusión que se delata en afirmaciones tales como: "para algunos proyectos usamos Kanban y para otros Scrum", "usábamos Scrum pero hemos decidido pasarnos a Kanban". Probablemente la cuestión de fondo es que en ciertos contextos no es conveniente usar Sprints (una de las prácticas de Scrum), o al menos usarlos con una interpretación menos rígida (los Sprint pueden ser "flexibles" en contenido y/o en duración, ver Sprints, "welcome to the real world"). Esto se une al hecho que a veces las decisiones se toman a nivel de método, es decir, cuando se usa uno u otro de forma exclusiva (ver ¿Kanban o Scrum?: that is not the question), siendo que lo más recomendable es usar las prácticas prácticas ágiles, independientemente del método ágil que las propone (ver Carta de Prácticas Ágiles: Arma tu propio menú ágil),
Obviamente no se trata de prescindir del término "Proyecto", sino de usarlo cuando sea conveniente, como un elemento más de la estrategia establecida para abordar un determinado contexto de trabajo. Es decir, asociar Proyecto a trabajos que tienen comprometidas fechas de inicio y fin, donde el alcance está previsto (aunque pueda sufrir algunos cambios).
Por otra parte, en el PMBOK se denomina "Operaciones" a todo el resto de trabajo que NO se enmarca en proyectos, es decir, el trabajo del día a día de la explotación y soporte de productos o servicios. Sin embargo, el mantenimiento (mejoras y correcciones de productos y servicios) a veces no es claramente asignable solo a una de estas dos categorías; "Proyectos" u "Operaciones". Por ejemplo, debido su la naturaleza, en productos software el mantenimiento es técnicamente equivalente a una continuación de su desarrollo, sin embargo, no es un trabajo planificable cuando se refiere a mantenimiento correctivo y pequeñas mejoras que se detectarán durante el uso del producto (no se conocen de antemano). Además, si es el mismo equipo el encargado de realizar el desarrollo y el mantenimiento se puede cometer el error de mezclar todo el trabajo. Si se mezclan ambos, probablemente el desarrollo (que sí es planificable) se verá interrumpido y retrasado el por mantenimiento, lo que provocará una continua re-planificación y frustración al respecto. En este caso lo recomendable sería reconocer Desarrollo y Mantenimiento como dos líneas de trabajo separadas (aunque estén sobre el mismo producto). En la línea de Desarrollo probablemente convendría trabajar con Sprints y opcionalmente con Proyecto, en cambio en la línea de Mantenimiento sería más adecuado gestionar un Backlog ordenado y realizar entregas continuas de trabajo terminado (no usar Proyecto). Evidentemente esta la separación del trabajo en dos líneas no haría desaparecer mágicamente dichas posibles interrupciones y retrasos, pero hará más fácil la gestión del trabajo y más explícita la toma de decisiones respecto, por ejemplo, de la distribución de la Capacidad de dicho equipo para dedicarla a cada línea de trabajo. Así, sería evidente cuando el trabajo de Desarrollo se está retrasando porque la Capacidad asignada no es suficiente para ir al ritmo que se esperaba o porque la Capacidad asignada a Mantenimiento se está regularmente sobrepasando y esto recorta la Capacidad disponible para Desarrollo.
Además, un producto o servicio puede tener asociados varios proyectos a lo largo de su existencia. Por ejemplo: el proyecto que desarrolla la primera entrega, un proyecto que hace una mejora significativa, un proyecto de integración con otros productos o servicios, etc. Sin embargo, en paralelo a dichos posibles proyectos, un producto o servicio requerirá cierto trabajo de soporte y mantenimiento continuo (que también hay que gestionar), no enmarcado en esos proyectos.
Por último, una de las características del enfoque ágil es centrarse en aportar valor al cliente/usuario a través del resultado del trabajo del equipo (el producto o servicio entregado al cliente/usuario). Esto debería implicar que cambiásemos el foco desde la gestión del proyecto hacia la gestión del producto o servicio. El éxito ya no es solo una cuestión de cumplir con el alcance-plazos-costos (Proyecto), sino que al mismo tiempo debemos satisfacer al cliente(usuario, y no solo en el momento de la primera entrega del producto o servicio, sino durante toda su vida útil. Así, un producto o servicio exitoso se continuará desarrollando y mejorando, siempre y cuando se vea reforzado por el valor que aporta a sus cliente/usuarios. Es por esto que considero más adecuado el concepto de Línea de trabajo que el de Proyecto cuando me refiero a toda la vida de un producto o servicio (ver "Gestión ágil de productos. Líneas de trabajo en un producto a partir de su primera entrega").
En conclusión, la gestión ágil del trabajo no debe limitarse a Proyectos, sino que debería aplicarse a todo el trabajo encargado a los equipos. Así, por ser un término más general, prefiero referirme a "Gestión ágil del trabajo" en lugar de "Gestión ágil de proyectos".
El tema de este post se extiende en este otro: "El concepto Línea de trabajo: más allá de Proyectos, Productos o Servicios".
Patricio Letelier
No hay comentarios:
Publicar un comentario