Řízení projektů AI: Proč je budování sgentů AI jen dalším IT projektem?

Několik měsíců poté, co se generativní umělá inteligence stala dostatečně praktickou, aby se s ní dalo pracovat, se na naší straně FlexiProjectu – v obchodním týmu, nikoli v týmu inženýrů – začalo dít něco zajímavého. Aniž bychom psali jakýkoli kód, najednou jsme měli agenty, kteří v tichosti prováděli části naší každodenní práce: připravovali nabídky pro klienty, vyplňovali údaje o smlouvách, vytahovali zprávy ze Search Console, aktualizovali náš produktový backlog po schůzkách s klienty, pomáhali nám spravovat webové stránky. Jejich budování se ukázalo jako ta snadnější část. Nečekali jsme však, že řízení projektů pomocí umělé inteligence, kdy ke každému agentovi přistupujeme jako ke skutečnému softwarovému projektu s plánem, sdílenou větví, testy a krokem dodání, bude mít stejný význam jako cokoli, co kdy naši inženýři dodali. Toto je příběh o tom, co jsme se naučili, v pořadí, v jakém jsme se to naučili.

V tomto článku se dozvíte:

Proč je budování agentů AI v praxi jen dalším IT projektem?
Pět fází, kterými by měl projít každý projekt AI agenta
Jak se MVP, Agile a Scrum hodí pro práci s agenty AI
Chyby, kterých jsme se na cestě dopustili, a jak se jich vyvarovat
Jak zabránit dvěma lidem v paralelním obnovení stejného agenta

Jak obchodní tým začal vytvářet agenty umělé inteligence

Vytváření agentů umělé inteligence, i když nejsme z oboru IT

Zajímavým zvratem posledních dvou let je, že k dodání funkční umělé inteligence již nepotřebujete vývojový tým. Obchodník, který dokáže popsat, co se má stát, a zkopírovat několik příkladů vstupů, může vytvořit agenta, který odvede skutečnou práci. Neměli jsme v plánu stát se staviteli. Stále jsme naráželi na úkoly, kde odpověď zjevně zněla „tohle by mohl udělat agent“, a tak jsme začali stavět. První z nich nám zabrala jedno odpoledne. Druhý zabral jedno odpoledne. Pak začaly problémy – ne se stavbou, ale se vším kolem.

Agenti, které jsme vytvořili

Seznam se rozrostl rychleji, než jsme očekávali. Máme agenta, který automaticky vyplňuje údaje o klientech do našich standardních smluv. Agenta, který připravuje první návrhy nabídek na základě shrnutí prodejní konverzace. Integrátora, který importuje seznam projektů klienta v Excelu přímo do prostředí FlexiProject. Asistenta, který nám pomáhá spravovat části našich webových stránek. Agent, který stahuje data z Google Search Console pro naši doménu a mění je do čitelného týdenního přehledu. Agent, který po schůzkách s klienty aktualizuje náš produktový backlog o to, co konkrétním firmám podle jejich názoru chybí, aby se nápady na funkce neztratily mezi hovorem a další plánovací schůzkou. A desítky menších, pomocníků pro jednotlivé úkoly, které si někdo vytvořil pro sebe, neustále je vylepšoval a nakonec se o ně podělil s týmem.

Při souběžném prodlužování téhož agenta

Třenice nevznikly kvůli agentům, které jsme kdysi vybudovali a zapomněli na ně. Pocházelo z agentů, na kterých skutečně záleželo. Dva lidé by vzali užitečného agenta, každý by měl samostatný nápad, jak ho vylepšit, a začali by ho nezávisle na sobě rozšiřovat. O týden později jsme měli dvě verze: různé výzvy, různé zadrátované nástroje, různé zachycené okrajové případy – a žádný čistý způsob, jak je sloučit. Byl to stejný problém, který vývojáři vyřešili před desítkami let pomocí systému Git: nemůžete mít dva lidi, kteří pracují na společném výchozím bodu a vylepšují ho různými směry, aniž byste měli model větvení. Jen jsme si mysleli, že ho nepotřebujeme. Agenti byli „snadní“. Slovní spojení řízení projektů s umělou inteligencí se do našeho slovníku ještě nedostalo.

Proč je vývoj agentů AI v podstatě řízením projektů IT

Vytváření agentů je triviálně snadné

