Plan de proiect. Planificarea proiectului. Noțiuni de bază. Caracteristicile planificării resurselor

Managementul de proiect este o simbioză a tehnologiei și a artei de a rezolva o sarcină unică la timp, în limita bugetului alocat pentru aceasta. Pentru ca proiectul să fie finalizat cu succes, este necesar să se realizeze o înțelegere între conducerea companiei și RM cum va fi implementat, de către cine, când și ce fel de lucru trebuie efectuat. Planul de proiect este considerat nu ca un document, ci ca un întreg set de soluții documentate care răspund la întrebările de mai sus. Vă prezint atenției un articol de recenzie care examinează elementele de bază ale tehnologiei de planificare a proiectelor.

Esența planificării proiectelor

Planificarea proiectului implică multe iterații interconectate, al căror rezultat este un singur master plan. Prin plan de proiect vom înțelege în continuare sistemul activităților planificate, documentate ca urmare a pregătirii. Acest sistem constă din parametri conectați într-un mod special, asigurând că o problemă de dezvoltare separată este rezolvată. Acești parametri sunt formați pe baza unui număr de domenii funcționale ale activității proiectului:

  • conţinut;
  • termenele limită;
  • cost;
  • personal;
  • provizii;
  • comunicații;
  • riscuri etc.

Planul este un element cheie al sistemului de management al proiectelor. Dacă PM a reușit să întocmească un set detaliat de documente de planificare, atunci el are dreptul de a se aștepta la primirea garantată a rezultatelor solicitate la sfârșitul lucrării. Pentru aceasta, timpul, resursele și alte aspecte trebuie bine planificate. Până la elaborarea unui plan, este imposibil să știi câți bani și timp vor fi necesari pentru a finaliza o sarcină unică. Fără un plan, managerul este practic lipsit de linii directoare pentru conformitatea lucrării cu obiectivele proiectului.

Trebuie să înțelegeți că planificarea nu aduce întotdeauna rezultate pozitive, dar concluziile negative pot aduce beneficii nu mai puține, și uneori chiar mai mari. În orice caz, eficiența investiției crește, iar profiturile obținute nu sunt risipite. Planificarea proiectelor pune bazele muncii productive și rezolvă următoarele probleme aplicate.

  1. Clarificați și detaliați obiectivele și rezultatele evenimentului.
  2. Determinați compoziția și domeniul de activitate.
  3. Estimați termenele și costurile bugetare.
  4. Întocmește un program și un buget pentru fazele principale sau întregul proiect.
  5. Faceți o estimare rafinată a cerințelor de resurse pentru fiecare fază sau pentru întreaga sarcină.
  6. Întocmește un plan de resurse.
  7. Efectuați o evaluare a riscurilor și creați un plan de răspuns la risc.
  8. Explicați clientului detaliile evenimentului.
  9. Acordați planul cu participanții principali.
  10. Distribuiți responsabilitatea pentru muncă și sarcini între participanți.
  11. Aprobați planul general.
  12. Clarificați planurile de interacțiune și planificarea procedurilor de management.

Locul planului de management al proiectului în etapa ciclului său de viață. Sursa: Ghidul PMBOK 5

Locul proceselor de planificare printre alte procese de implementare a proiectului. Sursa: Ghidul PMBOK 5

Planificarea proiectului nu poate fi lăsată în aer. Este precedat de inițiere, iar rezultatul acestor procese este execuția efectivă a proiectului. Și recunoaștem o serie de puncte importante pe care planificarea:

  • legat de un punct de timp specific din ciclul de viață al unei sarcini unice și de perioada semnificativă a acesteia (a se vedea diagramele prezentate mai sus);
  • iterativ – nu se termină după ce sunt scrise planurile, necesită o actualizare regulată până la faza de închidere activă;
  • cuprinzător - nu se limitează la un singur instrument și include o serie de instrumente și documente de ieșire relevante.

Compoziția extinsă a proceselor de planificare

Planul de proiect este diferit de planul de management al proiectului și de procesele de planificare aferente. După cum am definit deja, în sens larg, prin plan înțelegem un sistem de activități preplanificat pentru care se stabilește ordinea de execuție, succesiunea și calendarul lucrărilor. Într-un sens restrâns, un plan este un document care reflectă ordinea acțiunilor planificate și termenele de implementare. Un plan de management de proiect este rezultatul unor proceduri (procese) de planificare reglementate, în care principiul controlului este preluat de proceduri regulate, reglementate, pentru crearea planurilor sub formă de documente.

Definiții ale conceptelor de bază de planificare din PMI. Sursa: Ghidul PMBOK 5

Planificarea evenimentelor include două grupe de procese: procese pentru elaborarea directă a planurilor și proceduri auxiliare. Rezultatul unui bloc de dezvoltare este un document numit plan principal de proiect. Include un plan de calendar, un buget pentru eveniment și o serie de alte documente. Compoziția și conținutul lucrării, resursele necesare pentru implementarea lor determină succesiunea, durata și valoarea costurilor pentru producerea lor.

Planificarea riscurilor potențiale (identificare, identificare și evaluare) și managementul riscului influențează nu numai dezvoltarea programului, ci și nevoile bugetare. Clarificarea obiectivelor, definirea limitelor sarcinii unice și structurarea echipei și a responsabilităților pune bazele unui efort semnificativ de planificare a proiectului. În continuare, vă prezentăm atenției un model de conexiuni între principalele proceduri ale proceselor luate în considerare.

Model al proceselor de planificare în managementul proiectelor

Se știe că, conform standardului PMI, aproape fiecare secțiune a Ghidului PMBOK alocă un întreg bloc pentru planificare. Pe baza diagramei prezentate mai sus, acest lucru este destul de natural. Secțiunea PMBOK „Managementul integrării proiectelor” demonstrează imaginea cea mai holistică a managementului planificării și a creării unui singur master plan. Mai jos este un bloc local al diagramei de flux de date pentru dezvoltarea planului de management al evenimentelor.

Bloc de diagramă de flux de date de dezvoltare a planului de management al proiectului local

Blocul vizual prezentat mai sus este notabil din mai multe motive. Baza de cunoștințe privind managementul proiectelor, toată experiența dobândită în acest domeniu și reglementările sunt esențiale pentru succesul planificării. Acest lucru se aplică și standardelor, software-ului, structurii și culturii organizaționale, metodelor de management, infrastructurii etc. Carta este un ghid cheie pentru planificare. Aceste procese stau la baza integrării în planul general și oferă următoarele elemente de intrare pentru dezvoltarea versiunii sale finale:

  • planuri de management al parametrilor proiectului;
  • planuri de bază pentru conținut, cost și program;
  • actualizări de plan.

Etapele dezvoltării unui plan calendaristic

După cum ne amintim, managementul de proiect este construit pe „trei piloni”: conținutul muncii, restricții și riscuri. Dacă un manager știe să lucreze bine cu acești trei parametri, atunci nu există sarcini de nerezolvat pentru el. Să luăm în considerare dezvoltarea unui plan calendaristic din perspectiva acestor trei poziții și să împărțim acest proces în etape. Ne vom referi la prima și a doua etapă ca fiind conținutul lucrării.

  1. Etapa stabilirii si redactarii listei de lucrari. Destul de des se fac greșeli din cauza faptului că nu este posibilă prezentarea tuturor lucrărilor deodată. Pentru a determina calitativ compoziția operațiilor, este util să folosiți elementele de bază ale metodei de descompunere a lucrărilor secvențiale.
  2. Etapa de determinare a execuției proiectului din punct de vedere al succesiunii și duratei lucrărilor, care depind de tehnologia de implementare a acestora. Pentru a crea un rezultat de înaltă calitate al acestei etape, metoda deja menționată de descompunere secvențială a sarcinilor și evaluarea de către experți a duratei muncii folosind metode precum, de exemplu, brainstorming-ul sunt potrivite.
  3. Determinarea disponibilității resurselor. Evenimentul folosește o varietate de resurse: financiare, materiale, forță de muncă, informații etc. Din perspectiva resurselor financiare, este necesară legarea programului de lucru cu programul de finanțare. Se introduce conceptul de resurse limitate: specialiști și capacități unice. Acest lucru lasă o amprentă asupra succesiunii și duratei muncii.
  4. Definiţia external restrictions. Aceste restricții includ sezonalitatea, procesele tehnologice pentru furnizarea echipamentelor și diverse evenimente externe. Dacă luăm în considerare exemplul de dorințe speciale ale clientului (pentru anumiți parteneri) sau evenimente externe (de exemplu, momentul finalizării unei etape care coincide cu o sărbătoare națională), atunci astfel de evenimente sunt incluse în evenimentul din formă de repere.
  5. Etapa creării unui plan de răspuns la risc. Analizăm riscurile proiectului și dezvoltăm un plan de răspuns pentru principalele amenințări. Ținând cont de acest plan, definitivăm apoi programul.

A treia și a patra etapă se referă la pozițiile de restricții, a cincea etapă - la riscuri. Două baze de răspuns (activ și pasiv) determină momentul deciziei și includerea acestuia în planul proiectului. Răspunsul activ înseamnă că includem muncă suplimentară în program menită să minimizeze riscurile. Acest lucru poate afecta sincronizarea altor lucrări.

Ca exemplu, putem lua în considerare un proiect de introducere pe piață a unui nou serviciu. Să presupunem că a fost identificat riscul lipsei cererii sale pe piață. Apoi, pentru a minimiza acest risc, trebuie efectuate cercetări suplimentare, iar această muncă trebuie inclusă în program. Răspunsul pasiv presupune formarea de rezerve financiare suplimentare pentru riscurile identificate. Etapele dezvoltării unui program pot fi prezentate și în secvența logică prezentată mai jos.

Secvență logică pentru elaborarea unui program

Activități de bază de planificare a proiectelor

Pentru a crea un master plan, managerul de proiect implementează o serie de iterații de planificare. Pe parcursul executării proceselor de planificare se generează documente instrumentale și finale importante, care împreună alcătuiesc masterplanul. Printre ei:

  • structura ierarhică a muncii (WBS);
  • diagrama rețelei;
  • plan de management al calitatii;
  • programul proiectului;
  • buget;
  • Organigrama;
  • registrul riscurilor;
  • Plan de comunicare;
  • planul principal al proiectului.

Model vizual al proceselor de planificare a proiectelor

Mai sus este un model al proceselor de planificare pentru o sarcină de proiect. Puteți vedea compoziția completă a proceselor în diagramă. Procesele de planificare a benzii piscinei sunt legate de aproape toate domeniile managementului de proiect. Multe dintre procesele specificate în model vor avea posibilitatea de a fi prezentate în articole separate pe site-ul nostru. În acest material ne concentrăm pe scurt pe procedurile cheie de planificare.

  1. Procesul de definire a domeniului de aplicare este efectuat pentru a clarifica domeniul de aplicare al proiectului, limitele cu o descriere a produsului acestuia. Procesul începe cu clarificarea obiectivelor evenimentului, conexiunea acestuia cu strategia companiei și luarea în considerare a abordărilor variabile ale implementării. PM trebuie să fie clar ce lucru este în afara domeniului de aplicare al proiectului și care sunt cerințele produsului.
  2. Procesul de determinare a domeniului de activitate. Bazele puse în procesul anterior sunt dezvoltate în întreaga gamă de operațiuni necesare pentru a obține succesul. Structura și compoziția lor sunt legate de obiectivul principal al proiectului. WBS este principalul instrument folosit de PM pentru a rezolva problema prezentului proces.
  3. Determinarea relațiilor de muncă. Secvența logică a lucrărilor este subiectul și scopul acestui proces. Cel mai bun instrument și rezultat al implementării procesului este un model de rețea (diagramă, grafic), construit și optimizat folosind metoda PERT și CPM.
  4. Procesul de estimare a duratei muncii. Prognoza duratei fiecărei activități incluse în WBS și modelul de rețea se realizează pe baza unei varietăți de abordări. Principalele metode sunt metode de evaluare bazate pe analogi, „de jos în sus”, de la performeri, experti și evaluare parametrică.
  5. Procesul de evaluare a nevoilor de resurse. Scopul procesului este de a determina cantitatea necesară de resurse umane, resurse de mașini și mecanisme. Resursele sunt împărțite în grupuri: regenerabile, consumabile și financiare.
  6. Procedura de elaborare a unui plan calendaristic. Procesul este efectuat pentru a determina calendarul estimat al lucrărilor individuale și al proiectului în ansamblu. Problema detalierii planului este importantă. Profunzimea elaborării sale ar trebui să fie suficientă pentru ca managerul de proiect să controleze progresul lucrărilor și finalizarea sarcinilor atribuite.
  7. Elaborarea unui plan general de proiect. Combină toate rezultatele activității de planificare a evenimentelor într-un singur document de integrare a proiectului.

În acest articol, ne-am familiarizat cu „pachetul maxim” de proceduri și documente care creează un plan de proiect. În practică, mai ales atunci când proiectul este de scară medie sau mică și este de natură obișnuită, eforturile excesive de planificare nu sunt adesea necesare. În astfel de cazuri, vă puteți limita la soluții standard de planificare și la un set incomplet de documente. În același timp, cu greu se poate face fără un documentar de bază stabilit într-un plan consolidat, iar eforturile depuse pentru dezvoltarea lui dă roade extraordinare.

Principii de planificare a proiectelor.

Structura de defalcare a muncii.

Planificarea proiectului conform parametrilor de timp.

Metode de planificare a rețelei de proiect.

Organizarea lucrărilor de planificare a proiectelor.

    Management de proiect: manual / A.G. Ivasenko, Ya.I. Nikonova, M.V. Karkavin. – Rostov n/a: Phoenix, 2009. – P.177-212.

    Mazur I.I. Management de proiect: manual. manual pentru studenții care studiază la specialitatea „Managementul organizațiilor”/I.I. Mazur [și alții]. ; editat de I.I. Mazura și V.D. Shapiro - ed. a 6-a, șters. - M.: Editura „Omega-L”, 2010. -960 p.

Esența planificării constă în stabilirea obiectivelor și modalităților de realizare a acestora pe baza formării unui set de lucrări (evenimente, acțiuni) care trebuie efectuate, utilizarea metodelor și mijloacelor de implementare a acestor lucrări, legarea resurselor necesare implementării lor. și coordonarea acțiunilor organizațiilor participante la proiect.

Activitățile de dezvoltare a planului acoperă toate etapele de creare și execuție a proiectului. Acesta începe cu participarea managerului de proiect (managerul de proiect) la dezvoltarea conceptului de proiect, continuă cu selecția deciziilor strategice pentru proiect, precum și la dezvoltarea detaliilor acestuia, inclusiv pregătirea propunerilor de contract, contractarea. , execuția lucrării și se încheie cu finalizarea proiectului.

În etapa de planificare, sunt determinați toți parametrii necesari pentru implementarea proiectului:

    durata pentru fiecare dintre elementele controlate ale proiectului,

    nevoia de resurse de muncă, materiale, tehnice și financiare,

    timpii de livrare pentru materii prime, materiale, componente și echipamente tehnologice,

    calendarul și volumul de implicare a organizațiilor de proiectare, construcție și alte organizații.

Procesele și procedurile de planificare a proiectului trebuie să asigure fezabilitatea proiectului într-un interval de timp dat la un cost minim, în limitele costurilor standard cu resurse și cu o calitate adecvată.

Într-un proiect bine organizat, un organism de management specific ar trebui să fie responsabil de implementarea fiecărui obiectiv: managerul de proiect pentru toate obiectivele (misiunea proiectului), executanții responsabili pentru obiectivele private etc. Adică, arborele obiectivelor proiectului trebuie să coincidă. cu structura unitatii organizatorice responsabila de implementarea proiectului. În acest scop, este în curs de elaborare o așa-numită matrice a responsabilităților, care determină responsabilitățile funcționale ale executanților proiectului și precizează setul de lucrări pentru implementarea cărora aceștia sunt personal responsabili.

Cu cât nivelul organului de conducere este mai înalt, cu atât este mai generalizat, agregat de indicatori, acesta ia decizii cu privire la conducerea unităților din subordine. Pe măsură ce nivelul de ierarhie crește, intervalul de timp dintre emiterea sarcinilor planificate, monitorizarea executării acestora etc. De asemenea, în intervalele dintre momentele de intervenție (emiterea sarcinilor planificate, stabilirea reperelor etc.), unitățile de nivel inferior lucrează în mod independent. indiferent de unitățile de același nivel sau adiacent. Funcționarea independentă a departamentelor trebuie să fie asigurată de anumite rezerve de resurse, care trebuie și ele planificate.

Scopul principal al planificării este de a construi un model pentru implementarea proiectului. Este necesar să se coordoneze activitățile participanților la proiect cu ajutorul acestuia, se determină ordinea în care ar trebui efectuată munca etc.

Planificarea este un set de proceduri interconectate. Prima etapă a planificării proiectului este elaborarea planurilor inițiale, care stau la baza elaborării bugetului proiectului, determinarea cerințelor de resurse, organizarea suportului de proiect, încheierea contractelor etc. Planificarea proiectului precede controlul proiectului și stă la baza aplicării acestuia. , deoarece se face o comparație între indicatorii planificați și cei reali.

Planificarea este unul dintre cele mai importante procese pentru un proiect, deoarece rezultatul implementării acestuia este de obicei un obiect, produs sau serviciu unic. Sfera și detaliul planificării sunt determinate de utilitatea informațiilor care pot fi obținute ca urmare a procesului și depind de conținutul (intenția) proiectului.

Procesul de planificare în sine nu poate fi complet algoritmizat și automatizat, deoarece conține mulți parametri nesiguri și depinde adesea de factori aleatori. Prin urmare, opțiunile de plan propuse ca urmare a planificării pot diferi dacă sunt dezvoltate de echipe diferite, ai căror specialiști au evaluări diferite ale impactului factorilor externi asupra proiectului.

LA procese de bază planificarea include:

    planificarea și documentarea domeniului proiectului;

    intocmirea devizelor, evaluarea costului resurselor necesare finalizarii proiectului;

    definirea lucrării, formarea unei liste de lucrări specifice care asigură realizarea obiectivelor proiectului;

    aranjarea (secvența) muncii, identificarea și documentarea dependențelor tehnologice și a restricțiilor de muncă;

    evaluarea duratei muncii, a costurilor cu forța de muncă și a altor resurse necesare executării lucrărilor individuale;

    calcularea graficului, analiza dependențelor tehnologice ale execuției lucrării, durata lucrărilor și cerințele de resurse;

    planificarea resurselor, determinând ce resurse (oameni, echipamente, materiale) și în ce cantități vor fi necesare pentru finalizarea lucrărilor proiectului. Stabilirea în ce interval de timp poate fi finalizată lucrarea ținând cont de resursele limitate;

    bugetarea, legând costurile estimate cu anumite tipuri de activități;

    crearea (dezvoltarea) unui plan de proiect, colectarea rezultatelor altor procese de planificare și combinarea acestora într-un document comun.

Procese de ajutor efectuate după cum este necesar. Acestea includ:

    planificarea calității, definirea standardelor de calitate adecvate unui proiect dat și găsirea modalităților de realizare a acestora;

    planificarea organizațională (proiectare), definirea, sondajul, documentarea și distribuirea rolurilor, responsabilităților și relațiilor de raportare ale proiectului;

    selectarea personalului, formarea unei echipe de proiect în toate etapele ciclului de viață al proiectului, recrutarea resurselor umane necesare incluse în proiect și lucrul în acesta;

    planificarea comunicațiilor, determinarea nevoilor de informare și comunicare ale participanților la proiect: cine are nevoie de ce informații, când și cum ar trebui să le fie furnizate;

    identificarea și evaluarea riscurilor, determinarea factorului de incertitudine și în ce măsură poate afecta progresul proiectului, determinarea scenariilor favorabile și nefavorabile pentru implementarea proiectului, documentarea riscurilor;

    planificarea aprovizionării, stabilirea ce, cum, când și cu cine să cumpere și să livreze;

    planificarea propunerilor, documentarea cerințelor de produs și identificarea potențialilor furnizori.

