Trimiteți-vă munca bună în baza de cunoștințe este simplu. Utilizați formularul de mai jos

Studenții, studenții absolvenți, tinerii oameni de știință care folosesc baza de cunoștințe în studiile și munca lor vă vor fi foarte recunoscători.

postat pe http://www.allbest.ru/

postat pe http://www.allbest.ru/

• Introducere
• 1. Analiza abordărilor managementului de proiect bazate pe metodologie clasică și flexibilă
• 1.1 Introducere în metodologiile agile de management de proiect
• 1.2 Critici și probleme ale managementului agil al proiectelor
• 1.3 Istoricul dezvoltării opiniilor asupra metodologiilor agile
• 1.4 Metodologii agile versus abordarea tradițională de management de proiect
• 1.5 Factori cheie de succes pentru proiectele IT Agile
• 1.6 Abordarea situațională în managementul proiectelor în domeniul tehnologiei informației
• 1.7 Descrierea generală a proiectelor IT
• 1.8 Caracteristici ale managementului de proiect în diferite țări
• 1.9 Caracteristicile etnoculturale ale activităților proiectului în Rusia
• 1.10 Tranziția la agilitate de la o abordare tradițională de management de proiect
• Concluzii capitolului
• 2. Studiu empiric al KFU pentru proiecte IT
• 2.1 Metodologia cercetării
• 2.2 Ipoteze de cercetare
• 2.3 Descrierea procesului de interviu
• 2.4 Analiza rezultatelor
• 2.4.1 Datele demografice ale respondenților
• 2.4.2 Testul de fiabilitate al variabilelor modelului
• 2.4.3 Analiza corelațiilor variabilelor independente cu succesul proiectului
• 2.4.4 Construirea unui model de regresie liniară multiplă
• 2.5 Interpretarea rezultatelor
• Concluzii capitolului
• 3. Recomandări practice
• 3.1 Sfaturi pentru trecerea la o metodologie agilă
• 3.2 Recomandări pentru realizarea unei retrospective calitative
• 3.3 Echipa de autoreglare ca modalitate de a accelera procesul de luare a deciziilor
• 3.4 Abordarea situațională în practica managementului de proiect
• Recomandări pentru cercetări viitoare
• Concluzii capitolului
• Concluzie
• Lista literaturii folosite
• Lista ilustrațiilor
• Anexa 1. Chestionar
• Anexa 2. Diagrame ale reziduurilor de regresie
• Anexa 3. Rezultatele sondajului
• Anexa 4. Interpretare pentru rezultatele sondajului

Introducere

Astăzi trăim într-o lume în care informația a devenit principalul produs și resursa societății. Activitatea aproape tuturor companiilor este oarecum legată de prelucrarea, depozitarea, producția și utilizarea acesteia. Astfel, tehnologiile informaționale au intrat ferm în viața noastră, au devenit parte integrantă a acesteia. Societatea informaţională se caracterizează printr-o viteză enormă de dezvoltare şi schimbare. Acest lucru nu s-a observat acum câteva decenii: un inginer putea obține o educație, iar aceste cunoștințe i-au fost suficiente pentru o viață întreagă. Acum este nevoie nu doar de formare periodică avansată, ci și de învățare pe tot parcursul vieții. Cu alte cuvinte, ritmul schimbării mediu inconjurator a crescut foarte mult, așa că a devenit necesar să facem față schimbărilor din mediu. Deci, în domeniul dezvoltării software (SW), de-a lungul timpului, a apărut conceptul de dezvoltare agilă. A făcut posibilă să facă față în mod adecvat schimbărilor din mediu și să creeze un produs de care clientul avea nevoie.

Acum, acest concept a depășit semnificativ domeniul de aplicare al dezvoltării software și a devenit, de fapt, o alternativă la abordarea tradițională a managementului de proiect în toate domeniile. Dar este deosebit de popular în domeniul tehnologiei informației (IT), datorită dinamismului acestei zone. Cu toate acestea, în ciuda popularității în creștere și a ritmului actual de schimbare în mediul de afaceri, multe companii încă aderă la abordarea tradițională. Abordarea agilă (flexibilă) este de obicei necunoscută pentru ei, așa că trecerea la o nouă metodologie poate fi dificilă. Într-o astfel de situație, este util să aveți un set de puncte cheie cărora ar trebui să le acordați o atenție deosebită. În literatură, aceștia sunt numiți factori cheie de succes (KSF). În literatura străină există un număr semnificativ de lucrări pe această temă, dar în Rusia această zonă abia începe să se dezvolte, așa că practic nu există lucrări pe această temă. În timp ce factorii socio-culturali corespunzători diferitelor țări afectează foarte mult procesul de management. Și ar trebui să țineți cont de acest lucru atunci când lucrați cu proiecte.

Scopul acestei lucrări este de a umple un gol în cercetare: să ia în considerare factorii cheie de succes pentru proiectele IT care utilizează metodologii agile în Rusia și să ofere recomandări pentru utilizarea lor practică.

Pentru a face acest lucru, va trebui să finalizați următoarele sarcini:

1. Identificați UFC probabile folosind analiza literaturii de specialitate.

2. Realizați interviuri aprofundate cu managerii pentru a clarifica și completa KFU.

3. Proiectați și realizați un sondaj online al managerilor de proiecte IT care lucrează cu metodologii agile

4. Analizați rezultatele.

Obiectul lucrării îl reprezintă factorii cheie de succes ai proiectelor.

Subiectul reprezintă factorii cheie de succes pentru un proiect IT folosind metodologii agile.

Pentru a forma recomandări pentru managerii de proiect agile, este necesar să se identifice factorii care au cel mai mare impact asupra succesului proiectului. Este important să facem acest lucru tocmai bazându-ne pe managerii ruși, deoarece managementul diferă în diferite țări din cauza factorilor socio-culturali. Prin urmare, este necesar să se colecteze informații primare: nu există informații secundare.

Metoda de colectare este un sondaj al managerilor de proiect din IT cu privire la proiectul lor realizat folosind metodologii agile. Sondajul a fost realizat în 3 etape:

1. Formarea listei primare a KFU pe baza literaturii disponibile

2. Perfecţionarea KFU în timpul unui interviu nestructurat cu 3 manageri de proiect

3. Alcătuirea chestionarului și testarea pilot

Datele obținute au fost analizate pentru prezența unei relații între succesul proiectului și diverse variabile. Ca metode de analiză au fost utilizați coeficienții de corelație și analiza de regresie efectuată folosind SPSS.

Rezultatele studiului vor fi utile atât pentru managerii care lucrează deja cu metodologii agile, cât și pentru cei care urmează să le aplice într-unul dintre proiectele lor viitoare sau să le implementeze în organizația lor. În primul caz, recomandările elaborate în lucrare vor permite diagnosticarea problemelor, dacă există, și reconsiderarea ce aspecte ale activității necesită cea mai mare atenție. Pentru începători, va fi util să folosească recomandările ca punct de plecare și pentru a pune corect accent într-un proiect viitor.

Din punct de vedere structural, lucrarea este împărțită în 3 mari capitole. Prima – teoretică, este o analiză a literaturii existente pe această temă, în principal din surse străine. Cea mai mare atenție a fost acordată articolelor din International Journal of Project Management și revistelor de specialitate legate de dezvoltarea software. Al doilea capitol este o descriere detaliată a metodologiei de cercetare, analiza și interpretarea datelor eșantionului obținut. Al treilea capitol este un set de recomandări pentru practicieni bazate pe rezultatele studiului.

Noutatea științifică a lucrării se datorează lipsei aproape complete a cercetărilor publicate privind metodologiile agile de management de proiect în Rusia în ansamblu. Deși este absolut necesar să se țină cont de factorii socio-culturali atunci când gestionați proiecte agile. regresie liniară informațională managerială

1. Analiza abordărilor managementului de proiect bazate pe metodologie clasică și flexibilă

1.1 Introducere în metodologiile agile de management de proiect

Metodologiile de management al proiectelor IT pot fi împărțite în linii mari în două abordări:

· Tradițional

Flexibil (iterativ)

Tradițional - bazat pe o planificare destul de riguroasă a proiectului înainte de lansare și intervenție minimă după. Cu această abordare, fiecare fază ulterioară începe după cea anterioară: implementarea după planificare și așa mai departe. În același timp, nu există o întoarcere la fazele anterioare, motiv pentru care această metodă este uneori numită metoda cascadei. Abordarea tradițională se corelează cu standardul clasic de management de proiect de la PMI - PMBoK. În special, descrie bine procesul de definire a managementului de proiect:

Aplicarea cunoștințelor și abilităților, a instrumentelor și tehnicilor în munca de proiect pentru a îndeplini cerințele proiectului.

Metodologiile agile, la rândul lor, sunt mai puțin legate de planificare și implică un ciclu de viață complet diferit - iterații. Această abordare vă permite să lucrați mai eficient într-un mediu de afaceri în schimbare rapidă. Principala diferență este o privire asupra schimbărilor în diferite etape ale proiectului. Cu abordarea tradițională, schimbările într-o etapă ulterioară sunt nedorite și costisitoare. Metodologii agile - încurajează schimbarea în toate etapele. Acest lucru îi face mai competitivi în realitățile actuale.

Astăzi, metodologiile agile reprezintă o alternativă bună la abordarea tradițională și sunt utilizate pe scară largă în diverse domenii high-tech, în special în IT. Motivul este faptul că abordarea tradițională întâmpină dificultăți semnificative atunci când cerințele pentru proiect se pot schimba în aproape orice etapă, deoarece este necesar să se răspundă unui mediu în schimbare rapidă. Un caz și mai complicat - rezultatul final al produsului nu este complet clar, adică este necesar să se dezvolte fără a ști pe deplin ce se va întâmpla. Metodologiile agile în astfel de situații par mai de preferat.

Practica utilizării metodologiilor confirmă, de asemenea, aceste concluzii: ponderea proiectelor Agile în gama totală este în continuă creștere (de la 2% în 2002 la 9% în 2010), în timp ce abordările tradiționale își pierd din popularitate, ceea ce se remarcă mai ales în domeniul dezvoltarea aplicației.

Managementul proiectelor există la diferite niveluri ale ierarhiei. În vedere (Maylor, Brady, Cooke-Davies și Hodgson, 2006) arată astfel:

Figura 1. Mediul proiectului

Inițial, această schemă a vizat proiecte de dezvoltare software, dar există aproximativ în aceeași formă în alte proiecte din IT. Este clar că (Maylor, Brady, Cooke-Davies, & Hodgson, 2006) evidențiază metodologiile Agile specifice precum SCRUM și XP ca metodologii la nivel de echipă. Cu toate acestea, unii cercetători tind să privească SCRUM ca pe o metodologie mai generală care se aplică și la nivelul managerului de proiect (Barlow et al., 2011). O serie de cercetători iau în considerare Scrum și în alte domenii decât IT. Această metodologie prezintă rezultate bune și în alte domenii, cum ar fi construcțiile (Owen, Koaskela și Henrich, 2006).

1.2 Critici și probleme ale managementului agil al proiectelor

Cu toate acestea, abordarea agilă a managementului de proiect are și anumite dezavantaje, remarcate de mulți cercetători. În special (Coplien & Harrison, 2004) remarcă faptul că mulți manageri de astăzi sunt „ca lemmingii” urmând ultimele tendințe, în loc să le pese de utilizarea abordării optime. În plus (Coplien & Harrison, 2004) sunt îngrijorați de faptul că Agile se îndepărtează de principiile stabilite în Manifest. Din ce în ce mai mult, dorința este îndreptată către însuși faptul de a aplica abordarea agilă fără a înțelege principiile care stau la baza acesteia.

Ca unul dintre principalele riscuri ale unui proiect agil (Boehm & Turner, 2003), el a evidențiat posibile erori în timpul dezvoltării, deoarece controlul din exterior devine mai complicat din cauza lipsei de documentație.

Există un punct de vedere că, datorită faptului că un proiect agil necesită o echipă mai pregătită tehnic și destul de independentă, succesul proiectului se datorează în mare măsură acestui fapt, și nu aplicării vreunei metodologii (Cohen, Lindvall, & Costa, 2004). În acest caz, majoritatea studiilor privind eficacitatea abordării devin părtinitoare.

1.3 Istoricul dezvoltării opiniilor asupra metodologiilor agile

Metodologiile Agile sunt un întreg set de metode diferite: SCRUM, programare Xtreme, Lean și altele, dar sunt unite prin respectarea a 4 principii de bază descrise în Manifestul Agile din 2001:

Oameni și interacțiune mai important decât proceseleși unelte

Un produs care funcționează este mai important decât o documentație completă

Cooperarea cu clientul este mai importantă decât negocierea termenilor contractului

Dorința de schimbare este mai importantă decât respectarea planului inițial

Cu toate acestea, Agile nu a apărut în mintea câtorva oameni în 2001, de fapt, istoria dezvoltării sale are câteva zeci, iar Manifesto a fost doar o consolidare a fundațiilor.

Imperfecțiunea abordării existente a fost recunoscută cu mult înainte de 2001 și s-au încercat să se aplice noi abordări. Deja în anii 1970-1980 se foloseau metodologii iterative și incrementale, care prezentau avantaje serioase în ceea ce privește viteza de implementare a proiectelor și eficiența acestora. De exemplu, EVO, RAD, DSDM - toate aceste metodologii sunt foarte apropiate de ideile de management flexibil de proiect, au apărut și au fost folosite cu mult înainte de manifest. Mulți chiar au avut un oarecare succes: în 1988, compania a introdus metodologia sa Rapid Iterative Production Prototyping (RIPP), datorită căreia au reușit să reducă semnificativ timpul de dezvoltare a software-ului. Compania a garantat clienților un produs finit în termen de 90 de zile sau o garanție de returnare a banilor.

Cea mai interesantă parte a articolului arată ca un tabel care compară principiile din Manifestul Agile cu metodologiile abordărilor anterioare. Relativ nou doar 2 puncte din 12, iar toate celelalte au fost deja notate sau chiar aplicate în metodologiile menționate mai sus. Cu alte cuvinte, majoritatea principiilor agile sunt rezultatul a mai multor decenii de dezvoltare a unor abordări alternative pentru livrarea proiectelor.

A fost prezentată o revizuire excelentă a lucrărilor empirice pe tema metodologiilor Agile (Dybe & Dingshur, 2008). Au fost găsite lucrări din 1996, dintre care 36 s-au dovedit a fi empirice și au fost selectate pentru analiză. În cursul unei revizuiri detaliate și al sistematizării, autorii au concluzionat că există o lipsă de cercetări empirice de înaltă calitate pe acest subiect.

1.4 Metodologii agile versus abordarea tradițională de management de proiect

În ciuda unei perioade destul de lungi de aplicare cu succes în diverse proiecte, mulți manageri sunt încă sceptici față de metodologia agilă și preferă metodele tradiționale. Această poziție este parțial justificată: toate proiectele sunt unice și necesită o abordare diferită. Acest aspect este bine descris în articol (Fernandez & Fernandez, 2008). Răspunsul la întrebare se află în situația de aplicare. Autorii identifică 4 tipuri de condiții inițiale ale proiectului:

1. Sunt definite scopul și modalitatea de a-l atinge

2. Scop definit, nici o cale de atins

3. O anumită cale, fără un scop anume

4. Scop și cale incertă

În diferite situații, abordarea tradițională poate fi mai eficientă, în timp ce în altele poate fi mai flexibilă. Într-un proiect standard cu un obiectiv clar și ușor de atins, abordarea tradițională poate fi mai eficientă și mai ușoară, deoarece schimbările viitoare sunt puțin probabile. Într-o situație în care ceva este necunoscut, există incertitudine. Abordarea tradițională nu este foarte eficientă într-o astfel de situație: riscurile cresc, deoarece costul schimbării este foarte mare. Într-o situație de incertitudine în ceea ce privește obiectivul, calea sau toate împreună, metodologiile agile funcționează mai bine, deoarece susțin schimbări în toate etapele și nu necesită o înțelegere completă a rezultatului final chiar de la început. Echipa, împreună cu clientul, poate obține rezultatul dorit în timpul procesului de creație, ceea ce reduce semnificativ riscul de a primi un produs învechit. Autorii articolului mai notează că, pe lângă rezolvarea problemelor, metodologiile flexibile oferă anumite cerințe pentru organizație, manageri și echipe. Agile presupune rezolvarea multor probleme în echipe autonome, ceea ce înseamnă că liderul și structura organizationala ar trebui să permită acest lucru, ca să nu mai vorbim de o anumită maturitate a echipei în sine.

1.5 Factori cheie de succes pentru proiectele IT Agile

Atunci când un manager care a urmat anterior o metodologie tradițională în activitatea sa decide să aplice o abordare agilă pentru următorul proiect, întrebarea cheie care se pune este la ce factori ar trebui să acorde atenție el și echipa. Sunt multe aspecte care cu siguranță nu pot fi omise, dar pentru aplicarea eficientă a noii metodologii, este important să știm cărora ar trebui să li se acorde maxim accent. În același timp, în Manifestul Agile, dimpotrivă, principiile importante sunt descrise prea abstract și nu sunt aplicabile direct lucrării. Pentru aplicații viitoare, sunt necesare recomandări mai specifice, așa că există deja un corp semnificativ de lucrări care descrie factorii cheie de succes ai proiectelor.

