En TUNE-UP Process el trabajo que se quiere organizar está dividido en Unidades de trabajo (UT). Las UT representan lo que solicita el cliente respecto de un producto o servicio, y es lo que reciben las personas encargadas de dar respuesta a dicha solicitud. Es importante destacar que las UT no representan trabajo técnico sino necesidades del cliente respecto de dicho producto o servicio. Como veremos más adelante, el trabajo técnico que requiera cada UT para su realización NO lo consideraremos como nuevas UT sino como actividades por las cuales pasar la UT. La siguiente imagen ilustra una "Parte cliente" que solicita la realización de un conjunto de UT a una "Parte proveedor" (las personas que podrían encargarse de dicho trabajo).
Para que dichas UT solicitadas por el cliente sean eficaz y eficientemente resueltas debe existir una adecuada organización de ese trabajo. Las prácticas ágiles ofrecen muchas oportunidades de mejora en el trabajo. Sin embargo, no basta con aplicar prácticas ágiles, si el trabajo no está bien organizado, probablemente no se conseguirá una mejora significativa usando el enfoque ágil.
TUNE-UP Process utiliza tres dimensiones para organizar el trabajo. A continuación se describen cada una de dichas dimensiones:
- Líneas de trabajo. Cada UT pertenece a una Línea de trabajo. El concepto Línea de trabajo permite diferenciar contextos de trabajo para así poder abordarlos según sus necesidades. Por otra parte, este concepto facilita la asignación de responsabilidad de trabajo a diferentes equipos, o si fuera el mismo equipo, facilitar la distribución de la Capacidad del equipo a cada Línea de trabajo que tenga asignada. Lectura recomendada: El concepto "Línea de trabajo": más allá de Proyectos, Productos o Servicios.
- Contenedores de UT. El contenedor por defecto es el Backlog, cada Línea de trabajo tiene un Backlog. Opcionalmente, una Línea de trabajo puede tener otros contenedores temporales denominados Sprints o Proyectos.
- Actividades (y/o Estados). Cada UT pasará en mayor o menor medida (según sus necesidades de proceso) por una cadena de actividades que representan el flujo de trabajo (workflow) aplicado a la UT. Esta dimensión representa el o los tableros kanban que tenga asociados la Línea de trabajo. Las actividades pueden variar según el contexto de trabajo pero a modo general se sugieren las siguientes (como columnas de un tablero kanban esencial): Registrar, Ordenar, Preparar, Ejecutar, Probar, y Terminada, las cuales se describen más adelante.
- Una UT pertenece solo a una Línea de trabajo, aunque pueda excepcionalmente cambiar de una Línea de trabajo a otra.
- Cada Línea de trabajo tiene sus propios contenedores, aunque puedan coincidir sus nombres, de hecho, cada Línea de trabajo tiene siempre el contenedor llamado Backlog.
- El Backlog está siempre abierto para incorporar nuevas UT, sin embargo, los Sprints pueden cerrarse, y con ello, no permitir incorporar UT adicionales.
- Cada Línea de trabajo, de acuerdo a la naturaleza de sus UT, puede tener asociados diferentes workflows (tableros kanban). Así, a cada UT se le aplica uno de esos workflows asociados, el que mejor se adapte a sus necesidades.
- Una UT podría estar en más de una actividad al mismo tiempo. Esto puede ocurrir porque el workflow asociado a la UT tiene definidas actividades en paralelo, o porque estando la UT en una actividad, al mismo tiempo se está adelantando parte del trabajo en otra actividad posterior o mejorando/corrigiendo algo ya realizado en otra actividad previa.
¿Cómo empezar a organizar el trabajo de forma ágil?
Mientras mayor sea el ámbito de implantación del enfoque ágil mayores serán los desafíos puesto que probablemente aumentará la diversidad de contextos de trabajo y de personas involucradas. Si bien parece lo ideal es conseguir una tranformación ágil de toda una empresa, puede ser demasiado ambicioso realizarlo todo a la vez. Es por ello que mi recomendación es hacer una implantación acotada a un conjunto reducido de personas que compartan un contexto de trabajo. Lo ideal es que las personas participantes tengan toda su dedicación en el ámbito de trabajo que se va a organizar, así solo tienen que estar aplicando un solo enfoque en todo su trabajo. Para organizar el trabajo deben realizarse las siguientes actividades (no necesariamente en este orden):
- Identificar las Líneas de trabajo. Para comenzar se podría considerar que cada producto o servicio es una Línea de trabajo, cada una de ellas con el nombre de dicho producto o servicio, por ejemplo, si tenemos el producto ACME, establecemos la Línea de trabajo ACME. Veamos ahora otros escenarios. Escenario 1: si (ahora o más adelante) el producto ACME tuviese trabajo de desarrollo, mantenimiento y soporte, podría ser conveniente tener más de una Línea de trabajo asociada al mismo producto, las Líneas de trabajo: ACME Desarrollo, ACME Mantenimiento, y ACME Soporte. Escenario 2: si ACME fuese un producto de gran tamaño y el personal disponible para trabajar en él fuese numeroso, podrían establecerse Líneas de trabajo asociadas a partes (módulos) del producto.Otra consideración importante respecto a la definición de Líneas de trabajo es prever en qué medida interesa tener agrupada o descompuesta la información para el seguimiento del trabajo y según esto separar o unir posibles Líneas de trabajo. Otra consideración adicional es el o los potenciales Product Owner (PO) involucrados, pues si las unidades de trabajo con canalizadas por diferentes PO esto podría sugerir distinguir las Líneas de trabajo según el PO asociado. Por todo esto, vemos que la división o agrupación de Líneas de trabajo dependerá de las necesidades del contexto de trabajo, lo importante es que en todo momento las Líneas de trabajo sean cómodas y efectivas para el PO y para el equipo en cuanto a la gestión del trabajo involucrado.
- Identificar el Product Owner para cada una de las Líneas de trabajo. Establecer quién o quienes desempeñarán este rol. (ver "Se busca Product Owner ...").
- Establecer el patrón de planificación y seguimiento que utilizará cada Línea de trabajo. ¿Se utilizarán estimaciones? ¿Se hará la estimación en Puntos u Horas Ideales? Si se usan Horas Ideales ¿cuáles actividades se estimarán? ¿Se registrarán tiempos invertidos? ¿Se registrarán tiempos en todas las actividades? Según lo anterior ¿cuáles serán la métricas que se utilizarán para realizar el seguimiento del trabajo en cada Línea de trabajo?.
- Asignar los colaboradores (el equipos) responsables de cada Línea de trabajo. Un equipo puede tener varias líneas asociadas, y en este caso deberá tener pautas claras respecto de la distribución de su capacidad entre ellas.
- Definir los Tableros kanban que necesita cada Línea de trabajo según la actividades que se deben realizar sobre sus UT. El diseño de un tablero kanban podría reutilizarse entre diferentes Líneas de trabajo. Además, una Línea de trabajo puede utilizar varios Tableros kanban, según lo requieran sus UT.
- Para cada Línea de trabajo decidir si se trabajará con Sprints y cuáles serán sus características. Esto lo comento en detalle en el post Sprints, "welcome to the real world"
- Establecer Proyectos cuando sea necesario. Normalmente un Proyecto se asocia a una Línea de Trabajo, pero podría darse el caso que en un mismo Proyecto se vean involucradas varias Líneas de Trabajo.
Gestión de Portafolio en TUNE-UP Process
Hasta ahora pareciera que le he quitado protagonismo a los Proyectos centrándome en el concepto Línea de trabajo. Sin embargo, los Proyectos no deberían quedar relegados a un simple atributo de una UT, para indicar que la UT está o no en cierto Proyecto. El día a día de las operaciones de una empresa es importante pero también se debe poner especial atención al progreso de los Proyectos que están en marcha pues suelen tener restricciones rigurosas de plazos, recursos y costos. Los Proyectos deberían ser ciudadanos de primera categoría en la organización del trabajo. Por esto, en TUNE-UP Process los Portafolios y sus Proyectos tienen un encaje elegante y potente dentro del mismo marco ya explicado.
En TUNE-UP Process los Portafolios son Líneas de trabajo cuyas UT son Proyectos. De esta forma los Portafolios disponen de todas las facilidades comentadas para las Líneas de trabajo "normales" (que no son Portafolios) y de igual forma las tienen los Proyectos respecto de las facilidades disponibles para UT. La siguiente imagen ilustra el modelo desde la perspectiva de Portafolios y Proyectos. Tal como las UT, los Proyectos también tienen un workflow y en este ejemplo hemos considerado como actividades generales para proyectos Inicio, Preparación, Ejecución y Cierre, sin embargo, podrían ser otras definidas según las necesidades de un tipo de proyecto.
En la figura se muestran dos Proyectos, uno del Portafolio 1 que está en el Sprint llamado 2019 (proyectos previstos para terminarse ese año) y en la actividad Ejecución, el otro del Portafolio 3 en el Sprint llamado 2018 y en la actividad Cierre.
Un proyecto también actúa como contenedor de UT (las cuales deben terminarse dentro de los plazos del Proyecto). Es por esto que resulta importante disponer de una relación entre un Proyecto y sus UT. Además, un Proyecto podría contener UT de distintas Líneas de trabajo. La siguiente imagen ilustra esta relaciones entre Proyecto y sus UT.
Nótese que las UT de un proyecto pueden pertenecer a diferentes Líneas de trabajo, y también puede darse que algunas UT de una Línea de Trabajo estén asociadas a un proyecto y otras a otro, o incluso UT de Línea de trabajo puede que NO estén asociadas a proyectos. Podría darse también que los proyectos no tengan descomposición (no se descompongan en UT de una Línea de trabajo), con lo cual el proyecto simplemente seguirá su workflow hasta terminar, hacíéndose todo el trabajo del proyecto en la UT que lo representa.
Líneas de trabajo, Product Owner y Equipos
La organización del trabajo no está completa hasta no establecer para cada Línea de trabajo su Product Owner y el equipo encargado. La siguiente imagen muestra un escenario muy simple e ideal de una Línea de trabajo.
En este escenario ideal el Product Owner centraliza todas las solicitudes de la "parte cliente" y las gestiona ordenándolas y definiéndolas en detalle para que el equipo las vaya procesando y entregando a la "parte cliente". En este escenario de ejemplo no se usan los elementos Sprint ni Proyecto. Recordad que cada línea de trabajo tendrá siempre al menos su Backlog (Sprints y Proyectos se utilizarán solo cuando sea conveniente). Existen diversas situaciones en cuanto a la combinación de Product Owner, Líneas de trabajo y Equipos. En el post "Se busca Product Owner ..." se presentan algunas de dichas posibles combinaciones desde la perspectiva del Product Owner.
Si un mismo equipo está encargado de más de una Línea de trabajo debe establecerse cómo distribuirá su Capacidad en cada una de ellas, por ejemplo, dedicar un 50% a cada una, y las mañanas a una y las tardes a otra. Esta decisión no debería tomarla el equipo sino que debería ser negociada entre los Product Owners asociados a las Líneas de trabajo involucradas. Aunque lo ideal sería que un equipo estuviese dedicado un 100% a una sola Línea de trabajo. Esto también es aplicable a nivel de cada integrante del equipo, es decir, lo ideal es que una persona esté dedicada al 100% a un solo equipo.
En un próximo post presentaré Worki, nuestra herramienta que ofrece soporte al modelo y organización del trabajo propuestos por TUNE-UP Process.
Excelente articulo, gracias por compartirlo Patricio.
ResponderEliminar