Estructura de desglose del trabajo (EDT): cómo construirla y convertirla en un cronograma

Cuando un plan olvida las redirecciones de las páginas antiguas de la documentación, o la formación en la que nadie pensó, las fechas están mal antes de que empiece la primera tarea. La estructura de desglose del trabajo (EDT, o WBS en inglés) es donde se detecta ese trabajo que falta. Divide el proyecto en lo que tiene que entregar, antes de que nadie hable de fechas.

Esta guía explica las dos pruebas que mantienen completa una EDT, hasta qué profundidad conviene llegar y por qué la mayoría de los equipos pequeños deberían dejar las fases fuera del nivel 2. Después sigue el lanzamiento de un centro de ayuda, desde una EDT de 14 paquetes hasta un cronograma de 27 días, con los vínculos entre entregables incluidos.

Qué es una estructura de desglose del trabajo#

Una estructura de desglose del trabajo es una jerarquía que divide un proyecto en los entregables que debe producir, y cada entregable en piezas de trabajo más pequeñas que se pueden estimar y asignar. El manual de EDT de la NASA la define como “un árbol genealógico orientado al producto que identifica el hardware, el software, los servicios y todos los demás entregables necesarios para alcanzar el objetivo final del proyecto”^[1].

El nivel 1 es el proyecto y el nivel 2 recoge los entregables principales. Cada nivel siguiente divide un elemento en partes, hasta llegar a los paquetes de trabajo, cada uno de ellos “la unidad de trabajo necesaria para completar una tarea concreta”^[1]. En programas grandes el coste y el plazo se controlan un nivel más arriba, en la cuenta de control, que puede contener varios paquetes de trabajo^[1]. Con tres a diez personas ambos coinciden, y el paquete de trabajo es donde se nombra a un responsable.

El árbol no tiene fechas ni secuencia. Esas llegan con el cronograma, que se construye a partir de los paquetes de trabajo del final de cada rama.

Dos pruebas que mantienen completa una EDT#

La primera prueba sale de una frase del manual de la NASA: “El alcance de trabajo que no está contenido en la EDT del proyecto no debe considerarse parte del proyecto”^[1]. Aplicada a cada elemento, se convierte en una pregunta práctica. Si todos los hijos están terminados, ¿está terminado el padre? Una respuesta que empieza por “sí, salvo” ha encontrado un elemento que falta. El trabajo habilitador también cuenta como alcance, y la lista de comprobación de desarrollo de la NASA menciona de forma explícita la gestión del proyecto^[1].

La segunda prueba detecta duplicados. El coste y el plazo deben acumularse desde los elementos más bajos “sin asignar ningún elemento de alcance de trabajo a dos o más elementos de la EDT”^[1]. En los planes en hoja de cálculo, la señal habitual es una línea pegada bajo dos encabezados, como “Guía de usuario” bajo Construcción y otra vez bajo Formación, con dos estimaciones y dos porcentajes de avance.

Un diccionario de la EDT cierra los huecos que dejan los nombres cortos de los elementos, y la NASA lo prepara en parte “para eliminar la duplicación y el solapamiento de las asignaciones de trabajo”^[1]. En un proyecto pequeño bastan tres o cuatro líneas por paquete de trabajo. Una entrada típica del ejemplo de más abajo:

1.1.5 Artículos publicados. Alcance: 23 artículos aprobados, cargados y enlazados entre sí. Excluido: traducciones y vídeo. Responsable: redactora técnica. Terminado cuando: cada artículo tiene una URL pública y el buscador del centro de ayuda lo devuelve.

Esa última línea importa más adelante, porque une la rama de contenido con la rama de plataforma.

Entregables, fases o departamentos en el nivel 2#

El nivel 2 puede construirse en torno a lo que produce el proyecto (Contenido, Plataforma, Integración, Lanzamiento), en torno al tiempo (Diseño, Construcción, Pruebas, Publicación) o en torno a quién hace el trabajo. Solo la primera opción muestra qué existe cuando termina el proyecto. Las fases repiten lo que el diagrama de Gantt ya muestra con sus barras, y los departamentos pierden el trabajo que cae entre dos de ellos.

La NASA enumera Diseño, Ingeniería y Fase A entre los elementos que “no son productos y normalmente no deberían usarse” como subdivisiones de la EDT, siendo la Fase A “un marco temporal”^[1]. Sus contraejemplos basados en fases y en funciones llevan el mismo pie, “Este enfoque no se recomienda”^[1]. La misma sección señala el tirón que hay detrás de los árboles con forma de departamentos. La gente pregunta “¿Dónde estoy yo en esa EDT?” y quiere elementos que reflejen su propia área de responsabilidad, un error que según el manual debe evitarse^[1]. La responsabilidad pertenece a una matriz aparte que cruza la EDT con el organigrama^[1], y en un proyecto de tres personas esa matriz es una columna Responsable.

