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 zastanawiamy się w kontekście naszych retrospektyw; w niniejszym przewodniku przedstawiamy nasze dotychczasowe wnioski. Zachęcamy do skorzystania z niego, dostosowania go do własnych potrzeb i wdrożenia w ramach dowolnego narzędzia lub procedury, z których już Państwo korzystają.

Część 1 — przewodnik

Dlaczego ta kwestia powinna zostać uwzględniona podczas uroczystości zespołowej

W tym miesiącu gdzieś w Państwa zespole asystent oparty na sztucznej inteligencji poświęcił czterdzieści minut na analizę „nieprawidłowo działającej” 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 na różne wersje tej samej nieścisłości, oznacza to wiele godzin niewidocznej straty czasu w ciągu miesiąca — a nikt o tym nie wie, ponieważ każda osoba radziła sobie z tym samodzielnie.

Tak właśnie wygląda sytuacja w przypadku problemów związanych z sesjami AI: są one przewlekłe i nieznaczne, więc nigdy nie powodują przeprowadzenia analizy po zdarzeniu, a ponadto mają charakter przejściowy, więc zanikają wraz z zakończeniem sesji. Większość zespołów jest już w stanie je monitorować (około 90% z nich wdraża śledzenie działania agentów), jednak znacznie mniej z nich przekłada te dane na konkretne rozwiązania: jedynie około 37–52% systematycznie analizuje zebrane dane (LangChain, czerwiec 2026 r.).

Istniejące cykle doskonalenia są skuteczne, a niniejsza praktyka opiera się na nich wszystkich:AGENTS.md aktualizacjach plików kontekstowych, systemach pamięci, procesach samodoskonalenia dostawców oraz analizie 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 cykle mają charakter indywidualny: jedna osoba i jej agent lub jedna platforma i jej flota. Warstwa zespołowa wnosi do tego agregację: tarcie, które dla każdej osoby to pięć minut, nad którymi wzrusza się ramionami, staje się głównym 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 pułapu decyzyjnego, którego żadna osoba z osobna nie posiada. Koncepcja „Feedback Flywheel” autorstwa Rahula Garga wskazuje konkretne miejsce na to zagadnienie: „punkt porządku obrad w ramach istniejącej retrospektywy sprintu: co sprawdziło się w zakresie sztucznej inteligencji podczas tego sprintu?” (martinfowler.com), a niniejszy przewodnik stanowi jeden ze sposobów przeprowadzenia tego zadania.

Na wstępie 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 spotkanie retro, ale równie dobrze może to być sesja planowania sprintu, comiesięczny przegląd operacyjny lub przegląd wyników zespołu ds. mediów. Spotkanie retro lub istniejąca już ceremonia o podobnym charakterze.

Warto wiedzieć jako moderator: serwis Scrum.org podchodzi do tej samej kwestii z perspektywy 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 promptów, 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 przekazują własne relacje z pracy, przesyłane 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ła procedura, od początku do końca

1. Rejestracja wyników z każdej sesji. 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. 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, weryfikacja, czy wdrożono wcześniejsze rozwiązania, oraz trzy najważniejsze zalecane działania.
3. Proszę podjąć decyzję w ciągu 15 minut. Omówienie to jeden z punktów porządku obrad podczas istniejącego spotkania podsumowującego, a nie osobne spotkanie. Zespół dokonuje selekcji: decyduje, czy dane utrudnienie należy utrzymać, czy wyeliminować, ustala, gdzie należy wprowadzić poszczególne poprawki, 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 danych i syntezy zostały zaimplementowane jako umiejętności agentów typu open source w naszym repozytorium TeamRetro-skills.

Agent przekazuje dane bez filtrowania: agent, który potrzebuje uprawnień do rejestrowania tarć 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 znajdują odzwierciedlenie w budżetach, dokumentach, procesach i narzędziach, za które ludzie są odpowiedzialni i przed którymi odpowiadają. Agent przedstawia dowody i propozycje; decyzję podejmuje zespół.

Jak wygląda dobry wpis

Oto przykład z życia wzięty, który celowo nie dotyczy programowania:

# 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ę określającą przyczynę źródłową, 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 samym źródłem utrudnienia był konkretny element: zagmatwana struktura kampanii, przestarzały arkusz kalkulacyjny, moduł, którego nikt nie chce dotykać — zawsze z podaniem nazwy konkretnego elementu), a kończy się rozwiązaniem o rozmiarze zgłoszenia, które określa jego poziom: czy to rozwiązanie należy umieścić w prywatnej notatce, procedurze, środowisku, dokumentacji, samym materiale roboczym, procesie, czy też na wyższym szczeblu u dostawcy? Stałe etykiety umożliwiają porównywanie wpisów między różnymi osobami i sesjami; stwierdzenia typu „dokumentacja była niejasna” nie da się zagregować, ale osiemmissing-documentation wpisów już tak. Niejasność jest formą niepowodzenia; „nic godnego uwagi” jest prawidłowym wpisem.

Dobry raport powinien mieścić się na jednej stronie: należy w nim uwzględnić najczęściej występujące zagadnienia („4 z 9 sesji”) wraz z przykładami z konkretnych dat, jasne stwierdzenie, która z grup przyczyn źródłowych dominuje (odprawy, dokumentacja, materiały robocze, narzędzia lub pracownicy; to właśnie na tym zespół powinien skupić swoją uwagę), weryfikacja wdrożenia wcześniejszych sugestii oraz trzy działania, do których można przypisać konkretnych wykonawców. Stanowi ono 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 jest tym, którego ostateczny właściciel poprawki nigdy nie znajdzie. Schemat pozostaje identyczny wszędzie; to właśnie schemat, a nie miejsce przechowywania, umożliwia agregację wpisów.

Zasady dotyczące „never-log”

Wpisy są zatwierdzane, udostępniane i przetrwają swój kontekst, dlatego niektórych informacji nigdy nie należy w nich umieszczać: tajemnic, danych uwierzytelniających ani kluczy w jakiejkolwiek formie; danych klientów lub danych osobowych; niepublikowanych wyników finansowych; a także – co najważniejsze z punktu widzenia kultury retro – nazwisk, pełnionych funkcji ani niczego, 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 związane z tarciem dotyczą krytycznej oceny danych wejściowych i systemów, a nie osób. Jeśli nie da się opisać tarcia w zakresie bez ujawnienia wrażliwego kontekstu, proszę 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 żart
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 istotne, a nie nadużywać pochwał.
Tarcie – jego przyczyna	Gdzie wystąpiło spowolnienie i jaka była jego podstawowa przyczyna?	Na każdej karcie podano moment, przybliżony koszt oraz jedno określenie z ustalonego słownika zespołu.
Hipotezy, które pozostawiliśmy bez komentarza	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 nie zostało jeszcze zweryfikowane.
Zostawić czy zabić	Które z tych utrudnień wybraliśmy celowo?	Etapy weryfikacji i 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: dokumentacja, środowisko, proces, materiał lub etap wstępny.

Część 3 — karty z podpowiedziami dla moderatora

Pytania, które należy zadać, gdy zespół przedstawia na spotkaniu brief dotyczący projektu „AI-retro”. Jedno pytanie na kartę; proszę wykorzystać te, 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 czasu i kwoty nie można poddać wstępnej ocenie.
2. „Czy to utrudnienie jest punktem kontrolnym, który sami wybraliśmy?” Najpierw zasada „zachowaj lub wyeliminuj”: 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ż ostatnim razem. Co stanęło temu na przeszkodzie?” Niezrealizowane, powtarzające się propozycje 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ół w skali miesiąca?” 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 sekcji dotyczącej środowiska, czy też w opisie zakresu prac?” To 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 trafia ta rzecz?” Przedmiot 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?”agent-error— to 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 — należy raczej naprawić zestaw testowy (Osmani, Agent Harness Engineering).
8. „Która grupa przyczyn źródłowych dominuje w rozkładzie i czy właśnie na nią skupiamy naszą uwagę?” Dane liczbowe zawarte w raporcie wskazują, czy problem dotyczy instrukcji, dokumentacji, materiałów roboczych, oprzyrządowania czy konfiguracji urządzenia. 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 awarii zostało najpierw wykrytych przez osobę, która zauważyła, że coś jest nie tak (arXiv 2606.14589). Proszę traktować te wykrycia jako dowody najwyższej rangi, a nie jako zakłócenia.
10. „Czy chodzi o zakres naszych obowiązków, czy też o zakres innego zespołu?” Poprawki trafiają do zakresu odpowiedzialności zespołu, który je weryfikuje; kartę dotyczącą wspólnego szablonu lub procesu innego zespołu należy przekazać dalej, a nie włączać do własnych zadań.
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 usunięciu, 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. Zainstaluj umiejętności i przeprowadź pierwsze zebranie danych lub przenieś powyższy szablon na tablicę, z której już korzysta Państwa zespół. Część przewodnika po retrospektywach agentów AI.