Przeprowadzenie retrospektywy dotyczącej współpracy w zakresie sztucznej inteligencji

W TeamRetro interesuje nas każdy cykl ciągłego doskonalenia realizowany przez zespół. Praca wspomagana sztuczną inteligencją to nowy obszar, nad którym zastanawialiśmy się w kontekście naszych retrospektyw; w niniejszym przewodniku przedstawiamy nasze dotychczasowe wnioski. Prosimy o zapoznanie się z nim, dostosowanie go do własnych potrzeb i wdrożenie w ramach dowolnego narzędzia lub procedury, z których Państwo już korzystają.

Część 1: przewodnik

Dlaczego należy to uwzględnić podczas uroczystości drużynowej

W tym miesiącu gdzieś w Państwa zespole asystent oparty na sztucznej inteligencji poświęcił czterdzieści minut na analizę „uszkodzonej” kampanii reklamowej, która została celowo wstrzymana, ponieważ w briefie nie zawarto takiej instrukcji. Osoba prowadząca sesję skorygowała ten błąd, wzruszyła ramionami i zajęła się czymś innym. Jeśli czterech współpracowników natrafiło na różne wersje tej samej nieścisłości, oznacza to wiele godzin niepotrzebnie straconego czasu miesięcznie, o czym nikt nie wie, ponieważ każdy z nich samodzielnie zajął się tą sprawą.

Taki jest właśnie schemat problemów związanych z sesjami AI: mają one charakter przewlekły i są nieznaczne, więc nigdy nie powodują przeprowadzenia analizy po fakcie, a ponadto są ulotne, więc zanikają wraz z zakończeniem sesji. Większość zespołów jest już w stanie je obserwować (około 90% z nich monitoruje ślady agentów), jednak znacznie mniej z nich przekłada to na wprowadzenie poprawek: jedynie około 37–52% systematycznie analizuje zebrane dane (LangChain, czerwiec 2026).

Istniejące cykle doskonalenia są skuteczne, a niniejsza praktyka opiera się na nich wszystkich: aktualizacje plików kontekstowych, systemy pamięci, procesy samodoskonalenia dostawców orazAGENTS.md analiza błędów na podstawie śladów (Husain & Shankar, FAQ dotyczące ocen). Nawet dostawcy sięgają po termin „retro”: w wytycznych OpenAI dotyczących Codexu czytamy: „gdy Codex popełni ten sam błąd dwukrotnie, należy poprosić go o przeprowadzenie retrospektywy i zaktualizować plik AGENTS.md” (najlepsze praktyki). Jednak niemal wszystkie te pętle mają charakter indywidualny: jedna osoba i jej agent lub jedna platforma i jej flota. Warstwa zespołowa wnosi element agregacji: tarcie, które w ujęciu indywidualnym to pięć minut, nad którymi wzrusza się ramionami, staje się znaczącym kosztem dla zespołu dopiero w ujęciu zbiorczym, a podjęcie odpowiednich działań (przepisanie wspólnego szablonu, zmiana procesu przyjmowania danych, zakup narzędzia) wymaga limitu decyzyjnego, którego żadna osoba nie posiada. Koncepcja „Feedback Flywheel” autorstwa Rahula Garga wskazuje konkretne miejsce: „punkt porządku obrad w ramach istniejącej retrospektywy sprintu: co sprawdziło się w zakresie sztucznej inteligencji w tym sprincie?” (martinfowler.com), a niniejszy przewodnik stanowi jeden ze sposobów przeprowadzenia tego zadania.

Na wstępie jedno szczere przyznanie: potrzebna jest tu cykliczna, obiektywna i oparta na faktach sesja, w której uczestniczą osoby odpowiedzialne za wprowadzanie poprawek. Dla większości zespołów jest to retro, ale równie dobrze może to być spotkanie poświęcone planowaniu sprintu, comiesięczny przegląd operacyjny lub przegląd wyników zespołu ds. mediów. Retro lub Państwa istniejąca ceremonia o podobnym charakterze.

Warto wiedzieć jako moderator: Scrum.org podchodzi do tej samej kwestii od strony wskaźników; ich przewodnik dotyczący prowadzenia retrospektywy sprintu, gdy połowa zespołu składa się z agentów AI przedstawia to wydarzenie jako opartą na danych analizę wydajności agentów (przeróbki poleceń, wskaźniki odchyleń, zużycie tokenów). Niniejszy przewodnik przyjmuje podejście uzupełniające: skupia się na podstawowych przyczynach i rozwiązaniach w ramach całej współpracy, przy czym agenci przedstawiają własną relację z pracy, przesyłaną za pośrednictwem serwera TeamRetro MCP, jeśli korzystają Państwo z TeamRetro. Zespoły dysponujące dużą flotą agentów mogą chcieć wykorzystać elementy obu podejść.

Jak przebiega cały proces od początku do końca

1. Rejestracja wyników, na sesję. Pod koniec każdej istotnej sesji wspieranej przez sztuczną inteligencję agent sporządza krótki, uporządkowany wpis: co poszło dobrze, co się przedłużało (każda pozycja opatrzona jest przyczyną źródłową i proponowanym rozwiązaniem), jakie były jego przypuszczenia oraz jakie jest jedno rozwiązanie o największym potencjale oddziaływania. Jeden plik na każdy wpis w wspólnym dzienniku.
2. Podsumowanie po około 5 wpisach. Przed uroczystością agent sporządza jednostronicowe podsumowanie dziennika: powtarzające się tematy uszeregowane według częstotliwości i kosztów, rozkład przyczyn źródłowych, sprawdzenie, czy wdrożono wcześniejsze rozwiązania, oraz trzy najważniejsze zalecane działania.
3. Proszę podjąć decyzję w ciągu 15 minut. Zadanie to stanowi jeden z punktów porządku obrad podczas obecnego spotkania podsumowującego, a nie osobne spotkanie. Zespół dokonuje selekcji: decyduje, czy dane utrudnienie należy utrzymać, czy wyeliminować, ustala, gdzie powinno zostać wprowadzone każde rozwiązanie, oraz wyznacza osoby odpowiedzialne za najważniejsze działania. W sprawozdaniu z następnego cyklu podaje się, czy dane utrudnienie faktycznie uległo zmniejszeniu.

Jeśli chcą Państwo szybko rozpocząć pracę, etapy pozyskiwania i syntezy zostały zaimplementowane jako umiejętności agentów typu open source w naszym repozytorium TeamRetro-skills.

Agent przekazuje dane bez ograniczeń: agent, który potrzebuje uprawnień do rejestrowania problemów zaniża dane, a korekty wprowadzane przez ludzi po fakcie stanowią sygnał dodatkowy, a nie punkt kontrolny, na który czeka pętla. Decyzja należy do zespołu i nie jest to kwestia grzeczności: poprawki są uwzględniane w budżetach, dokumentach, procesach i narzędziach, za które ludzie są odpowiedzialni i przed którymi odpowiadają. Agent przedstawia dowody i projekty; decyzję podejmuje zgromadzenie.

Jak wygląda dobry wpis

Oto przykład z życia wzięty, celowo nie związany z programowaniem:

# 2026-07-16: Monthly ads account review

**Session size:** ~25 turns, 1 deliverable
**Outcome:** shipped

## Went well
- Exec summary shipped in one pass; the account structure doc from last month held up

## Friction
- **[missing-context]** The brief didn't say the French campaigns were deliberately
  paused for Q3; ~40 min (est.) auditing a "broken" campaign that was fine.
  → Fix (altitude: process): add campaign-status flags to the monthly brief template

## Guesses made
- Assumed the target CPA unchanged from June, unverified

## Do this first
Campaign-status flags in the brief template. Kills the largest single time sink this month.

Proszę zwrócić uwagę na dyscyplinę. Każdy element powodujący utrudnienia zawiera informację o momencie wystąpienia i koszcie (szacunki przybliżone oznaczone symbolem (est.)), posiada dokładnie jedną etykietę przyczyny źródłowej wybraną z niewielkiego, stałego zestawu terminów (etykiety takie jak ambiguous-instruction, missing-context, missing-documentation, missing-access-or-tool, agent-error, lub work-material-friction, gdzie sam element stanowił przeszkodę: zagmatwana struktura kampanii, przestarzały arkusz kalkulacyjny, moduł, którego nikt nie chce dotykać – zawsze z podaniem konkretnego elementu), a także kończy się rozwiązaniem o rozmiarze zgłoszenia, które określa jego poziom: czy to rozwiązanie powinno znaleźć się w prywatnej notatce, procedurze, środowisku, dokumentacji, samym materiale roboczym, procesie, czy też na wyższym szczeblu u dostawcy? Stałe etykiety pozwalają na porównywanie wpisów między różnymi osobami i sesjami; stwierdzenia typu „dokumentacja była niejasna” nie da się zagregować, ale osiem missing-documentationwpisów już tak. Niejasność jest przyczyną niepowodzenia; „nic godnego uwagi” jest prawidłowym wpisem.

