Managementul proiectelor

mici
 1. Introducere

În proiectele mici (specifice activităţii de laborator a studenţilor) apar

anumite probleme:

Folosirea instrumentelor nefamiliare

Cerinţe de design vag formulate

Dacă de exemplu proiectul de întinde pe 10 săptămâni, ar fi bine de
planificat pe o durată mai mică (9 săptămâni). Planificarea activităţilor
ar putea fi următoarea:
- săptămânile 1-2: analiza;
- săptămâna 3: designul;
- săptămânile 4-7: construirea sistemului;
- săptămânile 8-9: testarea şi evaluarea;
- săptămâna 10: săptămână de rezervă
Sisteme incomplete
Având în vedere timpul scurt, e posibil ca sistemul care trebuie
proiectat să nu fie funcţional. De aceea se recomandă ca lucrurile să
fie de aşa natură gândite, încât să existe ceva concret de arătat chiar
din fazele incipiente ale proiectului. În acest schelet al proiectului, ar fi
o idee bună să existe anumite funcţionalităţi vizibile. S pot adăuga alte
funcţionalităţi pe măsura trecerii timpului. O sugestie ar fi să folsoiţi
modelul incremental (vezi Modele de procese software), astfel încât
dacă de exemplu aveţi 3 incremente şi al treilea nu este finalizat,
există totuşi celelalte două.
Sfat: documentarea proiectului e bine să fie făcută pe măsură ce se
avansează cu etapele proiectului, mai bine decât să documentaţi
proiectul la sfârşit, din cauza lipsei de timp.

Lipsa interesului din partea clienţilor

Studentul nu va fi (probabil) plătit pentru proiectul făcut. Avantajul
acestei situaţii este că o organizaţie din afară ar putea fi interesată de
şansa de a avea o resursă free.
 2. Conţinutul unui plan de proiect

În proiectele mici e bine să urmaţi următorul plan:

A) Introducere
În introducere, e o idee bună să se explice pe scurt ce face sistemul
proiectat şi de ce. De asemenea, introducerea ar fi bine să conţină:
• identificarea clientului – pentru cine se face proiectul (inclusiv dacă e
pur didactic – cui s-ar putea adresa);
• o scurtă descriere a proiectului – cel mult câteva paragrafe;
• identificarea autorităţii de proiect – persoana sau persoanele din
cadrul organizaţiei clientului care va avea autoritate peste evoluţia
proiectului.
B) Background
Această parte ar trebui să conţină:
• informaţii relevante despre mediul software/hardware existent;
• circumstanţele sau problemele care conduc la proiect;
• munca din aria proiectului dusă deja la bun sfârşit;
• stakeholders din proiect (adică toţi cei care vor fi afectaţi de proiect
sau care sunt interesaţi de el).

C) Obiectivele proiectului
Obiectivele trebuie să definească ce ar trebui să se realizeze şi
metoda de măsurare a acestei creaţii. La proiectele studenţeşti,
evaluarea e făcută (de cele mai multe ori) din punct de vedere didactic.
Dacă însă această documentare e făcută şi în beneficiul clientului,
atunci punctul de vedere al clientului trebuie să fie prezent.
Dacă sunt multe obiective, ar trebui specificată prioritatea lor.
D) Constrângeri
De obicei se trec la partea cu obiectivele proiectului. Constrângerile
includ:
• scări de timp impuse din exterior;
• cerinţele legale;
• standarde specifice;
• limitări ale persoanelor care pot fi abordate pentru informaţii.

E) Metodele / tehnologiile folosite

Trebuie specificate instrumentele software folosite (acolo unde e
cazul).

F) Rezultatele proiectului
Trebuie listate toate rezultatele (produsele) sau elementelor cum ar fi
module software, documentaţie, ghiduri utilizator, rapoarte.
G) Activităţi
Trebuie precizată lista cu principalele activităţi pe care le implică
proiectul. Fiecare activitate trebuie precizată în termeni concreţi: de
exemplu, în loc de “familiarizarea cu procedurile departamentului-2 ar
trebui “documentarea procedurilor departamentului”. S-ar putea
descoperi rezultate intermediare ale proiectului.
Pentru fiecare activitate, se definesc:
• elementele necesare înainte de a începe activitatea;
• activităţile dependente, adică acele activităţi ce necesită terminarea
acestei activităţi curente pentru a începe;
• timpul / efortul estimat, într-o anumită marjă;
• detalii despre cum vor fi verificate şi validate produsele activităţii.
Se pot include aici şi tabelele Gantt pentru monitorizarea activităţilor
(sau alte instrumente specifice monitorizării).
H) Resurse
Se pot include aici cerinţele software / hardware şi cele legate de
personal.

I) Analiza riscului
Se identifică principalele lucruri care ar putea merge rău. În mod
normal, acestea ar putea include:
• indisponibilitatea resurselor;
• indisponibilitatea personalului;
• probleme tehnice (cum ar fi bugs-urile software).
Se aloca fiecărui risc o evaluare a probabilităţii (notă între 1-10) şi o
notă pentru impactul fiecărui risc (tot între 1-10). Înmulţind cele două
note, se obţine un scor de ansamblu.
Pentru riscurile mari, e bine să se specifice şi eventualele măsuri
pentru reducerea acelor riscuri.
 Concluzii

• atenţie la instrumentele sau tehnologiile noi;

• trebuie ajustate obiectivele proiectului, astfel încât

proiectul să nu depăşească timpul alocat;

• nu trebuie confundate obiectivele proiectului cu

obiectivele personale;

• evitaţi activităţile pentru care nu există rezultate tangibile