Determinarea nivelurilor de planificare face și obiectul planificării și se realizează pentru fiecare proiect specific, ținând cont de specificul acestuia, amploarea, geografia, calendarul etc.

Pe parcursul acestui proces se determină tipul și numărul de niveluri de planificare corespunzătoare pachetelor de lucru alocate pentru proiect, relațiile lor de fond și de timp.

Planurile (grafice, rețele) ca expresie a rezultatelor proceselor de planificare ar trebui să formeze împreună o structură piramidală care are proprietățile de agregare a informațiilor, diferențiate pe niveluri de management al conștientizării, eșalonate pe perioade de dezvoltare (pe termen scurt, mediu și lung). -termen). Nivelurile de planificare și sistemul de planuri ar trebui să fie construite folosind principii de feedback care să asigure o comparație constantă a datelor planificate cu datele reale și să aibă o mare flexibilitate, relevanță și eficiență.

Planificare este procesul de alocare și alocare a resurselor (materiale și umane) ținând cont de costul și timpul de finalizare a proiectului. Planificarea este unul dintre cele mai importante procese pentru un proiect, deoarece rezultatul implementării acestuia este de obicei un obiect, produs sau serviciu unic.

De bază functii de planificare sunt date mai jos.

Transformarea nevoilor în sarcini gestionabile. Inițial, proiectul apare sub forma unor cerințe elaborate și convenite cu clientul. Scopul planificării este de a prezenta aceste cerințe ca un set de sarcini individuale, a căror implementare poate fi controlată.

Determinarea resurselor necesare. Planurile detaliate vor determina numărul de oameni, echipamentele necesare și condițiile de funcționare care vor fi necesare pentru finalizarea proiectului.

Coordonarea lucrului in echipa pe proiect. Foarte des, un proiect este împărțit în lucrări separate care pot fi finalizate în paralel. Planurile fac posibilă coordonarea acestor activități prin definirea cine ce face și când.

Evaluarea riscurilor potențiale. Deși unele riscuri pot fi identificate în timpul formulării cerințelor, multe altele sunt descoperite după ce a avut loc planificarea detaliată. Cunoașterea existenței acestor riscuri vă va permite să le observați mai devreme (dacă se materializează) și să vă pregătiți să le abordați.

Alarmă când apar probleme. Abaterea de la plan servește ca un semnal că au apărut probleme. Planurile nu sunt o dogmă care trebuie urmată necondiționat. Pentru managerul de proiect, acestea sunt mai probabil să fie ipoteze și o bază de comparație. Dacă proiectul nu corespunde așteptărilor, planul trebuie ajustat în consecință.

grup procesele de planificare prezentat în Fig. 3.10. Aceste procese pot fi repetate și pot face parte dintr-o procedură iterativă până la obținerea unui anumit rezultat. De exemplu, dacă data inițială de finalizare a proiectului nu este acceptabilă, atunci resursele necesare, costul și, uneori, conținutul proiectului ( Grupuri de procese de management de proiect

Grupul de procese de planificare

Managementul resurselor umane de proiect

Planificare

Elaborarea unui plan de management al resurselor umane resurse tehnice

Definiție

Managementul timpului de proiect

Definiție

operațiuni

Control

integritate

Planificarea achizițiilor

Managementul costurilor de proiect^

Cost estimat

Managementul calitatii proiectelor

Elaborarea unui plan de management de proiect

Definiție

secvente

operațiuni

resurse operaționale

Planificare

calitate

durată

operațiuni

Dezvoltare

orare

Managementul riscului de proiect

Definiție

Planificare

management

risc

Efectuarea unei analize calitative de risc

Efectuarea analizei cantitative a riscului

Planificarea răspunsurilor la riscuri

Orez. RĂU. Procese de planificare

Proiectul trebuie schimbat. Rezultatul în acest caz va fi termenii conveniți, volumele, gama de resurse, bugetul și conținutul proiectului, corespunzător obiectivelor acestuia.

Planificarea este o condiție prealabilă necesară pentru îndeplinirea oricărei sarcini, chiar și a celei mai simple. Planificarea inadecvată poate duce la eșecul proiectului sau la rezultate inadecvate în mediul proiectului.

Planificarea într-o formă sau alta se realizează pe toată durata proiectului. La începutul ciclului de viață al unui proiect, se dezvoltă de obicei un plan inițial informal - o idee aproximativă despre ceea ce va trebui realizat dacă proiectul urmează să fie implementat. Decizia de selecție a proiectelor se bazează în mare măsură pe evaluările acestui plan inițial. Planificarea formală și detaliată a proiectului începe după ce a fost luată decizia de implementare.

Planificarea constă în întocmirea următoarelor planuri:

  • efectuarea muncii, inclusiv evaluarea intensității muncii și a termenelor limită;
  • gestionarea conținutului și domeniului de activitate;
  • structura organizationala;
  • managementul configurației;
  • administrare de calitate;
  • managementul riscurilor;
  • managementul achizițiilor;
  • certificarea rezultatelor de proiectare și a activităților executanților.

Definiție niveluri de planificare face si subiect de planificare si se realizeaza pentru fiecare proiect specific, tinand cont de specificul acestuia, amploarea, geografia, calendarul etc. Pe parcursul acestui proces se determină tipul și numărul de niveluri de planificare corespunzătoare pachetelor de lucru alocate pentru proiect, relațiile lor de fond și de timp.

Planurile (grafice, rețele) ca expresie a rezultatelor proceselor de planificare ar trebui să formeze în agregat o anumită structură piramidală care să aibă proprietăți de agregare a informațiilor diferențiate pe niveluri de management al conștientizării și să fie eșalonată pe perioade de dezvoltare (pe termen scurt, pe termen mediu și lung). Nivelurile de planificare și sistemul de planuri trebuie construite folosind principii de feedback, asigurând compararea constantă a datelor planificate cu datele reale, acestea trebuie să aibă o mare flexibilitate, relevanță și eficiență.

Planurile de rețea sunt consolidate datorită faptului că planul general de rețea constă din multe planuri de rețea privată. În fiecare dintre aceste planuri private, este determinată calea cea mai lungă. Aceste căi sunt apoi puse în locul părților individuale ale rețelei. Cu ajutorul unei astfel de agregări treptate, se obțin planuri de rețea pe mai multe niveluri (Fig. 3.11). De obicei, există un plan conceptual, un plan strategic pentru implementarea proiectului și planuri tactice (detaliate, operaționale).

Plan de rețea cu mai multe proiecte (pentru management superior)

Nivelul 1

Nivelul 3

Nivelul 2

Plan de rețea cu etapele cheie (etape)

Plan detaliat de rețea

Orez. 3.11.Planuri de rețea cu mai multe niveluri

Planificare conceptuală, care are ca rezultat un plan conceptual, este procesul de elaborare a documentației de bază a proiectului, cerințelor tehnice, estimărilor, graficelor detaliate, procedurilor de control și management. Planificarea conceptuală are loc la începutul ciclului de viață al proiectului.

Planificare strategica este procesul de dezvoltare a planurilor strategice, integrate, pe termen lung.

Detaliat (operativ, tactic) planificare asociat cu dezvoltarea de planuri (programe) tactice, detaliate, bazate pe structura ierarhică de lucru (WBS) pentru managementul operațional

la nivelul executorilor responsabili.

Planificați managementul conținutului. Una dintre „bolile” comune ale proiectelor software se numește „trăsătură târâtoare” atunci când un șopron pentru depozitarea uneltelor de grădină este adăugat mai întâi la cabina proiectată inițial pentru un câine iubit, iar apoi o casă de mai multe etaje pentru proprietarul său. Și încearcă să construiască toate acestea pe aceeași fundație și din aceleași materiale. Această abordare a cauzat moartea multor proiecte de dezvoltare software. Prin urmare, de îndată ce a fost posibil să se stabilească și să se convină asupra WBS - structura ierarhică a muncii, este necesar să se dezvolte planul de management al domeniului proiectului, pentru care ar trebui să:

  • identifica sursele cererilor de schimbare;
  • stabilirea unei proceduri de analiză, evaluare și aprobare/respingere a modificărilor de conținut;
  • stabilirea procedurii de documentare a modificărilor de conținut;
  • stabilirea procedurii de informare cu privire la modificările de conținut. Prima sarcină care trebuie rezolvată atunci când se analizează o solicitare

pentru modificări - identificați obiectele schimbării: cerințe, arhitectură, structuri de date, coduri sursă, scripturi de testare, documentație utilizator etc. Apoi este necesar să proiectați și să descrieți în detaliu modificările din toate obiectele identificate. În cele din urmă, ar trebui evaluate costurile pentru efectuarea acestor modificări, testarea modificărilor și impactul acestora asupra calendarului proiectului. Această muncă va necesita timp petrecut, și uneori semnificativ, de către diferiți specialiști: analiști, designeri, dezvoltatori, testeri, precum și un manager de proiect și, prin urmare, trebuie luat în considerare în plan.

Planificarea structurii organizatorice.Structura organizationala- aceasta este o distribuție agreată și aprobată a rolurilor, responsabilităților și obiectivelor participanților cheie la proiect. Trebuie să includă în mod necesar următoarele:

  • un sistem de relații de lucru între grupurile de lucru ale proiectului;
  • sistem de raportare;
  • evaluări ale progresului proiectului;
  • sistem de luare a deciziilor.

Trebuie amintit că structura organizatorică a proiectului este un organism „viu”. Începe să prindă contur în etapa de planificare și ar trebui să se schimbe pe măsură ce proiectul progresează. Instabilitatea structurii organizatorice (schimbări frecvente ale interpreților) poate deveni o problemă serioasă în managementul proiectului, deoarece există un cost de înlocuire, care este determinat de momentul în care un nou participant intră în contextul proiectului.

Planificarea managementului configurației. Unul dintre procesele importante de producție de software este managementul configurației. S-a scris mai mult de o carte despre acest domeniu de cunoaștere. Aici vom vorbi doar despre cum ar trebui să fie planificată această lucrare. Planul de management al configurației proiectului ar trebui să includă:

  • lucrează pentru a asigura un singur depozit pentru toată documentația de proiect și codul de program dezvoltat, asigurând siguranța și recuperarea informațiilor despre proiect după un eșec;
  • lucrează la configurarea stațiilor de lucru și a serverelor utilizate de membrii echipei de proiect;
  • munca necesară pentru organizarea ansamblului versiunilor intermediare ale sistemului, precum și a versiunii finale a acestuia.

Această lucrare este de obicei efectuată de un inginer de configurare. Dacă proiectul este mic, atunci acest rol poate fi suplimentar pentru unul dintre programatori sau managerul de proiect. „Răspândirea” acestei lucrări la toți participanții la proiect este, în primul rând, ineficientă. Instalarea și configurarea mediilor de dezvoltare, cum ar fi bazele de date și serverele de aplicații, necesită competențe specifice și cunoștințe despre versiuni specifice de produs. Dacă toți dezvoltatorii trebuie să învețe aceste abilități, va dura prea mult timp de lucru. În al doilea rând, „răspândirea” a muncii privind gestionarea configurației poate duce la iresponsabilitate colectivă, atunci când nimeni nu știe de ce „proiectul nu va funcționa” și cum să „retorn” la versiunea anterioară.

Managementul configurației poate deveni mult mai complex dacă echipa de proiect, în paralel cu dezvoltarea de noi funcționalități de produs, trebuie să suporte mai multe versiuni ale acestui produs care au fost instalate anterior de diferiți clienți, dar toată această muncă trebuie luată în considerare în proiect. plan.

Planificarea managementului calitatii. Un alt domeniu de bază de cunoștințe în ingineria software este asigurarea calității. Există opinii diferite cu privire la calitatea software-ului și cum să o asigurați eficient. Să ne limităm la afirmația că asigurarea calității este o lucrare destul de importantă care ar trebui planificată în avans și realizată pe parcursul întregului proiect software, și nu doar în timpul testelor de acceptare.

Atunci când planificați această lucrare, este necesar să înțelegeți că produsul proiectului nu trebuie să aibă cea mai înaltă calitate posibilă, care este de neatins într-un timp finit. Calitatea cerută a unui produs este determinată de cerințele pentru acesta. Sarcina principală a asigurării calității nu este de a căuta erori în produsul finit (controlul producției), ci de a le preveni în timpul procesului de producție.

Planul de management al calitatii ar trebui să includă următoarele lucrări:

  • verificarea obiectivă a conformității produselor software și a operațiunilor tehnologice cu standardele, procedurile și cerințele aplicabile;
  • identificarea abaterilor de calitate, identificarea cauzelor acestora, aplicarea măsurilor pentru eliminarea acestora, precum și monitorizarea implementării măsurilor luate și a eficacității acestora;
  • furnizarea conducerii superioare a informațiilor independente despre neconformitățile care nu sunt rezolvate la nivel de proiect.

Clarificarea conținutului și compoziției lucrării. Clarificarea conținutului (descompunerea) proiectului este una dintre cele mai importante componente ale disciplinei managementului de proiect. Detalierea face posibilă estimarea, de exemplu, a costului total al unui proiect prin costul total al lucrărilor sale individuale. Rezultatul detalierii conținutului proiectului este structura de defalcare a muncii(Work Breakdown Structure - WBS). În cele mai multe cazuri, această structură este ierarhică. În același timp, procesul de detaliere în sine este structura de defalcare a muncii, adică activitate pentru a crea o structură detaliată a sarcinilor de lucru sau de proiect.

Structura ierarhică a muncii(WBS) este o defalcare orientată către rezultate a muncii efectuate de echipa de proiect pentru a atinge obiectivele proiectului și rezultatele cerute. Cu ajutorul acestuia, întregul conținut al proiectului este structurat și determinat. Fiecare nivel ulterior al ierarhiei reflectă o definiție mai detaliată a elementelor proiectului. Baza dezvoltării WBS este conceptul de proiect, care definește produsele proiectului și principalele lor caracteristici. WBS se asigură că toate lucrările necesare pentru atingerea obiectivelor proiectului sunt identificate. Multe proiecte eșuează nu pentru că nu au un plan, ci pentru că planul neglijează lucrări importante, cum ar fi testarea și remedierea erorilor, precum și produsele de proiect, cum ar fi documentația utilizatorului. Prin urmare, dacă WBS este compilat corect, atunci orice lucrare care nu este inclusă în el nu poate fi considerată lucrare la proiect. WBS împarte proiectul în subproiecte, pachete de lucru și subpachete. Fiecare nivel ulterior de descompunere oferă detalii consecvente ale conținutului proiectului, ceea ce face posibilă estimarea calendarului și a sferei de lucru. WBS trebuie să includă toate produsele intermediare și finale.

Există diferite moduri de a descompune munca unui proiect. De exemplu, GOST 19.102-77 prevede abordarea cascadeiși definește următoarele etapele dezvoltării sistemului software.

  • 1) specificații tehnice;
  • 2) proiectare preliminară;
  • 3) proiectare tehnică;
  • 4) proiect de lucru;
  • 5) implementare.