První lekce je ta nejnepříjemnější: vybudovat agenta je skutečně snadné. Každý, kdo čte tento článek, si může otevřít model a během hodiny mít něco funkčního. Demonstrace bude vypadat kouzelně. Prvním třem uživatelům se to bude líbit. A to je přesně ten moment, kdy se projekt stává těžkým, protože dodání dema neznamená dodání nástroje, na který se firma může spolehnout. Rozdíl mezi „funguje na vstupech, které jsem vyzkoušel“ a „funguje na vstupech, které na něj hodí celá firma“ je obrovský a samotný model ho nijak nepřeklenuje. K jejímu překlenutí slouží projektové řízení umělé inteligence.

Obchodní tým, který vytváří agenty AI, se musí naučit řídit IT projekty.

Když tým, který není z IT, začne vytvářet software, a agent je software, zdědí všechny problémy, které se inženýrské týmy učily řešit padesát let. Požadavky je třeba zapsat. Je třeba navrhnout architekturu. Kód, výzvy nebo definice nástrojů musí být někde sdílené. Musí existovat testy. Změny je třeba před spuštěním zkontrolovat. Přeskočením kterékoli z těchto činností nezmizí, pouze se náklady posunou v čase. Dobrou zprávou je, že příručka již existuje. Disciplíny, díky nimž jsou IT projekty úspěšné, platí beze změny i v případě, že obchodní tým vytváří agenty. Jedinou novou složkou je hodnocení – specifická verze testování pro umělou inteligenci.

Začněte

Životní cyklus projektu agenta umělé inteligence

1. Úvodní analýza – jaký problém vlastně řešíme?

Každý agent, který stojí za to, začíná fází analýzy, která nemá s umělou inteligencí nic společného. Kdo to bude používat? Co dělají dnes, krok za krokem? Které z těchto kroků vlastně bolí? Jak vypadá „dobře udělaný“ – měřitelně? Než jsme vytvořili agenta pro přípravu nabídek, sepsali jsme přesnou manuální sekvenci, kterou obchodní tým dodržuje, označili jsme, které kroky se opakují a které vyžadují úsudek, a teprve potom jsme rozhodli, co by agent měl a neměl dělat. Analýza trvala déle než sestavení. Tento poměr je normální.

2. Plánování – rozsah, integrace, sdílená pobočka

Při plánování se rozhoduje o třech věcech: o vstupech a výstupech, o integracích, kterých se agent dotkne, a především o tom, kde bude práce probíhat. Pokud mají dva lidé přispívat, potřebují společnou definici „hlavního“. Může to být jeden dokument s kanonickými podněty a definicemi nástrojů, repozitář, složka s dovednostmi – na formátu záleží méně než na dohodě. Vyberte si ji hned první den. Rozhodněte, co agent nebude dělat, sepište to a držte se toho; scope creep je nejčastějším důvodem, proč se agenti stávají neudržovatelnými.

3. Vývoj – zdánlivě snadná část

Samotné sestavení je rychlé. To je ta past. Napíšete podněty, připojíte nástroje, spustíte pár příkladů a máte pocit, že je 80 % hotovo. Přitom máte hotovo spíše 30 %. Zbývajících 70 % je vše, co jste ještě neotestovali: podivné vstupy, dlouhé vstupy, vstupy v jiném jazyce, případy, kdy jeden nástroj vrátí prázdný výsledek, případy, kdy si to uživatel v polovině rozhovoru rozmyslí. Nic z toho není zevnitř sestavení vidět.

4. Testování – a následné opakované testování

V tomto bodě se agenti nejvíce liší od klasického softwaru a většina týmů zde šetří. Agent dnes testem projde a zítra může stejný test selhat, protože jste změnili jediný řádek ve výzvě nebo protože byl aktualizován základní model. Disciplínou, kterou potřebujete, je regresní vyhodnocení: uložená sada vstupů s očekávaným chováním, která se spouští automaticky nebo alespoň systematicky po každé změně. Bez toho se o regresích dozvíte, až když o ně uživatel zakopne.

5. Dodání a předání

Agent, který nebyl nikdy oficiálně dodán, je agentem, který se stává dědictvím v první den. Dodání znamená napsat dokumentaci pro uživatele, definovat, jak vypadá úspěch v produkci, a nastavit způsob, jak sledovat, zda je agent po třech měsících stále užitečný. To jsme se naučili pomalým způsobem – viz další část.

MVP, Agile a Scrum v projektech AI

MVP first – začněte s nejmenším užitečným prostředkem

Každý agent, kterého jsme vytvořili a který uspěl, začínal jako nejmenší použitelná verze sebe sama. Jeden úkol. Jeden vstup. Jeden výstup. Odolali jsme pokušení přidat druhý případ užití, dokud jsme neviděli, že ten první přežije kontakt se skutečnými uživateli. Agenti, kteří měli problémy, byli pravým opakem: od prvního dne ambiciózní, se třemi možnostmi, z nichž žádná nefungovala po celou dobu. Velkolepí agenti selhávají přesně ze stejných důvodů, proč selhávají velkolepé softwarové projekty; formální faktor nezmění matematiku. Pokud si z tohoto článku vezmete jen jedno pravidlo, pak toto: MVP pro agenta umělé inteligence je dostatečně malý na to, aby ho jeden člověk dokázal popsat ve třech větách a do konce dne spustit na reálném příkladu. Všechno potom je iterace.

Proč se Agile přirozeně hodí k agentům AI

Agenti jsou neobyčejně vhodní pro Agile práci, protože jsou neobyčejně nepředvídatelní. Agenta nemůžete předem plně specifikovat stejně jako formulář pro platby nebo zprávy. Vytvoříte malou verzi, sledujete, jak funguje v reálném světě, vidíte, kde selhává, a opravíte další věc. Snaha navrhnout dokonalého agenta na papíře před jeho sestavením je nejrychlejší způsob, jak sestavit špatného agenta. Iterace není u umělé inteligence preferencí projektového managementu; je to strukturální požadavek – stejný rytmus Plan, Do, Check, Act, který Deming popsal před desítkami let pro jakýkoli proces, který se musí neustále zlepšovat, jen aplikovaný na agenty, jejichž chování nemůžete plně předvídat.

Spouštění práce agentů ve sprintech Scrumu

Ke každému významnému agentovi přistupujeme jako k malému proudu práce ve stylu Scrum. Existuje zásobník schopností, které by agent mohl mít. Každý sprint vybere malý počet z nich. Demo sprintu je samotný agent, spuštěný na reálných vstupech od týmu, který ho bude používat. Pokud demo nepřesvědčí, práce pokračuje; kadence nutí ke skutečné konverzaci mezi tvůrcem a uživateli namísto několikaměsíčního tichého budování.

Chyby, kterých jsme se dopustili

Stavba před analýzou

Protože stavba je tak rychlá, je efektivní přejít rovnou k ní. Není tomu tak. Agenti, které jsme postavili bez jasné analýzy, nakonec technicky fungovali a přitom řešili špatný problém; tým, který je používal, to chvíli zdvořile řešil a pak se v tichosti vrátil k ruční práci. Odpoledne analýzy by ušetřilo týden budování.

Důvěřovat modelu, že na to přijde

To byla naše nejčastější chyba, kterou bylo nejtěžší se odnaučit. Předpokládali jsme, že když modelu zadáme úlohu srozumitelně, navrhne dobré řešení. Často tak neučinil – ne proto, že by model byl slabý, ale proto, že jsme sami neprovedli návrh. Model nemá přehled o kontextu vaší firmy, o existujících datech, o nepsaných konvencích, o systému kolem úkolu. Čím více z toho mu dáte, skutečnou analýzu, skutečnou architekturu, strukturu, kterou chcete, aby dodržoval, tím lepší je výsledek. Model je vynikající v provedení. Není to váš architekt.

Velký úspěch namísto začátku s nejlepším hráčem na trhu

Pokaždé, když jsme se snažili spustit plnohodnotného agenta hned první den, trvalo sestavení delší dobu, hůře se ladil a byl opuštěn častěji než malé verze, které jsme záměrně pěstovali. Big-bang se zdál být rychlejší. Nebyl.

Dvě osoby vyvíjející souběžně stejný prostředek

To byl moment Git. Dva lidé, stejný agent, různé nápady, různé větve v jejich hlavách, žádný společný „main“. O týden později dvě verze, které se nechtěly sladit. Nyní s každým smysluplným agentem zacházíme stejně jako vývojáři s kódem: jedna kanonická verze, explicitní model větvení, pokud na něm pracuje více než jeden člověk, a explicitní krok sloučení. Nebo, pokud se myšlenky skutečně rozcházejí, záměrné rozhodnutí rozdělit je na dva samostatné agenty, místo aby se předstíralo, že jsou stále jedním.

