Trimiteți-vă munca bună în baza de cunoștințe este simplu. Foloseste 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ă a managementului de proiect în domeniu tehnologia Informatiei
• 1.7 descriere generala proiecte IT
• 1.8 Caracteristici ale managementului de proiect în diferite țări
• 1.9 Trăsături etnoculturale activitati ale proiectului in Rusia
• 1.10 Tranziția la agilitate de la o abordare tradițională de management de proiect
• Concluzii capitolului
• 2. cercetare empirică 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. Pe scurt, ritmul schimbărilor de mediu a crescut foarte mult, deci este nevoie de a face față schimbărilor de mediu. Deci în dezvoltare software(software) 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 utilizând 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ă faceți acest lucru pe baza managerii ruși, întrucât managementul în diferite țări diferă 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. Întocmirea 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 tocmai 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 descriere detaliata metodologia 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 socioculturali în management agil proiecte. 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 general î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 din etapele ulterioare sunt nedorite și sunt asociate cu cu mare cheltuială. 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ă și aceste concluzii: ponderea proiectelor Agile în totalul matricei 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:

· Oamenii și interacțiunea sunt mai importante decât procesele și instrumentele

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 aveau avantaje serioaseîn viteza de implementare a proiectelor și eficacitatea 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 constă î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 cu privire la obiectiv, sau cale, sau toate împreună, metodologiile agile au rezultate mai bune, deoarece susțin schimbarea î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 organizatorică trebuie 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 munca sa decide să aplice o abordare agilă pentru următorul proiect, întrebare cheie care apare – 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 modifică î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 avut o opinie unanimă: sprijin de conducere, obiective clare și realiste, un plan detaliat - factorii care au primit cel mai mare număr mențiuni, le-au întâlnit pe toate trei împreună doar în 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, punctul forte al studiului este structura a 14 factori cheie de succes pentru proiectele Agile, care a fost construită pe baza unei analize a muncii existente și testată cu ajutorul unui 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. Trăsături 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, & 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 cunoașterii ș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 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 a sunat 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 disponibile autorității de reglementare” (Ashby, 2015) în capitolul 11. Dar aceeași lege funcționează și pentru alte sisteme, precum o organizație sau un proiect, ulterior a fost numită chiar „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 însuși. 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 forma sa cea mai 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.

Această abordare hibridă a fost explorată (Baird & Riggins, 2012) în articolele „Planning and sprinting: Use of a hybrid management de proiect metodologie î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 transferăm direct în sfera afacerilor.

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 principal pentru sprintul curent, și nu pe 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. IT - tehnologia informației este denumită în mod obișnuit tot ceea ce are legătură cu procesarea, stocarea și utilizarea informațiilor, dar recent, datorită dezvoltării tehnologiei informatice și a internetului, IT-ul este asociat în primul rând cu acestea. În această lucrare, un proiect IT va fi înțeles ca proiecte în domeniul dezvoltării software, securității informațiilor și sistemelor 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, sisteme CRM, ERP) și servere care susțin afaceri, și fără site-uri și pagini din rețelele sociale. Până în prezent cantitate semnificativă proiectele 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 sistemele de statistică de stat și dezvoltarea unui sistem de control al zborului au consecințe complet diferite ale unei erori de implementare. În construcții, de exemplu, proiectele care sunt interesante din punct de vedere al managementului sunt de obicei 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 ansamblu de norme și valori în domeniul activității economice este unul dintre cele cheie î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 există 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 interesele și opiniile grupului, 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 de niciun grup anume ș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 lor din cauza diferențelor fizice și intelectuale. Unele țări permit creșterea acestei inegalități (nivel ridicat de distanță 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 ar trebui 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 la nivel înalt încearcă să „abordeze” viitorul. Ș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), este important 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. Țări cu un nivel ridicat de segregare a rolurilor în funcție de gen (de exemplu, un profesor - munca femeilor, conducătorul auto este bărbat) se numesc masculin, iar cu unul scăzut - feminin. Din punctul de vedere al lui Hofstede, această dimensiune nu este semnificativ legată de managementul proiectelor.

În acești termeni, cultura rusă corespunde cu:

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 observat de oamenii de știință și cercetările sunt desfășurate în mod activ în această direcție.

Corpul de cunoștințe PMBoK Project Management: PMI listează cultura ca una dintre factori importanți mediu organizatoric. „Î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 mai subliniază 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ă altele noi. lucrări științifice, de exemplu, (Kozhevnikova, 2013) în lucrarea sa „Factori 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 până la mici companii de IT și consultanță), au fost identificate principalele domenii problematice ale managementului de proiect: managementul termenelor, calitatea, personalul și conținutul.

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) - retea globala sociologi, implicați în studiul schimbărilor în atitudinile valorice, precum și influența acestora asupra sferei sociale, politice și în alte sfere ale vieții. Pe baza datelor de pe 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 Statelor 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 practicienii 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 a fi 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 destul de evident 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, CSF-urile identificate reprezintă trăsăturile unei organizații care a integrat pe deplin metodologiile agile în cultura și fluxul său de lucru. Altfel, succesul este extrem de dificil. 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 asta. 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ă, sprijinului de resurse pentru implementare și testării 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 cea rusă cultura organizationala(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. Situație similară caracteristic în special sectorului 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ă cu privire 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). Există foarte puține lucrări similare despre proiectele rusești. 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

În etapa pregătitoare, a fost efectuată o analiză primară a situației problematice: a fost efectuată o trecere în revistă a literaturii ruse și străine pe această temă și au fost realizate interviuri nestructurate cu 3 manageri de proiect IT cu experiență de lucru 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 din a doua etapă a studiului a fost realizată cu ajutorul unui sondaj de la distanță a profesioniștilor IT prin intermediul internetului. Pentru aceasta, chestionarul creat în etapa anterioară a fost postat pe forumuri tematice și grupuri de pe rețelele de socializare folosind serviciul Google Docs.

Analiza informațiilor primite a fost efectuată cu ajutorul SPSS. Atentie speciala a fost dedicat 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 drept 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 în urma discuțiilor în cadrul interviurilor cu managerii și în timpul studiului pilot de către studenții Școlii Superioare de Economie a Universității Naționale de Cercetare. Î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 și grupuri tematice 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. Sa 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. Pentru analiza datelor au fost aplicate diferite metode statistice î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. Statistica descriptivă – 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 companii mijlocii și 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 punct importantîn partea demografică a sondajului - experiență cu metodologii Agile:

