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. Din fericire, sunt si multe exceptii.

Dupa parerea mea – urmatoarea metodologie de studiu poate fi aplicata indiferent de tehnologie sau de persoana care studiaza. N-am preluat-o de nicaieri, e doar ceva ce-am dedus in urma unor ani de experienta in domeniu. Sunt – totodata – de acord ca mai poate fi imbunatatita si voi reveni asupra acestui subiect. E vorba strict despre fructificarea orelor de studiu (in special cele din timpul programului, din “timpii morti”).

Pentru inceput, consider ca gradele de experienta ale unui developer pot fi separate dupa cum urmeaza :

  1. Incepator absolut.
  2. Incepator.
  3. Incepator – mediu.
  4. Mediu.
  5. Mediu – avansat.
  6. Avansat.
  7. Senior.

Aceste grade isi au rolul lor in planificarea unui proiect, dar voi vorbi despre asta mai spre finalul articolului.
Sa presupunem ca un developer incepe studiul pe un framework pe care nu-l cunoaste.
In ciuda experientei sale pe alte framework-uri care tin de aceeasi tehnologie – el va fi considerat incepator absolut (nivelul 1 de mai sus), din simplul motiv ca pana in momentul respectiv n-a mai avut deloc contact cu framework-ul in cauza. Sunt de acord ca multe framework-uri seamana, dar asta nu inseamna ca sunt exact la fel. Asadar – oricat de experimentat ai fi pe alte framework-uri, cand incepi studiul unuia nou il incepi de la zero (incepator absolut). Pentru ca altfel poti scapa diverse maruntisuri care se vor dovedi importante mai tarziu.

Avem deci gradele de experienta de mai sus.
Ce ne trebuie mai departe e un model (o scara) pentru parcurgerea acestor grade – de la 1 la 7.
Evident – pentru trecerea de la un grad la altul e nevoie de studiu, iar aici intervin doua intrebari :

  • De cat timp de studiu e nevoie – in medie – pentru a deveni apt pentru trecerea de la gradul X la X+1?
  • Cand se poate considera ca un anumit developer a promovat intr-adevar de la X la X+1?

Raspunsurile le voi da tot pe baza experientei.
Timpii de trecere de la un grad la altul se vor stabili cu ajutorul unui senior pe framework-ul respectiv. Adica cineva care are totusi o anumita vechime pe acel framework si a reusit sa duca la bun sfarsit un anumit numar de proiecte, de o anumita dificultate. Un alt factor il reprezinta statisticile din domeniu, cu privire la framework-ul in cauza. Ma refer aici la dificultate, similitudini cu alte framework-uri cunoscute, etc.

Project manager-ul care monitorizeaza programul de studiu, impreuna cu seniorul si ajutat de statisticile mentionate mai sus poate stabili urmatoarele :

  • Pentru trecerea de la incepator absolut la incepator – un programator mediu are nevoie de un set de N1 ore de studiu.
  • Pentru trecerea de la incepator la incepator-mediu – un programator mediu are nevoie de un set de N2 ore de studiu.
  • Pentru trecerea de la incepator-mediu la mediu – un programator mediu are nevoie de un set de N3 ore de studiu.
  • Pentru trecerea de la mediu la mediu-avansat – un programator mediu are nevoie de un set de N4 ore de studiu.
  • Pentru trecerea de la mediu-avansat la avansat – un programator mediu are nevoie de un set de N5 ore de studiu.
  • Pentru trecerea de la avansat la senior – un programator mediu are nevoie de un set de N6 ore de studiu.

Avem deci numerele (estimative) de ore de studiu necesare promovarii de la un nivel la altul.
Mai ramane evaluarea – la finalul fiecarui set de ore de studiu – de la N1 la N6.

Aceasta evaluare se face in baza unor proiecte de test, ale caror specificatii, nivele de dificultate si standarde de verificare vor fi definite tot de PM in colaborare cu seniorul pe framework-ul respectiv.
Altfel spus, vom avea :

  • La finalul setului de ore N1 (pentru avansarea la gradul de incepator) – se va sustine un proiect din clasa P1.
  • La finalul setului de ore N2 (pentru avansarea la gradul de incepator-mediu) – se va sustine un proiect din clasa P2.
  • La finalul setului de ore N3 (pentru avansarea la gradul de mediu) – se va sustine un proiect din clasa P3.
  • La finalul setului de ore N4 (pentru avansarea la gradul de mediu-avansat) – se va sustine un proiect din clasa P4.
  • La finalul setului de ore N5 (pentru avansarea la gradul de avansat) – se va sustine un proiect din clasa P5.
  • La finalul setului de ore N6 (pentru avansarea la gradul de senior) – se va sustine un proiect din clasa P6.

