Sobreasignación de recursos y nivelación: cómo detectarla y corregirla a mano, con un ejemplo

Un plan puede respetar todas las dependencias y aun así ser imposible. En el lanzamiento de la app que usamos a lo largo de esta guía las fechas son correctas, pero los días 8 y 9 Dana, la única tester, tiene asignadas a la vez dos tareas de pruebas a jornada completa. Un diagrama de Gantt dibuja una barra por tarea, así que las dos barras de Dana en los mismos días parecen un par más de barras solapadas.

Esta guía explica cómo medir la sobreasignación de recursos día a día frente al calendario de cada persona y cómo eliminarla a mano con cuatro ajustes: suavizar dentro de la holgura, reasignar, retrasar y añadir capacidad. Cada ajuste se prueba sobre el mismo lanzamiento, con el día de fin que produce y los días sobreasignados que deja.

Qué es la sobreasignación de recursos#

La sobreasignación de recursos es una situación del cronograma en la que a una persona o a un equipo se le asigna en un periodo más trabajo del que permite su tiempo de trabajo disponible. Si no se corrige, se convierte en un retraso del fin: en el ejemplo de abajo, dos días al 200 % para una tester llevan el lanzamiento de una app del día 12 al día 14 cuando nadie más puede hacer una prueba. Además, queda oculta. La Oficina de Rendición de Cuentas del Gobierno de EE. UU. (GAO) explica el motivo en su Schedule Assessment Guide: un cronograma sin asignación de recursos presupone un número ilimitado de recursos con disponibilidad ilimitada^[1].

La solución se llama nivelación de recursos (resource leveling en inglés). La GAO la describe como el ajuste del inicio programado de las actividades, o de las asignaciones de trabajo de las personas, para tener en cuenta su disponibilidad, y añade que puede ser tan sencilla como pasar trabajo de una persona sobreasignada a otra infrautilizada o retrasar un inicio hasta que la persona quede libre^[1]. La nivelación que se mantiene dentro de la holgura, de modo que la fecha de fin no se mueve, se conoce como suavizado de recursos; Microsoft Project la ofrece con la opción Redistribuir solo dentro del margen de demora disponible^[2].

Quién necesita revisar la sobreasignación, y cuándo#

Un plan necesita esta revisión a partir de unas 3 personas con nombre y 15 tareas, que es nuestra regla práctica para el punto en el que alguien acaba con dos tareas abiertas el mismo día. La hace el project manager, que toma las decisiones de nivelación. Los responsables de equipo leen el resultado de su gente y, en equipos de 4 a 15 personas, cada uno lee su propia fila para ver qué tareas se han movido. El sponsor solo ve la consecuencia: una fecha de fin.

Haz la revisión después del primer borrador completo, cuando ya estén las dependencias, las duraciones y los responsables, y antes de guardar la línea base. Después repítela cada vez que se mueva una fecha, porque un retraso aguas arriba empuja tareas hacia los días de otra persona.

Hay dos situaciones en las que se puede omitir. Quien trabaja en un solo flujo cada vez, o un equipo que toma tareas de un tablero con límite de trabajo en curso, no puede tener doble reserva en el plan, porque el límite ya fija cuántas tareas tiene cada persona. Un plan que se queda en las fases no tiene nada que nivelar: la guía de la GAO dice que la nivelación nunca debe aplicarse a cronogramas resumidos^[1].

Cómo se mide la carga, día a día#

La carga de una persona en un día son las horas de todas las tareas que tiene asignadas ese día, cada una multiplicada por su asignación, divididas entre las horas que trabaja ese día; por encima del 100 % está sobreasignada. En esta guía la asignación es la parte del tiempo que una persona dedica a una tarea (50 %, 100 %), y la carga es siempre esa proporción diaria.

Para Dana en el día 8 del ejemplo, con dos tareas al 100 % y una jornada de 8 horas, la carga es (8 + 8) / 8 = 200 %.

El calendario cambia el denominador. En un día libre es cero, así que cualquier trabajo planificado es sobreasignación. Medio día libre deja 4 horas, y una tarea al 100 % pasa a ser 8 / 4 = 200 %. Quien está disponible el 80 % del tiempo trabaja 6,4 horas de una jornada de 8, así que una tarea asignada al 100 % lo pone en 8 / 6,4 = 125 %.

Cuenta por días y luego resume. Si el día 1 es un lunes, la semana de Dana del día 6 al día 10 tiene 48 horas de pruebas frente a 40 disponibles, una carga del 120 %, y el mes de 20 días laborables en torno al lanzamiento tiene 64 horas frente a 160, es decir, un 40 %. Una vista mensual muestra a Dana con tiempo de sobra. Microsoft Project permite que la redistribución busque sobreasignaciones en cualquier periodo, de minuto en minuto a mes en mes, y su documentación advierte de que, según el periodo elegido, un recurso puede parecer sobreasignado sin que se marque^[2].