Tabel 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 puncte de vedere 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 de încredere.

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 și cerințele acestuia. 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 ale succesului î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 proiectelor, 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. Dezvoltarea unei metodologii de implementare în muncă instituție educațională Pachetul software de management de proiect Microsoft Project și evaluarea eficienței 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 sistemelor informatice. 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 in 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. Analiză indicatori economici munca intreprinderii. 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 activitati 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. Initierea si planificarea, finantarea proiectelor. Managementul programelor, riscurilor, comunicațiilor și portofoliului întreprinderii.

Agil („agil”) este un cuvânt care s-a auzit din fiecare fier de călcat în ultima vreme. Dar ce este Agile și, cel mai important, de ce este nevoie de acest Agile?

Dacă deschideți un dicționar explicativ, de exemplu, Oxford, puteți citi cel puțin două definiții acolo:

1. Capabil să se miște rapid și ușor.
2. Capabil să gândească și să înțeleagă rapid.

Adică, pentru a fi agil, trebuie să te poți mișca rapid și ușor și să gândești rapid. Par a fi calități destul de utile, mai ales în afaceri. A gândi rapid și a reacționa rapid este exact ceea ce a prescris medicul pentru timpul nostru, altfel pur și simplu nu vei supraviețui: concurenții te vor devora. Sunt din ce în ce mai puține industrii în lume în care acești concurenți nu există. Mai mult, viteza de copiere face practic imposibilă aducerea produsului pe piață și să se odihnească pe lauri. Fără capacitatea de a se adapta rapid la schimbare, ceea ce oferă așa-numita „metodologie Agile”, este din ce în ce mai dificil să supraviețuiești.

Nu întâmplător iau expresia „Metodologie Agile” între ghilimele, pentru că o auzi deseori, dar nu este în întregime corectă. Dacă nu intri detalii tehnice, atunci Agile nu este o metodologie, ci un nume colectiv pentru diverse metode și abordări ale managementului care:

1. Concentrați echipa pe nevoile și obiectivele clienților.
2. Simplificați structura și procesele organizaționale.
3. Oferă muncă în cicluri scurte.
4. Utilizați în mod activ feedback-ul.
5. Există o creștere a puterilor angajaților.
6. Ele se bazează pe o abordare umanistă.
7. Ele nu sunt o stare finală, ci mai degrabă un mod de a gândi și de a trăi.

Nimic supranatural, nu? Să mergem punct cu punct și să vedem de ce cele de mai sus sunt importante pentru a fi rapid și agil și cum Agile atinge aceste obiective.

Concentrați-vă pe nevoile și obiectivele clienților

Cred că nu merită să explic de ce cea mai de succes afacere este cea care satisface nevoile clientului său mai bine decât concurenții. Este mai interesant de înțeles ce instrumente din Agile ajută la realizarea acestui lucru.

Cel mai important, concentrarea asupra clientului cu abordarea Agile apare nu numai în capul proprietarului afacerii (există deja acolo), ci în toți cei care lucrează la crearea unui produs sau serviciu. Fiecare participant la proces trebuie să înțeleagă cine este clientul, ce își dorește, ce probleme rezolvăm cu produsul nostru, ce iubește, de ce se teme și așa mai departe. O astfel de concentrare globală vă permite să creați soluții de ordin de mărime mai bune. Am întâlnit în repetate rânduri o situație în care oamenii care anterior erau responsabili pentru o mică lucrare, după ce au înțeles obiectivele clientului, au început să dea idei minunate, iar oamenii care sunt responsabili cu dezvoltarea produsului au luat note cu surprindere. Sau - cum în sesiunile de grup de dezvoltare a produselor, astfel de idei sunt perfecționate de diferiți oameni și se completează reciproc, transformându-se din cele bune în unele excelente. Și, desigur, cum sunt apoi implementate.

„Instrumente de lucru” în acest caz sunt sesiuni (întâlniri) scurte, dar intense ale tuturor participanților la lucru sau ale majorității cheie, în care sunt generate și testate diverse idei. Aceste întâlniri servesc la nivel de înțelegere și concentrare: toți participanții la întâlnirea de ieșire înțeleg ce fac, de ce și de ce este important pentru client. Iar formatul democratic al atelierului, spre deosebire de prezentările plictisitoare, garantează o mai mare incluziune și motivare a tuturor participanților.

Exemple de astfel de instrumente sunt Lean Canvas, Impact Mapping, User Story Mapping și alte metode Agile pentru descrierea ipotezelor și proceselor.

Una dintre pietrele de temelie ale Agile este simplitatea extremă. Iar structura organizatorică a organizației și procesele prin care lucrează oamenii și regulile ar trebui să fie cât mai simple posibil. Acest lucru va permite oamenilor să se concentreze pe munca lor, pe valoarea pe care o creează și nu pe respectarea reglementărilor și regulilor. Exemple grozave ale acestei abordări pot fi găsite în multe echipe care lucrează pe Scrum, cel mai popular mod de organizare a fluxului de lucru în Agile. De fapt, toate acordurile și regulile unei echipe de 10-11 persoane, sarcinile curente pentru câteva săptămâni, obiectivele, precum și planurile strategice pot încăpea cu ușurință pe 2-3 coli de hârtie A0. Pe o foaie poate exista așa-numitul „sprint backlog”, o listă cu tot ce va face echipa în următoarea iterație. Dacă agățați unul în camera în care lucrați, vă puteți scuti de osteneala de a vă aminti toate acestea. Același lucru este valabil și pentru procese. De exemplu, în Scrum, locul și ora tuturor întâlnirilor sunt fixate în mod rigid. Orice participant știe sigur că, de exemplu, luni la 10-00 este planificată următoarea iterație, iar vineri la 17-30 - o întâlnire pentru a îmbunătăți procesul de lucru.

Și cu cât organizația este mai mare, cu atât beneficiază mai mult de pe urma acestei simplități, deoarece complexitatea are obiceiul de a crește exponențial, iar Agile este o modalitate bună de a învinge această complexitate, sau cel puțin de a-i limita creșterea.

Exemple de simplificare (și aplatizare, dar acesta este un subiect pentru altă discuție) în Agile sunt Scrum, Nexus, LeSS (Large-Scale Scrum, sau Scrum la scară largă), precum și manifestul Agile în sine.

În lumea Agile, nu este obișnuit să te închizi într-un atelier timp de trei ani pentru a ascuți ceva interesant acolo. Riscul este foarte mare, de a petrece o mare de forță și timp pe ceva de care nimeni nu are nevoie sau este depășit.

Pentru a evita acest lucru, se utilizează așa-numita abordare iterativă-incrementală, atunci când:

