Restricciones de tareas: ASAP, debe-empezar-el y fechas límite
Cada tarea de un diagrama de Gantt responde a una pregunta silenciosa antes de aterrizar en una fecha: ¿cuándo se le permite ocurrir? Esa respuesta es una restricción de programación. La mayoría de los planificadores nunca tocan este ajuste, y sus diagramas fluyen correctamente justamente por eso. Otros fijan tareas a fechas concretas a mano y luego se preguntan por qué la línea de tiempo deja de avisarles de los retrasos. Esta guía explica cada tipo de restricción, cuándo recurrir a una y cómo una sola fijación rígida puede enterrar un conflicto a plena vista.
- Por qué existen las restricciones
- El menú completo de tipos de restricción
- Las restricciones flexibles mantienen vivo el plan
- Restricciones semiflexibles: suelos y techos
- Cómo las restricciones rígidas luchan contra las dependencias
- Cómo las restricciones ocultan y destruyen la holgura
- El peligro de restringir en exceso
- Cuándo es legítima cada restricción
- Un ejemplo resuelto: la trampa del debe-empezar-el
- Prefiere restricciones flexibles más dependencias
- Leer las advertencias de restricción en tu herramienta
- Una disciplina sencilla de restricciones
Por qué existen las restricciones
Una restricción de programación le indica al motor de programación cuánta libertad tiene una tarea para moverse en el tiempo. Sin ninguna regla, una buena herramienta colocará el trabajo tan pronto como pueda una vez que terminen sus predecesoras. Ese comportamiento por defecto está haciendo mucho trabajo por ti en silencio. Significa que el plan se recalcula solo cada vez que cambia una fecha, de modo que un retraso al principio del proyecto se propaga hacia adelante de forma automática en lugar de dejar fechas obsoletas.
Las restricciones anulan ese comportamiento automático. Van desde empujones suaves que aún dejan flotar a la tarea hasta fijaciones rígidas que clavan una tarea a una fecha del calendario pase lo que pase a su alrededor. Entender dónde se sitúa cada una en ese espectro es la diferencia entre un plan que piensa por ti y un plan que te miente.
El menú completo de tipos de restricción
La mayoría de las herramientas exponen seis o siete tipos de restricción más un campo de fecha límite aparte. Se dividen en dos familias. Las restricciones flexibles mantienen la tarea en movimiento en la dirección del plan. Las restricciones rígidas bloquean una tarea a una fecha y le impiden responder al cambio.
| Restricción | Qué hace | Familia |
|---|---|---|
| Lo antes posible (ASAP) | Programa la tarea en la fecha legal más temprana | Flexible |
| Lo más tarde posible (ALAP) | Programa en la fecha más tardía sin retrasar a las sucesoras | Flexible |
| No empezar antes de | Fija un suelo, la tarea aún puede moverse más tarde | Semiflexible |
| No terminar después de | Fija un techo para la fecha de fin | Semiflexible |
| Debe empezar el | Fija el inicio a una fecha exacta | Rígida |
| Debe terminar el | Fija el fin a una fecha exacta | Rígida |
| Fecha límite | Un marcador objetivo que avisa pero no fija | Indicativa |
La fecha límite es la heroína silenciosa aquí. Te da la responsabilidad de una fecha fija sin la rigidez, porque señala un incumplimiento en lugar de forzar al calendario a obedecer.
Las restricciones flexibles mantienen vivo el plan
ASAP es el valor por defecto en casi todos los programadores serios, y con razón. Una tarea configurada como lo antes posible se desplazará hacia adelante en el momento en que su predecesora se mueva, que es exactamente lo que quieres que haga un plan. Las fechas se mantienen honestas porque el motor las sigue recalculando a partir de la red de dependencias y no a partir de una promesa que hiciste hace semanas.
Lo más tarde posible es su reflejo. Empaqueta el trabajo hacia el final de su ventana disponible, lo cual es útil para tareas que quieres aplazar, como pedir materiales perecederos o aprovisionar un entorno en la nube de corta vida. Ambas son flexibles porque ninguna lucha contra los enlaces entre tareas. Se montan encima de ellos.
Restricciones semiflexibles: suelos y techos
No empezar antes de y no terminar después de son el término medio, y a menudo son la respuesta correcta cuando la gente recurre por instinto a una fijación rígida. Imagina que un proveedor no puede enviar antes del día quince. Una restricción de no empezar antes de esa fecha fija un suelo. La tarea no comenzará antes del día quince, pero si una predecesora se retrasa más allá de esa fecha, la tarea igual se mueve más tarde por sí sola.
Compáralo con debe empezar el, que fijaría la tarea al día quince aunque el trabajo que la alimenta no esté terminado. La versión semiflexible captura la verdad del mundo real, que es que el quince es la fecha más temprana posible, no la única fecha. Recurre a un suelo o a un techo siempre que tu verdadera restricción sea un límite y no un único punto.
Cómo las restricciones rígidas luchan contra las dependencias
Una dependencia dice que la tarea B no puede empezar hasta que termine la tarea A. Una restricción de debe empezar el dice que la tarea B empieza en una fecha fija, y punto. Cuando esas dos reglas se contradicen, algo tiene que ceder, y qué cede depende por completo de tu herramienta. Algunos programadores respetan la restricción y dejan que B empiece en silencio antes de que A termine, produciendo un plan imposible que parece perfectamente ordenado. Otros respetan la dependencia y muestran una holgura negativa o una advertencia roja que muchos planificadores nunca notan.
Este es el peligro central. Una dependencia es una afirmación de la realidad física: no puedes pintar una pared antes de que esté construida. Una restricción rígida es una afirmación de preferencia. Cuando la preferencia anula la realidad sin una advertencia clara, el diagrama deja de describir el proyecto y empieza a describir tus deseos. Como se suele decir, un diagrama de Gantt construido una vez y nunca tocado no es un plan, es un deseo.
Cómo las restricciones ocultan y destruyen la holgura
La holgura, o margen, es la cantidad de tiempo que una tarea puede retrasarse antes de que retrase el proyecto. Se calcula a partir de la red de dependencias. Cuando fijas una tarea con una restricción rígida, cortas parte de ese cálculo, y la cifra de holgura que ves después puede carecer de sentido.
Una fecha de debe empezar el puede inventar una holgura que no existe, fingiendo que una tarea tiene una ventana cómoda cuando sus predecesoras en realidad van retrasadas. También puede destruir holgura real, al mantener una tarea en su sitio cuando podría haberse movido sin problema, convirtiendo un colchón sano en un apuro artificial. En cualquier caso pierdes la imagen honesta que se supone que debe darte el análisis de holgura.
El peligro de restringir en exceso
Restringir en exceso es el hábito de fijar muchas tareas a fechas concretas porque da sensación de precisión. Es la forma más común en que un principiante convierte un calendario inteligente en una hoja de cálculo torpe. Cada fijación rígida elimina un eslabón más de la cadena que permite al plan recalcularse solo. Añade suficientes y la línea de tiempo ya no podrá decirte cuánto cuesta realmente un retraso, porque la mitad de las tareas se niegan a moverse en respuesta.
Los síntomas son fáciles de detectar una vez que los conoces. Los retrasos dejan de propagarse hacia adelante. El camino crítico parece extrañamente corto o salta de forma impredecible. Los valores de holgura se vuelven negativos en lugares que deberían ser cómodos. Si tu plan tiene más que un puñado de restricciones rígidas, probablemente haya dejado de funcionar como modelo y haya empezado a funcionar como un dibujo estático.
Cuándo es legítima cada restricción
Las restricciones rígidas no son el mal. Son herramientas con usos estrechos y válidos. El error es recurrir a ellas por defecto en lugar de por necesidad. Aquí tienes una guía aproximada de cuándo cada tipo se gana su lugar.
| Situación | Mejor restricción | Por qué |
|---|---|---|
| Trabajo ordinario impulsado por predecesoras | ASAP | Deja que el plan fluya y se recalcule |
| Material disponible solo después de una fecha | No empezar antes de | Fija un suelo real, aún flexible |
| Informe regulatorio con fecha de entrega | No terminar después de o fecha límite | Limita el fin sin fijar en exceso |
| Puesta en marcha contractual, fijada por ley | Debe empezar el | Un evento de calendario genuinamente inamovible |
| Reunión del consejo o auditoría externa | Debe empezar el | La fecha realmente no puede moverse |
Fíjate en que una fijación rígida solo se justifica cuando la fecha la fija algo ajeno a tu proyecto, como un contrato, un regulador u otra organización. Si tú controlas la fecha, casi nunca necesitas fijarla.
Un ejemplo resuelto: la trampa del debe-empezar-el
Imagina un pequeño proyecto de infraestructura. Hay que entregar el hardware, luego instalar los servidores y después configurar la red. El instalador está reservado para el día dos, así que un planificador fija la tarea de instalación con debe empezar el en esa fecha. Parece responsable. Es una trampa.
El montaje. Entregar hardware va primero, luego Instalar servidores, enlazadas fin a inicio. La instalación se fija con una fecha de debe empezar el 2 de marzo.
El retraso. El proveedor retrasa la entrega. Entregar hardware termina ahora el 5 de marzo, tres días tarde.
| Tarea | Planificado | Tras el retraso |
|---|---|---|
| Entregar hardware | termina el 1 mar | termina el 5 mar |
| Instalar servidores (fijada) | empieza el 2 mar | sigue empezando el 2 mar |
El conflicto oculto. El diagrama muestra tan tranquilo la instalación empezando el 2 de marzo, tres días antes de que el hardware siquiera llegue. La fijación de debe empezar el ha anulado la dependencia, y a menos que detectes el diminuto marcador de holgura negativa, el plan parece correcto. Una restricción de no empezar antes de habría dejado que la instalación se deslizara al 5 de marzo y te habría avisado de que hay que volver a reservar al instalador.
Prefiere restricciones flexibles más dependencias
Los planes más sanos expresan su calendario a través de la red de dependencias, no a través de una dispersión de fechas fijas. Las dependencias dicen qué debe ir antes de qué. Las restricciones flexibles añaden los pocos límites del mundo real que la red no puede inferir. Juntas producen un calendario que se recalcula solo y sigue avisándote cuando la realidad se desvía.
- Empieza cada tarea como ASAP, el valor por defecto, y resiste la tentación de cambiarlo.
- Dibuja las dependencias reales para que el trabajo se ordene solo a partir de los enlaces.
- Añade un no empezar antes de solo donde una fecha externa bloquee de verdad un inicio temprano.
- Usa un marcador de fecha límite, no un debe terminar el, para los objetivos que quieras seguir pero no imponer.
- Reserva debe empezar el y debe terminar el para fechas fijadas por contrato, por ley o por otra parte.
- Revisa tu lista de restricciones cada mes y elimina cualquier fijación cuya razón haya caducado.
Puedes construir exactamente este tipo de calendario que se autocorrige en el creador de Gantt gratuito sin instalar nada.
Leer las advertencias de restricción en tu herramienta
Todo programador capaz señala cuándo una restricción está luchando contra una dependencia, pero las señales son discretas a propósito para que no incordien. Aprender a leerlas es lo que separa un plan en el que confías de un plan que solo esperas que funcione.
Holgura negativa. Si una tarea muestra holgura negativa, una restricción está exigiendo una fecha que la red no puede entregar. En el ejemplo del servidor de arriba, la instalación fijada arrastraría tres días de holgura negativa, el tamaño exacto del conflicto enterrado.
Un icono de fijación o candado. La mayoría de las herramientas marcan las tareas restringidas con un pequeño icono. Búscalos antes de cada actualización de estado. Un grupo de fijaciones es una advertencia de que tu plan puede haber dejado de recalcularse.
Fechas que no se mueven. La prueba más contundente es de comportamiento. Empuja una tarea temprana hacia más tarde a propósito y observa lo que sigue. Las tareas que se niegan a desplazarse o están fijadas o no esperan nada, y ambos casos merecen una segunda mirada.
Una disciplina sencilla de restricciones
No necesitas un documento de políticas para mantener sanas las restricciones. Necesitas un hábito: tratar una fijación rígida como un coste, no como una comodidad. Antes de establecer un debe empezar el, pregúntate si la fecha la fija el mundo exterior o simplemente tu plan actual. Si es tu plan, una dependencia o un suelo flexible te servirán mejor y mantendrán el calendario honesto.
Las restricciones son la gramática de un calendario. Usadas con moderación, dejan que el plan hable con claridad sobre qué puede moverse y qué no. Usadas en exceso, lo amordazan. Los mejores planificadores establecen las menos que pueden, se apoyan en las dependencias para el resto y mantienen cada fijación restante atada a una razón que pueden nombrar en voz alta.
Preguntas frecuentes
¿Cuál es la diferencia entre una fecha límite y una restricción de debe terminar el?
Una fecha límite es indicativa. Marca una fecha objetivo y lanza una advertencia si la tarea termina tarde, pero nunca fuerza al calendario a moverse. Una restricción de debe terminar el es una fijación rígida que fija la fecha de fin y puede anular dependencias, ocultando conflictos. Prefiere la fecha límite en casi todos los casos.
¿Por qué mi tarea empieza antes de que termine su predecesora?
Casi siempre porque una restricción rígida, normalmente debe empezar el, está anulando la dependencia entre ellas. El programador respeta la fecha fija en lugar del enlace. Busca un icono de fijación y un valor de holgura negativa en esa tarea, y luego cámbiala a no empezar antes de para que pueda deslizarse.
¿Es ASAP siempre el valor por defecto correcto?
Para la mayoría de las tareas, sí. Lo antes posible deja que cada tarea avance de forma automática cuando cambian las predecesoras, de modo que todo el plan se recalcula solo y se mantiene honesto. Usa lo más tarde posible solo para el trabajo que quieras aplazar deliberadamente, y recurre a las restricciones rígidas únicamente cuando una fecha externa realmente no pueda moverse.
¿Cuántas restricciones rígidas son demasiadas?
No hay un número exacto, pero si más de un puñado de tareas llevan fijaciones de debe empezar el o debe terminar el, es probable que tu plan haya dejado de recalcularse. Las señales de alerta son retrasos que ya no se propagan hacia adelante, un camino crítico que salta de un lado a otro y valores de holgura que se vuelven negativos en lugares que deberían ser cómodos.
¿Puede una restricción ocultar una holgura que en realidad no existe?
Sí, y este es el peligro sutil. Una fecha de debe empezar el puede hacer que una tarea parezca tener una ventana cómoda cuando sus predecesoras en realidad van retrasadas, inventando holgura. También puede destruir holgura real al mantener una tarea en su sitio. En cualquier caso, la cifra que lees deja de reflejar el verdadero riesgo del calendario.
Seguir leyendo
- Las dependencias entre tareas explicadas
- ¿Qué es la holgura (margen)?
- El método del camino crítico explicado
- Ver todas las guías
Las guías que aún no se han traducido se abren en inglés.