Dacă ne uităm la discursul public, AIul pare să fie deja peste tot. Vorbim despre companii extrem de specializate care construiesc sisteme complexe, despre agenți care se orchestrează între ei, despre automatizări care iau decizii și despre promisiunea unor organizații aproape autonome. La acest nivel, lucrurile sunt reale și, în multe cazuri, impresionante.
În același timp însă, dacă coborâm din zona de headlineuri și ajungem în activitatea de zi cu zi a majorității organizațiilor, imaginea se schimbă radical. În rolurile nontehnice precum manageri, coordonatori, Product Owners, Scrum Masters, consultanți, AIul este folosit într-un mod extrem de superficial. De cele mai multe ori, ca un Google pe steroizi.
Îl folosesc pentru a găsi idei, formate de workshop, explicații sau reformulări pentru prezentări. Ocazional, îl utilizăm pentru reorganizarea și îmbunătățirea textului și, din păcate, cam atât.
Privind retrospectiv, acest decalaj era oarecum inevitabil. Rolurile tehnice au fost primele care au adoptat AIul serios în munca lor, dintr-un motiv simplu: munca lor este mai clar delimitată. Scrierea de cod, chiar dacă este complexă, se întâmplă într-un domeniu relativ bine definit, cu reguli clare, feedback rapid și criterii de validare destul de obiective. În plus, integrarea AIului în IDEuri, sisteme de versionare, pipelineuri au fost mai ușor de realizat. Contextul necesar pentru ca un model să fie util este deja acolo.
Chiar și așa, nici în zona tehnică adopția nu este uniformă. Există dezvoltatori care nu mai scriu efectiv cod, ci orchestrează sisteme complexe: generează, structurează, validează și revizuiesc outputul produs de AI. În același timp, există și dezvoltatori care resping complet folosirea AIului, considerând că greșelile modelelor îi costă mai mult timp decât dacă ar scrie singuri codul. Diferențele sunt mari, chiar și într-un domeniu relativ "favorabil" adopției.
Pentru rolurile nontehnice însă, lucrurile sunt mult mai complicate. Deși multe dintre activități par similare la suprafață, cum ar fi să "compari documente", "analizezi cerințe" sau să "verifici consistența unor artefacte", în realitate ele diferă enorm ca structură, reguli și nivel de ambiguitate.
A compara două documente pentru a verifica dacă un proces apare în ambele poate fi o sarcină relativ simplă: trebuie doar să definești cum sunt delimitate secțiunile și ce înseamnă o potrivire acceptabilă. Dar a deriva requirements pentru un sistem automotive dintrun high level requirements document este cu totul altceva. Acolo vorbim despre standarde stricte de formulare, reguli complexe de descompunere, constrângeri de domeniu, exemple numeroase care trebuie furnizate modelului și criterii clare legate de ce trebuie evitat atunci când scrii un requirement. Din exterior, ambele sunt "comparații de documente". În realitate, sunt lumi complet diferite.
Din acest motiv, automatizarea cu agenți și integrarea AIului în procesele nontehnice presupun mult mai multe tooluri, formate și tipuri de date decât ne-am aștepta. Și, inevitabil, o complexitate mult mai mare decât simpla "generare de text".
Cu toate acestea, lucrurile se mișcă rapid. Din ce în ce mai mult, roluri precum Product Owner, Scrum Master sau Project Manager încep să se transforme. Nu mai sunt roluri care "produc" conținut în mod direct, ci roluri de orchestrare. Aduni informația corectă, o oferi AIului într-un mod structurat, validezi rezultatul și te concentrezi pe calitate.
Iar asta este o schimbare fundamentală. Atenția se mută de la "a scrie" la a citi, a înțelege și a evalua. Generarea de conținut devine aproape banală; discernământul, însă, devine esențial. În acest nou context, valoarea nu mai stă în cât de repede produci ceva, ci în cât de bine știi să judeci dacă acel ceva este corect, relevant și utilizabil.
Dacă ne uităm la esența rolurilor nontehnice din Agile, observăm un lucru comun. Indiferent că vorbim despre Scrum Masters, Product Owners, Product Managers sau roluri de coordonare la scară mai mare precum RTE, test managers sau engineering managers, munca lor se învârte în jurul acelorași preocupări fundamentale. Fluxul de informații, prioritizarea, urmărirea metricilor, calitatea proceselor, structura echipelor și modul în care competențele sunt puse împreună pentru a produce valoare.
Aceste roluri nu "produc" livrabile în sensul clasic. Ele optimizează condițiile în care livrabilele apar. Sunt profund preocupate de eficiență, adică de a obține cât mai mult din resursele existente, dar și de eficacitate, adică de a se asigura că organizația insistă pe lucrurile care contează cu adevărat. Iar exact în această zonă, AI-ul începe să aibă un impact real.
Desigur, majoritatea acestor activități au deja tooluri consacrate. Avem dashboarduri, rapoarte, metrici standard, instrumente de analiză. Ce aduce AI-ul nou nu este neapărat un set complet diferit de rezultate, ci o schimbare de paradigmă în modul în care ajungem la ele. De exemplu, în zona de metrici și date, până nu demult era nevoie de experiență serioasă în Excel, BI sau alte unelte specializate pentru a construi vizualizări mai complexe sau pentru a explora datele din mai multe unghiuri. Astăzi, AI-ul poate accelera dramatic acest proces. Poți ajunge mult mai repede la o formă de reprezentare care îți spune ceva relevant, ceea ce îți permite să îți muți atenția de la "cum construim raportul" la "ce decizii luăm pe baza lui".
Un alt domeniu unde AI-ul începe să depășească limitele toolurilor clasice este analiza organizațională. Aici apar perspective care înainte erau greu de accesat sau extrem de costisitoare. Analiza de sentiment la nivel de grup, de exemplu, devine mult mai fezabilă. Nu mai vorbim doar de stickies din retrospective sau de feedback punctual, ci de posibilitatea de a analiza conversații, texte sau chiar înregistrări pentru a înțelege ce simt oamenii cu adevărat. Pentru retrospective mari sau workshopuri cu multe echipe, acest lucru schimbă complet calitatea conversațiilor pe care le poți avea ulterior.
La fel de interesant este ce se întâmplă în zona de dependențe și coordonare între echipe. Folosind date existente din sisteme precum Jira, comentarii, istoric de modificări sau legături între work items, AI-ul poate scoate la suprafață tipare care până acum rămâneau invizibile. Am avut situații în care, analizând ce echipe apar împreună în features de-a lungul timpului, am putut vizualiza rapid dependențele reale dintre ele și ajusta structura meetingurilor sau a cadrelor de coordonare. Nu pentru că a apărut un nou tool, ci pentru că datele existente au devenit, în sfârșit, interpretabile la scară.
Poate cel mai puternic exemplu vine din zona de analiză a disfuncțiilor din flow. În mod tradițional, când un feature este mutat din "în development" înapoi în backlog, discuțiile sunt adesea bazate pe percepții. Cu ajutorul AI-ului, devine posibil să parcurgi istoricul complet al acelui feature, inclusiv comentariile și discuțiile asociate, și să reconstruiești efectiv ciclul său de viață. Astfel poți identifica tipare recurente, motivele reale pentru care lucrurile se întorc înapoi și să ai, în sfârșit, date concrete pe baza cărora să porți conversații dificile, dar necesare.
Toate aceste exemple indică aceeași schimbare mai profundă. Rolurile Agile nontehnice încep să se mute de la utilizarea unor instrumente rigide către interpretarea unor sisteme complexe de date și interacțiuni. AI-ul nu înlocuiește judecata umană, dar o amplifică. Reduce drastic costul de explorare al informației și deschide un spațiu nou pentru reflecție, decizie și ajustare fină a modului în care organizațiile lucrează.
În acest sens, AI-ul nu schimbă scopul muncii Agile. Schimbă însă viteza și profunzimea cu care putem înțelege ce se întâmplă cu adevărat în interiorul sistemelor noastre de lucru.
1.0 Vizualizarea interacțiunilor între echipe construită pe baza datelor din Jira Features
Pe măsură ce folosirea LLMurilor devine mai sofisticată și sarcinile pe care încercăm să le rezolvăm cu ele devin mai complexe, apar rapid câteva limite clasice. Limite care nu țin neapărat de "calitatea" modelului, ci de natura modului în care aceste sisteme sunt gândite să funcționeze.
Prima limită apare în momentul în care volumul de date devine problematic. Analiza, compararea sau corelarea unor cantități mari de documente începe să creeze dificultăți serioase. Chiar și atunci când modelul poate procesa informația, contextul devine fragmentat, iar controlul asupra a ceea ce este sau nu luat în considerare scade. Pentru sarcini simple acest lucru poate fi acceptabil, dar pentru procese recurente sau esențiale devine rapid o sursă de frustrare.
A doua limită este legată de formatare și reproductibilitate. În multe contexte operaționale ai nevoie de outputuri identice, în același format, de fiecare dată. Orice variație, oricât de mică, în structura rezultatului sau în modul în care modelul face judecăți devine o problemă. Dacă ai nevoie de precizie ridicată sau de evaluări consecvente, diferențele subtile dintre două rulări succesive ale aceluiași prompt pot eroda rapid încrederea în rezultat.
A treia limită este lipsa de interconectivitate. Mutarea manuală a datelor din mai multe surse într-un model "vanilla" este greoaie și consumă timp. Chiar și în ecosisteme bine integrate, cum este cel Microsoft, referențierea informațiilor din locații diferite rămâne, de multe ori, un proces manual. Pentru o singură operațiune ajungi să aduni documente, exporturi, linkuri și contexte din mai multe locuri, ceea ce diminuează considerabil avantajul inițial al folosirii AI-ului.
În acest punct, trecerea de la utilizarea simplă a unui LLM la automatizare prin agenți începe să devină atractivă. Nu pentru că agenții ar fi "mai inteligenți", ci pentru că permit separarea clară a datelor, regulilor și logicii de evaluare. Ei pot gestiona volume mai mari de informație, pot aplica aceleași criterii în mod consecvent și pot conecta surse multiple fără a repeta de fiecare dată același efort manual.
Agenții nu rezolvă toate problemele LLMurilor, dar apar exact în momentul în care folosirea directă a unui model începe să își arate limitele. În special în contexte operaționale, unde consistența, repetabilitatea și integrarea sunt mai importante decât creativitatea, această tranziție devine aproape inevitabilă.
Una dintre cele mai consumatoare de timp activități pentru Product Owners și Scrum Masters este verificarea integrității și calității work containerelor. Stories, Features, Epics și alte tipuri de itemuri trebuie nu doar să existe, ci să fie corect structurate și aliniate la criteriile de calitate ale organizației. Această muncă se repetă constant și presupune atât verificări constante, cât și judecăți calitative, care sunt dificil de menținut consecvente la scară.
Un prim nivel al acestei analize este un readiness check. Majoritatea organizațiilor au reguli clare legate de ce câmpuri trebuie să fie completate pentru un feature sau un story, însă aceste reguli diferă semnificativ de la un client la altul. Faptul că un anumit câmp este obligatoriu pentru un feature aflat într-un anumit status într-o organizație nu înseamnă că aceeași regulă se aplică și în alta. Criteriile depind de context, de industrie și de modul în care organizația alege să își structureze procesul de livrare.
Din acest motiv, am început să folosim agenți pentru acest tip de analiză. În ecosistemul Microsoft, am construit un agent care poate primi un set configurabil de criterii ce definesc ce înseamnă "complet" pentru orice work item. Practic, este vorba despre o mapare între statusuri și câmpurile care trebuie să fie completate pentru fiecare dintre ele. Aceste reguli pot fi ajustate ușor, fără a modifica logica agentului. Outputul este unul vizual și permite o înțelegere rapidă a stării backlogului.
1.1 Readiness check visual pentru features în timpul unui PI pentru câmpurile obligatorii în statusul "Ready for planning"
Acest tip de analiză este extrem de util în contexte precum PI Planning sau urmărirea progresului pe parcursul unui PI. În loc ca Product Owners sau Product Managers să verifice manual zeci sau sute de features, pot vedea instantaneu câte itemuri sunt pregătite, câte nu respectă criteriile și cât de departe este organizația față de stadiul la care ar trebui să se afle într-un anumit moment.
Analiza calității conținutului este însă mai complexă decât simpla verificare a existenței unor câmpuri. Aici nu mai vorbim doar despre dacă un text există, ci despre cât de bine este scris și din ce perspective. Pentru acest tip de evaluare, agentul folosește un document de input care definește criteriile de calitate într-un format ușor de procesat, în cazul nostru Markdown. Acest document stabilește praguri clare pentru diferite niveluri de calitate și poate fi adaptat în funcție de nevoile fiecărui client.
Un concept central în această abordare este folosirea așanumitelor microtrăsături. Pentru fiecare domeniu de calitate analizat, cum ar fi ipoteza de beneficiu a unui feature, există un set de trăsături concrete pe care agentul le caută în text. De exemplu, textul trebuie să conțină o afirmație clară legată de beneficiu sau de rațiunea implementării. Trebuie să fie clar cine este beneficiarul acelui beneficiu, fie că vorbim despre un utilizator, o echipă sau un proces. Beneficiul trebuie să fie cuantificabil sau măcar formulat într-un mod care permite măsurarea, iar acolo unde este cazul, să fie legat de un orizont de timp.
"dimension": "Benefit hypothesis",
"version": "l.1 ,
"grimarv fields": ["Benefit hypothesis"],
"notes": [
"Evaluate only the Benefit Hypothesis field.",
"Focus on clarity, specificity, and measurability of the stated benefit.",
"OK.Rs, KPis, or validation evidence are optional boosters but not required for baseline scoring.",
"A high-quality benefit hypothesis clearly states what improves, for whom, and by how much or how fast."
],
"micro traits": [
{"id": "OUTCOME_BASED", "label": "Outcome-based improvement", "desc": "Describes what measurable aspect improves (speed, accuracy, workload, cost, etc.)
{"id": "QUANTIFIED", "label": "Quantified benefit", "desc": "Includes measurable targets or percentage"
...
1.2 Logica pentru analiza calității folosind "Micro-trăsături" pentru fiecare dimensiune care trebuie analizată.
Aceste microtrăsături nu impun formulări rigide, ci definesc concepte care trebuie să fie prezente în conținut. Agentul caută aceste concepte, le evaluează individual și aplică un sistem de punctaj. Pe baza punctajului agregat, rezultatul este încadrat într-un nivel de calitate, de exemplu de la zero la trei. Astfel, evaluarea devine consecventă și reproductibilă, indiferent de volumul de date analizat.
Agentul este construit să poată procesa date din surse multiple. Pot fi folosite exporturi din Jira, documente Word, fișiere Excel, capturi de ecran sau conexiuni directe prin API. La fel de flexibil este și modul de prezentare a rezultatelor. Se pot genera tabele de overview pentru întregul backlog, analize detaliate pentru fiecare feature sau vizualizări care arată exact unde sunt problemele și de ce.
1.3 Output al agentului care are de clasificat calitatea dimensiunilor pentru un feature
După realizarea analizei, agentul poate fi folosit și pentru a genera recomandări concrete. Poate sugera cum ar trebui îmbunătățită o descriere, ce elemente lipsesc sau poate crea mesaje personalizate pentru persoana care a creat featureul, cu indicații clare despre ce trebuie ajustat. Astfel, analiza nu se oprește la identificarea problemelor, ci sprijină direct procesul de îmbunătățire.
Un aspect important este faptul că setul de criterii de calitate nu este fix. Documentul care definește regulile poate fi modificat în timp, fără a fi nevoie de cunoștințe tehnice sau intervenții în agent. Poate exista ca un document sau o pagină Confluence editabilă de către rolurile relevante, iar agentul își preia criteriile direct de acolo. În acest fel, regulile devin un artefact viu, care evoluează odată cu organizația.
Acest tip de automatizare schimbă natura muncii pentru rolurile Agile. Activitățile repetitive de analiză și verificare pot fi delegate sistemului, în timp ce oamenii rămân implicați în judecata finală, prioritizare și decizie. Analiza poate fi făcută automat, la scară, iar rolurile Agile pot folosi rezultatele pentru a înțelege mai bine unde se află și cât de aproape sunt de rezultatele dorite.
Activitățile repetitive de analiză și verificare pot fi delegate sistemului, în timp ce oamenii rămân implicați în judecata finală, prioritizare și decizie. Analiza poate fi făcută automat, la scară, iar rolurile Agile pot valorifica rezultatele pentru a înțelege mai bine unde se află și cât de aproape sunt de obiectivele dorite.
Pe măsură ce analiza devine mai rapidă și mai precisă, valoarea umană nu dispare, ci se mută într-un spațiu mai sofisticat. Judecata, contextul și responsabilitatea rămân profund umane și nu pot fi automatizate fără pierderi reale. Agile a fost întotdeauna despre adaptare, nu despre ritualuri, iar automatizarea este doar o nouă formă de adaptare. Rolurile nu se simplifică, ci se rafinează, în timp ce succesul va aparține echipelor care înțeleg această schimbare înainte ca ea să devină inevitabilă.
de Radu Dănescu
de Ovidiu Mățan
de Gelu Vac