Žádná počáteční dokumentace – uživatelé nevěděli, co agent dělá

První interní uživatelé našich dovedností kladli stále stejné otázky: co to vlastně dělá, co musím zadat, jak vypadá výstup, kdy to mám použít oproti předchozí verzi. Mysleli jsme si, že agent je srozumitelný sám o sobě. Nebyl. Nyní ke každému agentu při předání píšeme krátký popis směrem k uživateli – co dělá, čím ho mám krmit, co mám očekávat, co nedělá. Stojí to deset minut a zabrání to týdnům zmateného používání.

Začněte

Často kladené otázky o řízení projektů AI pro projektové vedoucí

Liší se řízení projektů AI od běžného řízení IT projektů?

Disciplíny jsou stejné – analýza, plánování, sestavení, testování, dodání, iterace. Rozdíly jsou uvnitř fází sestavení a testování: výstupy jsou nedeterministické, chování se může měnit, když se změní model nebo podněty, a „testování“ se stává „vyhodnocením na základě uložené sady případů“. Vše kolem těchto fází vypadá jako běžný IT projekt.

Potřebuji k řízení vývoje agenta AI nástroj pro řízení projektů?

Potřebujete místo, kde každý agent žije jako projekt: s plánem, aktuální verzí, vlastníkem a stavem dodání. Na tom, zda je tímto místem systém pro řízení projektů, wiki nebo struktura složek, nezáleží tolik jako na tom, že takové místo máte. Pro týmy, které provozují mnoho agentů paralelně, se skutečný systém PM rychle vyplatí.

Jak velký by měl být agent MVP?

Dostatečně malý na to, aby ho jeden člověk dokázal popsat ve třech větách a do konce dne ho spustit na reálném příkladu. Pokud to nedokážete, rozsah je příliš velký a MVP je něco užšího uvnitř.

Jak zabráníte dvěma lidem, aby paralelně vytvářeli stejného agenta?

Nezabráníte dvěma lidem, aby přispívali – jasně stanovíte, kde žije kanonická verze, kdo je vlastníkem sloučení a kdy by se odlišné nápady měly stát záměrným rozvětvením do dvou samostatných agentů. Poučení ze softwarového inženýrství platí jedna ku jedné: sdílená větev s dohodnutým procesem slučování.

Kdy se agent stává dědicem?

V okamžiku, kdy nikdo není zodpovědný za vyhodnocení, zda ještě pomáhá. Agent, kterého nikdo nekontroluje, tiše degraduje, svět kolem něj se mění, vstupy se vyvíjejí, základní model je nahrazen a jednoho dne je špatný a nikdo si toho nevšimne. Dědictví není stáří, je to stav zanedbání.

Závěr

Vzrušující část vytváření agentů AI, model, výzvy, okamžik, kdy ukázka poprvé funguje, je nejmenší část práce. Ty nevzrušující části jsou tím, co z dema udělá nástroj, na který se může spolehnout celá firma: jasná analýza, reálný plán, sdílená větev, regresní testy, dokumentace a iterační rytmus, který udržuje agenta užitečného ještě dlouho po odeslání první verze. Nic z toho není exotické. Je to přesně ta disciplína, díky které jsou IT projekty úspěšné už desítky let, aplikovaná bez rozmělnění na o něco novější druh softwaru. Týmy, které si tuto disciplínu osvojí včas, nakonec získají agenty, kterým věří. Týmy, které ji přeskočí, skončí u toho, že stejného agenta přestaví dvakrát. Přistupovat ke každému agentovi jako ke skutečnému projektu s plánem, který můžete stanovit, revidovat a vylepšovat, to je to, co v praxi znamená řízení projektů AI. To děláme v systému FlexiProject, kde každý agent dostane vlastní projektový záznam s jasně napsaným plánem činnosti; ať už si vyberete jakýkoli systém, přistupujte ke každému agentovi jako k projektu, ne jako k experimentu.

Dominik Wrzosek

General Manager at FlexiProject

Dominik je odborník na řízení projektů a absolvent Varšavské polytechniky. Řídí vývoj systému FlexiProject a převádí obchodní potřeby do praktických řešení podporujících projektové týmy. Má zkušenosti s implementací FlexiProject v organizacích různé velikosti a kombinuje technické znalosti s obchodním přístupem k efektivnímu plánování a realizaci projektů.