Există multe puncte de vedere asupra conceptului de succes al proiectului, dar cei mai cunoscuți și recunoscuți în managementul proiectelor sunt 3 indicatori: cost, timp, calitate. Această abordare este adesea numită triunghiul de proiectare și este descrisă după cum urmează:

Figura 2. Triunghiul de proiectare

O astfel de interpretare grafică demonstrează relația dintre aceste componente și influența lor reciprocă: încercările de a reduce timpul de implementare a proiectului duc la o scădere a calității sau la o creștere a costurilor etc.

Daniel (1961) a fost primul care a propus conceptul unui factor cheie de succes în articolul său din Harvard Business Review „Management Information Crisis”. Mai detaliat, termenul a fost dezvăluit (Rockart, 1979):

Factorii cheie de succes sunt „mai multe domenii cheie în care este nevoie de un rezultat pozitiv pentru ca organizația să reușească”. Astfel, acestea sunt cele mai importante domenii pentru management, atenția cărora este esențială pentru implementarea cu succes a proiectului. Acestea sunt aceleași 20% care aduc 80% din rezultat conform principiului Pareto.

Trebuie remarcat faptul că modelul KFU este un model relativ bun, dar, ca orice alt model, are câteva dezavantaje și simplificări:

Un singur factor. Modelul ia în considerare fiecare factor separat, în timp ce relația dintre factori este la fel de importantă (Nandhakumar, 1996)

Static. Modelul presupune că o implementare sau un proiect nu se schimbă în timp, în timp ce, în practică, în diferite etape, unul sau altul poate fi cel mai important pentru succes (Larsen & Myers, 1999).

Factorii cheie de succes (KSF) pentru managementul proiectelor sunt destul de bine acoperiți de diverși autori. (Fortune & White, 2006) În articolul lor, ei au analizat 63 de publicații și au identificat cele mai populare KFU. S-a dovedit că cercetătorii nu au fost unanimi în opinii: sprijinul conducerii, obiective clare și realiste, un plan detaliat - factorii care au primit cele mai multe mențiuni au apărut toți trei împreună în doar 17% din lucrări.

În domeniul proiectelor IT, există și un anumit nivel de lucru pe această problemă, însă, în acest caz, nu există un consens în rândul cercetătorilor. (Misra, Kumar și Kumar, 2009) În munca lor, ei au efectuat un studiu la scară largă asupra factorilor cheie de succes în proiecte folosind metodologii agile. Autorii și-au concentrat atenția asupra dezvoltării de software, dar nu există obstacole semnificative în calea extinderii constatărilor la sfera IT în ansamblu.

Pe lângă un eșantion fără precedent de 241 de respondenți, avantajul studiului este structura a 14 factori cheie de succes pentru proiectele Agile, care a fost construită pe baza analizei. munca existentași testat cu un sondaj.

(Misra, Kumar și Kumar, 2009) Următorii factori au fost identificați ca fiind cei mai importanți:

1. Orientare către client

2. Timp de decizie

3. Distribuția echipei (geografică)

4. Dimensiunea echipei

5. Cultura corporativă

6. Planificare și control

7. Competenta

8. Caracteristici personale

9. Comunicare și negociere

10. Caracteristici socio-culturale

11. Cunoaștere și învățare

În alte articole pe această temă, de regulă, sunt evidențiați aproximativ aceiași factori. Diferențele sunt în principal în formulare și ierarhie: unor factori li se acordă mai multă importanță.

Principalele contradicții în rândul cercetătorilor apar în legătură cu 3 factori:

Distribuția echipei

Marimea echipei

Cunoștințe și pregătire

Sunt exprimate puncte de vedere diferite - (Dybe & Dingsшyr, 2008) rețineți că este important nu numai să puneți laolaltă întreaga echipă, ci și pe cumpărător, deoarece acest lucru permite o discuție detaliată a tuturor momentelor de lucru. La rândul lor (Misra, Kumar și Kumar, 2009), în ciuda includerii acestui factor în modelul teoretic, ei nu au găsit o confirmare practică a semnificației pentru succesul proiectului. Același rezultat a fost obținut (Livermore, 2008) în studiul său. Astfel, este de remarcat faptul că amplasarea echipei de proiect într-un singur loc este un aspect care necesită un studiu suplimentar.

(Misra, Kumar și Kumar, 2009) Nici nu au găsit o corelație semnificativă între succesul proiectului și dimensiunea echipei, deși opinia predominantă în literatura de specialitate este că metodologiile Agile au fost dezvoltate și aplicate echipelor mici.

(Livermore, 2008) a observat că Scrum, ca una dintre metodologiile flexibile, este aplicabilă atât proiectelor mari (și, în consecință, echipelor), cât și celor mari, spre deosebire de Extreme Programming și altele.

Există, de asemenea, puncte de vedere contradictorii asupra cunoștințelor și învățării echipei: pe de o parte, o echipă cu experiență arată rezultate mai bune (Wysocki, 2012), ceea ce este destul de așteptat și confirmat de cercetări. Pe de altă parte, predarea exactă a metodologiei nu pare atât de clară. (Livermore, 2008) a găsit o corelație semnificativă între succesul proiectului și învățare, în timp ce (Misra, Kumar și Kumar, 2009) nu au găsit niciun sprijin pentru această poziție în studiul lor empiric. Este de remarcat faptul că eșantioanele în ambele cazuri au fost semnificative din punct de vedere statistic și au avut un număr mare de respondenți din diferite regiuni (mai mult de 100, respectiv mai mult de 200)

1.6 Abordarea situațională în managementul proiectelor în domeniul tehnologiei informației

În fiecare an, varietatea proiectelor crește - în funcție de domeniu de activitate, amploare și alți factori. Ca răspuns, managerii dezvoltă noi metode de gestionare a acestor proiecte. Controlul fiabil este posibil numai atunci când sistemul de control are o varietate de acțiuni nu mai mici decât varietatea de acțiuni probabile ale sistemului controlat. Aceasta este „Legea Varietății Necesare” enunțată în termeni mai înțeleși, formulată de matematicianul William Ashby în cartea sa „Introduction to Cybernetics”. A fost formulat inițial pentru sisteme tehniceși suna după cum urmează: „Diversitatea rezultatelor [situațiilor], dacă este minimă, poate fi redusă și mai mult printr-o creștere corespunzătoare a diversității pe care o are autoritatea de reglementare” (Ashby, 2015) în capitolul 11. Dar aceeași lege funcționează pentru alte sisteme, cum ar fi o organizație sau un proiect, de atunci a devenit cunoscută drept „Prima lege a managementului”. Astfel, pentru un management eficient este necesar să se mărească varietatea acțiunilor posibile - să se utilizeze diferite metodologii și combinațiile acestora.

Mulți cercetători și practicieni încă cred că proiectele sunt similare între ele și pot fi gestionate în același mod (Shenhar, 2001). Cu toate acestea, abordarea situațională câștigă din ce în ce mai multă popularitate, conform căreia este necesar să se selecteze o metodologie pentru fiecare proiect în mod individual, în funcție de o serie de factori: Mediul extern caracteristicile organizației și ale proiectului în sine. Cu un număr tot mai mare de alternative atunci când aleg o metodologie, managerii de proiect se confruntă cu sarcina dificilă de a alege opțiunea potrivită.

(Howell et al., 2010) în munca lor, pe baza analizei literaturii de specialitate, au propus un model care vă permite să corelați caracteristicile proiectului și cea mai eficientă metodologie.

Figura 3. Incertitudinea diagramei - Consecințe

Axa orizontală reprezintă gradul de incertitudine, iar axa verticală semnificația consecințelor. Aceste 2 dimensiuni includ toți factorii identificați de autori în analiza literaturii de specialitate:

Gradul de incertitudine include incertitudinea, complexitatea și urgența proiectului

· Semnificația consecințelor - criticitatea consecințelor și responsabilitatea echipei.

Pe diagramă, fiecare metodologie are o „zonă de confort” în cadrul căreia se aplică cel mai bine. De exemplu, pentru Agile, acestea sunt proiecte de orice nivel de incertitudine care nu au consecințe grave, de exemplu. al cărui eşec sau succes nu va pune în pericol existenţa firmei. În cazul suprapunerii zonelor, se recomandă aplicarea unei metodologii mai simplu și mai ieftin de aplicat.

În practică, managerii nu folosesc aceeași metodologie în formă pură- de cele mai multe ori este o combinație a două abordări. Un anumit instrument poate aduce un anumit beneficiu proiectului, dacă este aplicat în condițiile potrivite.

O astfel de abordare hibridă a fost luată în considerare (Baird & Riggins, 2012) în articolele „Planificare și sprinting: Utilizarea unei metodologii hibride de management de proiect în cadrul unui curs capstone CIS”. Ca echipe de proiect, cercetătorii au fost grupuri de studenți care au realizat un anumit proiect. Acest fapt impune, desigur, unele restricții în aplicarea rezultatelor: este dificil să le transferați direct în sfera de afaceri.

Abordarea hibridă a autorilor a fost următoarea: proiectul se desfășoară în iterații scurte cu un backlog de sprint și o prezentare a lucrărilor primite către profesori după fiecare sprint. Diferența față de Scrum în acest caz a fost în primul sprint: în loc să încerce să creeze un produs imediat, de la zero, în timpul primei iterații, elevii au produs un plan - o prezentare a lucrărilor ulterioare. Așa cum a fost concepută de cercetători, această abordare ar fi trebuit să ajute studenții în stadiile incipiente, fără a pierde beneficiile scrumului și posibilitatea unor schimbări nestingherite chiar și târzii.

Rezultatele studiului au arătat că atât profesorii (reprezentând în mod condiționat clienții), cât și membrii echipei au fost mulțumiți de procesul de implementare și de produsul final. Cercetătorii au arătat cum să depășești unele dintre problemele managementului agil al proiectelor, de exemplu, una dintre cele mai importante - dificultatea cu planificarea pe termen lung. În Scrum, planificarea se face în primul rând pentru sprintul curent, nu pentru termen lung. Această problemă a fost parțial rezolvată prin schimbarea obiectivului primului sprint în planul de producție. Desi cercetatorii au observat o usoara scadere a motivatiei datorita acestui proces, beneficiile planificarii depasesc acest factor.

1.7 Descrierea generală a proiectelor IT

În primul rând, merită să definim ce include conceptul de IT. ACEASTA- tehnologia de informație se obișnuiește să se numească tot ceea ce ține de prelucrarea, stocarea și utilizarea informațiilor, dar recent, în legătură cu dezvoltarea tehnologia calculatoarelorși internetul, IT-ul este asociat în primul rând cu acestea. În această lucrare, un proiect IT va fi înțeles ca proiecte din domeniul dezvoltării software, Securitatea informațiilor, sisteme corporative.

IT este una dintre zonele cu cea mai rapidă creștere în prezent. Companiile nu pot face fără diverse sisteme(sisteme de securitate, CRM, sisteme ERP) și servere care susțin afaceri și fără site-uri și pagini în în rețelele sociale. Până în prezent, un număr semnificativ de proiecte din domeniul IT sunt finalizate cu un exces de buget, termene limită sau se transformă într-un eșec total. Conform raportului CHAOS Summary 2010 („CHAOS Summary 2010,”[Electronic resource] 2010), doar 37% dintre proiecte sunt finalizate cu succes. Alți 42% se confruntă cu probleme de timp, buget sau calitate, iar restul de 21% sunt considerați complet eșuați. Deși există o anumită tendință pozitivă, nu există încă îmbunătățiri majore. 37% reprezintă o parte destul de mică din numărul total de proiecte. Acest raport se concentrează în principal pe proiecte de dezvoltare software, dar o situație similară se observă și cu alte proiecte.

Una dintre caracteristicile distinctive, pe lângă dezvoltarea și schimbarea rapidă, este gradul de criticitate al consecințelor. Pentru proiectele IT diferă mult mai mult decât în ​​alte domenii: proiectul de acces la sisteme statistici de statși dezvoltarea unui sistem de control al zborului au consecințe foarte diferite ale unei erori de implementare. În construcții, de exemplu, proiectele care sunt interesante din punct de vedere al managementului sunt, de regulă, critice și au consecințe grave care pot ruina compania.

1.8 Caracteristici ale managementului de proiect în diferite țări

Până în prezent, se acordă o influență destul de mare factorilor socio-culturali care afectează managementul unei organizații sau al unui proiect. Conceptul de cultură economică națională ca set de norme și valori în activitate economică este una dintre cheile în cadrul disciplinei științifice „Comportament organizațional”.

Cea mai populară tipologie a valorilor organizaționale a fost prezentată de G. Hofstede: în terminologia sa sunt prezentați 5 indici, care depind de cultura națională.

individualism – colectivism

distanta de putere

evitarea incertitudinii

feminitate – masculinitate

·Orientare pe termen lung

Inițial au fost evidențiate 4 dimensiuni, ultima - Orientare pe termen lung, a fost adăugată în lucrările ulterioare. Datele pentru analiza valorilor culturale au fost obținute de autori în mare parte întâmplător, când lucra ca psiholog într-o mare corporație transnațională - IBM și făcea cercetări acolo. În perioada 1967-1971, au fost analizați peste 116.000 de angajați din multe țări.

Să aruncăm o privire mai atentă asupra fiecărei dimensiuni culturale și a impactului acesteia asupra managementului de proiect.

Individualism – colectivism. În țările cu o cultură predominantă a individualismului, societatea îi oferă individului mult mai multă libertate, îl leagă mai puțin cu ceilalți: îi pasă doar de el însuși și, eventual, de cei mai apropiați membri ai familiei. În țările mai colectiviste, oamenii sunt mai aproape unii de alții și se simt incluși în grup. Împărtășesc interese și opinii de grup, iar grupul îi protejează într-o oarecare măsură, oferă sprijin în necazuri. Există o relație puternică între PIB-ul pe cap de locuitor și gradul de individualism: țările individualiste tind să fie mai bogate. Managementul proiectelor este o idee care a apărut în țările individualiste. În țările mai colectiviste, structurile flexibile și caracterul temporar al proiectelor îi pun pe oameni într-o poziție în care nu sunt atașați unui anumit grup și experimentează alienarea. Aceasta este o situație neobișnuită pentru ei. Pentru a evita această situație (Hofstede, 1983) sugerează să se acorde mai multă atenție relațiilor dintre oameni dintr-un proiect. Este mai bine să folosiți echipele existente sau să le formați din oameni din același grup. De asemenea, merită luat în considerare atunci când planificați momentul pentru a stabili relații în echipă.

Distanța de putere. Următoarea dimensiune este legată de conceptul de inegalitate. Oamenii sunt inegali prin natura sa din cauza diferentelor fizice si intelectuale. Unele țări permit creșterea acestei inegalități (nivel ridicat al distanței de putere), unele, dimpotrivă, încearcă să o reducă (nivel scăzut).

Evitarea incertitudinii. În unele țări, oamenilor li se spune că incertitudinea nu trebuie de temut, ci trebuie acceptată. Ei își asumă riscuri mai ușor și se simt mai confortabil cu comportamente și opinii altele decât ale lor. Aceste țări au un nivel scăzut de evitare a incertitudinii. În schimb, țările cu nivel inalt, încercând să „face față” viitorului. Și întrucât viitorul este imprevizibil, locuitorii acestor țări încearcă să creeze instituții care să asigure securitatea și să reducă riscul. Poate fi tehnologii, legi, religii (inclusiv știință, într-un sens).

Pe două dimensiuni - Distanța de putere și Acceptarea incertitudinii - țările erau situate într-un plan.

Figura 4. Distribuția țărilor pe clustere, în funcție de caracteristicile culturale

Axa orizontală este indicele distanței de putere, axa verticală este indicele de acceptare a incertitudinii. Țările sunt împărțite în mai multe grupuri. Colțul din dreapta sus corespunde modelului „de familie” - distanță de putere mare, indice de acceptare incertitudine scăzut. Colțul din dreapta jos este un model „piramidă” cu un indice mare al distanței de putere și acceptarea incertitudinii. Stânga jos - „mașină bine unsă”, indice de distanță cu putere redusă și acceptare ridicată a incertitudinii. Colțul din stânga sus - „piața satului”, indici mici ai distanței de putere și acceptarea incertitudinii. Managementul proiectelor presupune un model de „piață de sat”, când ierarhia nu este atât de importantă (pot fi două dintre ele - proiect și funcțional), important este să nu vă fie frică de incertitudine și să puteți rezolva conflictele prin negocieri (Hofstede, 1983). Pentru alte tipuri de culturi este necesară adaptarea managementului pentru a obține un rezultat mai bun.

Masculinitate și feminitate. Țările cu un nivel ridicat de separare a rolurilor pe gen (de exemplu, un profesor este meseria unei femei, un șofer este a unui bărbat) se numesc masculin, iar cele cu un nivel scăzut sunt numite feminine. Din punctul de vedere al lui Hofstede, această dimensiune nu este semnificativ legată de managementul proiectelor.

În acești termeni cultura rusă corespunde la:

individualism

Distanță de putere mare

Gradul ridicat de evitare a incertitudinii

feminitate

・Orientare pe termen scurt

