# Jak zmienić pracę zespołu, kiedy zaczynamy korzystać z AI?

Weźcie jedno zadanie, które i tak macie wykonać. Przejdźcie je razem od potrzeby do działającej zmiany. Wtedy zobaczycie, gdzie agent pomaga, a gdzie nadal czekacie na decyzję, wiedzę albo drugą osobę.

Nie oceniajcie ludzi ani liczby promptów. Sprawdźcie, czy użytkownik dostaje potrzebny wynik, a zespół mniej razy odtwarza ten sam kontekst.

## Zapiszcie model przed i po

Weźcie wasze obecne role i jedno rzeczywiste zadanie. Docelowy układ opisany w The A-Team to dziedzinowy Product Owner i AI Engineers. Poniżej zapiszcie odpowiedzialności do uzgodnienia, bez nazwisk i prywatnych informacji.

| Odpowiedzialność | Jak jest teraz — rola i przekazania | Jak ma być po zmianie |
| --- | --- | --- |
| Potrzeba, analiza, reguły i odbiór | [Product Owner / analityk / inne] | [Product Owner: zakres decyzji i brakująca wiedza] |
| Architektura, ekran, logika i dane | [tech lead / architekt / frontend / backend] | [AI Engineer prowadzący całą funkcję; potrzebne wsparcie] |
| Testy i sprawdzenie jakości | [tester manualny / automatyzujący / inne] | [AI Engineer i agenci: próby; niezależny przegląd; kto sprawdzi dowody] |
| Środowiska, wydanie i awarie | [DevOps / inne] | [AI Engineer odpowiedzialny za ten zakres; zastępstwo i zgoda na wydanie] |
| Uzgodnienia i usuwanie blokad | [Scrum Master / inne] | [kto podejmuje decyzję; kiedy wystarczy krótka rozmowa] |

Każdy wiersz musi mieć odpowiedzialnego człowieka. Jeśli brakuje wiedzy, wpiszcie, kto pomoże przy pierwszej próbie. Samo usunięcie nazwy stanowiska nie wykonuje jego pracy.

## Uzgodnijcie intencję przed startem

Product Owner i AI Engineer krótko omawiają zadanie. Agent zapisuje sedno:

- **Dla kogo i jaki problem rozwiązujemy:** [do uzupełnienia]
- **Co pokażemy na demo:** [czynność i oczekiwany wynik]
- **Czego teraz nie robimy:** [granica zadania]
- **Jaka odpowiedź jest potrzebna przed startem:** [pytanie i rola, która je rozstrzyga]
- **Potwierdzenie Product Ownera:** [potwierdzone / do poprawy]

Przy interfejsie wskażcie zaakceptowany design system i główne przebiegi użytkownika. Jeśli ich jeszcze nie ma, najpierw pokażcie próbę ekranów. Product Owner zatwierdza kierunek, AI Engineer wskazuje agentom zasady i komponenty do użycia.

## Co nas dziś spowalnia?

- Na co czekamy przy tym zadaniu: analizę, decyzję, frontend, backend, testy czy wydanie?
- Ile razy przekazujemy temat kolejnej osobie? Co trzeba jej za każdym razem tłumaczyć od początku?
- O co stale pytamy tę samą osobę, bo tylko ona zna powód obecnego zachowania?
- Gdzie agent zwrócił wynik, którego nie można było przyjąć bez poprawki albo drugiej opinii?

## Jak naprawdę pracujesz z agentem?

- Pokaż na tym zadaniu, co robisz sam, a co oddajesz agentowi.
- Gdzie mu nie ufasz? Pokaż konkretny wynik, który musiałeś poprawić albo wyrzucić.
- Czy agent ma potrzebną wiedzę o projekcie, czy w każdym czacie tłumaczysz mu wszystko od nowa?
- Co zajmuje ci więcej czasu: zlecenie pracy, czekanie na wynik czy sprawdzanie i poprawki?

## Co ta zmiana oznacza dla ciebie?

- Lubisz pisać kod. Co się zmienia, kiedy coraz więcej pisze agent? Co nadal chcesz robić sam i dlaczego?
- Do tej pory robiłeś frontend albo backend. Czego ci brakuje, żeby z agentem przejść przez całą funkcję i sprawdzić, czy działa?
- W którym miejscu potrzebujesz drugiej osoby, żeby nie zgadywać?
- Kto w zespole już tak pracuje i może pokazać reszcie jedno zadanie od początku do końca?

Przed próbą uzupełnijcie także ustalenia w części „Zbierzcie dane do przeglądu” poniżej. Rozmowa pokazuje przeszkody, a zapisane dane pozwolą później sprawdzić, czy sposób pracy rzeczywiście się zmienił.

## Zróbmy jedno zadanie inaczej

Zapiszcie przed startem:

- **Co ma działać na końcu?** Konkretny efekt do pokazania na demo.
- **Kto prowadzi zadanie od początku do końca?** Kto pomoże, gdy wyjdzie ono poza jego dotychczasowy obszar?
- **Co zrobi agent?** Do czego ma dostęp, a przed czym musi się zatrzymać i zapytać?
- **Skąd weźmie wiedzę?** Wskażcie opis, kod, regułę i przykład. Brakujące odpowiedzi zapiszcie dla następnej osoby.
- **Kto sprawdzi wynik?** Co sprawdzicie w testach, co na demo i kto podejmie decyzję o wydaniu?
- **Co w tym czasie poczeka?** Próba nie jest dodatkową pracą po godzinach.
- **Kiedy pokażecie wynik?** Ustalcie termin demo z czasem na naukę i poprawki.

## Uzupełnijcie zapis waszego zadania

Otwórzcie zadanie, które wybraliście do wykonania. Agent uzupełnia tabelę z jego opisu i rozmowy. Przy braku informacji ma zapytać, zamiast wstawić wymyślony przykład.

| Co zapisać | Co przekazać agentowi lub uzgodnić |
| --- | --- |
| Zadanie | Link do bieżącego zadania i powód, dla którego je robicie |
| Wynik do pokazania | Czynność, którą użytkownik wykona na demo, oraz oczekiwany efekt |
| Wiedza | Dokumenty, kod i odpowiedzi osoby znającej działanie tej funkcji |
| Podział pracy | Osoba prowadząca, pomoc w mniej znanym obszarze, recenzent i osoba odbierająca demo |
| Czekanie i przekazania | Gdzie podobna praca ostatnio utknęła i jakie przekazanie spróbujecie skrócić |
| Po wykonaniu | Co faktycznie pomogło, co wróciło do poprawy i jaka wiedza nadal była potrzebna |
| Następna próba | Jedna zmiana w sposobie pracy, osoba odpowiedzialna i zadanie, na którym ją sprawdzicie |

## Po demo

Przejdźcie funkcję na żywo, zbierzcie małe uwagi i poprawcie je. Potem uporządkujcie kod, wykonajcie sprawdzenia dobrane do ryzyka i zlećcie niezależny przegląd. Samo „działa na ekranie” nie zamyka zadania.

Wróćcie do zapisu sprzed próby: gdzie czekaliście krócej, ile pracy wróciło do poprawy i gdzie nadal potrzebowaliście pomocy? Czy potrafisz już przejść następne zadanie, czy nadal potrzebujesz kogoś obok? Co dało ci satysfakcję, a co przeszkadzało? Odpowiedź ma pomóc ustalić następną próbę i wsparcie, nie służyć do oceny pracownika.

Zapiszcie: **co zmieniamy, kto to bierze i przy którym zadaniu sprawdzimy efekt**. Materiały dla agenta muszą być dopuszczone przez zespół; nie wpisujcie nazwisk, danych prywatnych ani sekretów.

## Prompt do rozmowy o próbie

```text
Pracujemy nad jednym istniejącym zadaniem. Przeczytaj załączony plik oraz źródła: [linki].
Najpierw oddziel fakty potwierdzone źródłem od braków i propozycji.
Pomóż nam zapisać podział odpowiedzialności przed i po: Product Owner, AI Engineers
i praca agentów. Zapytaj o braki wiedzy i wsparcie, nie proponuj zmian zatrudnienia.
Skróć ustalenia do intencji, wyniku demo, granic zadania i pytań przed startem.
Pokaż je do potwierdzenia Product Ownerowi. Potem uzupełnij tabelę próby:
wiedza dla agenta, sprawdzenie, blokada i zmiana przy następnym zadaniu.
Nie wymyślaj decyzji, wyników testów ani wdrożeń. Przy niepewności zapytaj.
Najpierw pokaż uzupełniony tekst do wspólnego uzgodnienia. Nie zmieniaj plików,
kont, uprawnień, środowisk ani zewnętrznych systemów.
```

## Zbierzcie dane do przeglądu

Weźcie dwa równe okresy i podobne rodzaje pracy. Daty oraz wyniki bierzcie z waszych zadań i wydań. Brak danych oznaczcie wprost — nie odtwarzajcie liczb z pamięci. To propozycja karty do dopasowania do projektu.

| Co uzgodnić przed liczeniem | Wasz zapis |
| --- | --- |
| Okres przed zmianą / okres po zmianie | [daty] |
| Cel roadmapy i odpowiedzialność na kwartał | [linki do ustaleń] |
| Co liczymy jako ukończone zadanie | [warunki odbioru; bez podwójnego liczenia rodzica i podzadań] |
| Od czego mierzymy czas do produkcji | [zdarzenie wejścia, potwierdzenie wdrożenia, dni kalendarzowe lub robocze] |
| Jak długo obserwujemy błędy po wydaniu | [taki sam czas dla porównywanych zmian] |
| Co zmieniło się poza użyciem AI | [rodzaj i wielkość zadań, skład, dostępność, nauka, inne obowiązki] |

