Czy możesz mi powiedzieć, jak mogę użyć wartości luzu w moim diagramie sieci, aby go ponownie wyregulować (jeśli ma zastosowanie)? Korzystając z poniższej tabeli, obliczyłem wartość luzu i narysowałem diagram sieci. 
Znajdowanie wartości luzu: 
A->B->E->F = 14 weeks is the critical path A->B->D->F = 10 weeks A->C->E->F = 12 weeks Chcę zachować pierwotny czas trwania projektu w stanie nienaruszonym (dlatego nie zmieni liczby tygodni wykorzystanych w ścieżce krytycznej). Ale chcę zmniejszyć liczbę tygodni używanych na ścieżkach niekrytycznych. Czy mogę to zrobić, używając wartości zapasu czasu (lub innej metody)?
Komentarze
- Czy jest to bardziej związane z zarządzaniem projektami? lub pytanie, jak napisać oprogramowanie, aby odkryć ściślejszą oś czasu?
- @MichaelT Cześć, to ' jest bardziej związane z zarządzaniem projektami
- OK, dziękuję. nie ' nie wiedział, gdzie zadać pytanie. ludzie ze stackoverflow powiedzieli mi, żebym opublikował to tutaj.
- Najlepiej jest oflagować pytanie do migracji do innej witryny, zamiast publikować ponownie. W ten sposób linki " to należy do tego miejsca " są lepiej ustalone w wymianie stosów. Ponowne opublikowanie pytania oznacza, że masz zamknięte pytanie w jednym miejscu, a otwarte w innym. Ludzie SO często uważają, że wszystko, co nie ' nie należy do SO, należy do P.SE, co nie jest ' nie zawsze poprawne . Jeśli masz pytania dotyczące tego, gdzie coś należy, często zaleca się dołączenie do pokoju rozmów (pokój rozmów P.SE ' nazywa się tablicę i zapytaj.
- Dlaczego chcesz to zrobić?
Odpowiedz
TL; DR
Twoje wartości zmiennoprzecinkowe dla zadań podkrytycznych nie są tak naprawdę wolne przez resztę projektu. Możesz zwiększyć zmiennoprzecinkowe krytyczne zadania ze standardowymi technikami zarządzania projektami, takimi jak:
- Zmniejszenie zakresu podkrytycznych elementów zadań.
- Zwiększenie zasobów przydzielonych do każdego zadania lub kamienia milowego.
- Eliminacja nieistotnych kamieni milowych lub elementów pracy.
Chociaż nie jest to zalecane, możesz również zastosować techniki ze ścieżki krytycznej takie jak „szybkie śledzenie” lub „rozwalenie ścieżki” zadań podkrytycznych, ale tak naprawdę nie jest to część oficjalnej metodologii. Stosowanie tych technik z dala od krytyków l łańcuch może skrócić czas trwania awarii zadań podkrytycznych, ale generalnie w tym celu powoduje kanibalizację zasobów ze ścieżki krytycznej.
Do czego służy Slack
Slack w harmonogramie projektu generalnie spełnia kilka głównych celów:
- De-optymalizacja podprocesów w celu usprawnienia ogólny plan projektu.
- Zapobiega błędowi 100-procentowego wykorzystania procesu kruchości procesu.
- Daje zbiory czasu, pieniędzy lub zespołu do pożyczania, zamiast wymuszać ponowne obliczenie twojego planu przy każdej czkawce.
Twoja ścieżka krytyczna nie ma luzu
Twoja ścieżka krytyczna nie ma luzu. Definiujesz ścieżkę krytyczną jako:
A-> B-> E-> F = 14 tygodni to ścieżka krytyczna
Żadne z powiązań między ścieżką krytyczną nie ma luzu. Nie mam pojęcia, czy jest to prawdą w prawdziwym życiu. Jednak twój diagram wyraźnie mówi Slack = 0 dla każdego z elementów ścieżki krytycznej. Weź pod uwagę, że:
(0 float) * (4 chained milestones) = no slack on critical path Ponieważ masz zero luzu w łańcuchu krytycznym, wszelkie rzeczywiste niedoskonałości procesu spowodują opór projekt. Oznacza to, że żadne elementy na Twojej ścieżce krytycznej nie mogą w ogóle zaakceptować żadnego poślizgu bez zmuszania Cię do ponownego obliczenia całego harmonogramu, a także może zmusić Cię do ponownej oceny budżetu lub dat wysyłki. Wydaje się to złe.
Twoja podkrytyczna ścieżka nie dodaje luzu
Opóźnienia w zadaniach lub kamieniach milowych, które nie znajdują się na twojej ścieżce krytycznej, nie powinny opóźniać całego projektu. nie zdefiniowano, co reprezentują te niekrytyczne zadania, ale ponieważ nie znajdują się one na Twojej ścieżce krytycznej, prawdopodobnie reprezentują:
- Funkcje opcjonalne.
- Dodatkowy zakres.
- Fajne do posiadania.
- Ćwiczenia związane z ponownym prezentowaniem ciastek owocowych lub coś innego równie niezwiązanego z produktem, który można wysłać.
Niezależnie od tego, co reprezentują, a nawet jeśli są niezbędne dla produktu końcowego, luz w zadaniach podkrytycznych pozwala tylko dostosować daty rozpoczęcia i zakończenia tych zadań w ramach tolerancji; nie kupują Ci niczego związane z Twoim łańcuchem krytycznym.
Lepszy model dla Slacka ze ścieżką krytyczną
Zgodnie z wpisem Wikipedii dotyczącym metody ścieżki krytycznej :
Chociaż diagram aktywności na strzałce („Wykres PERT”) jest nadal używany w kilku miejscach, został on zasadniczo zastąpiony przez ćwiczenie – diagram na węźle, na którym każda czynność jest pokazana jako ramka lub węzeł, a strzałki reprezentują logiczne relacje przechodzące od poprzednika do następcy, jak pokazano tutaj na „diagramie aktywności na węźle”.
Zaletą tego modelu w stosunku do tego, którego dotyczy pytanie, jest to, że umożliwia on modelowanie wariancji na ścieżce krytycznej, czego obecnie nie zapewnia Twoja próbka. Warto więc ponownie ocenić to, co próbujesz modelować i czy aktywność w węźle zapewni lepsze narzędzie do planowania dla konkretnego przypadku użycia .
Odpowiedź
Ale chcę zmniejszyć liczbę tygodni używanych na ścieżkach niekrytycznych.
Czytam to, ponieważ chcesz, aby całkowity czas trwania twojej sieci niekrytycznej ścieżki zmniejszył się, zwiększając w ten sposób zapas czasu na tych ścieżkach. Aby to zrobić, wszystko, co musisz zrobić, to zmniejszyć docelowy czas trwania tych pakietów, które są poza ścieżką krytyczną.
Jednak nie jestem pewien, jaka jest wartość takiego działania. Początkowe założenie jest takie, że w ramach probabilistycznego rozkładu czasu trwania każdego z twoich pakietów celujesz w czas trwania, który jest gdzieś w pobliżu TRYBU tej dystrybucji, cel, który reprezentuje realistyczną możliwość, ale także jest wystarczająco ubogi, aby nie stanowić nadmiernego buforowania. Zmniejszając ten czas trwania, zwiększasz ryzyko, a aby je złagodzić, w końcu zwiększasz wykorzystanie zasobów i / godziny pracy, aby sprostać bardziej agresywnemu docelowemu czasowi trwania. Czas trwania = wykorzystanie pracy / zasobów.
To z kolei zagraża działaniom związanym z pracą tych pakietów na ścieżce krytycznej, co bezpośrednio zagrozi całkowitemu czasowi trwania.
Oczywiście z drugiej strony zwiększasz swój zapas czasu, więc masz tam kilka cykli, aby poradzić sobie z niekorzystnymi odchyleniami harmonogramu. Jednak wszystko to wygląda super na papierze, ale twoja rzeczywistość będzie zupełnie inna.
Twoje inne ryzyko polega na tym, że Twoja krytyczna ścieżka planowania jest ważna tylko podczas planowania. W momencie, gdy naciśniesz idź i rozpoczniesz pracę i zaczniesz rozwijać swoje pakiety w harmonogramie, Twoja ścieżka (y) krytyczna ZMIENI SIĘ i zmieni się i zmieni i zmieni. Pakiety, które arbitralnie skróciłeś czas trwania, mogą i prawdopodobnie znajdą się w nowej krytycznej ścieżce (ścieżkach), a ponieważ skróciłeś czas trwania i zwiększyłeś zagrożenie, stworzyłeś większe zagrożenie dla ogólnego czasu trwania harmonogramu.
Podsumowując, nie widzę logiki w tym, co próbujesz zrobić z perspektywy planowania / planowania. To nie znaczy, że nie ma logiki, po prostu tego nie widzę i nigdy wcześniej nie słyszałem, żeby ktoś o tym dyskutował.