Retrospektywa projektu: jak zamienić dobre uwagi w zmianę sposobu pracy

Po projekcie wszyscy wiedzą, że następnym razem trzeba „lepiej komunikować”. Po następnym projekcie wiedzą to jeszcze lepiej. Retrospektywa ma przerwać ten obieg dobrych intencji: odtworzyć konkretne zdarzenia, wybrać zmianę i sprawdzić ją w kolejnej pracy. Kolorowe karteczki mogą pomóc, ale same nie mają uprawnień do zmiany procesu. Potrzebują człowieka, zadania i momentu odbioru.

Retrospektywę rozumiemy tu jako rozmowę o sposobie wykonania pracy oraz wynikającym z niej usprawnieniu. Poniższy warsztat jest własną propozycją dla projektu usługowego. Nie zakłada, że firma pracuje w Scrumie, ani nie zastępuje odbioru produktu, wyjaśnienia incydentu czy oceny konkretnej osoby. Przykłady są hipotetyczne i służą pokazaniu decyzji.

Ustal, co spotkanie ma zmienić

Nazwij zakres: konkretny etap, publikację albo współpracę kilku ról. Nie próbuj w jednym spotkaniu rozwiązywać całej kultury organizacyjnej. Uczestnicy powinni wiedzieć, których zdarzeń dotyczy rozmowa i na jakie elementy mają wpływ. Jeśli ustalenia wymagają decyzji spoza zespołu, wskaż drogę ich przekazania.

Oddziel ocenę rezultatu od oceny sposobu pracy. Strona mogła spełnić wymagania, choć publikacja wymagała nieplanowanej nocnej interwencji. Projekt mógł też przebiec spokojnie, a nie rozwiązać problemu odbiorcy. Obie obserwacje są istotne, lecz prowadzą do różnych pytań. Odbiór strony nie zastępuje rozmowy o tym, jak zespół dotarł do tego wyniku.

Przygotuj ślad zdarzeń, zanim zaczniesz ocenianie

Zbierz ważne daty, wersje materiałów, punkty zatwierdzenia i przykłady przekazań. Nie potrzebujesz kompletnego archiwum każdej wiadomości. Wybierz elementy związane z omawianym problemem. Jeśli twierdzenie dotyczy opóźnienia, sprawdź, kiedy materiał był gotowy i na jaką decyzję czekano. Sama pamięć uczestników może pomijać zależności, które wówczas były oczywiste.

W rejestrze decyzji projektowych zachowuje się powody wyborów. Wykorzystaj go, żeby odróżnić błąd wykonania od świadomie przyjętego ograniczenia. Nie oceniaj starej decyzji tak, jakby zespół znał późniejszy wynik. Sprawdź, co było wiadomo wtedy i jaki warunek miał uruchomić ponowną ocenę.

Zacznij od obserwacji, którą da się rozpoznać

„Komunikacja była słaba” może oznaczać brak właściciela, zbyt późny komentarz, niejasną nazwę wersji albo sprzeczną decyzję. Poproś o zdarzenie: co miało się wydarzyć, co się wydarzyło i jaki był skutek. Dzięki temu rozmowa dostaje materiał do pracy. Przymiotnik sam nie podpowie, którą instrukcję trzeba poprawić.

Zapisuj również rzeczy, które pomogły. Jeżeli krótki podgląd przed publikacją wykrył brak, warto zachować ten krok. Retrospektywa nie musi być przeglądem wyłącznie rozczarowań. Ustal, co powtórzyć, co zmienić i co przestało być potrzebne. W przeciwnym razie kolejny projekt może niechcący usunąć działającą praktykę razem ze zbędną procedurą.

Oddziel inspirację Scrumem od własnego warsztatu

Scrum Guide z listopada 2020 opisuje Sprint Retrospective jako planowanie sposobów poprawy jakości i skuteczności. Zespół przygląda się ludziom, współpracy, procesom i narzędziom, a istotne ulepszenia podejmuje możliwie szybko. To opis konkretnego podejścia. Nasz przegląd projektu czerpie z tej idei, ale nie oznacza, że firma realizuje cały Scrum.

Nie przepisuj nazw wydarzeń bez ich znaczenia. Pokaz wykonanej pracy dla odbiorców i rozmowa zespołu o sposobie działania mają różne cele. Można je powiązać, lecz warto zapewnić miejsce na niewygodną obserwację bez konieczności jednoczesnego prowadzenia prezentacji sprzedażowej. Wybierz formę odpowiednią do problemu, osób i możliwości wykonania późniejszej zmiany.

Zadbaj o możliwość zgłoszenia odmiennej perspektywy

Nie zaczynaj od oceny osoby najwyżej postawionej w hierarchii. Uczestnicy mogą wtedy dopasować wspomnienia do przedstawionej interpretacji. Daj chwilę na samodzielne zapisanie obserwacji, a potem porównuj zdarzenia. Prowadzący powinien dopytywać o warunki i skutki, zamiast od razu rozdzielać racje.

W małym zespole nie obiecuj pełnej anonimowości, jeśli nie możesz jej zapewnić. Wyjaśnij sposób użycia notatek, dostęp i granice rozmowy. Jeśli pojawia się sprawa wymagająca odrębnego postępowania, nie próbuj rozwiązywać jej jednym głosowaniem przy tablicy. Warsztat usprawnienia procesu nie nadaje prowadzącemu kompetencji do rozstrzygania każdego rodzaju problemu.

Osobno potraktuj pierwszą rozmowę po zauważeniu bieżącego błędu. Może wymagać szybkiego ustalenia faktów i ochrony odbiorcy pracy; nie należy odkładać tych działań do następnej retrospektywy. Późniejszy przegląd może następnie wyjaśnić, co wymaga zmiany w sposobie pracy.

Znajdź mechanizm, zanim wybierzesz lekarstwo

Załóżmy ćwiczeniowo, że treść strony kilkakrotnie wracała do poprawy tuż przed publikacją. Możliwe przyczyny to brak decyzji o ofercie, oglądanie starej wersji albo niewskazana osoba zatwierdzająca. Każda prowadzi do innego usprawnienia. Ogólne „wysyłajmy wcześniej” nie naprawi źródła, jeśli nikt nie wie, kto ma podjąć decyzję.

Porównaj kilka podobnych zdarzeń i sprawdź wspólny warunek. Nie zakładaj, że pierwszy zauważony powód wyjaśnia wszystko. Zapisz alternatywne wyjaśnienia przyczyn i dowody potrzebne do ich rozróżnienia. Przy procesach wspieranych przez AI pomocne są zasady odpowiedzialnego działania agentów: zadanie, dostęp i punkt zatwierdzenia warto sprawdzać oddzielnie.

Wybierz niewiele zmian, które naprawdę wykonacie

Lista dwudziestu zaleceń może wyglądać ambitnie i nie zmienić żadnego następnego zadania. Oceń skutek, wysiłek oraz możliwość sprawdzenia. Wybierz jeden lub kilka kroków mieszczących się w realnej pracy zespołu. Liczba zaleceń nie jest miarą jakości spotkania. Ważniejsze, czy uczestnicy potrafią wskazać najbliższą zmianę i jej właściciela.

Atlassian w instrukcji retrospektywy zaleca przypisanie właścicieli oraz terminów działaniom i włączenie ich do zwykłej listy pracy. Korzystamy tu wyłącznie z tego fragmentu praktyki, nie z obietnicy określonej poprawy wyników. Ustalenie powinno otrzymać miejsce, w którym zespół rzeczywiście prowadzi zadania, zamiast czekać na ponowne otwarcie notatki ze spotkania.

Zapisz usprawnienie jako zachowanie do sprawdzenia

