Playbook zespołu: jak razem pracujemy

Playbook opisuje zasady codziennej pracy całego zespołu: jak ustalacie priorytety, dzielicie odpowiedzialność, komunikujecie się, korzystacie z agentów i wydajecie zmiany. Nowa osoba powinna móc z niego zrozumieć, jak dołączyć do pracy. Obecna — znaleźć ustalenie, zamiast pytać o nie kolejny raz.

Zróbcie mapę zasad i wiedzy

W moim playbooku stronę główną potraktowałem jako punkt wejścia dla ludzi i agentów. Z niej przechodzimy do sześciu obszarów:

• Zasady produktu: dla kogo go budujemy, jaką wartość ma dawać i czym kierujemy się przy decyzjach.
• Wiedza dziedzinowa: pojęcia, reguły, wyjątki i ich uzasadnienie. Wspólny zespół może rozwijać kilka produktów, ale ich reguły mogą się różnić.
• Organizacja zespołu: odpowiedzialności, priorytety, rytm pracy, komunikacja i sposób zapisywania zadań.
• Dostarczanie zmian: od potrzeby przez realizację i sprawdzenie do odbioru, wydania oraz reakcji na problem.
• Interfejs i korzystanie z produktu: przebiegi pracy użytkownika, formularze, komunikaty i wspólne elementy ekranów.
• Zasady techniczne: budowa systemu, kod, praca z agentami, przeglądy i testy.

Ważna jest zasada: każde ustalenie ma jedno miejsce. Playbook prowadzi do niego linkiem. Przy obszarze wskazujecie, kto dba o treść, kto sprawdza zmiany i kiedy ostatnio potwierdzono jej aktualność. Nazwy plików i liczba dokumentów zależą od projektu — wykorzystajcie to, co już macie.

Opis działania systemu i instrukcje utrzymania zbierzcie w dokumentacji operacyjnej. Playbook prowadzi do niej linkiem — określa, kto ją uzupełnia i kiedy.

Opiszcie konkretnie codzienną pracę

W playbooku zapisałem też praktyczne zasady organizacji. Możecie potraktować je jako przykłady do dopasowania:

• Jeden główny temat na osobę. Wiadomo, co ktoś dowozi; pomoc innym i przegląd kodu mieszczą się obok tego. Pilny temat wymaga decyzji, co odkładamy.
• Krótka informacja na bieżąco. Co zrobiłem, co robię dalej, co mnie blokuje i kiedy spodziewam się skończyć. Ustalcie miejsce i rytm takiej wiadomości.
• Pokaz, gdy wynik jest gotowy. Nie trzeba czekać na duże spotkanie, żeby zebrać uwagi i przyjąć małą zmianę.
• Sprawdzenia dobrane do ryzyka. Poprawka tekstu, zmiana obliczeń i awaria produkcji potrzebują innego przebiegu. Zapiszcie, kto decyduje i jakie sprawdzenie jest potrzebne; po pilnej naprawie uzupełnijcie ustalenia.

Zacznijcie od porównania dokumentu z dzisiejszą pracą. Sama obecność zasady w starym playbooku nie znaczy, że nadal obowiązuje. Zakres i postęp pojedynczej zmiany pozostają w zadaniu oraz planie projektu.

Ustalcie, gdzie jest co

U mnie Jira służy do prowadzenia pracy, Confluence do ustaleń, GitHub i CodeRabbit do kodu i jego przeglądu, a Google Chat do bieżącej komunikacji. Portal wdrożeń pokazuje wersje, a UptimeRobot pomaga zauważyć niedostępność. To nasz zestaw — w waszym zespole narzędzia mogą być inne.

W playbooku zbierzcie linki do zadań, dokumentacji, kodu, rozmów, roadmapy i celów kwartalnych. Przy każdym dopiszcie jedno zdanie: po co tu zaglądamy. Nowa osoba ma wiedzieć, gdzie zacząć.

Przykład: na czacie ustalacie zmianę działania funkcji. Osoba prowadząca dopisuje ustalenie do zadania. Jeśli zmienia się reguła produktu, aktualizuje też jej opis w Confluence. Na czacie zostaje link do tego zapisu. Status zadania sprawdzacie w Jira, a plan opisuje kolejne kroki — nie musicie odtwarzać ustaleń z historii rozmów.

Przygotujcie lub uaktualnijcie playbook

W pliku znajdziecie tabele odpowiedzialności, rytm pracy, przykładowe zadanie w Jira, zasady demo i przeglądu oraz wzory wiadomości do zespołu. Przykłady są wypełnione dla fikcyjnego produktu; obok jest miejsce na wasze ustalenia.

Pobierzcie plik i dołączcie go do rozmowy w projekcie. Wskażcie istniejący playbook i inne ustalenia, jeśli je macie. Agent porówna je z szablonem, pomoże wypełnić tabele i zapyta o braki. Zespół decyduje, które propozycje stają się zasadami.

Pomóż nam przygotować lub uaktualnić playbook całego zespołu. Przeczytaj załączony szablon i nasze obecne ustalenia: [linki, jeśli są]. Korzystaj tylko z dozwolonych źródeł. Najpierw zrób mapę obecnych źródeł: zasady produktu, wiedza dziedzinowa, organizacja zespołu, dostarczanie zmian, interfejs oraz zasady techniczne. Wskaż zakres produktu, osobę dbającą o każdy obszar, osobę sprawdzającą zmiany i datę ostatniego potwierdzenia. Nie kopiuj reguł między dokumentami. Zapytaj, które zapisane zasady nadal stosujemy. Potem doprecyzuj priorytety, odpowiedzialności, rytm komunikacji, pracę z agentami, sprawdzenia dobrane do ryzyka oraz wydania i utrzymanie. Oddziel potwierdzone ustalenia od niezweryfikowanych zapisów i nowych propozycji. Wskaż źródła, sprzeczności i braki; pytaj o nie po jednym temacie. Nie wymyślaj ról ani procedur za nas. Jeśli playbook już istnieje, przygotuj poprawki do niego zamiast drugiego dokumentu. Pokaż wersję do wspólnego omówienia. Ustal z nami, kto będzie ją aktualizował i kiedy wracamy do zasad. Nie zmieniaj dokumentów zespołu ani konfiguracji narzędzi przed uzgodnieniem zmian.

Sprawdźcie, czy da się według niego pracować

Dajcie playbook drugiej osobie. Niech znajdzie, kto ustala priorytety, gdzie zadać pytanie, jakie zasady obowiązują agenta i kto reaguje na problem po wydaniu. Potem prześledźcie jedno niedawne zadanie: czy rzeczywisty przebieg zgadza się z opisem?

Wynik: jeden punkt wejścia do zasad zespołu i produktów, zrozumiałe odpowiedzialności oraz osoby dbające o aktualność poszczególnych obszarów. Zadanie służy do sprawdzenia zasad; sam playbook obejmuje codzienną współpracę całego zespołu.