Dobry zestawienie mieści się na jednej stronie: zawiera tematy o wysokiej częstotliwości występowania („4 z 9 sesji”) wraz z przykładami z konkretnych dat, jasne stwierdzenie, która grupa przyczyn źródłowych dominuje (odprawy, dokumentacja, materiały robocze, oprzyrządowanie lub pracownicy; na tym właśnie powinien skupić się zespół), weryfikacja wdrożenia wcześniejszych sugestii oraz trzy działania, do których można przypisać konkretnych wykonawców. Stanowi on punkt wyjścia do dyskusji; nie zastępuje jej.

Zakres: jeden plik dziennika na każdy zakres przeglądu

Proszę prowadzić jeden dziennik dla każdego zakresu przeglądu: obszaru, w którym będą wprowadzane poprawki. W przypadku prac programistycznych jest to zazwyczaj repozytorium, ponieważ tam znajdują się dokumentacja, konfiguracja i konwencje. W przypadku prac niezwiązanych z kodem jest to konto reklamowe, skrzynka odbiorcza działu wsparcia lub obszar współpracy z klientem; dziennik znajduje się w katalogu dokumentów danego obszaru roboczego. Wpis umieszczony poza tym zakresem to taki, którego ostateczny właściciel poprawki nigdy nie odnajdzie. Schemat pozostaje identyczny wszędzie; to właśnie schemat, a nie miejsce przechowywania, umożliwia agregowanie wpisów.

Zasady dotyczące „never-log”

Wpisy są zatwierdzane, udostępniane i przetrwają swój kontekst, dlatego niektórych treści nigdy nie należy w nich umieszczać: tajemnic, danych uwierzytelniających ani kluczy w jakiejkolwiek formie; danych klientów lub danych osobowych; nieopublikowanych wyników finansowych; a także – co najważniejsze z punktu widzenia kultury retro – imion, ról lub czegokolwiek, co pozwala zidentyfikować daną osobę. Opisz lukę i związane z nią koszty, nigdy nie wskazuj, kto ją spowodował: „brief pozostawił odbiorców bez jasności”, a nie „brief X”. Elementy tarcia dotyczą krytyki danych wejściowych i systemów, a nie osób. Jeśli nie da się opisać tarcia w zakresie bez ujawnienia wrażliwego kontekstu, należy zachować te wpisy jako prywatne i udostępniać wyłącznie zbiorczy brief.

Część 2: szablon „AI Collaboration Retro”

Format gotowy do użycia: pięć pytań, opartych na schemacie wejściowym, które można wykorzystać w programie TeamRetro lub na dowolnej tablicy:

Kolumna	Podpowiedź	Jednowierszowy dowcip
Wszystko poszło dobrze	W jakim zakresie praca wspomagana przez sztuczną inteligencję przyczyniła się w tym cyklu do przyspieszenia lub poprawy wyników?	Wyłącznie zwycięstwa poparte dowodami: należy chronić i powtarzać to, co ma wartość, a nie nadużywać pochwał.
Tarcie i jego przyczyny	Gdzie wystąpiło spowolnienie i jaka była jego główna przyczyna?	Na każdej karcie podano nazwę zdarzenia, przybliżony koszt oraz jedno określenie z ustalonego słownika zespołu.
Hipotezy, które pozostawiamy bez zmian	Jakie założenia przyjął agent (lub my) bez wystarczających informacji?	Ukryte tarcia, które jak dotąd nie spowodowały żadnych szkód; proszę oznaczyć wszystko, co nadal nie zostało zweryfikowane.
Zostawić czy zabić	Które z tych utrudnień wybraliśmy celowo?	Etapy weryfikacji i procedury zatwierdzania mogą stanowić celowe punkty kontrolne (podsumowanie wystąpienia Ronachera podczas konferencji AIE Europe); usunięcie jednego z nich jest decyzją zespołu.
Proszę wykonać to w pierwszej kolejności	Spośród wszystkich wymienionych tutaj opcji, która z nich przynosi największe korzyści i na jakiej wysokości?	Maksymalnie trzy pozycje, z których każda ma swojego właściciela oraz poziom, na którym się znajduje: dokumenty, środowisko, proces, materiał lub etap wstępny.

Część 3: Karty z podpowiedziami dla moderatora

Pytania, które należy zadać, gdy zespół przedstawia podczas ceremonii brief dotyczący stylu retro z wykorzystaniem sztucznej inteligencji. Po jednym na kartę; proszę korzystać z tych, które są potrzebne w trakcie rozmowy.

1. „Z której sesji pochodzi ta transakcja i ile kosztowała?” Zgłoszenia dotyczące wzorców wymagają dowodów z datą; transakcji bez podania daty i kwoty nie można poddać wstępnej ocenie.
2. „Czy to utrudnienie jest punktem kontrolnym, który sami wybraliśmy?” Najpierw zasada „zachować czy wyeliminować”: pewne utrudnienia pełnią rolę sterującą (podsumowanie wystąpienia Ronachera podczas konferencji AIE Europe), a brak utrudnień nie oznacza braku kosztów; firma Thoughtworks ostrzega przed narastającym długiem poznawczym (komunikat).
3. „Zaproponowaliśmy to rozwiązanie już ostatnio. Co stanęło temu na przeszkodzie?” Niezrealizowane, powtarzające się sugestie stanowią element o największym znaczeniu w każdym briefie; bez tego pytania cała ta dynamika sprowadza się do czystej pozory.
4. „Każdemu z Państwa zajęło to dziesięć minut – ile kosztuje to zespół miesięcznie?” Agregacja stanowi główną zaletę zespołu; proszę o to pytać za każdym razem, gdy ktoś lekceważy jakąś kartę.
5. „Czy to poprawka powinna znaleźć się w dokumentacji, w środowisku czy w wytycznych dotyczących pracy?” Kwestia odpowiedniego poziomu. Jeśli cel zostanie niedoszacowany, problem powróci; jeśli zostanie przeszacowany, spowoduje to nadmierne rozbudowanie niewłaściwego elementu.
6. „Kto jest właścicielem przedmiotu, w którym trafi ta rzecz?” Czynność bez właściciela to pozycja z listy życzeń. Jeśli właściciela nie ma w pomieszczeniu, to również stanowi znalezisko.
7. „Zanim uznamy to za błąd agenta, należy zadać pytanie: czy dane wejściowe były odpowiednie?” – to jestagent-error etykieta resztkowa, a nie domyślna; domyślnym podejściem, które należy odrzucić, jest obwinianie agenta, gdy problemem był zestaw testowy lub brief, dlatego należy raczej naprawić zestaw testowy (Osmani, Agent Harness Engineering).
8. „Która grupa przyczyn źródłowych dominuje w rozkładzie i czy to właśnie na nią skupiamy naszą uwagę?” Dane liczbowe zawarte w raporcie wskazują, czy problem dotyczy odpraw, dokumentacji, materiałów roboczych, oprzyrządowania czy konfiguracji agenta. Należy kierować swoją uwagę zgodnie z danymi.
9. „Czy to zauważył człowiek, czy też agent?” Korekta dokonywana przez człowieka nadal odgrywa dominującą rolę: jedno z badań produkcyjnych wykazało, że około 70% cichych błędów zostało najpierw wykrytych przez osobę, która zauważyła, że coś jest nie tak (arXiv 2606.14589). Należy traktować te wykrycia jako dowody najwyższej rangi, a nie jako zakłócenia.
10. „Czy chodzi o zakres naszych zadań, czy o zakres innego zespołu?” Poprawki trafiają do zakresu, za który odpowiada dany zespół; kartę dotyczącą wspólnego szablonu lub procesu innego zespołu należy przekierować, a nie włączać do własnego zakresu.
11. „Czy to dyskusja, czy zgłoszenie?” Oczywiste poprawki należy wprowadzać bezpośrednio do systemu śledzenia; proszę poświęcić piętnaście minut wyłącznie na kwestie sporne: decyzje o utrzymaniu lub odrzuceniu, spory dotyczące wysokości, priorytety.
12. „Czy ta decyzja wykracza poza kompetencje któregokolwiek z nas?” Zakup narzędzia, zmiana sposobu pozyskiwania danych, eskalacja sprawy do dostawcy: zrewidowana lista priorytetów często wykracza poza zakres indywidualnych uprawnień decyzyjnych. Właśnie dlatego ta kwestia w ogóle znalazła się w porządku obrad.

---

Następny rozdział: Zacznij w dziesięć minut. Zainstalujcie narzędzia i przeprowadźcie swoje pierwsze sesje, lub przenieście powyższy szablon na tablicę, z której już korzysta Państwa zespół. Część przewodnika po retrospektywach agentów AI.