This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
Cuprins
Introducere
Motivele eşecurilor proiectelor software
1. Definirea proiectului
2. Planificarea activităţilor
3. Managementul planului de lucru
4. Probleme de conducere
5. Managementul scopului
6. Managementul riscurilor
7. Gestiunea comunicaţiilor
8. Managementul documentaţiei
9. Managementul de calitate
10. Managementul metricilor
Concluzii
Bibliografie
Managementul proiectelor informatice - pag. 1
Introducere
Managementul proiectelor software cuprinde cunoştinele, tehnicile şi uneltele necesare
pentru dezvoltarea produselor software. Acest material discută planul dezvoltării produselor
software folosind o estimare efectivă a mărimii şi efortului precum şi executarea acestui plan cu
menţinerea productivităţii şi calităţii. În acest context, topici ca managementul riscului, modele
alternative la ciclul de viaţă (al produselor software), organizarea echipelor de dezvoltare şi
managementul tehnicienilor sunt deasemeni discutate.
Managementul proiectelor software rămâne oarecum diferit de managementul proiectelor
din alte domenii dintr-un număr de motive: software-ul este un "produs exclusiv mental",
neconstrâns de legile fizicii sau limitele proceselor de producţie. Este dificil să se detecteze şi să se
prevină defectele în produsele software. Software-ul poate fi foarte complex. În fine, ca disciplină,
dezvoltarea software este relativ recentă astfel întât tehnicile de măsurare efectivă nu sunt încă pe
deplin disponibile iar acelea care există nu sunt bine calibrate.
În ciuda acestor dificultăţi, există o bază solidă de cunoştinte despre managementul
proiectelor software.
Managementul proiectelor software este implementat în programe pentru ingineria software
din cauză că dezvoltarea software este strâns legată de tehnicile de management. Ceea ce este
descris aici ca primul nivel de management de producţie este cel mai înalt nivel din managementul
predat la şcolile de afaceri.
Proiectele mici nu necesită foarte multe cunoştinţe de management al proiectului sau
disciplină în managementul proiectului. Dar, pe măsură ce proiectul devine mai mare, procesele
formale şi tehnicile devin esenţiale. Pentru organizarea şi structurarea acestor procese prin
managementul proiectelor există diferite metodologii dar sunt esenţiale zece arii de interes, descrise
mai jos în acest document. În general, dacă putem stăpâni aceste arii, putem avea succes în cele mai
multe proiecte. Pentru un proiect mic, nu trebuie să ne facem griji despre managementul
documentaţiei sau aprecierea calităţii dar pe măsură ce proiectul avansează va trebui să ne
focalizăm în toate cele zece procese.
De notat că lista noastră nu include analiza, proiectarea, testarea sau implementarea. Aceia
care au lucrat cu proiecte ştiu probabil că ele includ analiza şi testarea. Totuşi, trebuie să facem o
Managementul proiectelor informatice - pag. 2
distincţie majoră. Analiza şi testarea sunt părţi din efortul pentru realizarea proiectului propriu-zis
(denumit deasemeni durata de viaţă a proiectului). Aceste faze se schimbă în funcţie de tipul
proiectului. Dacă avem un proiect complet, putem executa toţi paşii de analiză, proiectare,
construcţie, testare şi implementare. În alte proiecte însă putem avea de realizat doar anumite
componente. De exemplu, dacă avem un proiect de cercetare şi dezvoltare (engl. R&D), nu vom
face implementarea. Dacă facem un studiu, proiectul ar putea să se sfârşească după faza de analiză.
Lipseşte ceva?
Câteodată două alte procese sunt incluse ca parte a managementului proiectului de bază:
managementul resurselor umane şi managementul contractului şi achiziţiilor. Managementul
resurselor umane este o pricepere valoroasă pentru managerii de proiect, dar nu este specifică
managementului de proiect. De fapt, toate relaţiile subordonate managementului necesită
managementul forţei de muncă. Distincţia este că este o îndemânare a unui manager de proiect dar
nu o secţiune separată din managementul proiectelor.
Deasemeni am exclus contractul de management şi achiziţii din listă. În cele mai multe
companii, managerii de proiect trebuie să aibă cunoştinţă despre managementul contractelor şi
vânzărilor, dar nu sunt responsabili pentru el. Pentru acestea, de obicei există un departament juridic
care este responsabil cu aceste discipline.
Temporizarea şi secvenţierea proceselor
Cu excepţia primelor două categorii - definirea proiectului şi planificarea lucrului - cele zece
faze ale managementului de proiect nu se realizează într-o anumită ordine. Procesele de la trei la
zece pot fi aranjate în orice ordine şi de fapt, sunt executate în paralel şi odată cu proiectul. De
exemplu, dacă apare o problemă majoră, trebuie mai întâi să se folosească managementul
problemelor indiferent ce alte aspecte ale managementului proiectelor s-au folosit înainte, în timpul
sau după acest timp.
Managementul proiectelor informatice - pag. 3
Motivele eşecurilor proiectelor software
Mai întâi trebuie să spunem că proiectele informatice au astăzi o şansă de succes de 32%,
44% este procentul pentru cele eşuate care nu s-au încadrat în timp, buget sau nu au respectat
cerinţele şi 24% au fost anulate înainte de a fi terminate sau au fost livrate şi nu s-au folosit
niciodată (Chaos Report 2009 - Standish Group).
Proiectul mediu este terminat cu 222% mai târziu, cu 189% peste buget şi livrează doar 61%
din funcţiile specificate.
Timp insuficient
De multe ori data începerii proiectului este fixată înainte de începerea proiectului şi nu este
negociabilă. Asta duce la graba de a începe proiectul făcând presupunerea că dacă se va începe
codarea mai repede rezultatul va fi disponibil mai devreme.
Aceasta este aproape întotdeauna alegerea eronată. Este vital să se folosească timpul pentru
a crea un bun design. Dacă nu aveţi un proiect bun asta va conduce la modificări de-a lungul fazei
Managementul proiectelor informatice - pag. 4
Ce a înţeles managerul de proiectCum a explicat clientul
Cum a proiectatanalistul
Ce a scris programatorul
Cum îl descriebusiness-consultant-ul
Cum a fost documentat Ce au instalat operatorii
Cum a fost facturatclientul
Cum este suportul Ce voia de faptclientul
de dezvoltare. Când se întâmplă asta timpul şi bugetul sunt consumate cu o viteză foarte mare.
Soluţie: Rezervaţi-vă timp pentru a face un proiect bun. Rezistaţi tentaţiei de a scurta timpul şi a
începe scrierea codului. Alocaţi-vă timp pentru aceasta şi restul proiectului va decurge mult mai
bine. Vă va creşte reputaţia când veţi livra proiecte care îndeplinesc aşteptările clienţilor şi
funcţionează bine de prima dată.
Buget insuficient
Multe proiecte au o politică de "cel mai mic preţ este cel mai bun candidat" sau un buget
nerealistic de mic, care nu se bazează pe cerinţele reale. Când se întâmplă asta, totul tinde să dureze
mai mult. Resursele ajung mai târziu sau niciodată, se fac improvizaţii, reduceri şi calitatea suferă.
Soluţie: Fiţi realişti asupra bugetului necesar şi asiguraţi-vă că se bazează pe cerinţele actuale.
Evitaţi să vă bazaţi doar pe un furnizor care are cel mai mic preţ. Mergeţi cu un furnizor sau echipă
care a demonstrat că livrează în bugetul estimat.
Slaba comunicare
O zicală veche spune "niciodată să nu presupui nimic" şi acesata este foarte adevărat pentru
proiectele software. Comunicarea corectă este vitală pentru succesul proiectului, clienţii, utilizatorii
şi în special cu echipa de dezvoltare. Vă înţelege toată echipa? Ştiu exact ceea ce se aşteaptă de la ei
sau aţi presupus că ştiu? Comunică bine între ei, cu utilizatorii şi cu alte departamente?
Soluţie: Identificaţi imediat lacunele în comunicare. Acestea pot duce la confuzii şi complicaţii mai
târziu. Niciodată nu presupuneţi că a înţeles toată lumea. Rezervaţi-vă timp pentru a crea un mediu
care va aduce proiectul în timp, în buget şi conform cerinţelor clienţilor.
Nu revizuiţi progresul proiectului
Pe măsură ce un proiect progresează apar modificări şi acestea pot avea un impact
semnificativ. Este important să monitorizaţi progresul din când în când astfel încât problemele pot fi
rezolvate mai repede şi clienţii avertizaţi de posibilele întârzieri şi schimbări în produs.
Soluţie: Fixaţi puncte de reper frecvente în timpul proiectului unde puteţi revizui progresul
împreună cu echipa şi puteţi face ajustările necesare pentru a rămâne în cursă. Staţi aproape de
echipă astfel încât să înţelegeţi ce se întâmplă şi cu ce probleme se confruntă.
Managementul proiectelor informatice - pag. 5
Testare insuficientă
Când se execută presiuni pentru livrare, de obicei testarea este cea care suferă Toate testările
sunt amânate până la sfârşitul ciclului de dezvoltare şi când nu mai sunt decât bani pentru service.
Foarte des produsul are multe erori ceea ce duce la un client nesatisfăcut.
Soluţie: Faceţi testări de-a lungul întregului ciclu de dezvoltare, testaţi fiecare modul sau
componentă de îndată ce a fost produsă. Aceasta lasă ca numai integrarea să fie testată la sfârşitul
ciclului de dezvoltare.
Testarea în mediul de producţie
Este surprinzător câte organizaţii testează produsele în mediul de producţie. Aceata este o
stragegie cu risc mare care poate duce la probleme de securitate şi livrări fără testare care pot afecta
mediul de producţie.
Soluţie: Creeaţi un proces pentru asigurarea calităţii şi livrarea de noi produse. Oferiţi un mediu
separat de producţie, numai pentru testare.
Lipsa asigurării calităţii
Adesea asigurarea calităţii suferă la livrearea produselor software. Schimbările în cod nu
sunt documenteate, proiectarea conţine erori fatale şi implementarea poate fi incompletă. Toate
acestea pot duce la refacerea muncii, pierderea de timp şi în cele din urmă a clienţilor.
Soluţie: Asiguraţi-vă timp pentru controlul de calitate şi documentaţi software-ul înainte de a fi
livrat.
Neconformitate faţă de standardele industriale
Conformitatea proiectelor software cu standardele din industrie se pot dovedi eficace la
asigurarea accesibilităţii, portabilităţii, uzabilităţii, robusteţii şi reducerea problemelor acum şi în
viitor.
Soluţie: Asiguraţi-vă timp pentru a introduce standardele în proiecte. Identificaţi ceea ce merge bine
şi schimbaţi ceea ce nu merge bine. Revizuiţi şi împrospătaţi standardele de câte ori este nevoie.
Managementul proiectelor informatice - pag. 6
1. Definirea proiectului
Ca manager de proiect, trebuie să vă asiguraţi că obiectivul este înţeles corect şi asumat de
sponsorul proiectului şi acţionarii principali înainte de începerea proiectului. Pentru aceasta, se va
lucra cu sponsorul şi acţionarii pentru ca echipa de proiectare şi clientul să aibă o viziune comună
asupra a ceea ce va livra proiectul, când va fi complet, cât va costa, cine va face munca, cum va fi
completată lucrarea şi care vor fi beneficiile.
Cu cât un proiect este mai mare, cu atât mai important este ca această informaţie să fie
stocată formal şi explicit. Toate proiectele ar trebui să înceapă cu acest tip de planificare anterioară
pentru a preveni problemele cauzare de diferite puncte de vedere asupra termenilor de bază din
proiect. Cea mai mare parte din acest pas este "Definirea proiectului" (unele companii îl numesc
"Graficul proiectului").
La un nivel superior, scopul definirii activităţii include: