Planificación: EDT, dependencias, camino crítico, Gantt e hitos

Cómo se convierte un objetivo en trabajo ejecutable: descomponer, ordenar, calcular cuánto dura de verdad el proyecto y qué tareas no pueden retrasarse, y por qué el plan es una guía que se actualiza.

1. Para qué se planifica

La planificación define objetivos, tareas, recursos y cronogramas, alineando a todos los involucrados; el seguimiento supervisa el progreso, detecta desviaciones y aplica medidas correctivas. Sus objetivos concretos son:Tema 1, diap. 60.

1. Convertir objetivos en trabajo ejecutable
2. Descomponer entregables y tareas → EDT (sección 3)
3. Estimar esfuerzo y duración → lección 10
4. Asignar recursos → sección 6 y lección 16
5. Establecer dependencias, hitos y calendario → secciones 4-5

Las diapositivas añaden que herramientas software, metodologías ágiles (Scrum, Kanban) y reuniones periódicas facilitan ambos procesos. La planificación no es exclusiva de lo predictivo: en ágil se planifica cada sprint y se mantiene un plan de entregas, con más frecuencia y menos detalle a largo plazo.

2. Vocabulario básico

El Tema 2 empieza fijando términos:Tema 2, diap. 4.

Lo importante del hito es "comprobable objetivamente". "El 80 % del backend hecho" no es un hito (¿quién comprueba ese 80 %?). "Todas las pruebas de la API pasan en el entorno de integración" sí lo es. Recuerda la lección 1: en software el progreso no se ve, y los hitos objetivos son la forma de hacerlo visible.

Esfuerzo frente a duración

La confusión más cara de la planificación (ampliación):

• Esfuerzo = cantidad de trabajo, en persona-horas o persona-días. Se relaciona con el coste: horas × precio/hora. Términos de "esfuerzo": horas, trabajo, coste, precio.
• Duración = tiempo de calendario que pasa desde que empieza hasta que termina. Términos de "duración": fechas, plazos, tiempo.

Una tarea de 40 h de esfuerzo hecha por una persona a jornada completa (8 h/día) dura 5 días. Si esa persona sólo dedica media jornada porque está en otro proyecto, dura 10 días: mismo esfuerzo, el doble de duración. Si se reparte entre dos personas a jornada completa, podría durar 2,5 días… sólo si la tarea es divisible y no se pierde tiempo coordinando (lección 16, ley de Brooks).

3. La EDT (Estructura de Desglose del Trabajo)

La EDT (en inglés WBS, Work Breakdown Structure) es la descomposición jerárquica de todo el trabajo del proyecto en partes cada vez más pequeñas, hasta llegar a paquetes de trabajo que se pueden estimar, asignar y controlar.Ampliación. PMBOK 6, proceso "Crear la EDT" (grupo de Planificación, área de Alcance). Ver Work breakdown structure.

Reglas que la hacen útil:

• Regla del 100 %: la EDT incluye el 100 % del trabajo del alcance (también la gestión, las pruebas, la formación) y nada más. Cada nivel suma exactamente su padre. Lo que no está en la EDT no está en el alcance, y lo que está en la EDT pero no en el alcance es gold plating.
• Orientada a entregables (sustantivos: "Backend", "App móvil"), no a actividades sueltas (verbos). Las actividades se derivan después de cada paquete.
• Paquete de trabajo = nivel más bajo: tan pequeño como para estimarlo con confianza y asignarlo a un responsable (regla práctica: entre 8 y 80 horas, o que quepa en un periodo de informe).
• Se acompaña de un diccionario de la EDT que describe cada paquete: qué incluye, criterios de aceptación, responsable, estimación.

La EDT es la base de todo lo que viene: de ella salen las actividades, las estimaciones (lección 10), el presupuesto (lección 14) y los riesgos (cada paquete se revisa preguntando "¿qué puede salir mal aquí?").

4. Dependencias

Las actividades no se pueden hacer en cualquier orden. Hay cuatro tipos de relación lógica entre una actividad predecesora (A) y una sucesora (B):Ampliación. Método de diagramación por precedencia (PDM), PMBOK 6, §6.3.

Además, una dependencia puede tener adelanto (lead: B empieza 2 días antes de que A termine) o retraso (lag: B empieza 3 días después, p. ej. esperar la revisión de la tienda de apps). Y por su origen pueden ser obligatorias (no hay otra forma), discrecionales (por buena práctica, se pueden saltar), externas (dependen de alguien de fuera: el acceso a la API del GPS del ayuntamiento). Las externas son casi siempre riesgos.

5. El camino crítico

El método del camino crítico (CPM, Critical Path Method) calcula la duración mínima del proyecto y qué actividades no pueden retrasarse sin retrasarlo todo.Ampliación. Desarrollado en 1957 por DuPont. Ver Critical path method. Es el ejemplo perfecto de "técnicas de la investigación de operaciones aplicables a la gestión" (Tema 2, diap. 5). Lo hacemos con TusBus (duraciones en semanas, todas las dependencias FS):

