1.1Introducir tareas, duraciones y de resumen
Lo esencial en 30 segundos
- La planificación se construye primero con tareas: una línea por tarea, nombrada con un verbo de acción, con una duración estimada.
- La jerarquía (WBS) hace legible el proyecto: las tareas se agrupan bajo tareas de resumen (fases) mediante sangría.
- La tarea de resumen calcula sola su duración y sus fechas a partir de sus subtareas: nunca se introducen a mano.
Minicaso continuo — Meriem estructura la planificación de una ampliación de edificio
Meriem, jefa de proyecto en una empresa de ingeniería y construcción en Argel, comienza la planificación de una ampliación de edificio para un cliente. Su primera página está vacía: empieza introduciendo las tareas una por línea —«Estudiar el terreno», «Verter los cimientos», «Montar la estructura», «Instalar las instalaciones»— con una duración estimada para cada una. Pero esta lista plana no le dice nada al cliente. Así que crea tareas de fase («Estudios», «Obra gruesa», «Acabados») y baja (sangra) las tareas correspondientes debajo, formando un WBS de tres niveles. Comprueba entonces que la fase «Obra gruesa» muestra sola su duración y sus fechas, calculadas a partir de sus subtareas: no ha introducido nada en la línea de fase. Meriem retiene la regla: se introducen las tareas y su duración, se estructura en fases, y la tarea de resumen se calcula sola.
Caso autónomo de esta sección: reaparece en el curso, el esquema, el guion y el reto de 48 h de la sección 1.1.
1. Tareas, una jerarquía
El corazón de una planificación son las tareas. Meriem las introduce en la cuadrícula, una por línea, con su duración (3 días, 2 semanas…). Pero un proyecto de construcción no es una lista plana: se estructura agrupando las tareas bajo tareas de resumen (fases), formando una jerarquía: es el WBS (Work Breakdown Structure).
Se bajan o suben (sangría) las líneas para crear este desglose: Fase > subtareas. Meriem coloca así «Verter los cimientos» y «Montar la estructura» bajo la fase «Obra gruesa».
2. La tarea de resumen se calcula sola
La tarea de resumen resume sus subtareas: su duración y sus fechas se calculan automáticamente a partir de ellas. No se introducen nunca a mano: es un reflejo de principiante que hay que perder.
Este desglose hace la planificación legible, permite razonar por fases y sirve de base para los informes. Buena práctica: descomponer hasta tareas de tamaño manejable, nombradas con verbos de acción.
3. Nombrar y calibrar las tareas
Una buena tarea tiene un entregable, un responsable y una duración estimable. Una referencia habitual es la regla 8/80: una tarea de unas 8 h (1 día) a 80 h (2 semanas) tiene una granularidad sana. Demasiado fina, la planificación se vuelve ingobernable; demasiado gruesa, deja de poder seguirse.
Meriem nombra cada línea con un verbo de acción («Estudiar», «Verter», «Instalar») y comprueba su desglose: ni microgestión, ni grandes bloques imposibles de seguir.
🔎 Ejemplo concreto — 🔎 Ejemplo concreto — La regla 8/80
Encontrar la granularidad adecuada de las tareas:
Una tarea entre ~8 h (1 d) y ~80 h (2 sem): buen tamaño.
Demasiado fina (1 h) → planificación ingobernable;
demasiado gruesa (3 meses) → seguimiento imposible.
→ cada tarea: un entregable, un responsable, una duración estimable.Lectura: Meriem busca tareas lo bastante pequeñas para poder seguirlas, sin caer en la microgestión.
Reflejo: no introducir nunca la duración de una tarea de resumen: se calcula a partir de sus subtareas.
Vocabulario de la sección
- Tarea
- Línea de trabajo de la planificación, con un nombre, una duración y (más adelante) vínculos, recursos y costes.
Ejemplo sencillo: Meriem introduce «Verter los cimientos» con una duración de 5 días.
Lo que no es: una nota suelta sin nombre, duración ni responsable.
Reflejo: una tarea → un entregable, una duración.
- Duración
- Tiempo de trabajo estimado de una tarea, expresado en días/semanas/horas y calculado según el calendario.
Ejemplo sencillo: Meriem estima «Montar la estructura» en 3 semanas.
Lo que no es: una tarea sin estimación, imposible de planificar.
Reflejo: duración = estimación según el calendario laborable.
- Tarea de resumen
- Tarea «madre» que agrupa subtareas; su duración y sus fechas derivan automáticamente de ellas.
Ejemplo sencillo: La fase «Obra gruesa» de Meriem resume los cimientos y la estructura.
Lo que no es: introducir a mano la duración de una fase de agrupación.
Reflejo: tarea de resumen → duración calculada, nunca introducida.
- WBS (estructura de desglose del trabajo)
- Desglose jerárquico del proyecto en fases y subtareas (Work Breakdown Structure).
Ejemplo sencillo: Meriem organiza su obra en Estudios, Obra gruesa y Acabados.
Lo que no es: una larga lista plana sin ninguna jerarquía.
Reflejo: estructurar → WBS en fases.
- Sangría (bajar/subir)
- Acción de desplazar una tarea en la jerarquía para colocarla bajo una tarea de resumen (o sacarla de ella).
Ejemplo sencillo: Meriem baja «Montar la estructura» bajo «Obra gruesa».
Lo que no es: tareas de fase que quedan al mismo nivel que el detalle.
Reflejo: colocar una subtarea → aplicarle sangría.
En la práctica — En la práctica — Introducir y estructurar las tareas
- Introduce la lista de tareas del proyecto, una por línea, con una duración estimada para cada una.
- Crea tareas de fase (p. ej. «Estudios», «Ejecución») y baja (sangra) las tareas correspondientes debajo.
- Comprueba que cada tarea de resumen calcula sola su duración y sus fechas a partir de sus subtareas.
- Nombra las tareas con verbos de acción y verifica que el desglose no sea ni demasiado fino ni demasiado grueso.
Guion paso a paso — introducir y estructurar como Meriem (5 min)
1) Enumera las tareas del proyecto una por línea, con una duración estimada para cada una. 2) Añade tareas de fase («Estudios», «Obra gruesa», «Acabados»). 3) Baja (sangra) las tareas de detalle bajo su fase para formar el WBS. 4) Verifica que la duración de cada tarea de resumen se calcula sola y no se introduce. 5) Nombra cada tarea con un verbo de acción y controla la granularidad (regla 8/80).
Conserva esta estructura: sirve de base para encadenar las tareas (vínculos) y para los informes del nivel.
Plantilla para copiar y pegar — mi lista de comprobación de introducción
[ ] Una línea por tarea, con una duración estimada
[ ] Tareas nombradas con verbos de acción
[ ] Tareas de fase creadas (tareas de resumen)
[ ] Subtareas con sangría (bajadas) bajo su fase
[ ] Duración/fechas de la tarea de resumen no introducidas (calculadas)
[ ] Granularidad respetada (regla ~8/80)
[ ] WBS legible y listo para encadenarse con vínculosProyecto pequeño
Meriem solo utiliza una fase y unas pocas tareas, pero mantiene la estructura tarea → tarea de resumen.
Obra grande
Meriem baja a tres niveles de WBS (proyecto → fases → lotes → tareas) para seguir siendo legible.
Nombrar con verbo de acción
Meriem escribe «Instalar las instalaciones» en lugar de «Instalaciones», para una planificación comprensible por todos.
Verificar la granularidad
Sea cual sea el proyecto, Meriem comprueba que ninguna tarea sea demasiado fina ni demasiado gruesa (regla 8/80).
✓ Buenas prácticas
- Estructurar en fases (tareas de resumen) + subtareas.
- Nombrar las tareas con verbos de acción.
- Buscar la granularidad 8/80 (un entregable por tarea).
✗ Errores frecuentes
- Introducir las fechas de cada tarea a mano.
- Introducir la duración de una tarea de resumen (se calcula).
- Descomponer demasiado fino (ingobernable) o demasiado grueso (imposible de seguir).
Puntos clave
- Se introducen las tareas con su duración (calculada según el calendario laborable).
- Se estructura el proyecto en jerarquía (WBS) con tareas de resumen (fases).
- La sangría (bajar/subir) coloca las subtareas bajo su fase.
- La tarea de resumen calcula automáticamente su duración y sus fechas: no introducirlas.
Reto 48 h — aplícalo mañana
Toma un proyecto real (aunque sea pequeño) y crea su WBS como Meriem: tareas una por línea con duración, tareas de fase y luego sangría de las subtareas. Verifica que la duración de una tarea de resumen se calcula sola. Escribe en una frase por qué no se introduce la duración de una fase.
- Puedo introducir tareas con su duración en Project.
- Sé estructurar un proyecto en fases y subtareas (WBS).
- Entiendo que la tarea de resumen calcula sola su duración y sus fechas.
Preguntas frecuentes
¿Hay que introducir las fechas de inicio y fin de cada tarea?
No, y es el error clásico del principiante. En modo automático, se introduce la duración y los vínculos entre tareas, y Project calcula las fechas solo. Forzar fechas a mano crea restricciones rígidas que impiden que la planificación se recalcule (ver sección 1.4). Solo se fija una fecha cuando realmente viene impuesta.
¿Hasta dónde hay que descomponer las tareas (nivel de detalle)?
Descompón hasta tareas lo bastante pequeñas para poder estimarlas y seguirlas, sin microgestionar. Una referencia habitual es la regla «8/80»: entre ~8 h (1 día) y ~80 h (2 semanas). Demasiado fino hace la planificación ingobernable; demasiado grueso impide seguir el avance. Cada tarea debe tener un entregable claro, un responsable y una duración estimable.
¿Cómo se estructura un proyecto en fases en Project?