jueves, 2 de mayo de 2019

Organización ágil del trabajo

Este post es la continuación de "Un modelo conceptual para la gestión ágil del trabajo", en el cual se explican los conceptos básicos utilizados para gestionar el trabajo usando TUNE-UP Process, nuestro framework para la implantación del enfoque ágil. En este post se se ofrecen pautas para que a partir del modelo conceptual de TUNE-UP Process se establezca una organización del trabajo y de los equipos responsables de realizarlo.

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): RegistrarOrdenarPreparar, Ejecutar, Probar, y Terminada, las cuales se describen más adelante. 
La siguiente imagen ilustra cómo usando estas tres dimensiones se pueden organizar las UT de un ámbito de trabajo. En la imagen se muestran dos UT, una pertenece a la Línea de trabajo 1, está en el Sprint 2 y está en la actividad Ejecutar, la otra pertenece a la Línea de trabajo 3, está en el Backlog y está en la actividad Preparar.

Algunas restricciones en cuanto a la organización de UT en este espacio tridimensional:
  • 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. 
Cada nueva UT se crea en el marco de una Línea de trabajo, y por defecto en su Backlog (podría ponerse directamente en un Sprint que esté abierto) y comenzaría su proceso en la actividad de su workflow. Posteriormente la UT continuaría su proceso pasando por otras actividades, y por otro lado, si la Línea de trabajo utiliza Sprints en algún momento la UT se moverá desde el Backlog a un Sprint para ser terminada. Cuando se usan Sprints lo normal es que en el Backlog se realice la actividad Preparación (trabajo asociado a especificación, estimación, diseño, etc.) y luego al pasar a un Sprint esencialmente se realicen las actividades de Ejecutar (implementar el requisito o cambio) y Probar (comprobar que el cambio ha sido realizado según lo esperado).

¿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.

Patricio Letelier



Se busca Product Owner ...

En el año 2012 publiqué un par de posts asociados a los roles propuestos por Scrum: "Roles de Scrum Parte I y Parte II". Me parece que todavía este tema de los roles no termina de estar adecuadamente resuelto en la práctica, y en especial el rol de Product Owner (PO). 

Respecto del rol PO mi posición es bastante radical: pienso que no tiene sentido poner un equipo a trabajar si no se ha establecido un buen PO que asegure que el esfuerzo invertido por el equipo será rentabilizado (una de las responsabilidades del PO). Pero por otra parte, reconozco que es muy difícil conseguir el PO ideal. En este post comentaré cómo se puede implementar rol de PO en el mundo real, y que sin ser el PO ideal, puede ser eficaz. Comencemos con la siguiente definición de PO, que he traducido desde la Scrum Guide (visitada en abril de 2019).

--------------------------------------

"El Product Owner es responsable de maximizar el valor del producto resultante del trabajo del Equipo de Desarrollo. El cómo conseguir esto puede variar significativamente dependiendo de la organización, de los equipos, y de las personas.

El Product Owner es la única persona responsable de gestionar el Product Backlog. La gestión del Product Backlog incluye:
  • Expresar claramente los ítems del Product Backlog;
  • Ordenar los ítems del Product Backlog para el mejor cumplimiento de objetivos y misiones;
  • Optimizar el valor del trabajo que realiza el Equipo de Desarrollo;
  • Asegurar que el Product Backlog es visible, transparente, y claro para todos, y en qué es lo trabajará próximamente el Equipo Scrum;
  • Asegurar que el Equipo de Desarrollo entiende los ítems del Product Backlog al nivel necesario;
El Product Owner puede hacer todo este trabajo, o puede dejar que lo haga el Equipo de Desarrollo. Sin embargo, el Product Owner sigue siendo el responsable de ello ("remains accountable").
El Product Owner es una persona, no un comité. El Product Owner puede representar los deseos de un comité respecto del Product Backlog, pero quienes quieran cambiar la prioridad de un ítem en el Product Backlog deben dirigirse al Product Owner.

Para que el Product Owner tenga éxito, toda la organización debe respetar sus decisiones. Las decisiones del Product Owner se hacen visibles en el contenido y ordenamiento del Product Backlog. Nadie puede forzar al Equipo de Desarrollo a trabajar en otros requisitos (fuera del Product Backlog). ".

------------------------------------

De esta definición remarcaría que el PO ideal de Scrum es una sola persona, que en la práctica desempeña tres roles tradicionales: 
  • Es un buen Cliente. Tiene autoridad para hacer respetar sus decisiones respecto de contenido y orden de realización del trabajo. Tiene visión del resultado esperado y del valor que aportará.
  • Es un buen Jefe de Proyecto. Realiza la planificación y seguimiento del trabajo.
  • Es un buen “Analista”. Explica con suficiente detalle el trabajo que debe realizar el equipo.
De esta forma, ya podemos hacernos una idea de lo difícil que puede ser encontrar al PO ideal. Aunque Scrum en su definición deja la posibilidad que el PO delegue sus tareas al equipo, pero no debe dejar de ser responsable de ellas. Esto no resuelve el hecho que el PO debería ser una sola persona. Desgraciadamente este PO como una sola persona no la he encontrado en ninguna empresa :-). 

En el mundo real lo que hemos podido establecer como una solución eficaz, aunque no ideal, es componer la figura de Product Owner sumando a varias personas que deben trabajar muy coordinadamente. Un ejemplo de esta situación se ilustra en la siguiente imagen. 

