# Playbook zespołu

Playbook ma pomóc nam pracować razem: wiadomo, co jest najważniejsze, kto odpowiada za wynik, gdzie szukać wiedzy i kiedy pokazać zmianę. Nowa osoba powinna móc dołączyć do pracy bez odtwarzania ustaleń z wielu rozmów.

Poniższy układ opieram na swoim playbooku. Rozbudowałem go o neutralne przykłady, żeby było widać, jak można go wypełnić. Dawne zasady z mojego dokumentu potraktujcie jako punkt wyjścia do rozmowy. U siebie wpiszcie to, jak chcecie pracować i co rzeczywiście stosujecie.

**Przykłady dotyczą fikcyjnej aplikacji do obsługi zgłoszeń. Nie opisują składu, wyników ani bieżących zasad mojego zespołu.** Oznaczenia A–D pokazują przykładowy podział pracy, a nie wymagane stanowiska. Pola w nawiasach kwadratowych uzupełniacie razem z agentem.

## 1. Jak skorzystać z tego pliku

1. Dołączcie go do rozmowy w projekcie. Wskażcie istniejący playbook, dokumentację i narzędzia zespołu.
2. Przejdźcie przez obszary poniżej. Agent ma porównać przykłady z waszą pracą, podać źródła i zapytać o braki.
3. Zostawcie ustalenia, które mają sens. Przy pozostałych zapiszcie, co trzeba doprecyzować. Jeśli playbook już istnieje, uzupełnijcie go.
4. Uzgodnioną wersję zapiszcie w jednym miejscu i podlinkujcie ją w projekcie. Sprawdźcie zasady na bieżącej pracy, a potem poprawcie to, co przeszkadza.

Nie musicie przyjmować wszystkich przykładów ani tworzyć osobnego pliku dla każdego obszaru. Ustalcie też, jakie materiały wolno przekazywać agentowi. Do tego szablonu nie wpisujcie haseł, kluczy ani poufnych informacji o pracownikach.

| Stan ustalenia | Co oznacza |
| --- | --- |
| Obowiązuje | Zespół je uzgodnił; wiadomo, od kiedy i kogo dotyczy |
| Do potwierdzenia | Jest w starym dokumencie, ale nie sprawdziliśmy, czy nadal je stosujemy |
| Propozycja | Chcemy je omówić lub wypróbować; jeszcze nie obowiązuje |
| Do ustalenia | Brakuje decyzji lub osoby odpowiedzialnej |

## 2. Po co jest zespół i co rozwija

Zacznijcie od tego, komu pomagacie i co ma się poprawić. Samo dostarczenie kolejnej funkcji nie mówi jeszcze, czy była potrzebna.

| Pole | Przykład | U nas |
| --- | --- | --- |
| Produkt i użytkownik | Aplikacja dla osób obsługujących zgłoszenia klientów | [wpiszcie] |
| Potrzeba | Szybciej znaleźć sprawy, które czekają na reakcję | [wpiszcie] |
| Granice produktu | Obsługa zgłoszeń; rozliczenia pozostają w osobnym systemie | [wpiszcie] |
| Kto ustala priorytety | Osoba A, odpowiedzialna za produkt | [rola lub wskazanie osoby] |
| Gdzie jest lista pracy | Tablica zespołu w Jira | [link] |
| Gdzie obowiązuje playbook | Strona główna playbooka w Confluence | [link] |
| Kto dba o aktualność | Osoba A zbiera uwagi; każdy odpowiada za swoje obszary | [ustalenie] |
| Wersja i przegląd | [wersja / data / kto potwierdził] | [wpiszcie] |

**Przykładowa zasada:** przed rozpoczęciem zmiany potrafimy powiedzieć, co użytkownik zrobi dzięki niej szybciej, łatwiej albo z mniejszą liczbą błędów. Jeśli nie potrafimy, wracamy do potrzeby.

### Roadmapa i cele kwartalne

U nas patrzymy na cele z roadmapy, a osoby mają przypisane cele indywidualne i zakres odpowiedzialności na kwartał. W playbooku zapiszcie, gdzie jest wasz aktualny plan, kto uzgadnia cele i kiedy do nich wracacie.

Wzór [Roadmapa, cele zespołu i cele indywidualne](team-cele-i-roadmapa-pl.md) zawiera plan ważniejszych rezultatów, cele zespołu, kartę odpowiedzialności osoby i tygodniowy przegląd priorytetów. Połączcie te ustalenia linkami z zadaniami. Cele nie zastępują bieżącej kolejki pracy; pokazują, po co ją wykonujecie i kto prowadzi dany obszar.