Por qué los equipos pequeños ponen fases en el nivel 2, y cuándo tienen razón#

Los equipos pequeños suelen acabar con Diseño, Construcción, Pruebas y Publicación en el nivel 2, sobre todo cuando el árbol y el cronograma se construyen en la misma cuadrícula la misma tarde y las filas de resumen se convierten en cajones de tiempo. El coste aparece semanas después. Las redirecciones de las páginas antiguas no pertenecen ni a Diseño ni a Construcción, así que en un árbol por fases nadie las estima.

Nuestra recomendación: para un equipo de tres a diez personas, pon los entregables en el nivel 2 y muestra las fases como hitos en el cronograma. El diagrama de Gantt ya muestra el tiempo, así que un nivel de fases lo repite. Un nivel de entregables responde de un vistazo a “¿está completo el centro de ayuda?” y permite leer el estado semanal entregable por entregable.

La excepción es un contrato aprobado y pagado fase a fase, como un descubrimiento a precio cerrado seguido de una construcción financiada por separado. La aceptación y la facturación necesitan un total por fase, y la conformidad del cliente abre la fase siguiente. Con las fases en el nivel 2, ese total es una fila de resumen en lugar de una suma manual.

Cuántos niveles y cómo numerarlos#

La NASA vincula el número de niveles con “el tamaño y la complejidad del esfuerzo total, el grado de incertidumbre técnica, las estructuras organizativas implicadas y el criterio de la dirección sobre la necesidad”^[1], y no todas las ramas tienen que detenerse a la misma profundidad. Como regla general, tres niveles encajan con un equipo de tres a diez personas durante dos o tres meses, con los paquetes de trabajo directamente bajo los entregables. El límite es la reunión semanal de seguimiento: a uno o dos minutos por paquete, entre 15 y 20 paquetes llenan media hora. Baja a un cuarto nivel en una rama cuando un paquete de trabajo necesitaría dos responsables, o cuando su estimación pesimista sea más del doble de la optimista. La misma decisión un nivel más abajo, dentro del cronograma, se trata en cuándo dividir una tarea en subtareas.

Los códigos decimales indican el nivel de un elemento y el elemento al que pertenece. El código 1.2.3 está en el nivel 3 bajo 1.2. Una vez compartido el plan, los informes de estado y los tickets citan esos códigos, así que un elemento nuevo va al final de su rama, como 1.3.3 después de 1.3.2, aunque quedara mejor en medio.

Un ejemplo resuelto: lanzar un centro de ayuda#

Una empresa de software sustituye un manual en PDF y un conjunto de páginas antiguas de documentación por un centro de ayuda público. El equipo lo forman una redactora técnica, un desarrollador front-end y la responsable de soporte, que además dirige el proyecto. La primera versión es solo en inglés.

El primer borrador de la EDT tenía 10 paquetes de trabajo. Al leer cada rama con la primera prueba se añadieron cuatro. Nadie había aprobado los borradores, las páginas antiguas guardadas en favoritos dejarían de funcionar en el lanzamiento, el producto seguiría apuntando al PDF y soporte seguiría respondiendo tickets con el manual antiguo.

La salida a producción no está en el árbol porque no tiene alcance propio; solo marca el momento en que termina el trabajo anterior. Entra en el cronograma como hito, igual que “Contenido aprobado”.

Cada paquete de trabajo se convierte en una tarea con nombre en verbo, lo que cumple la regla de la NASA según la cual el nivel más bajo de cada elemento “debe tener al menos una tarea o actividad”^[1]. Las duraciones están en días laborables y todos los vínculos son fin a inicio (la guía de dependencias entre tareas y desfase explica los otros tres tipos). Los dos hitos están al final de sus ramas, de modo que una herramienta que numera todas las filas conserva los códigos de paquete de trabajo de la EDT.

La publicación espera a la búsqueda porque el diccionario dice que un artículo está terminado solo cuando la búsqueda lo devuelve. Sin ese vínculo, búsqueda y analítica mostrarían 13 días de holgura y podrían retrasarse más allá de la publicación sin que nadie lo notara.

