jueves, 2 de mayo de 2019

El concepto "Línea de trabajo": más allá de Proyectos, Productos o Servicios

Este post es una extensión o continuación del post "Gestión ágil del trabajo en lugar de Gestión ágil de proyectos".

El concepto "Línea de trabajo" es clave en TUNE-UP Process, nuestra propuesta metodológica para la gestión ágil del trabajo. Pero ¿por qué introducir este nuevo concepto "Línea de trabajo" y no utilizar "Proyecto", el cual se suele usar en muchas empresas para organizar el trabajo?. A continuación comentaré nuestras razones al respecto.
  • Un Proyecto tiene como propósito generar un nuevo Producto/Servicio (o una mejora significativa en uno existente). Además, un proyecto tiene una fecha de inicio y una de fin, sin embargo, el Producto/Servicio resultante esperamos que se aproveche mucho más allá del fin del Proyecto :-). Si queremos gestionar Productos/Servicios debemos gestionar el trabajo asociado a ellos, esté o no enmarcado en un Proyecto. Además, un Producto/Servicio puede, a lo largo de su existencia, tener varios Proyectos: el proyecto que originalmente lo generó y los posteriores proyectos que hicieron mejoras significativas en él. Así, una Línea de trabajo estará asociada a un Producto/Servicio pero podrá, opcionalmente, tener varios Proyectos (abiertos o cerrados), o simplemente no necesitar una definición de Proyecto pues se trata de un trabajo continuo, sin limitaciones de tiempo.
  • Un Proyecto es un contenedor de unidades de trabajo, similar a un Sprint, la diferencia es que la duración recomendada para un Sprint debería es de no más de un mes, un Proyecto no tiene esa restricción. Una interpretación razonable para la relación entre Proyecto y Sprint es la siguiente: un Proyecto que tenga una duración de más de un mes podría descomponerse en varios Sprints que permitan realizar un seguimiento más continuo del avance del Proyecto. Así, una Línea de trabajo, además del Backlog (contenedor por defecto), podría, opcionalmente, tener otros contenedores (contenedores temporales), sean éstos Sprints y/o Proyectos.
  • Un Proyecto podría estar asociado a varios Productos/Servicios (por ejemplo, un proyecto de integración de productos que requiere cambios en varios productos). Interesará gestionar el trabajo desde la perspectiva de cada Producto/Servicio involucrado (posiblemente sean equipos distintos los encargados en cada Producto/Servicio). Así, un Proyecto podrá contener unidades de trabajo de diferentes Líneas de trabajo.
  • Todo Producto/Servicio, una vez entregado, requerirá en cierta medida servicios de soporte y mantenimiento, y puede que en paralelo continúe desarrollándose (ver Gestión ágil de productos. Líneas de trabajo en un producto a partir de su primera entrega). Posiblemente será conveniente separar el trabajo de desarrollo, de soporte y de mantenimiento debido a que en general el trabajo de soporte y mantenimiento NO es planificable (no se conoce su alcance de antemano). No tiene mucho sentido denominar Proyecto a trabajo no planificable :-). Por otra parte, para evitar interrupciones en el trabajo de desarrollo (si el Producto/Servicio continuara desarrollándose), se recomienda que otras personas se encarguen del trabajo y soporte y mantenimiento (al menos el urgente). Así, convenientemente se podrían establecer Líneas de trabajo separadas para el trabajo de desarrollo, mantenimiento y soporte en cada Producto/Servicio.
  • El registro de información asociada al trabajo debe ser coherente con la utilidad o explotación que se hace de dicha información. Particularmente esto debería configurarse respecto de la información de planificación y seguimiento. Por ejemplo, en algunos casos podría no registrarse tiempos invertidos y en otros sólo en algunas actividades, se podría no estimar el esfuerzo del trabajo o estimarse usando Puntos u Horas Ideales, etc. Así, cada Línea de trabajo puede tener su propia política de registro y explotación de información de estimaciones y esfuerzo invertido. Sin embargo, todas las Líneas de trabajo dispondrían de una información y métricas básicas, las asociadas a sus tableros kanban y opcionalmente (registrando mayor información) dispondrían de otras métricas, tales como Velocidad, Lead Time, Cycle Time, Diagramas Burndown, Retrabajo, Distribución de esfuerzo, etc. 
  • En Productos/Servicios de gran envergadura usualmente trabajan muchas personas. Una recomendación ágil es que los equipos no deben tener más de 10 integrantes, con lo cual podrían formarse varios equipos "pequeños" encargados del trabajo en una parte de dicho Producto/Servicio. Así, el mismo Producto/Servicio podría existir diferentes Líneas de Trabajo, para diferentes "partes" del Producto/Servicio.
  • Incluso más allá de Productos o Servicios, puede que sea más conveniente agrupar el trabajo por Cliente, Región, Tipo de producto, etc., es decir, la agrupación del trabajo puede corresponder a cualquier criterio de interés, especialmente pensando en el seguimiento que se requiere del trabajo. Por ejemplo, si la pregunta a responder es usualmente ¿cómo está el trabajo asociado a un cliente? puede que sea conveniente que esa agrupación de trabajo se establezca como una Línea de Trabajo. Obviamente, sea cual sea la agrupación que determina una Línea de Trabajo, posteriormente usando filtros se puede ver desde otra perspectiva, pero es importante que el trabajo que agrupa una Línea de Trabajo favorezca esas preguntas más frecuentes que se hacen asociadas al estado del trabajo.