## 3. Mapa zasad i wiedzy

W moim playbooku główna strona prowadzi do sześciu obszarów. Jedna reguła ma swoje miejsce, a pozostałe dokumenty prowadzą do niej linkiem.

| Obszar | Co tam trzymamy | Przykład wpisu | U nas: link / kto uzupełnia / kto sprawdza |
| --- | --- | --- | --- |
| Zasady produktu | Odbiorcy, cel, priorytety i kryteria decyzji | „Priorytetem jest skrócenie obsługi sprawy, nie liczba dodanych ekranów” | [uzupełnijcie] |
| Wiedza dziedzinowa | Pojęcia, reguły, wyjątki i ich uzasadnienie | Co oznacza „pilne zgłoszenie” i kto rozstrzyga przypadek niejednoznaczny | [uzupełnijcie] |
| Organizacja zespołu | Odpowiedzialności, rytm pracy, komunikacja i zadania | Kto prowadzi zmianę, kto sprawdza i kto zastępuje nieobecną osobę | [uzupełnijcie] |
| Dostarczanie zmian | Realizacja, demo, testy, odbiór, wydania i awarie | Jak mała poprawka przechodzi do użytkownika | [uzupełnijcie] |
| Interfejs | Proces użytkownika, formularze, komunikaty i wspólne elementy | Jak pokazujemy błąd zapisu i zachowujemy wpisane dane | [uzupełnijcie] |
| Zasady techniczne | Budowa systemu, praca z kodem, agentami i testami | Gdzie są instrukcje projektu i jak uruchomić sprawdzenia | [uzupełnijcie] |

Playbook prowadzi również do **dokumentacji operacyjnej w Confluence**. Ona opisuje stan systemu: architekturę, repozytoria, dane, integracje, środowiska, wdrożenia, monitoring, kopie, testy, dostępy i instrukcje na wypadek problemu. Playbook ustala, kto aktualizuje tę wiedzę i kiedy ją sprawdzamy. Kod pozostaje źródłem informacji o implementacji; historycznego powodu decyzji nie zgadujemy z samego kodu.

| Co zapisujemy przy źródle | Do uzupełnienia |
| --- | --- |
| Produkt i zakres, którego dotyczy | [np. obsługa zgłoszeń, bez rozliczeń] |
| Osoba dbająca o treść i osoba sprawdzająca | [ustalenie] |
| Data ostatniego potwierdzenia / wersja systemu | [data i wersja albo „nie sprawdzono”] |
| Znane braki oraz dalsza praca | [link do istniejącego zadania lub planu] |

### Współpraca z zewnętrznym wykonawcą

Przejdźcie te ustalenia przed pierwszym zadaniem, również gdy zlecacie modernizację lub przepisanie systemu. Po waszej stronie jest osoba, która ustala ramy i sprawdza wynik; wykonawca odpowiada za uzgodnioną pracę oraz jej opis. To wzór ustaleń operacyjnych do dopasowania, nie gotowa treść umowy.

| Co ustalić | Wasz zapis |
| --- | --- |
| Dokumentacja od początku | [miejsce, szkielet, wymagane opisy; kto uzupełnia i kto odbiera] |
| Firmowe narzędzia i zasoby od startu | [organizacja GitHub, Jira/Confluence, używane tablice, np. Miro, projekty GCP, wszystkie domeny, w tym techniczne i testowe; firmowy właściciel, administrator, rozliczenia i potwierdzenie kontroli] |
| Exit plan od początku w umowie | [odnośnik do uzgodnionego planu zakończenia współpracy; zakres przekazania, terminy, wsparcie wykonawcy i warunki odbioru] |
| Wiedza wewnątrz firmy | [kto uczy się rozwoju, wdrożeń i utrzymania; kiedy wykona je samodzielnie] |
| Dostępność i zastępstwo | [kluczowe role i wskazane osoby w waszych ustaleniach, dostępność, zastępstwo i sposób przekazania wiedzy] |

Dla każdego faktycznie używanego narzędzia, projektu chmurowego i domeny zapisz osobno: na kogo założono zasób, firmowego administratora, płatnika i wynik sprawdzenia dostępu. Domeny techniczne i testowe również uwzględnij z osobą dbającą o odnowienie. To lista waszych zasobów, nie zestaw narzędzi do zainstalowania.

**Exit plan — ustalenia jeszcze przed startem:**