El alcance también importa. Una carga calculada dentro de un solo proyecto ignora el trabajo de la persona en otros proyectos, así que alguien compartido entre tres planes puede parecer libre en cada uno de ellos. Cuando las personas son compartidas, haz la revisión entre proyectos.

Un ejemplo práctico: el lanzamiento de una app con una sola tester#

El ejemplo tiene 6 tareas, 4 personas y una ruta crítica de 12 días. Un equipo prepara una nueva versión de una app de compras: Lena redacta la especificación, Marco desarrolla la API de pago, Priya desarrolla las pantallas móviles y Dana es la única tester. Las duraciones están en días laborables de 8 horas, todas las dependencias son fin a comienzo y todas las asignaciones son al 100 %. Hay un detalle que está en un calendario: Priya tiene un día de vacaciones reservado el día 9.

La ruta crítica pasa por la especificación, la API, la prueba de la API y la regresión: 2 + 5 + 3 + 2 = 12 días. La carga de Dana es del 100 % el día 7, del 200 % los días 8 y 9, y otra vez del 100 % del día 10 al día 12. Nada en las fechas parece incorrecto.

Una vez medido, el problema son 2 días sobreasignados para una persona, un pico del 200 % y 16 horas de trabajo en exceso. Poner en secuencia las pruebas de Dana cuesta 2 días (ajuste 3, más abajo), así que ese es el techo para cualquier solución. La prueba de la API no puede ayudar adelantándose, porque la API de pago no termina hasta el final del día 7 y la prueba, que está en la ruta crítica, no tiene holgura que ceder.

Cuatro ajustes para nivelar el plan a mano#

Prueba los ajustes en este orden y anota dos resultados para cada uno: el nuevo día de fin y los días sobreasignados que quedan. El suavizado va primero porque, cuando funciona, no cuesta nada; comprar capacidad va al final porque cuesta dinero.

1. Suavizar dentro de la holgura. La prueba de las pantallas tiene 1 día de holgura, así que puede desplazarse de los días 7–9 a los días 8–10. Entonces Dana tiene las dos pruebas los días 8, 9 y 10. Para no coincidir con la prueba de la API, la prueba de las pantallas tendría que terminar el día 7, lo que obliga a empezar el día 5, cuando Priya sigue desarrollando las pantallas hasta el final del día 6. Resultado: fin el día 12, 3 días sobreasignados en lugar de 2. Descartado.
2. Reasignar. Priya termina las pantallas el día 6 y está libre desde el día 7, salvo por las vacaciones del día 9. Hay dos reasignaciones posibles, y el calendario las distingue: - Priya asume la prueba de la API. Necesita los días 8, 10 y 11, termina el día 11 y empuja la regresión a los días 12–13. Resultado: fin el día 13, 0 días sobreasignados. - Priya asume la prueba de las pantallas. Se hace los días 7, 8 y 10 y termina el día 10, dentro de su día de holgura, mientras Dana conserva la prueba de la API y la regresión. Resultado: fin el día 12, 0 días sobreasignados. El coste es que las pantallas las prueba la desarrolladora que las ha hecho.

Si olvidas las vacaciones, la primera opción parece gratuita, con Priya planificada para trabajar en un día libre.

1. Retrasar. Si nadie más puede probar, Dana hace las tres tareas en secuencia: prueba de las pantallas los días 7–9, prueba de la API los días 10–12, regresión los días 13–14. La GAO observa que las actividades que la nivelación retrasa suelen ser las que tienen más holgura libre^[1]. Aquí esa elección es peor: retrasar la prueba de las pantallas deja a Dana sin trabajo el día 7 y termina la regresión el día 15. Resultado: fin el día 14, 0 días sobreasignados.
2. Añadir capacidad. Una tester externa en la prueba de la API los días 8–10 mantiene el día 12 a cambio de 3 días pagados más una sesión de puesta al día; la guía para recuperar un proyecto retrasado compara la incorporación de personas por coste por día ganado.

Nuestra recomendación para este lanzamiento: dar a Priya la prueba de las pantallas, porque a este equipo un defecto de maquetación encontrado después del lanzamiento le cuesta menos que un día de retraso. Para un cambio en el flujo de pago daríamos a Priya la prueba de la API y aceptaríamos el día 13. Por defecto, reasigna primero y retrasa después. Invierte el orden cuando la única persona libre fuera a probar su propio trabajo en algo arriesgado y la fecha comprometida tenga margen: si el lanzamiento estuviera prometido para el día 15, el ajuste 3 no cambia nada que vea nadie fuera del equipo.