Diferențele de cultură națională impun anumite restricții în aplicarea teoriilor și metodologiilor scrise pentru organizații cu o cultură fundamental diferită. Acest factor a fost remarcat de oamenii de știință și cercetările sunt desfășurate în mod activ în această direcție.

În cadrul PMBoK Project Management Body of Knowledge: PMI, cultura este remarcată ca unul dintre factorii importanți în mediul organizației. „În lumina globalizării, înțelegerea influenței culturilor este critică.” Cultura devine un factor critic în determinarea succesului unui proiect.” PMBOK. Unii cercetători subliniază, de asemenea, că una dintre ipotezele PMBOK este că există o parte constantă și o parte variabilă în managementul proiectelor, care sunt direct influențate de factorii culturii naționale. Acest lucru este valabil mai ales pentru proiectele în care este implicată o echipă multiculturală sau distribuită geografic în diferite locuri. În condițiile rusești - cea mai mare și multinațională țară din lume, aceasta este o situație destul de comună, așa că acest subiect este deosebit de relevant pentru managerii de proiect ruși.

1.9 Caracteristicile etnoculturale ale activităților proiectului în Rusia

Dezvoltarea acestui subiect în domeniul managementului de proiect în Rusia este încă într-un stadiu incipient, dar încep să apară noi lucrări științifice, de exemplu, (Kozhevnikova, 2013) în lucrarea „Factorii etno-culturali ai activității de proiect în Rusia. : probleme și instrumente” a prezentat un studiu al influenței factorilor etno-culturali. În cadrul sondajului adresat managerilor de proiect din diverse companii (de la mari companii de construcții la mici companii de IT și consultanță), au fost identificate principalele domenii problematice ale managementului proiectelor: managementul termenelor limită, al calității, al personalului și al conținutului.

Astăzi, se colectează o cantitate imensă de date despre oameni din diferite țări, inclusiv date suficiente despre caracteristicile etno-culturale. În special, The World Values ​​Survey (www.worldvaluessurvey.org) este o rețea globală de oameni de știință socială care studiază schimbările în atitudinile valorice, precum și impactul acestora asupra sferei sociale, politice și în alte sfere ale vieții. Pe baza datelor din acest portal, precum și a studiului propriu al managerilor (Kozhevnikova, 2013), a fost întocmit un tabel de orientări valorice ale rușilor față de americani.

Tabelul 1 Comparația rușilor cu rezidenții din Statele Unite.

	Evaluarea manifestării la ruși (comparativ cu americanii)
Orientare spre rezultate	Mai puțin orientat spre rezultate, deși conștient de necesitatea realizării acestuia
Munca printre valorile vieții	Valoarea instrumentală a muncii (munca ca atingere a unor scopuri străine, nu autorealizarea), ca urmare, caracterul secundar al muncii în raport cu viața personală
Atitudine față de remunerație	Mai sensibil la valori materialeși remunerație
Formalism și cerințe	Acceptați o abordare mai puțin formală în timp ce sunteți obișnuit cu presiunea la locul de muncă
Inițiativă și realizări	Mai puțin pregătit să ia inițiativa și nu concentrat pe realizări
Încredere și toleranță	Să aibă un nivel mai scăzut de încredere și toleranță

Compilarea unor astfel de tabele ajută la arătarea vizuală a diferențelor dintre valorile americanilor (pe care se bazează în mare măsură teoriile de management și management de proiect) și ruși. Devine evidentă diferența, ceea ce nu este super grav, dar poate avea impact asupra procesului de management.

Punctele „Formalism și cerințe”, „Inițiativă și realizări”, „Încredere și toleranță” sunt de interes direct pentru practicanții metodologiilor flexibile de management al proiectelor din IT și alte domenii. Faptul că rușii „recunosc o abordare mai puțin formală” este un lucru pozitiv, deoarece practicile Agile se bazează pe o comunicare mai puțin formală și mai personală (nu trebuie luată în mod absolut), preferând planurile informale și comunicarea față în față între membrii echipei. Dimpotrivă, un nivel relativ scăzut de încredere și toleranță, precum și o dorință scăzută de a lua inițiativa și o orientare slabă spre realizare sunt factori negativi. Baza aproape a oricărei metodologii agile de management de proiect este o echipă bine coordonată, cu un grad adecvat de independență. Este clar că un grad scăzut de încredere și dorința de a lua inițiativa au un impact negativ asupra capacității echipei.

Aceste fapte arată necesitatea luării în considerare a factorilor etno-culturali în managementul proiectelor. Nu ar trebui să le percepi ca trăsături inerente fiecărei persoane din Rusia și punând în pericol utilizarea metodologiilor Agile. Managerul trebuie doar să fie conștient de prezența lor și să încerce să depășească punctele slabe și să obțină beneficii suplimentare din punctele forte.

1.10 Tranziția la agilitate de la o abordare tradițională de management de proiect

Introducerea unei noi metodologii este un proces complex, care este adesea însoțit de diverse probleme, cum ar fi nepregătirea personalului, rezistența angajaților și altele. După cum sa menționat mai sus, CSP-urile identificate reprezintă trăsăturile unei organizații care a integrat pe deplin metodologiile agile în cultura și fluxul său de lucru. LA in caz contrar este extrem de greu de reușit. Prin urmare, una dintre sarcinile principale ale managerului de proiect este implementarea metodologiei în echipă și organizație.

În teoria managementului de proiect, un loc semnificativ îl ocupă evaluarea maturității companiei, precum și construirea unui sistem de management al proiectelor corporative. Ideea principală este că organizația se îndreaptă către implementarea completă a managementului de proiect treptat, deoarece implementarea multor instrumente este imposibilă dacă organizația nu este încă pregătită pentru aceasta. O abordare similară ar trebui aplicată metodologiilor agile. Nu este posibil să realinizi instantaneu oamenii și echipele pentru a fi agili. Organizațiile și echipele au nevoie de timp pentru a înțelege treptat nu numai procedurile și procesele specifice care curg într-un proiect folosind o abordare agilă, ci și principiile fundamentale. O organizație poate începe să folosească o anumită metodologie, dar asta nu înseamnă că este implementată: integrată în sistemul de valori și credințe, practicile de lucru ale personalului.

Complexitatea trecerii la o nouă metodologie variază de la organizație la organizație și depinde de mulți factori. Managerul ar trebui să acorde o atenție deosebită predării echipei noi metode, transmiterii valorii noii metodologii către echipă, sprijinirea resurselor pentru implementare, testarea noii abordări (Fernandes, Ward și Arájo, 2015).

Un aspect important în implementare este și capacitatea personalului. (Cockburn, 2002) a observat că diferențele dintre oameni îi fac mai mult sau mai puțin apți pentru un anumit tip de muncă. (Boehm & Turner, 2003) au dezvoltat clasificarea în 5 tipuri de angajați:

3 - capabil să regândească metoda, încălcând regulile acesteia pentru aplicarea cu succes într-o situație complet nouă, imprevizibilă

2 - Capabil să adapteze metoda la situația actuală

1 A - După antrenament, ei sunt capabili să folosească diverse metode care implică alegere independentă. Cu experiență, se pot trece la categoria 2.

1 B - După antrenament, ei sunt capabili să efectueze proceduri standard

1 - Pot avea abilități tehnice, dar nu pot sau nu doresc să efectueze lucrări în comun, nu împărtășesc metode comune.

Implementarea cu succes a metodologiilor agile necesită un număr suficient de angajați de tip 2 și 3. Dacă organizația are o proporție semnificativă de angajați 1B inflexibili, adoptarea unei abordări agile este riscantă. Merită să luați în considerare o abordare planificată sau hibridă, care implică o planificare mai amănunțită și mai formalizată. De asemenea, trebuie menționat că această abordare este și mai în concordanță cu cultura organizațională rusă (Kozhevnikova, 2013).

Concluzii capitolului.

Metodologiile agile sunt una dintre principalele alternative la abordarea tradițională de management de proiect. Ele sunt deosebit de eficiente în condițiile condițiilor de mediu în continuă schimbare și, prin urmare, cerințele pentru produs. Această situație este tipică în special pentru sectorul IT. Modelul KFU este o modalitate bună de a arăta factorii cărora un manager ar trebui să le acorde cea mai mare atenție. În literatura străină pe Acest subiect nu există unanimitate: cercetătorii identifică diferiți factori ca fiind cheie pentru succesul proiectului. În Rusia, practic nu există astfel de studii. În timp ce există diferențe obiective între țări în ceea ce privește factorii socio-culturali. Ele nu permit, cu un grad ridicat de probabilitate, să se proiecteze concluziile unor studii străine asupra companiilor rusești.

2. Studiu empiric al factorilor cheie de succes pentru proiectele IT

2.1 Metodologia cercetării

Metodologiile agile de management de proiect bazate pe crearea de valoare de afaceri pentru client în procesul de dezvoltare graduală iterativă a produsului au devenit ferm stabilite în proiectele IT. Ei și-au dovedit eficiența în fața incertitudinii care însoțește afacerile timpului nostru. Cu toate acestea, problema aplicării agile în practică este încă controversată în rândul teoreticienilor și practicienilor. Există suficiente articole în literatura de limbă engleză referitoare la factorii cheie de succes ai unui proiect agil, dar este greu de spus că ei evidențiază în unanimitate orice indicator (Fortune & White, 2006). Mai mult, aceste lucrări examinează respondenți din țări diferite, în timp ce fiecare țară are propriile caracteristici în managementul proiectelor (Hofstede, 1983). Lucrări similare despre proiecte rusești extrem de putine. Reducerea acestui decalaj este scopul principal al studiului.

Studiul poate fi împărțit în 4 etape:

· Etapa pregătitoare

・Etapa de colectare a informațiilor

Etapa analizei informatiilor primite

Pe etapa pregătitoare s-a efectuat o analiză primară a situaţiei problematice: o trecere în revistă a rusului şi literatură străină pe acest subiect și a realizat interviuri nestructurate cu 3 manageri de proiect IT care au avut experiență cu Agile. Rezultatul acestei etape a fost formularea ipotezelor de cercetare și elaborarea unui chestionar pentru colectarea de la distanță a informațiilor.

Colectarea informațiilor în a doua etapă a studiului a fost realizată cu ajutorul unui sondaj de la distanță a profesioniștilor IT prin Internet. Pentru a face acest lucru, chestionarul creat în etapa anterioară a fost postat pe forumuri tematice și grupuri de pe rețelele sociale folosind serviciul Google Docs.

Analiza informațiilor primite a fost realizată cu ajutorul SPSS. O atenție deosebită a fost acordată analizei corelațiilor și construcției modelelor de regresie.

2.2 Ipoteze de cercetare

Pe baza rezultatelor studiilor anterioare au fost formulate următoarele ipoteze:

Tabelul 2. Ipotezele cercetării

Variabil	Conexiune
Satisfacția clientului	Legat de succes
Interacțiunea cu clienții	Legat de succes
Timp de decizie	Legat de succes
Locația echipei	Fără legătură cu succesul
Marimea echipei	Legat de succes
Cultură corporatistă	Legat de succes
Planificare	Legat de succes
Control	Legat de succes
	Fără legătură cu succesul
Caracteristici personale	Legat de succes
Comunicare	Fără legătură cu succesul
Contact cu conducerea	Legat de succes
Folosind software special	Fără legătură cu succesul
Viziunea conducerii	Fără legătură cu succesul
Înțelegerea rolului	Legat de succes

2.3 Descrierea procesului de interviu

Sondajul este principala metodă de colectare a informațiilor din studiu. Metodologia utilizată în articol (Misra, Kumar și Kumar, 2009) a servit ca bază pentru chestionar. Chestionarul original a fost tradus în limba rusă și ulterior modificat. După analizarea interviurilor preliminare cu managerii, au fost adăugate câteva întrebări:

Echipa de proiect și conducerea companiei schimbă în mod regulat informații cu privire la progresul proiectului

Folosim software special pentru ușurința managementului și comunicării în cadrul echipei

Echipa și conducerea au avut o viziune clară asupra a ceea ce ar trebui să realizeze proiectul

Fiecare membru al echipei este bine conștient de rolul și funcțiile sale în cadrul proiectului

Aceste subiecte nu au fost abordate în sondajul inițial, dar au fost menționate ca fiind esențiale pentru succesul proiectului de către managerii intervievați.

Unele dintre întrebări au fost excluse din metodologie după discuții în timpul interviurilor cu managerii și în timpul studiului pilot al studiului de către studenții HSE. În special, variabila „Factori socioculturali” nu are sens în contextul acestui studiu, deoarece studiul este realizat în cadrul unei țări - Rusia, prin urmare factorii sunt predeterminați. În studiu (Misra, Kumar, & Kumar, 2009), această variabilă este responsabilă pentru diferențele dintre țările în care își desfășoară activitatea respondenții, ceea ce în acest caz este incorect.

După verificarea finală, sondajul a fost postat pe serviciul Google Docs, iar apoi publicat pe forumuri tematice și grupuri de pe rețelele sociale:

http://www.cyberforum.ru/

http://programmersforum.ru/

http://www.pmprofy.ru/

http://www.microsoftproject.ru/

http://www.pmi.ru/forum/

https://www.facebook.com/

https://www.linkedin.com/

Au fost primite în total 17 răspunsuri. S-a realizat o diversitate suficientă atât în ​​experiența respondenților, cât și în dimensiunea organizației.

Propunerea de ipoteze de cercetare

2.4 Analiza rezultatelor

Abordarea sondajului a fost în întregime cantitativă, cu excepția întrebărilor demografice. Au fost aplicate diverse metode statistice pentru a analiza aceste întrebări închise. Scopul principal al studiului relației dintre variabile: 15 independente (unele au inclus mai mult de 1 întrebare) și 1 dependentă - succesul proiectului. Au fost calculați coeficienții de corelație Pearson pentru fiecare variabilă independentă și a fost construit un model de regresie.

2.4.1 Datele demografice ale respondenților

Studiul a colectat de asemenea Informații suplimentare despre respondenți. Majoritatea respondenților reprezintă companii din industriile legate de calculatoare (software, hardware etc.) (76%), restul industriilor reprezintă câte 1 respondent (6%) - telecomunicații, consultanță, vânzări și finanțe.

Există o diversitate mult mai mare în ceea ce privește dimensiunea organizațiilor reprezentate:

Tabelul 3. Statistici descriptive – numărul de angajați din organizație

Se poate spune că sunt reprezentate atât organizații foarte mici de 10-20 de persoane, cât și mijlocii și companii mari.

Majoritatea respondenților reprezintă echipe de 5-10 persoane (41,2%) sau 11-20 de persoane (41,2%), celelalte dimensiuni ale echipelor sunt reprezentate de un număr mic de respondenți (5,9% fiecare). Este de remarcat un eșantion destul de uniform: aproximativ 50% dintre respondenți reprezintă echipe mici (până la 10 persoane) și 50% dintre echipele de peste 10 persoane.

Cel mai important punct din partea demografică a sondajului este experiența cu metodologiile Agile:

Tabelul 4. Statistici descriptive – experiență cu metodologii agile

Eșantionul este destul de uniform: există respondenți cu experiență diferită cu metodologii agile. O oarecare predominanță a respondenților cu mai puțin de 3 ani de experiență se datorează probabil faptului că abordarea agilă în Rusia abia începe să câștige popularitate.

2.4.2 Test de fiabilitatevariabilele modelului

Analiza de validitate a fost efectuată pentru variabile compuse din mai mulți indicatori. Ca metodă de determinare a fost ales coeficientul alfa lui Cronbach. Acest indicator evaluează consistența internă a variabilelor și se măsoară în valori de la 0 la 1, unde 0 - complet inconsecvent, 1 - complet consecvent. Astfel, cu cât valoarea este mai mare, cu atât este mai bine pentru studiu. Există diferite vederi asupra pragului de limită, dar cel mai popular prag este 0,7. Tabelul arată rezultatele pentru variabilele compuse:

Tabelul 5. Analiza validității variabilelor

După cum se poate observa, pentru toate variabilele, valorile coeficientului sunt mai mari decât cele de prag, deci putem concluziona că aceste variabile compozite sunt fiabile.

2.4.3 Analiza corelațieivariabile independente cu succesul proiectului

Conceptul principal al studiului este de a analiza relația dintre 15 variabile independente (reprezentând factori critici de succes) și 1 variabilă dependentă - succesul proiectului. Unul dintre instrumentele principale este coeficientul de corelație Pearson. Pentru acest studiu, nivelul de semnificație este de 95%. Rezultatele analizei efectuate sunt prezentate în tabel.

Tabelul 6. Corelația variabilelor

Variabil	Coeficientul de corelație Pearson	Semnificaţie
Satisfacția clientului
Interacțiunea cu clienții
Timp de decizie
Locația echipei
Marimea echipei
Cultură corporatistă
Planificare
Control
Competența tehnică a echipei
Caracteristici personale
Comunicare
Contact cu conducerea
Folosind software special
Viziunea conducerii
Înțelegerea rolului

Conform rezultatelor analizei, doar 3 variabile independente au găsit o relație semnificativă statistic cu succesul proiectului: Focus pe satisfacția clienților, Timp de luare a deciziilor, Control. Aceste rezultate sunt în concordanță cu constatările studiului (Misra, Kumar și Kumar, 2009). Cea mai puternică relație cu succesul proiectului.