- Co uruchamia przekazanie i od kiedy liczymy uzgodnione terminy: **[ustalenie]**
- Co dokładnie obejmuje przekazanie: **[zasoby, dane i historia, dokumentacja, wiedza, otwarte zadania]**
- Kto prowadzi je po każdej stronie i kto może go zastąpić: **[odpowiedzialności]**
- Jakiej dostępności wykonawcy potrzebujemy i jak rozliczamy uzgodnione wsparcie: **[ustalenie]**
- Kto utrzymuje system w trakcie przejęcia i do jakiego momentu: **[ustalenie]**
- Jak potwierdzamy kompletność, gdzie zapisujemy braki i kto je uzupełnia: **[warunki odbioru i dalsze kroki]**

Powiąż te uzgodnienia z umową i bieżącą listą przekazania. Firmowe konta od początku ograniczają późniejsze przepinanie; nie zastępują przekazania wiedzy i sprawdzenia samodzielności zespołu.

**Lista przekazania — uzupełniajcie w istniejącym planie.** Każdy wiersz to wynik do pokazania, a nie ogólna obietnica przekazania. Poniższe warunki są przykładami do dopasowania; próby dotyczą bezpiecznego środowiska i uzgodnionego zakresu.

| Co przekazujemy | Odpowiedzialny po stronie wykonawcy / odbierający u nas | Termin | Warunek odbioru | Dowód i stan |
| --- | --- | --- | --- | --- |
| Kontrola nad narzędziami, GCP i wszystkimi domenami | [role] | [data] | Osoba z firmy potwierdza właściciela, administratora i rozliczenia każdego zasobu; także domen technicznych, ich odnowienia oraz historii zadań i dokumentów | [odnośnik do potwierdzenia; bez sekretów] |
| Kod i uruchomienie | [role] | [data] | Osoba po naszej stronie uruchamia aplikację z firmowego repozytorium według instrukcji | [wersja, wynik próby / brak] |
| Dokumentacja systemu | [role] | [data] | Zespół znajduje opis funkcji i potrafi wykonać uzgodnioną instrukcję bez dopowiadania przez autora | [strony i wynik próby / brak] |
| Wdrożenie i utrzymanie | [role] | [data] | Nasza osoba wdraża wersję na testach, przechodzi ustaloną próbę cofnięcia i wie, gdzie sprawdzić awarię | [wersja, wyniki / braki] |
| Wiedza i bieżąca praca | [role] | [data] | Osoba przejmująca wyjaśnia uzgodnioną regułę i prowadzi wybraną zmianę; wie, gdzie są otwarte zadania | [wynik próby / pytania do wyjaśnienia] |

Przy legacy dopiszcie, kto utrzymuje obecny system podczas zmian i kto przejmuje utrzymanie po przełączeniu. Oddzielcie stan dzisiejszy od tego, co dopiero ustaliliście. Sam dostęp do repozytorium ani spotkanie przekazujące wiedzę nie potwierdzają samodzielności.

Przekazanie zatwierdzacie na podstawie dowodów. Ta lista nie jest zgodą na przenoszenie kont, zmianę uprawnień, umów ani produkcji — takie działania wymagają właściwej decyzji w waszym projekcie. Dopuszczone materiały przekazujcie agentowi bez haseł, danych prywatnych i poufnych warunków handlowych.

## 4. Kto za co odpowiada

W modelu, do którego dążę, są dwie role: dziedzinowy Product Owner ze smykałką do analizy oraz AI Engineers. Product Owner ustala potrzebę, reguły i priorytet, a potem odbiera rezultat. AI Engineer prowadzi zmianę przez ekran, logikę i dane, sprawdza ją oraz przygotowuje wydanie z pomocą agentów.

**Przykładowy podział odpowiedzialności w czteroosobowym zespole:**

| Osoba | Za co odpowiada | Z kim sprawdza / kto zastępuje |
| --- | --- | --- |
| A — Product Owner | Potrzeba, reguły, priorytet, decyzje o interfejsie i odbiór użytkowy | Uzgadnia intencję z prowadzącym AI Engineerem; zastępstwo ustalone przed nieobecnością |
| B — AI Engineer | Całe funkcje w swoim obszarze; dodatkowo koordynacja wydań | C sprawdza zmianę; zastępstwo przy wydaniu ustalone z D |
| C — AI Engineer | Całe funkcje w innym obszarze; dodatkowo wspólne sprawdzenia jakości | B sprawdza zmianę; nie jest to osobny dział testów |
| D — AI Engineer | Całe funkcje w swoim obszarze; dodatkowo środowiska i wspólne decyzje techniczne | B zna instrukcje utrzymania; zastępstwo ma wymagany dostęp |