Dacă respectăm acest standard, atunci aceste produse de design ar trebui să fie la primul nivel al WBS. Dacă ar fi trebuit să dezvoltăm un sistem de control automat pentru a controla un reactor nuclear sau o navă spațială cu echipaj, atunci exact asta ar fi trebuit făcut. Cu toate acestea, în dezvoltarea de software comercial, această abordare este ineficientă.

Procesul modern de dezvoltare a software-ului comercial trebuie să fie incremental. Aceasta înseamnă că nivelul superior al descompunerii proiectului ar trebui să conțină produsele proiectului, iar nivelul următor ar trebui să conțină componentele din care constau aceste produse. Componentele pot fi descompuse în continuare în „funcții” - funcțiile pe care trebuie să le implementeze.

Izolarea componentelor care alcătuiesc un produs software este un element de proiectare la nivel înalt care ar trebui realizat în faza de planificare a proiectului, fără a aștepta ca toate cerințele funcționale ale software-ului în curs de dezvoltare să fie elaborate. Componentele pot fi atât subsisteme de aplicație, cât și infrastructură sau nucleare, de exemplu, un subsistem de autentificare și securitate și o bibliotecă de componente de interfață grafică vizuală (GUI). Când elaborați un plan de lucru de bază, nu ar trebui să vă străduiți să detaliați cât mai mult lucrul WBS 3-5 niveluri sunt suficiente;

În contextul detalierii, termenii „sarcini” și „muncă” sunt adesea folosiți în mod interschimbabil. Totuși, este mai corect să spunem că sarcina determină obținerea unui rezultat intermediar, iar munca este un set de acțiuni pentru a obține aceste rezultate. Întrucât orice sarcină necesită o anumită muncă pentru a fi efectuată în conformitate cu anumite restricții, putem vorbi cu siguranță despre „cartarea” fără îndoială a sarcinilor la locul de muncă și invers. Acesta este motivul interschimbabilității termenilor în viața de zi cu zi. În același timp, înțelegerea diferențelor dintre aceste concepte vă permite să simțiți nuanțele viziunii procesului de creare a unui produs și, prin urmare, ciclul de viață al proiectelor, inclusiv proiectele de sisteme software.

În general, putem vorbi despre detaliu: „program – proiect - sarcina este operațiunea.”În fig. Figura 3.12 oferă un exemplu de astfel de detaliere (sunt afișate doar operațiunile de sarcină A).


Orez. 3.12.Un exemplu de utilizare a termenilor: program, proiect, sarcină, operațiune

Fiecare element al unei astfel de structuri este asociat cu restricții și alte caracteristici și date semnificative. Relevanța se referă la necesitatea sau utilitatea lor pentru luarea deciziilor. Profunzimea detaliilor și nivelul de aplicare a anumitor termeni depind de proiectul specific, cultura de management, standardele ciclului de viață, specificul și amploarea proiectului, precum și de alți factori unici atât pentru o anumită organizație, cât și pentru un anumit proiect.

Responsabilitatea personală trebuie stabilită pentru toate părțile proiectului (subproiecte și pachete de lucru). Pentru fiecare pachet de lucru, rezultatul de ieșire trebuie să fie clar definit. Estimările de lucru și de proiect trebuie convenite cu membrii echipei cheie, conducerea companiei performante și, dacă este necesar, cu clientul. Ca urmare a unui acord, membrii echipei își asumă obligațiile de a implementa proiectul, iar conducerea își asumă responsabilitatea de a asigura proiectul cu resursele necesare.

WBS este unul dintre principalele instrumente (mijloace) din mecanismul de management al proiectelor, cu ajutorul căruia se măsoară gradul de realizare a rezultatelor proiectului. Funcția sa cea mai importantă este de a se asigura că toți participanții la proiect înțeleg și înțeleg cum va fi realizat proiectul. Ulterior, linia de referință va servi drept ghid pentru compararea cu execuția curentă a proiectului pentru a identifica abaterile.

Estimarea costurilor proiectului. Procesul de gestionare a unui proiect software începe cu multe activități, unite printr-un nume comun Planificarea proiectului. Prima dintre aceste acțiuni este efectuarea estimării costurilor proiectului. El pune bazele altor activități de planificare a proiectelor. La evaluarea unui proiect, costul greșelilor este extrem de mare. Este foarte important să efectuați evaluarea cu un risc minim.

Principala dificultate în modelarea algoritmică a costului proiectului este dependența estimării costurilor de proprietățile și parametrii produsului finit. În stadiul incipient al proiectului, este imposibil să se determine cu exactitate aceste proprietăți și parametri. Există multe metode de estimare a costului software-ului care ar trebui să fie utilizate în paralel. Dacă rezultatele obținute sunt foarte diferite, înseamnă că pentru analiză au fost utilizate informații insuficiente sau inadecvate. Prețul produsului software adesea determinate în prealabil în scopul contractării, ceea ce duce la ajustarea ulterioară a funcționalității sistemului la cele care ar corespunde acestui preț.