Alți indicatori nu au găsit o relație semnificativă statistic, ceea ce se poate datora parțial dimensiunii limitate a eșantionului.

2.4.4 Construirea unui model de regresie liniară multiplă

...

Documente similare

Esența și funcțiile sistemului de management al proiectelor corporative (CPMS), elementele sale și cerințele pentru acesta. Metodologii de bază și procese de management de proiect. Descrierea principalelor roluri în contextul CPMS, etapele dezvoltării și implementării acestuia.

lucrare de control, adaugat 13.06.2013


Esența conceptului de „proiect”. Relația metodologiei de management de proiect cu alte discipline de management. Diferența dintre un manager și un proprietar. Surse de succes în leadership. Pârghii de management de proiect. Ciclul de viață și fazele unui proiect de investiții.

prezentare, adaugat 21.11.2011


Utilizarea metodologiei de management de proiect ca mecanism de implementare a investițiilor inovatoare. Sinergia managementului proiectului, programului-țintă și portofoliului. Model de sistem informaţional-analitic pentru conducerea unei instituţii medicale.

lucrare de termen, adăugată 07.07.2015


Analiza tehnologiilor informaţionale existente în domeniul managementului de proiect. Elaborarea unei metodologii de implementare în muncă instituție educațională pachet software de management de proiect Microsoft Projectși evaluarea eficacității utilizării acestuia.

lucrare de termen, adăugată 14.01.2014


Caracteristicile etapelor de dezvoltare a managementului de proiect în Rusia. Conceptul, rolul și relevanța managementului de proiect. Principalele forme de planificare și control al activităților curente ale companiei. Caracteristici ale managementului de proiect în firmele partenere „1C: Francizații”.

lucrare de termen, adăugată 23.10.2015


Conceptul de management de proiect ca parte importantă a funcționării oricărei întreprinderi. Implementarea sisteme de informare. Standarde de management de proiect. Integrarea proiectelor și managementul conținutului. Caracteristici ale managementului timpului și costurilor.

lucrare practica, adaugata 04.07.2015


Managementul proiectelor în conditiile magazinului, caracteristici ale managementului lor în Rusia. Gestionarea eficienței, profitabilității și duratei proiectului. Activitățile oamenilor din proiecte. Factori și reguli pentru obținerea succesului în managementul proiectelor.

lucrare de termen, adăugată 25.03.2008


Conceptul, compoziția și tipurile de proiecte. Etapele managementului de proiect în întreprindere. Caracteristicile organizatorice și economice ale Kazzinctech LLP. Analiza performanței economice a întreprinderii. Principalele probleme în managementul proiectelor și modalități de rezolvare a acestora.

teză, adăugată 22.05.2012


Proiectul și caracteristicile acestuia. Managementul proiectelor ca una dintre sarcinile cele mai complexe și consumatoare de timp ale activităților de management. Tipuri de structuri organizatorice pentru managementul proiectelor. Analiza structurii organizatorice a managementului de proiect in IT Service LLC.

teză, adăugată 18.02.2013


Conceptul și structura sistemului de management al proiectelor corporative. Metode de bază pentru diagnosticarea nivelului de maturitate a managementului de proiect. Inițierea și planificarea, finanțarea proiectelor. Managementul programelor, riscurilor, comunicațiilor și portofoliului întreprinderii.

Oricine s-a ocupat vreodată de managementul proiectelor știe cât de dificil este să organizezi o muncă bine coordonată a unei echipe, iar în fața cerințelor în continuă schimbare pentru rezultatul unui proiect, toate eforturile depuse pot deveni zadarnice. Metoda de management agilă a proiectelor este ideală pentru a lucra cu astfel de proiecte.

Metoda Agile de management de proiect este o serie de etape de lucru definite de termene limită grele - sprinturi, permițând echipei să evalueze constant rezultatele muncii depuse și să primească feedback de la client și de la alți participanți la proiect. Această abordare vă permite să faceți modificări instantanee ale produsului atunci când sosesc noi cerințe.

Istoria Agile

Managementul evolutiv al proiectelor și dezvoltarea de software adaptiv au apărut la începutul anilor 1970. În 1970, dr. Winston Royce a prezentat o lucrare intitulată „Managing the Development of Large sisteme software”, care a criticat dezvoltarea secvențială. El a susținut că software-ul nu ar trebui dezvoltat ca o mașină pe o linie de asamblare în care fiecare piesă este adăugată în faze succesive. În astfel de faze succesive, fiecare fază a proiectului trebuie finalizată înainte ca următoarea fază să poată începe. Dr. Royce a recomandat utilizarea unei abordări pe etape, în care dezvoltatorii colectează mai întâi toate cerințele proiectului, apoi își finalizează întreaga arhitectură și design, apoi scriu tot codul și așa mai departe.

În anii 1990, au fost dezvoltate o serie de metode agile de dezvoltare a software-ului ca răspuns la metodele grele predominante. Acestea includ: din 1991 - RAD (dezvoltare rapidă a aplicațiilor); din 1994 - Metoda de dezvoltare a sistemelor dinamice (DSDM); din 1995 - Scrum; Din 1996, Crystal Clear and Extreme Programming (XP); Și din 1997 - Dezvoltare bazată pe caracteristici (FDD). Deși au apărut înainte de publicarea Agile Software Development Manifesto, ele sunt denumite în mod colectiv Agile Software Development.

În februarie 2001, șaptesprezece dezvoltatori de software s-au întâlnit la Snowbird Resort din Utah pentru a discuta despre tehnici de dezvoltare ușoare. Împreună au publicat Manifestul Agile.

Manifestul Agile

Manifestul Agile constă din 4 idei de bază și 12 principii. Fiecare metodologie Agile aplică aceste idei în mod diferit, dar toate se bazează pe ele pentru a gestiona proiectele cât mai eficient posibil.

4 Idei Agile

1. Oamenii și interacțiunea sunt mai importante decât procesele și instrumentele.
2. Software-ul care funcționează este mai important decât documentația.
3. Colaborarea cu clienții este mai importantă decât negocierea termenilor contractului.
4. Dorința de a face schimbări în prioritate, mai degrabă decât de a rămâne la planul inițial.

12 principii ale Agile

1. Satisfacția clienților prin livrarea timpurie și continuă a software-ului. Clienții sunt mai fericiți când primesc software funcțional la intervale regulate.
2. Modificați cerințele produsului pe parcursul procesului de dezvoltare.
3. Livrare frecventă a software-ului de lucru (în fiecare lună, douăsprezece, săptămânal etc.).
4. Cooperarea între părțile interesate (client și dezvoltatori) pe tot parcursul proiectului.
5. Sprijin, încredere și motivare a persoanelor implicate. Echipele motivate au mai multe șanse să facă cel mai bun lucru decât angajații care sunt nemulțumiți de condițiile de muncă.
6. Interactiune fata in fata. Comunicarea are mai mult succes atunci când echipele de dezvoltare sunt capabile să comunice direct.
7. Software-ul de lucru este principala măsură a progresului. Furnizarea de software funcțional către client este factorul final care măsoară progresul.
8. Menținerea unui ritm constant de lucru. Echipele stabilesc o rată de operare repetabilă și susținută la care pot furniza software funcțional.
9. Atenție la detalii tehnice și design. Abilitățile potrivite și designul bun permit echipei să mențină impulsul, să îmbunătățească continuu produsul și să lucreze la schimbare.
10. Simplitate.
11. Echipele auto-organizate încurajează arhitectura, cerințele și design-urile excelente. Membrii echipei calificați și motivați, care au autoritatea de a lua decizii, comunică în mod regulat cu alți membri ai echipei și fac schimb de idei care vor asigura crearea unui produs de calitate.
12. Adaptare constantă la condițiile în schimbare, ceea ce va contribui la creșterea competitivității produsului pe piață.

Baza metodei Agile

Baza metodei agile de management de proiect este o serie de elemente cheie:

1. Control vizual. Participanții la proiect folosesc carduri de diferite culori și tipuri în timpul lucrului la proiect, care semnalează ce element al produsului final a fost deja dezvoltat, planificat, finalizat etc. Astfel, echipa are o reprezentare vizuală a stării actuale a lucrurilor. Controlul vizual asigură aceeași viziune asupra proiectului de către fiecare dintre participanți.
2. Toți participanții la proiect lucrează cot la cot, inclusiv clientul. Această abordare nu numai că accelerează multe dintre procesele asociate cu informarea participanților grup de lucru dar creează şi o atmosferă favorabilă cooperării şi muncii eficiente.
3. Management adaptabil. Managerul de proiect nu este o persoană care dă instrucțiuni, ci un lider care stabilește regulile de bază ale muncii și cooperării.
4. Colaborare. Echipa, managerul de proiect și clientul lucrează împreună, ceea ce elimină posibilitatea pierderii de informații și neînțelegerea obiectivelor. De asemenea, transparența tuturor proceselor vă permite să eliminați instantaneu problemele emergente și să găsiți soluții și îmbunătățiri de succes.
5. Lucrare bazată pe împărțirea sferei totale a proiectului în părțile sale componente. Acest sistem de lucru reduce semnificativ complexitatea proiectului și permite echipelor să se concentreze pe fiecare parte în mod individual.
6. Lucrați la greșeli. În timpul lucrului unui ciclu, echipa învață noi abilități și analizează erorile care au apărut, ceea ce exclude apariția lor în ciclul următor.
7. Sprinturi și întâlniri zilnice. Sprinturile - perioade de timp în care echipele îndeplinesc o serie de sarcini - vă permit să vedeți clar rezultatele muncii. Împărțind timpul de lucru la proiect în sprinturi, obținem, de exemplu, 10 sprinturi, fiecare timp de două săptămâni. Și întâlnirile zilnice de cel mult 15 minute vor ajuta fiecare membru al echipei să răspundă la trei întrebări: ce am făcut ieri, ce voi face azi, ce mă împiedică să lucrez?

Astfel, introducerea unei metode agile este posibilă în următoarele condiții:

• sensul proiectului este clar indicat,
• clientul este implicat activ pe parcursul proiectului,
• posibila implementare pas cu pas a domeniului total al proiectului,
• rezultatul muncii este mai important decât documentația,
• grupul de lucru nu este mai mare de 7-9 persoane.

În acest moment, metodologia Agile este larg răspândită în domeniul IT și începe să stăpânească zona de business, în special marketing, management, training etc. Metoda agilă de management de proiect este folosită de multe companii și agenții guvernamentale, de exemplu, guvernele din Norvegia și Noua Zeelandă folosesc Agile. În Rusia, Sberbank stăpânește Agile pentru sectorul comercial.

Sisteme de management de proiect bazate pe Agile

Există multe metode bazate pe ideea de Agile, cele mai populare dintre ele sunt Scrum și Kanban.

SCRUM

Scrum este o metodologie de management de proiect care se concentrează pe controlul calității procesului de lucru. Hirotaka Takeuchi și Ikujiro Nonaka, primii care au descris abordarea Scrum, au explicat-o ca fiind „abordarea rugby”, în care scrum luptă pentru minge. Metoda în sine este un proces de dezvoltare împărțit în mici iterații - sprinturi, la sfârșitul cărora utilizatorii primesc o versiune îmbunătățită a software-ului. Sprintul este fixat rigid în timp, iar durata lui este de la 2 până la 4 săptămâni. Munca într-un singur sprint constă în mai multe etape:

1. Planificarea domeniului de lucru pentru un sprint.
2. Întâlniri zilnice de 15 minute pentru a corecta activitatea echipei și a rezuma rezultatele intermediare.
3. Demonstrarea rezultatelor muncii.
4. O retrospectivă de sprint care trece în revistă succesele și eșecurile ultimului sprint.

Scrum este cel mai frecvent utilizat pentru a gestiona dezvoltarea de software și produse complexe folosind metode iterative și incrementale.

Scrum crește foarte mult productivitatea și reduce timpul în avantaj față de procesele clasice „în cascadă”. Procesele Scrum permit organizațiilor să se adapteze fără probleme la cerințele în schimbare rapidă și să creeze un produs care îndeplinește obiectivele de afaceri în schimbare. Scrum vă permite să:

• Îmbunătățirea calității rezultatelor;
• Mai bine să faceți față schimbării;
• Furnizați estimări mai precise, petrecând mai puțin timp pentru a le crea;
• Este mai bine să controlați scenariul proiectului și etapele de lucru.

Kanban

Kanban este un proces conceput pentru a ajuta echipele să lucreze împreună mai eficient. În japoneză, kanban înseamnă „ panou, panou”, iar metoda în sine este preluată și adaptată din sistemul de producție Toyota. Esența Kanban este de a face procesul de dezvoltare cât mai transparent posibil și de a distribui sarcina în mod egal între membrii echipei. Kanban promovează colaborarea continuă și încurajează învățarea și îmbunătățirea activă și continuă.

Kanban se bazează pe trei principii:

1. Vizualizarea sarcinilor: vizibilitatea tuturor informațiilor despre proiect vă va ajuta să vedeți deficiențele, erorile și suprapunerile.
2. Control și limitare WIP (luc în curs): acest lucru ajută la echilibrarea abordării threading, astfel încât echipele să nu înceapă și să lucreze prea mult deodată.
3. Controlați timpul pentru a finaliza sarcina și optimizați munca pentru a economisi timp.

Avantajele și dezavantajele Agile

Orice metodologie are avantaje și dezavantaje. Luați în considerare avantajele și dezavantajele Agile.

Avantaje

1. Mai multă flexibilitate în comparație cu metodologia Waterfall.

Metodologia tradițională a cascadei dictează clar etapele de lucru. Cu metodologia Agile, programul și costul sunt principalii determinanți, iar acesta este un domeniu care se modifică pentru a satisface cerințele clienților și consumatorilor produsului.

2. Mai puține defecte în produsul final.

Acesta este rezultatul controalelor de calitate efectuate la fiecare etapă a lucrării. Procesul continuu de „dezvoltare, construire și testare” reduce, de asemenea, defectele pe măsură ce ciclurile de iterație continuă.

Defecte

1. Primirea constantă a feedback-ului duce la o amânare constantă a datei de finalizare a proiectului.

Datorită feedback-ului instantaneu pe care Agile îl oferă, există pericolul de muncă îndelungată. Utilizatorii finali care văd că aceste cerințe pot fi îndeplinite „ușor” (văd doar rezultatul, nu efortul) vor solicita funcții suplimentare. Dacă managerul de proiect și dezvoltatorii nu pot gestiona așteptările, utilizatorii finali vor continua să ceară mai mult până când întreaga echipă este încărcată cu muncă suplimentară.

2. Documentare

Datorită naturii flexibile a Agile, documentația trebuie să urmeze condițiile de proiect în schimbare rapidă. O solicitare de modificare sau de caracteristică ar putea fi discutată în detaliu și convenită cu utilizatorii finali, dezvoltatorii și testerii, dar dacă echipa nu ar fi informată, un document critic, cum ar fi un manual de utilizare, un document de arhitectură sau un document cu cerințe funcționale, ar deveni învechit.

3. Întâlniri frecvente

În timp ce Agile recomandă ca aceste întâlniri să fie organizate zilnic pentru a-i ține pe toți la curent cu privire la progresul celuilalt, sustenabilitatea acestei practici afectează progresul iterațiilor. Dezvoltatorii sunt concentrați pe ceea ce fac. A-i scoate la o întâlnire care le-ar putea distrage atenția de la a face munca efectivă nu este ceva ce vor accepta cu bucurie.

Implementare Agile

1. Alegerea metodologiei. Există diverse metodologii flexibile care sunt dezvoltate în anumite condiții. Primul pas în lucrul cu Agile este să determinați obiectivele sarcinii de lucru, termenele limită, numărul de angajați și multe altele și să alegeți o astfel de metodologie flexibilă de management de proiect, care să îndeplinească toate cerințele.
2. Instruire. Instruirea este necesară pentru ca angajații să înțeleagă principiile de bază ale Agile și să știe cum să lucreze cu ei. În această etapă sunt identificate capcanele care pot reduce eficiența Agile. Este echipa pregătită pentru schimbare? Sunt proiectele companiei potrivite pentru practici agile? Acestea și multe alte întrebări primesc de obicei răspunsuri de către antrenorii de afaceri Agile. Printre altele, se va întocmi și o listă de training-uri și un plan, conform cărora se va realiza implementarea Agile în companie.
3. Demo agil. Un fel de test drive Agile, care se desfășoară sub supravegherea unui specialist și arată toate etapele de lucru, explică funcțiile rolurilor, interacțiunea în cadrul echipei și între echipe etc.
4. Crearea unei echipe. Pe lângă selecția angajaților, crearea unei echipe include și definirea responsabilităților, repartizarea sarcinilor, crearea unui program de întâlniri etc. Fiecare dintre metode este concepută pentru un anumit număr de oameni din echipă.
5. Selectarea instrumentului necesare pentru distribuirea sarcinilor, raportare, analize și multe altele.
6. Primul proiect cu Agile.În primul proiect vor exista erori, inconsecvențe, respingerea unor instrumente și alegerea altora. Orice tehnică necesită un fel de adaptare la caracteristicile companiei în care este implementată.