A–D to fikcyjny przykład, nie opis rzeczywistego składu. Zapiszcie własny podział obszarów i zastępstw. Nie ma tu osobnego testera: AI Engineer z agentami wykonuje testy, sprawdza dowody i organizuje niezależny przegląd. Product Owner odbiera działanie produktu. Gdy brakuje kompetencji, wskazujecie potrzebne wsparcie.

| Decyzja | Kto ją podejmuje u nas | Gdzie zostaje zapis |
| --- | --- | --- |
| Co robimy teraz i co odkładamy | [odpowiedzialny za produkt] | [lista pracy] |
| Jak ma działać reguła i jej wyjątki | [osoba znająca dziedzinę] | [źródło reguły] |
| Jakiego rozwiązania technicznego użyjemy | [odpowiedzialny za technologię] | [decyzja w planie lub dokumentacji] |
| Czy wynik odpowiada potrzebie | [osoba odbierająca] | [odbiór przy zadaniu] |
| Kiedy wydajemy i kto reaguje na problem | [odpowiedzialny za wydanie] | [karta wydania / portal] |

## 5. Jedno główne zadanie i rytm pracy

W swoim playbooku przyjąłem jedno główne zadanie na osobę. Pomoc innym, przegląd kodu i reagowanie na awarię mieszczą się obok niego. Jeśli wpada pilna praca, jawnie ustalamy, co odkładamy i jak zmienia się termin.

| Kiedy | Przykładowa zasada z mojego playbooka | Co ma po tym zostać |
| --- | --- | --- |
| Codziennie, bez spotkania | Krótka wiadomość: dzisiaj, jutro, planowane zakończenie | Wiadomo, co się ruszyło i kiedy spodziewać się wyniku |
| Raz w tygodniu | Godzina na priorytety, blokady, wyniki i główne zadania | Uzgodniona kolejność i odpowiedzialność |
| Gdy pojawia się blokada | Rozmowa na czacie, a w razie potrzeby szybkie spotkanie właściwych osób | Decyzja lub konkretna pomoc |
| Gdy jest co pokazać | Demo i odbiór na bieżąco | Uwagi, decyzja i następny krok |

To przykłady ze starszego playbooka, nie obowiązkowy kalendarz ceremonii. Dziś kieruję się krótką rozmową Product Ownera z AI Engineerem wtedy, gdy trzeba przekazać intencję, podjąć decyzję albo zobaczyć wynik. Zapiszcie sedno: dla kogo, oczekiwany rezultat, poza zakresem i otwarte pytanie. Product Owner potwierdza skrót przygotowany przez agenta. Nie trzeba czekać do przeglądu tygodniowego z pytaniem, które zatrzymuje pracę.

**Przykład krótkiej wiadomości** — do podstawowego formatu dodałem pole na blokadę:

```text
Dzisiaj: filtr pilnych zgłoszeń działa w lokalnym podglądzie.
Jutro: sprawdzę pustą listę i zachowanie po zmianie priorytetu.
Planowane zakończenie: jutro po sprawdzeniu i demo.
Potrzebuję: potwierdzenia, co ma się stać ze sprawą bez priorytetu.
Zadanie: [link].
```

Nie powielajcie całej historii zadania w wiadomości. Status i dowody zostają przy zadaniu, a czat pomaga szybko się dogadać.

## 6. Gdzie pracujemy i gdzie pytamy

W tabeli jest przykład oparty na narzędziach, z których korzystamy. U siebie wskażcie konkretne miejsca; nie instalujcie całej listy tylko po to, żeby ją odhaczyć.

| Miejsce | Do czego służy | Co tam zapisujemy |
| --- | --- | --- |
| Jira | Uzgodniona praca i jej status | Cel, zakres, odpowiedzialność, wynik sprawdzeń, linki do kodu i odbioru |
| Confluence | Wspólne zasady i wiedza | Playbook, decyzje, reguły oraz uzupełniana dokumentacja systemu |
| GitHub i CodeRabbit | Kod i przegląd zmian | Propozycja zmiany, komentarze i wynik przeglądu; uwagi automatyczne wymagają oceny |
| Google Chat — rozmowy zespołu | Pytania, blokady i krótka informacja dzienna | Temat, potrzebna pomoc i link do zadania |
| Google Chat — wydania i awarie | Stan produkcji i szybka reakcja | Co wydano, gdzie, wynik sprawdzenia, kto prowadzi problem |
| Portal wdrożeń | Widok wersji w środowiskach | Wersja faktycznie uruchomiona i wynik jej sprawdzenia |
| Monitoring, np. UptimeRobot | Informacja o problemie z dostępnością | Alert i wskazanie, kto reaguje; sam alert nie potwierdza poprawności obliczeń |