• munca se desfășoară în perioade mici fixe de timp, de exemplu, în una, două sau patru săptămâni,
• și, cel mai important, la sfârșitul fiecărei perioade de timp, nu se creează doar un fel de rezultat intermediar, ci, deși mic, trunchiat, mic, dar versiunea de lucru a produsului, care poti incepe sa folosesti.

Ca exemplu cel mai simplu al unui astfel de model de lucru, ne putem imagina standardul programului „calculator” pentru toate computerele, care la început vă permite doar să adăugați două numere, apoi adăugăm scăderea, înmulțirea, împărțirea, numerele transcendentale, funcții trigonometrice, - și așa mai departe, în ordinea frecvenței de utilizare. La început, funcționalitatea este mică, dar putem deja să vedem cum arată calculatorul, cât de convenabil este de utilizat și să ne imaginăm cum să-l dezvoltăm în continuare. Și, cel mai important, unii dintre clienți (să zicem, școlari scoala primara) poate începe deja să-l folosească.

Un alt avantaj al acestei abordări, pe lângă intrarea timpurie pe piață și schimbările la primele etape munca este o oportunitate de a măsura mai precis progresul. Nu am făcut doar 15% din muncă, ceea ce este destul de abstract. Am „realizat 15% din funcționalitatea” care deja funcționează.

Toate abordările proceselor din Agile au cicluri scurte, fie că este vorba de Scrum, Nexus, LeSS, SAFe sau , menționat anterior, plus necesitatea de a lucra cu astfel de cicluri este menționată în manifestul Agile în sine.

Utilizarea activă, sistemică a feedback-ului

Acest punct, după părerea mea, este cel mai important pentru orice proces, deoarece vă permite să vă ajustați munca în timp, pe baza experienței, eliminând erorile și pierderile din proces și din produsul creat și adăugând ceva util.

În orice domeniu de activitate umană legat de crearea a ceva nou, vei găsi un similar lucru prin experiment. Rachete, inginerie aeronautică, farmaceutică, fizică, medicină, construcții, psihologie, economie - orice domeniu de activitate a început cu experimente și prelucrare atentă părere de la ei.

Agile oferă o utilizare sistematică a acestei abordări peste tot: în crearea unui produs (îl lansăm pe piață, sau îl arătăm clientului, sau efectuăm teste și folosim feedback pentru a-l corecta), în procesele de construire (periodic „oprim” lucrul). și să analizeze procesul în sine, pentru a-l îmbunătăți, a scăpa de pierderi și probleme), chiar și în construirea structurii organizației și reglarea relațiilor în echipe.

Din nou, exemplele sunt peste tot: întâlniri retrospective în Scrum, Kanban, Nexus și LeSS, cicluri I&A în SAFe, abordarea Design Thinking pentru crearea de produse etc.

De ce să dai mai multă autoritate când poți da o bucată de hârtie cu instrucțiuni? Există cel puțin trei motive pentru a face acest lucru.

În primul rând, oamenilor angajați în muncă mentală nu le place să se simtă ca niște maimuțe (ei bine, sau roboți), iar prin luarea capacității de a lua decizii de la o persoană, îi luăm munca mentală în sine. Și asta este cu siguranță demotivant.

În al doilea rând, dând mai multă autoritate, dăm mai multă responsabilitate, iar oamenii sunt forțați să învețe să ia singuri decizii și, cel mai important, să poarte responsabilitatea pentru ele. Este lung, greu, dar merită. Lucrarea nu se va opri dacă o echipă auto-organizată întâmpină o problemă necunoscută, necunoscută anterior. Și cine va susține că la locul de muncă, adulții maturi și responsabili sunt mai utili decât copiii mari care nu sunt capabili să gândească singuri?

În al treilea rând, este încă aceeași viteză. Dacă o persoană poate rezolva singură o problemă, în locul lui, fără să întrebe pe nimeni, acest lucru reduce timpul de luare a deciziilor. Nu mai trimiteți întrebarea „în sus” și așteptați un răspuns din partea conducerii. Acest avantaj nu este atât de vizibil dacă ai 3 oameni care lucrează, dar dacă ai 30, sau 300, sau 3000... În organizațiile mari construite pe luarea deciziilor pur ierarhice, paralizia voinței poate fi destul de comună.

Modalitățile populare de construire a muncii în Agile, în special cele bazate pe framework-ul Scrum, implică un sistem de echipe auto-organizate și încurajează conducerea la toate nivelurile.

De ce să tratezi oamenii ca pe oameni? Adică, partea morală a problemei este clară, dar ce beneficii va aduce proprietarului întreprinderii?

Răspunsul este destul de simplu. Dacă crearea a ceea ce vindeți nu necesită muncă mentală, ci doar acțiuni mecanice, nu vă puteți deranja. Plătește doar în funcție de munca depusă și atât. Dar, de îndată ce creierul lucrătorilor va intra în joc, va trebui să luați în considerare principiile de motivare a muncii mentale. Și spun că oportunitatea de auto-realizare, îmbunătățirea abilităților, aducerea pe lume a ceva valoros, independența în decizii și o serie de alți factori sunt importanți pentru oameni. Iar o persoană motivată (a nu se confunda cu o persoană stimulată!) va investi mai mult în muncă, iar rezultatul va fi mai bun și mai rapid. Și, în general, o atmosferă plăcută la locul de muncă se adaugă dorinței de a veni să lucreze acolo - aproape nimeni nu poate contrazice acest lucru.

Și, ce este frumos, dacă sapi în același Scrum, se dovedește că toți factorii cheie pentru motivarea unui lucrător de muncă mentală și/sau creativă sunt deja incluși în el. În fiecare iterație („sprint”), ne stabilim un obiectiv pe care dorim să-l atingem; ni se oferă posibilitatea de a decide cum exact să atingem obiectivul; la final, ne uităm la cât de mult am devenit mai buni (sau mai rău) să lucrăm decât înainte; vedem oameni care sunt interesați de produs și de emoțiile lor în urma cunoașterii acestuia. Este mai ales bine dacă aceste emoții sunt pozitive.

Concluzia este: oameni fericiti funcționează mai bine, iar tehnologiile Agile ajută la stabilirea unui proces în care oamenii se simt mai fericiți. Iar primul punct al manifestului este doar despre asta: oamenii și modul în care comunică sunt mai importante decât orice altceva.

Agile nu este o stare finală, ci un mod de a gândi și de a trăi