Antes de dar el plan por nivelado, comprueba:

• que la carga de cada persona está en el 100 % o por debajo todos los días, con las vacaciones y los días a tiempo parcial en su calendario;
• el día de fin frente al de antes de nivelar;
• que cada tarea que has movido a mano lleva una dependencia o una nota que explica por qué, para que la siguiente actualización no la deshaga (la GAO pide que los cambios hechos para resolver conflictos de recursos se documenten y que todos los entiendan^[1]);
• las personas compartidas, en todos sus proyectos.

Errores habituales#

• Repartir la asignación para que desaparezca el aviso. Poner a Dana al 50 % en las dos pruebas quita las celdas rojas mientras cada prueba conserva sus 3 días, así que sobre el papel desaparece la mitad de las horas de pruebas. Hecho con honestidad, cada prueba al 50 % dura 6 días.
• Dejar las vacaciones y los días a tiempo parcial fuera del calendario. En el ejemplo, el día 9 de Priya es el único dato que separa una reasignación que cuesta 1 día de otra que no cuesta nada.
• Asignar a todo el equipo a una sola tarea. Cinco nombres al 100 % son la carga de cinco personas durante toda la duración. Divide la tarea en subtareas con un responsable cada una, o da a cada persona su parte real.
• Nivelar un plan de fases. Una barra de "Pruebas" de 15 días asignada a dos testers no dice nada sobre quién está ocupado cada día.
• Nivelar una sola vez. La GAO recomienda comparar la fecha de la última nivelación con la del último cambio en los recursos y su disponibilidad^[1]. Vuelve a revisar después de cada retraso.

Los límites de la nivelación#

La nivelación, a mano o con software, cuenta horas y trata como intercambiables a las personas con las mismas horas. Puede que Dana sea la única con acceso al laboratorio de dispositivos, y que Marco sea el doble de rápido que cualquier otro con la API; ninguno de los dos hechos aparece en un porcentaje de carga. Cuando las competencias deciden quién puede hacer qué, fija primero las asignaciones y nivela después.

La nivelación automática falla de otra manera. La GAO indica a los planificadores que revisen el resultado de las rutinas de nivelación automática y lo ajusten cuando haga falta, y advierte de que una rutina puede resultar ineficiente al retrasar actividades mientras espera a una persona que solo está disponible en parte^[1]. En el ejemplo, una rutina que no divida la prueba de la API alrededor de las vacaciones de Priya la empieza el día 10 y termina el lanzamiento el día 14, un día más tarde que la división hecha a mano.

A mano, a partir de cierto tamaño los ajustes dejan de converger. Nuestra opinión: a partir de unas 5 personas compartidas entre 3 o más proyectos, cada solución en un plan abre un conflicto en otro, y un motor de nivelación automática como el de Microsoft Project compensa el tiempo dedicado a revisar su resultado.

Los datos de entrada también ponen un techo. Si las estimaciones de duración son erróneas, la sobrecarga se mueve con ellas. La guía de la GAO añade que la nivelación puede tener un efecto escaso o nulo en un cronograma o retrasar gravemente la fecha de fin prevista, según la holgura disponible, y que cuando retrasa la finalización los recursos son una restricción real y el plan necesita otro enfoque^[1]. Regla práctica: si la misma persona está por encima del 100 % durante más de 10 días laborables en un trimestre, mover fechas no lo arreglará; recorta el alcance o añade una persona.

Cómo hacerlo en Planitude#

Asigna personas a las tareas (clic derecho sobre una barra y luego Asignar personas) con la parte del tiempo que dedica cada una. La vista Carga de trabajo muestra la carga de cada persona por día, semana o mes, medida frente a su calendario y su disponibilidad. Las celdas sobreasignadas se ponen en rojo con un icono de aviso, una celda de semana o de mes se pone en rojo si cualquiera de sus días está sobreasignado e indica cuántos días y el pico, y al hacer clic en una celda se ven las tareas que hay detrás. El diagrama de Gantt nombra en un aviso a las personas sobreasignadas.

La cartera suma la carga de cada persona en todos los proyectos que puedes ver. Cuando el asistente propone un cambio, la vista previa marca a quien quedaría sobreasignado, con el pico y su disponibilidad. Un plan importado desde un archivo .mpp conserva la demora por redistribución que Microsoft Project guardó para cada tarea, el tiempo que se retrasa respecto a su inicio más temprano^[3], y las fechas la incluyen.

Planitude no nivela automáticamente. Tampoco calcula nuevas demoras por redistribución: muestra la sobrecarga y tú la resuelves con los ajustes descritos arriba.

Preguntas frecuentes#