Zarządzanie projektami AI: dlaczego tworzenie agentów to zwykły projekt IT?

Nie jesteśmy działem IT. Jesteśmy zespołem biznesowym firmy SaaS i kilka miesięcy po tym, jak generatywne AI stało się na tyle praktyczne, że dało się z niego coś realnie zbudować, okazało się, że mamy agentów cicho pracujących w tle naszej codzienności: przygotowujących oferty dla klientów, uzupełniających dane w umowach, wyciągających raporty z Search Console, pomagających zarządzać stroną internetową. Sama budowa tych agentów okazała się prostą częścią. Nie spodziewaliśmy się tylko, że zarządzanie projektami AI, traktowanie każdego agenta jak prawdziwego projektu, z planem, wspólną gałęzią, testami i etapem wdrożenia, będzie ważyć tyle samo co cokolwiek, co dotąd wypuściliśmy z działu inżynierii. To historia tego, czego się nauczyliśmy, w kolejności, w jakiej się tego uczyliśmy.

W tym artykule dowiesz się:

Dlaczego tworzenie agentów AI to w praktyce zwykły projekt IT
Jakie pięć faz powinien przechodzić każdy projekt agenta
Jak agile, Scrum i cykl Deminga pasują do pracy nad agentami
Jakie błędy popełniliśmy po drodze, i jak ich uniknąć
Jak nie dopuścić, żeby dwie osoby budowały tego samego agenta równolegle

Jak zespół biznesowy zaczął tworzyć agentów AI

Tworzymy agentów, choć nie jesteśmy IT

Ciekawym zwrotem ostatnich dwóch lat jest to, że nie potrzeba już zespołu programistów, żeby wypuścić działające AI. Osoba z biznesu, która potrafi opisać, co ma się wydarzyć i podać kilka przykładów wejść, zbuduje agenta, który robi realną pracę. Nie planowaliśmy zostać twórcami agentów. Po prostu cały czas trafialiśmy na zadania, gdzie odpowiedź była oczywista: to mógłby zrobić agent, więc zaczęliśmy budować. Pierwszy zajął popołudnie. Drugi zajął popołudnie. Potem zaczęły się problemy: nie z budowaniem, ale z całą resztą wokół.

Agenci, których stworzyliśmy

Lista rosła szybciej, niż się spodziewaliśmy. Mamy agenta, który automatycznie uzupełnia dane klienta w naszych standardowych umowach. Agenta, który przygotowuje pierwszą wersję oferty na podstawie podsumowania rozmowy handlowej. Integratora, który ściąga listę projektów klienta z Excela prosto do jego środowiska FlexiProject. Asystenta, który pomaga nam zarządzać częściami strony internetowej. Agenta, który pobiera dane z Google Search Console dla naszej domeny i przerabia je na czytelne tygodniowe podsumowanie. I kilkadziesiąt mniejszych: jednoosobowych pomocników, których ktoś zbudował dla siebie, dopracował i z czasem podzielił się z zespołem.

Równoległe rozwijanie jednego agenta

Trudności nie pojawiły się przy agentach, których budowaliśmy raz i o nich zapominaliśmy. Pojawiły się przy tych, którzy zaczynali naprawdę znaczyć. Dwie osoby brały użytecznego agenta, każda miała inny pomysł na ulepszenie, i każda zaczynała rozwijać go niezależnie. Tydzień później mieliśmy dwie wersje: różne prompty, różne narzędzia wpięte, różne przypadki brzegowe wyłapane, i żadnego czystego sposobu, żeby je scalić. To dokładnie ten sam problem, który programiści rozwiązali dekady temu Gitem: nie da się mieć dwóch osób pracujących na wspólnym punkcie startowym i rozwijających go w różnych kierunkach bez modelu gałęzi. Po prostu nie pomyśleliśmy, że nam to jest potrzebne. Agenci byli „łatwi”. Słowo „zarządzanie projektami AI” jeszcze nie weszło do naszego słownika.

Dlaczego tworzenie agentów AI to tak naprawdę projekt IT?

Tworzenie agentów jest banalnie proste

Pierwsza lekcja jest najbardziej niewygodna: zbudowanie agenta naprawdę jest proste. Każdy, kto to czyta, mógłby teraz otworzyć model i mieć coś działającego w ciągu godziny. Demo wygląda magicznie. Pierwsi trzej użytkownicy będą zachwyceni. I to dokładnie ten moment, w którym projekt staje się trudny, bo wypuszczenie dema to nie wypuszczenie narzędzia, na którym może polegać cała firma. Przepaść między „działa na wejściach, które wypróbowałem” a „działa na wejściach, które rzuci w niego cała firma” jest ogromna i model sam z siebie nie robi nic, żeby ją zasypać. Zasypanie tej przepaści to dokładnie jest zarządzanie projektami AI.

