ro
Instrumente, Manager de proiect
Manager de proiect AI: De ce construirea unor agenți AI este doar un alt proiect IT
La câteva luni după ce inteligența artificială generativă a devenit suficient de practică pentru a fi utilizată în construcții, ceva interesant a început să se întâmple în partea noastră de FlexiProject – echipa de afaceri, nu cea de inginerie. Fără să scriem niciun cod, am avut brusc agenți care executau în liniște părți din munca noastră de zi cu zi: pregăteau oferte pentru clienți, completau datele din contracte, extrăgeau Rapoarte Search Console, ne actualizau portofoliul de produse după întâlnirile cu clienții, ne ajutau să gestionăm site-ul web. Crearea lor s-a dovedit a fi partea ușoară. Ceea ce nu ne așteptam era că managerul de proiect AI, care tratează fiecare agent ca pe un proiect software real, cu un plan, o ramură comună, teste și o etapă de livrare, va conta la fel de mult ca orice proiect livrat vreodată de inginerii noștri. Aceasta este povestea a ceea ce am învățat, în ordinea în care am învățat.
În acest articol, veți afla:
|
Cum a început o echipă de afaceri să construiască agenți AI
Construirea de agenți AI chiar dacă nu suntem IT
Partea interesantă a ultimilor doi ani este că nu mai este nevoie de o echipă de dezvoltare pentru a livra AI funcțional. Un om de afaceri care poate descrie ce ar trebui să se întâmple și poate copia câteva exemple de intrări, poate construi un agent care să facă treabă adevărată. Nu am plănuit să devenim constructori. Am continuat să ne confruntăm cu Activități la care răspunsul era evident „acest lucru ar putea fi făcut de un agent”, așa că am început să construim. Prima a durat o după-amiază. A doua a durat o după-amiază. Apoi au început problemele – nu cu clădirea, ci cu tot ce era în jurul ei.
Agenții pe care i-am construit
Lista a crescut mai repede decât ne așteptam. Avem un agent care completează automat datele clientului în contractele noastre Standard. Un agent care pregătește primele proiecte de ofertă pe baza unui rezumat al conversației de vânzare. Un integrator care importă lista de proiecte Excel a unui client direct în mediul său FlexiProject. Un asistent care ne ajută să gestionăm părți ale site-ului nostru web. Un agent care extrage datele Google Search Console pentru domeniul nostru și le transformă într-un rezumat săptămânal ușor de citit. Un agent care, după întâlnirile cu clienții, actualizează portofoliul nostru de produse cu ceea ce anumite companii consideră că lipsește, astfel încât ideile de caracteristici să nu se piardă între un apel și următoarea sesiune de planificare. Și zeci de agenți mai mici, ajutoare pentru o singură activitate pe care cineva le-a construit pentru sine, le-a îmbunătățit și, în cele din urmă, le-a împărtășit cu echipa.
Atunci când același agent era extins în paralel
Frecarea nu a venit de la agenții pe care i-am construit o dată și de care am uitat. A venit de la agenții care chiar contau. Doi oameni luau un agent util, fiecare avea o idee separată despre cum să îl îmbunătățească și începeau să îl extindă independent. O săptămână mai târziu, aveam două versiuni: solicitări diferite, instrumente diferite conectate, cazuri limită diferite detectate – și nicio modalitate clară de a le îmbina. A fost aceeași problemă pe care dezvoltatorii au rezolvat-o cu decenii în urmă cu Git: nu poți avea două persoane care să lucreze de la un punct de plecare comun și să îl îmbunătățească în direcții diferite fără un model de ramificare. Pur și simplu nu am crezut că avem nevoie de unul. Agenții erau „ușori”. Expresia AI project management nu intrase încă în vocabularul nostru.
De ce dezvoltarea agenților AI este, în esență, management de proiect IT
Construirea agenților este extrem de ușoară
Prima lecție este cea mai incomodă: construirea unui agent este cu adevărat ușoară. Oricine citește acest text ar putea deschide un model și să aibă ceva funcțional într-o oră. Demonstrația va arăta magic. Primilor trei utilizatori le va plăcea. Și acesta este exact momentul în care proiectul devine dificil, deoarece trimiterea unui demo nu înseamnă trimiterea unui instrument pe care compania se poate baza. Diferența dintre „funcționează pe baza datelor pe care le-am încercat eu” și „funcționează pe baza datelor pe care întreaga companie le furnizează” este enormă, iar modelul în sine nu face nimic pentru a o reduce. Pentru aceasta este nevoie de managementul proiectului AI.
O echipă de afaceri care creează agenți AI trebuie să învețe managementul proiectelor IT
Atunci când o echipă non-IT începe să construiască software, iar un agent este un software, acesta moștenește toate problemele pe care echipele de ingineri le-au învățat timp de 50 de ani să le rezolve. Cerințele trebuie să fie scrise. Arhitectura trebuie să fie proiectată. Codul, prompterele sau definițiile instrumentelor trebuie să existe într-un loc comun. Testele trebuie să existe. Modificările trebuie revizuite înainte de a fi puse în aplicare. Sărirea peste oricare dintre aceste etape nu le face să dispară; doar devansează costurile în timp. Vestea bună este că manualul există deja. Disciplinele care asigură succesul proiectelor IT se aplică neschimbate atunci când o echipă de afaceri construiește agenți. Singurul ingredient nou este evaluarea – versiunea specifică IA a testării.
Încercați FlexiProject!
Ciclul de viață al proiectului AI Agent
1. Analiza inițială – ce problemă rezolvăm de fapt?
Orice agent care merită construit începe cu o fază de analiză care nu are nimic de-a face cu inteligența artificială. Cine va utiliza acest lucru? Ce fac ei astăzi, pas cu pas? Care dintre acești pași chiar dăunează? Cum arată „bine făcut” – în mod măsurabil? Înainte de a construi agentul de pregătire a ofertelor, am notat secvența manuală exactă pe care o urma echipa de vânzări, am marcat pașii care erau repetitivi și cei care necesitau judecată și abia apoi am decis ce ar trebui și ce nu ar trebui să facă agentul. Analiza a durat mai mult decât construirea. Acest raport este normal.
2. Planificare – domeniu de aplicare, integrări, filială comună
Planificarea este momentul în care decideți trei lucruri: intrările și ieșirile, integrările pe care le va atinge agentul și, cel mai important, locul de desfășurare a activității. Dacă două persoane urmează să contribuie, acestea au nevoie de o definiție comună a „principalului”. Aceasta poate fi un singur document cu prompterele canonice și definițiile instrumentelor, un repo, un folder de competențe – formatul contează mai puțin decât acordul. Alegeți-l în prima zi. Decideți ce nu va face agentul, scrieți acest lucru și respectați-l; scope creep este cel mai frecvent motiv pentru care agenții devin imposibil de întreținut.
3. Dezvoltarea – partea înșelător de ușoară
Construcția în sine este rapidă. Aceasta este capcana. Îți vei scrie instrucțiunile, îți vei conecta uneltele, vei rula câteva exemple și te vei simți realizat în proporție de 80%. Mai degrabă 30%. Restul de 70% reprezintă tot ceea ce nu ați testat încă: intrările ciudate, intrările lungi, intrările în altă limbă, cazurile în care un instrument returnează un rezultat gol, cazurile în care utilizatorul se răzgândește în mijlocul conversației. Nimic din toate acestea nu este vizibil din interiorul construcției.
4. Testarea – și apoi retestarea
Aici este unde agenții diferă cel mai mult de software-ul clasic și unde majoritatea echipelor fac economii. Un agent trece un test astăzi și ar putea să nu treacă același test mâine pentru că ați schimbat o singură linie în prompt sau pentru că modelul de bază a fost actualizat. Disciplina de care aveți nevoie este evaluarea regresiei: un set salvat de intrări cu comportamente așteptate, rulat automat, sau cel puțin sistematic, după fiecare modificare. Fără aceasta, veți afla despre regresii doar atunci când un utilizator se împiedică de ele.
5. Livrarea și predarea
Un agent care nu este niciodată livrat oficial este un agent care devine moștenit din prima zi. Livrarea înseamnă redactarea documentației pentru utilizatori, definirea aspectului succesului în producție și stabilirea unei modalități de a monitoriza dacă agentul este încă util după trei luni. Am învățat acest lucru pe calea cea mai lentă – a se vedea secțiunea următoare.
MVP, Agile și Scrum în proiectele AI
MVP în primul rând – începeți cu cel mai mic agent util
Fiecare agent pe care l-am construit și care a avut succes a început ca cea mai mică versiune utilă a sa. O activitate. O intrare. O ieșire. Am rezistat tentației de a adăuga al doilea caz de utilizare până când l-am văzut pe primul supraviețuind contactului cu utilizatori reali. Agenții care au avut probleme au fost opusul: ambițioși din prima zi, cu trei capacități dintre care niciuna nu a funcționat până la capăt. Agenții big-bang eșuează din exact aceleași motive pentru care eșuează proiectele software big-bang; factorul de formă nu schimbă calculele. Dacă luați o singură regulă din acest articol, luați-o pe aceasta: un MVP pentru un agent AI este suficient de mic încât o persoană să îl poată descrie în trei propoziții și să îl poată rula de la un capăt la altul pe un exemplu real până la sfârșitul unei zile. Tot ce urmează după aceea este iterație.
De ce Agile se potrivește în mod natural agenților AI
Agenții sunt neobișnuit de potriviți pentru munca Agile deoarece sunt neobișnuit de imprevizibili. Un agent nu poate fi specificat în întregime în prealabil, așa cum se specifică un formular de plată sau un raport. Creați o versiune mică, urmăriți cum funcționează în lumea reală, vedeți unde eșuează, apoi reparați următorul lucru. Încercarea de a proiecta agentul perfect pe hârtie înainte de a-l construi este cel mai rapid mod de a construi un agent greșit. Iterarea nu este o preferință în materie de gestionare a proiectelor pentru inteligența artificială; este o cerință structurală – același ritm Plan, Do, Check, Act pe care Deming l-a descris cu zeci de ani în urmă pentru orice proces care trebuie să se îmbunătățească continuu, aplicat doar agenților al căror comportament nu poate fi pe deplin prevăzut.
Desfășurarea activității de agent în sprinturile Scrum
Tratăm fiecare agent semnificativ ca pe un mic flux de lucru în stil Scrum. Există un portofoliu de capabilități pe care agentul le-ar putea avea. Fiecare sprint selectează un număr mic dintre acestea. Demonstrația sprintului este agentul în sine, rulat pe baza datelor reale de la echipa care îl va utiliza. Dacă demonstrația nu este convingătoare, munca continuă; cadența forțează o conversație reală între constructor și utilizatori, în loc de o construcție tăcută de luni de zile.
Greșeli pe care le-am făcut
Construirea înainte de analiză
Deoarece construcția este atât de rapidă, pare eficient să treci direct la ea. Dar nu este așa. Agenții pe care i-am construit fără o analiză clară au ajuns să funcționeze din punct de vedere tehnic, dar să rezolve o problemă greșită; echipa care îi folosea a fost politicoasă o vreme și apoi s-a întors liniștită să facă treaba manual. O după-amiază de analiză ar fi salvat o săptămână de construcție.
Încrederea în model pentru a găsi o soluție
Aceasta a fost cea mai frecventă eroare a noastră și cea mai greu de deprins. Am presupus că, dacă îi dăm modelului sarcina într-un limbaj simplu, acesta va concepe o soluție bună. De multe ori nu a fost așa – nu pentru că modelul ar fi fost slab, ci pentru că nu am făcut noi înșine munca de proiectare. Modelul nu cunoaște contextul companiei dvs., datele existente, convențiile nescrise, sistemul din jurul sarcinii. Cu cât îi oferiți mai multe din acestea, o analiză reală, o arhitectură reală, structura pe care doriți să o urmeze, cu atât rezultatul este mai bun. Modelul este excelent la execuție. El nu este arhitectul dumneavoastră.
Mergând la big-bang în loc să începeți cu un MVP
De fiecare dată când am încercat să lansăm un agent complet în prima zi, rezultatul a durat mai mult, a fost mai greu de depanat și a fost abandonat mai des decât versiunile mici pe care le-am dezvoltat în mod deliberat. Big-bang-ul părea mai rapid. Dar nu a fost așa.
Două persoane dezvoltă același agent în paralel
Acesta a fost momentul Git. Doi oameni, același agent, idei diferite, ramuri diferite în capul lor, niciun „principal” comun. O săptămână mai târziu, două versiuni care nu se reconciliau. Acum tratăm fiecare agent semnificativ în același mod în care dezvoltatorii tratează codul: o versiune canonică, un model explicit de ramificare atunci când mai mult de o persoană lucrează la el și o etapă explicită de fuzionare. Sau, dacă ideile sunt cu adevărat divergente, o decizie deliberată de divizare în doi agenți separați în loc să pretindem că sunt încă unul singur.
Lipsa documentației inițiale – utilizatorii nu știau ce face agentul
Primii utilizatori interni ai competențelor noastre au continuat să pună aceleași întrebări: ce face de fapt acest lucru, ce trebuie să introduc, cum arată rezultatul, când ar trebui să îl folosesc față de versiunea anterioară. Am crezut că agentul se explică de la sine. Nu a fost așa. Acum scriem o scurtă descriere adresată utilizatorului pentru fiecare agent la predarea acestuia – ce face, ce trebuie să îi dai, la ce să te aștepți, ce nu face. Costă zece minute și previne săptămâni de utilizare confuză.
Încercați FlexiProject!
Întrebări frecvente despre managementul de proiect AI
Este managementul proiectelor AI diferit de managementul proiectelor IT obișnuite?
Disciplinele sunt aceleași – analiză, planificare, construcție, testare, livrare, iterație. Diferențele se regăsesc în fazele de construcție și testare: rezultatele sunt nedeterministe, comportamentul poate devia atunci când se schimbă modelul sau instrucțiunile, iar „testarea” devine „evaluarea în raport cu un set de cazuri păstrate”. Totul în jurul acestor faze arată ca un proiect IT normal.
Am nevoie de un instrument de gestionare a proiectelor pentru a gestiona dezvoltarea agenților AI?
Aveți nevoie de un loc în care fiecare agent trăiește ca un proiect: cu un plan, o versiune curentă, un proprietar și o stare de livrare. Indiferent dacă acel loc este un sistem de gestionare a proiectelor, un wiki sau o structură de dosare, contează mai puțin decât existența unui astfel de sistem. Pentru echipele care gestionează mai mulți agenți în paralel, un sistem PM real se amortizează rapid.
Cât de mare ar trebui să fie un agent MVP?
Suficient de mică încât o persoană să o poată descrie în trei propoziții și să o ruleze de la un capăt la altul pe un exemplu real până la sfârșitul unei zile. Dacă nu puteți, domeniul de aplicare este prea mare, iar MVP-ul este ceva mai restrâns în interiorul acestuia.
Cum împiedicați două persoane să construiască același agent în paralel?
Nu opriți două persoane să contribuie – faceți explicit unde se află versiunea canonică, cui îi aparține fuziunea și când ideile divergente ar trebui să devină o bifurcare deliberată în doi agenți separați. Lecția din ingineria software se aplică unu-la-unu: o ramură comună, cu un proces de fuzionare convenit.
Când devine un agent moștenitor?
În momentul în care nimeni nu este responsabil să evalueze dacă mai este util. Un agent pe care nimeni nu îl verifică se degradează în liniște, lumea din jurul său se schimbă, datele de intrare evoluează, modelul de bază este înlocuit și, într-o zi, acesta greșește și nimeni nu observă. Moștenirea nu este o vârstă, este o stare de neglijență.
Concluzie
Partea interesantă a creării agenților AI, modelul, prompterele, momentul în care un demo funcționează pentru prima dată, reprezintă cea mai mică parte a muncii. Părțile neexcitante sunt cele care transformă un demo într-un instrument pe care întreaga companie se poate baza: o analiză clară, un plan real, o ramură comună, teste de regresie, documentație și un ritm de iterație care menține agentul util mult timp după livrarea primei versiuni. Nimic din toate acestea nu este exotic. Este exact disciplina care face ca proiectele IT să aibă succes de zeci de ani, aplicată fără diluare la un tip de software puțin mai nou. Echipele care adoptă această disciplină din timp ajung să aibă agenți în care au încredere. Echipele care o omit ajung să reconstruiască același agent de două ori. Tratarea fiecărui agent ca pe un proiect real, cu un plan pe care îl puteți stabili, revizui și îmbunătăți, este ceea ce înseamnă în practică managementul proiectelor AI. Noi facem acest lucru în FlexiProject, unde fiecare agent primește propria fișă de proiect cu un plan de acțiune clar scris; indiferent de sistemul pe care îl alegeți, tratați fiecare agent ca pe un proiect, nu ca pe un experiment.
AUTOR
Dominik Wrzosek
General Manager at FlexiProject
![Ce este o diagramă Gantt și cum se creează una? [EXEMPLU]](https://flexi-project.com/wp-content/uploads/2024/04/What-is-Gantt-chart-e1714048900401.png)