Nazwy dwóch miejsc rozmowy powyżej są opisowe. Wpiszcie własne kanały i zasady ich użycia. Pozostałe narzędzia, w tym chmurę, VPN i zarządzanie dostępami, połączcie z instrukcjami w dokumentacji operacyjnej. Playbook ma do nich prowadzić.

**Przykładowa zasada:** jeżeli na czacie ustalamy zmianę reguły, osoba prowadząca zapisuje decyzję i jej powód we właściwym dokumencie. W zadaniu dodaje link. Ustalenie nie zostaje tylko w rozmowie.

## 7. Jak wygląda zadanie w Jira

To wspólny standard zapisu pracy. Sam playbook obejmuje cały zespół; poniższa karta pokazuje jedynie, jak ten standard zastosować.

| Pole | Przykładowe wypełnienie |
| --- | --- |
| Tytuł | Pokaż pilne zgłoszenia na liście |
| Po co i dla kogo | Osoba obsługująca zgłoszenia ma szybko znaleźć sprawy wymagające reakcji |
| Zakres | Filtr priorytetu, pusta lista i zachowanie po zmianie priorytetu |
| Poza zakresem | Automatyczne wyznaczanie priorytetu oraz wysyłka powiadomień |
| Odbiór | Po włączeniu filtra widać tylko sprawy oznaczone jako pilne; brak wyników ma jasny komunikat |
| Reguła | Korzystamy z istniejącej definicji priorytetu [link]; brak reguły wymaga ustalenia |
| Osoba prowadząca / odbierająca | B / A — przykład, nie rzeczywiste przypisanie |
| Ryzyko i sprawdzenie | Trzeba sprawdzić filtr, brak wyników i zachowanie uprawnień: filtr nie ujawnia cudzych spraw |
| Powiązania | [plan], [reguła], [propozycja zmiany w GitHubie], [wyniki testów] |
| Stan | Przykład zadania przed realizacją; testów jeszcze nie wykonano |

Większą inicjatywę można zebrać w **Epic**, czyli temat łączący kilka rezultatów. **Task / Story** opisuje samodzielną zmianę, a **Bug** naprawę błędu. Podzadania dodawajcie wtedy, gdy pomagają podzielić pracę.

| Status | Co oznacza w tym przykładzie |
| --- | --- |
| Backlog | Temat czeka na swoją kolej |
| Do zrobienia | Wiadomo, co ma powstać, kto prowadzi i jak sprawdzimy wynik |
| W toku | Trwa rozpoznanie, realizacja, demo lub poprawki |
| Do odbioru | Jest wynik, dowody sprawdzenia i osoba, która może go ocenić |
| Odebrane technicznie | Zmiana spełnia uzgodnione warunki; stan wydania zapisujemy osobno |

**Wydanie ma własny stan:** nie dotyczy / oczekuje na decyzję / zaplanowane / wdrożone i sprawdzone / wycofane. Ustalcie, któremu stanowi odpowiada wasze „Gotowe” w Jira. Akceptacja demo nie jest zgodą na produkcję.

Blokadę można oznaczyć flagą przy zadaniu. Dopiszcie, czego brakuje i od kogo potrzebna jest pomoc. Nie zostawiajcie samego słowa „zablokowane”.

## 8. Ile sprawdzamy przed oddaniem zmiany

W moim playbooku rozróżniłem trzy tryby zależnie od ryzyka. Poniżej są przykłady do uzgodnienia. Mały zakres kodu nie zawsze oznacza małe ryzyko.

| Tryb | Przykład | Jak prowadzimy i sprawdzamy |
| --- | --- | --- |
| Mała zmiana — Fast | Literówka albo odstęp, bez zmiany działania | Oglądamy efekt i sprawdzamy to, co mogło się zepsuć; właściwa osoba przyjmuje wynik |
| Zwykła realizacja — Standard | Nowy filtr, integracja, zmiana reguły lub uprawnień | Najpierw wymagania i decyzje; potem demo, przegląd, testy dobrane do ryzyka i sprawdzenie na środowisku testowym |
| Awaria — Emergency | Niedostępna aplikacja albo zagrożone dane | Jedna osoba prowadzi reakcję; ustalamy bezpieczną naprawę lub cofnięcie, sprawdzamy krytyczny przebieg i uzupełniamy zapis po przywróceniu działania |

