Dos situaciones me han motivado a escribir este post. La primera es que más que una excepción, es casi una regla que un equipo de trabajo es responsable de más de un producto o servicio. Cuando todo el equipo está 100 % dedicado en un solo proyecto, la planificación y seguimiento se simplifica considerablemente. La mayoría de la literatura ágil asume esta condición favorable (que el equipo trabaja en solo un proyecto a la vez) o simplemente ignora dicha situación multi-proyecto. Por otra parte, el agilismo encuentra un importante obstáculo respecto de cómo convivir con (o cambiar) las prácticas tradicionales de planificación y seguimiento de proyectos, especialmente en organizaciones de mayor tamaño y/o donde hay prácticas tradicionales institucionalizadas, y posiblemente promovidas por una PMO (Project Management Office) o entidad similar. Así pues, pienso que es clave dotar de una visión "ejecutiva" al agilismo, para poder convencer de sus bondades y conseguir ese apoyo imprescindible de los niveles altos de la organización. Hasta ahora lo que más he visto/leído al respecto corresponde a una estrategia de confrontación con la gestión tradicional de proyectos. Mi recomendación como estrategia, y sin ceder un ápice respecto de las prácticas ágiles asociadas, es ilustrar y demostrar que la planificación y el seguimiento ágil son efectivos, y especialmente, que pueden reportar información del estado de los proyectos tan o más completa y rigurosa como la que se haría con un enfoque tradicional. Esto último es lo que debería enfatizarse como argumento y como punto de encuentro y convivencia con otros enfoques más tradicionales.
En esta Parte I voy a presentar la problemática y establecer la terminología para, posteriormente en la Parte II mostrar nuestra visión respecto de cómo abordarlo.
El término "proyecto" suele resultar ambiguo cuando se utiliza para referirse a cualquier trabajo que desarrolla un equipo. En el PMBOK "proyecto" se define como el esfuerzo temporal llevado a cabo para crear un producto, servicio o resultado, y que en cada cualquier éstos sean únicos. Aquí "únicos" se usa para para diferenciar proyecto respecto de "operaciones", las cuales de forma repetitiva producen productos u ofrecen servicios. Es importante puntualizar el significado de proyecto puesto que en el agilismo se enfatiza más el concepto de producto o servicio, pues se desea por ejemplo, establecer un buen flujo de trabajo terminado asociado a un servicio, o se desea hacer entregas frecuentes de nuevas versiones de un producto. Si bien cuando sólo interesa generar un buen flujo estaríamos más cercanos a "operaciones", cuando se hace una entrega frecuente de versiones de un producto la diferencia entre proyecto u operaciones puede no ser tan clara. Proyecto debería en un contexto ágil interpretarse como un sinónimo de Release (o entrega a producción) de un nuevo producto, o la creación de un nuevo servicio, o incluso un cambio o remodelación significativa de un producto o servicio (la cual conllevará un esfuerzo y tiempo importante).
Dicho lo anterior, un equipo puede estar ligado a varios productos o servicios. Por contraparte, un producto o servicio podrá estar ligado a varios equipos responsables de diferente proyectos (por ejemplo el equipo que lo crea o el equipo asociado a una remodelación importante) o equipos de operaciones (por ejemplo, el equipo de mantenimiento o el equipo de soporte). Así pues, la siguiente imagen ilustra la relación muchos-a-muchos entre equipo y producto/servicio.
Obviamente, esta situación "muchos-a-muchos" no es la más apropiada ni para el desempeño del equipo ni para el desarrollo o mantenimiento eficiente del producto o servicio. El equipo en esta situación debe distribuir su capacidad en la atención de varios productos o servicios, y los cambios de contexto penalizarán su desempeño. Esta situación es similar a la que se presenta cuando existe un WIP (Work in Process) demasiado alto en alguna actividad de un tablero kanban, el efecto negativo es el mismo, el alternar entre un trabajo y otro, sin privilegiar la finalización un determinado trabajo, reduce el desempeño del equipo. Pero limitar el WIP a nivel de ítems de trabajo es más sencillo que limitar el número de productos o servicios de los cuales es responsable un equipo, lo cual no suele ser decisión del equipo, sino de más alto nivel. Por otra parte, la tendencia en grandes empresas no suele ser crear equipos por producto o servicio. Así pues, tal como se refleja en la siguiente imagen, el trabajo sobre un producto o servicio lo pueden realizar diversos equipos, muchas veces creados puntualmente para un proyecto, o equipos externos encargados del outsourcing de ciertas actividades. Los protocolos de interacción entre estos diferentes equipos suelen penalizar el desempeño del producto o servicio visto de forma global.
Podríamos promover que se evite o reduzca dicha situación "muchos-a-muchos", sin embargo, no se trata de una decisión sencilla y rápida de implantar. Además, el tener diferentes equipos realizando trabajo sobre un mismo producto o servicio también tiene sus ventajas. Por ejemplo, basta pensar en el impacto que tendría prescindir del Outsurcing de actividades o de un área de QA, y la resistencia que encontraríamos para intentar hacerlo. Así pues, de antemano debemos estar preparados para ofrecer una forma se abordar de la mejor manera dicha situación, probablemente conviviendo con ella o haciendo mezclas. Por ejemplo, un Outsourcing in-situ, contando con el personal del proveedor en nuestra empresa no representa ningín inconveniente mayor de cara a nuestro propósito de aglutinar equipo. Si ponemos como condición previa a la implantación de agilismo que dicha situación "muchos-a-muchos" no exista, probablemente ni siquiera se llegue a disponer de una oportunidad para introducir agilismo en dicho contexto.
En mi opinión, la mejor forma de conseguir el apoyo de los altos ejecutivos para la introducción del agilismo (más allá de explicarles las bondades de la cultura y prácticas ágiles) pasa por dar respuesta a los siguientes desafíos (sin renunciar a los principios ágiles):
- Realizar la planificación y el seguimiento de los diferentes productos, servicios y/o de sus proyectos asociados.
- Coordinar los diferentes equipos que trabajan en un producto o servicio.
- Abordar eficazmente con un mismo equipo trabajo en varios productos o servicios durante un mismo período de tiempo.
- Supervisar el trabajos de diferentes equipos, disponiendo de reportes de estado que puedan equipararse a los que suelen disponer en proyectos tradicionales.
Cada uno de estos puntos los desarrollaré en detalle en la Parte II. Ahora concluiré esta primera parte enfatizando la gran oportunidad de mejora que en general se puede tener respecto del punto 4.
La forma en la cual se generan los reportes de estado en un contexto tradicional suele constituir una gran fuente de desperdicio ("waste"). A pesar de que la información de estado se genera a nivel operativo en cada equipo, ésta no suele ser aprovechada (al menos no restabilizada del todo) en el día a día del trabajo del equipo, y solo se recolecta de forma periódica para elaborar informes dirigidos a niveles superiores de supervisión. Por ejemplo, la gerencia pide informes a los departamentos, éstos a las unidades departamentales, éstas a los jefes de proyecto, y éstos finalmente recolectan la información que les proporcionan los miembros del equipo, por ejemplo, registrándola una vez a la semana. La siguiente imagen ilustra esta situación.
Las interrupciones y el tiempo invertido en dicha recolección de información y preparación de datos puede (y debería) evitarse. Hay que conectar el registro de dicha información con el trabajo díario de los miembros del equipo, de forma que el registro y recolección se realice de forma semi-automática. Además, hay que automatizar la elaboración de dichos reportes de estado, y finalmente, hay que promover una política de transparencia en cuanto a que dicha información esté disponible en todo momento y para todos los que la necesiten.
Continúa en Parte II: Planificación y Seguimiento ...
No hay comentarios:
Publicar un comentario