La gestión del proyecto (1.5.1) es una tarea de nivel de esfuerzo: va del día 1 al día 27 a razón de unas pocas horas por semana y no condiciona nada, así que queda fuera de la lectura de la ruta crítica. Las redirecciones usan los slugs acordados en el inventario y esperan a la búsqueda solo porque la misma persona desarrolla ambas. Los enlaces dentro de la aplicación esperan a las URL publicadas porque salen en una versión del producto, y uno roto exige otra versión.

El proyecto dura 27 días laborables. La ruta crítica pasa por inventario, redacción, capturas, revisión, publicación, enlaces en la aplicación, prueba de aceptación y anuncio, 2 + 11 + 3 + 3 + 2 + 3 + 2 + 1 = 27 días, y atraviesa cuatro de las cinco ramas. Un informe de estado por entregable mostraría Plataforma casi lista el día 9, con tres de sus cuatro paquetes terminados, mientras que el paquete que decide la fecha, la prueba de aceptación, no puede empezar antes del día 25. La puesta en marcha, el tema y la búsqueda tienen 10 días de holgura, las redirecciones 13 y la formación 5.

La redacción concentra el mayor riesgo: veintitrés artículos en 11 días son algo más de dos al día para una sola redactora, y cada día de retraso mueve la salida a producción. Merece una estimación de tres puntos (cómo estimar la duración de las tareas); la guía de la ruta crítica explica los cálculos que hay detrás de los valores de holgura.

La revisión de carga de trabajo encuentra un hueco: el desarrollador no tiene nada programado del día 12 al día 21. Hay que acordar los slugs al terminar el inventario, quitar los enlaces de la aplicación de detrás de la publicación (predecesoras 1.1.1 y 1.3.2) y ejecutarlos los días 12–14. La publicación enlaza entonces directamente con la prueba de aceptación, que empieza el día 22. La salida a producción pasa al final del día 23 y el anuncio al día 24. Es ejecución rápida (cómo recuperar un proyecto retrasado), y amplía la apuesta por los slugs del inventario a enlaces entregados dentro del producto, donde un slug renombrado exige una versión para corregirse.

Errores frecuentes#

• Reutilizar sin cambios la EDT del proyecto anterior. La NASA advierte contra arrastrar “cualquier error o rasgo indeseable de la EDT anterior”^[1]. Parte de ella si te ayuda, pero vuelve a pasar la primera prueba contra el alcance de este proyecto.
• Elementos llamados “Reuniones” o “Retrabajo”. Ninguno es algo que el proyecto produzca, y el retrabajo figura en la lista de términos no productivos de la NASA^[1]. El tiempo de reuniones va bajo gestión del proyecto, y el retrabajo dentro del paquete que corrige.
• La salida a producción como paquete de trabajo. No tiene alcance que estimar.

Cuándo no merece la pena una EDT completa#

Por debajo de unas 15 tareas con un único responsable, como regla general, una lista plana de tareas con una línea “terminado cuando” en cada fila cumple la función de un árbol y un diccionario. Aun así, pasa la primera prueba a la lista.

Desglosar cada rama hasta los paquetes de trabajo desde el primer día sale mal con el trabajo que queda a meses vista, porque inventa una precisión que el trimestre siguiente desmentirá. La alternativa de la NASA es el paquete de planificación, que “define el trabajo lejano a un nivel resumido”^[1] y se divide en paquetes de trabajo a medida que el trabajo se acerca. En un cronograma es una fila con una duración aproximada y una nota con la fecha límite para desglosarla.

Cómo hacerlo en Planitude#

Construye el árbol en el diagrama de Gantt, sin límite de niveles. Con Tab una fila pasa a ser subtarea de la de arriba, y con Shift+Tab vuelve a salir. Planitude llama fases a las filas de resumen; ponles el nombre de los entregables y los paquetes de trabajo pasan a ser sus subtareas.

Para partir de una hoja de cálculo, importa el archivo Excel o CSV. Planitude reconstruye las filas de resumen a partir de una columna EDT, una columna de nivel o la sangría, lee las predecesoras escritas como códigos EDT y muestra primero una vista previa. Una plantilla o un plan propuesto por el asistente de IA son los otros puntos de partida.

La columna EDT es de solo lectura. Las filas nuevas toman un código según su posición, hitos incluidos. Los códigos de un archivo importado (.mpp incluido), de una plantilla o de un proyecto duplicado se guardan tal cual y no cambian al mover filas, así que añade las filas nuevas al final de su rama. Para obtener códigos como 1.2.3, pon todo bajo una fila de resumen con el nombre del proyecto. No hay diccionario de la EDT; el alcance y la línea “terminado cuando” van en las notas de la tarea.

Preguntas frecuentes#