faimos modelul de estimare a costurilor proiectului B. Boema SOSOMO ia în considerare caracteristicile de proiectare, proprietățile software-ului creat, hardware-ul și capacitățile personalului. Acest model include și instrumente pentru determinarea duratei de lucru la un proiect. Timpul necesar pentru finalizarea lucrării nu depinde direct de numărul de specialiști angajați pentru proiect. Adăugarea mai multor persoane la un proiect care este în întârziere poate întârzia și mai mult timpul de finalizare.

Modelele algoritmice de costuri ale proiectelor sunt utilizate pentru gestionarea proiectelor software, deoarece suportă analiza cantitativă a parametrilor. Aceste modele vă permit să evaluați contribuția fiecărui parametru individual la costul total al proiectului și să faceți o comparație obiectivă (deși nu imună la erori) a acestor parametri.

Estimarea costului proiectului- una dintre cele mai importante lucrări ale proiectului, care se determină pe baza costului părților individuale ale proiectului, a condițiilor de executare a lucrării, a personalului efectiv al executanților, a metodelor și instrumentelor utilizate. Costul proiectului include și costurile de derulare a proiectului, adică. computere, software, spațiu, mobilier, telefoane, modemuri și multe altele. În plus, uneori trebuie luate în considerare costurile suplimentare (de exemplu, securitatea). Costurile suplimentare pentru proiect includ achiziționarea unui sistem de testare, a unui sistem CABE etc. Evaluarea principală în proiect este estimarea costurilor pentru proiect, exprimat în zile-om de muncă ale artiștilor interpreți la proiect. Această evaluare este efectuată într-un stadiu incipient de management și planificare.

Costul total al proiectului este determinat de specialiști experimentați cu o eroare de până la 10%. Estimarea costurilor poate fi de sus în jos, de jos în sus sau bazată pe costul unui design fabricat anterior. Experții fac evaluări pesimiste, optimiste și realiste intervievând toți membrii grupului de lucru și ajustând fiecare evaluare pentru a obține cea mai plauzibilă. În unele grupuri de lucru, evaluările pesimiste și optimiste pot fi foarte diferite.

Metode algoritmice de estimare a costurilor proiectului afișați relațiile dintre costurile proiectului și factorii care le influențează.

Există diverse abordări empirice pentru estimarea costului unui proiect, de exemplu, costul unui proiect este propus să fie determinat folosind formula

PREȚ = (a + b?)t(X),

unde 5 este o anumită estimare a dimensiunii sistemului; a, b, c - constante empirice; X - vector al factorilor de cost cu dimensiune vineri - multiplicator de reglementare bazat pe factori de cost.

O estimare mai simplificată obținută experimental este exprimată după cum urmează:

COST = 5,255 0,91.

Aceste estimări au fost derivate dintr-o analiză a proiectelor în care programele variau în dimensiune de la 4.000 la 467.000 de linii de cod și au fost scrise în 28 de limbaje de programare diferite pe 66 de computere. De la 12 la 11.758 de luni-om au fost cheltuite pentru dezvoltare. Sunt cunoscute și alte tehnici empirice de modelare.

Primele modele au folosit indicatori de preț, au luat în considerare personalul și proprietățile proiectului, produs și mediu. Modelele includ o evaluare a trei etape ale managementului de proiect. În prima etapă, se construiește un prototip pentru sarcini cu risc ridicat (interfață utilizator, software, sistem de interacțiune, implementare etc.) și se estimează costurile (de exemplu, numărul de tabele din baza de date, ecrane și formulare de raportare etc. .). În a doua etapă, sunt evaluate costurile de proiectare și implementare a punctelor funcționale ale proiectului reflectate în cerințele proiectului. În a treia etapă, estimarea se referă la proiectarea finalizată, când dimensiunea sistemului poate fi determinată în termeni de linii de program finalizate și alți factori.

Modelul de bază pentru estimarea experimentală a costurilor proiectului astăzi este următoarea ecuație:

COST = bS c m(X),

Unde bS c - estimare primară care este ajustată folosind un vector de cost t(X)și contabilizarea numărului de obiecte vechi și noi; Cu- un parametru care variază de la zero la unu pentru prima etapă a proiectului și de la 1,01 la 1,26 pentru etapele rămase.

Cu o abordare formalizată, evaluarea proiectului se bazează pe utilizarea parametrilor LOC și FP.

Modelul de cost constructiv(SOSOMO - Modelul de cost constructiv), propus de B. Boehm, combină cele mai cunoscute tehnici de evaluare formalizată a proiectelor - estimări LOC(LOC - Lines of Code), care se bazează pe numărul de linii de cod de program. În procesul de aplicare a acestui model se formează estimări preliminare care fac posibilă prezentarea clientului cu cerințe corecte privind costul și costurile dezvoltării software-ului și, de asemenea, asigură posibilitatea întocmirii unui plan software.

Metrici FP orientate pe funcțieÎn loc să calculeze scorurile LOC, ei măsoară indirect produsul software. Nu dimensiunea este luată în considerare, ci funcționalitatea sau utilitatea produsului. Autorul acestei metrici este A. Albrecht. Determinarea dimensiunii funcționale constă din mai mulți pași și începe cu identificarea funcțiilor pe care ar trebui să le aibă aplicația. International Function Point Users Group (IFPUG) a publicat criterii după care sunt determinate funcțiile aplicației. La calcularea metricii FP se folosesc cinci caracteristici informaționale: numărul de intrări externe; numărul de ieșiri externe (ieșirile înseamnă rapoarte, ecrane, imprimări, mesaje de eroare); numărul de solicitări externe; numărul de fișiere logice interne; numărul de fișiere de interfață externă.

După colectarea tuturor informațiilor necesare, treceți la calcularea valorilor - a determina numărul de indicatori de funcție FP (Function Points) conform unei anumite formule, în care valorile coeficienților de ajustare a complexității de intrare (fiecare coeficient poate lua următoarele valori: 0 - fără influență; 1 - aleatoriu; 2 - mic; 3 - mediu; 4 - important 5 - principal) sunt selectate empiric în ca urmare a răspunsurilor la 14 întrebări care caracterizează parametrii de sistem ai aplicației.

Metoda constă în măsurarea uniformă a tuturor capacităților aplicației pentru orice proiect și exprimarea dimensiunii aplicației ca un singur număr, care poate fi apoi folosit pentru a estima numărul de linii de cod, costul și timpul proiectului. Pe baza ei se formează metrici ale productivității, calității etc.

Avantaj metrica orientată pe funcție este că acestea nu depind de limbajul de programare și sunt ușor de calculat în orice etapă a proiectului.

Defecte metrici orientate pe funcție - rezultatele se bazează pe date subiective, mai degrabă decât pe măsurători directe; În plus, trebuie să ai anumite abilități pentru a aplica această metodă cu acuratețe și consecvență.

Folosind tabele standard, estimările FP pot fi ușor convertite în estimări LOC, de ex. Din dimensiunea funcțională, calculați numărul de linii de cod. Cu toate acestea, rezultatele conversiei depind de limbajul de programare utilizat pentru implementarea software-ului (de exemplu, în Java, o unitate de dimensiune funcțională este egală cu 53 de linii de cod sursă). La rândul său, numărul de linii de cod vă permite să determinați intensitatea totală a forței de muncă, exprimată în persoană-luni, și intervalul de timp al proiectului.

Atunci când se efectuează o evaluare, există două utilizări posibile ale datelor LOC și FP: ca variabile de estimare care determină dimensiunea fiecărui element de produs sau ca metrici colectate în timpul lucrului la proiectele anterioare și incluse în baza de metrică a companiei.

Exemplu 3.1. Să luăm în considerare procedura de realizare a procedurii de evaluare a muncii pe baza metricii ShS.

Etapa 1. Zona de scop a produsului proiectat este împărțită într-un număr de funcții/i,/2,/3, fiecare dintre acestea putând fi

evalua individual

Etapa 2. Pentru fiecare funcție/programator generează cel mai bun LOC n, cel mai rău YUS X si probabil YUS V evaluări. În procesul de formare a estimărilor, sunt utilizate date experimentale din baza metrică sau idei intuitive ale planificatorului. Gama de estimări posibile corespunde gradului de incertitudine furnizat.

Etapa 3. Pentru fiecare functie f t se determină valoarea așteptată a evaluării:

YUS I + YUS X + 4 BOC^ cooler = 6"

da.

Etapa 4. Valoarea performanței AL a dezvoltării funcției este calculată în conformitate cu una dintre cele trei reguli.

Regula L. Pentru toate funcțiile, se ia aceeași valoare, egală cu performanța medie a PR avg, luată din baza metrică, i.e.

PR, = PR avg; / = 1, 2, ..., P.

Regula B. Pentru funcția i-a, o valoare personalizată a performanței este calculată pe baza valorii medii de performanță:

da sr

MS cool

Unde YUS miercuri - scorul mediu LOC luat de la baza metrică (corespunde productivității medii).

Regula B. Pentru funcția i-a, valoarea performanței reglabile este calculată folosind analogul selectat (luat din baza metrică):

BOSdnI

Doamna Ozhi

Utilizarea regulii A în etapele ulterioare asigură o precizie minimă cu simplitate maximă a calculelor. Regula B vă permite să obțineți o precizie maximă cu o complexitate maximă de calcul.

Etapă 5. Costul total estimat (persoană-lună) pentru proiect se calculează dacă se utilizează regula A:

dacă se utilizează regula B sau C:

b1у ^ozh/

Etapa 6. Estimarea totală a costului proiectului este calculată dacă se utilizează regula A sau B:

COST = UDST avg yuS 0Zh/ ;

dacă se folosește regula B:

COST = UDST an/ ^YUS 0Zh/ ,

unde UDST avg este o valoare a costului mediu al unei linii de cod de program; UDST an, - metrica costului unei linii de analog (ambele metrici sunt luate din baza metricii).

Elaborarea unui program de proiect. După determinarea intensității forței de muncă a lucrării, este necesar să se determine programul de implementare a acestora și intervalul de timp general pentru proiect, de exemplu. întocmește un program de lucru pentru proiect Program de bază reprezintă un grafic aprobat cu faze de timp specificate ale proiectului, repere și elemente ale structurii ierarhice de lucru.

Programul de bază este în majoritatea cazurilor un element al contractului cu clientul. Puncte de control (repere) servesc drept puncte pentru analizarea stării proiectului și luarea deciziilor în formatul „§o sau po1 §o”, prin urmare ar trebui să demonstreze în mod vizibil stadiul proiectului. Există anumite cerințe pentru selectarea și formarea punctelor de control, de exemplu, punctul de control „Proiectarea este finalizată” nu este informativ metoda de livrare secvențială este considerată o abordare mai eficientă: punctul de control menționat mai sus este formulat sub forma „; Testarea cerințelor 1, 3, 5 și 7 este finalizată.”

Dacă lucrările nu au legătură între ele, atunci oricare dintre ele poate fi începută și finalizată atunci când ne este convenabil; toate lucrările pot fi realizate în paralel, caz în care durata minimă a proiectului este egală cu durata celei mai lungi lucrări. Cu toate acestea, în practică, există de obicei dependențe între joburi care pot fi „grele”, de exemplu „analiza - proiectare - codificare - testare - documentare” a unei anumite funcții, sau „soft”, care poate fi revizuită sau atenuată, de exemplu , executarea secvențială a sarcinilor de către un anumit executant poate fi reprogramată către un alt contractant și, în loc să dezvolte software de bază, care trebuie să precedă dezvoltarea software-ului de aplicație, puteți crea „stub-uri” care emulează activitatea acestuia.

Elaborarea unui plan de lucru cu termene limită pentru implementarea acestora poate fi realizată folosind metoda drumului critic CPM sau metoda de analiză și evaluare a programelor PERT. Planul proiectului este prezentat în termeni de etape: „Planificare”, „Proiectare”, „Codificare”, „Testare” și „Întreținere”. Planificarea se referă la determinarea specificațiilor, bugetului și programului, precum și dezvoltarea planului general al proiectului.

ÎN metoda calea critică a proiectului(Critical cale) se folosește cel mai lung lanț de lucru din proiect. Creșterea duratei oricărei lucrări din acest lanț duce la o creștere a duratei întregului proiect. Există întotdeauna cel puțin o cale critică într-un proiect, dar pot fi mai multe. Calea critică se poate modifica în timpul execuției proiectului.

Atunci când execută un proiect, managerul trebuie să acorde în primul rând atenție executării sarcinilor de-a lungul căii critice și să monitorizeze apariția altor căi critice. Există o recomandare practică: pe calea critică ar trebui să se lucreze cu conexiuni non-rigide, care pot fi oricând reprogramate dacă există amenințarea de a lipsi termenele limită. Programul de lucru este întocmit conform schemei prezentate în fig. 3.13.


Programul de cerințe

la proiect

Orez. 3.13.Pași pentru programarea lucrărilor la un proiect

Când planificați pentru metoda de analiza si evaluare a programelor Un eveniment sau o dată PERT din plan este o anumită piatră de hotar (punct de control) de-a lungul traseului lucrărilor individuale ale proiectului și este utilizat pentru a afișa/marca starea de finalizare a anumitor lucrări. În contextul unui proiect, managerii folosesc reperele pentru a identifica rezultate intermediare importante care trebuie atinse în timpul proiectului.

Secvența de etape definite de manager este adesea numită plan de reper (după evenimente). Definirea unui plan pentru atingerea reperelor relevante creează un program bazat pe repere.

În etapa de planificare, se pot utiliza, de asemenea, o defalcare a rețelei de lucru și o diagramă Gantt.

Defalcarea rețelei de lucru(SPP) este o structură ierarhică pentru descompunerea sarcinilor de proiect în subsarcini. La nivelul inferior există lucrări detaliate în elemente de activitate în modelul de rețea al sistemului de sisteme de lucru.

Modelul de rețea vă permite să împărțiți munca în componente și subcomponente principale, să determinați domeniile de activitate care vizează atingerea obiectivelor complexe, să distribuiți pe cei responsabili pentru implementarea lucrărilor individuale pe proiect și să completați raportarea care rezumă informațiile despre rezultatele proiectului.

Planul de lucru trebuie să reflecte principalele etape ale lucrării și starea necesară a lucrului în fiecare etapă, împărțirea fiecărei lucrări în sarcini separate, precum și conexiunile dintre lucrări, intervalele de timp pentru finalizarea fiecărei activități și timpii de începere și de finalizare a lucrărilor. muncă. Planul de lucru include diferite tipuri de demonstrații ale funcțiilor proiectului, subsistemelor, fiabilității, echipamentelor de protecție etc. Documentele planului includ și un set de manuale și tehnici pentru efectuarea operațiunilor specificate, menținerea conexiunilor sistemului cu alte subsisteme etc.

Planul de lucru sub forma unui grafic WBS conține faze (etape), pași și activități, inclusiv activitățile inițiale și finale ale procesului (Fig. 3.14).

Fază Și

Pasul 1 Pasul 2

Orez. 3.14.Graficul planului de proiect pas cu pas

O altă formă de reprezentare vizuală a planului de lucru ar putea fi diagrama rețelei, specificat sub formă de grafic, la vârfurile cărora se află elementele de lucru, iar pe arce - numărul de zile (săptămâni) necesare pentru a le finaliza (Fig. 3.15). Aceste semne sunt folosite pentru a seta timpul de execuție a procesului. Arc părăsind inițiala


Orez. 3.15.

vârf și intrarea în vârful final, corespunde marcajului de timp „zero”.

Graficul poate conține trasee ciclice. Graficul este folosit pentru a analiza căile critice, de ex. stabiliți durata fiecărui proces.

Elaborarea unui program constă în determinarea punctului de pornire (un eveniment sau un set de evenimente care au avut loc înainte de începerea unei etape a procesului și pentru care este descris un set de condiții, inclusiv începutul procesului), durata (intervalul de timp în care procesul trebuie să-și finalizeze cu succes execuția), termenul limită (data la care procesul își finalizează total sau parțial execuția) și punctul final al procesului (punctul de control la care clientul verifică calitatea rezultatelor procesului obținut).

Cel mai clar mod în care poate fi prezentat un program de bază este Diagrama Gantt- o diagramă liniară, în care sarcinile proiectului sunt reprezentate prin perioade de timp, inclusiv datele de început și de încheiere pentru implementarea lor, ținând cont de eventualele întârzieri. În această diagramă, activitățile planificate (elementele structurii de defalcare a activității) sunt listate în partea stângă, datele sunt afișate în partea de sus, iar duratele activității sunt afișate sub formă de bare orizontale de la data de începere a unei anumite activități până la data finalizării acesteia (Figura 3.16).

Plan de proiect

b Elvest K., Goricheva R., Ivannikova O., Plotnikova O.

Specificatiile necesare

2.1. Lista principală de cerințe

Goricheva R.

2.2. Modele de cerințe

Plotnikova O.

2.3. Arhitectură de sistem de nivel înalt

către Sorokina O., Elvest K.

2.4. Criterii de certificare a sistemului

Ivannikova O.

2.5. Model de bază de date mitologică

Schetchikova A.

2.6. Glosar

Goricheva R., Plotnikova O.

Documentatie de proiectare

3.1. Proiect de arhitectura

N Elvest K.

3.2. Proiect de interfață cu utilizatorul

| Schetchikova A., Plotnikova O.

3.3. Proiectarea subsistemului

Eu Sorokina O.

3.4. Modelul bazei de date

N Ivannikova O.

3.5. Planul de testare

b Goricheva R.

Document de implementare

4.1. Prezentare generală a implementării

Schetchikova A., Soroki

sha O., Iva

4.2. Manualul utilizatorului

Elvest K., Goricheva

Document de execuție a testului

5.1. Testarea cutiei albe

N Schetchikova A.,

Sorokina

5.2. Testarea integrării

1^ Elvest K

Un tâmplar

5.3. Testarea certificării

Cheva R., II

Finalizarea si livrarea proiectului

Tejghea

Orez. 3.16. Diagrama Gantt

Grupul de procese de execuție

Grupuri de procese de management de proiect

Managementul calitatii proiectelor

Securitate

calitate

Software-ul modern de management al proiectelor oferă vizualizarea structurii graficului proiectului și a proceselor de lucru, de exemplu, sistemul de management al proiectelor larg cunoscut și destul de des folosit în practică. Acest lucru permite dezvoltatorului sau managerului de proiect să vadă cum sunt efectuate diferite activități - secvențial sau în paralel și dacă se află pe calea critică.

Planificarea proiectelor este o parte a managementului de proiect care implică utilizarea programelor, cum ar fi diagrama Gantt, pentru a planifica munca și apoi a raporta progresul într-un mediu de proiect.

Inițial, sfera proiectului este definită, dar nu sunt definite metodele adecvate de finalizare a proiectului. După acest pas, unitățile de lucru necesare pentru finalizarea lucrării ar trebui listate și grupate într-o structură de defalcare a lucrărilor (WBS), ținând cont de durata diferitelor sarcini. Planificarea proiectelor este adesea folosită pentru a organiza diferite zone ale unui proiect, inclusiv planuri de proiect, sarcini de lucru și gestionarea echipelor și a oamenilor. Dependențele logice dintre sarcini sunt determinate folosind o diagramă activă în rețea, care permite determinarea căii critice.

Planificarea proiectului este incertă; trebuie făcută înainte ca proiectul să înceapă efectiv. Prin urmare, duratele sarcinilor sunt adesea estimate folosind o medie ponderată a estimărilor optimiste, normale și pesimiste. Acest lucru adaugă „tampon” în planificare pentru a putea anticipa întârzierile (cum ar fi aprobările îndelungate) în implementarea proiectului. Timpul dintr-un program poate fi calculat folosind software-ul de management al proiectelor. Resursele și costurile necesare pentru fiecare activitate pot fi estimate, dând costul total al proiectului. În această etapă, graficul proiectului poate fi optimizat pentru a realiza echilibrul adecvat între utilizarea resurselor și durata proiectului, în concordanță cu obiectivele proiectului. Odată ce un program de proiect este creat și aprobat, acesta devine programul de bază (sau țintă). Progresul integrat al proiectului va fi măsurat în raport cu un program de referință pe toată durata proiectului. Analiza progresului în raport cu un program de referință se numește metoda valorii câștigate.

Intrările în etapa de planificare a proiectului sunt carta de proiect și propunerile de concept. Rezultatele etapei de planificare a proiectului includ cerințele proiectului, calendarul proiectului și planul de management al proiectului.

Planificarea proiectelor se poate face manual, dar pachetele software de management de proiect sunt adesea folosite. Astfel de complexe includ profesionalul Oracle Primavera și MS Project, mai obișnuit.

În domeniul managementului de proiect, un program de proiect este o listă de repere ale proiectului, sarcini și livrabile, de obicei cu o dată estimată de început și de sfârșit. Aceste elemente sunt adesea estimate în raport cu alte informații incluse în programul proiectului, cum ar fi alocarea resurselor, bugetul, duratele sarcinilor, relațiile, dependențele și evenimentele programate. Un program de proiect este utilizat în mod obișnuit în planificarea și gestionarea unui portofoliu de proiecte. Elementele programului pot fi strâns legate de structura de defalcare a lucrărilor (WBS) prin evenimente cheie, declarație de lucru sau date contractuale.

Caracteristicile Programelor de Proiect

În multe industrii, cum ar fi inginerie și construcții, dezvoltarea și menținerea unui program de proiect este responsabilitatea unui planificator intern sau a unei echipe de planificatori, în funcție de dimensiunea proiectului. Metodele de planificare sunt bine dezvoltate și aplicate în mod constant în toate industriile.

Trebuie remarcat faptul că managementul proiectelor nu se limitează la industrie; o persoană obișnuită poate folosi această metodă pentru a-și organiza propria viață. Unele programe de management de proiect, șabloane, diagrame și exemple, îi vor ajuta pe utilizatori să-și creeze programul.

Metode de elaborare a graficelor de proiect

Înainte de a crea un program, trebuie să dezvoltați o structură de defalcare a muncii (WBS), să estimați costurile pentru fiecare sarcină și să determinați o listă de resurse. Dacă aceste componente ale programului nu sunt disponibile, ele pot fi create folosind metode de estimare bazate pe consens, cum ar fi metoda Delphi. Motivul pentru aceasta este că programul în sine este o estimare: fiecare zi din program este estimată și, cu excepția cazului în care acele date se bazează pe experiența reală a oamenilor care urmează să facă munca, atunci programul nu va fi exact.

Pentru ca un program de proiect să fie realist, trebuie îndeplinite următoarele criterii:

  • Programul trebuie să fie actualizat (actualizat) în mod constant (de preferință săptămânal).
  • Valoarea EAS (scorul la finalizare) trebuie să fie egală cu valoarea de bază.
  • Volumul de lucru trebuie distribuit corect între membrii echipei (ținând cont de weekend-uri).

INTRODUCERE

Managementul de proiect se referă la elaborarea unui plan și urmărirea progresului lucrărilor la acesta. În consecință, cu cât planul de proiect este mai bun, cu atât este mai precis întocmit, cu atât este mai ușor să efectuați apoi lucrările de proiectare și să finalizați cu succes proiectul.

Pentru a planifica bine, trebuie, în primul rând, să ai o idee bună despre ce este un proiect și din ce elemente constă planul său.

Activitatea oricărei organizații este de a efectua operațiuni și proiecte. Ambele au multe în comun, de exemplu, sunt executate de oameni, pentru care sunt alocate resurse limitate.

Principala diferență dintre operațiuni și proiecte este că operațiunile sunt continue și repetitive, în timp ce proiectele sunt temporare și unice. Pe baza acestui fapt, un proiect este definit ca un efort temporar întreprins pentru a crea un produs sau serviciu unic. „Temporar” înseamnă că fiecare proiect are o anumită dată de început și de sfârșit. Când vorbim despre un produs sau serviciu unic, ne referim la faptul că este semnificativ diferit de produse sau servicii similare.

Unicitatea fiecărui proiect creează dificultăți în planificarea acestuia, deoarece este adesea dificil de prezis cum vor fi de fapt atinse rezultatele. Prin urmare, rezultatul activității proiectului nu este doar un produs sau serviciu, ci și lecții învățate, adică experiență care este folosită în viitor la planificarea și executarea proiectelor ulterioare.

PLANIFICAREA PROIECTULUI

Etapa de planificare este una dintre cele mai importante. În această etapă se stabilesc sarcinile, bugetul și intervalul de timp al proiectului. Destul de des, planificarea este înțeleasă doar ca planificarea muncii, pierderea din vedere a managementului resurselor, bugetare etc.

O tehnică completă de planificare include următorii pași:

  • 1) Definirea obiectivelor proiectului și descrierea acestora. Destul de des, proiectele încep fără un obiectiv clar.
  • 2) Determinarea etapelor tehnologice. Pentru proiect trebuie selectată o tehnologie de implementare, care determină etapele dezvoltării proiectului. Una dintre erorile tipice de planificare este discrepanța dintre plan și ciclul tehnologic.
  • 3) Pentru etapele tehnologice, este necesar să se determine o listă de sarcini, să se indice relațiile (secvența) și durata prevăzută (în funcție de resursele alocate).
  • 4) Este necesar să se convină asupra resurselor alocate proiectului. Trebuie remarcat faptul că toate resursele companiei trebuie distribuite central. Destul de des, apare o eroare de planificare din cauza faptului că unele resurse limitate sunt utilizate simultan în două proiecte diferite în același timp.
  • 5) Dacă stabiliți prețurile pentru resurse, bugetul poate fi obținut și automat. Una dintre greșelile tipice este că bugetul este alocat fără a acorda atenție costului proiectat al proiectului.
  • 6) Misiunea scrisă, bugetul și programul de lucru formează documentul oficial „Planul de proiect”. Destul de des, înainte de începerea unui proiect, unele dintre aceste documente lipsesc, consecințele acestui lucru vor fi discutate mai jos.

Astfel, pentru succesul planificării proiectelor, o serie de factori sunt importanți și trebuie luați în considerare:

  • · clasa de sarcini de rezolvat, numărul de copii ale produsului finit, tipul de lucru (dezvoltare, dezvoltare, suport);
  • · selectarea unui plan de lucru (modelul ciclului de viață) ținând cont de complexitatea proiectului și de capacitățile echipei de dezvoltare;
  • · experiență în domeniu și instrumente de automatizare a dezvoltării;
  • · dotarea dezvoltatorilor cu instrumente de automatizare și baza hardware și software;
  • · nivelul cerințelor clienților privind calendarul și calitatea muncii.

Într-un proiect bine organizat, un organism de management specific ar trebui să fie responsabil de implementarea fiecărui obiectiv: managerul de proiect, pentru toate obiectivele (misiunea proiectului), executanții responsabili pentru obiectivele private etc. Adică, arborele obiectivelor proiectului trebuie să fie coincide cu structura unitatii organizatorice responsabila de implementarea proiectului. În acest scop, este în curs de dezvoltare un așa-numit patrice de responsabilitate, care definește responsabilitățile funcționale ale executanților proiectului și precizează setul de lucrări de implementare a cărora aceștia sunt personal responsabili.

Scopul principal al planificarii este de a construi un model pentru implementarea proiectului.

Greșeli comune de planificare

Planificare folosind obiective greșite. Orice proiect în conținutul său este destinat să rezolve o problemă, să satisfacă o nevoie specifică etc. În funcție de aceasta, se formulează anumite obiective specifice. Dacă problema este neclară și nu este clar formulată, atunci puteți întâlni o greșeală comună atunci când se ia decizia corectă, dar nu se știe exact despre ce problemă anume este vorba.

Pentru a evita o astfel de situație, este necesar să se afle baza reală a lucrării: se înregistrează - de preferință documentată - o descriere a problemelor și nevoilor care trebuie rezolvate la finalizarea proiectului; stabiliți modul în care soluția la probleme specifice este reflectată în descrierea scopurilor și obiectivelor proiectului. Abia după aceasta puteți începe planificarea.

Planificare bazată pe date incomplete. O situație similară este tipică atunci când este necesară planificarea lucrărilor, al cărei început și, eventual, chiar faptul căreia depinde de rezultatele testelor de testare sau de succesele/eșecurile din fazele anterioare.

O situație similară apare adesea în proiectele de dezvoltare și adaptare a sistemelor informaționale. Clientul are o dorință irezistibilă de a primi cât mai repede un instrument finit. Cu toate acestea, are doar o idee vagă despre capacitățile software-ului pe care l-a ales și despre ceea ce vrea să automatizeze. Pe de altă parte, furnizorii de software cunosc foarte puține despre procesele de management efective (funcționale, informaționale, structuri organizaționale) din organizația clientului. Și numai atunci când încep să implementeze proiectul, începe procesul de informare și instruire reciprocă. Clarificarea afirmației duce la o creștere semnificativă, uneori de mai multe ori, a volumului de muncă și la o schimbare a scopurilor și compoziției acesteia.

Planificarea se realizează cu implicarea doar a planificatorilor. O astfel de organizare de planificare poate duce la pierderi semnificative din cauza lipsei de luare în considerare a factorilor importanți. De regulă, detaliile sau circumstanțele aparent nesemnificative sunt uitate, nerespectarea cărora, totuși, poate duce la pierderi colosale. Prin urmare, în planificare ar trebui să fie implicați și cei responsabili pentru lucrări specifice de proiect, cei responsabili pentru finanțarea proiectelor, pentru provizii etc. Ca să nu mai vorbim de aspectele psihologice ale implementării planului, la elaborarea cărora nu au participat anumiți interpreți.

