Leadership tehnic și project management IT: cazuri reale

Această secțiune povestește partea meseriei care nu se află în planurile de execuție: deciziile, echipele, metoda. Este spațiul leadership-ului tehnic, unde oamenii, sistemele și alegerile trebuie să funcționeze împreună.

Am văzut project manageri care au făcut dezvoltatori seniori să plângă în ședințe. Am văzut echipe strălucite distruse de PM-uri care confundau autoritatea cu autoritarismul. Am văzut software livrat „la timp" care nu funcționa, și proiecte de milioane de euro care s-au terminat în nimic.

Și am văzut exact opusul: echipe mici, autonome, respectate — care construiau sisteme solide într-o fracțiune din timp și buget.

Diferența nu a fost niciodată tehnologia. A fost întotdeauna metoda.

După treizeci de ani în acest mesteria, un lucru l-am înțeles: oamenii nu dau ce au mai bun când le este frică. Dau ce au mai bun când au încredere.

Încredere în echipă. Încredere în proces. Încredere că dacă greșesc, nu vor fi pedepsiți — vor fi ajutați.

Project managerul care funcționează nu este cel care controlează, terorizează și numără orele. Este cel care:

definește obiective clare și dă echipei libertatea de a le atinge
construiește competențe profunde și le protejează de rotație
face team building în fiecare zi, nu o dată pe an la karting
măsoară rezultatele, nu orele la birou
folosește smart working-ul ca avantaj competitiv, nu ca o concesie
când ceva merge prost, se pune în fața echipei, nu în spatele ei

📊 Cum lucrez eu #

Abordarea mea este Scrum — dar Scrum făcut pe bune, nu liturgia notițelor lipicioase.

Scrum-ul care funcționează se bazează pe un pact: transparență radicală, responsabilitate partajată și autonomie în „cum". PM-ul definește ce și de ce. Echipa decide cum. Pentru că cine scrie codul știe mai bine decât oricine cum să-l scrie.

Și acest pact funcționează și mai bine în smart working. Daily standup-ul? 15 minute într-un call. Sprint review-ul? Screen sharing cu clientul, care vede software-ul — nu slide-urile. Retrospectiva? O oră în care echipa spune adevărul, pentru că nu are PM-ul la doi metri care se uită fix la ea.

Măsor puține lucruri, dar le măsor bine:

Metrică	Ce spune
Velocity	Cât livrează echipa per sprint
Lead time	Cât trece de la cerere la lansare
Bug escape rate	Câte defecte scapă în producție
Sprint goal success	% din obiectivele de sprint atinse
Team happiness	Cum se simte echipa — cea mai importantă metrică

Ultima — team happiness — este cea pe care PM-urile tradiționale nu o măsoară niciodată. O echipă fericită nu este o echipă care se distrează. Este o echipă care se simte respectată, ascultată și valorizată. Și o astfel de echipă produce mai mult. Nu pentru că lucrează mai multe ore. Pentru că lucrează mai bine.

📚 Despre ce scriu aici #

Povești reale, numere concrete și lecții învățate. Nimic teorie de manual. Doar ce am văzut că funcționează — și ce am văzut că eșuează.

Scriu despre inteligența artificială aplicată în workflow, despre consultanța IT și costurile ei ascunse, despre smart working ca avantaj competitiv. Fiecare articol provine dintr-o experiență reală — a mea.

Nu e nevoie de revoluții. E nevoie de alegeri precise, implementate cu metodă.

Și de capacitatea de a spune „nu" celor care îți vând complexitate când soluția este simplă.