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

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

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

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

• Introducere
• 1. Analiza abordărilor managementului de proiect bazate pe metodologie clasică și flexibilă
• 1.1 Introducere în metodologiile agile de management de proiect
• 1.2 Critici și probleme ale managementului agil al proiectelor
• 1.3 Istoricul dezvoltării opiniilor asupra metodologiilor flexibile
• 1.4 Metodologii agile în comparație cu abordarea tradițională a managementului de proiect
• 1.5 Factori cheie de succes pentru proiectele IT care utilizează metodologii flexibile
• 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 Caracteristici etnoculturale activitati ale proiectului in Rusia
• 1.10 Tranziția la agilitate de la o abordare tradițională la managementul proiectelor
• Concluzii capitolului
• 2. Cercetare empirică KFU pentru proiecte IT
• 2.1 Metodologia cercetării
• 2.2 Ipoteze de cercetare
• 2.3 Descrierea procesului de anchetă
• 2.4 Analiza rezultatelor
• 2.4.1 Datele demografice ale respondenților
• 2.4.2 Testul de fiabilitate a 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 metodologia agilă
• 3.2 Orientări pentru realizarea unei bune retrospective
• 3.3 Echipa autoreglată 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. Transcrierea rezultatelor sondajului

Introducere

Astăzi trăim într-o lume în care informația a devenit principalul produs și resursa societății. Activitățile aproape tuturor companiilor sunt legate într-un fel sau altul de prelucrarea, depozitarea, producția și utilizarea acesteia. Astfel, tehnologia informației a devenit o parte integrantă a vieții noastre și a devenit o parte integrantă a acesteia. Societatea informaţională se caracterizează printr-o viteză enormă de dezvoltare şi schimbare. Acesta nu a fost cazul cu doar câteva decenii în urmă: un inginer ar putea obține o educație, iar aceste cunoștințe l-ar dura pentru tot restul vieții. Acum este nevoie nu doar de instruire periodică, ci și de învățare continuă pe tot parcursul vieții. Pe scurt, ritmul schimbării mediu inconjurator 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 de mediu și să creeze produsul cerut de client.

Acum, acest concept a depășit semnificativ domeniul de aplicare al dezvoltării software și a devenit, de fapt, un fel de 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 Agile (flexibilă) le este de obicei necunoscută, 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 să le acordați o atenție deosebită. În literatură, aceștia sunt numiți factori cheie de succes (CSF). Există un număr semnificativ de lucrări pe această temă în literatura străină, 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 socioculturali corespunzători diferitelor țări influențează semnificativ procesul de management. Și merită să țineți cont de acest lucru atunci când lucrați la proiecte.

Scopul acestei lucrări va fi să umple golul de cercetare: să ia în considerare factorii cheie de succes ai proiectelor IT care utilizează metodologii agile în Rusia și să ofere recomandări pentru utilizarea lor practică

Pentru a face acest lucru, va fi necesar să îndepliniți următoarele sarcini:

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

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

3. Proiectați și desfășurați un sondaj online al managerilor de proiecte IT care lucrează cu metodologii flexibile

4. Analizați rezultatele.

Obiectul lucrării îl reprezintă factorii cheie pentru succesul proiectelor.

Subiectul reprezintă factorii cheie de succes ai unui proiect IT folosind metodologii flexibile.

Pentru a formula 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 precis pe baza managerii ruși, deoarece managementul diferă în diferite țări din cauza factorilor socioculturali. Prin urmare, este necesar să se colecteze informații primare: nu există informații secundare.

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

1. Formarea unei liste primare de CFU pe baza literaturii disponibile

2. Clarificarea KFU în timpul unui interviu nestructurat cu 3 manageri de proiect

3. Întocmirea unui chestionar și testare pilot

Datele obținute au fost analizate pentru a determina dacă a existat o relație între succesul proiectului și diverse variabile. Metodele de analiză utilizate au fost coeficienții de corelație și analiza de regresie efectuată folosind SPSS.

Rezultatele studiului vor fi utile atât managerilor care lucrează deja cu metodologii agile, cât și celor care doar plănuiesc să le aplice într-unul dintre proiectele lor viitoare sau să le implementeze în organizația lor. În primul caz, recomandările dezvoltate în lucrare vor face posibilă diagnosticarea problemelor, dacă este cazul, ș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 este teoretică și reprezintă 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 prezintă un set de recomandări pentru practicieni bazate pe rezultatele cercetării.

Noutatea științifică a lucrării se datorează absenței aproape complete a cercetărilor publicate privind metodologiile agile de management de proiect în Rusia în general. Deși este absolut necesar să se țină cont de factorii socioculturali când management agil proiecte. regresia liniară a informațiilor manageriale

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 la nivel global în două abordări:

· Tradițional

Flexibil (iterativ)

Tradițional - bazat pe o planificare destul de strictă 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 acest caz, nu există posibilitatea de a reveni la fazele anterioare, motiv pentru care această metodă este uneori numită metoda cascadei. Abordarea tradițională corespunde standardului clasic de management de proiect de la PMI - PMBoK. În special, procesul de definire a managementului de proiect descrie bine:

Aplicarea cunoștințelor și abilităților, instrumentelor și tehnicilor la activitățile proiectului 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 privirea 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 flexibile reprezintă o alternativă bună la abordarea tradițională și sunt utilizate pe scară largă în diverse domenii high-tech, în special în domeniul 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 complex este atunci când 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 par mai de preferat în astfel de situații.

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. După cum este prezentat de (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 IT. Este clar că (Maylor, Brady, Cooke-Davies și Hodgson, 2006) identifică metodologii Agile specifice, cum ar fi 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 se uită și la Scrum în alte domenii decât IT. Această metodologie a demonstrat rezultate bune în alte domenii, cum ar fi construcții (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” care urmează ultimele tendințe, mai degrabă decât să se preocupe 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 vizează însuși faptul de a folosi o abordare agilă fără a înțelege principiile care stau la baza acesteia.

Ca unul dintre principalele riscuri ale unui proiect agil (Boehm & Turner, 2003), a identificat posibile erori în timpul dezvoltării, deoarece controlul extern devine mai dificil 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 este asigurat în mare măsură de acest fapt, și nu de utilizarea oricărei 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 flexibile

Metodologiile Agile sunt un întreg set de tehnici 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țiunile sunt mai importante decât procesele și instrumentele

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

· Cooperarea cu clientul este mai importantă decât acordul asupra termenilor contractului

· Dorința de a se schimba este mai importantă decât respectarea planului inițial

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

Deficiențele abordării existente au fost recunoscute 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 acestea sunt metodologii 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 rambursare.

Cea mai interesantă parte a articolului este tabelul care compară principiile din Manifestul Agile cu metodologiile abordărilor anterioare. Doar 2 puncte din 12 sunt relativ noi, iar toate celelalte au fost deja notate sau chiar aplicate în metodologiile menționate mai sus. Cu alte cuvinte, cele mai multe principii agile sunt rezultatul a mai multor decenii de dezvoltare a unor abordări alternative pentru livrarea proiectelor.

O revizuire excelentă a articolelor empirice pe tema metodologiilor Agile a fost oferită de (Dybe & Dingschyr, 2008). Au fost găsite lucrări din 1996, dintre care 36 s-au dovedit a fi empirice și au fost selectate pentru analiză. După o revizuire detaliată și sistematizare, autorii au concluzionat că există o lipsă de cercetare empitică de înaltă calitate pe acest subiect.

1.4 Metodologii agile în comparație cu abordarea tradițională a managementului de proiect

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

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

2. Un scop definit, fără o cale pentru a-l atinge

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

4. Scop și cale nedefinite

În diverse situații, o abordare tradițională poate fi mai eficientă, în timp ce în altele o abordare flexibilă poate fi mai eficientă. Într-un proiect standard cu un obiectiv clar și ușor de atins, abordarea tradițională poate fi mai eficientă și mai simplă, deoarece schimbările în viitor sunt puțin probabile. Într-o situație în care ceva este necunoscut, apare incertitudinea. Abordarea tradițională nu este foarte eficientă într-o astfel de situație: riscurile cresc, deoarece costul schimbării este foarte mare. În situații de incertitudine în ceea ce privește obiectivul, calea sau toate împreună, metodologiile flexibile funcționează mai bine, deoarece susțin schimbări în toate etapele și nu necesită o înțelegere completă a rezultatului final chiar de la început. Echipa, împreună cu clientul, poate obține rezultatul dorit în timpul procesului de creație, ceea ce reduce semnificativ riscul de a primi un produs irelevant. Autorii articolului mai notează că metodologiile flexibile, pe lângă rezolvarea problemelor, 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 care utilizează metodologii flexibile

Atunci când un manager care a urmat anterior o metodologie tradițională în munca sa decide să adopte o abordare agilă în următorul său 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 a aplica eficient noua metodologie, este important să știm care dintre ele trebuie subliniate. În același timp, în Manifestul Agile, principiile importante, dimpotrivă, sunt descrise prea abstract și nu sunt direct aplicabile în muncă. Pentru aplicațiile viitoare, sunt necesare recomandări mai specifice, așa că există deja un corp semnificativ de lucrări care descrie factorii cheie pentru succesul proiectului.

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”. Termenul a fost explicat mai detaliat (Rockart, 1979):

Factorii cheie de succes sunt „mai multe domenii cheie în care performanța pozitivă este necesară pentru ca organizația să obțină succes”. Astfel, acestea sunt cele mai importante domenii pentru management, atenția cărora este esențială pentru implementarea cu succes a proiectului. Acesta este același 20% care aduce 80% din rezultate conform principiului Pareto.

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

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

Static. Modelul presupune că o implementare sau un proiect nu se schimbă în timp, dar, în practică, la 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 CFU. S-a dovedit că cercetătorii nu au opinii unanime: sprijinul managementului, obiectivele clare și realiste, un plan detaliat sunt factorii care au primit. cel mai mare număr menționează, toate trei au fost găsite împreună în doar 17% din lucrări.

În domeniul proiectelor IT există și un anumit nivel de lucru pe această problemă, însă în acest caz nu există un consens în rândul cercetătorilor. (Misra, Kumar și Kumar, 2009) În munca lor, ei au efectuat un studiu la scară largă asupra factorilor cheie de succes în proiecte folosind metodologii flexibile. 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ă eșantionul fără precedent de 241 de respondenți, punctul forte al studiului este cadrul a 14 factori cheie de succes pentru proiecte 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. Orientarea 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 negocieri

10. Caracteristici socio-culturale

11. Cunoștințe și pregătire

Alte articole pe această temă tind să evidențieze 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 cu privire la 3 factori:

· Distribuirea echipei

· Marimea echipei

· Cunoștințe și pregătire

Sunt exprimate diferite puncte de vedere - (Dybe & Dingshyr, 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 ca toate problemele de lucru să fie discutate în detaliu. La rândul său (Misra, Kumar și Kumar, 2009), în ciuda includerii acestui factor în modelul teoretic, nu a găsit o confirmare practică a semnificației sale pentru succesul proiectului. Același rezultat a fost obținut de (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 remarcat că Scrum, ca una dintre metodologiile flexibile, este aplicabilă atât proiectelor mari (și, în consecință, echipelor), spre deosebire de Extreme Programming și altele.

Există, de asemenea, puncte de vedere contradictorii în ceea ce privește cunoștințele și pregătirea echipei: pe de o parte, o echipă cu experiență dă rezultate mai bune (Wysocki, 2012), ceea ce este destul de așteptat și confirmat de cercetări. Pe de altă parte, predarea 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 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 zone diferite (mai mult de 100, respectiv mai mult de 200)

1.6 Abordarea situațională a managementului de proiect î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. Așa sună „Legea Varietății Necesare”, formulată de matematicianul William Ashby în cartea „Introduction to Cybernetics”, în termeni mai înțeleși. A fost formulat inițial pentru sistemele tehnice și a citit după cum urmează: „Varietatea rezultatelor [ale unei situații], dacă este minimă, poate fi redusă și mai mult doar printr-o creștere corespunzătoare a varietatii disponibile autorității de reglementare” (Ashby, 2015) în capitolul 11. Dar aceeași lege funcționează și pentru alte sisteme, cum ar fi o organizație sau un proiect, mai târziu a început chiar să fie numită „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ă o popularitate tot mai mare, conform căreia este necesar să se selecteze o metodologie pentru fiecare proiect în mod individual, în funcție de o serie de factori: condiții Mediul extern, caracteristicile organizației și ale proiectului în sine. Cu un număr tot mai mare de alternative la alegerea unei metodologii, managerii de proiect se confruntă cu sarcina dificilă de a alege opțiunea potrivită.

(Howell et al., 2010) în munca lor, pe baza unei analize a literaturii de specialitate, au propus un model care să permită corelarea caracteristicilor proiectului cu cea mai eficientă metodologie.

Figura 3. Incertitudinea graficului - 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 la 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 grafic, 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ă utilizarea unei metodologii mai simplu și mai ieftin de utilizat.

În practică, managerii nu folosesc aceeași metodologie în forma ei pură - de cele mai multe ori este o combinație a două abordări. Acest instrument sau acela poate aduce anumite beneficii proiectului dacă este utilizat în condițiile potrivite.

Această abordare hibridă a fost discutată în articolele (Baird & Riggins, 2012) „Planificarea și sprintul: utilizarea unui hibrid management de proiect metodologie în cadrul unui curs capstone CIS”. Echipele de proiect ale cercetătorilor au fost grupuri de studenți care derulau un anumit proiect. Acest fapt impune, desigur, unele restricții în aplicarea rezultatelor: poate fi dificil să se transfere direct în sfera de afaceri.

Abordarea hibridă a autorilor a fost următoarea: proiectul se desfășoară în iterații scurte cu un backlog de sprint și o prezentare a lucrărilor rezultate 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. Potrivit cercetătorilor, această abordare trebuia să ajute studenții în primele etape, fără a pierde beneficiile scrumului și posibilitatea unor schimbări nestingherite chiar și ulterioare.

Rezultatele studiului au arătat că atât profesorii (reprezentând relativ clienți) cât și membrii echipei au fost mulțumiți de procesul de implementare și de produsul final. Cercetătorii au demonstrat cum să rezolve unele dintre problemele managementului agil al proiectelor, cum ar fi 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 la producerea planului. 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 de obicei numită tot ceea ce are legătură cu procesarea, stocarea și utilizarea informațiilor, dar recent, în legătură cu dezvoltarea 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 din domeniul dezvoltării software, Securitatea informațiilor, sisteme corporative.

IT, astăzi, este una dintre zonele cele mai dinamice în curs de dezvoltare. Companiile nu se pot lipsi diverse sisteme(sisteme de securitate, CRM, sisteme ERP) și servere care susțin afaceri, și fără site-uri web și pagini de pe rețelele sociale. Până în prezent cantitate semnificativă Proiectele IT sunt finalizate peste buget, peste program sau se transformă într-un eșec total. Conform raportului CHAOS Summary 2010 („CHAOS Summary 2010,” [Resursa electronică] 2010), doar 37% dintre proiecte sunt finalizate cu succes. Alți 42% se confruntă cu dificultăți cu termenele limită, bugetul sau calitatea, iar restul de 21% sunt considerați eșecuri complete. Deși există o anumită tendință pozitivă, nu există încă îmbunătățiri semnificative. 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, diferențele sunt mult mai mari decât în ​​alte domenii: un proiect de acces la sistemele de statistică guvernamentală și dezvoltarea unui sistem de control al zborului au consecințe complet diferite pentru o eroare 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

Astăzi, se acordă o influență destul de mare factorilor socioculturali care influențează managementul unei organizații sau al unui proiect. Conceptul de cultură economică națională ca set 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ției a fost prezentată de G. Hofstede: terminologia sa prezintă 5 indici care depind de cultura națională.

· Individualism – colectivism

· Distanța de putere

Evitarea incertitudinii

· Feminitate – masculinitate

· Concentrare pe termen lung

Inițial au fost identificate 4 dimensiuni, ultima, Orientarea 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 din întâmplare, când a lucrat ca psiholog la o mare corporație multinațională - IBM și a fost angajat în cercetare 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 membrii apropiati ai familiei. În țările mai colectiviste, oamenii sunt mai aproape unii de alții și se simt incluși în grup. Ei împărtășesc interese și opinii ale grupului, iar grupul îi protejează într-o oarecare măsură și îi oferă sprijin în perioadele de 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 legați de niciun grup anume și experimentează alienarea. Aceasta este o situație neobișnuită pentru ei. Pentru a evita o astfel de situație (Hofstede, 1983) sugerează să se acorde mai multă atenție relațiilor dintre oameni din proiect. Este mai bine să folosiți echipe stabilite sau să le formați din oameni din același grup. De asemenea, la planificarea termenelor, merită luat în considerare timpul necesar stabilirii relațiilor în echipă.

Distanța de putere. Următoarea dimensiune se referă la 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), în timp ce unele, dimpotrivă, încearcă să o reducă ( nivel scăzut).

Evitarea incertitudinii. În unele țări, oamenii sunt învățați că incertitudinea nu trebuie de temut, ci mai degrabă acceptată. Ei își asumă riscuri mai ușor și se simt mai confortabil cu comportamente și opinii care diferă de ale lor. Aceste țări au niveluri scăzute de evitare a incertitudinii. În schimb, țările cu un nivel înalt încearcă să „fa față” viitorului. Și pentru că viitorul este imprevizibil, oamenii din aceste țări încearcă să creeze instituții care să asigure securitatea și să reducă riscul. Aceasta ar putea fi tehnologie, legi, religii (inclusiv știință, într-un sens).

Conform a 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 au fost împărțite în mai multe grupuri. Colțul din dreapta sus corespunde modelului „familiei” - distanță de putere mare, indice de acceptare scăzut al incertitudinii. Colțul din dreapta jos este modelul „piramidă”, un indice ridicat al distanței de putere și acceptarea incertitudinii. Stânga jos - „mașină bine unsă”, indice de distanță de putere redusă și acceptare ridicată a incertitudinii. Colțul din stânga sus este „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, managementul trebuie ajustat pentru a obține rezultate mai bune.

Masculinitate și feminitate. Țări cu niveluri ridicate de divizare a rolurilor de gen (de exemplu, profesor - munca femeilor, soferul este barbat) se numesc masculin, iar cei cu cele joase se numesc feminin. Din punctul de vedere al lui Hofstede, această dimensiune nu este semnificativ legată de managementul proiectelor.

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

· Individualismul

· 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 în această direcție sunt acum desfășurate în mod activ.

În cadrul PMBoK Project Management Body of Knowledge: cultura PMI este remarcată ca una dintre factori importanți mediul organizației. „În lumina globalizării, înțelegerea influenței culturilor este critică.” Cultura devine un factor critic în determinarea succesului unui proiect.” PMBOK. Unii cercetători notează, de asemenea, că una dintre ipotezele PMBOK este că în managementul de proiect există o parte fixă ​​și o parte variabilă, care este direct influențată de factorii culturali naționali. Acest lucru este valabil mai ales pentru proiectele care implică o echipă multiculturală sau una distribuită geografic în locuri diferite. Î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 „Factori etnoculturali ai activităților de proiect în Rusia: probleme și instrumente” a prezentat un studiu al influenței factorilor etnoculturali. Într-un sondaj al managerilor de proiect din diverse companii (de la mari companii de construcții la mici companii de IT și consultanță), au fost identificate principalele domenii problematice ale managementului de proiect: gestionarea termenelor limită, a calității, a personalului și a conținutului.

Astăzi, se colectează o cantitate imensă de date despre oameni din diferite țări, inclusiv date ample despre caracteristicile etnoculturale. În special, The World Values ​​Survey (www.worldvaluessurvey.org) - retea globala sociologi care studiază schimbările în sistemele de valori, precum și impactul acestora asupra sferei sociale, politice și în alte sfere ale vieții. Pe baza datelor de pe acest portal, precum și a cercetărilor proprii ale managerilor, (Kozhevnikova, 2013) a fost întocmit un tabel cu orientările valorice ale rușilor în comparație cu americanii.

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

	Evaluarea manifestărilor la ruși (comparativ cu americanii)
Orientat spre rezultate	Mai puțin orientați spre rezultate, deși sunt conștienți de necesitatea de a-l atinge
Lucrul printre valorile vieții	Valoarea instrumentală a muncii (munca ca atingere a unor obiective străine, mai degrabă decât autorealizarea), ca o consecință, caracterul secundar al muncii în raport cu viața personală
Atitudine față de recompensă	Mai sensibil la bunuri materialeși remunerație
Formalism și cerințe	Recunoașteți o abordare mai puțin formală, dar sunteți obișnuiți cu presiunea la locul de muncă
Inițiativă și realizări	Mai puțin dispus să ia inițiativă și nu orientat spre realizare
Încredere și toleranță	Aveți niveluri mai scăzute de încredere și toleranță

Compilarea unor astfel de tabele ajută la arătarea clară a diferențelor dintre sistemele de valori ale americanilor (pe care se bazează în mare măsură teoriile managementului și managementului de proiect) și ale rușilor. Devine evidentă diferența, ceea ce nu este foarte 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 de proiect în IT și alte domenii. Faptul că rușii „acceptă 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 directă între membrii echipei. Dimpotrivă, nivelurile relativ scăzute de încredere și toleranță, precum și dorința scăzută de a lua inițiativă și o orientare slabă spre realizare sunt factori negativi. Baza aproape a oricărei metodologii flexibile de management de proiect este o echipă bine coordonată, cu gradul corespunzător de independență. Este clar că un grad scăzut de încredere și dorința de a lua inițiativă afectează negativ abilitățile echipei.

Aceste fapte arată necesitatea de a lua în considerare factorii etnoculturali î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 pur și simplu să fie conștient de prezența lor și să încerce să depășească punctele slabe și să extragă beneficii suplimentare din punctele forte.

1.10 Tranziția la agilitate de la o abordare tradițională la managementul proiectelor

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ături ale unei organizații în care metodologiile agile au devenit pe deplin încorporate în cultură și procesul de lucru. Altfel, este extrem de dificil să obții succesul. Prin urmare, una dintre sarcinile principale ale unui manager 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 sistem corporativ management de proiect. Ideea principală este că organizația se îndreaptă către implementarea completă a managementului de proiect treptat, deoarece implementarea multor instrumente este imposibilă dacă organizația nu este încă pregătită pentru aceasta. O abordare similară ar trebui aplicată metodologiilor agile. Nu este posibil să transformați instantaneu oamenii și echipele pentru a se potrivi unei abordări agile. Organizațiile și echipele au nevoie de timp pentru a înțelege treptat nu doar procedurile și procesele specifice implicate într-un proiect agil, ci și principiile fundamentale. O organizație poate începe să folosească o anumită metodologie, dar asta nu înseamnă că a fost implementată: integrată în sistemul de valori și credințe și în practicile de lucru ale personalului.

Dificultatea de a trece 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ă instruirii echipei în tehnici noi, transmiterii valorii noii metodologii către echipă, sprijinului de resurse pentru implementare și testării noii abordări (Fernandes, Ward și Arajo, 2015).

Un aspect important în timpul implementării îl reprezintă și capacitățile personalului. (Cockburn, 2002) a observat că diferențele dintre oameni îi fac mai mult sau mai puțin potriviți pentru un anumit tip de muncă. (Boehm & Turner, 2003) au dezvoltat clasificarea identificând 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, capabil să efectueze proceduri standard

1 - Poate avea abilități tehnice, dar nu pot sau nu doresc să lucreze împreună și nu împărtășesc metode comune.

Pentru a implementa cu succes metodologii flexibile, este necesar un număr suficient de angajați de tip 2 și tip 3. Dacă o organizație are o proporție semnificativă de angajați 1B inflexibili, implementarea 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, este de remarcat faptul 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ă a managementului 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ă tipic în special pentru sectorul IT. Modelul CFU 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ă un consens: cercetătorii identifică diferiți factori ca fiind cheie pentru succesul proiectului. În Rusia, practic nu există astfel de studii. Deși există diferențe obiective în ceea ce privește factorii socioculturali între țări. Ele nu ne permit să proiectăm concluziile cercetării străine asupra companiilor rusești cu un grad ridicat de probabilitate.

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

2.1 Metodologia cercetării

Metodologiile flexibile 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 condițiile de incertitudine care însoțește afacerile timpului nostru. Cu toate acestea, problema aplicării agile în practică provoacă încă controverse în rândul teoreticienilor și practicienilor. Există suficiente articole în literatura de limbă engleză referitoare la factorii cheie pentru succesul unui proiect agil, dar este greu de spus că ei evidențiază în unanimitate vreun indicator (Fortune & White, 2006). Mai mult, aceste studii studiază respondenți din diferite țări, în timp ce fiecare țară are propriile caracteristici în managementul proiectelor (Hofstede, 1983). Există foarte puține lucrări similare pe proiecte 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 de analiza a informatiilor primite

În etapa pregătitoare, a fost efectuată o analiză primară a situației problemei: 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 care au avut 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 în a doua etapă a studiului a fost realizată folosind un sondaj de la distanță a profesioniștilor IT, prin internet. În acest scop, chestionarul creat în etapa anterioară a fost postat pe forumuri tematice și grupuri de pe rețelele sociale folosind serviciul Google Docs.

Analiza informațiilor primite a fost realizată cu ajutorul SPSS. 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	Asociat cu succesul
Interacțiunea cu clienții	Asociat cu succesul
E timpul să iei decizii	Asociat cu succesul
Locația echipei	Nu are legătură cu succesul
Marimea echipei	Asociat cu succesul
Cultură corporatistă	Asociat cu succesul
Planificare	Asociat cu succesul
Control	Asociat cu succesul
	Nu are legătură cu succesul
Caracteristici personale	Asociat cu succesul
Comunicare	Nu are legătură cu succesul
Contact cu conducerea	Asociat cu succesul
Folosind software special	Nu are legătură cu succesul
Viziunea managementului	Nu are legătură cu succesul
Înțelegerea rolului	Asociat cu succesul

2.3 Descrierea procesului de anchetă

Sondajul este principala metodă de colectare a informațiilor în cercetare. Chestionarul sa bazat pe metodologia utilizată în articol (Misra, Kumar și Kumar, 2009). 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 fac schimb regulat de 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 rezultatului pe care trebuie să îl obțină 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 chestionați.

Unele întrebări au fost excluse din metodologie după discuții în timpul interviurilor cu managerii și în timpul pilotajului studiului de către studenții HSE. În special, variabila „Factori socioculturali” nu are sens în contextul acestui studiu, deoarece studiul se desfășoară într-o singură țară - Rusia, deci factorii sunt predeterminați. În studiu (Misra, Kumar și Kumar, 2009), această variabilă ține cont de diferențele dintre țările în care își desfășoară activitatea respondenții, ceea ce este incorect în acest caz.

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

· http://www.cyberforum.ru/

· http://programmersforum.ru/

· http://www.pmprofy.ru/

· http://www.microsoftproject.ru/

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

· https://www.facebook.com/

· https://www.linkedin.com/

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

Propunerea de ipoteze de cercetare

2.4 Analiza rezultatelor

Abordarea sondajului a fost în întregime cantitativă, cu excepția întrebărilor demografice. Pentru analiza datelor au fost aplicate diferite metode statistice întrebări închise. Scopul principal al studierii relației dintre variabile: 15 independente (unele au inclus mai mult de 1 întrebare) și 1 dependentă - succesul proiectului. Coeficienții de corelație Pearson au fost calculați 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 fiind reprezentate de câte 1 respondent (6%) - telecomunicații, consultanță, vânzări și finanțe.

Există o diversitate semnificativ mai mare în dimensiunea organizațiilor reprezentate:

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

Putem 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%), restul dimensiunilor echipelor fiind 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% echipe de peste 10 persoane.

Cel mai punct importantîn partea demografică a sondajului - experiență cu metodologii Agile:

Tabelul 4. Statistica descriptivă - Experiență în utilizarea metodologiilor agile

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

2.4.2 Test de fiabilitatevariabilele modelului

Au fost efectuate analize de validitate pentru variabile compuse din indicatori multipli. 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 este complet inconsecvent, 1 este 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 cea mai populară valoare de limită este 0,7. Tabelul arată rezultatele pentru variabilele compozite:

Tabelul 5. Analiza validității variabilelor

După cum puteți vedea, pentru toate variabilele valorile coeficientului sunt mai mari decât valorile de prag, astfel încât putem trage o concluzie despre fiabilitatea acestor variabile compuse.

2.4.3 Analiza corelațieivariabile independente cu succesul proiectului

Conceptul principal al studiului este analiza relației 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 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
E timpul să iei decizii
Locația echipei
Marimea echipei
Cultură corporatistă
Planificare
Control
Competența tehnică a echipei
Caracteristici personale
Comunicare
Contact cu conducerea
Folosind software special
Viziunea managementului
Î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 concluziile unui studiu (Misra, Kumar și Kumar, 2009). Cea mai puternică relație cu succesul proiectului.

Alți indicatori nu au evidențiat o relație semnificativă din punct de vedere statistic, care 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 unui sistem de management al proiectelor corporative (CPMS), elementele sale și cerințele pentru acesta. Metodologii și procese de bază de management de proiect. Caracteristicile principalelor roluri în contextul CMMS, etapele dezvoltării și implementării acestuia.

test, adaugat 13.06.2013


Esența conceptului de „proiect”. Relația dintre metodologia de management de proiect și alte discipline de management. Diferența dintre manager și proprietar. Surse ale succesului unui lider. Pârghii de management de proiect. Ciclul de viață și fazele unui proiect de investiții.

prezentare, adaugat 21.11.2011


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

lucrare de curs, adăugată 07.07.2015


Analiza tehnologiilor informaţionale existente în domeniul managementului de proiect. Dezvoltarea unei metodologii de implementare instituție educațională pachete software managementul proiectelor Microsoft Project și evaluarea eficienței utilizării acestuia.

lucrare curs, adăugată 14.01.2014


Caracteristicile etapelor de dezvoltare a managementului de proiect în Rusia. Conceptul, rolul și relevanța managementului de proiect. Forme de bază de planificare și control al activităților curente ale companiei. Caracteristici ale managementului de proiect în companiile partenere 1C:Franchisee.

lucrare curs, adaugat 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 în conditiile magazinului, caracteristici ale managementului lor în Rusia. Gestionarea eficienței, profitabilității și duratei proiectului. Activitățile oamenilor din proiecte. Factori și reguli pentru obținerea succesului în managementul proiectelor.

lucrare curs, adaugat 25.03.2008


Concept, compoziție și tipuri de proiecte. Etapele managementului de proiect într-o î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 la IT Service LLC.

teză, adăugată 18.02.2013


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

Agil („agil”) este un cuvânt care s-a auzit din fiecare cuvânt în ultima vreme. Dar ce este Agile și, cel mai important, de ce este nevoie de 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 deplaseze 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 calități destul de utile, mai ales în afaceri. Gândirea rapidă și reacția rapidă este exact ceea ce a prescris medicul pentru timpul nostru, altfel pur și simplu nu vei supraviețui: concurenții tăi te vor înghiți. 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ă te odihnești pe lauri. Fără capacitatea de a se adapta rapid la schimbare, pe care o oferă așa-numita „metodologie Agile”, devine din ce în ce mai dificil să supraviețuiești.

Nu întâmplător am pus între ghilimele expresia „Metodologie Agile”, pentru că se aude des, dar nu este în întregime corectă. Fără a intra în detalii tehnice, atunci Agile nu este o metodologie, ci un nume colectiv pentru diverse tehnici și abordări ale managementului, care:

1. Concentrează 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. Ei sugerează creșterea 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ă trecem prin puncte și să ne dăm seama de ce este important cele de mai sus pentru a fi rapid și flexibil și cum sunt atinse aceste obiective în Agile.

Concentrarea pe nevoile și obiectivele clienților

Cred că nu este nevoie să explic de ce afacerea de succes este cea care satisface nevoile clientului său mai bine decât concurenții săi. Este mai interesant să ne dăm seama ce instrumente Agile ajută la realizarea acestui lucru.

Cel mai important lucru este că concentrarea asupra clientului cu abordarea Agile apare nu numai în capul proprietarului afacerii (este 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 îi este frică și așa mai departe. Această concentrare generală ne permite să creăm soluții de ordine de mărime de mai bună calitate. Am întâlnit în mod repetat o situație în care oamenii care anterior erau responsabili pentru o mică lucrare, după ce au înțeles obiectivele clientului, au început să vină cu idei minunate, iar oamenii care erau responsabili cu dezvoltarea produsului au fost surprinși să le noteze. Sau cum, în sesiunile de dezvoltare de produse de grup, idei similare sunt perfecționate de oameni diferiți și se completează reciproc, trecând de la pur și simplu bune la excelente. Și, desigur, cum sunt apoi implementate.

„Instrumentele de lucru” în acest caz sunt sesiuni (întâlniri) pe termen scurt, dar intense ale tuturor participanților la lucru sau ale majorității cheie, în care are loc generarea și testarea diferitelor idei. Aceste întâlniri servesc la nivel de înțelegere și de concentrare: toți participanții la întâlnire la sfârșit î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ă. Structura organizatorică a organizației, procesele prin care lucrează oamenii și regulile ar trebui să fie cât mai simple posibil. Acest lucru va permite oamenilor să se concentreze asupra muncii lor, asupra valorii pe care o creează și nu asupra conformării cu reglementările și regulile. Exemple excelente ale acestei abordări pot fi găsite în multe echipe care lucrează în Scrum, cel mai popular mod de organizare a muncii î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. O foaie poate conține 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 salva de a fi nevoit să vă amintiți toate acestea. Același lucru este valabil și pentru procese. De exemplu, în Scrum, locul și ora tuturor întâlnirilor sunt strict fixate. Orice participant știe sigur că, de exemplu, următoarea iterație este planificată luni la ora 10:00, iar vineri la ora 17:30 are loc o întâlnire pentru îmbunătățirea procesului de lucru.

Și cu cât organizația este mai mare, cu atât beneficiul unei astfel de simplități este mai mare, 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 - 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. Există un risc foarte mare de a cheltui mult timp și efort pentru 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, 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 rezultat intermediar, ci, deși mic, trunchiat, sumar, dar versiunea de lucru a produsului, care poți deja să-l folosești.

Ca exemplu cel mai simplu al unui astfel de model de lucru, ne putem imagina un standard de program „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 clienți (să zicem, școlari clasele primare) 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 funcționează deja.

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 în astfel de cicluri este menționată în manifestul Agile însuși.

Utilizarea activă, sistematică a feedback-ului

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

În orice domeniu al activității umane legate de crearea a ceva nou, veți găsi un similar lucru prin experiment. Știința rachetelor, producția de avioane, produse farmaceutice, 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 unui client, sau efectuăm teste și folosim feedback-ul pentru a-l corecta), în construirea proceselor (periodic „oprim” lucrați și analizați procesul în sine, pentru a-l îmbunătăți, a scăpa de pierderi și probleme), chiar și în construirea structurii organizației și a „ajustării” relațiilor în echipe.

Exemple, din nou, 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 implicați în munca mentală nu le place să se simtă ca niște maimuțe (sau roboți), iar prin eliminarea capacității unei persoane de a lua decizii, îi luăm însăși munca mentală. Și acest lucru 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ă își asume responsabilitatea pentru ele. Este lung, dificil, dar merită. Munca nu se va opri dacă o echipă auto-organizată se confruntă cu o problemă necunoscută, necunoscută anterior. Și cine ar susține că la locul de muncă, adulții maturi și responsabili sunt mai folositori 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ă, la locul său, fără să întrebe pe nimeni, acest lucru reduce timpul de luare a deciziilor. Nu mai trimiteți o întrebare „î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ă pentru tine, dar dacă ai 30, sau 300, sau 3000... În organizațiile mari construite exclusiv pe luarea deciziilor ierarhice, paralizia voinței poate fi destul de comună.

Modalitățile populare de organizare 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 aceasta proprietarului întreprinderii?

Răspunsul este destul de simplu. Dacă a crea ceea ce vinzi nu necesită muncă mentală, ci doar acțiune mecanică, nu trebuie să te deranjezi. Plătește doar proporțional cu munca depusă și atât. Dar de îndată ce creierul lucrătorilor intră în joc, trebuie să ținem cont de principiile motivației pentru munca mentală. Și spun că oportunitatea de auto-realizare, îmbunătățirea abilităților lor, aducerea de ceva valoros în lume, 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 de mai bună calitate și mai rapid. Și, în general, un mediu plăcut la locul de muncă se adaugă la dorința de a veni acolo și de a lucra - aproape nimeni nu va contrazice acest lucru.

Și, ce este frumos, dacă sapi în același Scrum, se dovedește că toți factorii cheie de motivație pentru un lucrător în cunoștințe și/sau munca 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 exact cum să atingem obiectivul; la final ne uităm la cât de mult mai bine (sau mai rău) am lucrat 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 crearea 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 aspect este că utilizarea Agile în general este o cale, nu un scop. Nu poți „implementa” Agile și relaxa. Dacă alegeți această cale, va exista întotdeauna altceva pe care îl puteți face mai bine, o altă provocare la care trebuie răspuns, o altă problemă care trebuie rezolvată, o altă înălțime care trebuie 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ă „tragă” nicio schimbare sau să „dea cu piciorul” angajaților, astfel încât 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ă, rezultatele sunt mai mari. 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 oameni consideră că această metodă de implementare a proiectelor este singura corectă. 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 ele. Când sunt descoperite probleme, dezvoltatorii dau vina pe alți membri ai echipei.

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

Această metodologie se poate schimba cultura de afaceriîntreaga companie, unind echipa, care ulterior va începe să concureze efectiv pe piață.

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

Astăzi, există două modalități destul de utilizate pe scară largă de a stabili o relație de lucru cu un client - preț fix și contracte de 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 solicită definirea sarcinilor sub forma unei casete negre cu o anumită cantitate de informații de intrare și un anumit termen limită pentru demonstrarea rezultatului obținut. La începutul procesului, participanții evaluează sarcina și își asumă responsabilitatea pentru rezultat.

Feedback-ul are o problemă principală, care este incapacitatea clientului de a formula corect sarcina. Chiar și un plan clar documentat poate deveni irelevant după câteva luni de dezvoltare. Reconstruirea conceptului inițial poate implica revizuiri îndelungate și reelaborarea 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 punctul de plecare al proiectului. După ce parcurgeți două etape de dezvoltare, puteți lansa o versiune de testare a produsului pentru a obține feedback. Caracteristica suplimentară iată un răspuns aproape instantaneu la schimbările funcționale.

Auto-organizarea ajută la eliminarea structurii de management inutile și la eliminarea nevoii de a controla membrii echipei, fiecare dintre ei își asumă o anumită responsabilitate. Acest lucru va garanta productivitate ș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 „gestionării dezvoltării sistemelor software mari”. De atunci, conceptul de Agile a început să existe. 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 controlat

Principiile de bază ale Agile

1. Implicarea utilizatorilor este esențială;
2. Pentru a lua decizii, echipele trebuie să fie foarte eficiente;
3. Etape și ciclicitatea ca bază;
4. Se concentrează pe prezentări frecvente ale rezultatelor proiectului;
5. Se aplică regula de funcționare 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 prezentat cele 12 principii principale ale metodologiei Agile într-un infografic separat. Poti sa vezi

Caracteristicile tehnicii:

• Iterativ
• Modular
• Crescând
• Adaptiv
• Unificarea erorilor la implementarea metodelor flexibile de management de proiect sunt descrise în articol

De ce să folosiți Agile?

• Creșterea fluxului de numerar
• Controlul riscurilor
• Timp redus și costuri generale
• Creșterea responsabilității Citiți articolul despre cum să utilizați Agile pentru dezvoltare

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

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

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

Dar când ai de ales între metodele de planificare în cascadă și agile, cum vei ști care este cea 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 managementului 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 treci la pasul următor numai după ce ai finalizat cel precedent

Avantajele metodei cascadă de management de proiect

• Cel mai potrivit pentru proiecte care se ocupă de obiecte fizice - de la Proiecte de construcții la proiectele de instalare a echipamentelor
• Cerințele sunt descrise la începutul proiectului
• Cel mai bun pentru proiecte cu sarcini clar definite și pași care trebuie finalizați într-o anumită secvență (de exemplu, construirea primului etaj al unei clădiri înainte de etajul al doilea)
• Nu este necesară participarea clienților în procesul de dezvoltare
• Programele de proiect pot fi folosite în viitor pentru proiecte identice sau similare
• Domeniul complet al cerințelor este cunoscut în prealabil
• Rezultatele definite în specificațiile tehnice reduc probabilitatea apariției deficiențelor

Dezavantajele metodologiei clasice de management de proiect

• Necesită efort semnificativ pentru planificarea și programarea de înaltă calitate a proiectelor înainte de începerea lucrărilor
• Clientul vede rezultatele lucrării abia la sfârșitul proiectului și poate fi nemulțumit
• Modificările aduse domeniului 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 specificațiilor tehnice provoacă depășiri de buget
• Modificările târzii ale specificațiilor tehnice prelungesc perioada de implementare a 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 pașii ordonați ai metodei de planificare în cascadă, principiile Agile sunt de obicei implementate în cicluri rapide și iterative de lansare a produsului.

Avantajele metodologiei flexibile 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ă
• Permite corectarea rapidă a cursului pe baza feedback-ului părților interesate
• Prioritățile se concentrează pe beneficiul afacerii clientului
• Proiectul oferă echipei libertatea de a lucra creativ și eficient
• Implicarea clientului în proiect oferă o dezvoltare concentrată
• Include interacțiunea și colaborarea cu toți membrii echipei de proiect

Dezavantajele metodologiei flexibile de management de proiect

• Echipa este mereu implicată în proiect
• Nu este potrivit pentru proiecte cu cerințe și domeniu de aplicare clar definite
• Incertitudinea în domeniul de aplicare și timpul 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ă monitorizarea constantă a muncii și menținerea documentației pentru a gestiona sarcinile echipei
• Clientul poate revizui domeniul de activitate
• Pornirea rapidă poate duce la finalizarea 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ă va permite dvs. și echipei dvs. să configurați proiectul așa cum doriți.

Mult succes cu proiectele tale!

Combinând metodologia Agile și fluxul

Succesul 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 software reduce cantitatea de dezordine din proces și, prin urmare, are ca rezultat mai mult timp scurt dezvoltare și cea mai bună calitate.

Proiectele folosesc adesea o combinație de modele flexibile și în cascadă ciclu de viață dezvoltare de produs, metodologie flexibilă pentru dezvoltarea etapelor mici și metodologie de flux pentru implementarea întregului proiect.

Procesul de livrare a serviciilor

1. Definirea problemei
Companie de dezvoltare trebuie să înțeleagă și să definească cât mai exact posibil problema pe care clientul încearcă să o rezolve. În mare măsură, rezolvarea corectă a problemei este jumătate din soluție.

2. Definirea solutiei
Există câteva lucruri de luat în considerare opțiuni posibile solutii si sa le ofere clientului. Concentrați-vă pe propunerea care rezolvă cel mai bine problemele de afaceri și are beneficiul maxim.

3. Verificarea pieței
Trebuie să verificați soluția propusă folosind instrumente de marketing precum definiția mediu competitiv, tendințele industriei și clienții țintă. Aceasta se face pentru a confirma si intari in mod rezonabil solutia propusa 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 suficiente date deschise pentru a confirma conceptul. Cu un flux constant de proiecte, puteți începe propriul departament de analiști și îl puteți oferi ca serviciu separat.

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

Metodologie de dezvoltare flexibilă (structură agilă)

Gestionarea proiectelor complexe de dezvoltare software presupune utilizare eficientă resurse, prioritizarea sarcinilor, estimarea corectă a termenelor limită și managementul riscului. Metodologia agilă este utilizată pentru a reduce riscurile și a crește beneficiile pentru clienți.

Folosind metodologia Agile, diverse aspecte ale activităților echipei sunt integrate între ele, ceea ce asigură că întregul concept se bazează pe obiective corect 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 verificări periodice, clarificarea cerințelor și dezvoltarea produsului final. Metodologia agilă asigură, de asemenea, îmbunătățirea continuă, primind în același timp feedback-ul clienților pentru a evita orice surprize mai târziu în ciclul de viață.

Unicitatea metodologiei combinate:

Folosirea metodologiilor 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 vă oferă control asupra rezultatelor generale.

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

Rapid și frecvent prototipare.

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

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

Ce este Metodologia Agile?

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

Baza metodologiei agile este împărțirea proiectelor în bucăți mici lucrabile numite povești de utilizator. În funcție de prioritate, sarcinile sunt rezolvate în 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:

• Prioritizarea 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;
• Prioritatea dorinței de a schimba față de urmărirea planului creat inițial.

Metode prezente în Agile:

Termenul „Scrum” provine de la rugby, în care cuvântul înseamnă o metodă joc de echipa sub forma construirii a trei linii de catre fiecare dintre adversari si incercarea de a captura mingea. Pentru o interceptare de succes, aveți nevoie nu numai de o bună pregătire fizică, ci și de coordonarea fiecărui participant la luptă și de o înțelegere clară a obiectivului.

Metoda este folosită cu succes de companii precum Microsoft, Yahoo, Siemens Healthcare și chiar a fost descrisă de un manager de proiect de la Amazon 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. Colectarea echipă— până la 10 persoane cu abilitățile necesare pentru a crea un produs funcțional.
3. Găsi Scrum Master— monitorizează progresul proiectului, ajută echipa de proiect să facă față dificultăților.
4. Compune restante produs— pe placa Agile, acordați prioritate fiecărei cerințe de produs. Proprietarul produsului joacă un rol important în acest sens, colectând cereri de produse pentru evaluare de către echipa de backlog.
5. Programa sprinturi(iterații) - perioade de timp pentru a finaliza o anumită serie de sarcini.
6. Organiza „întâlniri” zilnice de cincisprezece minute— puneți 3 întrebări fiecărui membru al echipei: 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— implicarea părților interesate în vizionare și discuție.
8. Conduce retrospectiv— discutarea problemei și găsirea 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 cerințelor proiectului
• 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. Facilitează înțelegerea dinamicii și a nivelului de progres al echipei în proiect.

(XP)

Dezvoltatorul tehnicii, Kent Beck, a creat metoda Extreme Programming, al cărei scop este să facă față cerințelor în continuă schimbare pentru un produs software și să îmbunătățească 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 cadrul echipei;
2. testarea— testele sunt scrise chiar de programatori înainte de a scrie codul care va fi testat;
3. planificare- atât construcția 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 și se determină cerințele și valorile.

Metodologii

Puțin cunoscut în spațiile domestice management de proiect o familie de metodologii dezvoltate de Alistair Cockburn, unul dintre autorii Agile Software Development Manifesto. Cockburn sugerează clasificarea după culoare în funcție de numărul de oameni din echipă: de la 2 (Crystal Clear) la 100 (Crystal Red). Pentru proiectele mai mari sunt alocate culorile Maroon, Blue and Violet.

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

1. livrare rapidă a codului de lucru— dezvoltarea ideii unui model iterativ de dezvoltare Agile.
2. excelență prin reflecție— 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)

Dezvoltarea DSDM nu a fost munca unei persoane sau chiar a unei echipe, ci a unui consorțiu de 17 companii engleze. DSDM, ca și Extreme Programming, este folosit în primul rând 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 operare.

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

La început, echipa studiază realitatea dezvoltării aplicației și domeniul de aplicare. Lucrarea este apoi împărțită î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 în stare de funcționare.
3. ciclu de implementare- implementarea sistemului.

Dezvoltare bazată pe caracteristici (FDD)

O metodologie care precede chiar Manifestul de dezvoltare a software-ului Agile.

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

• mai mult accent pe pre-modelare
• importanță crescută (comparativ cu Agile) a raportării și a diagramelor
• care vizează dezvoltarea corporativă.

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

1. Crearea unui model general— viziunea proiectului pe baza datelor preliminare.
2. Elaborarea unei liste de proprietăți— un analog al numărului de produse restante în metodologia Scrum.
3. Planificare pe proprietăți— evaluarea complexității proprietăților de către fiecare membru al echipei.
4. Pentru fiecare proprietate- proiectare tehnică și implementare - etapa finală, la sfârșitul căreia proprietatea intră în produs și ciclul se repetă.

Dezvoltare de software

Lean Software Development nu este o metodologie, ci un set de principii ale producției lean, care vizează creșterea eficienței procesului de dezvoltare și minimizarea costurilor.

Setul include următoarele 7 principii:

1. scaparea de pierderi- tot ceea ce nu aduce un plus de valoare produsului pentru consumatorul final.
2. formare continuă— dezvoltarea continuă a echipei crește capacitatea de a îndeplini sarcinile în mod eficient.
3. luând o decizie cât mai târziu posibil— nu se acordă prioritate deciziilor spontane, ci celor gândite dezvoltate pe baza cunoştinţelor dobândite.
4. Livrare rapidă— în esență baza modelului iterativ.
5. consolidarea echipei- unul dintre principiile „Manifestului...” afirmă 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ă creați inițial un produs de înaltă calitate, pentru a nu pierde timp și resurse cu teste ulterioare și pentru a scăpa de erori.
7. văzând întreaga imagine— împărțirea unui proiect în părți separate este imposibilă fără înțelegere Statusul curent dezvoltarea, obiectivele, conceptele și strategiile software-ului dezvoltat.

Tipuri de metodologii de dezvoltare agile

Modelare agilă (AM)

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

AM este folosit ca o componentă a unei metodologii de dezvoltare software cu drepturi depline - de exemplu, programare extremă sau Dezvoltare rapidă a aplicațiilor.

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
• primirea constantă de feedback
• curajul de a lua și de a fi responsabil pentru decizii
• înțelegând că nu știi absolut 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 primordială.
• Respectarea principiilor metodologiei flexibile de dezvoltare.
• Concentrați-vă pe activități care sunt valoroase pentru proiect.
• Independență în alegerea instrumentelor.
• Configurare individuală a AUP pentru nevoile unui proiect specific.

Metoda Agile de Date (ADM)

ADM este un set de tehnici de dezvoltare software agilă iterativă care pun accent pe generarea de cerințe și soluții de proiect prin colaborarea echipelor individuale. La fel ca AUP, nu este o tehnică de sine stătătoare.

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

1. Date- baza pentru crearea oricărei aplicații.
2. Probleme cu proiectul— pot fi descoperite 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 ideală; 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ăutarea soluției optime a problemei („sweet spot”), evitând extremele.

Proces unificat esențial (EssUP)

O dezvoltare a 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 - descrierea comportamentului sistemului.
• dezvoltare iterativă - crearea de piese de lucru de cod în cicluri scurte de câteva săptămâni.
• practici de echipă – care vizează unirea echipei și creșterea eficacității acesteia.
• practici procedurale - 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 în metodologiile de dezvoltare flexibilă.

Devenirea reală (GR)

O metodologie eficientă pentru startup-uri și echipe de începători, care oferă o utilizare maximă a caracteristicilor micilor proiecte și companii: mobilitate, flexibilitate, căutare 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 este utilizat pe scară largă, deși unele elemente 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;
• Realizarea de întâlniri zilnice și retrospective la finalizarea iterațiilor;
• conceptul de micropași și testarea timpurie folosind liste de verificare;
• Metodologia de modelare agilă (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 vă va ajuta să determinați eficacitatea fiecăruia dintre ele. Metricurile sunt un astfel de instrument.

Pentru majoritatea proiectelor, 4 zone de metrici sunt 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, dar acestea nu sunt egale. Metrica Work-in-Progress determină limita sarcinii în diferite etape: cu cât este mai mare, cu atât este mai proastă;
2. Prognoza— metrica capacității: determinarea cantității ceas perfect disponibil în următorul sprint. În consecință, puteți înțelege cât timp aveți pentru muncă, cât de eficient sunt îndeplinite sarcinile și cum să finalizați 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ă la acest moment + Numărul de cerințe adăugate + Numărul de cerințe eliminate) / (numărul total de cerințe originale cerințe). Valoarea este utilizată pentru a determina timpul petrecut pentru refacerea sarcinilor;
4. Valori— în fiecare caz se calculează individual, în funcție 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 produsului pentru utilizatori. Odată cu creșterea lor, și numărul consumatorilor a crescut proporțional.

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

Nu există o singură măsură corectă sau necesară 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 și să nu devină un scop în sine. Metrica de dragul valorii este o soluție proastă.

Străbători de mituri: Agile

Popularitatea familiei de metodologie de dezvoltare flexibilă a jucat o glumă crudă și chiar și pe portalurile specializate există mituri despre unul sau altul aspect al Agile. Ne vom da seama!

Mitul #1: Agile este potrivit pentru toate proiectele.

Cea mai persistentă concepție greșită. Nicio metodă Agile în sine nu va adăuga valoare unui produs sau nu va motiva o echipă.

Mitul #2: Agil vs. Documentare.

Dezvoltarea agilă 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ă cu adevărat prioritate comunicării live.

Mitul #3: Agile și planificarea nu se amestecă.

Infirmarea acestui mit este planificarea zilnică cu stand-up-uri de 10 minute, planificarea iterativă la fiecare două săptămâni, întâlnirile de sprint etc.

Mitul #4: Agile necesită multă reluare.

În dezvoltarea agilă de software, reproiectarea vine sub două forme: reproiectarea cerințelor (utilizatorii înțeleg de ce au nevoie cu adevărat) și reproiectarea software (echipele de dezvoltare găsesc modalități mai bune de a scrie și proiecta aplicația). Dar trebuie să te ocupi de 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. Și livrarea timpurie și frecventă a software-ului crește încrederea părților interesate în echipa de proiect și îi atrage și mai adânc î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 și accelerează lansarea produsului.
3. concentrându-se pe valoarea afacerii— colaborarea cu clientul asigură că echipa înțelege cum să facă produsul cât mai valoros posibil 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 ne permite să îmbunătățim și să rezolvăm erorile software înainte ca produsul final să fie lansat.

Minusuri:

• pretenții crescute față de 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 necesită o echipă experimentată pentru implementare.
• 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, provine din dezvoltarea iterativă și îmbunătățirea continuă a produsului - avantajele Agile.
• nu funcționează fără o viziune clară asupra obiectivelor de afaceri ale proiectului— deoarece echipa Agile se concentrează 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 Nu toate serviciile sau programele de management de proiect sunt potrivite pentru Agile, deoarece fiecare are specificul său.

Dacă afacerea ta estemarketing și publicitate, design, SEO sau agenții digitale, apoi saas service poate fi aplicat întregii echipe. Suntem recomandați .

Iată câteva trucuri pentru a configura Agile

1. configurați etichete și stări, care sunt necesare pentru funcționarea companiei dumneavoastră.
   Stările pot fi astfel: în curs, verificare, finalizat, necesită îmbunătățire, critic, caracteristică, plată.
   Etichetele arată adesea astfel: layout, testare, producție, concept, cod.
2. creați un stoc de proiectȘi proiect-primavara.
3. creați sarciniși liste de verificare preliminare, schițe etc. în restanță.
4. definiți la întâlniri sarcini de primăvarăȘi mutați-le din restanță la sprint.
5. utilizare acces client oaspete 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 dezvoltarea agilă de software, echipele mici de proiect obțin eficiență maximă. Agile este implementat prin alte metode flexibile: Scrum, XP, Lean etc.

Nu poate fi implementat în grabă, de o echipă fără experiență, într-o perioadă scurtă de timp., Dar implementarea Agile va îmbunătăți interacțiunea dintre IT și afacere, va accelera timpul de lansare pe piață al produsului și va crește valoarea produsului pentru utilizatorul final.