Paso 1 · Pasada hacia delante (lo antes posible)

Para cada actividad: inicio temprano (IT) = el mayor fin temprano de sus predecesoras; fin temprano (FT) = IT + duración.

Paso 2 · Pasada hacia atrás (lo más tarde posible)

Desde el final: fin tardío (FTa) = el menor inicio tardío de sus sucesoras; inicio tardío (ITa) = FTa − duración.

Paso 3 · Holgura y camino crítico

El camino crítico es la secuencia de actividades con holgura cero: A → B → D → F → G = 3 + 4 + 6 + 2 + 3 = 18 semanas. Es el camino más largo de la red, y por eso marca la duración mínima del proyecto.

Cómo se lee como gestor:

• Si D (backend) se retrasa 1 semana, el proyecto se retrasa 1 semana. Esas tareas son las que hay que vigilar y proteger (los mejores recursos, las dependencias externas resueltas antes).
• Si E (app móvil) se retrasa 2 semanas, no pasa nada: tiene 3 de holgura. Si se retrasa 5, el proyecto se retrasa 5 − 3 = 2 semanas, y el camino crítico cambia.
• Acortar C o E no adelanta el proyecto. Poner más gente en lo que no es crítico es tirar dinero.
• El camino crítico puede cambiar durante el proyecto cuando las tareas se retrasan o adelantan. Se recalcula en cada seguimiento.

Si el camino crítico no cabe en el plazo

Dos técnicas clásicas de compresión del cronograma, ambas sobre actividades críticas:

• Intensificación (crashing): añadir recursos para acortar una tarea crítica. Cuesta dinero, y en software rinde poco o nada si la tarea no es divisible (ley de Brooks, lección 16).
• Ejecución rápida (fast tracking): hacer en paralelo tareas que iban en secuencia (empezar la app con la API todavía en diseño). No cuesta más dinero, pero aumenta el riesgo de retrabajo.

Y la tercera, que en software suele ser la mejor: reducir el alcance del camino crítico con la priorización de la lección 5.

6. Gantt, recursos y línea base

Diagrama de Gantt

Representa las actividades como barras sobre una línea de tiempo, con dependencias como flechas y los hitos como rombos. Su gran virtud es la comunicación: cualquier stakeholder entiende de un vistazo qué pasa cuándo. Su límite: no muestra bien la incertidumbre (una barra parece muy precisa aunque la estimación no lo sea) y oculta el camino crítico si no se resalta.

Asignar recursos

El cálculo del camino crítico supone recursos ilimitados. Si la misma persona tiene asignadas B y C a la vez, no puede hacerlas en paralelo. La nivelación de recursos reordena actividades (normalmente usando la holgura) para que nadie esté sobreasignado; a veces alarga el proyecto. Y recuerda (lección 16): planificar a alguien al 100 % de su jornada es planificar el retraso.

La línea base

Cuando el plan se aprueba, se congela una copia: la línea base (de alcance, de cronograma y de coste). Sirve para comparar: el seguimiento mide la realidad frente a la línea base (lo verás con valor ganado en la lección 14). La línea base sólo se cambia mediante control de cambios formal; si se cambiara cada vez que hay un retraso, siempre irías "en plazo" y nunca aprenderías nada.

7. Planificar con incertidumbre

La incertidumbre es inherente al software, así que las metodologías actuales no intentan eliminarla con planificaciones rígidas e irreales, sino que la integran: ciclos cortos, retroalimentación continua y ajustes permanentes, convirtiendo la incertidumbre en una oportunidad para aprender. Cuatro ideas:Tema 1, diap. 61.

1. Una estimación no es una promesa. (Lección 10.)
2. Cuanto más lejano es el trabajo, mayor incertidumbre. Por eso se planifica con detalle lo próximo y a grandes rasgos lo lejano: planificación gradual (rolling wave), que se va detallando como una ola que avanza.
3. El plan se actualiza cuando cambia la información. Un plan que no cambia nunca no es estable: está muerto.
4. Planificar ≠ predecir perfectamente. Planificar es pensar por adelantado para decidir mejor, no adivinar el futuro.

"La planificación debe adaptarse a nueva información" es una de las cinco ideas clave del Tema 1.Tema 1, diap. 71. Y no contradice la línea base: la línea base te dice cuánto te has desviado; adaptar el plan es decidir qué haces con esa desviación.

Práctica

Usa esta red para las tres preguntas siguientes (semanas, dependencias fin-inicio): P 2 (—) · Q 5 (P) · R 3 (P) · S 4 (R) · T 2 (Q, S).

Repaso espaciado · lecciones 3, 6, 8

Para profundizar

Resumen imprimible: Referencia · Fundamentos.