A través del concepto Línea de trabajo se promueve la diversidad en la organización del trabajo ofreciendo los grados de libertad antes indicados, de forma que la configuración de una Línea de trabajo se adapte al máximo a la naturaleza del trabajo que realiza el equipo y a sus necesidades de seguimiento.

Entonces, en concreto ¿qué es una Línea de Trabajo?. Tal como se muestra en la siguiente figura, una Línea de Trabajo es una agrupación de unidades de trabajo que intenta favorecer la planificación y seguimiento de dicho trabajo. 

Una Línea de Trabajo está compuesta por un Product Owner (representante de la parte negocio responsable del éxito del trabajo), Backlog (conjunto ordenado de unidades de trabajo que en momento determinado están sin terminar) y un equipo encargado de ejecutar el trabajo del Backlog. 

Opcionalmente, por necesidades del contexto de la Línea de Trabajo, esta podría tener además asociados Sprints y/o Proyectos, que son agrupaciones temporales de unidades de trabajo. Además, dependiendo del rigor que se requiera en los compromisos y su seguimiento, cada Línea de Trabajo podría tener una configuración diferente en cuanto a estimación del trabajo y/o registros de esfuerzo invertido. Adicionalmente, por las particularidades de procesamiento que requieran las unidades de trabajo de un Líneas de Trabajo, podrían tener disponibles diferentes Workflows (tableros kanban) para cada tipo de unidad de trabajo. Para conseguir que la metodología de trabajo se adapte a la naturaleza del trabajo es necesario establecer una adecuada configuración de las Líneas de Trabajo.

Finalmente, la identificación de Líneas de trabajo y la asignación de equipos encargados de dichas Líneas de trabajo es un proceso en el cual se estudien varios elementos: las características del contexto de trabajo (por ejemplo, en cuanto a necesidades de planificación y seguimiento), el personal disponible para abordar dicho trabajo, e incluso el o los posibles Product Owners involucrados. Además, periódicamente debería evaluarse la efectividad de las Líneas de trabajo establecidas y según sea conveniente, replantearlas.

Puedes consultar información más detallada respecto de Líneas de Trabajo en: "Organización Ágil del trabajo: Parte I y Parte II".

Nuestra propuesta de metodología ágil TUNE-UP Process está apoyada por la herramienta Worki que ofrece soporte a todas las características de configuración de Líneas de Trabajo comentadas en este post. Si te interesa puedes echarle un vistazo a la Ayuda de Worki y/o ponerte en contacto con nosotros ;- ).


Patricio Letelier

www.tuneupprocess.com 

No hay comentarios:

Publicar un comentario