Ejemplos de diagrama de red y cómo usarlos

Un diagrama de red es una representación visual de las tareas de un proyecto y sus dependencias. Muestra qué debe ocurrir antes de que otra cosa pueda comenzar, y en qué orden fluye el trabajo de principio a fin.

Un diagrama de Gantt muestra fechas. El diagrama de red muestra la lógica: por qué el proyecto tiene esa secuencia y dónde están los cuellos de botella estructurales. Los dos se complementan: el software de proyectos suele construir el Gantt a partir de las dependencias de la red.

En gestión de proyectos también se llama red de precedencias o red de actividades. Las dos técnicas que lo popularizaron nacieron casi al mismo tiempo: CPM, desarrollada en DuPont y Remington Rand en 1957, y PERT, creada en 1958 por la Marina de Estados Unidos con Booz Allen Hamilton para el programa de misiles Polaris.

Los dos formatos más usados

Existen dos variantes principales:

• AON (actividad en el nodo): cada nodo es una tarea y las flechas indican dependencia. Es el formato que usan MS Project, Primavera P6 y casi todas las herramientas de planificación actuales.
• AOA (actividad en la flecha): las flechas representan las tareas y los nodos son eventos o hitos. Hoy es menos común, pero es el formato de la literatura clásica de PERT.

Para la mayoría de los equipos, AON es más intuitivo y es el que ilustran los ejemplos de este artículo.

Ejemplo de diagrama de red: lanzamiento de un producto

Imagina un lanzamiento con seis tareas. El siguiente ejemplo muestra la estructura de dependencias y la duración estimada de cada una:

Tarea	Descripción	Duración	Depende de
A	Definir especificaciones	3 días	-
B	Diseño de interfaz	5 días	A
C	Desarrollo de funcionalidades	8 días	A
D	Pruebas de usabilidad	4 días	B
E	Pruebas técnicas	6 días	C
F	Lanzamiento	1 día	D, E

En un diagrama visual, esto se dibuja así:

• A apunta a B y a C.
• B apunta a D.
• C apunta a E.
• D y E apuntan a F.

El resultado es una red con dos caminos paralelos que convergen en el lanzamiento:

Camino	Suma de duraciones	Total
A-B-D-F	3 + 5 + 4 + 1	13 días
A-C-E-F	3 + 8 + 6 + 1	18 días

El camino A-C-E-F es el más largo y dicta la fecha de entrega: el proyecto necesita 18 días como mínimo. Las tareas B y D tienen 5 días de holgura; si el diseño de interfaz se atrasa tres días, el lanzamiento sigue en pie. Un día de atraso en el desarrollo o en las pruebas técnicas mueve la fecha final.

Ese camino más largo se llama ruta crítica. Puedes profundizar en cómo calcularla con el método CPM y qué hacer con la holgura en el ejemplo de ruta crítica paso a paso.

El método PERT: agregar incertidumbre al diagrama

El método PERT (Program Evaluation and Review Technique) extiende el diagrama de red añadiendo estimaciones probabilísticas de duración. Es útil cuando no tienes datos históricos sólidos y la variabilidad es alta.

La lógica central es calcular una duración esperada para cada tarea a partir de tres estimados:

Duración esperada = (O + 4M + P) / 6

Donde:

• O = estimado optimista (todo sale bien)
• M = estimado más probable
• P = estimado pesimista (todo sale mal)

Ejemplo de cálculo PERT para una tarea

Supón que la tarea C (Desarrollo de funcionalidades) tiene estas estimaciones:

Escenario	Valor
Optimista (O)	5 días
Más probable (M)	8 días
Pesimista (P)	17 días

Aplicando la fórmula:

Paso	Cálculo	Resultado
4 × M	4 × 8	32
O + 4M + P	5 + 32 + 17	54
Duración esperada	54 / 6	9 días

La duración esperada es 9 días, aunque el escenario más probable sean 8. Con ese valor, la ruta crítica del ejemplo pasa de 18 a 19 días. La diferencia parece menor en una tarea y se acumula cuando sumas varias en la misma ruta.

PERT hace visible y cuantificable una incertidumbre que existe de todos modos. Aplicado sobre el diagrama de red, permite estimar rangos realistas en lugar de fechas únicas que luego nadie cumple.

Cómo se aplica en el trabajo: tres usos concretos

1. Identificar dependencias bloqueantes antes de que bloqueen. Cuando el equipo dibuja el diagrama juntos, aparecen dependencias que nadie había declarado. Muchos bloqueos crónicos existen porque el flujo nunca se dibujó. Si una tarea aparece en el diagrama con tres predecesoras, esa tarea merece atención inmediata.

2. Distribuir trabajo en paralelo. El diagrama revela qué tareas pueden correr en simultáneo. En el ejemplo anterior, B y C pueden ejecutarse al mismo tiempo. Sin el diagrama, muchos equipos las hacen en serie por inercia, alargando el proyecto sin necesidad.

3. Delegar con contexto. Cuando delegas una tarea sin mostrar el diagrama, la persona no sabe qué la bloquea ni a quién bloquea. Cuando delegas con el diagrama, cada responsable entiende su lugar en el flujo. Eso reduce las interrupciones y acelera la toma de decisiones en el nivel donde ocurre el trabajo. Si tu equipo trabaja por iteraciones, el sprint backlog cumple una función parecida a escala de una o dos semanas.

Errores comunes al construir un diagrama de red

Omitir dependencias externas. El diagrama refleja solo lo que el equipo controla y omite aprobaciones, proveedores o áreas de soporte. Esas dependencias son frecuentemente las que retrasan el proyecto.

Dibujar el diagrama una vez y no actualizarlo. Un diagrama que no evoluciona con el proyecto es decoración. Debe revisarse al inicio de cada fase o cada vez que una estimación cambie de forma significativa.

Confundir secuencia con prioridad. Una tarea puede ser urgente y quedar fuera de la ruta crítica. El diagrama de red ordena la lógica de ejecución. El valor de negocio de cada tarea se decide en otra conversación. Combinar ambas lecturas lleva a mejores decisiones.

Corregir estos errores es cuestión de dedicar una hora al inicio del proyecto a construir el diagrama con todo el equipo presente, incluidas las áreas de las que depende el trabajo.

Cuándo conviene usarlo y cuándo no

El diagrama de red aporta más valor cuando:

• El proyecto tiene más de ocho o diez tareas con dependencias cruzadas.
• Participan varios equipos o áreas que deben coordinarse.
• La fecha de entrega es fija y cualquier retraso tiene costo real.

Aporta menos cuando el trabajo es lineal, el equipo es pequeño y las dependencias son obvias. En esos casos, una lista ordenada o un tablero Kanban simple cumplen la función sin el costo de construir la red.

La herramienta vale lo que la conversación que genera. Si el equipo termina la sesión con claridad sobre quién depende de quién y cuándo, el diagrama cumplió su función, independientemente de si quedó en papel, en una pizarra o en software.