„Poprawić komunikację” zamień na konkretny krok. Przykład roboczy: przed przekazaniem tłumaczenia osoba prowadząca wskazuje zatwierdzoną wersję źródła i zakres ostatniej zmiany. Odbiorca potwierdza, że pracuje na tej podstawie. To czynność, którą można zaobserwować. Nie wymaga deklaracji, że od teraz wszyscy będą bardziej uważni.

• Zdarzenie: jaki problem powracał?
• Zmiana: co zrobimy inaczej przy następnej podobnej sprawie?
• Właściciel: kto przygotuje i przeprowadzi próbę?
• Miejsce: gdzie zmieni się instrukcja lub narzędzie?
• Ocena: po czym rozpoznamy użyteczność kroku?
• Przegląd: kiedy zdecydujemy, czy go zachować?

Nie dokładaj automatycznie nowego formularza do każdej trudności. Czasem właściwa zmiana polega na usunięciu pola, połączeniu dwóch zatwierdzeń albo wskazaniu jednego źródła. Procedura też kosztuje czas. Jeśli tworzy więcej pracy niż rozwiązywany problem, powinna umieć przegrać własną próbę użyteczności.

Rozlicz poprzednią zmianę, zanim dopiszesz następną

Na początku kolejnego przeglądu sprawdź los wcześniejszego ustalenia. Czy miało właściciela, dostępny czas i miejsce w planie? Jeśli nikt go nie wykonał, nie dopisuj od razu zalecenia większego zaangażowania. Rozpoznaj przeszkodę. Być może zmiana wymagała decyzji spoza zespołu albo pozostawała sprzeczna z obowiązującą instrukcją. To konkretna zależność do rozstrzygnięcia, nie dowód złej woli wszystkich uczestników.

Oddziel brak wykonania od braku skuteczności. Usprawnienie, którego nie zastosowano, nie zostało jeszcze sprawdzone. Usprawnienie zastosowane bez porównywalnej sytuacji nadal może czekać na ocenę. W notatce zachowaj ten stan. Dzięki temu zespół nie skreśla pomysłu tylko dlatego, że nie zdążył go użyć, ani nie ogłasza sukcesu po samym opublikowaniu nowej procedury.

Jeżeli zadanie stale przegrywa z bieżącą pracą, zmniejsz zakres lub świadomie z niego zrezygnuj. Wybór jednej mniejszej zmiany może być rozsądniejszy niż utrzymywanie pięciu nietkniętych zaleceń. Uzasadnienie zachowaj razem z pierwotnym celem. Kolejna osoba zobaczy wtedy decyzję o priorytecie, a nie tajemniczą listę otwartych spraw, które od dawna udają aktywny plan.

Sprawdź, czy poprawka nie przenosi problemu dalej

Nowy krok może ułatwić pracę jednemu zespołowi i zwiększyć obciążenie drugiego. Jeśli wprowadzasz dodatkowe zatwierdzenie, ustal jego cel, osobę odpowiedzialną oraz dostępność. Obserwuj cały przebieg zadania. Szybsze przekazanie dokumentu nie jest jeszcze skróceniem obsługi, jeśli później dokument czeka w kolejnej kolejce, której nikt nie uwzględnił w przeglądzie.

Zaproś do oceny osoby dotknięte zmianą, choćby do krótkiej rozmowy o konkretnym przypadku. Nie muszą uczestniczyć we wszystkich szczegółach retrospektywy. Powinny zrozumieć nowe zadanie i móc zgłosić ograniczenie. Wspólny wynik jest ważniejszy niż lokalny rekord szybkości. Inaczej usprawnienie przypomina porządkowanie biurka przez przesunięcie wszystkiego na biurko sąsiada.