Jeśli rośnie zakres, ryzyko lub niepewność, zmieniamy sposób prowadzenia pracy. Pilna naprawa nadal wymaga osoby odpowiedzialnej i sprawdzenia efektu. Nie daje agentowi dodatkowych uprawnień do produkcji.

## 9. Praca z agentami, demo i przegląd

Te zasady łączą przykłady z playbooka z moim sposobem pracy opisanym w The A-Team. Dostosujcie je do swoich narzędzi i uprawnień.

| Moment | Co robimy | Co zostaje po tej pracy |
| --- | --- | --- |
| Start etapu | Wskazujemy potrzebę, instrukcje projektu, wiedzę, zakres i sposób sprawdzenia | Jeden plan powiązany z zadaniem; pytania i decyzje przed realizacją |
| Praca | Prowadzimy główny temat w jednym czacie; agent realizuje uzgodniony fragment | Działający przyrost i aktualny stan w planie |
| Pytanie obok | Ogólne wyjaśnienie można uzyskać w osobnym czacie, bez zmieniania plików | Ważna decyzja wraca do głównego zadania |
| Pierwsze ekrany | Product Owner zatwierdza główne przebiegi i design system; AI Engineer zapisuje zasady oraz wskazuje komponenty agentom | Kolejne widoki powstają według tych ustaleń; nowy wzorzec wymaga uzgodnienia |
| Praca równoległa | AI Engineers prowadzą różne funkcje. Przed startem sprawdzają wspólne pliki, dane i komponenty; ustalają właściciela kolizji | Osobne gałęzie i katalogi pracy; kolejność wspólnej zmiany oraz osoba sprawdzająca połączenie |
| Demo | Człowiek ogląda wynik także małego zadania; zatrzymuje pokaz, zapisuje uwagę lub zleca poprawkę teraz | Jedna lista uwag w istniejącym planie lub zadaniu oraz jasny zakres akceptacji |
| Po demo | Poprawiamy uwagi i sprawdzamy skutki; małe poprawki oglądamy, większe przechodzimy w ponownym demo. Po akceptacji porządkujemy kod i robimy potrzebny refaktor | Ponownie sprawdzona i obejrzana wersja, bez pozostałości po próbach |
| Niezależny przegląd | Inny agent w świeżym czacie sprawdza wymagania, czytelność, duplikacje, błędy i gotowość do użycia | Konkretne uwagi z dowodami, poprawki i wyniki sprawdzeń |
| Koniec etapu | Aktualizujemy plan; sprawdzamy dotyczące zmiany strony w Confluence i poprawiamy ich treść, jeśli zmiana na nią wpływa | Wersja, wynik, ograniczenia oraz następny krok; kolejny większy etap może zacząć nowy czat |

Przy większej zmianie lub na koniec projektu korzystam z drugiej perspektywy, np. mocniejszego modelu Claude od Anthropic. Najpierw prosimy o przegląd, a potem uzgadniamy poprawki i refaktor. Samo użycie innego modelu nie potwierdza jakości. Po zmianach trzeba ponownie sprawdzić działanie.

Agent może proponować, pisać i testować. Osoba prowadząca sprawdza wynik; właściwa osoba akceptuje regułę, produkt i wydanie. brAIn, middleware oraz MiddleBrain są opisane osobno w The A-Team jako moje rozwijane podejście do wiedzy. Korzystanie z tego szablonu nie wymaga ich wdrożenia.

## 10. Kiedy przyjmujemy zmianę i kiedy ją wydajemy

| Pytanie przed odbiorem | Gdzie szukamy odpowiedzi |
| --- | --- |
| Czy rozwiązuje uzgodnioną potrzebę? | Kryteria zadania, demo i decyzja osoby odbierającej |
| Czy reguły oraz wyjątki nadal działają? | Właściwe źródło wiedzy i sprawdzenia dla tej wersji |
| Czy uwagi z przeglądu zostały rozstrzygnięte? | Przegląd kodu oraz zapis wykonanych poprawek i otwartych spraw |
| Co rzeczywiście sprawdzono? | Wyniki testów; niewykonane sprawdzenia są nazwane |
| Czy dokumentacja odpowiada zmianie? | Sprawdzone strony, źródła, wersja i osoba sprawdzająca; potrzebne poprawki lub potwierdzenie, że zmiana nie wpływa na treść |
| Czy można to oddać do użycia? | Konfiguracja, uprawnienia, dane, zachowanie przy błędach i utrzymanie stosownie do aplikacji |
| Czy jest decyzja o wydaniu? | Jawne ustalenie dla konkretnej wersji i środowiska |

