Retrospektywa Pre-Mortem

Wyobraź sobie porażkę projektu i znajdź jej przyczyny, póki jest czas działać

Zapraszamy do obejrzenia tej retrospektywy na żywo

Nie udało się. Dlaczego?

Jest pół roku później, a projekt się nie udał. Opisz każdy powód tak, jakby już się wydarzył.

Polegaliśmy na sandboksie dostawcy płatności i nigdy nie przetestowaliśmy limitów produkcyjnych. Ruch w dniu premiery położył proces płatności.
Tylko Priya rozumiała skrypty migracji danych. W trzecim miesiącu poszła na urlop i wszystko stanęło.
Dział prawny przejrzał regulamin dwa tygodnie przed premierą i musieliśmy przebudować proces zbierania zgód.
Wczesne sygnały ostrzegawcze

Co zauważylibyśmy jako pierwsze, gdyby to zaczęło się dziać?

Odpowiedzi na zgłoszenia do supportu dostawcy przychodzą po ponad dwóch dniach.
Ta sama osoba jest oznaczana do review każdego pull requesta z migracją.
W trakcie sprintu pojawiają się nowe zadania z dopiskiem „szybka prośba od sprzedaży” w opisie.
Jak temu zapobiec

Co możemy zrobić już teraz, żeby do tego nie dopuścić?

W drugim sprincie przeprowadzić test obciążeniowy na środowisku produkcyjnym dostawcy, zanim zaczniemy na nim budować.
Dobrać kogoś do pary z Priyą przy skryptach migracji i do końca miesiąca spisać runbook.
Zarezerwować przegląd prawny procesu zgód na etapie projektowania, a nie po wdrożeniu.
Właściciele i kolejne kroki

Kto odpowiada za każde z najważniejszych ryzyk i do kiedy?

Marco odpowiada za test obciążeniowy u dostawcy, termin: koniec drugiego sprintu.
Zajmę się migracją w parze z Priyą i do 15. opublikujemy runbook.
Dana zarezerwuje przegląd prawny procesu zgód przed zatwierdzeniem projektu w przyszły piątek.

Czym jest retrospektywa pre-mortem?

Pre-mortem to sesja poświęcona ryzyku, którą przeprowadza się na starcie projektu, zanim zakres, terminy i budżet zostaną ostatecznie ustalone. Zespół wyobraża sobie konkretną przyszłość: jest pół roku później, a projekt zakończył się porażką. Każdy zapisuje, dlaczego tak się stało, tak jakby porażka już nastąpiła. Technikę opracował psycholog Gary Klein, który opisał ją w artykule „Performing a Project Premortem” opublikowanym w Harvard Business Review w 2007 roku. Opiera się ona na badaniach nad „prospektywnym spojrzeniem wstecz” (ang. prospective hindsight), które wykazały, że wyobrażenie sobie, że zdarzenie już się wydarzyło, pomaga ludziom wskazać bardziej konkretne jego przyczyny. Cała siła tkwi w sposobie postawienia pytania. Zapytaj zespół „co może pójść nie tak?”, a usłyszysz uprzejme, ogólnikowe odpowiedzi w rodzaju „rozrastający się zakres” czy „problemy z komunikacją”. Zapytaj „dlaczego się nie udało?”, a ludzie wskażą prawdziwe przyczyny: API dostawcy, którego nikt nie przetestował pod obciążeniem, interesariusza, z którym nikt się nie skonsultował, jedynego inżyniera, który ma całą wiedzę w głowie. Przyjęcie porażki za pewnik sprawia też, że można bezpiecznie wyrazić wątpliwości, które podczas optymistycznego kickoffu brzmiałyby negatywnie albo nielojalnie. Ten szablon pre-mortem prowadzi przez cztery kroki w TeamRetro. Najpierw wypisujecie powody, dla których projekt się nie udał. Potem określacie wczesne sygnały ostrzegawcze, uzgadniacie działania zapobiegawcze, a na koniec każde z najważniejszych ryzyk dostaje właściciela i termin. Ostatni krok jest najważniejszy. Ryzyko bez właściciela i terminu zwykle idzie w zapomnienie jeszcze przed końcem pierwszego tygodnia. Korzystajcie z anonimowych pomysłów, żeby staż i stanowisko nie wpływały na to, co ludzie piszą, a w zespołach rozproszonych zbierajcie pomysły asynchronicznie przez jeden dzień i spotykajcie się tylko po to, by zagłosować i przypisać właścicieli.