Zapisz również warunek wycofania poprawki. Jeśli tworzy zbędne oczekiwanie albo nie zmniejsza rozpoznanego problemu, zespół powinien umieć wrócić do prostszej drogi. Nie każda procedura zasługuje na stały pobyt po jednej udanej prezentacji. Retrospektywa może zakończyć się usunięciem kroku, jeśli właśnie to wynika z obserwacji. Ważne, żeby decyzja pozostała sprawdzalna i zrozumiała.

Przećwicz retrospektywę publikacji

W hipotetycznej firmie strona została wdrożona poprawnie, ale zespół sprawdzał formularz na wcześniejszym podglądzie. Przy publicznym odbiorze odkryto inną konfigurację wysyłki. Retrospektywa nie kończy się zdaniem „trzeba testować dokładniej”. Uczestnicy wskazują konkretny moment i brak powiązania sprawdzenia z publikowaną wersją.

Zmiana polega na zapisaniu publicznego adresu oraz identyfikatora wdrożenia przy wyniku próby. Osoba odbierająca potwierdza wiadomość w docelowej skrzynce. Przy kolejnej publikacji zespół sprawdza, czy krok wykonano i czy potrafi odtworzyć jego dowód. To nie gwarantuje braku przyszłych błędów; usuwa rozpoznaną niejasność w konkretnym sposobie odbioru.

Wróć do usprawnienia przy następnej okazji

Przegląd powinien obejmować wykonanie i użyteczność. Czy instrukcję zmieniono? Czy ktoś z niej skorzystał? Czy krok pomógł w sytuacji, dla której powstał? Jeśli nie wystąpił jeszcze podobny przypadek, poczekaj z oceną skuteczności. Zapisz, że zmiana czeka na właściwą próbę, zamiast dopisywać sukces do zakończonego spotkania.

Usprawnienie można opisać jako eksperyment biznesowy. Ustal oczekiwaną obserwację, warunek oceny i możliwość wycofania. Jeśli zespół różnie rozumie samo słowo „gotowe”, zacznij od słownika firmowego. Dodatkowy status nie pomoże, gdy każdy nadaje mu inne znaczenie.

Odbierz zmianę na przykładzie pracy z wiedzą

Załóżmy ćwiczeniowo, że nowy pracownik znalazł dwie sprzeczne instrukcje. Zespół ustala jednego właściciela źródła i dodaje odsyłacz ze starszego dokumentu. Przy wdrażaniu kolejnego pracownika sprawdza, czy osoba bez znajomości historii trafia do właściwej wersji. To osobna próba użyteczności, nie tylko kontrola, czy ktoś dopisał link.

Jeśli nadal wybiera starą instrukcję, wróć do nazwy i miejsca wyszukiwania. Nie kończ rozmowy stwierdzeniem, że przecież poprawka została wykonana. Wykonanie czynności i rozwiązanie problemu to dwa różne wyniki. Retrospektywa powinna pomagać zobaczyć tę różnicę bez rozkręcania następnego projektu poprawy wszystkiego. Czasem potrzebna jest mała korekta tego samego kroku oraz jeszcze jedna spokojna obserwacja.

Zachowaj kontekst i usuń zbędną ceremonię

W notatce pozostaw zdarzenia, wnioski, wybrane działania i sposób przeglądu. Nie zapisuj każdej wypowiedzi, jeśli nie jest potrzebna do celu. Po kilku spotkaniach oceń również samą formę: czy uczestnicy mogą zgłosić problem, czy wybierają wykonalną zmianę i czy do niej wracają. Powtarzający się rytuał bez skutku nie staje się procesem doskonalenia dzięki regularności kalendarza.

Jeśli chcesz przeanalizować przepływ pracy wspieranej przez AI i przygotować usprawnienie do próby, poznaj Aeneia Audit. Przy zakończeniu niepotrzebnego procesu przyda się też plan wycofania automatyzacji. Wniosek ze spotkania ma sens wtedy, gdy następne zadanie rzeczywiście wygląda dzięki niemu inaczej.