Capitole Curs Management Proiecte 2022-2023 PDF

1 2 3 4 5 6 7 8 Efort temporar subliniază că orice proiect are un început și un sfârșit. Un proiect începe atunci când există un document oficial care declară acest lucru. Documentul va ilustra mijloacele de realizare a cheltuielilor și costurilor proiectului. Finalizarea proiectului are loc...

1 2 3 4 5 6 7 8 Efort temporar subliniază că orice proiect are un început și un sfârșit. Un proiect începe atunci când există un document oficial care declară acest lucru. Documentul va ilustra mijloacele de realizare a cheltuielilor și costurilor proiectului. Finalizarea proiectului are loc atunci când sunt realizate toate obiectivele acestuia. Există însă proiecte care se încheie atunci când se decide abandonarea proiectului pentru că obiectivele sale nu sunt rentabile sau nu pot fi realizate practic. Produs sau serviciu unic se referă la faptul că orice proiect generează livrabile diferite față de alte proiecte anterioare, nu neapărat total inovatoare, ci conținând părți substanțiale diferite pentru a justifica efortul necesar pentru dezvoltare și implementare. 9 Parte interesată (en. stakeholder) este reprezentată de persoana sau organizația interesată de rezultatele unui proiect. Clientul sau sponsorul este principala parte interesată de rezultatele unui proiect, deoarece asigură partea financiară indispensabilă dezvoltării proiectului și are cel mai mare interes în succesul acestuia. Managementul proiectelor reprezintă aplicarea unor cunoştinţe, aptitudini şi tehnici pentru activităţile proiectului cu scopul de a satisface sau depăşi nevoile şi aşteptările părţilor interesate. Deci, managementul de proiect utilizează o serie de instrumente şi tehnici pentru a gestiona proiecte. Managerul de proiect este persoana responsabilă în final pentru succesul sau eşecul proiectului. Se poate face o distincţie între termenii de proiect şi program. Un program reprezintă un grup de proiecte administrate într-un mod coordonat pentru a obţine beneficii care nu s-ar putea obţine dacă proiectele ar fi administrate separat. Livrabilul reprezintă un fragment independent funcțional al proiectului Punctul de referință reprezintă data până la care trebuie finalizate activitățile majore ale proiectului Acțiunea reprezintă activitatea întreprinsă în cadrul proiectului Riscul denotă potențialele probleme care pot să apară în cadrul proiectului Diagrama Gantt ilustrează reprezentarea grafică a acțiunilor în timp Plan: Graficul datelor de începere şi terminare ale activităţilor împreună cu informaţii despre resurse şi costuri. Un plan de bază este planul iniţial, care se salvează şi se foloseşte pentru a monitoriza progresul. Un plan interimar este un set de date salvate în timpul derulării proiectului, folosite pentru a le compara cu alte planuri interimare. Buget: Costul estimat al proiectului care se stabileşte în planul de bază (engl. “baseline”). Cost: Costul total planificat pentru o activitate, resursă, sarcină trasată sau pentru întregul proiect. Uneori este denumit „cost curent”. Resurse: Oamenii, echipamentele şi materialele folosite pentru a finaliza activităţile din proiect. Tarif de plată: Costul resurselor pe oră. Există două tipuri de tarife de plată: standard şi pentru ore suplimentare. Supra-alocare: Rezultatul atribuirii mai multor activităţi decât poate realiza o resursă în timpul de lucru disponibil. Activitate divizată: O activitate al cărei grafic de lucru este întrerupt. De exemplu, o activitate de două zile, care nu necesită execuţia prin lucru continuu, poate fi împărţită astfel încât prima zi de lucru să fie programată luni iar cea de-a doua zi – joi. Nivelare: Rezolvarea conflictelor de resurse sau a supra-alocărilor prin întârzierea sau divizarea unor activităţi. Când o resursă este nivelată, sarcinile sale sunt distribuite şi reprogramate. Dată de încheiere: Data la care o activitate este programată pentru a fi finalizată. Această dată depinde de data de începere a activităţii, durata acesteia, calendarele după care se lucrează, datele unor sarcini precedente, dependenţele faţă de alte activităţi şi alte constrângeri. Întârziere: Timpul dintre data planificată de începere a unei activităţi şi momentul în care începe efectiv lucrul la aceasta. Întârzierile sunt deseori folosite pentru a rezolva supra-alocările de resurse. Livrabil: Un rezultat concret şi măsurabil, produsul sau un element care trebuie produs pentru a finaliza proiectul sau o parte a proiectului. În mod normal, echipa proiectului şi părţile interesate decid de comun acord livrabilele înainte de începerea proiectului. 10 Managementul reprezintă îndeplinirea unor obiective prin intermediul oamenilor şi al altor tipuri de resurse. Acesta se referă la procesul de stabilire şi atingere a scopurilor prin cinci funcţii de bază: planificare, organizare, selecţie de personal, conducere şi control, folosind resurse umane, financiare şi materiale. 11 Priveşte anticiparea situaţiilor viitoare şi determinarea celei mai potrivite modalităţi de acţiune pentru îndeplinirea obiectivelor organizaţionale. Deseori considerată „prima” funcţie a managementului, planificarea pune bazele tuturor celorlalte funcţii. Planificarea e un proces continuu care implică stabilirea acţiunilor necesare pentru a răspunde la întrebări precum: ce trebuie făcut, când şi cum. De asemenea, în această fază managerul trebuie să ia în calcul şi factorii care pot ajuta sau împiedica atingerea scopului, precum şi posibilele alternative disponibile pentru atingerea sa. Prin planificare se instituie o serie de acţiuni care angajează indivizii, departamentele şi întreaga organizaţie timp de zile, luni sau chiar ani. De aceea, planificarea trebuie făcută cu atenţie, luându-se în calcul următoarele aspecte:  determinarea resurselor necesare;  identificarea numărului de oameni şi a tipurilor de calificare (personal tehnic, de supervizare sau managerial);  dezvoltarea mediului organizaţional în care se va lucra (ierarhia organizaţională);  determinarea standardelor necesare pentru evaluarea evoluţiei proiectului, astfel încât să se poată face corecţii atunci când acest lucru se impune. În funcţie de amploare sau sfera de acţiune, se pot evidenţia trei categorii de planificare: Planificarea strategică; Planificarea tactică; Planificarea operațională. 12 1. Planificarea strategică: Determină obiectivele majore ale organizaţiei. Este iniţiată şi ghidată de un management de nivel înalt, însă toate nivelurile de management trebuie să participe pentru ca planificarea strategică să dea rezultate. Acest tip de planificare îndeplineşte scopuri precum: Stabilirea unor direcţii şi angajamente pe termen lung pentru întreaga organizaţie; Implicarea mai multor niveluri de management în procesul de planificare; Dezvoltarea unui model organizaţional în care planurile subunităţilor să fie armonizate şi consistente; 2. Planificarea tactică: Priveşte mai ales implementarea planurilor strategice printr-un management de nivel mediu. Tactica este mijlocul de îndeplinire a strategiei. Planurile se referă la responsabilităţile unităţilor şi în general se concentrează pe activităţile curente şi pe termen scurt; 3. Planificarea operaţională: Se referă la îndeplinirea responsabilităţilor la nivel de post sau compartiment. Planurile pot fi: singulare (pentru activităţi care nu se repetă, de exemplu realizarea unui buget) sau continue (care includ anumite proceduri sau politici). 13 Organizarea este funcţia managementului care îmbină resursele umane şi materiale prin proiectarea unei structuri formale a sarcinilor şi autorităţii. Organizarea stabileşte deci relaţiile dintre activitate şi autoritate. În acest context, managerul trebuie să îndeplinească patru scopuri principale:  să determine ce activităţi de lucru trebuie făcute pentru atingerea obiectivelor organizaţionale;  să clasifice tipurile de activităţi şi grupurile de lucru în unităţi uşor gestionabile;  să atribuie indivizilor sarcini de lucru şi să-şi delege autoritatea într-un mod adecvat;  să proiecteze o ierarhie a relaţiilor pentru luarea deciziilor. 14 1. Studierea planurilor şi scopurilor: Planurile dictează scopurile şi activităţile curente sau viitoare. În unele situaţii, ar trebui create noi unităţi, alteori, unor unităţi existente li se conferă noi atribuţii, iar unele unităţi pot fi desfiinţate. Pot apărea noi relaţii între părţile interesate. Organizarea creează o nouă structură, noi relaţii şi le modifică pe cele existente; 2. Identificarea activităţilor necesare pentru atingerea obiectivelor: Trebuie creată o listă de sarcini începând cu cele continue şi terminând cu cele singulare; 3. Clasificarea şi gruparea activităţilor: Managerii trebuie să efectueze trei proceduri: Să examineze fiecare activitate pentru a-i determina natura generală (marketing, producţie etc.); Să grupeze activităţile în ariile corespunzătoare; Să stabilească departamentele adecvate în cadrul structurii organizaţiei; 4. Atribuirea sarcinilor şi delegarea autorităţii: Un pas critic în care se stabilesc departamentele, natura, scopul şi sarcinile fiecărui departament, împreună cu performanţele aşteptate; 5. Proiectarea unei ierarhii de relaţii: Se hotărăsc relaţiile de lucru verticale şi orizontale. Structurarea verticală rezultă într-o ierarhie de luare a deciziilor în care se ştie cine răspunde pentru fiecare sarcină. Structurarea orizontală defineşte relaţiile de lucru între departamente şi stabileşte numărul de subordonaţi ai fiecărui manager. 15 Această funcţie priveşte recrutarea, selecţionarea, instruirea şi desemnarea persoanei potrivite pentru poziţia potrivită în cadrul organizaţiei. În general, se consideră că oamenii sunt cea mai importantă resursă de care dispune organizaţia. Prin selecţia personalului, se doreşte identificarea, atragerea şi păstrarea personalului calificat pentru a ocupa poziţiile disponibile. Selecţia personalului poate fi văzută ca un proces în opt paşi: 1.Planificarea resurselor umane: Trebuie să asigure faptul că nevoile de personal ale organizaţiei vor fi satisfăcute. De obicei, se analizează planurile organizaţiei pentru a vedea ce competenţe anume vor fi necesare în viitor. După realizarea previziunilor, se stabileşte numărul de persoane care trebuie recrutate (din afara organizaţiei) sau instruite (din interior); 2. Recrutarea: Se identifică şi se atrag candidaţi care îndeplinesc cerinţele pentru posturile vacante prevăzute. Ca rezultat al analizei posturilor, se întocmesc descrierile şi specificaţiile acestora. Recrutarea efectivă se realizează prin site-uri Internet specializate, agenţíi de ocupare a forţei de muncă, legături cu universităţile, anunţuri publice în ziare etc.; 3. Selecţionarea: După recrutare, candidaţii interesaţi trebuie evaluaţi şi selecţionaţi cei ale căror competenţe se potrivesc cu cerinţele posturilor. Etapele urmărite în evaluare pot fi: completarea unor formulare, examinarea profesională, verificarea recomandărilor şi interviul; 16 4. Instalarea şi orientarea: Odată selecţionaţi, noii angajaţi trebuie integraţi în organizaţie; trebuie să li se prezinte grupul de lucru, precum şi regulamentul intern sau normele organizaţiei; 5. Instruirea şi dezvoltarea: Se încearcă îmbunătăţirea capacităţii angajaţilor de a contribui la funcţionarea eficientă a organizaţiei. Instruirea se concentrează asupra calificării angajaţilor. Dezvoltarea implică pregătirea lor pentru responsabilităţi suplimentare sau avansare; 6. Evaluarea performanţelor: Un sistem proiectat să măsoare performanţele efective ale angajaţilor în comparaţie cu standardele de performanţă prestabilite; 7. Deciziile de recompensare: Pe baza evaluării performanţelor, se pot lua decizii privind recompensele financiare, transferările, promovările sau retrogradările; 8. Încetarea relaţiilor de muncă: Managementul trebuie să fie preocupat şi de demisii, pensionări sau concedieri. 17 După crearea planurilor, structurii organizaţiei şi completarea personalului, următorul pas al procesului managerial este conducerea, adică dirijarea şi motivarea angajaţilor către obiectivele organizaţionale. Din acest motiv, conducerea este importantă mai ales la primul nivel de supervizare, deoarece la acest nivel este concentrată majoritatea angajaţilor organizaţiei. Caracteristicile cele mai importante ale funcţiei de conducere se referă la stilul de conducere (autocratic, democratic) şi la procesul de luare a deciziilor. Acestea sunt în strânsă legătură cu o serie de factori precum urgenţa situaţiei sau motivarea subordonaţilor. De asemenea, managerul ca lider trebuie să cunoască toate aspectele situaţiei curente, să estimeze impactul pe care îl vor avea deciziile sale şi să ia totdeauna în calcul elementul uman. El trebuie să atribuie sarcinile iniţiale tuturor angajaţilor, să dea ordine clare şi concise şi să urmărească modul cum sunt îndeplinite sarcinile, dând dacă este nevoie îndrumări verbale sau scrise. 18 Ultima funcţie a managementului se referă la evaluarea performanţelor organizaţiei pentru a determina dacă îşi îndeplineşte sau nu obiectivele. În această fază trebuie luate următoarele măsuri: 1. Stabilirea standardelor de performanţă utilizate pentru a măsura progresul către scop. Standardul reprezintă un mecanism de măsură cantitativă sau calitativă, destinat monitorizării performanţelor oamenilor sau proceselor. În general putem vorbi de: 2. Standarde manageriale: includ rapoarte, regulamente şi evaluări de performanţă. De exemplu, un raport lunar din partea tuturor persoanelor implicate în vânzări, centrat pe ariile cheie de interes pentru managerul de vânzări; 3. Standarde tehnice: se referă la metodele şi procesele de producţie, la materiale, echipamente, componente şi furnizori. Standardele tehnice pot veni din surse interne sau externe. De exemplu, standarde de calitate dictate de reglementări guvernamentale sau specificaţiile producătorului pentru echipamente; 4. Monitorizarea şi evaluarea performanţelor: sunt măsurate performanţele şi se determină dacă respectă standardele stabilite. Dacă o asemenea comparaţie indică faptul că rezultatele sunt acceptabile, nu este necesară nicio acţiune. În caz contrar, se trece la următorul pas: 5. Corectarea deviaţiilor de la standarde: măsurile de corecţie necesare se vor lua pe baza a trei factori – standardul, precizia măsurătorii care a indicat deviaţia şi diagnosticul persoanelor care au investigat cauzele deviaţiei. Standardele pot fi prea slabe sau prea stricte. Măsurătorile pot fi imprecise deoarece instrumentele de măsură pot fi utilizate defectuos sau prezintă ele însele defecte. Oamenii pot lua decizii greşite la hotărârea acţiunilor corective necesare. 19 Managementul proiectelor este adesea rezumat într-un triunghi: Principalii trei factori sunt timpul, costul şi domeniul de aplicare, numiţi şi tripla constrângere. Acestea formează vârfurile triunghiului având calitatea ca temă centrală:  Proiectele trebuie să fie livrate la timp.  Proiectele trebuie să se încadreze în costuri.  Proiectele trebuie să se încadreze în domeniul de aplicare.  Proiectele trebuie să îndeplinească cerinţele de calitate ale clienţilor. Dacă timpul sau banii ar fi nelimitaţi, sau cerinţele ar fi nule, nu ar mai fi nevoie de management de proiect. Din păcate, cele mai multe proiecte au o anumită limită de timp, de buget şi domeniu de aplicare. Înţelegerea triunghiului proiectului permite luarea de decizii mai bune atunci când trebuie făcute compromisuri. Dacă se ajustează o latură a triunghiului, celelalte două laturi sunt afectate. De exemplu:  Dacă se decide scăderea timpului alocat pentru finalizarea proiectului, poate rezulta o creştere a costurilor, precum şi o restrângere a domeniului de aplicare;  Dacă se decide scăderea bugetului proiectului, poate rezulta un grafic de lucru mai lung şi o scădere a domeniului de aplicare;  Dacă se decide extinderea domeniul de aplicare, proiectul poate să dureze mai mult timp şi să coste mai mulţi bani, de exemplu sub formă de resurse umane. Modificările din planul proiectului pot afecta triunghiul în diverse moduri, în funcţie de circumstanţele specifice şi de natura proiectului. De exemplu, de cele mai multe ori, scurtarea timpului de execuţie al proiectului poate creşte costurile. În alte cazuri, acestea se pot chiar diminua. 20 Din punct de vedere al triunghiului proiectului, resursele sunt considerate un element de cost. Deci, în funcţie de cum ajustăm resursele pentru mai mult sau mai puţin efort de lucru sau pentru a reflecta disponibilitatea acestora, costurile vor urca sau vor coborî în mod corespunzător. Aceste costuri sunt bazate pe tarifele de plată ale resurselor. De asemenea, se poate observa că pe măsură ce se ajustează resursele, apar modificări în graficul de lucru. De exemplu, dacă avem un număr de resurse supra-alocate şi se nivelează proiectul, graficul de lucru poate conţine acum sarcini divizate şi întârzieri, care extind data limită a terminării proiectului. În cele mai multe proiecte, cel puţin o latură a triunghiului este fixă. Pentru unele proiecte, este latura bugetului: sub nicio formă nu se vor primi mai mulţi bani pentru proiect. La altele, este latura timpului: datele nu se pot schimba. Sau este domeniul de aplicare: nu va fi permisă nicio schimbare în livrabile. Ideea este de a găsi părţile „blocate” sau fixe ale triunghiului proiectului. Aceste părţi ne spun ce se poate schimba sau ajusta dacă există o problemă. Enunţarea problemei ne poate ajuta să clarificăm ce parte a triunghiului are dificultăţi. Cunoscând care parte a triunghiului nu poate fi schimbată ne poate ajuta să aflăm ce trebuie ajustat. Aşa că, atunci când se începe optimizarea, în primul rând, se decide care dintre cele trei elemente este fix. Acesta este de obicei elementul cel mai important pentru succesul proiectului (terminarea la timp, nedepăşirea bugetului sau respectarea domeniului de aplicare convenit). Apoi, se determină pe care latură a triunghiului apare problema curentă pentru a şti la ce elemente trebuie lucrat pentru a relua bunul mers al proiectului. Dacă latura pe care a apărut problema şi latura fixă a triunghiului coincid, rămân celelalte două laturi ale triunghiului pentru a fi ajustate. De exemplu, dacă proiectul trebuie să fie terminat la timp şi problema este că proiectul necesită prea mult timp, se pot modifica resursele sau domeniul de aplicare. Dacă latura problemei este diferită de latura fixă, proiectul trebuie optimizat adaptând latura rămasă. De exemplu, dacă proiectul trebuie să fie terminat la timp, dar creşte domeniul de aplicare, mai rămâne să ajustăm numai latura costului, de exemplu, prin adăugarea de resurse. Când se ajustează o latură a triunghiului, celelalte două sunt susceptibile de a fi afectate, pozitiv sau negativ. Proiectele au întotdeauna resurse limitate, dar uneori există proiecte în care costul şi cantitatea resurselor par a fi nelimitate. Pentru managerul de proiect care încercă să finalizeze un proiect cu resurse puţine sau rare, acesta poate părea un mod minunat de a gestiona un proiect, dar de obicei aceste tipuri de proiecte vin de obicei cu cerinţe severe pentru graficul de lucru şi termenele limită. 21 Ciclul de viaţă al unui proiect defineşte începutul şi sfârşitul acestuia şi diferitele etape din cadrul lui. În diferite puncte ale ciclului de viaţă, aceste etape sunt reevaluate şi este luată o decizie dacă să se continue proiectul sau nu. Punctele dintre începutul şi sfârşitul proiectului variază considerabil în funcţie de specificul proiectului care urmează să fie realizat. În Ghidul PMBOK sunt discutate procesele de bază ale managementului de proiect. Managementul de proiect este un proces în care intră anumite resurse, acestea sunt prelucrate şi sunt produse rezultate. În cadrul proceselor de management de proiect sunt incluse şi alte procese precum: iniţierea, planificarea, execuţia şi încheierea. Pe parcursul duratei de viaţă a unui proiect, vor exista rezultate la fiecare fază. Îndeplinirea acestor rezultate duce la crearea unui produs livrabil, tangibil, verificabil – rezultatul muncii depuse în cadrul proiectului. Produsele pot fi livrate în exteriorul proiectului, sau sunt necesare pentru realizarea altor activităţi din cadrul proiectului, fiind considerate livrări interne. Există mai multe modele ale ciclului de viaţă al proiectelor, în funcţie de specificul domeniului. Modelul tipic cuprinde patru stadii, din care ultimul poate fi compus din două etape. În figura următoare este prezentat ciclul de viaţă generic al unui proiect. Stadiile ciclului de viață al unui proiect: 1. Stadiul de definire: Definirea specificaţiilor proiectului; Definirea obiectivelor proiectului; Identificarea principalelor responsabilităţi; 2. Stadiul de planificare: Planificarea graficelor de lucru calendaristice; Planificarea resurselor umane, de timp şi a bugetului proiectului; Managementul riscurilor; 3. Stadiul de execuţie şi control: Implementarea proiectului; Monitorizarea progresului înregistrat în implementare; Evaluarea, măsurarea şi controlul realizărilor intermediare; Elaborarea de previziuni şi prognoze de dezvoltare; 4. Stadiul de livrare şi finalizare: Livrarea produsului proiectului către beneficiar, incluzând activităţi de instruire, transfer de documente etc.; Realizarea unei analize post-implementare; Realocarea resurselor; Raportul final al proiectului. 22 Pe durata ciclul său de viaţă, proiectul trebuie să facă faţă în principal la două tipuri de cerinţe. Prima dintre acestea se referă la etapa de definire a problemei, în care eventualele erori pot conduce la dezvoltarea unei soluţii corecte pentru o problemă definită greşit. În faza iniţială a proiectului, nivelurile de costuri şi de personal sunt mici. Există doar câţiva oameni cheie care îşi petrec timpul lucrând la proiect. Au fost achiziţionate puţine materiale sau deloc, iar angajamentul companiei cu privire la partea financiară a proiectului nu este deplin. În această etapă există cea mai mare probabilitate ca proiectul să nu fie niciodată finalizat. Multe proiecte ajung în această fază doar pentru a fi întrerupte atunci când se stabileşte că nu se poate respecta costul de realizare sau costurile depăşesc beneficiile. În această etapă a proiectului, multe aspecte ale sale sunt necunoscute. Cea de-a doua problemă caracterizează etapa post-implementare. Orice proiect trebuie să se finalizeze cu elaborarea unei analize postimplementare, cu scopul de a identifica atât aspectele pozitive ale proiectului cât şi aspectele ce trebuie îmbunătăţite. În practică, această etapă este deseori trecută cu vederea. Astfel, în cadrul conferinţei Frontiers Conference on Proiect Management, unul dintre moderatori a întrebat audienţa formată din 400 de persoane: „Câţi dintre dumneavoastră au primit dispoziţia ca, după executarea proiectului, să elaboreze un raport de evaluare care să cuprindă concluziile finale?” La această întrebare doar 10 persoane au ridicat mâna. A doua întrebare a aceluiaşi moderator a fost: „Câţi dintre dumneavoastră aţi fost solicitaţi să prezentaţi managementului companiei ce veţi face ca să evitaţi repetarea în viitor a greşelilor făcute în executarea proiectului?” La această întrebare numai 2 persoane au ridicat mâna. Concluziile finale după executarea unui proiect sunt deosebit de importante, deoarece persoanele care nu cunosc istoricul proiectelor precedente au tendinţa de a repeta greşelile anterioare. Reticenţa unor persoane de a face o trecere în revistă a rezultatelor finale poate avea mai multe cauze. În primul rând, pe măsură ce se apropie de finalizarea proiectului, managerii devin nerăbdători să treacă la realizarea altor sarcini sau proiecte. În al doilea rând, ei nu doresc să recunoască faptul că la anumite aspecte trebuie aduse îmbunătăţiri. Uneori, această atitudine este determinată de dorinţa de a nu crea dificultăţi persoanelor a căror activitate trebuie perfecţionată. Totuşi, oricât de bine este realizată o activitate, întotdeauna este loc pentru îmbunătăţiri, iar analizele finale trebuie conduse în acest spirit. Tendinţa de a pedepsi persoanele a căror activitate prezintă deficienţe poate dăuna managerilor de proiect în elaborarea unor rapoarte de evaluare corecte. 23 Managementul proiectelor poate fi o profesie, o ocupaţie, un rol sau o activitate. Unele companii au manageri de proiecte a căror datorie este de a superviza proiecte întregi cu sute de persoane. Alte companii acordă acest titlu unor manageri începători, fiecare fiind responsabil de o mică parte dintr-un proiect mai mare. În funcţie de modul în care este structurată o organizaţie, de cultura sa organizaţională şi de obiectivele proiectului, managementul de proiect poate avea un rol informal (este realizat de către oricine, ori de câte ori este necesar) sau clar definit (X, Y şi Z sunt manageri de proiect cu normă întreagă). Uneori absenţa unui manager de proiect dedicat nu pune probleme. Programatorii şi şefii lor realizează planurile inginereşti când este nevoie şi un specialist în marketing face planificarea sau stabileşte cerinţele. Orice altă activitate de management de proiect pur şi simplu se distribuie în întreaga echipă. Poate că unii oamenii din echipă au fost angajaţi pentru interesul lor dincolo de scrierea de cod. Aceştia nu vor refuza activităţi precum planificarea, proiectarea interfaţei cu utilizatorul sau definirea strategiei de afaceri. Folosind acest mod de lucru se pot realiza optimizări semnificative. Atâta timp cât toţi membrii echipei sunt dispuşi să accepte responsabilităţi pentru a face lucrurile să meargă în mod coordonat şi să preia activităţile unui manager de proiect dedicat, aceasta înseamnă un om mai puţin, de care echipa se poate lipsi. Eficienţa şi simplitatea trebuie apreciate. Alteori, lipsa unui manager de proiect creează disfuncţii. Fără o persoană a cărei principală activitate este ghidarea efortului global, interesele individuale pot afecta direcţia echipei. În jurul rolurilor tehnice şi comerciale pot apărea tensiuni care duc la încetinirea progresului şi frustrarea celor implicaţi. De exemplu, în spitalele de urgenţă un singur medic ia deciziile privind acţiunile efectuate pentru un pacient. Acest mod de lucru accelerează luarea multor decizii şi clarifică rolul fiecărui membru din echipă. Fără o astfel de autoritate clară pentru probleme de management al proiectelor, echipele de dezvoltare pot întâmpina dificultăţi. Dacă nu există un responsabil pentru conducerea procesului de prelucrare şi sortare a defectelor, sau nimeni nu este direct responsabil pentru monitorizarea graficului de lucru şi semnalarea problemelor, aceste activităţi pot rămâne mult în urma celor bazate pe programarea propriu-zisă. Deşi mulţi programatori de vârf au suficient de multe cunoştinţe despre managementul de proiect, încât ar putea face chiar ei acest lucru, aceştia recunosc valoarea unică a unei persoane competente, dedicate, care joacă rolul de manager. 24 Managementul de proiect este în acelaşi timp: o ştiinţă deoarece presupune înţelegerea proceselor, instrumentelor şi tehnicilor, precum şi definirea şi coordonarea activităţilor care trebuie efectuate; o artă, datorită aspectelor inter-personale care se referă la conducerea oamenilor. Instrumentele şi tehnicile de management de proiect sunt încercate şi testate şi pot fi folosite cu succes la orice proiect. Aproape toate dintre acestea sunt disponibile de mulţi ani, dar au fost oarecum dificil de utilizat fără ajutorul calculatoarelor personale. De asemenea, prin organizarea într-o manieră care canalizează eforturile depuse de echipă în direcţia de realizare a proiectului, se creează o stare de înaltă motivaţie. Aceasta permite echipei să se concentreze asupra obiectivelor şi să nu fie distrasă de alte activităţi din jur. Părţile interesate trebuie să aibă puncte de contact consecvente cu echipa de proiect, iar managerul de proiect trebuie să fie o sursă sigură de informaţii cu privire la proiect şi tot ce se întâmplă în cadrul acestuia. Managerii de proiect pot fi văzuţi ca nişte manageri de întreprinderi mici. Multe din caracteristicile necesare în gestionarea unei mici afaceri sunt aceleaşi cu cele necesare pentru un bun management de proiect. În realitate, datorită faptului că mulţi manageri de proiect din ziua de astăzi au pregătirea de bază în discipline tehnice, este surprinzător faptul că aptitudinile care le sunt solicitate erau considerate anterior abilităţi neobişnuite pentru managerii tehnici. Astăzi este de aşteptat ca managerul de proiect să aibă cunoştinţe considerabile din domeniul financiar, contabilitate, vânzări, marketing, producţie, cercetare şi dezvoltare, planificare strategică şi operaţională, caracteristicile organizaţiilor, resurse umane, administraţie, gestionarea relaţiilor de muncă, motivare şi alte competenţe inter-umane. Echipa multidisciplinară a proiectului devine o entitate în sine, axată pe nevoile proiectului şi care încearcă satisfacerea acestor nevoi în cel mai bun mod posibil. 25 Managerii de proiect buni sunt greu de găsit deoarece aceştia trebuie să menţină un echilibru al atitudinilor. Un manager de proiect trebuie nu numai să fie conştient de aceste trăsături, dar şi să îşi dezvolte instinctele adecvate pentru anumite situaţii. Aceasta contribuie la ideea că managementul de proiect este o artă: necesită intuiţie, hotărâre şi experienţă de a utiliza aceste forţe în mod eficient. 1.Orgoliul / lipsa orgoliului. Datorită responsabilităţii mari pe care o au managerii de proiect, aceştia găsesc o satisfacţie personală în munca lor. Ei investesc o mare încărcătură emoţională în ceea ce fac şi, pentru mulţi, această legatură emoţională este ceea ce îi determină să menţină intensitatea necesară pentru a fi eficienţi. Dar în acelaşi timp, managerii de proiect trebuie să evite plasarea intereselor proprii înaintea proiectului. Ei trebuie să fie dispuşi să delege atât sarcini importante cât şi distractive, să împartă premiile şi recompensele cu întreaga echipă. Chiar dacă mândria poate fi o rezervă de energie, managerul de proiect trebuie să recunoască momentul în care aceasta îi stă în cale. 2. Autocraţia / delegarea. În unele situaţii, cele mai importante lucruri sunt o linie clară de autoritate şi un timp de răspuns rapid. Un manager de proiect trebuie să fie încrezător şi dispus să preia controlul şi să forţeze anumite acţiuni ale echipei. Totuşi, în general scopul este să se evite asemenea situaţii extreme. Un proiect gestionat bine trebuie să creeze o atmosferă unde sarcinile pot fi delegate iar colaborarea este eficientă. 3. Tolerarea ambiguităţii / urmărirea perfecţiunii. Primele faze ale oricărui proiect conţin experienţe deschise şi de o fluiditate mare, acolo unde necunoscutul surclasează cunoscutul. Ambiguitatea controlată este esenţială pentru scoaterea la suprafaţă a ideilor bune, şi un manager de proiect ar trebui cel puţin să respecte acest lucru dacă nu să îl faciliteze şi să îl controleze. Dar în alte momente, mai ales în fazele finale ale proiectului, disciplina şi precizia sunt vitale. Este nevoie de inteligenţă pentru a discerne între cazul în care perfecţiunea este răsplatită şi cazul în care o soluţie mediocră, rapidă şi neglijentă este suficientă. 26 4. Comunicarea orală / scrisă. Indiferent cât este de axată o organizaţie de dezvoltare software pe comunicarea electronică, aptitudinile de comunicare orală sunt de o importanţă critică pentru managementul proiectului. Întotdeauna vor fi întâlniri, negocieri, discuţii pe hol şi sesiuni de brainstorming, iar managerul de proiect trebuie să fie eficient atât la înţelegerea cât şi la comunicarea ideilor faţă în faţă. Cu cât organizaţia sau proiectul este mai mare, cu atât abilităţile scrise devin mai importante. În ciuda preferinţelor lui personale, un manager de proiect trebuie să îşi dea seama când este mai eficientă comunicarea scrisă şi când este de preferat comunicarea orală. 5. Recunoaşterea complexităţii / promovarea simplităţii. Mulţi oameni cad victime complexităţii. Când sunt puşi faţă în faţă cu o provocare organizaţională sau inginerească complexă, ei tind să se concentreze asupra detaliilor şi să piardă din vedere imaginea de ansamblu. Alţii refuză complexitatea şi iau decizii proaste pentru că nu înţeleg întru totul subtilităţile problemelor apărute. Echilibrul aici poate fi găsit văzând care perspectivă asupra proiectului e mai folositoare, prin schimbarea sau combinarea perspectivelor. Managerii de proiect trebuie să determine echipa să urmărească simplitatea şi calitatea, ără a minimiza însă complexitatea necesară scrierii unui cod bun şi de încredere. 6. Răbdarea / nerăbdarea. În cele mai multe cazuri, managerul de proiect este persoana care împinge la acţiune, forţându-i pe ceilalţi să se concentreze asupra sarcinilor de lucru. Dar în unele situaţii, nerăbdarea se întoarce împotriva proiectului. Unele activităţi politice, birocratice sau inter-organizaţionale sunt consumatoare de timp. De exemplu, dacă o persoană importantă trebuie să vină la un moment dat la o întâlnire, managerul de proiect trebuie să fie răbdător. A şti când să forţezi o problemă şi când să te retragi şi să laşi lucrurile să meargă de la sine este o calitate pe care trebuie să şio dezvolte managerii de proiect. 7. Curajul / frica. O idee greşită este aceea că oamenilor curajoşi nu le este frică. De fapt, curajoşi sunt cei cărora le este frică, dar cu toate acestea aleg să acţioneze. Un manager de proiect trebuie să aibă o bună înţelegere a tuturor lucrurilor care pot merge rău şi să le considere posibile. Dar, cu toate acestea, el trebuie să aibă curajul necesar pentru a accepta provocări mari. 8. Încrederea / scepticismul. Nu este nimic mai important pentru moralul echipei decât un lider respectat care crede în ceea ce face. Un manager de proiect trebuie să aibă încredere în munca realizată şi să vadă adevărata valoare a obiectivelor ce vor fi atinse. În acelaşi timp, este nevoie de o doză de scepticism (nu cinism) referitoare la modul în care se fac anumite lucruri. Cineva trebuie să critice şi să pună întrebări, să conteste presupunerile altora şi să aducă problemele dificile la lumină. Cheia este capacitatea de a pune întrebări referitoare la presupunerile cuiva, de a-i contesta ipotezele fără a zdruncina încrederea echipei în munca pe care o face. Persoanele cu astfel de abilităţi se găsesc foarte rar, cu atât mai mult cele care au capacitatea de a le echilibra eficient. Multe dintre greşelile pe care le face un manager de proiect sunt cauzate de ineficienţa echilibrării acestor forţe conflictuale. Totuşi, oricine poate deveni mai bun în recunoaşterea, înţelegerea şi apoi în creşterea abilităţilor sale de a ţine forţele în echilibru. Privind această listă de forţe conflictuale inevitabile, managerul de proiect poate reconsidera ce face şi de ce, pentru a lua decizii mai bune. 27 Una din temerile managerilor de proiect începători este aceea că succesul necesită schimbare: modificare, construire sau distrugere. Menţinerea stării curente, în afara unui scop explicit pentru aceasta, este o practică ineficientă. Lumea se schimbă tot timpul şi dacă un site web sau orice alt proiect este la fel de bun astăzi cum era anul trecut, asta înseamnă că a rămas în urmă deoarece atingerea scopurilor a fost rău direcţionată sau execuţia proiectului a eşuat într-un fel. Este greu de ignorat imensa presiune care cade pe umerii managerului de proiect, dar aceasta este inevitabilă. Există întotdeauna un mod nou de a gândi, altceva de învăţat şi aplicat, sau un nou proces care face munca mai uşoară şi mai eficientă. Un manager bun are nevoie de abilităţi de lider, iar un lider bun necesită abilităţi de management. Oricine e implicat în managementul proiectelor este responsabil de câte un pic din amândouă, indiferent ce scrie în fişa postului. Revenind la chestiunea presiunii, sunt mulţi manageri care fug de momentele în care trebuie să fie şi lideri, de exemplu când echipa are nevoie de cineva care să ia o decizie, şi se complac în a urmări eforturile altora în loc să faciliteze sau chiar să participe la ele. Dacă cineva stă tot timpul şi ţine scorul sau priveşte de pe margine, acesta este mai potrivit pentru un post de contabil. Când cineva cu un rol de lider răspunde la presiune ferindu-se de ea, el nu conduce, ci se ascunde. Managerii de proiect laşi sau ineficienţi tind să fie împinşi înspre periferia proiectului, de unde aduc puţină valoare acestuia. Unii manageri în această situaţie se rezumă la a cuantifica lucruri care nu trebuie cuantificate. Nesiguri de ce ar trebui să facă sau prea speriaţi să facă ce trebuie făcut, ei îşi ocupă timpul cu lucruri secundare. Cu cât spaţiul dintre manager şi proiect creşte, cu atât mai mult creşte şi timpul alocat verificării tabelelor, listelor sau rapoartelor. Este posibil ca managerul de proiect să ajungă să creadă în timp că datele şi procesele sunt chiar proiectul. El se bazează pe lucruri mai puţin importante cu care se lucreză mai uşor precum fişe de lucru şi rapoarte, în pofida lucrurilor importante care se rezolvă mai greu, cum ar fi efortul de planificare sau programare. Ar putea ajunge să creadă că dacă urmează perfect o anumită rutină şi verifică rapoartele, proiectul este garantat să aibă succes şi, mai cinic, orice greşeală care apare nu este din vina lui. Pentru a minimiza posibilitatea confuziilor, managerii de proiect buni rezistă tentaţiei de a defini limite stricte asupra muncii pe care sunt dispuşi să o facă sau nu. Ei evită să tragă o linie între sarcinile referitoare la managementul proiectului şi proiectul în sine. Utilizarea listelor de obiective implică faptul că există un proces bine definit care garantează un anumit final, ceea ce nu este cazul. În realitate există întotdeauna trei lucruri: un scop, un volum de lucru şi o mână de oameni. Rolurile bine definite îi pot ajuta pe aceşti oameni să se organizeze privitor la volumul de muncă, dar formarea acestor roluri nu este scopul principal. O listă de obiective poate ajuta oamenii să lucreze într-un fel care atinge scopul, dar nu lista este scopul principal. Confundarea proceselor cu scopurile este una din cele mai mari greşeli de management. În loc să se concentreze pe procese sau metode, managerii de proiect ar trebui să se concentreze asupra echipei. În mod sigur trebuie folosite sisteme simple de planificare şi monitorizare, dar ele trebuie să fie compatibile cu complexitatea proiectului şi cultura echipei. Mai exact, planificarea şi monitorizarea trebuie să ajute echipa în atingerea scopului proiectului, nu să-i împiedice. Atâta timp cât managerii de proiect sunt atenţi şi câştigă încrederea echipei, orice scăpare privind sarcinile, procesele, rapoartele sau listele necesare managementului de proiect va ieşi la lumină înainte ca problemele pe care acestea le pot rezolva să devină serioase. 28 Managerii nu sunt angajaţi să contribuie în mod liniar la munca din organizaţie, ca programatorii simpli, ci să amplifice valoarea celor din jurul lor. Metodele prin care se poate adăuga această valoare diferă de munca realizată la nivelurile inferioare. Dar pentru că mulţi manageri sunt foşti programatori care au fost promovaţi, sunt şanse ca ei să aibă mai mult talent la scrierea codului decât la conducerea unor persoane. Prezenţa unui manager ar trebui să contribuie cu ceva de altă natură decât simpla adăugare a unei contribuţii individuale. Uneori această contribuţie vine din aplanarea conflictelor şi izolarea echipei de partea politică. Alteori se referă la planificarea de nivel înalt sau găsirea unor căi de evitare a situaţiilor neaşteptate. Pentru că aceste contribuţii sunt mai greu de măsurat, mulţi manageri de proiect au o problemă cu ambiguitatea rolului lor. Cea mai bună metodă de a găsi punctele de echilibru este utilizarea diferenţei psihologice pe care o conferă poziţia de pe un nivel superior. Un manager de proiect, în timpul activităţilor sale, va petrece în mod natural mai mult timp cu oamenii din echipă decât alţii, obţinând astfel mai multe surse de informare şi o perspectivă mai largă asupra proiectului. Un manager de proiect va înţelege atât perspectiva comercială a proiectului cât şi pe cea tehnică şi va ajuta echipa să comute între cele două dacă este necesar. Această perspectivă mai largă face posibilă oferirea unor informaţii critice angajaţilor la momentul potrivit. Managerii de proiect buni trebuie să cunoască tot felul de lucruri utile referitoare la starea echipei şi a proiectului şi apoi să le aplice pentru a ajuta oamenii să-şi termine activităţile. Transferul la timp al informaţiilor este ceea ce face o echipă mediocră – bună, iar o echipă bună – excelentă. Niciun sistem de monitorizare a unui proiect nu poate înlocui complet nevoia oamenilor de a comunica între ei despre ce se întâmplă, pentru că reţelele sociale sunt întotdeauna mai puternice şi uneori mai rapide decât cele tehnice. Marile provocări precum viziunea asupra proiectului, listele de caracteristici şi graficele de lucru se reduc la o serie de numeroase provocări mai mici care sunt influenţate de cât de bine curg informaţiile într-o echipă. Managerii de proiect joacă un rol critic în menţinerea activă a acestui flux de informaţii. Managerii de proiect petrec mai mult timp cu fiecare persoană din echipă decât oricine altcineva. Ei participă la mai multe întâlniri, intră în mai multe birouri şi vorbesc cu mai mulţi colaboratori decât oricine altcineva din organizaţie. Dacă un manager de proiect e fericit, supărat, motivat sau deprimat, ceva din aceste stări de spirit se va reflecta şi asupra oamenilor pe care îi întâlneşte în fiecare zi. Ceea ce un manager aduce proiectului, bun sau rău, va fi contagios pentru restul echipei. Managerii de proiect buni câştigă de obicei un anumit respect din partea proiectanţilor, a programatorilor, a testerilor şi a celorlalte persoane cu care vin în contact. Un manager de proiect trebuie să fie în stare să realizeze strategii, planuri, să aibă idei şi un mod de gândire şi de conducere cu un impact pozitiv asupra echipei. De obicei, aceasta implică găsirea unor optimizări inteligente în fluxul zilnic de lucru sau aducerea unui impuls de entuziasm şi încurajare în direcţia potrivită la momentul potrivit. Managerii de proiect nu trebuie să fie supra-oameni sau să fie deosebit de inteligenţi. Trebuie doar să înţeleagă avantajul perspectivei lor asupra situaţiei şi să folosească acest lucru. 29 Deseori există presupuneri tacite sau chiar explicite despre modul în care un individ este recunoscut sau nu pentru performanţele sale. Dezvoltatorii sunt premiaţi pentru terminarea sarcinilor la timp. Testerii sunt recompensaţi pentru efectuarea a numeroase teste şi găsirea multor defecte. Specialiştii pentru suport telefonic sunt răsplătiţi pentru preluarea a numeroase apeluri şi rezolvarea lor şi aşa mai departe. Totuşi, folosirea unor metrici liniare pentru măsurarea performanţelor unui individ poate fi neproductivă. Aşa cum reiese din figura 1.3, când un sistem de măsurare este pus în aplicare, măsurile performanţelor încep să crească. La început, valoarea reală a organizaţiei poate de asemenea să crească. Acest fenomen are loc într-o anumită măsură pentru că angajaţii nu înţeleg sistemul de măsurare foarte bine la început, aşa că aleg calea cea mai sigură de a atinge scopurile organizaţionale. Îmbunătăţiri reale pot apărea şi pentru că primele ţinte sunt modeste şi nu determină angajaţii să înşele sistemul. Cu trecerea timpului însă, cu cât standardele organizaţiei cresc prin mărirea cotelor sau inducerea unei stări de competiţie între angajaţi, sunt folosite căi de atingere a scopurilor incompatibile cu politicile firmei. Când un grup de angajaţi vede alt grup că profită de scăpările sistemului de evaluare, grupul mai lent simte presiunea de a-i imita. Treptat, măsurile îşi pierd relevanţa pentru adevăratele performanţe, fiindcă angajaţii cedează presiunii de a înşela sistemul. Performanţele măsurate cresc, însă adevăratele performanţe scad dramatic. În acest mod sistemul de măsurare devine disfuncţional. 30 31 O metodologie de dezvoltare a programelor, numită şi proces de dezvoltare software, reprezintă o structură impusă asupra dezvoltării unui produs software. Este planul de acţiune privind succesiunea celor patru faze ale ingineriei programării: analiza, proiectarea, implementarea şi testarea. Unele companii folosesc propriile metodologii. Altele folosesc metodologii comerciale. Însă fără o metodologie adecvată, dezvoltarea produsului este haotică. Alegerea unei metodologii de dezvoltare trebuie să ţină seama de natura fiecărui proiect: mărimea echipei, bugetul, tehnologia şi instrumentele utilizate, termenele limită, procesele existente deja. 32 Abordarea „codează şi repară” (engl. “code and fix”) este cea mai rapidă şi puţin eficientă metodologie; Nu există reguli de organizare şi se ignoră etapele cheie de dezvoltare; Aceasta este metoda utilizată de obicei de companiile de la început de drum, cu puţini dezvoltatori; Recomandarea în această situaţie este introducerea treptată a unor modalităţi formale de dezvoltare şi verificare. Modelul Big Bang Modelul nu respecta nici o tendiță aparte de dezvoltare software Este utilizat pentru a ghida implementarea atunci când nici clientul nu știe exact ce dorește să obțină Recomandat pentru proiecte mici Model simplu care nu implică proceduri formale Avantaje Model simplu Necesită pre-planificare redusă și dezvoltarea produsului începe direct Necesită puține resurse Este ușor de gestionat Reprezintă un cadru propice pentru dezvoltarea echipelor de programatori începători Dezavantaje Risc sporit, nefiind recomandat pentru proiecte mari și complexe Dacă cerințele clientului nu sunt înțelese, proiectul riscă să fie abandonat și reînceput 33 Metodologia cascadă (engl. “waterfall”) a fost propusă de Winston W. Royce (1970). Procesul „curge” de la etapă la etapă, ca apa într-o cascadă. După fiecare etapă există un pas de validare. În descrierea iniţială există o întoarcere, un pas înapoi interactiv între fiecare două etape succesive. Avantaje Poate fi implementat pentru proiecte de orice dimensiune Testarea este o componentă proprie pentru fiecare etapă => abordare clară și concretă documentația fiecărei etape este realizată de către dezvoltatori, simplificând astfel urmărirea procesului simplu și ușor de folosit chiar și pentru dezvoltatorii amatori în ciuda rigidității sale, este ușor de gestionat finalizarea etapizată a proceselor reprezintă un factor de economisire a timpului Dezavantaje Clientul obţine o viziune practică asupra produsului doar în momentul terminării procesului de dezvoltare. De asemenea, modelul nu are suficientă putere descriptivă, în sensul că nu integrează activităţi ca managementul riscului sau managementul configuraţiei nu este un model recomandat pentru proiectele care presupun întreținere și este ideal pentru proiecte pe termen lung modificarea unui proces care ajunge în faza de testare nu mai este posibilă necesită specificarea clară și exactă a specificațiilor 34 Metodologia iterativă se bazează pe ideea perfecţionării incrementale a metodologiei secvenţiale. Fazele sunt dispuse în cicluri care contribuie succesiv la realizarea sistemului final. În fiecare fază se consumă un timp mai scurt, după care urmează mai multe iteraţii prin toate fazele. Pe măsură ce procesul înaintează, sunt generate din ce în ce mai multe detalii. În final, după câteva cicluri, sistemul este complet şi gata de lansare. Procesul poate continua pentru lansarea mai multor versiuni ale produsului. Este recomandată pentru proiecte unde timpul este esenţial, unde apar riscuri asociate cu o durată mare a proiectului sau unde cerinţele nu pot fi cunoscute exact de la început. Avantaje Permite feedback-ul de la fiecare echipă în ceea ce priveşte corectitudinea cerinţelor. Există etape în care pot fi corectate eventualele greşeli. Clientul poate studia rezultatul şi poate oferi informaţii importante mai ales în faza dinaintea lansării produsului. Dezvoltarea se poate adapta mai bine progresului tehnologic: pe măsură ce apar noi soluţii, ele pot fi încorporate în produs. Pot avea loc livrări regulate sau rapide. Permite prioritizarea cerinţelor. Dezavantaje De vreme ce nu există constrângeri asupra echipei de analiză să facă lucrurile cum trebuie de prima dată, acest fapt poate duce la scăderea responsabilităţii. Echipa de proiectare nu are o viziune globală asupra produsului şi deci nu poate realiza o arhitectură completă. Fiecare iteraţie necesită un timp suplimentar de planificare. Ciclurile pot continua fără o condiţie clară de terminare. Echipa de implementare poate fi pusă în situaţia nedorită în care cerinţele şi arhitectura sistemului sunt în permanentă schimbare iar renunţarea la părţi de cod deja scrise determină creşterea costurilor. 35 Metodologia spirală, propusă de Barry Boehm (1988), consideră că fiecare etapă a procesului de dezvoltare conţine o serie de activităţi comune: pregătirea: se identifică obiectivele, alternativele, constrângerile; managementul riscului: analiza şi rezolvarea situaţiilor de risc; activităţi de dezvoltare specifice pasului curent, de exemplu analiza cerinţelor sau scrierea de cod; planificarea următorului stadiu: termenele limită, resursele necesare, revizuirea stării curente a proiectului. Procesul începe în centrul spiralei. Fiecare ciclu terminat reprezintă o etapă. Pe măsură ce se parcurge spirala, produsul se maturizează. Cu fiecare ciclu, sistemul se apropie de soluţia finală. 36  Încearcă accelerarea procesului de dezvoltare prin aplicarea paralelismului între diferite iteraţii. Unitatea de bază este o casetă de timp (engl. “time box”), cu durată fixă. De aceea, un factor cheie în alegerea cerinţelor este ce poate fi realizat într-o casetă de timp. Acest fapt contrastează cu metodologiile iterative clasice în care mai întâi se hotărăşte funcţionalitatea şi aba apoi timpul de livrare. Fiecare casetă de timp este împărţită într-o succesiune de etape, ca în modelul cascadă. Duratele acestor etape trebuie să fie de asemenea aproximativ egale. Trebuie să existe o echipă dedicată pentru fiecare etapă. Când o echipă termină etapa i din caseta de timp k, îi predă livrabilul echipei dedicate fazei i+1 şi apoi începe lucrul la aceeaşi etapă din caseta de timp k+1. Dacă o casetă de timp are T zile şi n etape, prima livrare are loc după T zile, iar următoarele la câte T / n zile distanţă. Costul suplimentar pentru scurtarea timpului de livrare stă în utilizarea resurselor. De exemplu, dacă T este 9 săptămâni iar n este 3, prima livrare va fi făcută după 9 săptămâni, a doua la 12 săptămâni, a treia la 15 ş.a.m.d. Execuţia liniară a iteraţiilor ar conduce la termene de livrare de 9, 18, respectiv 27 de săptămâni. De exemplu, dacă pentru un proiect analiza şi proiectarea durează 2 săptămâni cu 2 persoane, implementarea 2 săptămâni cu 4 persoane iar testarea 2 săptămâni cu 3 persoane, pentru execuţia serială a iteraţiilor sunt necesare 4 persoane. Pentru metodologia timeboxing, sunt necesare 2+4+3 = 9 persoane. 37 Metodologia ecluză (engl. “watersluice”), propusă de Ronald LeRoi Burback (1998), combină progresul constant al metodologiei secvenţiale cu incrementele iterative ale metodologiei ciclice. În prima etapă, schiţa de principiu, echipele lucrează iterativ la toate fazele problemei. Echipa de implementare se concentrează asupra sarcinilor critice. Unul din scopurile acestei etape este de a se convinge echipele că proiectul este fezabil, că o soluţie poate fi găsită şi pusă în practică. În cea de a doua etapă, de prototip, cerinţele sunt îngheţate. După ce sarcinile critice au fost terminate, echipa de implementare se poate concentra pe extinderea acestora. Unul din scopurile acestei etape este de a convinge persoanele din afara echipelor (părţile interesate) că o soluţie este posibilă. În versiunile alfa şi beta, arhitectura este îngheţată, iar accentul cade pe implementare şi asigurarea calităţii. Rolul acestei etape este de a convinge clienţii că aplicaţia va fi un produs adevărat. Înainte de lansarea produsului, implementarea este îngheţată şi accentul cade pe testare. Scopul este realizarea unui produs competitiv. 38 Modelul V (germ. “V-Modell”) evidenţiază testarea pe tot parcursul ciclului de dezvoltare. A fost creat pentru reglementarea dezvoltării produselor software în administraţia federală germană. Modelul poate fi considerat o extensie a metodologiei cascadă, însă pune accentul pe relaţia dintre fiecare fază de dezvoltare şi faza de testare asociată. Trecerea la faza următoare se face numai după ce toate livrabilele din faza curentă au trecut testele de verificare şi validare. Avantaje metodologia ideală datorită simplității de folosire înainte de scrierea efectivă a codului se efectuează teste referitoare la procesele de planificare și proiectare eliminând eventualele erori erorile sunt identificate încă din etapele preliminare prevenind propagarea lor ideal pentru proiecte mici cu specificații clare și limitate Dezavantaje cel mai puțin flexibil model nu există prototipuri după etapa inițială de implementare măsurarea erorilor la începutul procesului poate fi consumatoare de timp o modificare neplanificata în mijlocul procesului este dificil de documentat în documentele de testare. 39 Acest model de dezvoltare apelează la formalismul şi rigoarea matematicii pentru construirea specificaţiilor. Metodele formale sunt potrivite în special pentru sisteme cu cerinţe critice. Avantaje: precizia obţinută prin specificarea formală; păstrarea corectitudinii în timpul transformării specificaţiilor în cod executabil; oferă posibilitatea generării automate de cod; verificarea consistenţei şi testarea prin metode similare demonstrării automate de teoreme. Dezavantaje: specificarea formală este de obicei o barieră de comunicare între client şi analist; necesită personal foarte calificat, deci mai scump; folosirea impecabilă a tehnicilor specificării formale nu implică neapărat obţinerea de programe sigure, deoarece anumite aspecte critice pot fi omise din specificaţii. 40 Programare extremă (engl. “eXtreme Programming”) este o metodologie „agilă”, potrivită dezvoltării rapide de aplicaţii, propusă de Kent Beck (1996). Dintre caracteristicile XP, amintim următoarele: Echipa de dezvoltare nu are o structură ierarhică. Fiecare contribuie la proiect folosind maximul din cunoştinţele sale; Scrierea de cod este activitatea cea mai importantă; Proiectul este în mintea tuturor programatorilor din echipă, nu în documentaţii, modele sau rapoarte; La orice moment, un reprezentant al clientului este disponibil pentru clarificarea cerinţelor; Codul se scrie cât mai simplu; Se scrie mai întâi cod de test; Dacă apare necesitatea rescrierii sau eliminării codului, aceasta se face fără milă; Modificările aduse codului sunt integrate continuu, de câteva ori pe zi; Se programează în perechi. Echipele se schimbă la sfârşitul unei iteraţii (1-2 săptămâni); Se lucrează 40 de ore pe săptămână, fără lucru suplimentar. 41 Finalizarea unui proiect presupune în acest caz flexibilitatea și capacitatea de a face schimbări pentru a progresa într-un mediu necunoscut și agitat. Metodologia AGILE grupează o serie de metode și practici bazate pe valorile și principiile descrise în manifestul AGILE. Soluțiile metodologiei AGILE presupun evoluția unor echipe inter- funcționale care apelează la practici de dezvoltare diferite pentru a acoperi nevoile proiectului oferind flexibilitate la schimbare în cadrul procesului de dezvoltare software. Avantaje: Schimbările – sunt înțelese și recunoscute, însă acestea nu incomodează dezvoltarea proiectului având un impact pozitiv atât asupra proiectului cât și asupra echipei. Opțiuni creative – sunt permise îmbunătățiri și modificări pe durata procesului de dezvoltare încurajând creativitatea în proiectarea codului. Cost și buget – procesul de dezvoltare software necesită estimarea costurilor la începutul unei iterații, permițând echipei să distribuie resursele în mod adecvat pe parcursul procesului de dezvoltare. Rezultate de înaltă calitate – procesul de dezvoltare software livrează produse de calitate superioară prin divizarea proceselor care facilitează testarea și mentenanța reducând erorile și crescând calitatea produsului final. Comunicarea clară – interacțiunile dintre client, dezvoltatori și alți membri ai echipei de proiectare asigură ca proiectul să își urmărească cu claritate obiectivele. Dezavantaje: Pot exista probleme privind claritatea specificațiilor în cazul în care clientul nu este foarte sigur în privința fluxului evenimentelor, afectând atât etapa de proiectare cât și bugetul proiectului. Tehnologiile AGILE sunt axate pe dezvoltarea de software funcțional și nu pe documentare. Lipsa unei documentații de bază poate reprezenta un obstacol în cadrul proiectării. Tradiționaliștii critică tehnologiile AGILE pentru metodele lipsite de strictețe și pentru lipsa unor structuri solide de susținere. 42 Manifest pentru dezvoltarea agilă de software (2001) Descoperim continuu metode mai bune pentru dezvoltarea de software prin aplicarea acestora şi prin ajutorul acordat altora pentru a le aplica. Astfel, am ajuns să preţuim: Oamenii şi interacţiunile mai mult decât procesele şi instrumentele Software-ul funcţional mai mult decât documentaţia cuprinzătoare Colaborarea cu clienţii mai mult decât negocierea contractelor Adaptarea la schimbare mai mult decât respectarea unui plan Mai exact, deşi elementele din dreapta sunt valoroase, le preţuim mai mult pe cele din stânga. Principiile Manifestului agil 1. Prima noastră prioritate este aceea de a satisface clienţii prin livrări neîntârziate şi continue de software valoros. 2. Acceptăm schimbarea cerinţelor, chiar şi mai târziu în procesul de dezvoltare. Procesele agile valorifică schimbarea în avantajul competiţional al clientului. 3. Livrăm frecvent software funcţional, de la câteva săptămâni până la câteva luni, preferând intervalele de timp mai scurte. 4. Oamenii de afaceri şi dezvoltatorii trebuie să lucreze zilnic împreună pe parcursul proiectului. 5. Construim proiecte în jurul persoanelor motivate. Le oferim mediul şi sprijinul de care au nevoie şi avem încredere în ei că vor finaliza lucrarea. 6. Metoda cea mai eficientă şi eficace pentru comunicarea informaţiilor către şi în cadrul echipei de dezvoltare o reprezintă conversaţia faţă în faţă. 7. Software-ul funcţional este principala măsură a progresului. 8. Procesele agile promovează dezvoltarea durabilă. Sponsorii, dezvoltatorii şi utilizatorii trebuie să fie capabili să menţină un ritm constant pe timp nedefinit. 9. Atenţia continuă pentru superioritate tehnică şi proiectare bună sporeşte agilitatea. 10. Simplitatea – arta maximizării cantităţii de muncă neefectuată – este esenţială. 11. Cele mai bune arhitecturi, cerinţe şi proiectări provin din cadrul echipelor care se organizează singure. 12. La intervale regulate, echipa reflectează asupra modului în care poate deveni mai eficace şi apoi îşi modifică în mod corespunzător comportamentul. Carta drepturilor dezvoltatorului: Ai dreptul să ştii ceea ce se cere, prin cerinţe clare, cu declaraţii clare de prioritate; Ai dreptul să spui cât îţi va lua să implementezi fiecare cerinţă, şi să îţi revizuieşti estimările în funcţie de experienţă; Ai dreptul să îţi accepţi responsabilităţile, în loc ca acestea să-ţi fie atribuite; Ai dreptul să faci treabă de calitate în orice moment; Ai dreptul la linişte, distracţie şi la muncă productivă şi plăcută. Carta drepturilor clientului: Ai dreptul la un plan general, să ştii ce poate fi făcut, când, şi la ce preţ; Ai dreptul să vezi progresul într-un sistem care rulează şi care se dovedeşte că funcţionează trecând teste repetabile pe care le specifici tu; Ai dreptul să te răzgândeşti, să înlocuieşti funcţionalităţi şi să schimbi priorităţile; Ai dreptul să fii informat de schimbările în estimări, suficient de devreme pentru a putea reduce cerinţele astfel ca munca să se termine la data prestabilită. Poţi chiar să te opreşti la un moment dat şi să rămâi cu un sistem folositor care să reflecte investiţia până la acea dată. 43 SCRUM reprezintă un context flexibil de aplicare a metodologiei AGILE care încurajează cooperarea pe mai multe direcții pentru gestionare a unui proiect software. Unul dintre beneficiile acestei metodologii de dezvoltare îl reprezintă comutările rapide și simplitatea de reorientare atunci când este necesar. Ciclurile cu feedback rapid și capacitatea de a identifica timpuriu problemele au transformat SCRUM într-una din cele mai cunoscute metodologii agile. Avantaje: Ciclurile de feedback rapid – deși dezvoltarea strictă a cerințelor nu acoperă întotdeauna nevoile părților interesate, SCRUM identifică din timp eventualele probleme. Identificarea timpurie a problemelor – metodologia SCRUM presupune menținerea unei durate reduse pentru întâlniri permițând echipei să își actualizeze planul. Astfel, problemele mari pot fi identificate cu ușurință și pot fi soluționate separat fără a irosi timp suplimentar. Flexibilitatea ierarhizării – SCRUM oferă flexibilitate în ierarhizarea funcționalităților comandate de client. Fiecare etapă permite gestionarea livrabilelor și încurajează progresul către produsul final. Dezavantaje Timpul și costurile trebuie estimate cu acuratețe, o estimare inadecvată afectând negativ dezvoltarea proiectului. Este o metodologie ideală pentru proiectele mari, însă nu este eficientă ca și costuri pentru proiecte de dimensiuni mici. Coordonarea între membrii echipei este foarte importantă pentru tranzițiile omogene în cadrul proceselor. Existența unor resurse calificate și experimentate reprezintă o necesitate pentru succesul metodologiei. 44 Conceptul de dezvoltare open-source (sursă la vedere) este o abordare recentă, apărută ca urmare a dezvoltării mijloacelor de comunicare prin internet: email, grupuri de discuţie, site-uri dedicate dezvoltării colaborative de software. Codul sursă este transmis utilizatorului final într-o manieră non-proprietară (fără patent), pe baza unei licenţe open-source (de exemplu GNU). Exemple clasice de produse dezvoltate în această manieră sunt sistemul de operare Linux şi browser-ul Netscape 5. O iteraţie tipică: Iniţiatorul realizează proiectarea şi implementarea, individual sau în echipă; Ceilalţi dezvoltatori sau comunitatea de utilizatori realizează testarea şi eventual depanarea; Noile funcţionalităţi dorite şi erorile depistate sunt trimise iniţiatorului proiectului; Se lansează o nouă versiune cu defectele corectate şi se analizează noile cerinţe; Se distribuie o listă de sarcini către comunitatea de utilizatori, căutându-se membri voluntari care să execute sarcinile de pe listă. Avantaje: Preţ mult mai mic decât al produselor proprietare; Ideile vin de la o întreagă comunitate de utilizatori şi programatori; Accesul la surse poate ajuta detectarea şi repararea defectelor. Dezavantaje: Lipsa garanţiilor de calitate; Risc privind cazurile de încălcare a proprietăţii intelectuale, dacă programatorii folosesc surse proprietare, greu de verificat; Unele licenţe prevăd ca produsele derivate să fie tot open-source,ceea ce obligă companiile care utilizează aceste produse să îşi publice propriul cod. 45 Companiile utilizează outsourcing-ul pentru funcţiile care pot fi dezvoltate mai ieftin în altă ţară. Un proiect tipic are următoarele etape: Iniţierea proiectului (local); Analiza cerinţelor (local); Proiectarea de nivel înalt (local); Proiectarea detaliată (offshore); Implementarea (offshore); Testarea (offshore sau local); Livrarea (local). Motive pentru outsourcing: Reducerea costurilor; Creşterea eficienţei; Concentrarea asupra obiectivelor critice ale proiectului; Accesarea flexibilă a unor resurse care altfel nu ar fi accesibile, deexemplu personal înalt calificat; Dimensiunea mare a proiectului. Dezavantaje: Control managerial mai redus; Probleme de confidenţialitate şi securitate; Risc în cazul falimentului companiei offshore; Probleme de limbă, fus orar. Concluzii Simpla adoptare a unei metodologii fără o analiză temeinică acerinţelor şi contextului de lucru nu este recomandată. Metodologia este o tactică ce trebuie considerată numai după determinarea strategiei generale a companiei. 46 47 48 Înainte de începerea proiectului, se realizează aşa-numita cartă a proiectului (engl. “project charter”), documentul care autorizează în mod formal începerea acestuia şi nominalizează managerul de proiect. Autorizarea formală presupune de obicei deschiderea unui cont pentru gestionarea costurilor proiectului. Carta proiectului este redactată de managerul de proiect, însă se distribuie sub semnătura persoanei autorizate să creeze şi să finanţeze proiectul. este important ca managerul de proiect să scrie carta deoarece este o primă ocazie ca acesta să definească modul în care vede proiectul. conţine şi justificarea financiară a proiectului. Una din justificările cele mai puternice este conceptul de beneficiu financiar pentru organizaţia care depune efortul de realizare a proiectului. Desigur, există şi alte justificări, precum răspunsul la noi reglementări guvernamentale, creşterea cotei de piaţă sau oportunităţi de a intra pe noi segmente de piaţă. 49 Diagrama pragului de rentabilitate este utilă la compararea a două sau mai multe alternative. Pentru justificarea proiectului, se compară realizarea acestuia cu alternativa de a nu-l realiza. Pe abscisă se reprezintă timpul iar pe ordonată costul total. Dacă realizarea proiectului necesită o investiţie iniţială, costul variabil se reprezintă începând cu punctul de pe axa verticală corespunzător costului total fix iniţial al proiectului. Dacă alternativa este de a nu realiza proiectul, costul iniţial este nul. La un anumit moment de timp, dacă proiectul are un beneficiu, liniile variabile se intersectează. Acesta este „pragul de rentabilitate”, când beneficiile proiectului depăşesc costurile în comparaţie cu alternativa de a nu face proiectul. Punctul corespunzător de pe axa timpului reprezintă perioada de recuperare a investiţiei (engl. “payback period”). Această metodă este potrivită când se presupune că ratele de producţie sunt constante, astfel încât costurile totale sunt liniare. Dezavantajul este că proiectele cu o recuperare rapidă a investiţiei sunt favorizate în comparaţie cu proiectele care ar putea aduce mai mult profit pe termen lung. EXEMPLU: Sistemul de automatizare a producţiei unei firme poate asigura producerea de componente cu 2 USD bucata. Un nou sistem ar putea creşte productivitatea la 1,5 USD / componentă, însă necesită o investiţie iniţială de 200.000 USD. Firma produce 25.000 de componente pe lună. Pragul de rentabilitate este afişat în figura alăturată. nr_luni x 25.000 x 2 = nr_luni x 25.000x1.5 + 200000 nr_luni = 200000/12.500 nr_luni = 16 50 Diagrama pragului de rentabilitate este utilă la compararea a două sau mai multe alternative. Pentru justificarea proiectului, se compară realizarea acestuia cu alternativa de a nu-l realiza. Pe abscisă se reprezintă timpul iar pe ordonată costul total. Dacă realizarea proiectului necesită o investiţie iniţială, costul variabil se reprezintă începând cu punctul de pe axa verticală corespunzător costului total fix iniţial al proiectului. Dacă alternativa este de a nu realiza proiectul, costul iniţial este nul. La un anumit moment de timp, dacă proiectul are un beneficiu, liniile variabile se intersectează. Acesta este „pragul de rentabilitate”, când beneficiile proiectului depăşesc costurile în comparaţie cu alternativa de a nu face proiectul. Punctul corespunzător de pe axa timpului reprezintă perioada de recuperare a investiţiei (engl. “payback period”). Această metodă este potrivită când se presupune că ratele de producţie sunt constante, astfel încât costurile totale sunt liniare. Dezavantajul este că proiectele cu o recuperare rapidă a investiţiei sunt favorizate în comparaţie cu proiectele care ar putea aduce mai mult profit pe termen lung. EXEMPLU: Sistemul de automatizare a producţiei unei firme poate asigura producerea de componente cu 2 USD bucata. Un nou sistem ar putea creşte productivitatea la 1,5 USD / componentă, însă necesită o investiţie iniţială de 200.000 USD. Firma produce 25.000 de componente pe lună. Pragul de rentabilitate este afişat în figura alăturată. nr_luni x 25.000 x 2 = nr_luni x 25.000x1.5 + 200000 nr_luni = 200000/12.500 nr_luni = 16 51 EXEMPLU: 52 EXEMPLU: 53 Elimină problema orizontului de timp a metodei pragului de rentabilitate, comparând toate alternativele pe aceeaşi perioadă de timp: durata aproximativă de viaţă a produselor rezultate din proiect. Continuând exemplul anterior, luăm acum în calcul şi variaţiile de productivitate şi cheltuielile de întreţinere ale sistemului, care apar după câţiva ani de funcţionare. În acest caz, profitul de 935.000 USD pentru investiţia de 200.000 USD reprezintă o rată de recuperare de 467,5% în 10 ani, adică o rată medie de recuperare a investiţiei de 46,75%. ROI_AVG = 935000/200000*100/10=46.75% 54 Elimină problema orizontului de timp a metodei pragului de rentabilitate, comparând toate alternativele pe aceeaşi perioadă de timp: durata aproximativă de viaţă a produselor rezultate din proiect. Continuând exemplul anterior, luăm acum în calcul şi variaţiile de productivitate şi cheltuielile de întreţinere ale sistemului, care apar după câţiva ani de funcţionare. În acest caz, profitul de 935.000 USD pentru investiţia de 200.000 USD reprezintă o rată de recuperare de 467,5% în 10 ani, adică o rată medie de recuperare a investiţiei de 46,75%. ROI_AVG = 935000/200000*100/10=46.75% 55 Metoda pleacă de la principiul că banii primiţi sau cheltuiţi în viitor valorează mai puţin decât banii din prezent. De exemplu, dacă se depun la bancă 100 USD cu o dobândă de 5%, peste un an banii vor valora 105 USD iar peste 2 ani – 110,25 USD, conform formulei: 𝑉𝑉 = 𝑉𝐴 ∙ 1 + 𝑑 𝑛 unde 𝑉𝑉 este valoarea viitoare, 𝑉𝐴 este valoarea actuală, d este dobânda iar n este numărul de ani. Invers, se poate utiliza aceeaşi formulă pentru a calcula valoarea actuală a unei sume de bani din viitor: 𝑉𝑉 𝑉𝐴 = 1+𝑑 𝑛 Considerând acelaşi nivel al dobânzii, de 5%, putem spune că 100 USD primiţi peste un an sunt echivalenţi cu 95,24 USD primiţi în prezent iar 100 USD primiţi peste 10 ani sunt echivalenţi cu 61,39 USD primiţi în prezent. Multe proiecte pornesc cu o investiţie iniţială, urmând ca beneficiile să apară ulterior. Folosind valoarea actuală, putem determina mai precis valoarea reală a unui proiect. Proiectele care generează profit mai repede vor fi considerate mai bune decât proiectele care au acelaşi profit mai târziu. 56 Valoarea actuală netă este suma intrărilor şi ieşirilor de capital ajustată la valoarea actuală. În tabelul alăturat se prezintă spre comparaţie 2 proiecte care presupun o investiţie iniţială de 100.000 USD, după care proiectul A aduce mai mult profit în primii ani, iar proiectul B aduce profit constant pe toată durata considerată, de 10 ani. Rata dobânzii se consideră 7%. Ambele proiecte au intrări totale de capital de 300.000 USD, însă primul proiect are o valoare actuală netă mai mare. Această metodă prezintă avantajul de a lua în calcul dinamica proiectului pe parcursul ciclului de viaţă, însă are şi unele dezavantaje. De exemplu, dacă în viitor apar pierderi, valorile actualizate ale acestora sunt mai mici, ceea ce ar putea conduce la un rezultat prea optimist al analizei proiectului. Totuşi, dacă valoarea actuală netă a unui proiect este negativă, aceasta nu înseamnă că proiectul trebuie respins automat. Alternativa de a nu-l realiza poate fi şi mai defavorabilă. De asemenea, pot exista alte criterii de justificare, de exemplu creşterea cotei de piaţă etc. după cum am menţionat mai sus. 57 Valoarea actuală netă este suma intrărilor şi ieşirilor de capital ajustată la valoarea actuală. În tabelul alăturat se prezintă spre comparaţie 2 proiecte care presupun o investiţie iniţială de 100.000 USD, după care proiectul A aduce mai mult profit în primii ani, iar proiectul B aduce profit constant pe toată durata considerată, de 10 ani. Rata dobânzii se consideră 7%. Ambele proiecte au intrări totale de capital de 300.000 USD, însă primul proiect are o valoare actuală netă mai mare. Această metodă prezintă avantajul de a lua în calcul dinamica proiectului pe parcursul ciclului de viaţă, însă are şi unele dezavantaje. De exemplu, dacă în viitor apar pierderi, valorile actualizate ale acestora sunt mai mici, ceea ce ar putea conduce la un rezultat prea optimist al analizei proiectului. Totuşi, dacă valoarea actuală netă a unui proiect este negativă, aceasta nu înseamnă că proiectul trebuie respins automat. Alternativa de a nu-l realiza poate fi şi mai defavorabilă. De asemenea, pot exista alte criterii de justificare, de exemplu creşterea cotei de piaţă etc. după cum am menţionat mai sus. 58 În exemplul din tabelul anterior, proiectul A a fost preferat de fapt datorită ratei dobânzii. Dacă aceasta ar fi fost 0%, ambele proiecte ar fi fost la fel de atractive. Metoda ratei interne de recuperare a investiţiei se bazează pe analiza modului de investire a banilor şi a riscurilor existente. De exemplu, o sumă de bani poate fi investită în bonuri de trezorerie care au risc practic nul dar şi o dobândă mică. Alternativ, banii pot fi investiţi pentru realizarea unui proiect, unde riscul este mai mare dar şi profiturile pot fi mai mari. La dobânzi mici, vor fi favorizate investiţiile în proiecte cu riscuri asociate dar şi cu intrări mai mari de capital. Pe măsură ce dobânda creşte, diferenţa dintre cele două tipuri de investiţii va scădea până când investiţia lipsită de risc va fi mai potrivită. Pentru această metodă de justificare financiară, se calculează rata dobânzii bonurilor de trezorerie care ar face ca investiţia în bonuri şi investiţia în proiect să fie la fel de atractive. Pentru aceasta, comparăm valoarea actuală netă a proiectului la sfârşitul ciclului de viaţă cu valoarea actuală netă a unei investiţii fără risc (0). Conform metodei, se determină dobânda limită pentru care valoarea actuală netă a ciclului de viaţă estimat al proiectului (N ani) este 0: 𝑁 𝐶𝑡 𝑉𝐴𝑛𝑒𝑡 = 𝑡 1+𝑑 𝑡=0 unde Ct sunt intrările (valori pozitive) şi ieşirile (valori negative) de capital. 59 Conform metodei, se determină dobânda limită pentru care valoarea actuală netă a ciclului de viaţă estimat al proiectului (N ani) este 0: 𝑁 𝐶𝑡 𝑉𝐴𝑛𝑒𝑡 = 𝑡 1+𝑑 𝑡=0 unde Ct sunt intrările (valori pozitive) şi ieşirile (valori negative) de capital. Rata internă de recuperare este rata de actualizare (engl. „discount rate”) la care totalul intrărilor de capital în valoare actualizată egalează totalul ieşirilor de capital la valoare actualizată. De exemplu, să considerăm proiectul A din exemplul anterior şi să analizăm fluxul de capital pentru diferite rate de dobândă (tabelul urmator). Dacă vom calcula valoarea actuală în fiecare caz, observăm că, la sfârşitul ciclului de viaţă estimat, valorile nete sunt pozitive sau negative. Ne interesează valoarea limită la care totalul este 0, care se vede că aparţine intervalului (40% – 42,5%). Se poate determina iterativ, pe baza împărţirilor succesive ale intervalului, valoarea exactă: 41,2%. 60 Conform metodei, se determină dobânda limită pentru care valoarea actuală netă a ciclului de viaţă estimat al proiectului (N ani) este 0: 𝑁 𝐶𝑡 𝑉𝐴𝑛𝑒𝑡 = 𝑡 1+𝑑 𝑡=0 unde Ct sunt intrările (valori pozitive) şi ieşirile (valori negative) de capital. Rata internă de recuperare este rata de actualizare (engl. „discount rate”) la care totalul intrărilor de capital în valoare actualizată egalează totalul ieşirilor de capital la valoare actualizată. De exemplu, să considerăm proiectul A din exemplul anterior şi să analizăm fluxul de capital pentru diferite rate de dobândă (tabelul urmator). Dacă vom calcula valoarea actuală în fiecare caz, observăm că, la sfârşitul ciclului de viaţă estimat, valorile nete sunt pozitive sau negative. Ne interesează valoarea limită la care totalul este 0, care se vede că aparţine intervalului (40% – 42,5%). Se poate determina iterativ, pe baza împărţirilor succesive ale intervalului, valoarea exactă: 41,2%. 61 Se consideră că un proiect este o investiţie bună dacă rata sa de recuperare este mai mare decât rata de recuperare a unei investiţii alternative. Cu cât este mai mare rata de recuperare, cu atât mai dezirabilă este demararea unui proiect. Astfel, rata de recuperare poate fi folosită pentru a ierarhiza diferite proiecte potenţiale pe care le-ar putea realiza o firmă. Rata internă de recuperare este un indicator al eficienţei sau calităţii unei investiţii, spre deosebire de valoarea actuală netă care reflectă mărimea investiţiei. Toate proiectele trebuie justificate, de obicei pe baza comparării costurilor cu beneficiile. În prezent, metoda cea mai utilizată pentru justificarea financiară a proiectelor este cea a ratei interne de recuperare a investiţiei. 62 63 Managementul domeniului (engl. “scope”) unui proiect se referă la gestionarea anvergurii, amplorii, întinderii, dimensiunii proiectului. Acest tip de management include procesele care garantează că proiectul include toate activităţile necesare, şi numai activităţile necesare, pentru a finaliza proiectul cu succes. Managementul domeniului se ocupă deci cu definirea şi controlul a ceea ce este inclus sau nu în proiect. Managementul domeniului include următoarele aspecte: Definirea domeniului; Crearea structurii de descompunere a activităţilor; Verificarea domeniului; Controlul domeniului. Trebuie reţinut faptul că îndeplinirea domeniului proiectului este măsurată în raport cu planul proiectului, iar îndeplinirea domeniului produsului este măsurată în raport cu cerinţele produsului. 64 Cel mai frecvent motiv pentru eşecul proiectelor este definirea deficitară a domeniului, atunci când aşteptările părţilor interesate, în special ale clientului sau sponsorului, sunt diferite de aşteptările echipei proiectului. Uneori, este dificil de convins clientul că atât el cât şi echipa au de fapt acelaşi scop în cadrul proiectului, acela de a-i oferi clientului un produs util şi cu funcţionalităţile dorite. Echipa proiectului trebuie de asemenea să îl înţeleagă pe client şi să nu devină frustrată în cazul în care acesta pare să ştie mai puţin despre proiect decât însăşi echipa. Clientul nu este un expert în realizarea proiectelor software şi de aceea a apelat la ajutorul echipei. Etapele de definire a domeniului, crearea Structurii de descompunere a activităţilor, SDA (engl. “Work Breakdown Structure”, WBS) şi verificarea domeniului au loc în mod iterativ în metodologiile agile. O SDA clasică este de obicei împărţită la nivel înalt în fazele de analiză, proiectare, implementare, testare şi apoi acţiuni de desfăşurare (engl. “deployment”). Fiecare din aceste faze este descompusă mai apoi în pachete de activităţi (engl. “work packages”). Planificarea tradiţională a unui proiect este top-down şi se bazează pe elaborarea de activităţi detaliate cu estimări şi dependenţe care ghidează graficul de lucru al proiectului cu ajutorul analizei drumului critic. Totuşi, o descompunere excesivă poate conduce la un efort de management neproductiv, la o utilizare inadecvată a resurselor şi la scăderea eficienţei de executare a lucrărilor. 65 În metodologiile agile aceste practici sunt abordate diferit. Se definesc caracteristicile (engl. “features”) de nivel înalt ale produsului şi apoi acestea sunt alocate iteraţiilor de lansare (engl. “release”). O iteraţie sau chiar o caracteristică poate fi considerată echivalentul agil al unui pachet de activităţi. Caracteristicile sunt estimate în linii generale, fără a se detalia activităţile sau resursele asociate. Când începe o iteraţie, caracteristicile alocate (şi numai acestea) sunt descompuse pe activităţi care reprezintă planul de dezvoltare. În acest mod se previne acumularea unor cerinţe detaliate care s-ar putea să nu trebuiască implementate niciodată. Durata scurtă a unei iteraţii îmbunătăţeşte capacităţile de planificare şi control şi reduce numărul de detalii şi complexitatea estimărilor. Abordarea agilă pleacă de la premisa că vor apărea schimbări dese ale cerinţelor şi deci că nu trebuie realizată o descompunere detaliată pe activităţi până în momentul în care se poate începe lucrul efectiv la o caracteristică. Tabelul de mai sus prezintă o comparaţie între abordarea clasică şi cea agilă în privinţa definirii domeniului, care în proiectele agile se numeşte planificare multinivel. 66 Într-o primă fază, sunt eliminate din listă cerinţele asupra cărora toate părţile interesate cad de acord că nu sunt necesare. S-ar putea să trebuiască eliminate în continuare unele cerinţe asupra cărora nu există un consens, pe baza analizei de fezabilitate, a priorităţilor şi a importanţei părţilor interesate. Cerinţele rămase reprezintă linia de bază (engl. “baseline”) a domeniului proiectului. În general, este importantă documentarea cerinţelor care nu au fost implementate la un moment dat, împreună cu justificarea deciziei de neimplementare. Dacă excluderea nu este documentată adecvat, aceste cerinţe se pot reîntoarce ulterior drept cerinţe noi pe parcursul derulării proiectului. De asemenea, toate elementele din linia de bază a domeniului trebuie clar definite. Trebuie să existe rezultate concrete, măsurabile, care trebuie îndeplinite. Acestea trebuie documentate împreună cu criteriile de acceptare, ca parte a definirii domeniului. Dacă nu se întâmplă acest lucru, domeniul nu poate fi verificat, iar clienţii pot solicita mereu introducerea unor noi cerinţe sau pot refuza produsul datorită unei interpretări diferite a specificaţiilor. 67 Tabelul de mai sus prezintă o comparaţie între abordarea clasică şi cea agilă în privinţa descompunerii activităţilor. În proiectele agile, SDA se regăseşte în planul de lansare şi în planul de iteraţie. 68 Verificarea domeniului se realizează în cadrul iteraţiei, clientul putând revizui, testa şi accepta caracteristicile implementate. În mod ideal, aceasta are loc pe parcursul iteraţiei, dar poate avea loc şi la sfârşitul acesteia, la prezentarea (demonstrarea) codului. Caracteristicile neimplementate, din lipsa timpului sau din cauza problemelor de specificare, sunt reintroduse pe lista de cerinţe (engl. “backlog”) sau intră în următoarea iteraţie, conform deciziei clientului. 69 În metodologiile agile, controlul domeniului constă în: gestionarea listei de cerinţe (“backlog”); protejarea iteraţiei. Clientul gestionează lista de cerinţe iar managerul de proiect protejează echipa şi previne schimbările de cerinţe din timpul unei iteraţii. Este importantă stabilirea corectă a duratei unei iteraţii, deoarece clientul trebuie să aştepte următoarea iteraţie pentru a face modificări. Dacă cerinţele de modificare sunt frecvente, ciclurile de iteraţii pot fi scurtate. Pot exista excepţii; în urma discuţiilor dintre client şi managerul de proiect, o iteraţie poate fi oprită sau reîncepută, însă aceste situaţii trebuie să fie foarte rare. Tabelul de mai sus prezintă o comparaţie între abordarea clasică şi cea agilă în privinţa controlului domeniului. Unul din motivele eşecului proiectelor este lipsa identificării clare a livrabilelor care trebuie realizate. Fără stabilirea unei linii de bază a domeniului, nici liniile de bază ale costului şi graficului de lucru nu pot fi precizate. 70 Companiile utilizează outsourcing-ul pentru funcţiile care pot fi dezvoltate mai ieftin în altă ţară. Un proiect tipic are următoarele etape: Iniţierea proiectului (local); Analiza cerinţelor (local); Proiectarea de nivel înalt (local); Proiectarea detaliată (offshore); Implementarea (offshore); Testarea (offshore sau local); Livrarea (local). Motive pentru outsourcing: Reducerea costurilor; Creşterea eficienţei; Concentrarea asupra obiectivelor critice ale proiectului; Accesarea flexibilă a unor resurse care altfel nu ar fi accesibile, deexemplu personal înalt calificat; Dimensiunea mare a proiectului. Dezavantaje: Control managerial mai redus; Probleme de confidenţialitate şi securitate; Risc în cazul falimentului companiei offshore; Probleme de limbă, fus orar. Concluzii Simpla adoptare a unei metodologii fără o analiză temeinică acerinţelor şi contextului de lucru nu este recomandată. Metodologia este o tactică ce trebuie considerată numai după determinarea strategiei generale a companiei. 71 72 Principalul instrument necesar pentru definirea activităţilor, precum şi pentru determinarea duratei şi succesiunii acestora este Structura de Descompunere a Activităţilor (engl. “Work Breakdown Structure”). Metoda este utilizată pentru a descompune proiectul în sub-proiecte mai uşor de gestionat. SDA defineşte nivelul de control cel mai de jos pe care trebuie să-l gestioneze managerul de proiect: nivelul pachetului de activităţi (engl. “work package”). Din punctul de vedere al managerului unui sub-proiect, un pachet de activităţi poate fi împărţit la rândul său până la nivel de activitate sau sarcină individuală. 73 În faza de dezvoltare a SDA, se verifică dacă fiecare activitate are intrări corespunzătoare pentru lucrul aferent. Fiecare ieşire a unei activităţi trebuie să fie utilizată de o altă activitate sau să fie parte a unui livrabil al proiectului. Dependenţele dintre activităţi pot fi: obligatorii: definite de natura proiectului. De exemplu, testarea de tip „cutie albă” nu poate fi făcută decât după implementare; discreţionare: definite de management. Rezultă de obicei din bunele practici în domeniu, de exemplu aplicarea unei metodologii de dezvoltare software. Trebuie să fie bine documentate deoarece limitează deciziile ulterioare de planificare; externe: definite din afara proiectului. De exemplu, testarea poate depinde de livrarea unor componente hardware dintr-o sursă externă. Diagrama de precedenţă conţine noduri reprezentate ca nişte dreptunghiuri, cu orice informaţii necesare despre activităţi, precum numărul curent, descrierea, data de începere şi terminare, durata etc. Activităţile sunt conectate prin săgeţi care precizează relaţiile logice ale graficului de lucru. Capătul săgeţii indică activitatea dependentă. Sunt posibile 4 relaţii logice: sfârşit-început (FS), început-început (SS), sfârşitsfârşit (FF), început-sfârşit (SF). 74 Sfârşit-început (Finish-to-start, FS) O relaţie sfârşit-început reprezintă cel mai des întâlnit tip de dependenţă. În cadrul unei astfel de relaţii, activitatea succesoare poate începe doar după terminarea activităţii predecesoare. Un raport trebuie scris înainte să poată fi publicat; O persoană trebuie să aibă un calculator înainte să- şi poată instala programele de care are nevoie. Început-sfârşit (Start-to-finish, SF) În relaţia început-sfârşit, activitatea succesoare se poate termina doar înainte de începerea activităţii predecesoare. Angajaţii pot începe să folosească o nouă procedură numai după ce au terminat pregătirea profesională pentru aceasta. În cazul în care utilizarea noii proceduri este întârziată, se doreşte de asemenea întârzierea pregătirii, astfel încât aceasta să aibă loc cât mai târziu posibil înainte de punerea în aplicare. Acest exemplu de relaţie început-sfârşit nu se poate considera ca o relaţie sfârşit- început. Ideea este de a nu permite niciun fel de întârziere între pregătire şi aplicare. Dacă noua procedură poate începe doar după ce se termină pregătirea (relaţie sfârşit-început), noua procedură poate începe în orice moment ulterior încheierii pregătirii, în funcţie de modul în care alte relaţii o pot întârzia. Dacă activitatea de pregătire trebuie să se termine chiar înainte de începerea celeilalte activităţi, întârzierile activităţii ulterioare (de punere în aplicare) întârzie de asemenea şi activitatea anterioară; Schimbul 2 începe când se termină schimbul 1. Dar nu poate exista o perioadă între cele două schimburi în care nu lucrează nimeni. Dacă începutul schimbului 2 întârzie, trebuie să întârzie şi sfârşitul schimbului 1. Început-început (Start-to-start, SS) Într-o relaţie început-început, activitatea succesoare poate începe doar în momentul în care începe activitatea predecesoare. De exemplu: Când încep să se primească rezultatele unor alegeri, se poate începe centralizarea lor; Când începe lucrul la un proiect, încep şi activităţile de management. Sau activităţile de management încep cu n zile înainte de începerea lucrului la proiect. Activităţile de management şi cele de lucru efectiv se desfăşoară apoi în paralel o perioadă de timp. Sfârşit-sfârşit