Lessons learned: co to jest, jak zebrać wnioski z projektu i wzór

Na koniec projektu zespół siada razem, obkleja ścianę karteczkami i zgadza się: następnym razem wcześniej porozmawiamy z działem IT. Pół roku później startuje kolejny projekt i nikt nie pamięta karteczki. Ten poradnik wyjaśnia, co oznacza lessons learned i czym różni się od podobnych formatów, pokazuje pięć kroków do wniosków, które naprawdę się wykorzystuje, i daje ci pytania oraz wzór do skopiowania.

Lessons learned: co to jest?

Lessons learned (po brytyjsku lessons learnt) to dosłownie „wyciągnięte lekcje”, po polsku najczęściej wnioski z projektu albo wyciągnięte wnioski. Chodzi o doświadczenia z minionych działań, które należy uwzględnić w przyszłych. Project Management Institute definiuje je jako wiedzę zdobytą w trakcie projektu, która pokazuje, jak rozwiązano lub jak należałoby w przyszłości rozwiązywać zdarzenia projektowe, aby poprawić wyniki. Najczęściej używa się jednak angielskiej nazwy.

Bardziej rygorystycznej definicji używają agencje kosmiczne NASA, ESA i JAXA: lesson learned to wiedza lub zrozumienie zdobyte dzięki doświadczeniu, zarówno z sukcesu, jak i z porażki. Żeby się liczyła, musi spełnić trzy warunki:

• Istotna: ma rzeczywisty lub przewidywalny wpływ na pracę.
• Prawdziwa: jest poprawna merytorycznie i technicznie.
• Możliwa do zastosowania: wskazuje konkretne rozwiązanie, proces albo decyzję, które zmniejszają ryzyko błędu lub utrwalają dobry wynik.

Te trzy pytania przydadzą się przy analizie. Pokazują też różnicę wobec dokumentacji projektu: dokumentacja opisuje, co się stało, a lesson learned mówi, co następnym razem zrobisz inaczej. Dlatego to jedna z najprostszych metod zarządzania wiedzą: jest przypięta do terminu, który i tak istnieje, czyli do końca projektu.

Lessons learned, retrospektywa, after action review i post mortem

Wiele zespołów robi lessons learned pod inną nazwą. Formaty różnią się momentem i celem.

Retrospektywa: Scrum Guide opisuje retrospektywę sprintu jako wydarzenie, które go kończy. Zespół sprawdza, jak przebiegł sprint pod względem ludzi, interakcji, procesów i narzędzi, co poszło dobrze, jakie były problemy i czy udało się je rozwiązać. Przy sprincie miesięcznym trwa najwyżej trzy godziny, a najważniejsze usprawnienia wdraża się jak najszybciej.

After action review: metodę opracowała armia Stanów Zjednoczonych. Zaczyna się od porównania zamierzonego i rzeczywistego wyniku. Szukanie winnych jest sprzeczne z jej celem, każdy patrzy na własne działania.

Post mortem: szuka przyczyn porażki lub awarii, podczas gdy retrospektywa omawia zarówno to, co dobre, jak i to, co złe.

Najważniejsza różnica: retrospektywa poprawia pracę tego samego zespołu w następnym sprincie. Lessons learned mają pomóc także osobom, które nie brały udziału w projekcie. Dlatego zapisanie i przechowywanie wniosków jest tu tak ważne.

Kiedy zbierać wnioski z projektu

• Na zamknięcie projektu: klasyczny moment, często jako część raportu końcowego.
• Po etapach i kamieniach milowych: w dłuższych projektach. Asana radzi wysłać ankietę zaraz po zakończeniu projektu lub ważnego etapu, póki wszystko jest świeże w pamięci.
• Na start nowego projektu: tu wnioski się wykorzystuje, a nie zbiera. Wpisz czytanie lessons learned z podobnych projektów do każdego spotkania otwierającego.
• Zanim kluczowa osoba odejdzie z projektu: moment, o którym najczęściej się zapomina. Kto odchodzi w trakcie, zabiera swoją perspektywę, i na spotkaniu zamykającym już jej brakuje.

Lessons learned w projekcie w 5 krokach

Kroki odpowiadają cyklowi, który opisuje też Asana: identyfikacja, dokumentacja, analiza, przechowywanie i wykorzystanie.

1. Zbierz doświadczenia

Dobrze sprawdza się krótka ankieta, a po niej spotkanie. Asana radzi, żeby spotkania nie prowadził menedżer projektu, bo wtedy wszyscy mówią swobodniej. Przy planowaniu pomocny jest poradnik Atlassian o retrospektywie: około 15 minut przygotowania, 60 minut spotkania, od 4 do 8 osób.

2. Zapisz konkretnie

