Puteți să-mi spuneți cum pot folosi valoarea slack din diagrama mea de rețea pentru a o reajusta (dacă este cazul)? Folosind următorul tabel, am calculat valoarea slack și am desenat o diagramă de rețea. 
Găsirea valorii slabe: 
A->B->E->F = 14 weeks is the critical path A->B->D->F = 10 weeks A->C->E->F = 12 weeks Vreau să păstrez intactă durata inițială a proiectului (prin urmare, eu sunt nu va schimba numărul de săptămâni utilizate în calea critică). Dar vreau să reduc numărul de săptămâni utilizate pe căi non-critice. Pot face asta folosind valorile slack (sau o altă metodă)?
Comentarii
- Este aceasta mai legată de managementul proiectului? sau o întrebare despre cum se scrie software-ul pentru a descoperi o cronologie mai strânsă?
- @MichaelT Bună, ' este mai legat de gestionarea proiectelor
- Bine, mulțumesc. ' nu știa unde să pun întrebarea. oamenii de la stackoverflow mi-au spus să-l postez aici.
- Este mai bine să semnalizez o întrebare pentru migrarea pe un alt site, mai degrabă decât repostarea. În acest fel, legăturile " aparțin acolo " sunt stabilite mai clar în schimbul de stive. Repostarea unei întrebări înseamnă că aveți o întrebare închisă într-un loc și o întrebare deschisă în altul. Oamenii SO sunt adesea de părere că orice lucru care nu ' t aparține SO aparține P.SE, ceea ce nu este întotdeauna corect ' . Dacă aveți întrebări despre locul în care aparține ceva, este recomandat adesea să vă alăturați unei camere de chat (camera de chat P.SE ' se numește tablă albă și întrebați.
- De ce doriți să faceți acest lucru?
Răspundeți
TL; DR
Valorile dvs. flotante pentru sarcinile sub-critice nu sunt de fapt slabe pentru restul proiectului. Puteți mări float pe sub- sarcini critice cu tehnici standard de gestionare a proiectelor, cum ar fi:
- Reducerea domeniului de aplicare al elementelor sarcinii sub-critice.
- Creșterea resurselor alocate fiecărei sarcini sau etapă.
- Eliminarea reperelor neesențiale sau a elementelor de lucru.
Deși nu este recomandat, puteți aplica și tehnici din calea critică cum ar fi „urmărirea rapidă” sau „blocarea căii” sarcinilor sub-critice, dar asta nu face parte din metodologia oficială. Aplicarea acestor tehnici departe de critică Lanțul poate reduce durata blocării a sarcinilor sub-critice, dar, în general, va canibaliza resursele din calea critică pentru a face acest lucru.
Pentru ce Slack
Slack într-un program al proiectului îndeplinește, în general, mai multe obiective principale:
- Dez-optimizează subprocesele pentru a netezi planul general al proiectului.
- Împiedică eroarea de utilizare de 100% să-ți facă procesul fragil.
- Vă oferă povești de timp, bani sau capacitatea echipei de a vă împrumuta, mai degrabă decât să forțați o recalcularea planului dvs. la fiecare sughiț.
Calea critică nu are slăbire
Calea critică nu are nicio slăbiciune. Definiți calea critică astfel:
A-> B-> E-> F = 14 săptămâni este calea critică
Niciuna dintre legăturile dintre calea critică nu are slăbiciune. Fie că acest lucru este adevărat sau nu în viața reală, habar n-am. Cu toate acestea, diagrama dvs. spune explicit Slack = 0 pentru fiecare dintre elementele de cale critice. Luați în considerare faptul că:
(0 float) * (4 chained milestones) = no slack on critical path Întrucât aveți zero slăbiciune în lanțul critic, orice imperfecțiuni ale procesului din viața reală vor crea proiect. Asta înseamnă că niciun articol din calea critică nu poate accepta orice derapaj deloc fără să vă oblige să recalculați întregul program și vă poate obliga să vă reevaluați bugetul sau datele de livrare. Pare rău.
Calea dvs. sub-critică nu adaugă slăbire
Întârzierile în sarcini sau repere care nu sunt pe calea critică nu ar trebui să întârzie proiectul general. Nu am definit ce reprezintă aceste sarcini non-critice, dar, deoarece acestea nu sunt pe calea ta critică, probabil că le reprezintă:
- Caracteristici opționale.
- Domeniu suplimentar.
- Plăcut.
- Exerciții de recompensare a tortului cu fructe sau altceva la fel de legat de un produs care poate fi expediat.
Indiferent de ce acestea reprezintă și chiar dacă sunt esențiale pentru produsul final, slăbiciunea în sarcinile sub-critice vă permite doar să ajustați datele de începere sau de sfârșit ale acelor sarcini în limitele toleranțelor; nu vă cumpără nimic legat de lanțul tău critic.
Un model mai bun pentru Slack cu cale critică
Conform articolului Wikipedia din metoda căii critice :
Deși diagrama activitate-pe-săgeată („Diagrama PERT”) este încă utilizată în câteva locuri, în general a fost înlocuită de activitate- diagramă on-nod, unde fiecare activitate este afișată ca o casetă sau nod și săgețile reprezintă relațiile logice care merg de la predecesor la succesor, așa cum se arată aici în „Diagrama Activity-on-nod”.
Avantajul acestui model față de cel din întrebarea dvs. este că vă permite să modelați varianța pe calea critică, ceea ce eșantionul dvs. nu oferă în prezent. Prin urmare, ar putea fi util să reevaluați ceea ce încercați să modelați și dacă activitatea pe nod va oferi un instrument de planificare mai bun pentru cazul dvs. de utilizare specific .
Răspuns
Dar vreau să reduc numărul de săptămâni utilizate în căile non critice.
Citesc acest lucru deoarece doriți ca durata totală a rețelei dvs. de căi non critice să scadă, crescând astfel slăbiciunea pe acele căi. Pentru a face acest lucru, tot ce trebuie să faceți este să reduceți durata țintă a acelor pachete care sunt în afara căii critice.
Cu toate acestea, nu sunt sigur ce valoare are acest lucru. Presupunerea inițială este că, în cadrul distribuției probabilistice a duratei fiecăruia dintre pachetele dvs., vizați o durată care se află undeva în jurul MODULUI respectivei distribuții, o țintă care reprezintă o posibilitate realistă, dar, de asemenea, suficient de slabă pentru a nu constitui supra-tamponare. Când reduceți această durată, creșteți riscul și, pentru a atenua, ajungeți la creșterea utilizării resurselor și / a orelor de lucru pentru a atinge durata țintă mai agresivă. Durata = Utilizarea resurselor.
Aceasta amenință apoi activitatea de lucru pe acele pachete pe calea critică, ceea ce vă va amenința direct durata totală.
Bineînțeles, pe de altă parte, vă creșteți slăbiciunea, astfel încât aveți câteva cicluri acolo pentru a face față variațiilor de program nefavorabile. Cu toate acestea, toate acestea arată super pe hârtie, dar realitatea ta va fi foarte diferită.
Celălalt risc este că calea ta critică la planificare este valabilă doar la planificare. În momentul în care apăsați pe go și începeți lucrul și începeți să vă progresați pachetele în program, calea (camerele) dvs. critice se vor schimba și se vor schimba și se vor schimba și se vor schimba. Acele pachete pe care le-ați redus în mod arbitrar pot și vor cădea probabil în noile căi critice și, întrucât ați redus durata și ați crescut amenințarea, ați creat acum o amenințare mai mare pentru durata totală a programului.
Una peste alta, nu pot vedea logica în ceea ce încercați să faceți din perspectiva planificării / planificării. Asta nu înseamnă că nu există logică, pur și simplu nu o pot vedea și nu am mai auzit pe nimeni discutând acest lucru până acum.