Postari din categoria: it

Scara competentelor (III)

Am inceput sa scriu acum o vreme despre o teorie – conceptie proprie – numita Scara Competentelor. Se referea la modul in care timpul de invatare poate fi fructificat intr-un cadru controlat si la evaluarea corecta a competentelor celor care studiaza. Mai mult decat atat, poate fi aplicata in orice domeniu unde se invata progresiv ceva. Deci nu neaparat doar in IT.

Primul articol din serie poate fi citit aici, iar al doilea aici. Teoria in sine nu e complicata absolut deloc, necesita doar putina atentie pentru a o intelege. Rog asadar pe cei interesati sa parcurga intai primele doua parti mentionate mai sus – inainte de-a continua lectura acestui articol. Desigur, pentru o mai buna intelegere a subiectului.

Imi dau seama ca aceste trei articole sunt lungi si (probabil) obositoare. Insa am vrut sa ma asigur ca teoria este – inainte de orice altceva – bine explicata. Daca va fi considerat necesar, in masura in care timpul imi va permite voi reveni cu un scurt sumar a tot ceea ce am cuprins in aceste trei articole. Insa oricum, ele vor trebui citite in intregime pentru a intelege sumarul.

Asadar, voi exemplifica aceasta teorie mai jos, printr-un exemplu inspirat din IT.

Sa presupunem ca programatorul Popescu n-a mai avut niciodata contact cu framework-ul ShopNet (nu-l cautati pe Google, e un nume ales la intamplare – de dragul exemplului). Din varii motive (se anunta un flux de proiecte pe acest framework in urmatoarele luni, etc) va trebui sa-l invete. Inainte insa ca Popescu sa inceapa sa invete ShopNet, avem nevoie de un program de studiu.

Pentru stabilirea programului de studiu e nevoie de doi oameni :

  • PM-ul care va superviza programul de studiu si proiectele pe ShopNet care vor incepe in viitor.
  • Un Senior Developer pe ShopNet. Veti spune probabil ca gradul de senior pe ShopNet poate fi atribuit doar la finalul programului de studiu (care inca nici nu exista). Si asa e. Insa in acest caz (pentru stabilirea regulilor programului) avem nevoie de cineva care a dus la bun sfarsit un anumit set de proiecte pe ShopNet, de o anumita dificultate. Deci, un om experimentat pe acest framework- capabil sa aprecieze corect complexitatea lui.

Dupa cum probabil va amintiti (din cele doua articole precedente pe aceasta tema), scara competentelor are sapte pasi – de la inceputul pana la finalul programului de citeste mai departe


Cine face munca cea mai grea?

Mi s-a pus de curand intrebarea “cine face munca cea mai grea in IT”. Am dat un raspuns atunci si m-am gandit sa-l elaborez putin aici. Sunt de parere ca nu putem generaliza. Adica nu exista un departament anume care face “munca cea mai grea” – in cadrul unei companii de IT.

Munca cea mai grea in design o fac designerii.

Munca cea mai grea in programare o fac programatorii.

Munca cea mai grea in templating o fac HTML-istii.

Munca cea mai grea in testing o fac testerii.

Munca cea mai grea in administrarea sistemelor o fac sysadminii.

Si lista poate continua. Nu in ultimul rand, munca cea mai grea in project management o fac project managerii.

Totodata, sa nu uitam un lucru. Intr-o ierarhie relativ piramidala, multi dintre angajati vor considera mereu ca pot face o treaba mai buna decat superiorul lor direct. De ce? Pentru c-asa functioneaza mecanismele mintii umane. Multi considera ca pot face fara nicio problema treaba superiorului lor (mai bine decat acesta din urma) si – de ce nu – sa incaseze si salariul lui, pe acest motiv. Ei bine, ideea asta rezista de regula doar pana cand este confruntata cu dura realitate. Din simplul motiv ca e din cale-afara de usor sa subestimezi o treaba pe citeste mai departe


Oameni si resurse

In dezvoltarea unui proiect exista de regula o ierarhie clara. Zic “de regula” pentru ca unii pot fi de parere ca regulile sunt facute ca sa fie incalcate. Parerea mea e contrara, cata vreme regulile au un scop pozitiv si bine definit – dar despre asta, in alt film.

Spuneam asadar ca exista o ierarhie clara in procesul de development. Insa – in majoritatea cazurilor (includ aici chiar si cartile de PM) – developerii sunt numiti resurse. Auzi mereu de “resurse implicate”, “resurse disponibile”, resurse-n sus si resurse-n jos. Exact aceasta terminologie incerc s-o combat in ultima vreme (cat m-ajuta posibilitatile). Si incerc sa fac asta pentru ca – in fond – vorbim de oameni, nu de resurse. Mi se pare aiurea si usor jignitor sa numesti un om “resursa“.

Oamenii nu sunt roboti. Daca erau, probabil ca denumirea de resursa ar fi fost mai potrivita decat in contextul actual. Si probabil ca unii si-ar dori sa conduca echipe de roboti si nu de oameni (nu fac parte dintre ei). Oricum am lua-o, oamenii care dezvolta un citeste mai departe


Clientul nu e inamicul tau

Spuneam intr-unul din articolele anterioare ca – in IT si nu numai – clarificarea cerintelor clientului este o parte importanta a procesului de PM.
De multe ori (de cele mai multe ori, din pacate) materialul primit de la clienti se rezuma la cateva fraze aruncate intr-un document.