Przed wdrożeniem ustalcie, kto je prowadzi, co sprawdzi pod docelowym adresem i jak zareaguje na problem. Sposób cofnięcia musi uwzględniać dane, jeśli zmiana ich dotyczy. Instrukcje szczegółowe znajdują się w dokumentacji operacyjnej.

**Przykładowy komunikat po wdrożeniu** — rozszerzenie krótkiej wiadomości z mojego playbooka. W prawdziwym komunikacie wpisujemy tylko potwierdzone informacje:

```text
[PRZYKŁAD — nie jest raportem z rzeczywistego wdrożenia]
Aplikacja do zgłoszeń • v0.4 • środowisko testowe
Zmiana: filtrowanie pilnych zgłoszeń. Zadanie: [link].
Wersja potwierdzona w portalu: [wersja / czas / link].
Sprawdzenie po wdrożeniu: [co sprawdzono i jaki był wynik].
Otwarte problemy: [lista albo potwierdzony brak znanych problemów].
Wydanie prowadzi: [osoba]. Problemy zgłaszamy: [miejsce].
Cofnięcie i ewentualne odtworzenie danych: [instrukcja].
```

Przy awarii wskażcie jedną osobę prowadzącą reakcję. Oceńcie wpływ, ustalcie naprawę lub cofnięcie, sprawdźcie krytyczny przebieg i poinformujcie właściwe osoby. Po przywróceniu działania uzupełnijcie zadanie oraz instrukcję, jeśli można dzięki temu uniknąć powtórki.

## 11. Jak nowa osoba dołącza do pracy

| Krok | Po czym poznajemy, że działa |
| --- | --- |
| Czyta cel produktu i playbook | Potrafi powiedzieć, komu pomagamy, kto ustala priorytety i gdzie pytać |
| Uzyskuje zatwierdzone dostępy do potrzebnych narzędzi | Otwiera właściwy projekt; nie korzysta z cudzego konta |
| Uruchamia bezpieczny podgląd i przechodzi główny scenariusz | Rozumie, co użytkownik robi od początku do wyniku |
| Sprawdza agenta z instrukcjami i jednym źródłem wiedzy | Agent wskazuje źródło odpowiedzi i nazywa to, czego nie wie |
| Wykonuje małą zmianę z drugą osobą | Przechodzi od zadania przez demo i sprawdzenia do odbioru |

Zapiszcie, kto pomaga na starcie: **[osoba / zastępstwo]**. Brak dostępu lub niezrozumiały opis wraca jako poprawka do instrukcji, zamiast pozostawać problemem każdej kolejnej osoby.

## 12. Czy ten sposób pracy nam pomaga

W swoim playbooku patrzyłem na wynik inicjatywy, czas dostarczenia i problemy po wdrożeniu. Najpierw zbieramy punkt odniesienia, dopiero potem ustalamy cele. Liczba promptów czy linii kodu nie mówi, czy użytkownik ma lepiej.

| Co obserwujemy | Przykładowe źródło | O czym rozmawiamy |
| --- | --- | --- |
| Wynik dla użytkownika | Próba wykonania tej samej czynności przed i po zmianie | Czy łatwiej znajduje pilne sprawy i rzadziej się myli? |
| Czas dostarczenia | Daty uzgodnienia zadania, odbioru i wdrożenia | Gdzie czekamy, wracamy po wiedzę lub robimy poprawki? |
| Problemy po wydaniu | Awarie, regresje, cofnięcia i zgłoszenia | Co trzeba lepiej sprawdzać lub uprościć? |
| Praca ludzi z agentami | Rozmowa o konkretnym zadaniu | Co pomaga, gdzie nie ufamy wynikowi i jakiego wsparcia potrzebujemy? |

To rozmowa o działaniu zespołu, nie ranking ludzi. Przy pierwszej próbie wpiszcie „jeszcze nie zmierzyliśmy”, jeśli nie ma danych.

Ustalcie też pomiar pracy z AI. Ja porównuję liczbę wykonanych zadań, mierzę czas dojścia do produkcji i patrzę na cele roadmapy. Osoby mają cele indywidualne oraz zakres odpowiedzialności na kwartał. Sam wzrost liczby zadań nie pokazuje realizacji tych celów, jakości ani bezpieczeństwa. Praktyczną kartę do uzupełnienia znajdziecie w [rozmowie o zmianie i pomiarze efektów AI](team-ai-transition-pl.md).