Format retrospektywy pre-mortem

Nie udało się. Dlaczego?

Jest pół roku później, a projekt się nie udał. Opisz każdy powód tak, jakby już się wydarzył.

Ta kolumna to serce pre-mortem. Jasno nakreśl sytuację: projekt się zakończył, nie udał się i wszyscy o tym wiedzą. Poproś, by pisać w czasie przeszłym („Nie zdążyliśmy z premierą, bo...”), ponieważ takie ujęcie daje bardziej konkretne przyczyny niż spekulowanie o tym, co mogłoby pójść nie tak. Pomysły powinny być anonimowe, żeby głosy osób na wyższych stanowiskach nie narzucały kierunku. Daj 8–10 minut na ciche pisanie, zachęcaj do jednego powodu na pomysł, a potem pogrupuj podobne pomysły i zagłosujcie, by wyłonić najważniejsze ryzyka do dalszej pracy.

Wczesne sygnały ostrzegawcze

Co zauważylibyśmy jako pierwsze, gdyby to zaczęło się dziać?

Wczesne sygnały ostrzegawcze zamieniają mgliste obawy w rzeczy, które zespół może obserwować. Przy każdym z najważniejszych ryzyk z pierwszej kolumny zapytaj, jaki byłby pierwszy zauważalny sygnał: wskaźnik, przegapiony punkt kontrolny, powtarzający się wzorzec na standupach. Naciskaj na sygnały konkretne i mierzalne. „Spada morale” trudno śledzić. „Dwa sprinty z rzędu z ponad 30% przeniesionych zadań” łatwo wychwycić. To właśnie te sygnały będą obserwować właściciele ryzyk.

Jak temu zapobiec

Co możemy zrobić już teraz, żeby do tego nie dopuścić?

Tu zespół przechodzi od obaw do działania. Skup się wyłącznie na ryzykach z największą liczbą głosów, zwykle od trzech do pięciu. Przy każdym zapytaj, co zespół może zrobić w tym tygodniu lub miesiącu, żeby zmniejszyć prawdopodobieństwo albo skutki. Stawiaj na małe, konkretne kroki zamiast dużych zmian w procesach. Jeśli pomysł wymaga zgody lub budżetu, zanotuj, kogo trzeba o to poprosić. Utrzymuj praktyczny ton; celem jest krótsza lista działań, które ludzie faktycznie wykonają.

Właściciele i kolejne kroki

Kto odpowiada za każde z najważniejszych ryzyk i do kiedy?

Ta kolumna to sedno całej sesji. Każde z najważniejszych ryzyk potrzebuje jednego, imiennie wskazanego właściciela i terminu, inaczej zebrane dziś obawy wyparują, zanim skończy się pierwszy tydzień. Właściciele nie muszą sami eliminować ryzyka; odpowiadają za obserwowanie sygnałów ostrzegawczych i dopilnowanie, żeby działanie zapobiegawcze zostało wykonane. Zapisz każde z nich jako zadanie w TeamRetro, żeby przechodziło do kolejnych retrospektyw, i zaplanuj krótki przegląd postępów przy pierwszym kamieniu milowym.

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

  • Na starcie nowego projektu, wprowadzenia produktu na rynek lub dużej inicjatywy, zanim zakres, terminy i budżet zostaną ostatecznie ustalone.
  • Przed ważnym kamieniem milowym, takim jak migracja, uruchomienie produkcyjne czy podpisanie umowy, gdy niespodzianka na ostatniej prostej byłaby kosztowna.
  • Gdy zespół jest wyjątkowo optymistycznie nastawiony do planu, a cichsze osoby mogą zatrzymywać wątpliwości dla siebie.
  • Na początku współpracy z nowym dostawcą, partnerem lub zespołem międzydziałowym, którego zależności nie są jeszcze dobrze znane.
  • Na początku nowego kwartału lub inkrementu programu (PI), by sprawdzić odporność planu, zanim zespół się do niego zobowiąże.

