Învață să codezi sfatul care a devenit mai rău decât Fă-ți un tatuaj pe față
Pe măsură ce inteligența artificială (AI) avansează cu pași repezi, un sfat care părea de aur pentru tinerii care își construiau cariera a devenit în prezent complet depășit și chiar nociv. Expertul în risc Ian Bremmer a afirmat recent în cadrul emisiunii „Real Time with Bill Maher” că „învață să codezi” este acum sfatul cel mai prost pe care îl poți da, chiar mai rău decât să îndemni pe cineva să-și facă un tatuaj pe față. Cum s-a ajuns aici? Ian Bremmer explică faptul că în urmă cu doar câțiva ani, cel mai inteligent sfat pentru cei tineri era să învețe programare. Acest domeniu părea o cale sigură spre un viitor prosper, cu joburi bine plătite în domeniul tehnologiei. Însă acum, odată cu proliferarea inteligenței artificiale, realitatea s-a schimbat dramatic. Tehnologia a început să înlocuiască rapid munca umană în multe poziții, inclusiv în cele de programatori. Datele recente confirmă această tendință. Un raport al Rezervei Federale din New York arată că absolvenții din domeniul informaticii și ingineriei calculatoarelor se confruntă cu rate de șomaj chiar mai mari decât cei care au studiat domenii precum jurnalismul, științele politice sau limba engleză. Mai exact, rata de șomaj pentru absolvenții în informatică a fost de 6,1%, iar pentru cei în inginerie calculatoarelor de 7,5%, în comparație cu o medie generală de 5,8% pentru toți absolvenții. Aceasta este o schimbare surprinzătoare și dezamăgitoare, mai ales pentru o zonă care a fost cândva considerată o opțiune „sigură” și profitabilă. „Învață AI” – noul clișeu care nu rezolvă problema Pe măsură ce „învață să codezi” a devenit un sfat inutil, noua recomandare care circulă în industria tech este „învață AI”. Cu toate acestea, și acest nou îndemn riscă să devină la fel de falimentar pe termen lung. Joe Procopio, fondator tech și consilier, a subliniat într-un articol publicat în Inc Magazine că actuala generație de „talent AI” știe cum să folosească instrumente precum GitHub Copilot, dar asta nu înseamnă neapărat că produce coduri mai bune sau aplicații mai performante. În esență, AI generează o mulțime de coduri „slabe”, iar mulți dintre cei care au învățat să codeze s-au transformat într-o forță de muncă ușor de înlocuit de către inteligența artificială. Astfel, cercul vicios se închide: programatori care nu mai sunt indispensabili și care vor fi treptat înlocuiți de AI. Rutger Bregman, istoric și autor, a menționat într-o discuție despre această problemă că, pe măsură ce AI va absorbi din ce în ce mai multe joburi, capitaliștii vor crea noi slujbe inutile pentru a ocupa oamenii, însă aceste poziții nu vor fi neapărat mai bune sau mai sigure. Ce înseamnă acest lucru pentru viitorul carierelor tehnologice? Această realitate pune o întrebare crucială pentru viitorul tinerilor care vor să-și construiască o carieră în domeniul IT sau AI. În timp ce AI-ul continuă să avanseze și să preia sarcini din ce în ce mai complexe, rolul programatorilor umani se schimbă și el. Sfatul „învață să codezi” nu mai este sinonim cu un viitor sigur, iar „învață AI” poate fi doar o mutare temporară în această cursă de adaptare. Pentru cei interesați să rămână relevanți pe piața muncii, succesul va veni din înțelegerea profundă a modului în care AI-ul funcționează, dar și din dezvoltarea unor competențe complementare pe care mașinile încă nu le pot reproduce – creativitatea, gândirea critică, gestionarea proiectelor sau relațiile umane. În concluzie, lumea muncii se schimbă fundamental, iar adaptarea este obligatorie. Este clar că simplele sfaturi „învață să codezi” sau „învață AI” nu mai pot garanta succesul profesional fără o înțelegere mai amplă a ecosistemului digital și a modului în care tehnologia redefinește joburile. Fiecare dintre noi trebuie să privească mai departe de clișee și să caute să învețe cum să lucreze împreună cu tehnologia, nu doar să încerce să o imite sau să o concureze. Acest articol pune în lumină provocările aduse de inteligența artificială asupra unei industrii odinioară stabile și arată că, pentru a avea succes, trebuie să fim mult mai flexibili și informați decât oricând.
Cum să depășim conflictele dintre business analiști (product management), programatori și QA [P]
![cum-sa-depasim-conflictele-dintre-business-analisti-(product-management),-programatori-si-qa-[p]](https://ziaruiasi.ro/wp-content/uploads/2025/05/6323-cum-sa-depasim-conflictele-dintre-business-analisti-product-management-programatori-si-qa-p-1024x683.jpg)
Echipele de dezvoltare software sunt formate din oameni care pot avea mentalități diferite, provin din medii diferite, au skill-uri și experiențe diferite, etc. De multe ori apar conflicte și dezbateri aprinse, ajungându-se astfel ca momentele tensionate să facă parte din munca de zi cu zi. Cheia este să identifici zonele în care pot apărea probleme și să găsești soluții clare pentru ele, care să economisească timp, energie, și nervi, și să ajute echipa să lucreze împreună. Ideal ar fi să nu existe astfel neînțelegeri, dar în cazul în care se întâmplă este nevoie să găsim modalități de a le rezolva și clarifica. Iată câteva exemple de conflicte precum și soluțiile pe care le-am întâlnit în Cognyte. 1. Nu este o eroare, dar nici nu este chiar o caracteristică. Unul din membrii echipei de QA detectează și ridică un bug (o eroare software) în Jira (Instrument de Urmărire a Problemelor și Managementul de Proiect). Team Lead: Merge bine. Nu înțeleg de ce spui că e bug. Așa a fost specificat că trebuie să funcționeze. QA: De fapt, este un scenariu pe care nu l-ai luat în considerare când ai scris codul. Clientul ne-a trimis niște scenarii pe care ei le folosesc și, din păcate, nu funcționează cu ce le-am livrat noi. Programatorul: Ok, pot înțelege că sunt scenarii noi, dar nouă nu ni s-a spus atunci când au fost făcute specificațiile. Pentru noi este ceva nou. QA: Înțeleg, din păcate, scenariile acestea vin de la client și ei au nevoie de funcționalitățile acestea. Hai să vedem ce zice și echipa de business analiști. Business analist: Înțeleg ce spuneți, pare că nu am luat în considerare scenariile respective. Care sunt estimările pentru schimbările acestea? Programatorul: Estimăm 200 de ore de lucru, și va trebui să replanificăm ce facem acum, pentru că este clar că vom avea întârzieri. Business analist: Ok, înțeleg. Hai să discutăm astfel încât să găsim o soluție. Răspunsul care îi poate enerva pe cei de la QA și, uneori, pe clienți este: „funcționează conform specificaţiilor”. Practic, acest lucru înseamnă că produsul funcţionează conform specificaţiilor, dar nu satisface pe deplin nevoile clientului. Este posibil să putem schimba, dar trebuie să ținem cont de costuri: orele de lucru care vor întârzia alte evoluții la deteriorarea mai multor sisteme (mai ales atunci când vine vorba de un produs complex, bogat în date, cu componente și integrări, precum și de utilizatorii activi din întreaga lume). Categoric se pot face schimbările necesare, dar trebuie să ținem cont și de costurile pe care le implică. Sunt ore suplimentare de care trebuie să ținem cont, apoi pot exista efecte adverse, posibil impact în alte zone ale produsului care pot face ca alte funcționalități să nu mai meargă. Asta este foarte posibil atunci când discutăm de un produs complex, cu multe componente și integrări, cu un volum de date semnificativ, clienți din toată lumea, și mai ales o industrie cu toleranță zero pentru perioadele de nefuncționare (zero tolerance for downtime), așa cum avem la Cognyte. Toate aceste aspecte trebuie luate în considerare. Ce este important de înțeles, este că nu vorbim de un „blaming game”. Nu arătăm pe nimeni cu degetul. Dacă echipă de QA ridică și confirmă în final un bug, este numai după ce se consultă și cu echipa de programatori. Dacă, în schimb, este o problemă mai complexă, atunci se apelează și la echipa de BA (business analist), cea care conduce din punct de vedere funcțional produsul. Ce se ȋntâmplă când toată lumea are dreptate? Este important să înțelegem că orice modificare are un cost, care nu este întotdeauna ușor de evaluat. Doar cei care cunosc cum funcționează întregul sistem, infrastructura sa și posibilul impact, pot estima cât de cât corect costul real al implementării unei schimbări complexe. Și chiar și în aceste cazuri, nu există o siguranță în estimare. O estimare este doar… o estimare. În final, deciziile de a implementa o cerință nouă depinde de priorități, iar echipa de business analiști (product management) și project management este implicată aici. În cazuri speciale, deciziile pot ajunge și la C-level. Totuși, înainte de orice decizie, inițiem o discuție deschisă, unde toate părțile implicate pot veni cu argumente pro și contra, încercând să luăm o decizie care să ne ajute pe viitor, atât din punct de vedere al clientului actual, cât și a altor clienți existenți sau potențiali. O discuție de acest tip poate duce la două rezultate: fie noua cerință va fi rezolvată ca un bug fix, fie vom decide că este o limitare a versiunii actuale urmând să o implementăm într-o versiune viitoare. O altă abordare pe care o avem este de a ne defini un plan de testare, convenit cu echipa de QA, înainte de începerea scrierii codului (test driven-development). Acest lucru ajută la definirea clară a așteptărilor și permite programatorilor să știe ce scenarii vor fi testate, astfel încât să poată scrie codul cât mai corect de la început. De asemenea, planul de testare este aprobat de echipa care coordonează cerințele funcționale. Această metodă ajută la reducerea bug-urilor și asigură o bună aliniere între echipe din punct de vedere al înțelegerii noilor cerințe. 2. Modificare majoră sau corecție minoră? Am menționat că produsele noastre sunt complexe. Unele dintre ele sunt atât de complicate încât o nouă versiune poate apărea doar o dată pe trimestru sau chiar mai rar, uneori la șase luni sau chiar mai mult. Chiar și actualizarea unei versiuni pe platformele interne (On-Premises) este un proces semnificativ. Nu este vorba doar de un „click pe un buton”. Totuși, asta nu împiedică clienții să ne trimită cerințe noi în tot acest timp. Aceste solicitări sunt normale și legitime. Pentru a răspunde rapid tuturor clienților, am creat un nou departament numit „Servicii” (Services). Prin acest departament, există o echipă de programatori dedicată pentru a rezolva bug-uri și a implementa mici corecții și actualizări care nu sunt parte din produsul global standard. Ei sunt primii care interacționează cu clienții atunci când apare o problemă. Uneori, echipa de produs (Product Management- PM)