Postari cu eticheta: proiect

Asumare, justificare, rezolvare

Dezvoltarea unui proiect (in IT si nu numai) are la baza o estimare de timp. In functie de domeniu, aceasta estimare se da in ore, zile sau saptamani. In IT, unitatea de masura pentru asa ceva e ora.

Estimarea va cuprinde de regula si o anumita marja de eroare. Un factor de risc, o asigurare in plus ca procesul de dezvoltare se va incadra in numarul de ore estimat. Acest factor de risc e calculat in functie de complexitatea proiectului, gradul sau de dificultate, nivelele de pregatire a oamenilor implicati, numarul oamenilor implicati, etc.

Oricum, ideea e ca se ajunge la un numar de ore. Pe baza acestuia se elaboreaza un calendar de dezvoltare, cu date exacte de livrare pentru fiecare stagiu de dezvoltare si – implicit – pentru intregul proiect.

Marja de eroare despre care vorbeam mai sus se reflecta si in acest calendar. Un exemplu foarte simplu ar fi urmatorul.

Sa presupunem ca ai un task estimat la 32 de ore. Adica – 4 zile de lucru.
Daca – in calendar – data inceperii taskului este luni dimineata, atunci (conform citeste mai departe


Scara competentelor

In procesul de software development se poate intampla uneori ca oamenii implicati sa aiba “timpi morti”.
Aceste perioade sunt cauzate (printre altele) de :

  • Ne-trimiterea specificatiilor la data promisa.
  • Finalizarea unui feature inainte de perioada estimata.
  • Planificare incorecta.
  • Stoparea proiectului pe o perioada nedeterminata – din motive ce nu tin de planificare.

Acesti timpi morti pot fi valorificati foarte bine prin studiu. Obiectivul procesului de studiu se stabileste in functiile de viitoarele proiecte care-l includ pe developerul respectiv si de skill-urile acestuia.

Studiul individual (cel putin, cel efectuat in timpul orelor de program – in “timpii morti”) va trebui atent contorizat si valorificat. Pentru ca altfel – multi oameni care se stiu nesupravegheati vor tinde sa piarda timpul (de multe ori, chiar si involuntar). Iar orele petrecute pentru studiu in aceste conditii nu vor fi productive deloc sau cel putin nu vor avea productivitatea asteptata – daca nu sunt valorificate corect. Nu generalizez. citeste mai departe


Despre perfectiune

Ati intalnit vreodata un om perfect? Sau un obiect, un produs perfect? Si – daca da – s-a intamplat ca aceasta perfectiune sa prinda contur doar in ochii vostri? Iar altii – din jur – sa aiba pareri (radical) diferite?

Sunt convins ca da. Ca o paranteza – se spune ca frumusetea e in ochii privitorului. La fel sta situatia si in cazul perfectiunii. Depinde de personalitatea si criteriile celui care analizeaza.

Daca obiectul discutiei e un anumit produs – care se cere a fi perfect – atunci exigenta celui care analizeaza creste direct proportional cu pretul care trebuie platit pentru produsul in cauza.

Domenii din care se pot da exemple ar fi destule – dar voi vorbi in special despre cel in care-mi desfasor activitatea. Si anume IT-ul.

Se primesc asadar specificatiile pentru un nou proiect. Se analizeaza/clarifica. In mod normal – la finalul procesului de clarificare – viziunea clientului despre proiectul care tocmai s-a analizat trebuie sa fie foarte apropiata de a celui care a facut analiza. “Foarte apropiata” inseamna in procent de vreo 90%. In cazurile fericite – aceste viziuni aproape coincid. Dar cazurile fericite sunt mai rare decat preotii cinstiti, asa ca citeste mai departe