Acest punct este despre modul în care Agile este, în general, calea, nu scopul. Nu poți „implementa” Agile și relaxa. Dacă alegeți această cale, veți avea întotdeauna altceva de făcut mai bine, altă provocare la care să răspundeți, altă problemă de rezolvat, altă înălțime de cucerit... Aceasta este mișcarea la nesfârșit, pentru că nu există un proces sau un produs ideal, dezvoltarea și competiția nu se opresc niciodată, așa cum lupta pentru supraviețuire în natură nu se oprește niciodată.

Și dacă totul a avut succes: oamenii din companie înțeleg și împărtășesc valorile și principiile Agile și lucrează în conformitate cu acestea, atunci conducerea nu va trebui să „trage” nicio schimbare sau să „dea cu piciorul” angajaților pentru ca aceștia să înceapă să facă ceva diferit. Întreprinderea va deveni un singur organism, al cărui management va necesita mai puțin efort și va aduce mai multă plăcere.
Și acolo unde este mai multă plăcere de la muncă, iar rezultatul este mai mare. Acest lucru se aplică nu numai specialiștilor, ci și managementului și într-o măsură și mai mare.

Un exemplu de filozofie Agil este principiul de funcționare al celebrei uzine Toyota, unde orice subordonat putea opri transportorul și face ajustări. ()

Mulți consideră că această metodă de implementare a proiectului este singura adevărată. Baza unei astfel de declarații este implicarea fiecărui participant în procesul general. În orice moment, un membru al echipei de proiect are dreptul de a face o propunere sau de a face modificări proiectului.

Adesea, la crearea unui produs, persoanele responsabile pentru anumite etape ale proiectului intra în conflict între ei. Când se găsesc probleme, dezvoltatorii dau vina pe alți membri ai echipei.

Metodologia inovatoare Agile implică toți participanții la lucru, păstrându-și în același timp responsabilitățile obișnuite. Abordarea vizează pe toată lumea să obțină un rezultat sub forma unui produs care să satisfacă clientul.

Această metodologie se poate schimba cultura de afaceri intreaga companie, raliand echipa, care ulterior va deveni eficienta pe piata.

La trasaturi caracteristice Agile include diferențierea riscurilor posibile, auto-organizare, predictibilitate, răspunsuri prompte la transformări și interacțiune stabilă (feedback).

Până în prezent, există două modalități destul de utilizate pe scară largă de a stabili o relație de lucru cu un client - contracte cu preț fix și timp și materiale. Un acord cu preț fix transferă responsabilitatea pentru eventualele riscuri către contrapartidă, al doilea prevede plata de către client pentru serviciile prestate, ceea ce poate afecta negativ rezultatul final.

Predictibilitatea respinge planificare pe termen lung, termene clare și un preț final stabilit. Metodologia Agile necesită definirea sarcinilor cutie neagră cu o anumită cantitate de informații de intrare și un timp alocat pentru a demonstra rezultatul obținut. La începutul procesului, participanții evaluează sarcina și își asumă responsabilitatea pentru rezultat.

Feedback-ul are principala problemă, care este incapacitatea clientului de a formula corect sarcina. Chiar și un plan bine documentat poate deveni depășit după câteva luni de dezvoltare. Restructurarea conceptului inițial va implica probabil revizuiri îndelungate și reelaborare a rezultatelor.

Metodologia prevede ca nici dupa stadiul initial de lucru conform planului, produsul nu va avea functionalitatea declarata, ceea ce va permite clientului sa comenteze si sa faca ajustari incepand de la linia de plecare a proiectului. După ce parcurgeți două etape de dezvoltare, puteți rula o versiune de testare a produsului pentru a obține feedback. Caracteristică suplimentară iată o reacție aproape instantanee la schimbările funcționale.

Autoorganizarea contribuie la eliminarea unei structuri manageriale excesive, absența necesității de a controla membrii echipei, fiecare dintre ei își asumă o anumită responsabilitate. Aceasta va fi o garanție de performanță și un produs de înaltă calitate. Cu toate acestea, mulți oameni fac greșeli.

Istoria Agile

în 1970, dr. Winston Royce a introdus tehnica „managementului dezvoltării marilor sisteme software". De atunci, conceptul de Agile a existat. Istoria completă a dezvoltării managementului de proiect este descrisă în

Ceva despre metoda Scrum

Beneficiile metodelor de dezvoltare agile

• Îmbunătățirea calității rezultatelor
• Adaptarea la schimbare
• Foarte rapid si eficient
• Program de proiect mai controlabil

Principiile de bază ale Agile

1. Implicarea utilizatorilor este esențială;
2. Pentru a lua decizii, echipele trebuie să fie foarte eficiente;
3. Stadial și ciclic ca bază;
4. Se concentrează pe prezentarea frecventă a rezultatelor intermediare ale proiectelor;
5. Se aplică regula de lucru 80/20;
6. Utilizarea unei abordări colaborative pentru implementarea planului;
7. Finalizarea unei singure etape, pentru a trece la următoarea.

De asemenea, am scos la iveală cele 12 principii principale ale metodologiei Agile într-o infografică separată. Poti sa vezi

Caracteristicile tehnicii:

• Iterativ
• Modular
• Crescând
• Adaptiv
• Combinarea erorilor în implementarea metodelor agile de management de proiect sunt descrise în articol

De ce să folosiți Agile?

• Creșterea fluxului de numerar
• Controlul riscurilor
• Timp și cheltuieli generale reduse
• Creșterea responsabilitățiiPentru cum să utilizați Agile pentru dezvoltare, citiți articolul

Ce metodologie de management de proiect este potrivită pentru tine?

Adesea, secretul succesului unui proiect constă în metodologia corectă de management de proiect.

Alegere sistem eficient managementul pentru implementarea calității este esențial pentru orice proiect.

Dar când ai de ales între planificarea în cascadă și planificarea agilă, de unde știi care este cel mai bun pentru proiectul și echipa ta.

Pentru a vă ajuta să decideți, am întocmit o listă de argumente pro și contra pentru fiecare metodă.

Metodologia de management al proiectelor în cascadă

Metodologia cascadă necesită o planificare detaliată la începutul proiectului

Toate etapele sunt cunoscute și se construiesc dependențe logice între ele și treceți la pasul următor numai după finalizarea celui precedent

Beneficiile managementului de proiect în cascadă

• Cel mai potrivit pentru proiecte care se ocupă de obiecte fizice - de la Proiecte de construcții la proiecte de instalare
• Cerințele sunt descrise la începutul proiectului
• Cel mai bun pentru proiecte cu sarcini clar definite și repere care trebuie finalizate într-o anumită secvență (de exemplu, construiți primul etaj al unei clădiri până la al doilea etaj)
• Nu este necesară implicarea clientului în procesul de dezvoltare
• Programele de proiect pot fi folosite pe viitor, pentru proiecte identice sau similare
• Domeniul complet al cerințelor este cunoscut în prealabil
• Rezultatele definite în TOR reduc probabilitatea apariției imperfecțiunilor

