Tiempo medio de lectura: 10 minutos.
Este artículo explica qué es una dependencia, qué tipos de dependencias hay y cómo gestionarlas con el método Kanban para aumentar la agilidad organizativa.
Cursos relacionados
| Fecha | Ciudad | Curso |
|---|
Artículos relacionados
Contenidos del artículo
Qué es una dependencia
Las dependencias nos han hecho sufrir más o menos en silencio a todos los que hemos gestionado proyectos en organizaciones grandes y complejas o, peor todavía, entre una constelación de organizaciones. Porque este tipo de entornos implican una multiplicidad de actores y de dependencias muy intrincadas.Una dependencia es una situación en la que el progreso de un ítem está subordinado a la ejecución a tiempo de otra acción, item o el cumplimiento de una determinada condición.
Efectos de las dependencias
Cuando impactan, las dependencias tienen una serie de efectos:- Aumentan el lead time de los proyectos o los servicios y su variabilidad.
- Reducen los grados de libertad a la hora de secuenciar las actividades y los ítems.
- Provocan conflictos entre equipos que compiten por recursos escasos.
- Por el retraso de actividades precedentes a esa dependencia de las que ésta dependía.
- Por la desviación en el tiempo de ejecución de esa dependencia –ya sea por una mala estimación, pura incertidumbre, mayor complejidad de la prevista, etc.
- Porque el recurso que la debe resolver es un cuello de botella, ya sea por falta de capacidad para atender la demanda o bien por no estar disponible en ese momento.
Tipos de dependencias
El hecho de que una actividad sobre un ítem no pueda iniciarse o progresar si otra actividad no se ha completado sucede en workflows en los que varios inputs, actividades y sus recursos intervienen para producir un mismo ítem en un orden requerido. Respecto a la no disponibilidad de un recurso, ésta sucede típicamente cuando varias actividades –de un mismo proyecto o de diferentes proyectos– lo utilizan. Las fuentes de dependencias según su origen se debe a que se necesita en el proceso:- Inputs concretos en forma de un producto o servicio.
- Recursos especializados, ya sea porque disponen de conocimientos o de medios específicos.
- Una información para poder realizar adecuadamente el entregable.
- Un control.
Un input en el proceso crea claramente una dependencia que puede introducir retrasos si no se resuelve a tiempo. En este caso, el proceso necesita un producto o servicio de un proveedor externo, un actor que se considera fuera de dicho workflow.
En otras ocasiones se necesita la participación directa en dicho proceso de un recurso -ya sea un medio material o un equipo de personas.
Esos recursos con los que tenemos dependencias tendrán conocimientos o bien medios muy especializados. Tiene sentido que dediquemos a determinadas personas o áreas a realizar actividades de uso poco frecuente o que requieren el uso de una herramienta cara. O bien que lo hagamos porque esas actividades son críticas (p. ej. ciberseguridad) y se necesita mantener un estricto control. Y eso creará una dependencia.
La especialización de recursos y roles o el diseño de procesos que están detrás de esas dependencias surgen por causas técnicas, económicas y organizativas.
Cabe decir que la diferencia entre necesitar un input o un recurso especializado puede ser sibilina, ya que se produce a partir del criterio de considerar que la contribución procede de un actor interno o externo.
Esta diferenciación es bizantina ya que depende de si decidimos obtener un determinado input ya finalizado o de si decidimos hacer participar un recurso para hacerlo dentro del proceso. En otras palabras, depende de si el recurso se externaliza o internaliza. Por ello, es innecesario abundar en ella./
Una forma típica de dependencia es que realizar una actividad requiere información que tiene otro rol o actor. El ejemplo típico es cuando necesitamos contactar con nuestro interlocutor con el cliente para saber qué se ha acordado con el cliente o si el cliente ha realizado los preparativos necesarios.
Finalmente aparece una dependencia por la existencia de un control en el proceso, de una autorización es necesaria para tener permiso para ejecutar una actividad o acceder a un recurso, input o información.
Los motivos de porque aparecen las dependencias anteriores pueden deberse a:
- El diseño técnico u operacional del proceso.
- El diseño organizativo del proceso.
El diseño técnico u operacional del proceso crea dependencias de forma necesaria. La tecnología utilizada requiere unos ciertos componentes y eso lleva a un cierto orden temporal necesario en la disposición de esos inputs, recursos e informaciones del proceso. Lo que origina a una cierta secuencia de actividades necesarias para obtenerlos.
Eso establece un cierto orden en la ejecución de actividades que impone la técnica o la ordenación de operaciones del proceso.
Para desplegar un ítem debemos haberlo desarrollado previamente. El testing es posterior al desarrollo).
Aunque ese orden técnico existe un cierto margen de libertad y de elecciones concretas en cómo realizar las actividades. Por ejemplo, se pueden realizar determinadas partes del testing concurrentemente con el desarrollo para que esta fase sea más rápida.
Luego encontramos dependencias creadas por el diseño organizativo del proceso. Es decir, pors la forma concreta en la que hemos diseñado y distribuido las operaciones en la organización.
Al definir la estructura organizativa se ha definido una forma de dividir el trabajo y habilidades entre roles y agruparlo en equipos, áreas y departamentos.
En ese diseño organizativo también se establecen niveles de control y mecanismos de comunicación internos. Esto son unas políticas sobre quién puede autorizar qué y quién comunica o es comunicado sobre qué.
Este diseño organizativo depende en parte del diseño técnico del proceso. Pero en muy buena parte depende de tanto factores económicos –concentrar actividades para beneficiarse de curvas de experiencia o economías de escala– y de la cultura, idiosincracia y juegos políticos internos de la propia organización.
Así, una buena organización puede crear un número mínimo de dependencias y que estas sean coherentes con los factores claves del éxito de su estrategia.
Una mala organización dividirá excesivamente los roles entre áreas y departamentos y con ello creará un número elevado de transferencias de trabajo entre roles y áreas. Eso puede multiplicar las dependencias hasta un extremo que dificulte enormemente la adaptabilidad y la respuesta rápida.
En cualquier caso, si hay un elevado número de dependencias se dificulta enormemente la entrega incremental del backlog y la adaptación en la priorización de los ítems.
Las metodologías de gestión de proyectos han reconocido siempre la importancia de las dependencias. Pero la forma de tratarlas ha sido diferente.
El enfoque de la gestión de proyectos tradicional sobre las dependencias
La gestión de proyectos tradicional intenta gestionar las dependencias modelándolas y controlando los cambios en el proyecto así como las interacciones entre los actores.
Cuando se realiza un diagrama de Gantt o un PERT en la planificación de un proyecto, se analizan las dependencias entre actividades, recursos y entregables para modelar cuáles son precedentes y cuáles son posteriores. A partir de aquí y de las estimaciones de duración se planifica el calendario del proyecto.
Y la duración del proyecto no es sino el camino crítico, la ruta de inicio a fin con la secuencia de actividades dependientes más larga.
También se establece la estructura de gestión para gestionar y coordinar la ejecución. Así mismo se implantan procesos de control de cambios para evaluar –y aceptar o rechazar– las eventuales modificaciones en el alcance, coste y calendario del proyecto.
La enfoque de la gestión ágil de proyectos sobre las dependencias
Mientras las metodologías tradicionales gestionan las dependencias existentes, las metodologías ágiles no sólo lo hacen sino que también se las cuestionan:
- ¿Qué dependencias hay?
- ¿Cómo se pueden eliminar, reducir o acortar?
Por eso las metodologías ágiles ponen mucho énfasis en la comunicación y coordinación continua de los equipos para reconocerlas y resolverlas lo antes posible. Y también ponen énfasis en la autoorganización como una vía para la resolución, cuando no reducción, de las dependencias.
Otro aspecto que también resaltan las metodologías ágiles es la necesidad de preparar los ítems (con la Definition of Ready en Scrum o los pull criteria en Kanban) para asegurarse de que, además de definir y clarificar los ítems, las dependencias asociadas han sido identificadas y, dentro de lo posible, resueltas antes de comprometer dichos ítems.
La gestión de las dependencias en Kanban
Kanban dispone de una serie de prácticas y subprácticas para tratar las dependencias, ya que estas son una fuente de esperas y riesgos de los ítems.
En la práctica de “Visualizar”, las dependencias se atacan con subprácticas como:
- Indicar los ítems dependientes con decoradores o con otras señales visuales, como diferentes colores de tarjetas.
- Identificar el tipo de dependencias (padre-hijo o peer-to-peer), para ayudar al equipo a resolverlas de forma adecuada.
- Identificar las dependencias concretas con, por ejemplo, checklists.
- Indicar en la tarjeta fechas de integración, ya que estas crean un punto concreto de dependencias.
- Señalar cuándo la dependencia se convierte en un bloqueo, para realizar una análisis de causas y aplicar acciones de mejora al respecto.
En la práctica de ”Gestionar el flujo”, encontramos varias formas de tratar las dependencias:
- Utilizar una matriz de dependencias para marcar la vinculación entre ítems.
- Analizar periódicamente los bloqueos derivados de dependencias.
- Escalar las dependencias que no puedan resolverse.
En la práctica de “Explicitar las políticas”, se recomienda:
- Disponer de criterios de arrastre (pull criteria) para aceptar los ítems, entre los cuales está la identificación y tratamiento de las dependencias.
- Tener políticas referidas a cómo y cuándo escalar dependencias si estas son un problema.
- Establecer SLAs sobre los servicios dependientes.
En la práctica de ”Implementar ciclos de feedback”, sin querer ser exhaustivos, encontramos varias cuestiones referidas a las dependencias:
- En el Replenishment, contemplar las dependencias antes de comprometer los ítems.
- En el Daily Kanban, la resolución de dependencias y bloqueos para conseguir el flujo.
- En las revisiones (Service delivery review, Flow Review,…), el análisis dels impacto de las dependencias y la decisión de acciones de mejora.
- Una es la Delivery Planning Meeting es un evento que prepara entregas concretas y entre los puntos que se tratan son los riesgos a la misma, entre los cuales se encuentran, lógicamente, las dependencias.
- En la Operations Review se tratan los efectos entre servicios dependientes.
- Y la Risk Review tratar con riesgos, entre los cuales se encuentran las dependencias.
También en la práctica de “Mejorar colaborativamente, evolucionar experimentalmente”, que está vinculada a la práctica anterior, se pueden incluir las dependencias en el análisis de las fuentes de retraso, así como el análisis del impacto y probabilidad de los bloqueos, para poder realizar sobre ellas acciones de mejora.
Ideas clave sobre las dependencias
Las dependencias son una fuente de riesgos para la entrega de nuestro sistema. Como tales, deben ser claramente identificadas y gestionadas para evitar impactos adversos.
Pero también deben ser reducidas. Y eso exige replantear el diseño de nuestros procesos y organización, en especial la distribución de conocimientos, información y autoridad.
Aquí las metodologías como Scrum o Kanban dan un paso más allá y permiten plantear soluciones que aumentan la agilidad organizativa.
¿Quieres saber más?
Puedes profundizar en los principios de Kanban con nuestro curso de Kanban.
¿Quieres recibir más información y recursos de calidad?
¡Suscríbete a nuestra newsletter mensual!
Cada mes enviamos una newsletter a más de 1.200 personas con contenidos, recursos y ofertas especiales de nuestros cursos. Queremos ofrecer contenido de calidad y sin spam.
