Omisiuni in estimarea proiectelor IT

forgetObisnuiesc sa spun – mai in gluma, mai in serios – ca estimarea unui proiect (software sau de alta natura) este o activitate excelenta pentru cei care si-au dorit vreodata sa poata prezice viitorul. De ce? Pentru ca acuratetea estimarii reprezinta unul dintre motoarele care asigura succesul proiectului.
Despre estimarea proiectelor software vom vorbi mai des, e un subiect foarte vast si care ma pasioneaza.

Estimarile nu vor fi niciodata exacte. Sunt aproximari. Sunt deseori ceea ce in engleza se numeste “educated guess”. Insa pot fi aduse aproape de adevar (de realitate) daca sunt facute responsabil.

Deseori, cei care fac estimarile proiectelor IT omit anumite puncte importante – care afecteaza corectitudinea si claritatea rezultatului final. Iar aceste omisiuni duc la inconsistenta. Voi lista mai jos cateva dintre cele mai des intalnite.

I. Lista de presupuneri (assumptions) pe baza careia a fost gandita estimarea

Deseori, lista de presupuneri este la fel de importanta ca si estimarea in sine. Aproape fiecare dintre taskurile estimate individual trebuie insotit de presupunerea care a dus la estimarea respectiva. Voi da mai jos un exemplu.

Sa presupunem ca e vorba de functionalitatea de inregistrare a unui utilizator. Mai exact, partea de sign up. In general, aceasta parte consta in colectarea unor informatii, verificarea lor si mai apoi salvarea in sistem.
Insa procedura de inregistrare poate fi construita in mai multe moduri. Listez doua dintre acestea, in continuare. Atentie – se aplica doar daca nu exista specificatii detaliate despre functionalitatea respectiva (adica, daca exista loc de presupuneri).

a. Simplu, in care procedura de inregistrare va colecta / verifica / salva urmatoarele date :

  • numele utilizatorului
  • prenumele utilizatorului
  • adresa de mail
  • o parola care va fi folosita ulterior pentru logare
  • un duplicat al parolei, pentru verificare

b. Mai complex, in care procedura de inregistrare va colecta – in plus fata de informatiile de mai sus – si pe cele ce urmeaza :

  • data nasterii (care poate necesita un tip mai special de validare)
  • o imagine pentru profilul utilizatorului
  • raspunsuri la anumite intrebari predefinite, de tip grila (legate de ocupatia utilizatorului, de hobby-urile lui, etc)
  • numarul de telefon (care poate necesita un tip mai special de validare)
  • o descriere sumara a utilizatorului (asa-zisul “short bio” intalnit deseori)
  • uploadarea unui CV intr-un format prestabilit (PDF, Microsoft Word, etc)

Daca tot ceea ce aveti in specificatii despre aceasta specificatie se rezuma la “inregistrarea unui utilizator”, atunci puteti estima primul caz de mai sus (cel simplu), insa trebuie neaparat mentionata presupunerea care insoteste aceasta estimare. Si anume – “se vor colecta si valida doar campurile de nume, prenume, adresa de mail, parola si confirmarea parolei ; colectarea si validarea unor campuri suplimentare se va estima separat”.

In acest fel, estimarea taskului de inregistrare a utilizatorilor – desi facuta pe specificatii foarte sumare – este “acoperita” de presupunerea pe baza careia a fost facuta. Aceasta presupunere, odata comunicata clientului (inclusa in estimare) va putea fi verificata de acesta. In cazul in care clientul revine cu cerinte suplimentare pentru taskul in cauza – in afara celor estimate pe baza presupunerii – estimarea va fi revizuita.

II. Estimarea timpului necesar pentru scrierea documentatiei

De obicei, procesul de documentare a codului se rezuma la comentariile care explica utilitatea / functionalitatea anumitor parti din cod – ceea ce e departe de a fi suficient.
Insa deseori echipa de dezvoltare este diferita de cea care va asigura mentenanta proiectului pe termen lung. Motivele sunt multe si diverse : fie clientul este nemultumit de modul in care a decurs dezvoltarea si doreste sa continue intretinerea proiectului cu o alta echipa, fie bugetul a fost negociat si nu mai e convenabil pentru client, fie echipa care a dezvoltat proiectul nu mai doreste / poate continua cu partea de mentenanta, etc.
Oricum, ideea e ca documentatia amanuntita a codului il face mult mai usor de inteles pentru o noua echipa sau chiar pentru dezvoltatori care se alatura echipei actuale pe parcurs. Cei mai multi clienti presupun ca aceasta documentatie va fi livrata odata cu codul, asa ca timpul necesar realizarii ei va trebui inclus in estimarea initiala.

III. Estimarea timpului necesar pentru acomodarea noilor membri, in cadrul echipei de dezvoltare

Daca procesul de dezvoltare se intinde pe o perioada mai lunga (luni sau – uneori – ani) – exista posibilitatea ca structura echipei sa se schimbe pe parcurs, din diverse motive.
Dezvoltatorii care intra in echipa vor trebui pusi la curent cu structura proiectului, particularitatile lui, etc. Vor avea nevoie de timp ca sa studieze documentatia despre care povesteam mai sus si sa se familiarizeze cu noul mediu de lucru. In functie de durata proiectului, timpul pentru acomodarea noilor membri ai echipei de dezvoltare trebuie luat in calcul in estimarea initiala.

IV. Estimarea timpului necesar pentru testele de incarcare (load tests)

Deseori, in functie de specificul proiectului la care se lucreaza, vor fi necesare anumite teste de incarcare – care simuleaza de fapt activitatea unui anumit numar de utilizatori. Aceste teste se ruleaza inainte ca proiectul sa ajunga live iar rezultatele lor vor da informatii pretioase despre stabilitatea proiectului in fata unui flux mare de utilizatori.
Realizarea si rularea acestor teste reprezinta deasemenea taskuri care vor trebui prevazute in estimarea initiala.

V. Coordonarea subcontractorilor

Unele proiecte presupun integrarea anumitor servicii externe, dezvoltate de alte echipe. Aceste servicii vin cu propria documentatie si cu propriile echipe de suport.
Exemple : integrarea unui sistem de plati online, a unui mecanism de order tracking (urmarirea coletelor livrate de un shop online), etc.
La timpul necesar pentru integrarea lor se adauga timpul pentru studierea documentatiei si cel pentru colaborarea cu echipele de suport, atunci cand va fi cazul. Aceste doua elemente vor trebui sa apara si ele in estimarea data pentru dezvoltarea proiectului.

VI. Demo-urile pentru clienti / investitori

Periodic, unele proiecte vor necesita prezentari pentru clientii sau investitorii implicati. Aceste prezentari vor trebui pregatite in prealabil. Timpul necesar pentru pregatirea si sustinerea lor va trebui si el cuprins in estimarea data la inceput.

VII. Suportul acordat in timpul lansarii / imediat dupa

Lansarea unui proiect nu presupune doar copierea si configurarea sa pe serverul de productie. De cele mai multe ori, in functie de complexitatea proiectului, lansarile vin cu anumite seturi de probleme. Unele dintre ele pot fi prevazute, altele insa nu. In functie de marimea si complexitatea proiectului, o anumita perioada de timp va trebui prevazuta in estimarea initiala pentru suportul acordat de echipa de dezvoltare atat in timpul lansarii cat (mai ales) imediat dupa lansare – pentru monitorizare / rezolvarea problemelor care apar ca urmare a folosirii serviciului de catre utilizatori reali.

Sigur, lista ramane deschisa. Ea poate fi completata diferit, in functie de tipurile de proiecte la care se lucreaza. Ideea e ca estimarea data initial trebuie sa acopere cat mai multe dintre cazurile care nu fac parte in mod direct din procesul de dezvoltare, dar deriva (indirect, uneori) din acesta. Aveti ceva de adaugat?

Add a Comment

Your email address will not be published. Required fields are marked *