Planificare fără a ține cont de experiența anterioară. Chiar și cu cele mai bune estimări, fără utilizarea experienței anterioare în implementarea unor proiecte similare, pot fi comise erori grave de planificare.

Planificarea resurselor fără a ține cont de disponibilitatea acestora. Aceasta se referă, în primul rând, la resursele de muncă cu anumite calificări și capacitatea de a ajunge la un moment dat într-un loc dat pentru a efectua lucrări la proiect. O altă problemă este dacă același grup de specialiști este planificat în mai multe proiecte care se desfășoară simultan.

Planificare fără a ține cont de motivație. De regulă, performanții din departamentele funcționale care au propriile lor sunt atrași să lucreze la proiecte. Managementul, propriile obiective și sarcini specifice și, desigur, propria lor formă de remunerare, care de obicei nu au nicio legătură cu scopurile și obiectivele proiectului. Prin urmare, executanții nu simt responsabilitatea și importanța activității proiectului fără stimulente adecvate pentru rezultatele activităților lor. Iar managerul de proiect nu este dotat cu drepturi suficiente pentru a stimula interpreții și nu poate forma un buget de stimulare financiară pe baza rezultatelor proiectului.

Planificare cu detalii excesive. Când un proiect este planificat prea detaliat , problemele apar la analizarea, planificarea și monitorizarea stării sale - de exemplu, ce este finalizat și care este întârzierea. Mai mult, este dificil să gestionați eficient un număr mare de resurse, să determinați întârzieri, să estimați costurile și să dezvoltați Programe realiste acceptabile pentru scopuri de management. Detalierea excesivă în luarea în considerare a factorilor duce la necesitatea rezolvării unui număr mare de conflicte, la schimbări frecvente, la necesitatea unei coordonări constante cu alte proiecte care se desfășoară în același timp. Cu toate acestea, mărirea excesivă poate duce și la probleme cu pierderea controlabilității. Este nevoie de un mijloc de aur atunci când proiectul planifică doar acei parametri care pot și ar trebui controlați.

De ce aveți nevoie pentru a evita greșelile de planificare (câteva sfaturi):

  • · pentru proiect trebuie formulată o listă de probleme de rezolvat;
  • · scopul principal al proiectului (misiunea) trebuie adus în atenția tuturor participanților;
  • · trebuie identificate riscurile și, dacă este posibil, excluse accidentele;
  • · este necesar să se asigure că strategia proiectului poate fi implementată și satisface constrângerile de buget, timp și sfera de aplicare (a fost efectuată o analiză de fezabilitate PCTS: P - Performanță, C - Cost, T - Timp, S - Domeniul de aplicare. Costurile sunt un funcția nivelului de execuție P, timpul T și conținutul, domeniul de activitate S);
  • · prezența rezultatelor pozitive ale analizei „pro și contra” implementării proiectului (a fost efectuată o analiză de forță-câmp, care constă într-o descriere și evaluare cantitativă a factorilor care pot facilita și împiedica implementarea proiectului );
  • · rezultatul final trebuie să fie clar pentru toți membrii echipei de proiect;
  • · indicatorii pentru evaluarea rezultatelor activităților proiectului ar trebui să evalueze starea de fapt cu acuratețea necesară. Este recomandabil să se elaboreze scale interne de evaluare a performanței în funcție de tipul de muncă.

Definirea obiectivelor proiectului

Definirea obiectivelor mai întâi înseamnă că proiectul trebuie să înceapă cu o declarație de scop. În acest caz, obiectivul trebuie înregistrat în scris sub formă de indicatori măsurabili.

Etapa formulării problemei, această etapă se desfășoară în baza unui acord de consultanță, adică. plata etapei este bazată pe timp. Din cauza incertitudinii sarcinii, este imposibil să-i planificați costul în avans. Costul scenei este aproximativ egal cu 10% din costul tuturor lucrărilor.

Produsul principal al etapei este documentul „Declarație de problemă” (Viziunea produsului).

Acest document ar trebui să definească scopul proiectului și să includă o listă de cerințe cheie fără explicații detaliate. Un criteriu important: în ciuda lipsei unei descrieri detaliate, lista trebuie să fie susceptibilă de evaluare statistică a intensității muncii cu o abatere standard (risc) într-un interval acceptabil.

Pe baza „Declarației de problemă”, se solicită întocmirea unui document „Justificare economică”.

Acest document trebuie să conțină o evaluare statistică a intensității muncii (costului) muncii. Pe de altă parte, trebuie făcută o analiză a efectului economic al implementării.

Analiza utilizează statistici privind intensitatea muncii (eficiența) unor proiecte similare. În absența acestor statistici, erorile în estimări sunt inevitabile, de un ordin de mărime, în acest caz, ar trebui să încercați să obțineți statistici pe baza rezultatelor dezvoltării/demonstrării prototipurilor;

Evaluarea riscului trebuie exprimată sub forma unui posibil exces de intensitate a muncii (evaluare pesimistă). Din această evaluare ar trebui să se procedeze atunci când se determină intensitatea totală a muncii (prețul) a produsului.

Ca urmare, avem o sarcină vag formulată în „Declarația problemei” și o estimare a costului în „Justificarea economică”. Riscurile generate de cerințe neclare trebuie acoperite printr-o evaluare pesimistă. Condiție pentru parcurgerea etapei: semnarea de către părți a „Declarației de problemă” și „Justificarea economică”.

Gestionarea și planificarea resurselor

resurse de planificare a proiectelor de management

Managementul resurselor este unul dintre principalele subsisteme ale managementului de proiect. Include procesele de planificare, cumpărare, furnizare, distribuție, contabilitate și control al resurselor, de obicei forța de muncă și logistica. Sarcina managementului resurselor este de a asigura utilizarea lor optimă pentru atingerea scopului final - formarea unui rezultat al proiectului cu indicatori planificați.

Resursele materiale și tehnice sunt materiile prime, materialele, structurile, componentele, resursele energetice, resursele tehnologice etc.

Resursele de muncă sunt cele care lucrează direct cu resurse materiale și tehnice.

Managementul resurselor materiale ale proiectului începe, în principal, în faza de pre-investire în timpul elaborării unui studiu de fezabilitate în faza de planificare, se elaborează cerințele de resurse și posibilitatea de a le furniza; Practica arată că în orice moment resursele sunt limitate și, prin urmare, principalele sarcini ale managementului resurselor sunt:

  • 1. Planificarea optimă a resurselor
  • 2. Managementul logisticii, inclusiv:
    • · managementul achizițiilor de resurse;
    • · managementul alocării resurselor.

Conceptul de resurse este interconectat cu conceptul de „muncă”, deoarece resursele nu se referă la proiect în ansamblu, ci la o activitate specifică efectuată într-o secvență planificată corespunzătoare programului de lucru al proiectului.

Planificarea si organizarea achizitiilor si achizitiilor - prima etapă în managementul resurselor proiectului. Constă în etape, inclusiv selectarea furnizorilor, plasarea comenzilor și monitorizarea consumabilelor.

În etapa de planificare, se realizează o analiză echilibrată a pachetelor de lucru și a resurselor consumate, ținând cont de restricții și de distribuția previzională a acestora pe baza orarului cererii de resurse. Planificarea resurselor proiectului este baza pentru determinarea în timp a necesarului de resurse și pentru determinarea posibilității de a furniza resurse pentru încheierea contractelor de achiziție de resurse, planificarea aprovizionării cu resurse, precum și baza pentru distribuirea resurselor deja achiziționate pentru munca de proiect.

Ca o componentă principală a managementului de proiect, planificarea resurselor include o serie de componente, inclusiv:

  • · dezvoltarea și analiza echilibrată a pachetelor de lucru și a resurselor care vizează atingerea obiectivelor proiectului;
  • · dezvoltarea unui sistem de distribuție a resurselor și numirea executorilor responsabili;
  • · monitorizarea progresului lucrărilor - compararea parametrilor de lucru planificați cu cei efectivi și elaborarea acțiunilor corective.

Resursele acționează ca furnizarea de componente ale lucrării proiectului, inclusiv performanți, energie, materiale, echipamente etc. În consecință, funcția de necesar de resurse poate fi asociată cu fiecare lucrare, iar cerințele de resurse pentru proiect în ansamblu pot fi calculate folosind metode de planificare și metode de potrivire pot fi asigurate nevoi, disponibilitate sau capacitatea de a furniza resurse.

În principiu, atunci când planificați îndeplinirea cerințelor de resurse pentru activitățile proiectului, trebuie luată în considerare o regulă generală: volumul total de cerințe pentru fiecare tip de resursă la fiecare moment din timpul ciclului de viață al proiectului nu trebuie să fie mai mic decât volumul total. de disponibilitatea acestei resurse în acel moment, ținând cont de rezerve.

Estimarea costului proiectului

În funcție de stadiul ciclului de viață al proiectului și de scopul evaluării, se folosesc diverse tipuri și metode de estimare a costului proiectului. Pe baza scopurilor evaluărilor, acuratețea acestor evaluări variază, de asemenea. Nu vom lua în considerare în detaliu, dar trebuie să țineți cont de faptul că cea mai mare eroare apare, desigur, în etapa de stabilizare a proiectului, când erorile dintr-o anumită versiune sunt identificate și corectate, de asemenea, este posibil ca totul; a fost făcut nu a fost implementat corect (în sensul tehnologiei), dar acest lucru se referă deja la design analfabet.

Pentru a estima costul unui proiect, trebuie să cunoașteți costul resurselor care compun proiectul, timpul necesar pentru finalizarea lucrării și costul acestei lucrări.

Astfel, estimarea costurilor începe cu determinarea resurselor și structurii de lucru a proiectului. Aceste sarcini sunt rezolvate ca parte a planificării proiectului, iar modulul de estimare a costurilor ar trebui să primească rezultatele acestui proces. Costul proiectului este determinat de resurse necesare executării lucrării.