Wiesz o tym, że warto wyciągać wnioski ze swoich porażek i sukcesów, prawda? Nie raz pewnie przeszło Ci przez myśl coś w stylu “czemu znowu robimy ten sam błąd?” Albo “co mogę zrobić, aby następnym razem było lepiej?”. Post-mortem to dobre narzędzie do oceny projektów, które może Ci pomóc wyciągnąć z nich wnioski na przyszłość.
Post-mortem jest po prostu sesją, wydarzeniem czy spotkaniem, w ramach którego zespoły mogą oceniać swoją pracę w projektach. Sprawdzają co im poszło dobrze, a co źle, szukają wniosków i usprawnień na przyszłość. Najczęściej ocenia się zakończone projekty, ale w zależności od długości ich trwania itp. warto pokusić się o ocenianie etapów – po to, aby nie obudzić się z setką problemów po pół roku, gdy była szansa rozwiązywać je dużo częściej. W tym poście opisuję jak warto podejść do tematu post-mortem projektu.
Post-mortem jak wydarzenie
Niech ta sesja nie będzie kolejnym, nudnym spotkaniem, z którego każdy chce wyjść jak najszybciej. Niech jest wydarzeniem! Jej formuła, otoczka i przebieg mogą sprawić, że będzie czymś ciekawym i angażującym. Nie musisz od razu robić z tego misterium, ale wszelkie smaczki podkreślające wagę, urozmaicenia formy, sprawią że ludziom będzie się bardziej chciało. Pomyśl o tym. Zamiast zapowiadać wydarzenie jako “spotkanie podsumowujące projekt” możesz użyć ciekawej nazwy, opisu, poczucia humoru i kreatywności ;-)
Przed zbliżającym się wydarzeniem, postaraj się wytworzyć jakąś formę napięcia, oczekiwania. Ja lubię nie tylko anonsować wydarzenie w formie tekstowej (np. poprzez e-mail), ale w miarę możliwości rozmawiać z uczestnikami w ramach nieformalnych rozmów (np. kawa w kuchni biura) i podrzucać temat. Wówczas jego zapowiedź nie jest tylko kolejnym wpisem w kalendarzu czy skrzynce mailowej, ale zaczyna być “prawdziwa”. Podczas samego spotkania nie idź przez nie z agendą w ręku, odznaczając tylko kolejne punkty, które poruszasz – Twoja energia udzieli się też innym, więc Ty też musisz je tratować jak wydarzenie!
Zwlekanie to zło
Najlepiej nie czekać z takim wydarzeniem długo tylko zrobić je bezpośrednio po zakończeniu projektu, wręcz wpisując je w harmonogram. Niektóre projekty potrafią trwać miesiącami. W zależności od długości jego trwania może okazać się, że trzeba je zrobić także w trakcie realizacji, np. podsumowując jakieś etapy. Zastanów się nad tym.
Ja preferuję takie wydarzenia co 2-3 tygodnie. Wzorując się na zdarzeniach w Scrumie – raz na miesiąc to maksymalny odstęp czasowy między takimi punktami. Dużo zależy od tego czy zespół miał okazje do usprawnień w trakcie trwania projektu czy nie, czas trwania itd.
Przed samym wydarzeniem – ankieta to jest to
Jeśli przed wydarzeniem, nie będzie czasu i przestrzeni w głowach uczestników na refleksję to wszelkie pomysły podczas spotkania mogą być jeszcze niedojrzałe, nieprzetrawione, a samo spotkanie mniej poukładane i przez co mniej owocne. Czasem może Ci na takiej świeżości zależeć co też jest super, gdy potrafisz tym świadomie zarządzać. Ja jednak częściej wolę przygotować odpowiednią ankietę, której wyniki omówimy wspólnie, komentując, zadając pytania itd. To też dobre rozwiązanie dla zespołów rozproszonych – skraca czas spotkań i sprzyja zdobyciu szerszej wiedzy przed sesją.
Taka ankieta nie tylko pozwoli przygotować treść wydarzenia i lepiej się przygotować. Pomoże też wskazać uczestnikom obszary, o których być może ktoś nie pomyślałby nie widząc danego pytania w ankiecie. Powinna być możliwie krótka i treściwa – lubię tworzyć jak najwięcej pytań, które pozwalają dany element ocenić w skali liczbowej. To znacznie ułatwia obróbkę wyników i wszelkie podsumowania (średnia, mediana itp.). Jednak trzeba zostawiać też opcje wypowiedzi otwartej. Większość ankiet, które przygotowuję wypełnione może zostać w maksymalnie 3-5 minut. Każdy powinien zatem znaleźć ten czas między kolejnymi zadaniami :)
Etapy i ważne elementy projektu w post-mortem jako nawigacja
Projekty IT mają swoje etapy – np. planowanie, realizacja, wdrożenie. Ponadto można też na nie patrzeć pod kątem różnego rodzaju interakcji i działań (np. współpraca z partnerem zewnętrznym, wsparcie wewnątrz zespołu oraz od naszej firmy). Jeśli się nad tym zastanowisz to pomoże Ci to przygotować ankietę oraz agendę.
O co mi chodzi, konkretnie? Ja lubię te etapy i elementy kluczowe wykorzystywać do przygotowania ankiety, która potem jest bazą agendy. Układam je w pewien ciąg narracyjny, który pozwala przejść przez ankietę jak przez logiczną całość. Tak samo robię ze spotkaniem. Zatem pierwsze pytania dotyczą chwil przed rozpoczęciem kodowania – pytam o wszelkie burze mózgów, sesje pielęgnacyjne, planowanie itd., które poprzedziły kodowanie. Następnie pytam już o bezpośredni proces wytwórczy. Potem jak przebiegało wdrożenie itd. Gdzieś w tym wszystkim znajduję miejsce na tematykę wsparcie od firmy dla zespołu, jak ocenia interakcje z klientem zewnętrznym gdy takowy brał udział w projekcie, jak ocenia wsparcie wewnątrz zespołu itp.
Niespodziewany atak na problemy
Znasz już problemy. Wiesz nawet co z nimi zrobić. To na co czekasz? :) Działania, które tylko można podjąć należy podjąć od razu po wydarzeniu. Jeśli zatem trzeba omówić temat z jakimś menadżerem to nie za 2-3 tygodnie, ale np. następnego dnia. Każdy dzień zwłoki to rozmywanie się problemów, wciąganie się ludzi w nowe i kolejne straty tej energii, o którą tak dzielnie cały zespół walczył na sesji post-mortem. Jeśli dasz radę to w rozwiązywanie problemów wciągaj także innych członków zespołu, niezależnie od roli jaką pełnisz – oni też mogą pomóc usuwać przeszkody, ustanawiać nowe standardy, utrwalać dobre praktyki. To tylko sprzyja samoorganizacji i wzmacnia relacje.
Post-mortem nie tylko dla samego zespołu
Bardzo łatwo wpaść w tę pułapkę – omówić temat projektu tylko z samym zespołem, który go wykonywał, w ramach ścisłego grona osób zaangażowanych w codzienną pracę. Co jednak z otoczeniem? Jak pracę oceniają interesariusze, menadżerowie, klienci, działy zależne?
Zespół sobie poradził z projektem, wdrożył go bez błędów? Jednak np. w ogóle nie komunikował terminów wdrożeń, zależności z innymi zespołami itd. przez co doszło do kilku nerwowych sytuacji, a Biuro Obsługi Klienta dowiedziało się od klienta (a nie z wew. firmy) o nowej funkcjonalności. Warto wiedzieć jak pracę oceniają kierownicy, menadżerowie, klienci zewnętrzni, inne zespoły itd. Dzięki temu można stale podnosić jakość wykonywanej pracy. Co z tego, że zespół doskonale pracuje z kodem skoro nie potrafi pracować z otoczeniem? Uwzględnimy także szersze opinie, może takie, które pokażą nam coś o czym sami byśmy nie zdawali sobie sprawy.
Poza tym…
Coś o czym jeszcze warto pamiętać to agenda spotkania (i jego cel). Nie musi być szczegółowa, ale uporządkuje je i każdy będzie wiedział jakie są jego ramy. Agenda jest zawsze sprzymierzeńcem moderatorów spotkań, szczególnie w sytuacjach gdy dyskusje schodzą na poboczne tematy ;-)
Po sesji wracamy do biurek i do pracy. Dobra sesja pójdzie w zapomnienie dość szybko. Z tego tytułu lubię robić podsumowanie, umieścić je gdzieś na WIKI i podesłać uczestnikom. Warto po prostu, żeby każdy kto wziął udział w spotkaniu wiedział że takie podsumowanie jest i gdzie go szukać. Potem przed kolejnymi sesjami czy w codziennych dyskusjach można się do nich odnosić. Lubię także wracać do nich, niezależnie od toczących się projektów, gdy widzę ryzyko wystąpienia jakiegoś problemu czy inną sytuację, która pozwala posłużyć się takimi lekcjami.
Kilka słów na koniec
Generalnie jeśli pracujesz w sposób zwinny to zapewne znana Ci jest Retrospektywa (np. Sprintu, jak w Scrumie). Najczęściej będzie ona wystarczającym narzędziem wspierającym usprawnienia, naukę na porażkach i sukcesach w zespołach IT. I w sumie jest czymś bardzo zbliżonym do post-mortem. Świadome zespoły, menadżerowie, liderzy powinni w swoim “arsenale” różne narzędzia i korzystać z nich zależnie od okoliczności. Post-mortem jest jednym z nich, przyda się w wielu projektach (nie tylko IT w sumie). Trzymam kciuki, jeśli chcesz go spróbować!
Podziel się opinią w komentarzach.