WBS: estructura de desglose de trabajo, con ejemplo

El WBS —estructura de desglose de trabajo, a veces EDT— es un árbol de entregables. El nivel 1 es el proyecto. El nivel 2 son los bloques grandes que, juntos, son el proyecto. El nivel 3 son paquetes que una persona puede estimar y terminar. Cada caja es un resultado, no una actividad: “UI de las 5 páginas”, no “diseñar”.

Una lista de tareas mezcla “escribir copy”, “reunión con el cliente” y “homepage” en el mismo nivel, y nadie sabe si el proyecto está 40% o 80% hecho. Un WBS te deja decir: de cinco entregables de nivel 2, tres están cerrados y dos no. También es la forma más honesta de escribir el alcance del proyecto: si un pedido no aparece como rama, no está en el proyecto.

1. Orientado a entregables. Cada nodo se puede mostrar o aceptar. Si el nombre es un verbo (“investigar”, “coordinar”), reescríbelo como resultado.
2. Regla del 100%. Los hijos de un nodo suman todo el trabajo de ese nodo, y nada más. Si “Diseño” no incluye los wireframes, está incompleto. Si incluye “reuniones semanales”, mezcla gestión con entregable.
3. Parar cuando un dueño estima en días. Un paquete de “un trimestre” es un subproyecto. Uno de “40 minutos” es una tarea. El corte práctico: una persona, en días — no en meses, no en horas.

La regla del 100% es la que más se viola. Equipos dejan afuera el contenido porque “eso lo hace marketing”, o el QA porque “se hace sobre la marcha”. Si el proyecto no existe sin eso, va en el árbol.

Tres artefactos se confunden porque todos “parten el trabajo”:

El WBS es el qué. El cronograma de proyecto es el cuándo. Si empiezas por el Gantt, fechas trabajo que todavía no nombraste. La ruta crítica se calcula sobre el cronograma, no sobre el WBS — pero sin WBS no hay dependencias honestas.

Tres niveles alcanzan para un proyecto de semanas o pocos meses. Más de cuatro suele ser microgestión:

No bajes “porque el software tiene sub-tareas”: bajas porque un humano no puede estimar el nodo tal como está.

Un sitio de empresa pequeña, 5 páginas, sin e-commerce. El WBS no incluye “standups” ni “elegir herramienta”. Incluye lo que el cliente puede aceptar:

• 1.0 Rediseño del sitio
• 1.1 Investigación — auditoría del sitio, entrevistas a 5 usuarios, brief de contenido
• 1.2 Diseño — arquitectura de información, wireframes de 5 páginas, UI de páginas clave
• 1.3 Contenido — textos de las 5 páginas, imágenes y assets
• 1.4 Desarrollo — front de las 5 páginas, formularios y analytics, QA en 3 navegadores
• 1.5 Lanzamiento — migración de dominio, checklist de go-live, comunicación interna

“Contenido” es hermano de “diseño”, no una subtarea: si el copy no tiene dueño, el diseño se rehace cuando el texto llega tarde. Eso es lo que el WBS hace visible antes de estimar tiempos. Un lanzamiento de producto usa la misma forma con otras ramas. El árbol cambia; las tres reglas no.

No necesitas software de WBS. Una hoja o un documento con indentación alcanzan:

1. Escribe el entregable final como 1.0. Si no puedes nombrarlo, todavía no hay alcance.
2. Lista 5–8 entregables de nivel 2 que, juntos, sean el 100%. Lo que falte, súbelo; lo que sobre, sácalo.
3. Parte cada nivel 2 en paquetes de nivel 3, con un dueño. Si dos personas lo “comparten”, pártelo.
4. Revisa la regla del 100% de abajo hacia arriba. Recién entonces pasa al cronograma.

Dos horas suelen alcanzar si está quien puede validar exclusiones. El WBS que se arma sin esa persona se reescribe a la semana.

• WBS de tareas. “Llamar al hosting”, “revisar con legal”. Reescríbelos como resultados, o sácalos: son actividades que cuelgan de un paquete.
• Demasiado profundo o demasiado plano. Cinco niveles para seis semanas es microgestión; un solo nivel con 40 ítems es una lista, no un WBS.
• Armarlo y no usarlo. El WBS alimenta el plan de proyecto y el cronograma. Si vive en un slide del kickoff, era un ejercicio.

Cuando entra un cambio de alcance, el primer movimiento es decidir en qué rama entra. El WBS es una de las 8 plantillas de gestión de proyectos que sí se usan: nombra el trabajo antes de fecharlo.