Como se observa en este ejemplo, el PO se ha compuesto por cuatro personas en sus roles tradicionales. El representante de la "Parte cliente" y que tiene autoridad sería el Product Manager, pero probablemente no tiene suficiente tiempo (ni ganas) de definir las UT a un nivel de detalle necesario para para el equipo, ni para ordenar el trabajo. Así, el Analista de Negocio se encargará de proporcionar dicha información y priorizarla, pero probablemente no podrá hacerlo en los términos técnicos requeridos por el equipo, con lo cual alguna persona del equipo actuará como Analista para realizar las especificaciones de las UT. Finalmente, alguien debe encargarse de gestionar plazos, costos y recursos, si el Product Manager no lo hace podríamos asignar esa responsabilidad al Jefe de Proyectos (el tradicional) que en este ejemplo hemos supuesto que es de la parte del proveedor. Obviamente este ejemplo de tratamiento PO no es el ideal, deja en evidencia estamos prácticamente manteniendo los roles tradicionales :-), pero al menos nos señala esta debilidad y se destaca que estas personas deben trabajar de forma muy coordinada. A partir de una solución como esta, una evolución hacia una solución más ágil en cuanto al PO sería que el Product Manager (o equivalente) delegue solo el trabajo en otras personas pero se mantenga responsable y muy involucrado en todo el trabajo, asumiendo que esto le significará mucha más dedicación a ello. 

Otro usual desafío respecto del PO son los conflictos de intereses entre Product Owners que comparten la Capacidad de un mismo equipo. Veamos primero una situación que NO presenta este problema, ilustrada en la siguiente imagen.


En esta imagen se muestran tres Líneas de trabajo, cada una con sus correspondientes PO, Backlog y equipo asignado. Si la Línea de trabajo tiene asignado un equipo totalmente dedicado a ella no hay ningún inconveniente. Tampoco habrá conflicto de intereses si el equipo tiene asignada más de una Línea de trabajo pero todas tienen el mismo PO, pues será él quien decida la distribución de Capacidad del equipo a cada Línea de trabajo. La siguiente imagen ilustra la situación en la cual SÍ que se presentarán conflictos entre Product Owners.


En este caso tres Líneas de trabajo están encargadas al mismo equipo, pero cada una de ellas tiene un PO diferente. Un caso así, con PO diferentes y distintas Líneas de trabajo ocurre normalmente cuando las solicitudes de trabajo provienen de diferentes fuentes. Por ejemplo, cuando los PO son comerciales que tienen carteras de clientes separadas. Por otra parte y desgraciadamente también es usual que un mismo equipo se encargue de varias Líneas de trabajo. Hay que ser consciente de la degradación del desempeño del equipo que puede provocar el cambio de contexto al trabajar cambiando de una Línea de trabajo a otra.  Así pues en este caso: diferentes PO en líneas que comparten el mismo equipo, probablemente tengamos que establecer el PO como una instancia superior (algún tipo de comité) con autoridad para determinar la distribución de Capacidad del equipo a cada una de las Líneas de trabajo. En dicho instancia superior participarían los PO de cada Línea de trabajo. Esto se ilustra en la siguiente imagen.


En conclusión, y a pesar de lo comentado debo enfatizar que estoy totalmente de acuerdo con la propuesta de PO de Scrum :-), Es indudable que contar con el PO que define Scrum sería muy beneficioso para la eficacia y eficiencia del trabajo realizado por el equipo. Por esto, aunque sea muy difícil establecer dicho PO, debemos tomarlo más bien como una excelente referencia de lo que sería ideal e intentar acercarnos lo más posible a él. Cualquier solución que encontremos, y que probablemente no será el PO ideal, nos alertará al mismo tiempo de las carencias que tenemos al respecto y debería llevarnos a cuidar la coordinación que tienen que mantener los involucrados al desempeñar, de forma complementaria, las responsabilidades asociadas al rol de PO.  



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).
  • Un Proyecto es un contenedor de UT, 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, 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 UT 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 explotación de información. 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, Re-trabajo, 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 una Línea de trabajo para cada uno de sus equipos.
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.

Finalmente, la identificación de Líneas de trabajo y el establecimiento de equipos asociados a dichas Líneas de trabajo debe ser 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.


Patricio Letelier

www.tuneupprocess.com 

miércoles, 1 de mayo de 2019

"Gestión ágil del trabajo" en lugar de "Gestión ágil de proyectos"

En el PMBOK un proyecto se define como: “A project is a temporary endeavor undertaken to create a unique product, service, or result. The temporary nature of projects indicates that a project has a definite beginning and end. ...". Sin embargo, en la mayoría de empresas (y herramientas) se usa el término "Proyecto" casi como sinónimo de "trabajo", incluso sin existir fechas de inicio y fin predeterminadas, o cuando el resultado no es algo claramente nuevo (como es el caso de servicios de mejora y mantenimiento). Más allá de cuestiones de terminología, lo realmente importante es que este uso indiscriminado del término Proyecto podría determinar una estrategia errónea para abordar el trabajo. Por ejemplo, poco sentido tendría el imponer una planificación con Sprints rígidos, entregas pre-establecidas, cálculos de esfuerzo y de capacidad requerida, etc., solo porque el trabajo que se realizará ha sido denomino "Proyecto de mantenimiento de 2020", y siendo que se trata de un acuerdo de mantenimiento para un producto software que acabamos de entregar. Obviamente dicha estrategia es errónea básicamente porque el alcance a priori es desconocido, no se sabe qué mejoras o correcciones se solicitarán durante el período de realización del trabajo, con lo cual no es una situación planificable.

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

www.tuneupprocess.com