Dacă găsiți o eroare, evidențiați o bucată de text și faceți clic Ctrl+Enter.

Nu pierde. Abonați-vă și primiți un link către articol în e-mailul dvs.

Ați fost vreodată implicat în proiecte sau cel puțin ați luat parte la munca de proiect? Dacă da, atunci probabil ați observat că a face echipa să lucreze poate fi destul de dificil. Și chiar dacă se stabilește, există riscul ca toate eforturile să fie în zadar, deoarece cerințele pentru rezultatul dorit se schimbă adesea.

Cu toate acestea, este posibil să simplificați semnificativ munca la proiect și să învățați cum să o gestionați, crescând astfel eficiența echipei, folosind un sistem flexibil de management al proiectelor numit Agile („Agile” sau „Agile”). În general, am vorbit deja pe scurt despre asta în (a patra lecție), dar acum vom vorbi despre acest subiect mai detaliat.

Metoda Agile: Definiție și scurt istoric

Indiferent cât de neobișnuit ar suna, dezvoltarea serioasă a software-ului și a managementului de proiect a început deja în anii 70 ai secolului trecut. În 1970, informaticianul american Winston Royce a scris o lucrare numită „Managing the Development of Large Software Systems”. În ea, el a criticat dezvoltarea secvenţială, subliniind că dezvoltarea de software nu ar trebui să fie ca rularea unei linii de asamblare (cum se face, de exemplu, în fabricarea auto), în care piese noi sunt adăugate una câte una în faze succesive.

În loc să aștepte ca fiecare etapă (fază) să fie finalizată pe rând, Royce a propus o abordare pe fază. Esența sa este că inițial sunt colectate toate cerințele necesare proiectului, după care se finalizează întreaga arhitectură, se creează designul, se scrie codul etc.

Pe baza acestui fapt, în anii 90 a fost posibil să se creeze un set de metode flexibile de dezvoltare a software-ului care pot înlocui metode complexe și consumatoare de timp. S-a întâmplat așa:

• În 1991 a luat naștere metoda de dezvoltare rapidă a aplicațiilor RAD.
• În 1994, a apărut o metodă de dezvoltare a sistemelor dinamice DSDM
• În 1995, a apărut platforma de dezvoltare agilă Scrum (cadru).
• În 1996, a luat naștere metodologia de dezvoltare agilă Crystal Clear, precum și XP Extreme Programming.
• În 1997, a apărut o metodologie iterativă pentru dezvoltarea software-ului FDD

Împreună, aceste metode s-au reunit sub denumirea generală de metode agile de dezvoltare a software-ului.

Patru ani mai târziu, în 2001, șaptesprezece dezvoltatori de software s-au adunat în stațiunea Snowbird din Utah (SUA). Ca urmare a discuției despre metodele de dezvoltare, a fost publicat „Manifestul de dezvoltare a software-ului Agile”. El a stabilit ritmul pentru toate lucrările ulterioare privind crearea de software.

Manifestul Agile

Manifestul, creat de programatori, include 4 idei de bază și 12 principii de management eficient al proiectelor. Oricare dintre sistemele de management de proiect bazate pe Agile (vom vorbi despre sisteme mai târziu) se bazează pe aceste idei și principii, deși le folosește în diferite variante.

1. Oamenii și interacțiunile lor sunt mai importante decât procesele și instrumentele
2. Software-ul care funcționează este mai important decât documentația
3. Clienții și cooperarea cu aceștia sunt mai importante decât un contract și negocierea condițiilor
4. Disponibilitatea de a face schimbări este mai importantă decât planul inițial

Principii agile:

1. Satisfaceți clienții prin livrarea software-ului din timp și în mod constant (clienții sunt mulțumiți când software-ul funcțional sosește regulat și la intervale regulate)
2. Modificați cerințele pentru produsul final pe parcursul ciclului de dezvoltare
3. Livrați software-ul funcțional cât mai des posibil (o dată pe săptămână, la două săptămâni, o lună etc.)
4. Menține colaborarea între dezvoltatori și client pe tot parcursul ciclului de dezvoltare
5. Susține și motivează pe toți cei implicați în proiect (dacă își face treaba mult mai bine decât o echipă ai cărei membri sunt nemulțumiți de condițiile de muncă)
6. Oferă interacțiune directă între dezvoltatori (posibilitatea contactului direct contribuie la o comunicare mai reușită)
7. Măsurați progresul numai prin intermediul software-ului funcțional (clienții ar trebui să primească numai software funcțional și funcțional)
8. Mentine un ritm continuu de lucru (echipa trebuie sa dezvolte un ritm de lucru optim si sustinut)
9. Acordați atenție designului și detaliilor tehnice (datorită abilităților eficiente și design bun echipa de proiect are ocazia de a îmbunătăți constant produsul și de a lucra la îmbunătățirea acestuia)
10. Încercați să faceți fluxul de lucru cât mai simplu posibil, iar software-ul - simplu și ușor de înțeles
11. Permite membrilor echipei (dacă dezvoltatorii pot lua singuri decizii, se organizează și pot comunica cu alți membri ai echipei, schimbând idei cu ei, probabilitatea de a crea un produs de calitate crește semnificativ)
12. Adaptarea constantă la un mediu în schimbare (mulțumită acestui lucru, produsul finit va fi mai competitiv)

În timp ce învățați Agile, pe lângă o prezentare generală a ideilor și regulilor, asigurați-vă că urmăriți acest scurt videoclip, în care Alexey Tachenkov, specialist în management de proiect, consultant și antrenor de afaceri, vorbește despre elementele de bază ale sistemului.

Pentru a pune efectiv în practică ideile și principiile de mai sus, este necesar să se respecte mai multe reguli. Doar atunci poate fi eficient managementul de proiect Agile.

Puncte cheie în aplicarea Agile

Metodologia agilă se bazează în primul rând pe control vizual. Cel mai adesea, participanții la proiect, lucrând la obținerea rezultatelor, folosesc carduri speciale de culoare. O culoare indică finalizarea planificării unui element al produsului final, cealaltă - finalizarea dezvoltării sale, a treia - pregătirea etc. Controlul vizual permite echipei să aibă o reprezentare vizuală a stării curente a procesului și asigură aceeași viziune asupra proiectului de către toți membrii săi.

Membrii echipei și clientul în cele mai multe cazuri lucrează împreună și cot la cot. Datorită acestui fapt, multe procese de lucru care sunt asociate cu informarea participanților la proiect sunt accelerate semnificativ. In afara de asta, lucru in echipa contribuie la crearea unei atmosfere sănătoase pentru o cooperare fructuoasă și eficientă și la obținerea rapidă a rezultatelor.

Atunci când managerul de proiect, echipa și clientul lucrează împreună, nu există pericolul de înțelegere greșită a obiectivelor și pierderea de informații. Toate procesele de lucru devin cât mai transparente posibil, ceea ce înseamnă că orice probleme care apar pot fi rezolvate aproape instantaneu și pot fi găsite cele mai bune opțiuni deciziile lor.

O atenție deosebită trebuie acordată managerului de proiect. Nu poate fi numit un om care dă instrucțiuni în stânga și în dreapta. Liderul acționează aici mai degrabă ca un lider care stabilește direcția și stabilește regulile pentru cooperare și muncă. Cu alte cuvinte, managementul Agile este adaptabil.

O alta punct important Metodologia agilă este împărțirea întregului scop al proiectului în mai multe componente mai mici. Această abordare simplifică foarte mult procesul de dezvoltare, iar grupurile individuale ale echipei se pot concentra fiecare pe sarcina lor specifică.

Lucrând pe un singur ciclu, participanții la proiect stăpânesc noi abilități și dobândesc noi cunoștințe, precum și analizează greșelile făcute în acest proces. Toate acestea reduc probabilitatea de a face astfel de greșeli în viitor (în următoarele cicluri și alte proiecte) la aproape zero.

Și, în sfârșit, ultimul element semnificativ al abordării sunt sprinturile și întâlnirile zilnice. Sprinturile sunt numite limitate de anumite termene limită (deadline) perioade de timp în care echipa reușește să finalizeze anumite sarcini. Datorită sprinturilor, echipa poate vedea rezultatele acțiunilor lor.

Dacă împărțim tot timpul alocat proiectului în mai multe sprinturi, obținem un anumit număr dintre acestea; să fie 15. Fiecare sprint durează, de exemplu, două săptămâni. Asta doar în timpul acestor două săptămâni (timpul alocat sprintului) participanții se întâlnesc în fiecare zi pentru a discuta despre procesul și progresul.

Întâlnirile zilnice nu trebuie să depășească 15 minute. Acestea sunt organizate astfel încât fiecare membru al echipei să-și dea singur răspunsul la trei întrebări:

• Ce am facut ieri?
• Ce voi face azi?
• Ce mă oprește să lucrez?

Răspunsul la aceste întrebări vă permite să mențineți procesul sub control, să înțelegeți în ce stadiu se află fiecare dintre membrii echipei și să eliminați potențialele probleme pe drumul către obiectiv. Pentru a rezuma, implementarea metodologiei Agile este posibilă dacă sunt îndeplinite mai multe condiții:

1. Sensul proiectului este clar indicat
2. Clientul este implicat activ în procesul de implementare
3. Cantitatea totală de lucru se realizează pas cu pas
4. Concentrați-vă pe rezultate specifice
5. Numărul unui grup de lucru: de la 7 la 9 persoane

În prezent, managementul de proiect susținut de Agile este distribuit în mare parte în domeniul IT, cu toate acestea, zonă de afaceriîncepe să-l învețe. Acest sistem este folosit în educație, marketing, afaceri. Managementul agil al proiectelor este adoptat de multe companii și agenții guvernamentale.

Exemple: guvernul Noii Zeelande, guvernul nigerian, norvegian Fond de pensie, Return Path (software), Oreo (producție de cookie-uri), Aviasales (cel mai mare motor de căutare a biletelor de avion), Hewlett-Packard (cea mai mare companie IT americană), Sberbank (probabil știți ce este).

Acestea și multe alte organizații folosesc cel mai mult metode diferite management de proiect bazat pe Agile. Și a vorbi despre aceste metode nu este mai puțin important decât a vorbi despre metodologia în sine.

Metode populare de management de proiect

Există multe metode de management de proiect care sunt folosite de diverse companii moderne. Dar cele mai faimoase și populare dintre ele sunt considerate a fi Scrum (Scrum) și Kanban (Kanban).

Metoda Scrum

Dintre toate metodele sistemului Agile Scrum, acesta diferă prin faptul că pune accent pe controlul calității fluxului de lucru. Specialiștii japonezi în management strategic Hirotaka Takuechi și profesorul de știință și tehnologie Ikujiro Nonaka, care a descris-o pentru prima dată, numesc metoda „abordarea rugby”, în care Scrum este „luptă pentru minge”.

Metoda este ca dezvoltarea proiectului să fie împărțită în sprinturi, după care clientul primește software îmbunătățit. Sprinturile sunt strict fixate în timp și pot dura de la 2 până la 4 săptămâni. Fluxul de lucru într-un singur sprint include mai multe etape:

• Domeniul de activitate este determinat
• În fiecare zi, au loc întâlniri de 15 minute, astfel încât membrii echipei să își poată ajusta munca și să rezume rezultatele intermediare
• Rezultatele sunt prezentate
• Sprinturile sunt discutate pentru a găsi succes și decizii proasteși acțiune

În cele mai multe cazuri, Scrum este folosit pentru a lucra cu software complex și pentru a dezvolta un produs folosind metode incrementale și iterative. Datorită lui, productivitatea echipei este mult crescută și timpul petrecut pe .

Scrum îmbunătățește rezultatele, ajută proiectul să se adapteze la schimbare, oferă estimări mai precise cu mai puțin efort de analiză și vă oferă mai mult control asupra etapelor de lucru și asupra scenariului proiectului. Toate acestea sunt cele mai potrivite pentru obiectivele de afaceri.

Metoda Kanban

Kanban este o altă metodă care face munca în echipă mai eficientă și mai productivă. Semnificația sa se rezumă la a oferi procesului de dezvoltare o transparență maximă și o distribuție uniformă a sarcinii între participanții la proiect. O caracteristică importantă a Kanban este că îi motivează pe oameni să colaboreze, să se îmbunătățească și să învețe constant.

Lucrarea metodei Kanban este construită pe mai multe principii. În primul rând, toate informațiile despre proiect trebuie să fie vizualizate, ceea ce vă permite să vedeți suprapunerile, erorile și deficiențele și să le eliminați în mod activ. În al doilea rând, munca la o sarcină ar trebui să fie efectuată simultan de întreaga echipă - acest lucru ajută la echilibrarea eforturilor și a rezultatelor, elimină distribuția neuniformă a volumului de muncă. Și în al treilea rând, timpul de finalizare a tuturor sarcinilor este strict controlat, ceea ce optimizează procesul și economisește timp.

Spre deosebire de Scrum, Kanban a câștigat popularitate mult mai târziu, dar acest lucru nu îi scade în niciun fel meritele și nu îl face mai puțin eficient. Metoda este utila atat in domeniul IT, cat si in cel al afacerilor.

Acestea sunt doar exemple ale principalelor practici de management de proiect Agile. Dar nu neglijați alte metode precum PRINCE2, Lean, Six Sigma, XP, CCPM, ECM, Waterfall și altele. În plus, Agile, alături de avantaje, are câteva dezavantaje.

Avantaje și dezavantaje ale Agile

Când învățați Agile, este important să fiți conștienți atât de aspectele pozitive, cât și de cele negative ale acestei metodologii. Să începem cu aspectele pozitive.

În primul rând, este de remarcat faptul că managementul Agile este foarte flexibil. Dacă, de exemplu, metodologia tradițională indică anumite etape de lucru, atunci Agile se adaptează cu ușurință la consumatorul produsului final și la cerințele clientului.

De fapt, numărul de defecte ale produsului final este minimizat, deoarece este rezultatul unui control amănunțit al calității, care se efectuează la sfârșitul fiecărei etape de sprint.

În plus, Agile se lansează rapid, răspunde la schimbări și permite echipei de dezvoltare și clienților să rămână în comunicare constantă în timp real. Avantajele sunt evidente, dar haideți să vorbim despre contra.

Deficiențele metodologiei sunt că, în primul rând, feedback-ul constant poate duce la faptul că termenul limită al proiectului va fi amânat tot timpul, creând astfel amenințarea unei lucrări nesfârșite. Dacă clientul vede, de exemplu, doar rezultatele, dar habar nu are despre eforturile necesare pentru a le atinge, va cere constant îmbunătățiri.

Al doilea dezavantaj este nevoia de adaptare la condițiile în schimbare ale proiectului. documentatia proiectului. Dacă echipa nu este informată în mod corespunzător despre modificări sau caracteristici suplimentare, este posibil ca cerințele funcționale sau documentele de arhitectură să nu fie actualizate la ora curentă.

Al treilea dezavantaj semnificativ al Agile este nevoia de întâlniri frecvente. Ele, desigur, ajută la creșterea eficienței muncii, dar totuși, distragerea constantă a atenției membrilor echipei poate afecta negativ procesul, deoarece atenția oamenilor se îndepărtează sistematic de sarcinile în curs de rezolvare.

Aceasta include și lucruri precum nevoia de prezență constantă a clientului, incapacitatea de a construi planuri pe termen lung și nevoia de specialiști motivați și de înaltă calificare. Apropo, acesta din urmă se aplică în mare măsură implementării managementului Agile în activitățile organizației. Și, înțelegând Agile, trebuie să vă familiarizați și cu subiectul implementării acestuia.

Implementare Agile

Există destul de multe exemple de implementare a Agile în munca companiilor. Și aproape toți spun că necesită o serie întreagă de măsuri importante.

Pentru început, este selectată o metodă specifică, care depinde de condițiile proiectului. Apoi sunt determinate sarcinile și obiectivele, termenul limită principal și datele de sprint, dimensiunea echipei și alte componente ale lucrării la proiect. Este important să alegeți o metodă care să îndeplinească numărul maxim de cerințe.

După cum am spus, implementarea Agile necesită o echipă de profesioniști. Toți membrii săi trebuie să cunoască ideile și principiile de bază ale metodologiei și să le poată aplica. Dacă compania nu are astfel de oameni, angajații trebuie să fie instruiți. De asemenea, conducerea unei companii care a decis să treacă la Agile trebuie să înțeleagă clar dacă organizația este pregătită pentru schimbare, dacă sistemul poate fi aplicat proiectelor sale etc. Cel mai adesea, pentru a răspunde la aceste întrebări, trebuie să apelezi la specialiști Agile.

În etapa următoare, este invitată o persoană cu experiență în lucrul cu sistemul. O demonstrează, explică esența sprinturilor și acțiunilor, funcțiile membrilor viitoarei echipe, caracteristicile interacțiunii dintre ei și alte probleme. Și numai după aceea se formează o nouă echipă, se atribuie roluri, sarcini și responsabilități, se selectează instrumente de analiză, raportare etc.

Etapa finală va fi prima experiență cu Agile, adică. primul proiect care îl folosește. Trebuie să înțelegeți că greșelile, neajunsurile, inconsecvențele și întârzierile sunt inevitabile. Va trebui să abandonăm unele instrumente și să le înlocuim cu altele, poate schimbând rolurile între oamenii din echipă. Prima experiență este un proces de adaptare, iar adaptarea este bidirecțională: compania se obișnuiește cu metodologia, iar metodologia se adaptează companiei.