Proponowane pytania lodołamacze

  • Który plan, w pracy albo w życiu, najbardziej zapadł ci w pamięć, bo poszedł nie tak? Jaki był pierwszy sygnał ostrzegawczy?
  • Gdyby ten projekt był filmem, jakiego gatunku byłaby wersja z porażką?

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ź pre-mortem na starcie projektu, zanim zobowiązania zostaną przypieczętowane. Nigdy nie rób tego w środku kryzysu, kiedy zespół musi rozwiązywać problemy, a wyobrażanie sobie porażki tylko dokłada niepokoju.
  • Dbaj o anonimowość pomysłów. Jeśli nazwiska są widoczne, obawy osoby z najwyższym stanowiskiem nadają ton, a reszta pisze tylko zdawkowe przytaknięcia.
  • Pilnuj czasu przeszłego w pierwszej kolumnie. Pytanie „Dlaczego się nie udało?” daje bardziej konkretne i realistyczne ryzyka niż „Co może pójść nie tak?”, więc delikatnie przeformułowuj pomysły, które wracają do trybu przypuszczającego.
  • Zanim przejdziecie do zapobiegania, zagłosujcie, by zawęzić listę do trzech, najwyżej pięciu najważniejszych ryzyk. Próba zajęcia się każdym pomysłem rozprasza siły zespołu i w efekcie nic nie zostaje zrobione.
  • Nie kończ sesji, dopóki każde z najważniejszych ryzyk nie ma jednego właściciela i terminu. Bez tego zebrane ryzyka pójdą w zapomnienie przed końcem pierwszego tygodnia.
  • W zespołach rozproszonych postaw na tryb asynchroniczny: zbierajcie pomysły przez jeden dzień w różnych strefach czasowych, a potem spotkajcie się na 30 minut tylko po to, by pogrupować, zagłosować i przypisać właścicieli.

Najczęściej zadawane pytania

Czym różni się pre-mortem od post-mortem?
Post-mortem odbywa się po zakończeniu lub porażce projektu i analizuje, co faktycznie poszło nie tak. Pre-mortem odbywa się przed rozpoczęciem pracy i zakłada porażkę z góry, żeby zespół mógł jej zapobiec, póki jest jeszcze czas na działanie.
Kto stworzył technikę pre-mortem?
Pojęcie pre-mortem wprowadził psycholog Gary Klein, który opisał je w artykule „Performing a Project Premortem” w Harvard Business Review z 2007 roku. Technika czerpie z badań pokazujących, że wyobrażenie sobie, że dany wynik już nastąpił, pomaga wskazać bardziej konkretne jego przyczyny.
Ile trwa pre-mortem?
Większość sesji pre-mortem trwa 45–60 minut dla zespołu liczącego od pięciu do dziesięciu osób. W wariancie asynchronicznym spotkanie na żywo można skrócić do około 30 minut, bo pomysły są zebrane jeszcze przed rozmową.
Kiedy przeprowadzić pre-mortem?
Na starcie projektu, zanim zobowiązania takie jak zakres, terminy i budżet zostaną przypieczętowane. Unikaj przeprowadzania go w środku kryzysu, gdy zespół musi skupić się na rozwiązywaniu realnych problemów.
Dlaczego pomysły w pre-mortem powinny być anonimowe?
Gdy nazwiska są widoczne, ludzie zwykle powtarzają obawy osoby z najwyższym stanowiskiem w zespole. Anonimowe pomysły ujawniają ryzyka, którymi ludzie naprawdę się martwią, także te dotyczące decyzji kierownictwa.
Czy pre-mortem można przeprowadzić asynchronicznie?
Tak. Zespoły rozproszone mogą zbierać pomysły w TeamRetro przez jeden dzień, a potem spotkać się tylko po to, by je pogrupować, zagłosować na najważniejsze ryzyka i przypisać im właścicieli z terminami.

Powiązane szablony

Przegląd po działaniu (After Action Review)

Porównaj plan z rzeczywistością i zapisz wyciągnięte wnioski

Półroczny przegląd celów

Przejrzyjcie cele w połowie roku i ustalcie kurs na drugie półrocze

Retrospektywa osi czasu

Odtwórzcie kluczowe wydarzenia projektu i nastroje zespołu na każdym etapie

Planowanie kick-offu projektu

Uzgodnijcie cele, ryzyka i kamienie milowe przed startem prac.

Czy są Państwo gotowi do przeprowadzenia tej retrospektywy?Zapraszamy do obejrzenia tej retrospektywy na żywo