| Ustalenie zespołu | Co wpisać do naszych zasad |
| --- | --- |
| Co liczymy jako zakończone zadanie | Wspólna definicja odbioru; osobna data wydania, jeśli następuje później; bez podwójnego liczenia podzadań |
| Co porównujemy | Podobne rodzaje pracy, równe okresy, dostępność zespołu oraz jednakowy czas obserwacji błędów |
| Jak mierzymy czas dostarczenia | Uzgodnione zdarzenie wejścia do procesu → potwierdzona produkcja; jawna jednostka czasu i lista jeszcze niewydanych zmian |
| Co sprawdzamy obok liczby zadań | Użycie AI w realnej pracy, czas do produkcji, praca nadal niedostarczona, poprawki, problemy po wydaniu, kontrole bezpieczeństwa i wynik celów |
| Kto zbiera dane i gdzie je omawiamy | [odpowiedzialność, istniejące miejsce zapisu, rytm przeglądu i termin pierwszego porównania] |

Nie twórzcie drugiego rejestru: karta prowadzi do danych z zadań, wydań i sprawdzeń. Brak pomiaru to „brak danych”, nie zero. Używanie agenta nie dowodzi przyspieszenia, a brak wykrytych usterek nie potwierdza bezpieczeństwa. Wspólne zasady określają zakres kontroli i problemy blokujące wydanie — większa liczba zadań tego nie zmienia.

## 13. Jak utrzymujemy playbook

Przy zmianie narzędzia, odpowiedzialności albo sposobu wydawania poprawiamy właściwy fragment. Przy przeglądzie zespołu wracamy do zapisów, które rozmijają się z pracą.

| Co wymaga decyzji | Propozycja | Kto uzgodni i do kiedy | Wynik / źródło |
| --- | --- | --- | --- |
| Przykład: demo czeka do spotkania tygodniowego | Pokazujemy gotowy fragment od razu osobie odbierającej | [uzgodnijcie] | Propozycja — do wypróbowania |
| Przykład: dokumentacja pozostaje po zmianie nieaktualna | Aktualizacja i sprawdzenie odpowiednich stron przy odbiorze | [uzgodnijcie] | Propozycja — do potwierdzenia |
| [wasz temat] | [propozycja] | [odpowiedzialność i termin] | [decyzja / link] |

**Gotowy wynik:** potraficie znaleźć wspólne zasady, wskazać odpowiedzialność i przejść według nich pracę. Uzgodniony playbook ma aktualną wersję. Otwarte decyzje są widoczne, a potwierdzone ustalenia trafiają do właściwych źródeł.

## Prompt do pracy nad waszym playbookiem

```text
Przeczytaj załączony playbook oraz nasze obecne ustalenia: [linki].
Chcemy dopasować zasady pracy całego zespołu, a nie stworzyć plan jednego zadania.

Najpierw wskaż, co już mamy: cel produktów, źródła wiedzy, odpowiedzialności,
rytm pracy, narzędzia, standard zadań, sposób sprawdzania i wydawania zmian.
Oddziel potwierdzone zasady od starych zapisów, propozycji i braków.
Nie kopiuj przykładowych osób A–D, terminów ani wyników jako naszych danych.

Przejdź z nami po jednym obszarze. Wypełniaj tabele na podstawie odpowiedzi
i źródeł; przy brakach pytaj. Przygotuj przykłady dopasowane do naszej pracy.
Zachowaj jeden zapis każdej reguły i odnośniki do istniejących dokumentów.
Uwzględnij dokumentację operacyjną w Confluence i jej aktualizację przy zmianach.
Nie narzucaj nowych stanowisk ani narzędzi.

Pokaż proponowane zmiany do wspólnego uzgodnienia. Ustal, kto dba o każdy
obszar i kto sprawdza treść. Po zatwierdzeniu przez nas zmian i wskazaniu
konkretnego dokumentu do aktualizacji zapisz je w uzgodnionym miejscu.
Bez takiego polecenia lub bez dostępu do zapisu przygotuj
treść i powiedz, co nadal wymaga zapisania. Nie zmieniaj kont, uprawnień,
środowisk ani konfiguracji narzędzi. Nie wykonuj publikacji lub wdrożenia.
Na koniec zaproponuj próbę zasad na jednym bieżącym zadaniu.
```