Concluzie

Rezumând această recenzie Amintiți-vă că teoria și practica sunt două lucruri diferite. Noile metode și tehnologii și implementarea lor reprezintă un fel de provocare pentru echipă, iar modul de a obține o eficiență mai mare este întotdeauna o chestiune individuală. Agile nu este un panaceu sau o garanție a succesului, dar vă permite să vă setați curs corectși găsiți repere pe parcurs.

Pentru a implementa orice proiect, cu siguranta va trebui sa schimbi ceva, sa cauti solutii noi,. Doar prin adaptarea la condițiile de lucru în continuă schimbare și la cerințele clienților se poate găsi cursul corect de acțiune. Iar metodologia flexibilă de management de proiect Agile poate deveni un asistent fidel în această problemă.

„Din toate dificultățile cu care s-a confruntat NASA pentru a pune un om pe Lună, controlul a fost probabil cea mai dificilă sarcină”

— Roger Launis, istoric NASA

De-a lungul istoriei, omenirea a acumulat o listă impresionantă de implementate cu succes proiecte complexe. De la construirea Piramidelor de la Giza până la trimiterea unui om pe Lună, cele mai îndrăznețe activități umane au necesitat munca coordonată a mii de oameni. Și asta implică un sistem complex de management al proiectelor.

Și deși doar câțiva dintre noi se vor confrunta cu sarcini de această amploare, majoritatea cititorilor acestui blog vor experimenta gestionarea proiectelor într-un fel sau altul. Până în 2020, se estimează că PMI vor fi acolo - și mulți alți profesioniști trebuie adesea să gestioneze mini-proiecte, cel puțin la nivel personal.

vorbind în cuvinte simple Managementul proiectelor înseamnă gestionarea și organizarea a tot ceea ce este necesar pentru atingerea unui obiectiv – la timp și în limita bugetului, desigur. Fie că este vorba despre dezvoltarea de noi software, derularea unei campanii de marketing sau aterizarea unui om pe Marte, managementul de proiect face posibilă reușita.

Toate proiectele sunt diferite. Nu există un sistem perfect de management de proiect pentru fiecare tip de proiect. De asemenea, nu există un sistem care să se potrivească fiecărui lider și să fie convenabil pentru toți membrii echipei. Cu toate acestea, în timpul existenței managementului de proiect, au fost create multe abordări, metode și standarde eficiente care pot fi adoptate. Vom vorbi astăzi despre cele mai populare dintre ele.

Abordările dezvoltate sunt foarte diferite unele de altele. Ele diferă în domeniul de aplicare, detaliu, autosuficiență și formalizare. În titlu, le-am numit „metode” pentru comoditate, dar, de fapt, articolul prezintă standardele, conceptele, metodele și cadrele care sunt utilizate în managementul proiectelor. Scopul acestui articol este de a oferi cea mai largă privire de ansamblu asupra abordărilor existente în managementul proiectelor.

În acest articol, ne vom uita la:

• Managementul clasic de proiect
• Agil
• Scrum
• A se sprijini
• Kanban
• ŞaseSigma
• PRIȚUL 2

Și înainte de a ne uita la metode specifice, să răspundem la întrebarea evidentă - „De ce avem nevoie de sisteme și metode de management de proiect?”- să luăm în considerare, desigur, pe scurt, istoria managementului de proiect și să definim termenii de bază ai managementului de proiect.

De ce „management de proiect”?

Numele lui Neil Armstrong și Buzz Aldrin vor rămâne pentru totdeauna în istorie ca simboluri ale uneia dintre cele mai mari realizări ale omenirii - aterizarea unui om pe Lună. Cu toate acestea, principalii contribuitori la acest eveniment au fost cei 400.000 de angajați ai NASA și cele 20.000 de companii și universități care au lucrat împreună la misiunea Apollo.

În 1961, John F. Kennedy a stabilit sarcina de a ateriza un om pe un satelit al Pământului și de a-l întoarce înapoi - în ciuda faptului că la acel moment NASA a trimis un om în spațiu pentru doar 15 minute. Un astfel de obiectiv ambițios a necesitat o cantitate incredibilă de resurse, cooperare, inovare și planificare.

După cum afirmă cartea NASA Managing the Moon Program, principala problemă nu a fost „ ce să fac?", și în asta, " cum să faci atât de multe într-un timp atât de scurt? Potrivit dr. Max Faget, șef de inginerie la Centrul Spațial Lyndon Johnson (Centrul spațial Lyndon B. Johnson, JSC), atunci NASA nu avea idee cum să pună toate acțiunile necesare în 10 ani. Așa că primul pas a fost să „descompune proiectul în pași gestionați”.

Apoi a fost important să grăbim execuția fiecărei etape individuale și să ne asigurăm că echipele și companiile care lucrează în fiecare fază comunică eficient între ele și oferă rezultate la timp. Această sarcină a fost încredințată doctorului George E. Muller, care a gestionat fiecare parte a proiectului Apollo, de la Casa Albă până la furnizorul celei mai mici părți. Pentru a facilita controlul proiectului, a decis să împartă proiectul în 5 domenii: Controlul programelor, Ingineria sistemelor, Testare, Fiabilitate și calitate și Operațiuni de zbor. Schema de control pentru programul Apollo este prezentată în figura 1.

Acest sistem în 5 etape – numit „Etapele GEM” după inițialele Dr. Muller – a fost conceput „pentru a se concentra pe testarea produsului și pe dezvoltarea acestuia cu cunoștințele că va fi testat”, potrivit lui Muller însuși. Controlul programului a determinat ceea ce trebuia făcut, a gestionat bugetul și cerințele și a gestionat relația dintre elementele programului. Ingineria sistemelor a fost responsabilă pentru dezvoltarea de noi dispozitive și ansambluri, Testarea a fost responsabilă pentru a se asigura că aceste elemente noi funcționează, Fiabilitatea și calitatea au verificat elementele dezvoltate pentru conformitatea cu cerințele și standardele, iar Operațiunile de zbor a fost responsabilă pentru a se asigura că aceste noduri vor funcționa. în timpul zborului.

Mulți au fost inițial sceptici față de metoda lui Muller, dar el a reușit în cele din urmă să-i convingă pe membrii programului de necesitatea de a urma acest algoritm. Acest sistem și-a arătat eficiența - proiectul a fost finalizat cu succes și, s-ar putea spune chiar, triumfător, înainte de termenele stabilite. Acest lucru a fost posibil doar prin împărțirea unui proiect la scară largă în pași gestionați și repetați, permițând multor companii și profesioniști să lucreze în același ritm. Așa și-a dovedit managementul de proiect eficiența în cursa spațială.

O scurtă istorie a managementului de proiect

Managementul proiectelor nu a fost inventat de NASA și dr. Muller. Piramidele Egiptuluiși Marele Zid Chinezesc sunt produse ale managementului de proiect din timpuri preistorice. Din păcate, nu există dovezi documentare cu privire la modul în care s-a desfășurat implementarea și managementul acestor proiecte, iar managementul actual al proiectelor este divorțat de cunoștințele secolelor trecute.

Cel mai evident mod de a implementa un proiect este de a-l împărți în faze sau sarcini individuale. Ca o rețetă, cumperi ingredientele, le amesteci corect, le gătești și le servești. Cel mai simplu instrument de management de proiect este o listă de verificare a acțiunilor care trebuie întreprinse pentru a atinge obiectivul. Simplu și eficient.

Cu toate acestea, dacă sunteți bucătar și pregătiți mai multe feluri de mâncare, dar mai multe, de exemplu, o salată (care constă din 3 etape) și un desert (care trebuie doar servit), atunci veți avea nevoie de un instrument care vă permite să urmăriți timpul petrecut pentru fiecare dintre ele.articole și când ar trebui să fie gata. Și iată că unul dintre primii vine în ajutor instrumente moderne management de proiect: diagrama Gantt prezentată pe Figura 2.

Inventat independent de K despreÎn rolul lui Korol Adamecki și Henry L. Gantt la începutul secolului al XX-lea, diagrama Gantt arată programul proiectului pe baza termenelor limită și a termenelor limită pentru sarcini. Sarcinile, duratele și relațiile lor sunt introduse în el, iar apoi se calculează calea critică - cel mai lung lanț de sarcini interconectate care determină durata proiectului. Relațiile dintre începutul și sfârșitul diferitelor sarcini sunt foarte importante - nu poți servi supă oaspeților tăi până nu ai gătit-o, nu?

Așadar, un proiect tipic este foarte asemănător cu un proiect de gătit și servit cină, doar că are mult mai multe sarcini, relații, termene limită și tipuri de resurse. Pentru proiectele cu termene limită strânse, diagrama Gantt vă ajută să decideți când este mai bine să începeți anumite sarcini pentru a reduce timpul de implementare. Și pentru proiectele cu constrângeri puternice de resurse, diagrama Gantt oferă o oportunitate de a construi o schemă sub forma unui lanț de proces bazat pe evenimente pentru planificarea resurselor.

Proiectele diferite necesită niveluri diferite de control. De exemplu, dacă publicați o serie de articole în , termenele limită strânse nu sunt atât de importante. Mult mai important este un proces clar în care este posibil să structurați fiecare articol, să schițați fiecare dintre ele, să obțineți feedback, să faceți editări, să finalizați articolul, să corectați și să publicați. În loc să gestionezi timpul și resursele, tu gestionezi procesul.

Metodele agile de management al proiectelor și abordările asociate, cum ar fi Lean, Kanban și altele, sunt mai potrivite pentru astfel de proiecte. Există și metode care vă permit să gestionați atât fluxul de lucru, cât și timpul și resursele - 6 Sigma și Scrum.

Sisteme populare de management de proiect

De-a lungul istoriei managementului de proiect, au fost create multe metode diferite de management de proiect pentru aproape orice nevoie. Chiar dacă nu ai de gând să trimiți un bărbat pe Lună și nu ai o cantitate similară de resurse, vei găsi totuși instrumentul potrivit pentru tine. Principalul lucru este să înțelegeți ce este cel mai important pentru proiectul dvs. - termenele limită, resursele, aderarea la proces sau mai mulți factori simultan - și apoi alegeți o metodă de management de proiect axată pe atingerea acestui indicator.

Înainte de a începe să ne uităm la cele mai populare metode, să definim câțiva termeni cheie.

Termenii de bază ai managementului de proiect

Agil O abordare flexibilă iterativ-incrementală a managementului proiectelor și produselor, axată pe formarea dinamică a cerințelor și asigurarea implementării acestora ca urmare a interacțiunii constante în cadrul unor grupuri de lucru auto-organizate formate din specialiști din diverse domenii. Există multe metode bazate pe ideile Agile, dintre care cele mai populare sunt Scrum și Kanban.

Traiectorie critică: O secvență continuă de activități și evenimente de la început până la sfârșit, care durează cel mai mult timp pentru a fi finalizate.

Lanțul de procese de evenimente (diagrama EPC): o diagramă care arată secvența implementării activității proiectului în funcție de disponibilitatea și volumul de muncă al resurselor

Rezerva de timp: Perioada de timp în care începerea lucrărilor poate fi amânată fără a afecta durata totală a proiectului. Astfel, slăbirea activităților pe calea critică va fi zero.

reper (punct de control,reper): Un eveniment cheie care marchează, de exemplu, sfârșitul unei etape. În diagrama Gantt, este notat cu o sarcină cu durată zero.

Manager de proiect (lider de proiect,proiectadministrator,P.M ): Seful echipei de proiect responsabil cu managementul proiectului (planificarea, implementarea si inchiderea proiectului).

Resurse: Elemente necesare implementarii proiectului. Resursele sunt timpul, echipamentele, materialele, angajații și așa mai departe.

Sprint (Sprint): Iterație (ciclu de lucru) în Scrum, cu durata de la o săptămână la o lună, timp în care se creează o versiune de lucru a produsului sau a elementului acestuia care este de valoare pentru client.

Management de proiect „clasic” sau „tradițional”: Cea mai folosită metodă de management al proiectelor, bazată pe așa-numita „Cascada” (Waterfall) sau ciclul în cascadă, în care sarcina este transferată secvenţial prin etape, asemănător unui flux.

Managementul clasic de proiect

Cel mai evident mod de a vă face proiectul mai ușor de gestionat este de a-l împărți în pași succesivi. Este pe asa structura liniara bazat pe managementul de proiect tradițional. În acest sens, seamănă cu un joc pe calculator - nu poți trece la nivelul următor fără a-l finaliza pe cel anterior. Diagrama fluxului de lucru este prezentată în Figura 3.

Această abordare este axată pe proiecte în care există restricții stricte asupra succesiunii sarcinilor. De exemplu, construirea unei case - nu puteți construi pereți fără fundație.

De obicei, există 5 etape ale managementului de proiect clasic, dar pot fi adăugate etape suplimentare dacă proiectul o cere.

5 etape ale managementului tradițional:

Etapa 1. Inițiere. Managerul de proiect și echipa definesc cerințele pentru proiect. În această etapă, se organizează adesea întâlniri și sesiuni de brainstorming, la care se stabilește care ar trebui să fie produsul proiectului.

Etapa 2. Planificare.În această etapă, echipa decide cum va atinge obiectivul stabilit în etapa anterioară. În această etapă, echipa rafinează și detaliază obiectivele și rezultatele proiectului, precum și domeniul de activitate pentru acesta. Pe baza acestor informații, echipa creează un program și un buget, evaluează riscurile și identifică părțile interesate.

Etapa 3. Dezvoltare. Această etapă nu este implementată pentru toate proiectele - de regulă, face parte din faza de planificare. În faza de dezvoltare se determină caracteristicile proiectelor tehnologice, configurația viitorului proiect și/sau produs și mijloacele tehnice de realizare a acestuia. De exemplu, în proiectele IT, în această etapă se alege un limbaj de programare. ( În practica casnică, de obicei, această fază nu se distinge, iar termenul „dezvoltare” nu este folosit - cca. traducere)

Etapa 4. Implementare și testare.În această fază, are loc de fapt activitatea principală a proiectului - scrierea codului, ridicarea unei clădiri și altele asemenea. În urma planurilor elaborate, începe să se creeze conținutul proiectului, definit anterior, se efectuează controlul în funcție de metricile selectate. În a doua parte a acestei faze, produsul este testat, se verifică conformitatea cu cerințele Clientului și părților interesate. În ceea ce privește testarea, deficiențele produsului sunt identificate și corectate.

Etapa 5. Monitorizarea și finalizarea proiectului.În funcție de proiect, această fază poate consta într-un simplu transfer al rezultatelor proiectului către Client, sau într-un proces îndelungat de interacțiune cu clienții pentru a îmbunătăți proiectul și a crește satisfacția acestora și pentru a susține rezultatele proiectului. Acesta din urmă se referă la proiecte din domeniul customer service și software.

Ceea ce este descris mai sus este baza pe care sunt construite diverse metode de management de proiect. Diferite proiecte necesită diferite faze de implementare – unele necesită trei faze, altele mult mai multe. Uneori se folosește așa-numita „cascada iterativă”, în care fiecare etapă este un fel de subproiect, în timpul căruia sarcinile sunt implementate în iterații fixe. Dar esența rămâne aceeași - proiectul este împărțit în etape care sunt executate într-o secvență strict definită.

Datorită faptului că managementul clasic de proiect este strict legat de timpul de execuție al sarcinilor, de regulă, predeterminat în etapa de planificare, instrumentele sunt excelente pentru implementarea proiectelor în cadrul acestei abordări. calendar-planificarea rețelei. Cel mai comun instrument de programare este diagrama Gantt menționată anterior. Există multe instrumente pentru a-l crea, de la simple foi de calcul precum Excel și Smartsheet până la pachete software profesionale precum Microsoft Project și Primavera.

Punctele forte ale clasicului management de proiect

Astăzi, se spune adesea că abordarea clasică a cascadei este depășită, dar nici nu se gândește să piardă teren. Marele avantaj al acestei abordări este că impune clienților și conducerii companiei să stabilească ce vor să primească deja în prima etapă a proiectului. Includerea timpurie aduce o anumită stabilitate activității proiectului, iar planificarea vă permite să eficientizați implementarea proiectului. În plus, această abordare presupune monitorizarea indicatorilor și testarea, ceea ce este absolut necesar pentru proiecte reale de diferite dimensiuni.

Potenţial, abordarea clasică evită stresul datorită prezenţei timpului liber în fiecare etapă, prevăzut în cazul oricăror complicaţii şi implementarea riscurilor. În plus, cu o etapă de planificare desfășurată corespunzător, managerul de proiect știe întotdeauna ce resurse are. Chiar dacă această estimare nu este întotdeauna exactă.

Punctele slabe ale managementului clasic de proiect

Principala slăbiciune a managementului clasic de proiect este intoleranța la schimbare. Conducerea Toyota, renumită pentru crearea de sisteme precum Lean și Kanban, este adesea criticată pentru că a adoptat o abordare clasică în dezvoltarea de software pentru compania lor și tocmai pentru lipsa de flexibilitate.