Dezavantajele metodologiei clasice de management de proiect

• Necesită efort semnificativ pentru planificarea și programarea de calitate a proiectelor înainte de începerea lucrărilor
• Clientul vede rezultatele lucrării abia la sfârșitul proiectului și poate fi nemulțumit
• Schimbările în domeniul de aplicare al proiectului pot fi de lungă durată și necesită un management oficial al schimbărilor
• Clientul poate avea probleme cu viziunea proiectului chiar de la început
• Modificările târzii ale TOR cauzează depășiri de buget
• Modificările târzii ale TOR extind cronologia proiectului
• Metoda este mai puțin eficientă pentru proiecte din sectorul serviciilor, software, design și alte proiecte în care nu există obiecte fizice.

Agile - metodologie de management de proiect

Agile este o abordare rapidă și flexibilă a managementului de proiect bazată pe principiile colaborării, adaptabilității și îmbunătățirii continue.

Spre deosebire de etapele ordonate ale planificării în cascadă, principiile Agile tind să fie implementate în cicluri rapide și iterative de lansare a produsului.

Beneficiile Metodologiei Agile de Management de Proiect

• Cea mai bună metodologie pentru proiecte care se ocupă de livrabile orientate spre servicii și non-fizice, cum ar fi codificarea, redactarea sau designul
• Proiectul este transparent și ușor de înțeles pentru client în toate etapele
• Excelent pentru pornire rapidă
• Oferă o corectare rapidă a cursului pe baza feedback-ului părților interesate
• Prioritățile se concentrează pe beneficiul pentru afacerea clientului
• Proiectul oferă echipei libertate de acțiune pentru a lucra creativ și eficient.
• Implicarea clientului în proiect dă accent pe dezvoltare
• Include interacțiunea și colaborarea cu toți membrii echipei de proiect

Dezavantajele Metodologiei Agile de Management de Proiect

• Echipa este implicată în proiect tot timpul
• Nu este potrivit pentru proiecte cu cerințe și domenii bine definite
• Incertitudinea în domeniul de aplicare și calendarul de lucru poate face clienții și conducerea nervoși (la început)
• Este posibil ca clientul să nu aibă timp să se implice în proiect
• Necesită urmărirea constantă a muncii și documentarea managementului sarcinilor echipei
• Clientul poate revizui domeniul de activitate
• Pornirea rapidă poate duce la executarea incompletă a sarcinilor

Metoda de management de proiect pe care o alegeți va varia în funcție de proiect, echipă și obiective. Odată ce ați ales stilul dvs. de management, asigurați-vă că utilizați un software de management de proiect care vă permite dvs. și echipei dvs. să configurați proiectul așa cum doriți.

Mult succes cu proiectele tale!

Combinarea metodologiei Agile și Flow

Succesul implementării proiectului depinde în mare măsură de metodologia aleasă și de nivelul de pregătire al managerului de proiect. O abordare metodică a dezvoltării de software reduce cantitatea de mizerie din proces și, prin urmare, oferă mai mult timp scurt dezvoltare și cea mai bună calitate.

Proiectele folosesc adesea o combinație de modele agile și cascade ciclu de viață dezvoltare de produs, o metodologie agilă pentru dezvoltarea pașilor mici și o metodologie simplificată pentru implementarea întregului proiect.

Procesul de livrare a serviciilor

1. Definirea problemei
Dezvoltator companie ar trebui să înțeleagă și să definească problema pe care clientul încearcă să o rezolve cât mai exact posibil. În mare măsură, definirea corectă a problemei este jumătate din soluție.

2. Definiția unei soluții
Este necesar să luați în considerare mai multe Opțiuni solutii si oferta clientului. Alegeți oferta care rezolvă cel mai bine problema afacerii și oferă cea mai mare valoare.

3. Verificarea pieței
Trebuie să verificați soluția propusă cu instrumente de marketing precum identificarea mediului competitiv, a tendințelor din industrie și a clienților țintă. Acest lucru se face pentru a confirma și întări în mod rezonabil soluția propusă clientului.

Acesta este un pas opțional, puteți implica companii terțe prin cercetare de piata, utilizați datele experților inițiale ale clientului (dacă sunt disponibile) sau monitorizați datele deschise suficiente pentru a confirma conceptul. Cu un flux constant de proiecte, puteți începe propriul departament de analiză și îl puteți oferi ca un serviciu separat.

4. Dezvoltarea soluției
Echipa de dezvoltare începe să lucreze la o soluție.

Metodologie de dezvoltare agilă (cadru agil)

Gestionarea proiectelor complexe de dezvoltare software presupune utilizare eficientă resurse, prioritizarea sarcinilor, estimări precise ale timpului și managementul riscurilor. Metodologia agilă este utilizată pentru a reduce riscul și a crește valoarea clienților.

Prin utilizarea metodologiei Agile, diverse aspecte ale activităților echipei sunt integrate între ele, acest lucru asigură că întregul concept se bazează pe obiective bine definite, iar abordările și metodele de lucru sunt îmbunătățite constant. Metodologia împarte întregul proces de dezvoltare în etape mici și iterații cu integrare constantă a tuturor componentelor dezvoltate. Caracteristicile includ un ciclu de proiectare secvențială și revizuiri periodice, clarificarea cerințelor și dezvoltarea produsului final. Metodologia agilă asigură, de asemenea, îmbunătățirea continuă bazată pe feedback-ul clienților pentru a evita orice surprize mai târziu în ciclul de viață.

Unicitatea metodologiei combinate:

Utilizarea metodologiei Agile la fiecare pas duce la economii de costuri și resurse atât pentru client, cât și pentru contractor.

Utilizarea unui model de cascadă pentru un proiect mare are ca rezultat controlul asupra rezultatelor generale.

Furnizarea de feedback rapid între client și echipa de dezvoltare.

rapid si frecvent prototipare.

Abordare centrată pe client – ​​concentrarea pe minimizarea costului total de proprietate (TCO) și pe maximizarea rentabilității investiției (ROI).

Format din 12 principii. Desigur, anumite prevederi ale abordării Agile au apărut înainte de asta, dar doar acest document le-a sistematizat și conturat într-o măsură suficientă pentru utilizare. În fiecare an, noi companii, specialiști IT și manageri de proiect semnează manifestul. Există noi metode și modificări ale sistemului de dezvoltare agilă.

