Lessons Learned jest narzędziem pracy powszechnie stosowanym w zarządzaniu projektami (bardzo popularnym u kierowników projektów). Dowiesz się, dlaczego naszym zdaniem ta koncepcja jest antywzorcem? W tej rozmowie usłyszysz o ciągłym doskonaleniu procesu i produktu wraz z listą rekomendacji, co można zrobić, żeby uniknąć pułapki zbyt późnych usprawnień.

<iframe width="100%" height="166" scrolling="no" frameborder="no" allow="autoplay" src="https://w.soundcloud.com/player/?url=https%3A//api.soundcloud.com/tracks/1821843789&color=%23ff5500&auto_play=false&hide_related=false&show_comments=true&show_user=true&show_reposts=false&show_teaser=true"></iframe>

Lessons Learned, czyli wyciąganie wniosków na końcu projektu, dla wielu wydaje się, być sensownym podejściem. Dowiedz się, dlaczego warto zrewidować tę koncepcję i jak efektywniej usprawniać produkty i procesy.

Pomysł na poruszenie tego tematu pojawił się podczas konferencji dotyczącej zbierania wymagań. Jacek opowiadał na niej o tym, dlaczego koncepcja Lessons Learned jest bardziej antywzorcem niż polecaną przez niego praktyką. Wzbudziło to duże zainteresowanie i postanowiliśmy rozwinąć to zagadnienie. 

Czym jest Lessons Learned?

Lessons Learned jest powszechnym narzędziem stosowanym w zarządzaniu projektami. Polega na tym, że bazując na dotychczasowych działaniach, zbiera się i podsumowuje wnioski. Na tej podstawie ustalane są w zespole projektowym potrzebne zmiany, np. w podejściu do pracy zespołu lub do sposobu działania procesów, czy też dostosowania narzędzi dla kolejnych projektów w przyszłości. 

Najczęściej polega to na spotkaniu podsumowującym pracę po skończonym projekcie lub wdrożeniu. Cały zespół projektowy zastanawia się przez chwilę, co można było zrobić lepiej. Przemyślenia te i wnioski są spisywane, aby wiedziedzieć jak działać lepiej w przyszłości.

Koncepcja Lessons Learned ma rację bytu, w sytuacji, gdy jest to jedyna rzecz, jaką ma zrobić zespół w ramach wyciągania wniosków, czy szukania usprawnień. Pozwala ona, chociaż w małym stopniu unikać ponownych błędów lub zawirowań. Jednocześnie Lessons Learned może być taktyką organizacji, która się uczy, a także w pewnym sensie elementem rozwoju osobistego członków zespołu, z których każdy nabiera coraz lepszych doświadczeń na temat tego, co działa, co nie działa, jak działać lepiej. 

Z obserwacji niestety wiemy, że z implementacją tego podejścia bywa różnie, zwłaszcza gdy jest traktowana, tylko jako pewien punkt na liście do odhaczenia, zamiast stanowić szczerą refleksję.

Często jest ona też realizowana już po skończonym projekcie, kiedy ludzie są już myślami w nowych zadaniach, zespoły się mieszają lub realizują całkowicie odmienne projekty. Bywa to też traktowane jako smutny obowiązek bez dostrzegania pozytywnych aspektów, które mogą usprawniać działanie w przyszłości. 

Jednocześnie widzimy, że jest to po prostu zwykłe dokumentowanie pewnych wniosków i nacisk jest kładziony na to, żeby je dobrze spisać i to jest głównym celem ćwiczenia. Wnioski potem nie są wykorzystywane, a propozycji zmian nikt nie wdraża w życie. Bywa też tak, że ze spisanych przemyśleń korzysta zupełnie inny zespół, więc nie ma tu motywacji, żeby zrobić to rzetelnie.

Ciągłe doskonalenie procesu

Lessons Learned stoi trochę w kontrze z ciągłym doskonaleniem procesu, gdyż zgodnie z tym, co wspomnieliśmy powyżej, moment refleksji pojawia się trochę późno, bo na koniec projektu. Z kolei podejście ciągłego doskonalenia procesu sugeruje, aby takie ćwiczenie odbywało się częściej, np. co tydzień lub co 2 tygodnie albo po każdej iteracji czy innym rodzaju cyklu.  

Koncepcja ciągłego doskonalenia podczas korzystania ze Scruma zwykle łączona jest z Retrospektywami Sprintu, natomiast my chcemy Cię zachęcić do podejścia, jakie znamy od Alistair’a Cockburn’a, czyli do nano-usprawnień. Są to takie, naprawdę drobne usprawnia, dzięki którym ciągle się doskonalimy, ciągle poprawiamy swój proces pracy i  sposób działania zespołu, usprawniamy przebieg spotkań, szukamy lepszych narzędzi czy taktyk. Stawiamy sobie tu proste pytanie: co działa, co warto wypróbować, a potem robimy małe kroki i przeprowadzamy drobne eksperymenty. Można to robić np. na koniec Daily, gdzie zespół odpowiada na pytania: jak bardzo wartościowe było to spotkanie, co działa dobrze, a co można by zrobić lepiej. Wystarczy dosłownie 5 minut rozmowy każdego dnia, gdyż to już po tygodniu może doprowadzić, że Daily stanie się satysfakcjonujące i przydatne dla wszystkich. 

Nano-usprawnienia sprawdzą się w zasadzie przy każdej czynności, czy to w przypadku pojedynczego warsztatu z klientem, sesji planowania, czy Refinementu Backlogu Produktu. Nie ma tu potrzeby przeprowadzania jakiejś formy rozgrzewki, głosowania kropkami, czy długiej burzy mózgów. Wystarczy szybka rozmowa w zespole i wspólne zastanowienie się, czy jest coś, co można przetestować, zrobić inaczej, poprawić.

Dlaczego warto się usprawniać?

Podzielimy się 5 najważniejszymi naszym zdaniem powodami, dla których warto się nieustannie usprawniać.

Uniknięcie popełniania tych samych błędów.

Zespoły, z którymi rozmawiamy często narzekają, na popełnianie wciąż tych samych błędów, co jest bardzo frustrujące. Ciągłe usprawnianie procesu pomaga zidentyfikować te błędy, a następnie w prosty sposób je wyeliminować.