Pilonul abordării clasice îl reprezintă acum proiectele de construcții și inginerie, în care conținutul proiectului rămâne practic neschimbat pe parcursul întregului proiect. Dar dacă resursele și timpul nu sunt constrângeri cheie în proiectul dvs., iar domeniul de aplicare al proiectului este supus modificării, poate fi necesar să vă uitați la alte sisteme de management de proiect.

Agil

După cum sa menționat mai devreme, nu toate proiectele pot fi structurate astfel încât să fie implementate conform abordării clasice a proiectelor. Revenind la exemplul nostru de bucătar, gătirea unui fel de mâncare este perfectă pentru o abordare în cascadă, dar pregătirea și servirea unei cine cu patru feluri la timp ar fi aproape imposibilă dacă ar trebui să așteptați de fiecare dată ca un fel de mâncare să se termine de gătit înainte de a începe altul.

Și aici intervine Agile - o familie de metode iterative-incrementale flexibile pentru gestionarea proiectelor și produselor. Conform acestei abordări, proiectul nu este împărțit în faze succesive, ci în mici subproiecte, care sunt apoi „asamblate” într-un produs finit. Schema de lucru este afișată pe Figura 5.

Astfel, se realizează inițierea și planificarea la nivel superior pentru întregul proiect, iar etapele ulterioare: dezvoltare, testare și altele sunt realizate pentru fiecare mini-proiect separat. Acest lucru vă permite să transferați mai rapid rezultatele acestor mini-proiecte, așa-numitele incremente, iar atunci când începeți un nou sub-proiect (iterație), puteți face modificări fără costuri mari și fără impact asupra restului proiectului. .

În ciuda faptului că Agile a intrat în vogă relativ recent, ideea dezvoltării iterative nu este nouă. (despre istoria aparițieiAgile poate fi citit - aprox. per.). Familia de metodologii agile și-a primit numele actual în 2001 odată cu publicarea Agile Manifesto (Agile Manifesto), care a consolidat valorile și principiile de bază ale dezvoltării agile de software, care se bazează pe munca în echipă și adaptare, chiar „dragoste” pentru Schimbare.

Agile în sine nu este o metodă de management de proiect. Este mai degrabă un set de idei și principii despre cum ar trebui implementate proiectele. Deja pe baza acestor principii și bune practici au fost dezvoltate metode flexibile separate sau, așa cum sunt numite uneori, cadre: Scrum, Kanban, Crystal și multe altele. Aceste metode pot fi destul de diferite unele de altele, dar urmează aceleași principii.

Puncte forteAgil

Cel mai important avantaj al Agile este flexibilitatea și adaptabilitatea sa. Se poate adapta la aproape orice condiții și procese ale organizației. Acesta este ceea ce determină popularitatea sa actuală și câte sisteme pentru diferite zone au fost create pe baza acestuia.

Unul dintre principiile Agile este: „Răspunsul la schimbare este mai important decât respectarea unui plan.” Reacția rapidă și relativ nedureroasă la schimbare este motivul pentru care multe companii mari se străduiesc să își flexibilizeze procesele. În plus, Agile este excelent pentru proiecte deschise, cum ar fi pornirea unui serviciu sau a unui blog.

Domeniul Agile este dezvoltarea de noi, produse inovatoare. În proiectele de dezvoltare a unor astfel de produse, există un grad ridicat de incertitudine, iar informațiile despre produs sunt dezvăluite pe parcursul proiectului. În astfel de condiții, devine imposibilă implementarea proiectului pe „cascada” - nu există informații pentru planificare.

Părțile slabeAgil

Spre deosebire de PRINCE2 și PMBOK, Agile nu este nici o metodologie, nici un standard. Agile este un set de principii și valori. Partea slabă este că fiecare echipă va trebui să-și compună în mod independent propriul sistem de management, ghidat de principiile Agile. Acesta este un proces complex și îndelungat, care va necesita schimbări în întreaga organizație, de la proceduri la valorile de bază. aceasta potecă spinoasăși nu toate organizațiile o pot face.

Această cale va necesita de la liderul schimbării nu numai cunoștințe și perseverență, ci și resurse administrative serioase, precum și costuri. Din fericire, există seturi gata făcute de practici care facilitează transformarea Agile unei organizații. Aceste seturi includ cadrul Scrum, metoda Kanban și multe altele - Crystal, LeSS, SAFe, Nexus.

Scrum

Cadrul Agile, creat în 1986, este considerat cel mai structurat din familia Agile. Creat în 1986, combină elemente ale procesului clasic și ideile unei abordări agile a managementului de proiect. Rezultatul este o combinație foarte echilibrată de flexibilitate și structură.

Urmând preceptele Agile, Scrum descompune proiectul în părți care pot fi folosite imediat de către Client pentru a obține valoare, numite backlog de produse. Și în ciuda faptului că „întârziere de produs” este o traducere destul de precisă și este folosită în literatura profesională, în practica rusă, pur și simplu „întârziere” este folosit cel mai des. Apoi aceste părți sunt prioritizate de Product Owner - reprezentantul Clientului în echipă. Cele mai importante „piese” sunt primele care sunt selectate pentru execuție în Sprint – așa-numitele iterații în Scrum, cu o durată de la 2 la 4 săptămâni. La finalul Sprintului, Clientului i se prezintă un increment de produs de lucru - cele mai importante „piese” care pot fi deja folosite. De exemplu, un site cu o parte din funcționalitate sau un program care funcționează deja, deși parțial. După aceea, echipa de proiect trece la următorul Sprint. Durata Sprintului este fixă, dar echipa o alege independent la începutul proiectului, pe baza proiectului și a propriei performanțe.

Pentru a ne asigura că proiectul îndeplinește cerințele Clientului, care tind să se modifice în timp, înainte de începerea fiecărui Sprint, sfera proiectului care nu a fost încă finalizată este reevaluată și i se fac modificări. Toată lumea este implicată în acest proces - echipa de proiect, Scrum Master (Scrum Master, lider de echipă de proiect) și Product Owner. Și toată lumea este responsabilă pentru acest proces.

După cum sa menționat deja, Product Owner este reprezentantul Clientului în proiect, sau personifică toți clienții viitorului proiect, dacă Clientul nu este prezent. Pentru a face acest lucru, el trebuie să cunoască temeinic nevoile și modul lor de gândire, precum și să înțeleagă produsul și tehnologia de fabricație a acestuia. Scrum Master este conceput pentru a ajuta participanții la proiect să înțeleagă și să accepte mai bine valorile, principiile și normele practicii Scrum. El este liderul și mediatorul între lumea de afara si echipa. Sarcina lui este să se asigure că nimeni nu intervine singur cu echipa și să lucreze confortabil la sarcini. Echipa este responsabilă să se asigure că la sfârșitul sprintului toate sarcinile necesare sunt îndeplinite și livrările sunt finalizate.

Structura de bază a proceselor Scrum se învârte în jurul a 5 întâlniri principale: Backlog Sequencing, Sprint Planning, Daily Meetings, Sprint Debriefing și Sprint Retrospective.

Pentru mulți, Scrum poate părea dificil de implementat - un nou proces, noi roluri, multă delegare și o structură organizațională complet nouă. Dar este o abordare flexibilă, dar structurată a livrării proiectelor, care, spre deosebire de principiile vagi și generale ale Agile, nu va permite ca lucrurile să meargă prost.

Puncte forteScrum

Scrum a fost conceput pentru proiecte care necesită „câștiguri rapide” combinate cu o toleranță la schimbare. În plus, acest cadru este potrivit pentru situațiile în care nu toți membrii echipei au suficientă experiență în domeniul în care se implementează proiectul - comunicarea constantă între membrii echipei permite lipsa de experiență sau de calificare a unor angajați datorită informațiilor și ajutorului colegilor. .

Canalul de televiziune online Netflix este un exemplu excelent de livrare rapidă a rezultatelor. Site-ul de resurse este actualizat la fiecare două săptămâni datorită Scrum, care nu numai că vă permite să lucrați cu de mare viteză, dar acumulează și experiența utilizatorului și face posibilă identificarea celui mai important lucru pentru clienți.

În timpul fiecărei iterații, dezvoltatorii adaugă și testează noi funcții ale site-ului și le elimină pe cele care nu au fost folosite de clienți. Potrivit echipei Netflix, principalul avantaj al Scrum este că îți permite să „eșuezi rapid”. În loc de o lansare majoră lungă și costisitoare, livrările de scrum sunt de dimensiuni mici. Sunt ușor de urmărit și, dacă ceva nu merge bine, remediați rapid.

Părțile slabeScrum

Scrum este foarte solicitant cu echipa de proiect. Ar trebui să fie mic (5-9 persoane) și interfuncțională - adică membrii echipei ar trebui să aibă mai mult de o competență necesară pentru implementarea proiectului. De exemplu, un dezvoltator de software trebuie să aibă cunoștințe de testare și business intelligence. Acest lucru se face astfel încât o parte din echipă să nu „lege” pentru diferite etape proiect, precum și pentru ca angajații să se poată ajuta și înlocui reciproc.

În plus, membrii echipei trebuie să fie „jucători de echipă”, să își asume în mod activ responsabilitatea și să fie capabili să se organizeze. Găsirea unei echipe atât de mature este foarte dificilă!

Scrum nu este potrivit pentru toate echipele și organizațiile, de asemenea, deoarece procesul propus poate să nu fie potrivit pentru dezvoltarea unui anumit produs - de exemplu, o mașină industrială sau construirea unei clădiri.

A se sprijini

Agile ne spune ce să împărțim în pachete mici, ușor de gestionat, dar nu spune nimic despre cum să gestionăm dezvoltarea acestui pachet. Scrum ne oferă procesele și procedurile sale. Lean, la rândul său, adaugă o schemă de flux de lucru la principiile Agile, astfel încât fiecare dintre iterații să fie efectuată cu aceeași calitate.

În Lean, la fel ca în Scrum, munca este împărțită în pachete mici de livrare care sunt implementate separat și independent. Dar în Lean, pentru dezvoltarea fiecărui pachet de livrare, există un flux de lucru cu pași similari cu cei creați pentru proiectul Apollo. Ca și în managementul de proiect clasic, acestea pot fi etapele de planificare, dezvoltare, producție, testare și livrare - sau orice alte etape necesare implementării calitative a proiectelor.

Etapele Lean și flexibilitatea lor vă permit să fiți sigur că fiecare parte a proiectului este implementată așa cum este necesar. Lean nu are limite clare de etapă, așa cum face Scrum cu limitele de Sprint. În plus, spre deosebire de managementul clasic de proiect, Lean vă permite să efectuați mai multe sarcini în paralel în diferite etape, ceea ce crește flexibilitatea și crește viteza de execuție a proiectului.

La fel ca Agile, Lean este mai degrabă un concept, un mod de a gândi decât ceva pus în piatră. Folosind ideile Lean, puteți crea în mod independent un sistem care să corespundă cerințelor dumneavoastră în managementul proiectelor.

Puncte forteA se sprijini

Dacă vă plac ideile Agile, dar proiectul necesită o calitate foarte bună și o execuție precisă, Lean oferă un set de instrumente pentru a îndeplini aceste cerințe. Lean combină flexibilitatea și structura precum Scrum, dar într-un mod ușor diferit.

Părțile slabeA se sprijini

Nu fiecare parte a proiectului necesită același studiu și atenție detaliat și meticulos. Dar Lean își asumă exact această abordare pentru fiecare sarcină și etapă. Acesta este principalul dezavantaj al utilizării Lean pentru proiecte mari și eterogene.

De asemenea, spre deosebire de Scrum, Lean nu oferă un flux de lucru clar pentru implementarea „pieselor” din proiect, ceea ce contribuie la extinderea cronologiei proiectului. Această problemă poate fi rezolvată cu un leadership eficient și o comunicare clară ̶ principalul lucru de reținut este acesta.

Kanban

Lean pare puțin abstract de la sine, dar atunci când este combinat cu Kanban, devine mult mai ușor să îl utilizați pentru a vă construi propriul sistem de management al proiectelor. Creat de inginerul Toyota Taiichi Ono în 1953, Kanban este foarte asemănător cu producția industrială. La intrarea in acest proces intra o bucata de metal, iar piesa finita se obtine la iesire. Tot în Kanban, incrementul de produs este transmis înainte de la etapă la etapă, iar la final, se obține un articol gata de livrare.

În plus, creatorul Kanban s-a inspirat din supermarketuri, și anume principiul lor - „păstrați pe rafturi doar ceea ce are nevoie clientul”. Prin urmare, Kanban vă permite să lăsați o sarcină neterminată într-una dintre etape dacă prioritatea acesteia s-a schimbat și există alte sarcini urgente. O postare de blog needitată, suspendarea fără o dată de publicare sau o bucată de cod pentru o caracteristică care ar putea să nu fie inclusă în produs sunt toate normale pentru lucrul Kanban.

Kanban este mult mai puțin strict decât Scrum - nu limitează timpul de sprint, nu există roluri, cu excepția proprietarului produsului. Kanban chiar permite unui membru al echipei să facă mai multe sarcini, ceea ce Scrum nu permite. De asemenea, ședințele privind stadiul proiectului nu sunt reglementate în niciun fel - poți să o faci așa cum vrei, sau nu o poți face deloc.

Pentru a lucra cu Kanban, trebuie să definiți pașii fluxului de lucru. În Kanban, acestea sunt afișate ca coloane, iar sarcinile reprezintă carduri speciale. Cardul trece prin etape, ca o piesă dintr-o fabrică care se deplasează de la mașină la mașină, iar la fiecare etapă procentul de finalizare este mai mare. Ca rezultat, obținem un element de produs gata pentru livrare către client. O tablă cu coloane și carduri poate fi atât reală, cât și electronică - chiar și aici Kanban nu impune nicio restricție utilizatorilor.

Propriul sistem Kanban poate fi atât de flexibil pe cât doriți, deoarece în multe privințe Kanban este o vizualizare a ideii Agile. Dar Kanban are 4 piloni pe care se sprijină întregul sistem:

1. Carduri: Pentru fiecare sarcină, este creat un card individual, în care sunt introduse toate informațiile necesare despre sarcină. Astfel, toate informațiile necesare despre sarcină sunt întotdeauna la îndemână.
2. Limitarea numărului de sarcini pe etapă: Numărul de carduri într-o etapă este strict reglementat. Datorită acestui fapt, devine imediat clar când apare o „congestie” în fluxul de lucru, care este eliminată prompt.
3. Flux continuu: Sarcinile din restanță intră în flux în ordinea priorității. Deci munca nu se oprește niciodată.
4. Îmbunătățirea continuă (kaizen)kaizen)): Conceptul de îmbunătățire continuă a apărut în Japonia la sfârșitul secolului al XX-lea. Esența sa este analiza constantă a procesului de producție și căutarea modalităților de îmbunătățire a productivității.

Puncte forteKanban

La fel ca Scrum, Kanban este potrivit pentru echipe destul de strânse, cu o bună comunicare. Dar, spre deosebire de Scrum, Kanban nu are termene limită stricte, ceea ce este bun pentru echipele foarte motivate și experimentate.

La setare corectăși management, Kanban poate fi de mare beneficiu pentru echipa de proiect. Calculul precis al sarcinii pentru echipă, plasarea corectă a restricțiilor și concentrarea pe îmbunătățirea continuă - toate acestea permit Kanban să economisească serios resurse și să se încadreze în termene limită și buget. Și toate acestea combinate cu flexibilitate.

Părțile slabeKanban

Puteți auzi adesea că Kanban, spre deosebire de Scrum, poate lucra cu aproape orice echipă. Dar nu este așa. Kanban este cel mai potrivit pentru echipele ale căror abilități ale membrilor se suprapun. În acest fel, se pot ajuta reciproc să depășească dificultățile în rezolvarea problemelor. Fără aceasta, Kanban nu va fi atât de eficient pe cât ar putea fi. De asemenea, așa cum am menționat deja, Kanban este mai potrivit în cazurile în care nu există termene limită stricte. Pentru termene strânse, abordarea clasică sau Scrum este mai potrivită.

6 sigma (Six Sigma)

Motorola, împreună cu Toyota, au contribuit, de asemenea, la dezvoltarea managementului global de proiect. Bill Smith, inginer la această companie, a creat conceptul 6 Sigma în 1986. Este o versiune mai structurată a Lean decât Kanban, care adaugă mai multă planificare pentru a economisi resurse, a îmbunătăți calitatea și a reduce deșeurile și problemele.

Scopul final al proiectului este satisfacția clientului față de calitatea produsului, care poate fi atins printr-un proces continuu de îmbunătățire a tuturor aspectelor proiectului, bazat pe o analiză amănunțită a indicatorilor. În conceptul 6 sigma, se acordă o atenție deosebită eliminării problemelor emergente.

Pentru aceasta, a fost propus un proces în 5 etape cunoscut sub numele de DMEDI:

• Definiție (defini): Prima etapă este foarte asemănătoare cu primele etape ale altor sisteme de management de proiect. Determină conținutul proiectului, colectează informații despre cerințele prealabile ale proiectului, stabilește obiective.
• Dimensiunea (măsura): 6 Sigma se concentrează pe colectarea și analiza datelor cantitative despre proiect. În această etapă, se determină ce indicatori vor determina succesul proiectului și ce date trebuie colectate și analizate.
• studiază (Explora):În timpul etapei de cercetare, managerul de proiect decide cum echipa își poate atinge obiectivele și îndeplini toate cerințele la timp și în limita bugetului. În această etapă, gândirea non-standard a managerului de proiect în rezolvarea problemelor apărute este foarte importantă.
• Dezvoltare (Dezvolta):În această etapă, planurile și deciziile luate în etapele anterioare sunt în curs de implementare. Este important de înțeles că în această etapă este nevoie de un plan detaliat, care să descrie toate acțiunile necesare atingerii obiectivelor. Progresul proiectului este, de asemenea, măsurat în această etapă.
• Control (Control): O etapă cheie în metodologia 6 Sigma. Scopul său principal este îmbunătățirea pe termen lung a proceselor de implementare a proiectelor. Această etapă necesită documentarea atentă a lecțiilor învățate, analiza datelor colectate și aplicarea cunoștințelor dobândite atât în ​​proiecte, cât și în întreaga companie în ansamblu.

6 Sigma este foarte asemănător cu Kanban, doar cu etapele stabilite de implementare a sarcinilor - planificare, stabilire a obiectivelor și testarea calității. Cel mai probabil, vor avea loc semnificativ mai multe întâlniri de echipă cu 6 Sigma decât cu Kanban, dar procesul de implementare a proiectului este mai structurat și este mai dificil pentru echipă să se rătăcească. Și ca și Kanban, 6 Sigma este relativ ușor de adaptat la nevoile unei anumite companii sau echipe. O cerință strictă este doar o măsurare și un control amănunțit al indicatorilor proiectului în etapele de implementare - fără aceasta, îmbunătățirea continuă pe termen lung a proceselor de implementare a proiectului este imposibilă.

Punctele forte ale 6 Sigma

Six Sigma oferă un plan clar pentru implementarea proiectului și îmbunătățirea continuă a procesului. Prin definirea obiectivelor, apoi analizându-le și revizuindu-le cu atenție, obțineți date cantitative pentru o înțelegere mai profundă a proiectului și luarea unor decizii mai bune. Deși colectarea, analiza și învățarea datelor pot dura ceva timp, acestea vor îmbunătăți și eficientiza procesele de implementare a proiectelor și, astfel, vor economisi resurse în viitor.

6 sigma este potrivit pentru proiecte dificile cu multe operațiuni noi și complexe. Această abordare vă permite să implementați elemente de proiect, să învățați din greșeli și să îmbunătățiți calitatea în viitor.

Punctele slabe ale 6 Sigma

Problema cu 6 Sigma este că, deși principalul obiectiv declarat este reducerea costurilor și creșterea eficienței, satisfacția clienților vine adesea în prim-plan. Având în vedere unele dintre diferențele de obiective în diferite etape ale unui proiect, echipele devin adesea confuze cu privire la priorități, iar evitarea acestui lucru nu este ușoară.

În plus, principalul laitmotiv al 6 Sigma este: „Totul poate fi întotdeauna făcut și mai bine”. Acest lucru poate demotiva angajații care nu se simt mulțumiți de munca depusă. În plus, dacă proiectul este unul unic și compania nu intenționează să implementeze proiecte similare în viitor, toate costurile de analiză și învățare pot fi zadarnice.

PRIȚUL 2

NASA nu este singura organizație guvernamentală care a contribuit la dezvoltarea managementului de proiect. Guvernul britanic a apreciat de mult eficacitatea managementului de proiect, iar în 1989 a fost creată metodologia britanică PRINCE2. Numele provine de la acronimul " relatii cu publicul obiecte ÎN C controlat E versiunea de mediu 2 ”, care se traduce prin „Proiecte într-un mediu controlat versiunea 2”. Spre deosebire de metodele agile, PRINCE2 nu adoptă o abordare iterativă a proiectului. În comparație cu alte produse, PRINCE2 poate fi comparat cu un hibrid al abordării clasice a managementului de proiect și un accent pe calitate de la 6 sigma.

Metodologia PRINCE2, spre deosebire de, de exemplu, corpul de cunoștințe PMBOK, nu conține:

• Aspecte specializate ale managementului de proiect, cum ar fi industria;
• Practici specifice și instrumente de management de proiect, cum ar fi diagrama Gantt, WBS etc.

PRINCE2 se concentrează pe aspectele de management de proiect exprimate în 7 principii, 7 procese și 7 teme de proiect.

• 7 principii definesc regulile generale de gestionare a proiectelor conform PRINCE2, definesc baza metodologiei;
• 7 procese definesc pașii pentru a trece prin ciclul proiectului;
• Cele 7 subiecte sunt aspectele care sunt monitorizate pentru a atinge succesul proiectului.

La începutul unui proiect, PRINCE2 ne cere să definim 3 aspecte principale ale proiectului:

• Aspect de afaceri (Va aduce acest proiect beneficii?)
• Aspectul consumatorului (De ce produs este necesar, ce vom face?)
• Aspectul resurselor (avem suficient pentru a atinge obiectivul?)

PRINCE2 are o structură de echipă de proiect mai clar definită decât majoritatea abordărilor de management de proiect. Acest lucru se datorează faptului că PRINCE2 se concentrează pe proiecte guvernamentale la scară largă și pe organizații mari.

Potrivit PRINCE2, fiecare membru al echipei are un rol distinct în fiecare dintre cele 7 procese:

• Începutul proiectului (Starting susA proiect): În timpul acestui proces, este numit un manager de proiect și Cerințe generale la caracteristicile produsului. Managerul de proiect, a cărui responsabilitate principală este atenția la detalii, raportează Comitetului de coordonare a proiectului, care este responsabil pentru direcția generală a proiectului. Comitetul de coordonare este cel care menține proiectul pe drumul cel bun și este pe deplin responsabil pentru succesul proiectului.
• Initierea proiectuluiA proiect): În timpul acestui proces, managerul de proiect pregătește un „Document de inițiere a proiectului” care conține planul în faze al proiectului. Etapele pot dura o perioadă diferită de timp, dar, ca și în abordarea clasică, urmează strict una după alta.
• Management de proiect (Directing A proiect): Acest proces permite Comitetului de conducere să-și asume responsabilitatea generală pentru succesul proiectului, fără a se bloca în detalii care sunt de competența managerului de proiect.
• Controlul etapei (Controlling A etapă): Pe parcursul implementării proiectului, chiar și în condiții ideale, se vor face anumite modificări. Procesul Stage Control implementează unul dintre principiile PRINCE2 - principiul managementului prin excepții. Este responsabilitatea managerului de proiect să monitorizeze în timpul implementării etapei abaterile de la parametrii planificați ai proiectului în ceea ce privește timpul, domeniul de aplicare, bugetul etc. Dacă aceste abateri depășesc autoritatea acordată managerului de proiect de către Comitetul de Coordonare (în Terminologia PRINCE2 - toleranțe), managerul de proiect este obligat să informeze Comitetul de Coordonare și să propună o ieșire din situație.
• Managementul creării produselor (Gestionarea produs livrare): Procesul de management al creării produsului este interacțiunea dintre managerul de proiect și managerul de echipă pentru a crea unul dintre produsele proiectului. Responsabilitățile managerului de proiect în acest proces includ delegarea autorității de a crea produsul către managerul echipei și acceptarea produsului creat.
• Managementul limitelor etapei (Managing A etapă limite): Pe parcursul acestui proces, managerul de proiect pune la dispoziție Comitetului de conducere toate informatie necesara pentru a evalua rezultatele etapei trecute și a lua o decizie cu privire la trecerea la etapa următoare.
• Finalizarea proiectului (ÎnchidereA proiect): Una dintre diferențele din PRINCE2 este că procesul de finalizare a proiectului nu este separat într-o etapă sau etapă separată, ca în abordarea clasică, ci este realizat ca parte a etapei finale a creării produsului. Scopul procesului este de a confirma că produsul proiectului a fost acceptat sau că proiectul nu mai poate oferi nimic util.

PRINCE2 poate fi adaptat la proiecte de orice dimensiune și orice domeniu. Metodologia oferă recomandări specifice pentru schimbare ciclu de viață proiect, model de urmat și decor documente obligatorii conform nevoilor proiectului.

Punctele forte ale PRINCE2

• Adaptabilitate la caracteristicile organizației;
• Prezența unei descrieri clare a rolurilor și repartizarea responsabilităților;
• Accent pe produsele proiectului;
• Anumite niveluri de management;
• Accent pe fezabilitate economică;
• Secvența lucrărilor la proiect;
• Accent pe captarea experienței și îmbunătățirea continuă.

Punctele slabe ale PRINCE2

• Lipsa practicilor industriale;
• Lipsa instrumentelor specifice pentru lucrul în proiect.

Cel mai bun sistem de management de proiect... pentru tine!

Managementul proiectelor este o știință, dar știința nu este cea mai exactă. Nu există fundații de neclintit și soluții universale în acest domeniu. Dacă reușești să găsești o metodă care se potrivește perfect proiectului tău, consideră-te foarte norocos, deoarece majoritatea managerilor mai puțin norocoși trebuie să depună efortul de a crea și personaliza propriile sisteme de management de proiect. Aceste sisteme pot fi formate din elemente ale sistemelor existente, sau chiar create în întregime de la zero, ca în cazul misiunii Apollo. Principalul lucru este să folosiți ceva care vă oferă o anumită structură și vă permite să vă amintiți ce este important pentru proiectul dvs.

Cum să obțineți un certificat internațional în Agile?

Pentru cei care doresc să obțină o înțelegere sistematică a Agile, să înțeleagă avantajele și dezavantajele unei abordări agile a proiectelor și produselor, să găsească domenii de cea mai bună aplicare a Agile și să obțină certificat international Profesionist certificat ICAgile - formarea noastră

Metodele Agile de management de proiect (Agile) devin unul dintre cele mai populare instrumente de management, atât din punct de vedere strategic, cât și tactic. În această notă, vom încerca să ne dăm seama cât de mult este necesar managementul de proiect Agile în managementul companiei dumneavoastră, luând în considerare câteva întrebări, răspunsurile la care permit managerului să ia o decizie: merită implementarea metodologiei Agile în procesele de afaceri ale companiei sale sau nu și, dacă există o astfel de nevoie, atunci ce sarcini specifice vă permite să rezolvați în compania dvs.

Metode flexibile de management Agile sunt, în primul rând, abordări care vă permit să găsiți soluții foarte rapid, să lansați proiecte pilot și, dacă este necesar, să le extindeți.

Agil, în ceea ce privește managementul de proiect, va fi necesar pentru compania dumneavoastră dacă:

• produsul, serviciul sau prezentarea produsului dumneavoastră necesită ajustare constantă.
• dacă trebuie să ajustați marketingul, în funcție de cerințele pieței.
• dacă ești interesat să inovezi pentru a crește profiturile și a reduce costurile.

Și la figurat vorbind: ai întotdeauna nevoie de o metodologie Agile dacă lucrezi pe o piață aflată în schimbare rapidă în condiții de schimbare constantă sau de incertitudine, atât din punct de vedere strategic, cât și din punct de vedere al practicii.

Metodologie agilă(metodologia agile) vă permite să formați echipe agile de un nou tip de management și leadership, asigurând în același timp transparența și eficiența procesului, viteza de luare a deciziilor, dezvoltarea, adaptarea și scalarea produsului, precum și capacitatea de răspuns la incertitudini, schimbări și crize.

Metodologia Agile ce este?

Putem spune că agilul este un instrument pentru managementul crizelor și managementul schimbării? Categoric da!

Metodologia agilă este un instrument pentru rezolvarea problemelor specifice, practice, în managementul crizelor și managementul schimbării.

Cum să implementezi corect Agile?

O greșeală destul de comună este să vrei să implementezi Agile, profitând de popularitatea direcției și de experiența pozitivă a altor companii, dar există un risc mare dacă acționezi atât de imprudent:

Organizarea agilă necesită o schimbare în gândire, abordare a muncii și principii de interacțiune atât în ​​echipă, cât și în leadership, ești pregătit pentru asta? Dar angajații tăi? Rețineți că aceasta este o problemă foarte importantă care este de obicei trecută cu vederea de mulți:

Metodologie agilă nu este un produs într-o cutie, este o soluție a cărei aplicare necesită capacitatea de a învăța lucruri noi, de a se adapta sarcinilor tale și abia apoi de a scala.

De aceea, recomand întotdeauna să desfășurați, să desfășurați mai multe quest-uri de business cu privire la implementarea Agile și abia apoi să luați în considerare posibilitatea implementării metodologiilor de management agil în companiile dumneavoastră. Ca o soluție, vă pot sugera să urmați cursul meu practic:

Metode agileîți poate distruge afacerea și depinde de afacerea ta, de procesele tale de afaceri și nu de tine sau de angajați.

Când să nu implementezi Agile

Există o regulă simplă:

Metodologie agilă poate fi folosit numai atunci când sunteți dispus să plătiți pentru greșeli.

Metodologia agilă oferă nu numai rezultatul:

Agil, din punctul de vedere al dezvoltării flexibile, face posibilă construirea unui proces de obținere a rezultatelor prin feedback, multe opțiuni de feedback, dar feedback-ul nu este doar emoții și chestionare, este și bani: profit și pierdere, rețineți asta.

Dacă doriți să luați în considerare implementarea managementului de proiect Agile, atunci compania dvs. este pregătită să integreze metode de management agil de proiect în procesele dvs. de afaceri:

• coaching personal și de grup.
• colegii tăi împărtășesc valorile unei echipe agile
• sunteți hotărât să implementați Agile în organizație în toate procesele de afaceri necesare și sunteți conștient de riscurile implementării Agile în managementul proiectelor.

Și repet din nou: Metodologie agilă este gândire, nu doar instrumente.

Și gândirea înseamnă în sine: atitudine față de rezultat și comunicări, precum și feedback construit corespunzător, care este foarte important dacă intenționați să utilizați metode flexibile de management de proiect.

Metodologia agilă funcționează bine în condiții de incertitudine și rezultate previzibile, în condiții de pregătire pentru costuri mari de dragul unui obiectiv superior; dacă aveți procese de afaceri construite, gândiți-vă la ce obiective încercați să atingeți prin implementarea managementului de proiect Agile și merită „lucrarea jocului”.

Algoritm pentru implementarea Agile într-o companie

Să ne uităm la un algoritm orientativ pentru implementarea metodologiei Agile în procesele curente de afaceri ale companiei, concentrându-se pe Agile în managementul proiectelor:

• Începând cu obiective: Ce obiective încercați să atingeți prin implementarea metodelor de management Agile? Și cum corespund aceste obiective cu organizația Agile.
• Descriem problemele afacerii tale sau ale departamentului pe care l-ai ales pentru a implementa proiectul pilot Agile, dacă este necesar, descriem la ce stil aderă în munca ta, cum faci schimb de opinii și urmărește obținerea rezultatelor.

Desigur, următorul pas sugerează de la sine, clasicul „cum să”, dar nu ar trebui să te grăbești aici, pentru că de unde știi cum să o faci? - Metodologia Agile reconstruiește gândirea, iar la implementarea Agile în managementul proiectelor, este necesar să se creeze un mediu de comunicare eficient pentru construirea unui dialog între membrii echipei Agile.

Construirea unei echipe Agile într-o companie

Formarea unei echipe Agile poate fi destul de rapidă, poate dura câteva zile, dar cât timp durează pentru a „macina” membrii echipei?

Bineînțeles, din punctul de vedere al team building-ului, se disting etapele: formarea, conflictele, dezvoltarea regulilor și normelor, iar ca rezultat obținem: un anumit stil de lucru, dar într-o echipă Agile totul se întâmplă puțin diferit. :

• Membrii echipei și liderii agili aderă la Manifestul Agile și se concentrează pe construirea unei activități eficiente și pe atingerea obiectivelor într-un mediu de schimbare rapidă.
• nu creează o zonă de confort, nu creează o utopie, ei înșiși caută schimbări, tendințe noi, le analizează pentru posibilitatea de a le folosi în realizarea scopurilor companiei.

Metodologia agilă este:

Metodologia Agile nu este management de proiect, Agile este o metodă de management agilă care poate fi un instrument de management de proiect sau poate fi complet independentă în organizația ta. Desigur, pentru eficacitatea echipelor Agile, va fi o mare greșeală să antrenezi angajații în team building și leadership clasic, forțându-i astfel să gândească la modul vechi!

Metode flexibile de management Agile este o chemare la acțiune, la găsirea a ceva nou, la atingerea scopurilor stabilite, la capacitatea de a folosi oportunitățile și amenințările mediului extern și intern pentru a atinge obiectivele necesare și a rezolva probleme specifice care afectează profitul și competitivitatea în afaceri.

Doamnelor și domnilor, metodologia Agile este esențială în conducerea unei companii, dar necesită o abordare flexibilă a implementării și idei noi, în timp ce utilizarea metodelor vechi va duce la rezultate care nu vă vor permite să atingeți noi obiective și să construiți competitivitatea unei companii. Prin urmare, mare atenție atunci când alegeți consultanți pentru metodologia Agile, evaluați gradul de adaptabilitate al acestora la cerințele pieței moderne, întrebările dumneavoastră sunt binevenite, scrieți în comentarii. Mulțumesc!