## Uzupełnijcie wynik

Przy każdej liczbie podajcie źródło. Jeśli zadanie nie wymaga wdrożenia, zaznaczcie to z powodem; nie dopisujcie fikcyjnej daty produkcji. Przy błędach porównujcie wyłącznie zmiany, dla których minął cały uzgodniony czas obserwacji.

| Co sprawdzamy | Przed / źródło | Po / źródło |
| --- | --- | --- |
| Odebrane zadania, osobno funkcje / błędy / utrzymanie | [liczby] | [liczby] |
| Czas do produkcji dla każdego wydanego zadania | [daty wejścia i wdrożenia, różnica dat] | [daty wejścia i wdrożenia, różnica dat] |
| Niewydane zmiany i czas oczekiwania | [liczba i najstarsze zadania] | [liczba i najstarsze zadania] |
| Zadania, które wróciły przez potwierdzony błąd | [liczba z błędem / wszystkie z pełnym okresem obserwacji] | [liczba z błędem / wszystkie z pełnym okresem obserwacji] |
| Problemy po wydaniu | [wydanie, objaw, wpływ, czas naprawy] | [wydanie, objaw, wpływ, czas naprawy] |
| Sprawdzenia jakości i bezpieczeństwa | [wersja, co sprawdzono, wynik, otwarte problemy] | [wersja, co sprawdzono, wynik, otwarte problemy] |
| Użycie agentów w rzeczywistej pracy | [ile osób z obecnego zespołu; zastosowania, wyniki przyjęte i odrzucone] | [ile osób z obecnego zespołu; zastosowania, wyniki przyjęte i odrzucone] |
| Wynik celu roadmapy | [co działa, czego brakuje, dowód] | [co działa, czego brakuje, dowód] |

Z tej tabeli przygotujcie krótkie podsumowanie: liczba obserwacji, typowy czas do produkcji i najdłuższe przypadki. Możecie użyć mediany — środkowej wartości uporządkowanych czasów, a przy parzystej liczbie wyników średniej dwóch środkowych. Czas oczekiwania nie jest liczbą godzin pracy człowieka. Przy małej liczbie zadań pokażcie je osobno.

Nie sumujcie jednego wydania kilka razy dlatego, że zawiera kilka zadań. Brak wykrytych usterek nie potwierdza bezpieczeństwa, jeśli nie ma dowodu wykonania potrzebnych kontroli. Nowy skaner mógł wykryć starszy problem; zaznaczcie zmianę zakresu sprawdzeń.

## Ustalcie, co zmieniacie po przeglądzie

Otwórzcie konkretną zmianę, na której widać problem. Czy czekacie na wiedzę, decyzję, przegląd czy wydanie? Czy poprawki po agencie zjadają zaoszczędzony czas? Co można poprawić przy najbliższym zadaniu?

| Decyzja | Wasz zapis |
| --- | --- |
| Co pomaga i zostaje | [praktyka oraz zadanie, na którym się sprawdziła] |
| Co przeszkadza | [konkretny przypadek i źródło] |
| Jedna zmiana w pracy | [co zrobicie inaczej] |
| Kto prowadzi i jakiej pomocy potrzebuje | [odpowiedzialność i wsparcie] |
| Na którym zadaniu i kiedy sprawdzicie wynik | [link, termin, sposób sprawdzenia] |

Cele i odpowiedzialności zapisujcie w swoim planie. Do jego uzupełnienia możecie użyć wzoru [Roadmapa i cele kwartalne](team-cele-i-roadmapa-pl.md). Cel indywidualny sprawdzajcie po uzgodnionym rezultacie, nie liczbie promptów czy zamkniętych zadań. Nie przypisujcie całej różnicy między okresami AI, jeśli zmieniły się również inne warunki.

## Prompt do przeglądu

```text
Przeczytaj kartę i nasze źródła z okresów [przed] i [po]: [linki lub załączniki].
Najpierw sprawdź, czy porównujemy podobną pracę. Zapytaj o brakujące definicje.
Policz zadania i czas do potwierdzonej produkcji, pokaż zmiany niewydane,
poprawki oraz faktyczny wynik celów roadmapy i odpowiedzialności kwartalnych.
Uwzględnij dostępność zespołu, czas obserwacji błędów i dowody sprawdzeń.
Podaj źródła oraz liczbę obserwacji. Nie licz podwójnie zadań ani wydań.
Brak danych to nie zero; odbiór lub połączenie kodu nie potwierdzają produkcji.
Pokaż, gdzie agent pomógł, a gdzie musieliśmy poprawiać lub czekać.
Nie przypisuj całej zmiany AI i nie oceniaj osób liczbą zadań.
Zaproponuj jedną zmianę do następnego zadania: co, kto, kiedy sprawdzi wynik.
Pokaż ją do uzgodnienia. Nie zapisuj nic w zewnętrznych systemach.
```