Biznes tworząc agentów AI musi nauczyć się zarządzać projektami IT

Kiedy zespół spoza IT zaczyna budować oprogramowanie, a agent jest oprogramowaniem, dziedziczy każdy problem, z którym zespoły inżynierskie radzą sobie od pięćdziesięciu lat. Wymagania trzeba spisać. Architekturę trzeba zaprojektować. Kod, albo prompty, albo definicje narzędzi, musi gdzieś żyć wspólnie. Testy muszą istnieć. Zmiany trzeba zrecenzować, zanim trafią na produkcję. Pominięcie któregokolwiek z tych kroków nie sprawia, że problem znika; przesuwa tylko jego koszt w czasie. Dobra wiadomość: playbook już istnieje. Te same dyscypliny, które robią z projektów IT sukcesy, stosują się bez zmiany, gdy agentów buduje zespół biznesowy. Jedyny nowy składnik to ewaluacja: AI-owy odpowiednik testowania.

Rozpocznij

Cykl życia projektu agenta AI

1. Analiza wstępna – co tak naprawdę rozwiązujemy?

Każdy agent wart zbudowania zaczyna się od fazy analizy, która nie ma nic wspólnego z AI. Kto będzie tego używać? Co ta osoba robi dziś, krok po kroku? Który z tych kroków rzeczywiście boli? Jak wygląda „dobrze zrobione”, mierzalnie? Zanim zbudowaliśmy agenta do ofert, spisaliśmy dokładnie ręczną sekwencję handlowca, zaznaczyliśmy, które kroki są powtarzalne, a które wymagają oceny, i dopiero wtedy zdecydowaliśmy, co agent ma robić, a czego nie. Analiza zajęła więcej niż budowa. To normalna proporcja.

2. Planowanie – zakres, integracje, wspólna gałąź

W planowaniu decydujesz trzy rzeczy: wejścia i wyjścia, integracje, których agent dotknie, i, najważniejsze, gdzie żyje praca. Jeśli dwie osoby mają współtworzyć, potrzebują wspólnej definicji „main”. To może być jeden dokument z kanonicznymi promptami i definicjami narzędzi, repozytorium, folder ze skillem, format znaczy mniej niż samo porozumienie. Wybierz format pierwszego dnia. Zdecyduj, czego agent ma nie robić, spisz to i tego się trzymaj; rozjazd zakresu to najczęstsza przyczyna, dla której agent przestaje nadawać się do utrzymania.

3. Development – pozornie najłatwiejszy etap

Sama budowa jest szybka. To pułapka. Napiszesz prompty, podepniesz narzędzia, puścisz kilka przykładów i poczujesz, że jesteś na 80%. Jesteś bliżej 30%. Pozostałe 70% to wszystko, czego jeszcze nie przetestowałeś: dziwne wejścia, długie wejścia, wejścia w innym języku, przypadki, gdy jedno z narzędzi zwraca pustkę, przypadki, gdy użytkownik zmienia zdanie w połowie rozmowy. Nic z tego nie widać od środka budowy.

4. Testy, i jeszcze raz testy

Tu agenty najbardziej różnią się od klasycznego oprogramowania i tu większość zespołów idzie na skróty. Agent przechodzi test dziś i może oblać ten sam test jutro, bo zmieniłeś jedno zdanie w promptcie albo bo podstawowy model został zaktualizowany. Dyscyplina, której potrzebujesz, to ewaluacja regresyjna: zapisany zestaw wejść z oczekiwanymi zachowaniami, uruchamiany automatycznie, albo przynajmniej systematycznie, po każdej zmianie. Bez tego o regresji dowiadujesz się dopiero, gdy potknie się o nią użytkownik.

5. Wdrożenie i przekazanie

Agent, który nie został oficjalnie wydany, to agent, który staje się legacy w dniu pierwszym. Wdrożenie znaczy: spisanie dokumentacji dla użytkownika, zdefiniowanie, jak wygląda sukces w produkcji, i ustawienie sposobu monitorowania, czy agent dalej jest przydatny po trzech miesiącach. Tej lekcji uczyliśmy się powoli, szczegóły niżej.

Agile, Scrum i cykl Deminga w projektach AI

Dlaczego agile naturalnie pasuje do agentów AI

Agenci wyjątkowo dobrze nadają się do pracy zwinnej, bo są wyjątkowo nieprzewidywalni. Nie da się zaprojektować agenta z góry tak, jak projektuje się formularz płatności czy raport. Robisz małą wersję, patrzysz, jak działa w rzeczywistym świecie, widzisz, gdzie pęka, i naprawiasz kolejną rzecz. Próba zaprojektowania idealnego agenta na papierze przed zbudowaniem to najszybsza droga do zbudowania nie tego agenta. Iteracja to nie preferencja zarządcza dla AI, to wymóg strukturalny.

Praca nad agentem w sprintach Scrum

Każdego znaczącego agenta traktujemy jak mały strumień pracy w stylu Scrum. Jest backlog możliwości, które agent mógłby mieć. Każdy sprint wybiera mały zestaw. Demo sprintu to sam agent, uruchomiony na rzeczywistych danych zespołu, który będzie z niego korzystać. Jeśli demo nie przekonuje, praca trwa dalej; sam rytm wymusza prawdziwą rozmowę między twórcą a użytkownikami, zamiast wielomiesięcznej cichej budowy.

PDCA – cykl Deminga jako rytm pracy z agentem

Cykl Deminga, Plan, Do, Check, Act, to operacyjny puls każdego agenta, który długoterminowo zostaje przydatny. Plan: zdecyduj, jaka jest następna poprawka. Do: zbuduj ją. Check: sprawdź, czy faktycznie pomaga, na realnych przypadkach. Act: zaadoptuj zmianę albo ją wycofaj. Bez wyraźnego Check i Act zostają ci tylko Plan i Do, a agent przestaje się rozwijać w dniu, w którym przestajesz nad nim pracować. PDCA daje agentowi puls.

Najpierw MVP, dopiero potem rozbudowa

Każdy agent, którego zbudowaliśmy i który się udał, zaczął jako najmniejsza użyteczna wersja samego siebie. Jedno zadanie. Jedno wejście. Jedno wyjście. Opieraliśmy się pokusie dorzucenia drugiego przypadku użycia, dopóki pierwszy nie przeżył kontaktu z prawdziwymi użytkownikami. Agenci, którzy się męczyli, byli dokładnie odwrotni: ambitni od pierwszego dnia, z trzema funkcjami, z których żadna nie działała do końca. Wielcy agenci zawodzą z dokładnie tego samego powodu, dla którego zawodzą wielkie projekty programistyczne; forma nie zmienia matematyki.

Błędy, które popełniliśmy

Budowanie przed analizą

Ponieważ budowanie jest tak szybkie, wydaje się efektywne, żeby przejść od razu do niego. Nie jest. Agenci, których budowaliśmy bez czystej analizy, technicznie działali, rozwiązując nie ten problem; zespół, który ich używał, znosił to przez chwilę grzecznie, a potem po cichu wracał do robienia tego samego ręcznie. Popołudnie analizy oszczędziłoby tydzień budowania.

Zaufanie, że model sam wymyśli rozwiązanie

To był nasz najbardziej powtarzalny błąd i najtrudniejszy do oduczenia. Zakładaliśmy, że jeśli damy modelowi zadanie zwykłym językiem, on sam zaprojektuje dobre rozwiązanie. Często nie projektował, nie dlatego, że model był słaby, ale dlatego, że to my nie odrobiliśmy pracy projektowej. Model nie widzi kontekstu twojej firmy, twoich istniejących danych, niespisanych konwencji, otoczenia wokół zadania. Im więcej z tego mu dasz, realna analiza, realna architektura, struktura, której ma się trzymać, tym lepszy wynik dostaniesz. Model jest świetny w wykonaniu. Nie jest twoim architektem.

Od razu duży agent zamiast MVP

Za każdym razem, gdy próbowaliśmy wystartować z agentem w pełnej wersji pierwszego dnia, efekt powstawał dłużej, trudniej go było debugować i częściej był porzucany niż małe wersje, które rozwijaliśmy świadomie. Wielki agent wydawał się szybszą drogą. Nie był.

Dwóch ludzi rozwijających tego samego agenta równolegle

To był ten moment z Gitem. Dwie osoby, ten sam agent, różne pomysły, różne gałęzie w głowach, brak wspólnego „main”. Tydzień później dwie wersje, które nie chciały się pogodzić. Dziś każdego znaczącego agenta traktujemy tak, jak programiści traktują kod: jedna kanoniczna wersja, jasny model gałęzi, gdy pracuje nad nim więcej niż jedna osoba, i wyraźny krok scalania. Albo, jeśli pomysły faktycznie się rozjeżdżają, świadoma decyzja, żeby podzielić to na dwóch osobnych agentów, zamiast udawać, że to wciąż jeden.

Brak dokumentacji dla użytkowników na starcie

Pierwsi wewnętrzni użytkownicy naszych skilli ciągle zadawali te same pytania: co to dokładnie robi, co mam podać na wejściu, jak wygląda wynik, kiedy używać tego, a kiedy poprzedniej wersji. Myśleliśmy, że agent jest oczywisty. Nie był. Dziś dla każdego agenta przy przekazaniu spisujemy krótki opis dla użytkownika: co robi, czym go karmić, czego się spodziewać, czego nie robi. Kosztuje dziesięć minut i oszczędza tygodnie zagubionego użytkowania.

Rozpocznij

Najczęstsze pytania o zarządzanie projektami AI

Czy zarządzanie projektami AI różni się od zwykłego zarządzania projektami IT?

Dyscypliny są te same: analiza, planowanie, budowa, testy, wdrożenie, iteracja. Różnice siedzą wewnątrz fazy budowy i testów: wyjścia są niedeterministyczne, zachowanie może dryfować, gdy zmienia się model albo prompty, a „testowanie” staje się „ewaluacją na zapisanym zestawie przypadków”. Wszystko wokół tych faz wygląda jak zwykły projekt IT.

Czy potrzebuję narzędzia PM do prowadzenia projektów AI?

Potrzebujesz miejsca, w którym każdy agent żyje jako projekt: z planem, aktualną wersją, właścicielem i stanem wdrożenia. Czy tym miejscem będzie system PM, wiki, czy struktura folderów, znaczy mniej niż samo posiadanie tego miejsca. Dla zespołów prowadzących wielu agentów równolegle prawdziwy system PM zwraca się szybko.

Jak duży powinien być MVP agenta?

Na tyle mały, żeby jedna osoba potrafiła go opisać w trzech zdaniach i puścić end-to-end na realnym przykładzie do końca dnia. Jeśli się nie da, zakres jest za duży, a MVP to coś węższego wewnątrz.

Jak nie dopuścić, żeby dwie osoby budowały tego samego agenta równolegle?

Nie powstrzymujesz dwóch osób od współpracy, sprawiasz, że jasno wiadomo, gdzie żyje wersja kanoniczna, kto odpowiada za scalanie i kiedy rozjeżdżające się pomysły powinny stać się świadomym podziałem na dwóch osobnych agentów. Lekcja z inżynierii oprogramowania ma się jeden do jednego: wspólna gałąź i uzgodniony proces scalania.

Kiedy agent staje się legacy?

W chwili, gdy nikt nie odpowiada za sprawdzanie, czy dalej pomaga. Agent, którego nikt nie pilnuje, po cichu się rozjeżdża: świat wokół się zmienia, wejścia ewoluują, podstawowy model jest podmieniany, i pewnego dnia odpowiada źle, a nikt tego nie wyłapuje. Legacy to nie wiek, to stan zaniedbania.

Co zamienia demo AI w realne narzędzie biznesowe?

Ekscytująca część budowania agentów AI: model, prompty, moment, w którym demo działa po raz pierwszy, to najmniejszy ułamek pracy. Nudne części to to, co zmienia demo w narzędzie, na którym może polegać cała firma: czysta analiza, realny plan, wspólna gałąź, testy regresyjne, dokumentacja i rytm iteracji, który utrzymuje agenta przydatnym długo po wypuszczeniu pierwszej wersji. Nic z tego nie jest egzotyczne. To dokładnie ta dyscyplina, która od dekad sprawia, że projekty IT się udają, zastosowana bez rozcieńczenia do nieco nowszego rodzaju oprogramowania. Zespoły, które przyjmują tę dyscyplinę wcześnie, kończą z agentami, którym ufają. Zespoły, które ją pomijają, kończą budując tego samego agenta dwa razy. Traktowanie każdego agenta jak prawdziwego projektu, z planem, który możesz rozpisać, regularnie do niego wracać i go ulepszać, to praktyczne znaczenie zarządzania projektami AI. Robimy to we FlexiProject, gdzie każdy agent ma swój rekord projektu z jasno spisanym planem działania; jakikolwiek system wybierzesz, traktuj każdego agenta jak projekt, a nie eksperyment.

Dominik Wrzosek

General Manager at FlexiProject

Dominik jest ekspertem w zarządzaniu projektami i absolwentem Politechniki Warszawskiej. Kieruje rozwojem systemu FlexiProject, przekładając potrzeby biznesowe na praktyczne rozwiązania wspierające zespoły projektowe. Zdobywa doświadczenie we wdrożeniach w organizacjach o różnej skali, łącząc techniczne zaplecze z biznesowym spojrzeniem na efektywne planowanie i realizację projektów.