PM-ul va trebui sa faca analiza ideii de business a clientului, s-o dezvolte si s-o clarifice suficient de mult incat rezultatul sa permita emiterea unor specificatii extinse si a unei estimari cat mai exacte.

Ideal ar fi ca – cel putin in cazul proiectelor web – la finalul sesiunii de clarificare a specificatiilor sa ai si un wireframe, care va fi de un real ajutor atat echipei de design cat si programatorilor care se vor ocupa de implementarea propriu-zisa.

Revenind la cele cateva fraze aruncate in documentul clientului – trebuie sa ai mare grija la abordarea lor initiala.
Marea majoritate a clientilor nu sunt oameni tehnici. Asta inseamna ca daca incepi procesul de clarificare cu intrebari tehnice, omul va fi in ceata.
Si fie-ti va raspunde cu “nu stiu, spune-mi tu – ca tu ai experienta in domeniu”, fie se va stradui sa-si reaminteasca cele cateva notiuni tehnice invatate cu ani in urma (pe care le va considera probabil actuale) si sa-ti dea un raspuns pe baza lor.

Oricum – va trebui sa tii minte un lucru. Pentru client, acele specificatii au sens. Pentru el, sunt logice. Sigur, logica lui va fi – foarte probabil – diferita de a ta. Dar nu trebuie sa uiti niciodata ca asa cum tie ti se par logice diverse lucruri, tot asa si lui i se par logice acele citeste mai departe


Bine sau exceptional?

Sa presupunem ca lucrezi intr-un service auto.

Intr-o zi vine un client cu un Logan vechi de cativa ani, pentru un schimb de ulei si de placute de frana. Te intreaba cat il costa toata treaba asta.

Tu – cunoscandu-ti meseria – ii spui ca-l costa (sa zicem) 500 RON, si ca masina va fi gata peste doua zile. Zic 500 RON ca si suma ipotetica, nu-s la curent cu tarifele service-urilor auto. Clientul analizeaza oferta ta, se declara multumit si iti lasa cheile, urmand ca peste doua zile sa revina dupa masina.

Cele doua zile trec, iar clientul revine. Masina lui are uleiul schimbat si placute de frana noi. In plus, ii returnezi surplusul de ulei ramas in urma operatiunii (daca a mai ramas ceva). Clientul se declara multumit, iti plateste cei 500 RON si pleaca in treaba lui. Probabil te va recomanda unor cunoscuti, si astfel ti se va mari clientela.

Asta inseamna c-ai facut o treaba de exceptie? Ei bine… NU. I-ai dat respectivului un pret si un termen, pentru ceva ce ti-a cerut sa faci. Ai respectat termenul si nu ai depasit citeste mai departe


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


Cu un pas mai aproape de Matrix

Acum cateva luni, o echipa de cercetatori de la UC Berkeley a pus la punct o modalitate de a asocia gandurile cu imagini animate (clipuri video). Adica puteau sa inregistreze activitatea neuronala, s-o decodifice si s-o transpuna intr-o suita de imagini ce alcatuiau un scurt film.

Filmul era generat pornind de la aproximativ 5000 de ore de inregistrari video, luate la intamplare de pe YouTube. Adica era aproximat pe baza corelarii activitatii neuronale (inregistrata cu ajutorul unei masini de tip MRI) cu niste imagini deja existente.

O descriere mai detaliata a modului in care se realizeaza acest lucru gasiti aici.

Era – daca vreti – un mod incipient de citire a gandurilor.

Mai jos puteti vedea un exemplu – un rezultat al corelarii despre care vorbeam. Adica – o reconstructie a ceea ce persoana aflata sub observatie “vedea”, dar una facuta citeste mai departe



Deadline vs. creativitate

Conform dictionarului, deadline-ul e o limita, un hotar, o margine.
Un termen final – menit a ne impune sa-l respectam cu strictete.

Sunt rare cazurile in care (la job) ne stabilim propriile deadline-uri. De cele mai multe ori acestea sunt prestabilite, iar cuvantul “trebuie” apare in schema tot mai des.

Clarificam specificatii, analizam proiecte, dam estimari si calendare de lucru.

Cand calendarul rezultat in urma estimarii nu poate fi incadrat in deadline-ul cerut, suntem citeste mai departe


Scara competentelor (II)

Acest articol este o continuare a celui de aici, la finalul caruia spuneam ca voi reveni cu un exemplu clar si o schita explicativa.

Veti gasi aici schita explicativa (alaturi de comentariile aferente), iar exemplul promis va urma (intr-un articol viitor).

In urma unei scurte recapitulari a primului articol, avem urmatorii termeni :

  • 7 grade de experienta pe scara competentelor (raportate la un framework dat) : incepator absolut, incepator, incepator-mediu, mediu, mediu-avansat, avansat, senior
  • 6 seturi de ore necesare pentru studiu, pentru trecerea de la un grad la altul : N1, N2, N3, N4, N5, N6
  • 6 clase de proiecte din care se vor da testele de promovare de la un grad la altul : P1, P2, P3, P4, P5, P6

O ordonare a evenimentelor de mai sus pe axa timpului va arata ca in schita de mai jos :

Identificam asadar momentele de la T0 la T6, dupa cum urmeaza citeste mai departe


Pages:123