¿Puede decirme cómo puedo usar el valor de holgura en mi diagrama de red para reajustarlo (si es aplicable)? Usando la siguiente tabla, calculé el valor de holgura y dibujé un diagrama de red. 
Encontrar valor de holgura: 
A->B->E->F = 14 weeks is the critical path A->B->D->F = 10 weeks A->C->E->F = 12 weeks Quiero mantener intacta la duración del proyecto original (por lo tanto, no va a cambiar el número de semanas utilizadas en la ruta crítica). Pero quiero reducir la cantidad de semanas utilizadas en rutas no críticas. ¿Puedo hacer eso usando los valores de holgura (u otro método)?
Comentarios
- ¿Esto está más relacionado con la gestión de proyectos? o una pregunta de cómo se escribe el software para descubrir una línea de tiempo más ajustada?
- @MichaelT Hola, ' está más relacionado con la gestión de proyectos
- Ok, gracias. No ' no sabía dónde hacer la pregunta. la gente de stackoverflow me dijo que lo publicara aquí.
- Es mejor marcar una pregunta para migrarla a otro sitio en lugar de volver a publicarla. De esa manera, los enlaces de " que pertenece allí " se establecen más claramente en el intercambio de pila. Volver a publicar una pregunta significa que tiene una pregunta cerrada en un lugar y una abierta en otro. La gente de SO suele opinar que todo lo que no ' t pertenece a SO pertenece a P.SE, que no es ' t siempre correcto. . Si tiene preguntas sobre a dónde pertenece algo, a menudo se recomienda unirse a una sala de chat (la sala de chat de P.SE ' se llama la pizarra y pregunte.
- ¿Por qué quiere hacer esto?
Responder
TL; DR
Sus valores flotantes para tareas subcríticas no están realmente flojos para el resto del proyecto. Puede aumentar float en sub- tareas críticas con técnicas de gestión de proyectos estándar como:
- Reducir el alcance de los elementos de tareas subcríticas.
- Incrementar los recursos asignados a cada tarea o hito.
- Eliminar hitos o elementos de trabajo no esenciales.
Si bien no se recomienda, también puede aplicar técnicas de la ruta crítica como «acelerar» o «interrumpir el camino» de tareas subcríticas, pero eso no es realmente parte de la metodología oficial. Aplicar estas técnicas lejos de las críticas La cadena l puede reducir la duración del bloqueo de las tareas subcríticas, pero generalmente canibalizará los recursos de la ruta crítica para hacerlo.
Para qué sirve Slack
Slack en el cronograma de un proyecto generalmente logra varios objetivos principales:
- Desoptimiza los subprocesos para suavizar el plan general del proyecto.
- Evita que la falacia de la utilización del 100% haga que su proceso sea frágil.
- Le brinda cantidades de tiempo, dinero o capacidad de equipo para contraer préstamos, en lugar de forzar recalcular su plan en cada contratiempo.
Su ruta crítica no tiene holgura
Su ruta crítica no tiene holgura. Defina la ruta crítica como:
A-> B-> E-> F = 14 semanas es la ruta crítica
Ninguno de los vínculos entre la ruta crítica tiene holgura. Si esto es cierto o no en la vida real, no tengo ni idea. Sin embargo, su diagrama dice explícitamente Slack = 0 para cada uno de los elementos de la ruta crítica. Tenga en cuenta que:
(0 float) * (4 chained milestones) = no slack on critical path Dado que tiene cero holgura en su cadena crítica, cualquier imperfección del proceso de la vida real creará una resistencia proyecto. Eso significa que ningún elemento en su ruta crítica puede aceptar ningún deslizamiento sin forzarlo a recalcular todo su programa, y puede obligarlo a reevaluar su presupuesto o fechas de envío también. Eso parece malo.
Su ruta subcrítica no agrega holgura
Las demoras en tareas o hitos que no están en su ruta crítica no deberían retrasar el proyecto en general. Usted No hemos definido lo que representan estas tareas no críticas, pero como no se encuentran en su ruta crítica, probablemente representan:
- Funciones opcionales.
- Alcance adicional.
- Es bueno tenerlos.
- Ejercicios para volver a regalar pasteles de frutas, o algo igualmente no relacionado con un producto que se puede enviar.
Independientemente de qué representan, e incluso si son esenciales para el producto final, la holgura en las tareas subcríticas solo le permiten ajustar las fechas de inicio o finalización de esas tareas dentro de las tolerancias; no le compran nada relacionados con su cadena crítica.
Un mejor modelo para Slack con ruta crítica
Según la entrada de Wikipedia sobre el método de ruta crítica :
Aunque el diagrama de actividad en flecha («Gráfico PERT») todavía se usa en algunos lugares, generalmente ha sido reemplazado por la actividad- diagrama en el nodo, donde cada actividad se muestra como un cuadro o nodo y las flechas representan las relaciones lógicas que van del predecesor al sucesor, como se muestra aquí en el «Diagrama de actividad en el nodo».
El beneficio de este modelo sobre el de su pregunta es que le permite modelar la varianza en la ruta crítica, que es algo que su muestra no proporciona actualmente. Por lo tanto, puede valer la pena volver a evaluar lo que está tratando de modelar y si la actividad en el nodo proporcionará una mejor herramienta de planificación para su caso de uso específico .
Respuesta
Pero quiero reducir el número de semanas utilizadas en rutas no críticas.
Estoy leyendo esto porque desea que la duración total de su red de rutas no críticas disminuya, aumentando así la holgura en esas rutas. Para hacer esto, todo lo que necesita hacer es disminuir la duración objetivo de aquellos paquetes que están fuera de la ruta crítica.
Sin embargo, no estoy seguro de cuál es el valor de hacer esto. La suposición inicial es que, dentro de la distribución probabilística de duración de cada uno de sus paquetes, está apuntando a una duración que está en algún lugar alrededor del MODO de esa distribución, un objetivo que representa una posibilidad realista pero también lo suficientemente delgado como para no constituir un almacenamiento en búfer excesivo. Cuando reduce esa duración, aumenta el riesgo y, para mitigar, termina aumentando la utilización de recursos y las horas de trabajo para cumplir con la duración objetivo más agresiva. Duración = Trabajo / Utilización de recursos.
Esto luego amenaza la actividad laboral en esos paquetes en la ruta crítica, lo que amenazará directamente su duración general.
Por supuesto, en el otro lado de eso, está aumentando su holgura, por lo que tiene algunos ciclos allí para hacer frente a variaciones desfavorables de programación. Sin embargo, todo esto se ve genial en el papel, pero su realidad será muy diferente.
Su otro riesgo es que su camino crítico en la planificación es válido solo en la planificación. En el momento en que presione ir y comience a trabajar y comience a progresar sus paquetes en el cronograma, su ruta crítica (s) cambiará y cambiará y cambiará y cambiará. Esos paquetes cuya duración redujo arbitrariamente pueden caer y probablemente caerán en las nuevas rutas críticas y, dado que redujo la duración y aumentó su amenaza, ahora ha creado una amenaza mayor para la duración general de su programa.
Con todo, no veo la lógica de lo que está intentando hacer desde una perspectiva de programación / planificación. Eso no significa que no haya lógica, simplemente no puedo verlo y nunca había escuchado a nadie discutir esto antes.