In momentul in care va incepe studiul setului de ore Nx, programatorul va cunoaste specificatiile proiectului din clasa Px pe care va trebui sa-l realizeze pentru a promova la gradul urmator.

In acest fel, gradul atribuit unui anumit programator pe scara competentelor va fi justificat.
Adica, in loc sa spunem ca “Popescu este la nivel mediu pe frameworkul X pentru ca studiaza de ceva vreme” – vom putea spune ca “Popescu este la nivelul mediu pe frameworkul X pentru ca a studiat un set de N3 ore si a realizat cu succes un proiect din clasa P3, cu gradul de dificultate aferent si corespunzator standardelor pre-stabilite”.
Cu alte cuvinte, vorbim de studiu controlat, cu rezultate vizibile. Nu la voia intamplarii. Pentru ca daca totul e lasat la voia intamplarii (si fara supraveghere), atunci in multe cazuri o parte din orele de studiu se transforma in ore de pierdut vremea – iar la final vom sti doar ca respectivul programator a petrecut un anumit numar de ore de studiu pe un anumit framework – fara a ne fi insa clar care este nivelul sau si cat de bine au fost valorificate acele ore (luate – desigur – din timpul orelor de program).
Sigur – studiul se poate realiza si in timpul liber. Dar despre asta – in alt articol.

M-am intins deja prea mult, asa ca voi trece direct la rolul gradelor in planificarea unui proiect.
Sa presupunem ca avem de estimat/planificat un proiect ce va fi dezvoltat pe un framework unde avem developeri ale caror grade variaza intre incepator si senior (nota : cei cu gradul incepator absolut nu vor participa la proiectele comerciale, ei trebuind sa avanseze cel putin pana la gradul de incepator pentru a avea aceasta posibilitate). Foarte, foarte rar vom avea ocazia de-a lucra pe un anumit proiect numai cu seniori.
Intr-o lume ideala, fiecare programator isi va estima partea pe care-o are de dezvoltat, in cadrul proiectului.
Insa lumea in care lucram e cam departe de cea ideala – asa ca estimarile sunt deseori facute de o singura persoana (PM sau senior developer pe tehnologia/frameworkul in cauza).
Estimarea va consta intr-un numar final de ore. Un numar total, pentru toate functionalitatile prezente in specificatii.
Insa – e un lucru stiut ca gradele celor ce vor fi implicati in dezvoltare variaza (de la incepator la senior). Asadar – si ponderea lor raportata la numarul de ore estimate pentru proiect variaza proportional cu gradul. Pentru ca un feature de o anumita dificultate va fi dezvoltat de un senior intr-un anumit numar de ore, iar de un incepator intr-un numar de ore (mult) mai mare.

Persoana care realizeaza estimarea ia de obicei in calcul un singur grad al dezvoltatorilor implicati (undeva intre mediu si senior). Insa numarul de ore rezultat in urma estimarii va trebui revazut – cand se cunoaste echipa implicata si gradele fiecarui membru. Pentru ca fiecare dezvoltator va avea o pondere diferita in numarul de ore generate in dezvoltarea proiectului. Pondere aflata in directa legatura cu gradul sau.

Inchei aici prima parte a acestei teorii. Voi reveni cu a doua parte – intr-un nou articol – impreuna cu un exemplu clar si o schita explicativa.

Tin sa mentionez ca aceeasi metoda de studiu se poate aplica (evident, cu diverse adaptari – mai mici sau mai mari) si in orice alt domeniu de activitate (din IT si nu numai) – inclusiv management.

Sursa imaginii – link.


4 Comments

  • Reply Nicu |

    Aceste teorii pot fi incercate doar de cei receptivi la nou. Si pana la urma la putini le plac schimbarile.

Lasa un comentariu