Ce este Metodologia Agile (metodologie flexibilă)?

Agile este un model de dezvoltare iterativ în care software-ul este construit progresiv încă de la începutul unui proiect, spre deosebire de modelele în cascadă în care codul este livrat la sfârșitul unui ciclu de lucru.

Baza unei metodologii agile este împărțirea proiectelor în bucăți mici de lucru numite povești de utilizator. Conform priorității, sarcinile sunt rezolvate în cadrul unor cicluri scurte de două săptămâni (iterații).

Cele 12 principii care alcătuiesc Metodologia Agile pot fi împărțite în 4 idei principale:

• Prioritatea oamenilor și a comunicării față de instrumente și procese;
• Prioritatea unui produs de lucru față de documentația completă;
• Prioritatea cooperării cu clienții față de aprobarea contractului;
• Acordați prioritate dorinței de a schimba în fața planului inițial.

Metode prezente în Agile:

Rugby-ul își datorează termenul „Scrum”, în care acest cuvânt înseamnă o metodă joc in echipa sub forma construirii a trei linii de catre fiecare dintre adversari si incercarea de a captura mingea. Interceptarea reușită necesită nu numai o bună pregătire fizică, ci și coerența fiecărui participant la luptă și o înțelegere clară a obiectivului.

Metoda este folosită cu succes de companii precum Microsoft, Yahoo, Siemens Healthcare, iar managerul de proiect de la Amazon chiar a descris-o pe baza experienței acumulate.

Deoarece Scrum este un cadru de dezvoltare, în fiecare exemplu ulterior acesta poate diferi semnificativ de cel anterior.

Jeff Sutherland, autorul a identificat 8 pași pentru utilizarea tehnicii:

1. Selectați proprietarul produsului- Cunoaște scopul proiectului și rezultatul așteptat.
2. Aduna comanda- până la 10 persoane cu abilitățile necesare pentru a crea un produs funcțional.
3. Găsi Scrum Masters— monitorizează progresul proiectului, ajută echipa de proiect să facă față dificultăților.
4. Inventa restante produs- Pe placa Agile, prioritizează fiecare cerință de produs. Aici are un rol important Product Owner-ul, care colectează dorințele pentru produs pentru evaluarea de către echipa de backlog.
5. Programa sprinturi(iterații) - perioade de timp pentru a efectua un anumit număr de sarcini.
6. Organiza „întâlniri” zilnice de cincisprezece minute- puneți 3 întrebări fiecăruia din echipă: ce ați făcut ieri, ce se va întâmpla astăzi, ce vă împiedică să îndepliniți sarcina.
7. Do recenzii ale părților de lucru ale produsului- cu implicare în vizionarea și discuția părților interesate.
8. Petrece retrospectiv— discutarea problemei și căutarea unei soluții după fiecare sprint. Implementați planul de schimbare rezultat la următorul sprint.

Retrospectivă în Agile

Scrum are 4 elemente cheie:

• restante produs- lista de cerințe pentru proiect
• Sprint Backlog- o listă de cerințe care trebuie îndeplinite în următorul sprint
• Gol de sprint- gol de sprint
• Graficul Sprint Burndown- O diagramă care se actualizează pe măsură ce sarcinile sunt finalizate. Este ușor de înțeles dinamica și nivelul de progres al echipei în proiect.

(XP)

Dezvoltatorul metodologiei, Kent Beck, a creat metoda Extreme Programming, al cărei scop este de a face față cerințelor în continuă schimbare pentru un produs software și de a îmbunătăți calitatea dezvoltării.

Este aplicabil exclusiv în domeniul dezvoltării software și este construit în jurul a 4 procese:

1. codificare— conform standardelor uniforme de proiectare în echipă;
2. testarea- testele sunt scrise chiar de programatori înainte de a scrie codul care va fi testat;
3. planificare- atât versiunea finală, cât și iterațiile individuale. Acesta din urmă are loc în medie o dată la două săptămâni.
4. auz- atât dezvoltatorii, cât și clientul, timp în care ambiguitățile dispar, cerințele și valorile sunt determinate.

Metodologii

Puțin cunoscut în întinderile interne management de proiect o familie de metodologii dezvoltate de Alistair Cockburn, unul dintre autorii Agile Manifesto. Cockburn își propune să clasifice după culoare după criteriul numărului de persoane din echipă: de la 2 (Crystal Clear) la 100 (Crystal Red). Culorile maro, albastru și violet sunt alocate pentru proiecte mai mari.

Proiectele Crystal trebuie să îndeplinească 3 indicatori principali:

1. livrare rapidă a codului de lucru— dezvoltarea ideii unui model de dezvoltare Agile iterativ.
2. perfectiunea prin reflexie- noua versiune a software-ului este îmbunătățită pe baza datelor din cea anterioară.
3. interacțiune „osmotică”.- Inovația lui Alistair, o metaforă a comunicării și schimbului de informații între dezvoltatorii de software din aceeași cameră.

Metoda de dezvoltare software dinamică (DSDM)

Nu o persoană sau măcar o echipă nu a lucrat la dezvoltarea DSDM, ci un consorțiu de 17 companii engleze. DSDM, la fel ca Extreme Programming, este folosit în principal pentru a crea software.

Un rol special este acordat participării consumatorului final (utilizatorului) la procesul de dezvoltare. Pe lângă acest principiu, cele de bază includ:

• lansări frecvente ale versiunilor de lucru ale produsului
• autonomia dezvoltatorilor în ceea ce privește luarea deciziilor
• testarea pe parcursul întregului ciclu de lucru.

DSDM este împărțit în versiuni care sunt actualizate pe măsură ce tehnologia se dezvoltă, apar noi cerințe pentru dezvoltarea software. Ultimul de astăzi este DSDM Atern, lansat în 2007, deși precedentul (2003) este încă în service.

La început, echipa explorează realitatea dezvoltării aplicațiilor și domeniul de aplicare. Lucrările ulterioare sunt împărțite în trei cicluri interconectate:

1. ciclu de model funcțional— crearea documentației analitice și a prototipurilor.
2. ciclu de proiectare și construcție- aducerea sistemului in stare de functionare.
3. ciclu de implementare- implementarea sistemului.

Dezvoltare bazată pe caracteristici (FDD)

O metodologie care precede chiar și Manifestul Agile.

Deși FDD utilizează, de asemenea, un model de dezvoltare iterativ, acesta diferă de Agile în următoarele moduri:

• mai multă atenție la pre-modelare
• importanță crescută (comparativ cu Agile) a raportării și a graficării
• care vizează dezvoltarea corporativă.

Dezvoltarea bazată pe caracteristici constă din următoarele etape ciclice:

1. Creați un model comun— viziunea proiectului pe baza datelor preliminare.
2. Proiectarea unei liste de proprietăți- un analog al backlog-ului de produse în metodologia Scrum.
3. Planificarea după proprietăți- Evaluarea complexității proprietăților de către fiecare membru al echipei.
4. Pentru fiecare proprietate- proiectare și implementare tehnică - etapa finală, la sfârșitul căreia proprietatea intră în produs și ciclul se repetă.

Dezvoltare de software

Lean Software Development nu este mai degrabă o metodologie, ci un set de principii de lean manufacturing, care vizează creșterea eficienței procesului de dezvoltare, minimizând costurile.

Setul include următoarele 7 principii:

1. scaparea de pierderi- tot ceea ce nu aduce un plus de valoare produsului pentru consumatorul final.
2. învățare continuă- dezvoltarea continua a echipei creste capacitatea de a indeplini eficient sarcinile.
3. luând o decizie cât mai târziu posibil- prioritate nu sunt deciziile spontane, ci gândite, dezvoltate pe baza cunoștințelor dobândite.
4. livrare rapidă- de fapt, baza modelului iterativ.
5. consolidarea echipei- unul dintre principiile „Manifestului...” spune că oamenii și interacțiunea sunt mai importante decât procesele și instrumentele. Echipa de proiect este baza pentru îndeplinirea cu succes a sarcinilor.
6. integritate si calitate- trebuie să faceți inițial un produs de calitate pentru a nu pierde timp și resurse cu teste ulterioare și pentru a scăpa de bug-uri.
7. văzând întreaga imagine— împărțirea proiectului în părți separate este imposibilă fără înțelegere Statusul curent dezvoltarea, obiectivele, conceptele și strategiile software-ului dezvoltat.

Varietăți de metodologii de dezvoltare agilă

Modelare agilă (AM)

Agile Modeling este un set de valori, principii și practici pentru modelarea software.

AM este utilizat ca parte a unei metodologii complete de dezvoltare a software-ului, cum ar fi Extreme Programming sau Rapid Application Development.

Principiile modelării agile sunt:

• interacțiune eficientă între părțile interesate ale proiectului
• dorința de a dezvolta cea mai simplă soluție posibilă, care să se potrivească tuturor cerințelor
• feedback constant
• curajul de a lua și de a-și asuma responsabilitatea pentru decizii
• înțelegând că nu știi totul.

Proces unificat agil (AUP)

AUP este o versiune simplificată a unei alte metodologii de dezvoltare software, Rational Unified Process (RUP). Din 2012, a fost înlocuit cu Disciplined Agile Delivery (DAD), dar AUP se mai găsește în unele locuri.

Autorul metodologiei, Scott Ambler, a identificat următoarele poziții cheie ale procesului unificat Agile:

• Echipa ta știe ce face;
• Simplitatea este mai presus de toate.
• Respectarea principiilor metodologiei de dezvoltare agile.
• Concentrați-vă pe activități care sunt valoroase pentru proiect.
• Independență în alegerea instrumentelor.
• Ajustarea individuală a AUP pentru nevoile unui anumit proiect.

Metoda Agile de Date (ADM)

ADM este un set de metodologii de dezvoltare software agilă iterativă care pun accent pe generarea de cerințe și decizii de proiect prin colaborarea echipelor individuale. La fel ca AUP, nu este o tehnică valoroasă în sine.

Esența metodei Agile de date este definită de șase prevederi:

1. Date- baza pentru crearea oricărei aplicații.
2. Probleme cu proiectul— pot fi detectate numai cu o înțelegere clară a scopului și conceptului proiectului.
3. Grupuri de lucru- pe lângă echipa de dezvoltare directă, există grupuri de întreprinderi care sprijină alte grupuri de lucru.
4. Unicitatea— nu există o metodologie perfectă, pentru fiecare proiect trebuie să combinați instrumente din metodologii diferite.
5. lucru in echipa- lucrul împreună este mult mai eficient decât lucrul singur.
6. „Sweet Spot”– căutați soluția optimă a problemei („sweet spot”), evitând extremele.

Proces unificat esențial (EssUP)

Dezvoltarea omului de știință suedez Ivar Jacobson, creată pentru a îmbunătăți Procesul Rațional Unificat.

EssUP operează cu conceptul de practică, care include:

• caz de utilizare - o descriere a comportamentului sistemului.
• dezvoltare iterativă - crearea de bucăți de cod de lucru în cicluri scurte de câteva săptămâni.
• practici de echipă – care vizează ralierea echipei și creșterea eficacității acesteia.
• practici de proces - de exemplu, „Gândește mare, începe mic” sau „Implica părțile interesate în procesele de afaceri”.

Toate practicile într-o formă sau alta se regăsesc în RUP, CMMI și metodologii agile.

Devenirea reală (GR)

O metodologie eficientă pentru startup-uri și echipe de începători, care oferă să profite la maximum de caracteristicile micilor proiecte și companii: mobilitate, flexibilitate, căutarea de noi soluții, absența unei ierarhii rigide confuze etc. Jason Fried și David Hansson, fondatorii 37signals (acum Basecamp), au definit Getting Real ca un sistem de rezolvare a problemelor reale: cât se poate de simplu, de înțeles și de funcțional.

GR este un amestec de o duzină de instrumente de dezvoltare agile care sunt folosite pentru a minimiza:

• oportunități
• opțiuni și setări
• structurile companiei
• întâlniri
• promisiuni.

Conceptul neobișnuit nu a fost adoptat pe scară largă, deși elementele individuale folosesc alte tehnici.

OpenUP (OUP)

O metodologie de dezvoltare software independentă de instrumente, fără o structură rigidă, care conține următoarele practici:

• măsurarea vitezei echipei;
• organizarea de întâlniri zilnice și retrospective la sfârșitul iterațiilor;
• conceptul de micropași și testarea timpurie folosind liste de verificare;
• tehnica flexibilă de modelare (AMDD).

Practicile sunt implementate pe baza a patru principii:

Metrici Agile

Având în vedere varietatea de instrumente, practici, metode și metodologii în Agile, trebuie să alegeți un instrument care va ajuta la determinarea eficacității fiecăruia dintre ele. Metricile sunt un astfel de instrument.

Pentru majoritatea proiectelor, 4 domenii de metrici vor fi suficiente:

1. Performanţă- aceasta include Velocity și WIP. Primul nu este potrivit pentru toate proiectele, deoarece se măsoară numărul de sarcini finalizate pe iterație și nu sunt echivalente. Metrica Work-in-Progress determină limita sarcinilor în diferite etape: cu cât este mai mare, cu atât este mai rău;
2. Prognoza- metrica capacitatii: determinarea numarului de ore ideale disponibile in urmatorul sprint. În consecință, este posibil să înțelegem cât timp este disponibil pentru muncă, cât de eficientă este executarea sarcinilor și cum pentru un sprint;
3. Calitate- de exemplu, indicele de stabilitate a cerințelor, care se calculează prin formula = (Numărul total de cerințe de afaceri inițiale + Numărul de cerințe care s-au modificat până acum + Numărul de cerințe adăugate + Numărul de cerințe eliminate) / (numărul total de cerințe originale ). Valoarea măsoară timpul petrecut pentru refacerea sarcinilor;
4. Valori- in fiecare caz se calculeaza individual, in functie de formatul proiectului. De exemplu, startup-ul AirBnb a ales numărul de fotografii de înaltă calitate încărcate ca măsurătoare care determină valoarea finală a unui produs pentru utilizatori. Odată cu creșterea lor, și numărul consumatorilor a crescut proporțional.

Aceleași reguli se aplică pentru metrici ca și pentru alte instrumente Agile.

Nu există o singură măsurătoare corectă sau corectă pentru proiectul dvs.

Ele trebuie revizuite în mod constant, cele învechite eliminate și altele noi adăugate după cum este necesar. Ar trebui să fie de înțeles și accesibil întregii echipe, nu să devină un scop în sine. Valorile de dragul valorilor sunt o decizie proastă.

Străbători de mituri: Agile

Popularitatea familiei de metodologie de dezvoltare agilă a jucat o glumă crudă cu ea și chiar și pe portalurile specializate există mituri despre acest sau acel aspect al Agile. Ne vom da seama!

Mitul #1: Agile este bun pentru toate proiectele.

Cea mai încăpățânată concepție greșită. Nicio metodă Agile nu va adăuga valoare unui produs sau nu va motiva o echipă singură.

Mitul #2: Agil versus documentare.

Agile nu este împotriva documentării, este împotriva documentării ca scop în sine. Dar atunci când alegeți documentația ca mijloc de comunicare, Agile acordă prioritate comunicării live.

Mitul #3: Agile și planificarea nu merg împreună.

Acest mit este dezmințit de planificarea zilnică cu stand-up-uri de 10 minute, planificare iterativă la fiecare două săptămâni, întâlniri de sprint etc.

Mitul #4: Agile necesită multă reluare.

În dezvoltarea agilă de software, reproiectarea vine sub două forme: rescrierea cerințelor (utilizatorii înțeleg de ce au nevoie cu adevărat) și rescrierea software (echipele de dezvoltare găsesc modalități mai bune de a scrie și proiecta o aplicație). Dar trebuie să faci față cu asta și în alte metode! Mai mult, pentru a reduce impactul negativ al reprelucrării, este nevoie de un model iterativ, care este o caracteristică a Agile.

Avantaje și dezavantaje ale utilizării Agile

Pro:

1. implicarea părților interesate- echipa are mai multe oportunități de a înțelege dorințele clientului. Iar livrarea timpurie și frecventă de software sporește încrederea părților interesate în echipa de proiect și o implicare și mai profundă în proiect.
2. livrare anticipată și previzibilă- modelul de dezvoltare prin iterații (intervale scurte de la 1 la 6 săptămâni) oferă flexibilitate, accelerează lansarea lansării produsului.
3. concentrați-vă pe valoarea afacerii- Colaborarea cu clientul asigură că echipa înțelege cum să facă produsul cât mai valoros pentru consumator.
4. îmbunătățirea continuă a calității- testarea în timpul fiecărei iterații, împărțirea build-ului final în bucăți separate de cod de lucru vă permite să îmbunătățiți și să tratați erorile software înainte de lansarea produsului final.

Minusuri:

• cerințe crescute pentru echipă și clienți– fără o interacțiune strânsă între echipa de proiect și utilizatori, este imposibil să se realizeze un produs de înaltă calitate cu valoare ridicată. Și abundența de instrumente și metode în Agile pentru implementare necesită o echipă cu experiență.
• nu este potrivit pentru externalizareși proiecte în care participanții interacționează între ei doar online.
• riscul de a nu lansa niciodată versiunea finală a software-ului- acest minus, destul de ciudat, reiese din dezvoltarea iterativă și îmbunătățirea continuă a produsului - plusurile Agile.
• nu funcționează fără o viziune clară asupra obiectivelor de afaceri ale proiectului- întrucât echipa Agile este concentrată pe părțile interesate, dezvoltarea este imposibilă fără dezvoltarea obiectivelor și a unui concept de produs.

Aplicații

Pentru a gestiona proiecte cu Agile nu este potrivit pentru toate serviciile sau programele de management de proiect, deoarece fiecare are specificul său.

Dacă afacerea dvs. este înmarketing și publicitate, design, seo sau agenții digitale, apoi serviciul saas poate fi aplicat muncii întregii echipe ca întreg. Suntem recomandați .

Iată câteva trucuri de viață pentru a configura Agile

1. personalizați etichetele și stările necesare pentru funcționarea companiei dumneavoastră.
   Stările pot fi: în curs, verificare, finalizat, necesită îmbunătățiri, critic, caracteristică, plată.
   Etichetele arată adesea astfel: layout, testare, producție, concept, cod.
2. creați un proiect în așteptareși proiect de primăvară.
3. crea sarciniși liste de verificare preliminare, schițe și multe altele în restanță.
4. stabiliți cu privire la întâlniri sarcini de primăvarăși mutați-le din restanțăîntr-un sprint.
5. utilizare acces client oaspeți la sarcini pentru a avea întotdeauna comentarii consistente și actualizate asupra proiectului.
6. sărbători responsabil de sarcini astfel încât fiecare coleg să-și cunoască aria de responsabilitate și să se simtă implicat în rezultatul sprintului.

Verdict

Cu o metodologie agilă de dezvoltare a software-ului, echipele mici de proiect obțin eficiență maximă. Agile este implementat prin alte metode agile: Scrum, XP, Lean etc.

Nu poate fi implementat dintr-o lovitură, de o echipă fără experiență, într-o perioadă scurtă de timp, dar Implementare agilă va îmbunătăți interacțiunea dintre IT și afaceri, va accelera lansarea produsului pe piață, va crește valoarea produsului pentru utilizatorul final.