În ultima perioadă, discuția despre IA în IT a fost dusă foarte mult în zona de tooluri. Ce poate face Copilot? Cât cod poate genera un model? Cât de repede poate un developer să termine un task? Sunt întrebări valide, dar cred că ele acoperă doar o parte din schimbare.
Din punctul meu de vedere, impactul real al IA nu va fi doar în felul în care scriem cod. Impactul mai mare va fi în felul în care organizăm munca de la idee până în producție.
În multe organizații IT, mai ales în cele mari, livrarea de software este împărțită pe roluri și echipe specializate: Business Analyst-ul colectează cerințele; Product Owner-ul le pune în backlog; Developerii implementează; QA-ul testează; DevOps-ul pregătește release-ul. Echipa de infrastructură gestionează mediile. Operațiunile și suportul intervin după ce soluția ajunge în producție.
Modelul acesta nu este greșit. A funcționat mulți ani și a ajutat companiile să scaleze. Problema este că, odată cu scalarea, a apărut și foarte multă fricțiune.
Fiecare transfer între roluri înseamnă un pic de context pierdut. Fiecare handover generează întâlniri, tichete, documentație, clarificări și uneori rework. Oamenii sunt ocupați, calendarul este plin, dar munca nu se mișcă întotdeauna cu viteza pe care o așteptăm. Aici cred că IA va schimba lucrurile cel mai mult.
Prima schimbare vizibilă va fi la nivel de roluri. Nu pentru că toate rolurile dispar, ci pentru că unele activități nu mai au sens să fie separate.
Un exemplu simplu este zona de requirements. În multe echipe avem Business Analyst, Product Owner, Process Analyst și uneori Data Analyst. Fiecare are o parte din context. Cu IA, o parte din activitățile repetitive, sumarizarea ședințelor, generarea de user stories, draftul de acceptance criteria, analiza feedbackului pot fi susținute mult mai ușor. Asta permite apariția unui rol mai integrat, de tip Product Discovery Lead.
La fel, în delivery management, multe activități de PMO, project coordination și status reporting pot fi automatizate sau cel puțin accelerate. Asta nu elimină nevoia de leadership în livrare. Rolul de Delivery Manager nu mai este doar despre a colecta statusuri, ci despre a elimina blocaje, a înțelege dependențe și a face flow-ul să funcționeze mai bine.
În zona de development și testare, schimbarea poate fi și mai vizibilă. Developerul nu va mai fi doar persoana care scrie cod. Cu IA, același om poate genera cod, teste unitare, date de test, documentație tehnică și chiar explicații pentru un reviewer. În același timp, QA-ul se mută dinspre testare manuală repetitivă spre strategie de calitate, testare exploratorie, scenarii de risc și validare end-to-end.
Așa apar roluri precum AI Product Engineer și Quality Engineer. Nu ca denumiri de modă, ci ca răspuns la faptul că munca se compactează în jurul ownershipului.
Când vorbim despre IA și productivitate, multă lume se gândește imediat la developer productivity. Este normal. Codul este vizibil, iar toolurile de code generation sunt cele mai discutate. Dar în organizațiile reale, codingul este doar o parte din efortul total.
Mult timp se pierde înainte și după coding: în clarificări, ședințe de aliniere, documentație, estimări, testare manuală, pregătirea mediilor, approvaluri de release, monitorizare, suport și raportare.
Dacă IA reduce doar timpul de scriere a codului, impactul este util, dar limitat. Dacă IA reduce handoverele din tot SDLC-ul, atunci schimbarea este mult mai mare.
Să luăm testarea. Dacă IA poate genera test cases, test data și regression scenarios, rolul de Manual QA Tester sau Test Case Writer ca rol separat devine mai greu de justificat în multe contexte. Nu înseamnă că dispare calitatea. Înseamnă că ea trebuie mutată mai aproape de engineering.
Să luăm release-ul. Dacă pipeline-urile sunt standardizate, mediile sunt self-service, iar release readiness poate fi verificat automat, atunci rolurile de Build Engineer, Release Coordinator sau Environment Manager în forma lor clasică se reduc. Munca nu dispare complet, dar se mută spre Platform Engineer sau Release Reliability Engineer.
Să luăm suportul. AI agents pot ajuta la password reset, ticket routing, known issues, incident summaries și corelarea alertelor. Asta poate reduce echipele mari de L1 support sau NOC, dar crește nevoia de oameni care pot construi și opera automatizarea: AIOps, reliability engineering și Digital Workplace Automation.
O greșeală pe care am văzut-o în multe transformări este că organizația schimbă denumirile rolurilor, dar păstrează același mod de lucru. După câteva luni, oamenii au job titles noi, dar munca trece prin aceleași queue-uri, aceleași approvaluri și aceleași dependențe.
Într-o transformare AI-enabled, nu aș începe cu întrebarea: "câți oameni putem reduce?". Aș începe cu întrebarea: "unde se blochează munca?".
Un exercițiu foarte simplu, dar extrem de util, este să mapezi un value stream real, de la idee până în producție. Nu procesul ideal dintr-un slide, ci procesul real. Cine primește cererea? Cine o clarifică? Cine o aprobă? Când intră developmentul? Când apare testingul? Cât stă munca în așteptare? Câte tichete se creează doar pentru a muta informație dintr-un loc în altul?
De multe ori, acolo apar surprizele. Nu descoperi neapărat că oamenii nu muncesc. Descoperi că sistemul îi obligă să petreacă prea mult timp mutând context, confirmând informații și așteptând decizii. Aici trebuie să intervină noul operating model.
O echipă modernă nu trebuie să fie doar mai mică. Trebuie să aibă mai puține handovere și mai mult ownership end-to-end.
Un posibil model ar putea arăta așa:
| Arie de responsabilitate | Rol AI-enabled |
|---|---|
| Discovery, cerințe, backlog și proces | Product Discovery Lead |
| Flow, planificare, riscuri și dependențe | Delivery Manager |
| Development, integrare, basic testing și delivery readiness | AI Product Engineer |
| Strategie de calitate, test design, risc și validare | Quality Engineer |
| Platformă, pipelines, infrastructură și medii | Platform Engineer |
| Release safety și producție | Release Reliability Engineer |
| Monitoring, incidente și insight operațional | AIOps |
| Suport, knowledge și automatizare workplace | Digital Workplace Automation Engineer |
Important este că aceste roluri nu trebuie să fie întotdeauna FTE full-time într-o echipă. Într-o organizație mare, unele pot fi shared. Dar ownershipul trebuie să fie clar. Cineva trebuie să fie responsabil de flow, de calitate, de platformă, de release și de experiența post-producție.
Un alt risc este să credem că un model mai rapid înseamnă mai puțin control. Nu cred asta. În enterprise, mai ales în industrii reglementate, ai nevoie în continuare de arhitectură, securitate, conformitate, auditabilitate și quality gates. IA nu elimină aceste lucruri. De fapt, în unele cazuri le face și mai importante.
Diferența este că guvernanța trebuie integrată în flow, nu adăugată la final ca un zid de approvaluri. Code review-ul, security scanningul, testarea automată, deciziile de arhitectură, evidențele de conformitate și criteriile de release trebuie să fie parte din modul normal de lucru. Controlul bun nu ar trebui să încetinească inutil livrarea. Ar trebui să o facă mai sigură.
Nu aș recomanda o transformare big bang. Este prea riscant și, de obicei, produce rezistență. Aș începe cu un product stream, un value stream sau un ART. Măsori cum funcționează astăzi, identifici unde sunt handoverele mari, introduci câteva roluri AI-enabled, automatizezi activitățile repetitive și compari după câteva cicluri de livrare.
Metricile trebuie să fie simple:
După un astfel de pilot, discuția despre FTE devine mai matură. Nu mai este o estimare teoretică. Devine o consecință a unui flow mai simplu.
IA nu va transforma IT-ul doar pentru că scrie cod mai repede. Îl va transforma pentru că pune presiune pe toate zonele unde noi, ca industrie, am construit prea multă coordonare, prea multe handovere și prea multă muncă repetitivă.
Rolurile se vor schimba, echipele se vor redimensiona, iar modelul de operare va trebui regândit. Dar organizațiile care vor câștiga nu vor fi neapărat cele care reduc cel mai repede headcountul. Vor fi cele care înțeleg unde se pierde valoare astăzi și redesenează modul de lucru în jurul flow-ului.
Din experiența mea, pot afirma că aici este diferența dintre o transformare reală și una doar pe hârtie. Dacă după IA oamenii au titluri noi, dar încă așteaptă aceleași aprobări, încă fac aceleași ședințe și încă pierd context la fiecare pas, nu s-a schimbat mare lucru.
Schimbarea reală se vede atunci când o cerință nu mai pierde context până ajunge la engineering, testingul nu mai descoperă probleme de bază la final, release-ul nu mai cere zece confirmări manuale, iar suportul nu mai pornește de la zero la fiecare incident cunoscut. Acolo începe, de fapt, modelul operațional bazat pe IA.
de Vlad Petrean
de Ovidiu Mățan
