En un par de posts anteriores comenté respecto del "Agilidad en un contexto multiproyecto" (Parte I y Parte II). En este post veremos otra forma de "multiproyecto" que ocurre cuando en el marco de un mismo producto se presentan varias líneas de trabajo con diferentes necesidades de gestión. El reconocimiento y gestión diferenciada de estas líneas de trabajo es clave para el buen funcionamiento de los equipos encargados. En el post "Gestión ágil de productos que tienen varias líneas de trabajo" ya comenté unos aspectos generales respecto de tener varias líneas de trabajo sobre un mismo producto. Ahora veremos una cuestión específica y natural que lleva a una línea de trabajo de desarrollo a transformarse en tres líneas de trabajo sobre el mismo producto.
Mientras un producto/servicio se está desarrollando tiene una una sola línea de trabajo, la línea de Desarrollo, pero a partir de la primera entrega (paso a producción) tendremos que tomar decisiones respecto de cómo abordar las tres líneas de trabajo que existirán a partir de ese momento: Desarrollo, Mantenimiento y Soporte, tal como se ilustra en la siguiente figura.
La situación planteada conlleva tomar decisiones en dos aspectos: qué equipo(s) se encargará(n) de cada línea de trabajo a partir de la primera entrega y qué configuración de gestión se utilizará en cada una de las líneas de trabajo. Comentemos primero respecto de la configuración de gestión.
La línea de trabajo de Desarrollo normalmente es "planificable", es decir, puede definirse a priori lo que se va a desarrollar y acordar con el cliente el alcance, plazos y costo (es decir, estamos en un escenario de proyecto), y opcionalmente (pero deseable) el trabajo se puede organizar en Sprints que agrupan los cambios para producir versiones con una regularidad de un cierto número de semanas (Sprints de no más de 4 semanas). Aún siendo planificable otra opción sería trabajar sin el marco de proyecto, solo definiendo Sprints mientras el cliente estime conveniente que vale la pena continuar. Incluso podría trabajarse sin Sprints ni proyecto, simplemente estableciendo priorización del trabajo, abordándolo según dicha priorización y consiguiendo nuevas versiones al implementar cada nueva característica. Por otra parte, la línea de trabajo de Desarrollo, a partir de la primera entrega tiene una exigencia mayor respecto de pruebas de regresión y no interferencia con el uso que ya están haciendo del producto los usuarios. Además, si ya se tiene una versión en producción las siguientes versiones son en mayor medida potenciales entregas.
Por otra parte, la línea de trabajo de Soporte es claramente "no planificable", no podemos saber qué dudas, mejoras, o fallos nos reportarán los usuarios (llamémoslos tickets). Aunque puede que tengamos alguna acumulación de tickets pasados pendientes de resolver, los cuales podrían en alguna medida planificarse, el Soporte es un servicio, y como tal es muy importante la velocidad de respuesta, con lo cual la idea es priorizar, ejecutar y resolver lo más rápido posible los tickets. Además, las acumulaciones de tickets no resueltos se producirán probablemente por escalamiento a otro nivel de servicio, en particular las mejoras y fallos se suelen derivar a la línea de trabajo de Mantenimiento o de Desarrollo. Cuando dichas mejoras o fallos se implementan en una nueva entrega del producto los correspondientes tickets puedes darse por cerrados.
Finalmente, la línea de trabajo Mantenimiento podría no reconocerse como línea independiente y considerarse incluida en la línea de Desarrollo ya que en ambos casos se trata de cambios de producto y el equipo realiza básicamente el mismo trabajo técnico. Sin embargo, conviene que el Mantenimiento esté diferenciado, especialmente si tenemos una demanda importante de trabajo urgente/pequeño que debe/puede hacerse de inmediato para ofrecer respuesta rápida. El Mantenimiento está a medio camino entre trabajo planificable y no planificable, ya que no todos los cambios son urgentes o pequeños. Todo lo no urgente o de mayor envergadura podría planificarse en Mantenimiento, o incluso pasarse para ser abordado por la línea de trabajo de Desarrollo. Para una línea de Mantenimiento es usualmente recomendable trabajar con Sprints flexibles en cuanto a contenido y duración, es decir, los Sprints podrían contener desde solo un cambio, implementado y entregado inmediatamente, hasta acumular varios cambios que se implementan en unos pocos días y luego se entregan. Esta flexibilidad también podría darse respecto a no llegar a terminar todo lo que se pretendía, porque podrían incorporarse otros ítems durante el Sprint.
El flujo de trabajo de una línea de Soporte (en la cual se gestionan tickets) difiere significativamente del flujo de trabajo de las líneas de trabajo de Desarrollo y de Mantenimiento (en las cuales se gestionan cambios en el producto). De todas formas, en cada línea debería poder visualizarse el estado del trabajo no terminado asociado a la línea (lectura recomendada: Multikanban, un tablero kanban para contextos multiproyecto).
Respecto al equipo encargado de las líneas de trabajo, si es el mismo equipo el que va asumir todo el trabajo habrá que establecer ciertas directrices para la distribución de su capacidad en cada línea de trabajo, asignando cierta capacidad a la línea de Desarrollo y reservando un porcentaje de capacidad para abordar las otras dos líneas. La línea de Soporte es buena candidata para ser encargada a un equipo independiente, que incluso pueda encargarse del servicio de Soporte para varios productos ofrecidos por la empresa. Sin embargo, como comenté antes, los tickets que requieran cambios en producto deben sincronizarse con ítems en líneas de trabajo de Mantenimiento o Desarrollo. Las líneas de Mantenimiento y Desarrollo podrían encargarse a un mismo equipo pero aún así conviene gestionarlas como dos líneas en las cuales el equipo debe distribuir su capacidad. Si el Desarrollo y el Mantenimiento están encargados a equipos diferentes es muy importante su coordinación pues ambos equipos estarán generando versiones del mismo producto, es decir, cada uno tendrá su ritmo de generación de versiones y pueden coincidir en las partes del producto sobre las cuales están trabajando o que los cambios que realiza un equipo tengan impacto en el trabajo del otro equipo.
En un enfoque tradicional puede que esta situación se postergue hasta el final del proyecto de desarrollo, es decir, que se haga una sola entrega al final. Pero si seguimos un enfoque ágil se intentará realizar entregas frecuentes durante el desarrollo (aunque acotadas en cierta medida). Las entregas frecuentes permiten hacer una validación más certera para confirmar que el desarrollo está bien encaminado, pero además, contribuyen a no acumular "tensión" respecto a aspectos que suelen provocar retrasos y problemas cuando se dejan todos para ser resueltos al momento de la entrega final, tales como: formación de usuarios, integración con otros sistemas, migraciones de datos, infraestructuras necesarias para que opere el sistema, etc. Así, todos estos aspectos se van abordando incrementalmente según lo requieran las entregas parciales.
En cualquier caso siempre llegará el momento en que una línea "pura" de Desarrollo genere las tres líneas que hemos indicado y con ello nos enfrentemos a las cuestiones antes comentadas.
Patricio Letelier
No hay comentarios:
Publicar un comentario