Postari cu eticheta: IT

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


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



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


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



Pages:123