„Poprawić komunikację” to nie wniosek, tylko życzenie. Przydatny wniosek opisuje sytuację, co się stało, dlaczego i co następnym razem będzie inaczej. Na przykład: „W projektach z nowym oprogramowaniem angażować IT w pierwszym tygodniu, bo inaczej nadawanie dostępów opóźnia start”. Zapisz też to, co poszło dobrze. Według definicji NASA, ESA i JAXA sukcesy liczą się tak samo jak błędy.

3. Przeanalizuj i skondensuj

Połącz powtarzające się punkty i sprawdź każdy trzema pytaniami: istotny, prawdziwy, możliwy do zastosowania? Atlassian radzi nie skupiać się na jednorazowych błędach lub sukcesach, które nie wpłyną na dalszą pracę. Celem jest kilka wniosków, które coś zmienią.

4. Przechowuj tam, gdzie inni szukają

Wniosek w czyimś prywatnym folderze jest dla następnego zespołu stracony. Trzymaj lessons learned w jednym stałym miejscu, na przykład w bazie projektów lub na wspólnym dysku, i opisz je tagami: rodzaj projektu, temat, dział.

5. Zastosuj w kolejnym projekcie

Krok, który najczęściej się pomija. Każdy wniosek potrzebuje osoby odpowiedzialnej i miejsca, w którym coś zmieni: listy kontrolnej, szablonu projektu, standardowej procedury operacyjnej albo mapy procesu. Dopiero gdy wniosek trafi tam, gdzie dzieje się praca, zmienia sposób pracy.

Pytania na spotkanie lessons learned

Rdzeń stanowią trzy pytania, które podaje też Asana: Co poszło dobrze? Co poszło źle? Co możemy poprawić? Wariantem z retrospektyw jest metoda 4L: co się zespołowi podobało, czego nie znosił, czego się nauczył i za czym tęsknił. Przy całym projekcie warto pytać głębiej:

• Czy osiągnęliśmy cel? Gdzie wynik odbiega od planu i dlaczego?
• Którą decyzję podjęlibyśmy dziś inaczej?
• Które założenie z początku okazało się błędne?
• Jaką wiedzę miała tylko jedna osoba i gdzie jest teraz zapisana?
• Co następny zespół powinien wiedzieć na samym początku?
• Co z tego przenosimy do szablonów, list kontrolnych lub procesów i kto się tym zajmie?

Wzór raportu lessons learned

Skopiuj tabelę do dokumentu lub arkusza. Nad nią wpisz nazwę projektu, okres, uczestników, datę i osobę prowadzącą. Dwa wiersze to zmyślone przykłady, które pokazują, jak konkretny powinien być wpis.

Ostatnia kolumna jest najważniejsza. Jeśli zostaje pusta, wniosek jest zapisany, ale jeszcze nie wyciągnięty.

Najczęstsze błędy

• Szukanie winnych: gdy pojawia się wina, ludzie mówią tylko to, co muszą. W after action review obwinianie wprost przeczy celowi metody.
• Ogólniki: „lepiej planować” niczego nie zmienia. Każdy wniosek potrzebuje konkretnej rekomendacji.
• Archiwum bez wdrożenia: bez kroku 5 archiwum to cmentarz dobrych intencji.
• Brak kluczowych osób: kto wcześniej odszedł z projektu, nie siedzi przy stole, a razem z nim brakuje doświadczeń z najtrudniejszych etapów.

Gdy doświadczenie odchodzi razem z człowiekiem

Lessons learned zapisują to, czego zespół nauczył się wspólnie. Nie obejmują tego, jak konkretna osoba wykonuje swoją pracę: sztuczki przy rozliczeniu, którym kanałem oddzwania który dostawca, jakie są wyjątki. To często wiedza ukryta, która na warsztacie rzadko wychodzi sama.

Gdy kluczowa osoba odchodzi z firmy, spotkanie lessons learned nie wystarczy. Potrzebne jest uporządkowane przekazywanie wiedzy i dokument przekazania obowiązków dla następcy. Jeśli ktoś odchodzi w trakcie projektu, przed jego ostatnim dniem dodaj krótką rozmowę w cztery oczy: Co poradzisz następcy w tym projekcie? Które decyzje są otwarte? Kogo trzeba znać? To coś innego niż exit interview, w którym chodzi o powody odejścia.

Podsumowanie

Wnioski z projektu szybko się zbiera i równie szybko zapomina. Żeby działały, potrzebują konkretnych sformułowań, stałego miejsca i przede wszystkim kroku 5: osoby, która przeniesie każdy wniosek tam, gdzie dzieje się praca. Zaplanuj spotkanie, póki wszyscy są jeszcze w zespole, pytaj o dobre i złe strony i pamiętaj o tych, którzy odeszli z projektu wcześniej.