Szablon post-mortem projektu

Format retrospektywy post-mortem

Przegląd projektu, cele i zakres

Co projekt miał osiągnąć i do kiedy?

Ten temat wyznacza ramy, zanim ktokolwiek zacznie cokolwiek oceniać. Poproś o pierwotny cel, uzgodniony zakres, harmonogram i kryteria sukcesu, a także o to, co faktycznie dostarczono w odniesieniu do nich. Przy przeglądzie incydentu wykorzystaj ten temat na oś czasu: co się zepsuło, kiedy to wykryto, kto był zaangażowany i jak problem rozwiązano. W tej kolumnie trzymajcie się faktów, a opinie zostawcie na kolejne tematy. Jeśli ludzie nie zgadzają się nawet co do tego, jakie były cele czy kryteria sukcesu, ta różnica zdań sama w sobie jest wnioskiem, który warto zapisać.

Co poszło dobrze

Które sukcesy i procesy warto powtórzyć?

Zespoły przelatują przez ten temat, zwłaszcza po trudnym projekcie lub stresującym incydencie, więc zadbaj o czas na niego. Szukasz praktyk wartych powtórzenia, a nie komplementów; na podziękowania jest osobny temat na końcu. Gdy ktoś wpisuje pochwałę, zapytaj, co konkretnie sprawiło, że to zadziałało, aby dało się to wykorzystać ponownie. Zwracaj uwagę na sukcesy, które wynikały z indywidualnego heroizmu, i nazywaj je ryzykiem.

Co nie poszło dobrze

Gdzie utknęliśmy, co się zepsuło, jakich celów nie osiągnęliśmy?

To tutaj kryje się najwięcej nauki, więc zanim zaczniecie, powiedz na głos zasadę braku obwiniania: analizujecie systemy i decyzje, a nie ludzi. Proś o konkrety zamiast ogólnego narzekania. Z hasłem „komunikacja była zła” nie da się nic zrobić, ale z „o zmianie terminu dowiedzieliśmy się z rozmowy na korytarzu” już tak. Korzystaj z głosowania, aby dyskusja nie rozlała się na każdą irytację z ostatnich trzech miesięcy.

Analiza przyczyn źródłowych

Dlaczego coś poszło nie tak, a nie tylko że poszło?

Opcjonalny przy prostym przeglądzie projektu, niezbędny przy incydencie. Weź problemy z największą liczbą głosów z poprzedniego tematu i pytaj „dlaczego”, dopóki nie dojdziesz do warunku, a nie do osoby: brakującego zabezpieczenia, niejasnego właściciela, presji czasu, założenia, którego nikt nie sprawdził. Dobrze sprawdza się tu metoda 5 Why, podobnie jak pytanie, co sprawiło, że błędne działanie wydawało się wtedy rozsądne. Zatrzymaj się, gdy dojdziecie do czegoś, co faktycznie możecie zmienić, a czynniki sprzyjające zapisuj oddzielnie od bezpośredniego wyzwalacza.

Wyciągnięte wnioski

Jakie lekcje zabieramy ze sobą dalej?

To jest to „i co z tego”, które zamienia obserwacje w wiedzę do ponownego wykorzystania. Dopracowujcie każdy pomysł, aż wskaże konkretne zachowanie, wyzwalacz lub zabezpieczenie, które będzie miało sens także w następnym projekcie. Oddziel to, co zespół może zmienić sam, od tego, co trzeba przekazać menedżerowi lub innej grupie, i bądź szczery co do tej drugiej listy. Zapisuj każdy wniosek tak, aby osoba spoza zespołu mogła go przeczytać w wyeksportowanym raporcie i zrozumieć bez Twoich wyjaśnień.

Działania, właściciele i terminy

Kto robi co i do kiedy?

Post-mortem bez przypisanych działań się nie liczy, więc zarezerwuj na ten temat odpowiednio dużo czasu, zamiast upychać go w ostatnich dwóch minutach. Zamień wnioski z największą liczbą głosów w kilka konkretnych działań, każde z imiennie wskazanym właścicielem i terminem zapisanym w TeamRetro, aby wróciły na kolejnej sesji. Dwa lub trzy działania z dobrze określonym właścicielem są lepsze niż dziesięć życzeniowych. Jeśli działanie należy do kogoś spoza zespołu, ustalcie, kto i do kiedy mu je przekaże.

Docenienie zespołu i podziękowania

Kto zasługuje na uznanie, zanim zamkniemy temat?

Zakończ na ludziach, nie na problemach. Poproś każdego, aby wskazał konkretną osobę i konkretną rzecz, którą zrobiła; to znaczy znacznie więcej niż ogólne podziękowania i sprawdza się nawet po trudnym projekcie. Najbardziej liczy się to wtedy, gdy przegląd był ciężki, bo przypomina zespołowi, że analizowanie porażki to nie to samo co wzajemne obwinianie się. Niech to będzie krótkie: przeczytaj kilka podziękowań na głos, a resztę zostaw w wyeksportowanym raporcie.

Kiedy należy skorzystać z niniejszego przeglądu retrospektywnego

• Projekt, wdrożenie, migracja lub kampania właśnie się zakończyły i chcesz przeprowadzić uporządkowany przegląd, a nie nieformalną rozmowę, która szybko pójdzie w zapomnienie
• Incydent, awaria lub nieudane wydanie wymagają post-mortem bez szukania winnych, obejmującego oś czasu, przyczyny źródłowe i działania zapobiegawcze
• Długotrwały program zakończył etap i chcesz zebrać wnioski, póki szczegóły są jeszcze świeże
• Zespół interdyscyplinarny się rozwiązuje i to ostatnia okazja, by omówić wspólną pracę i docenić osoby, które się do niej przyczyniły, zanim wszyscy przejdą do nowych zadań
• Coś poszło nieoczekiwanie dobrze i chcesz zrozumieć dlaczego, aby móc to powtórzyć, zamiast przypisywać to szczęściu

Proponowane pytania lodołamacze

• Jednym słowem: jakie odczucia towarzyszyły Ci w samym środku tego projektu lub incydentu?
• Gdyby można było wysłać jedno zdanie rady sobie samemu w pierwszym dniu, jak by brzmiało?

Czy chciałby Pan/Pani, aby Państwa zespół wykonał ćwiczenie rozgrzewkowe, a nie tylko odpowiadał na pytania na głos? Przejrzyj bezpłatne lodołamacze →

Pomysły i wskazówki dotyczące spotkania retrospektywnego

• Przeprowadź spotkanie w ciągu tygodnia lub dwóch od zamknięcia projektu lub rozwiązania incydentu. Pamięć szybko blednie, a wraz z nią znikają przydatne szczegóły
• Na początku przypomnij zasadę braku obwiniania. Analizujecie decyzje, systemy i presję, a nie szukacie kogoś, kogo można pociągnąć do odpowiedzialności
• Poświęć kilka minut na uzgodnienie przeglądu projektu, zanim pojawią się opinie. Wspólne ramy sprawiają, że sesja nie zamienia się w spór o to, jaki w ogóle był cel
• Przy sprawnie przeprowadzonym projekcie pomiń lub skróć analizę przyczyn źródłowych, a przy incydentach, gdzie chodzi o zapobieganie, poświęć jej więcej czasu
• Ustal priorytety przez głosowanie i nie kończ spotkania bez właścicieli i terminów dla najważniejszych działań, bo inaczej wnioski pozostaną teorią
• Przynieś działania z poprzedniego post-mortem i omów je na początku. Nic tak nie poprawia realizacji jak świadomość, że zostanie ona sprawdzona

Najczęściej zadawane pytania