AAR – czyli jak szybko uczyć się na własnych błędach?

Autorzy: Zbigniew Waz

27.08.2017
Ugruntowaną praktyką na koniec projektu jest dokonanie całościowej oceny retrospektywnej ( np. w Scrumie po zakończeniu każdej jednostki zwanej sprintem, odbywają się tzw. Retrospektywy) tak, by podsumować to, co poszło dobrze i błędy, jakie popełniono. Jak przebiega taki proces?
  • Najczęściej jest robiony jednorazowo, po zakończeniu projektu w momencie, kiedy zespół już nie ma możliwości dokonania zmian w projekcie, zatem takie podsumowanie sprowadza się niestety tylko do tego, że winni „posypują głowy popiołem” i zapewniają, że drugi raz błędów nie powtórzą.
  • Niestety - jest spora przerwa między retrospekcją i działaniami w kolejnym projekcie, co sprawia, że nauka nie jest tak efektywna jak mogłaby być, gdyby podsumowanie następowało w trakcie trwania projektu, a wnioski byłby wdrażane natychmiast.
  • Raport z wynikami jest najczęściej przygotowywany dla managerów wyższego szczebla i nie zawsze trafia do członków zespołów, co sprawia, że wnioski i zdobyta wiedza szybko „ulatują”.
  •  Nie zawsze też członkowie zespołu mogą wykorzystać konkretne doświadczenia w innych projektach, które mogą się znacząco różnić od tego, który właśnie ukończyli.

After Action Review, czyli jak SZYBKO uczyć się na własnych błędach

Jak widać – typowe spotkania retrospektywne są mało użyteczne i bywa, że cenne wnioski, które padają po zakończeniu projektu, są niemożliwe do wdrożenia w kolejnych przedsięwzięciach, które odbiegają specyfiką od tego, który właśnie podsumowujemy. Kolejnym problemem jest to iż najczęściej spotkania retrospektywne nie mają ustalonej formy, co powoduje, że ich skuteczność jest zazwyczaj niska.
Jak zatem działa AAR? Określiłbym to jednym słowem – DYNAMICZNIE.

Jak my go stosowaliśmy we współpracy z Pridictiv?


• Założenie AARa jest takie, że spotkania odbywają się wielokrotnie w trakcie trwania projektu i trwają od 15 min do 1h. My robiliśmy je co 2-3 tygodnie, co zaowocowało efektywnym teaworkiem – bardzo szybko przestaliśmy być dwoma oddzielnymi zespołami po dwóch stronach barykady: klient – wykonawca, a staliśmy się jednym teamem, który wspólnie pracuje nad najlepszą możliwą wersją aplikacji.
• W AARze silny nacisk kładziony jest na zaplanowanie konkretnych działań opartych na wyciągniętych wcześniej wnioskach. Podczas naszych cotygodniowych skype’owych Review moglibyśmy na bieżąco monitorować postęp prac – co zostało zrobione, a co nie i z jakiego powodu. Dzięki temu mogliśmy reagować niemal od razu. W tradycyjnym zarządzaniu projektem byłoby to możliwe dopiero po zakończeniu danego etapu developmentu. Tutaj czas między retrospekcją a działaniem jest bardzo krótki – zespół wdraża plan praktycznie od razu po Review i obserwuje, jak wpływa na rozwój projektu.
• Najczęściej tematem jest wąskie zagadnienie (np. konkretny feature aplikacji). Wówczas spotyka się grupa osób, której to zagadnienie dotyczy. Dzięki temu komunikacja jest w pełni personalna i transparentna, nie ma pośredników w postaci managerów projektu a feedback pochodzi wprost od źródła - zleceniodawcy. To niezastąpione w budowaniu relacji i komunikacji w zespole.

Spójrzcie, jak analizowaliśmy taski, które zostały poprawnie wykonane: Kliknij żeby zobaczyć


Jak wygląda struktura AAR? To cztery proste pytania!

1. Jakie były nasze cele? Istotą tego pytania jest jasne sprecyzowanie celu i oczekiwań. W praktyce często się zdarza, ze członkowie teamu ze zdumieniem odkrywają, iż różnie rozumieli zadanie, jakie przed nimi postawiono. To momen, kiedy musimy wrócić do dokumentów BAR, gdzie skrupulatnie rozpisaliśmy projekt.
2. Jakie rezultaty osiągnęliśmy? Tutaj szukamy faktów opisujących wynik naszych działań, analizujemy efekty jakie uzyskaliśmy, realizując dany projekt.
3. Dlaczego osiągnęliśmy takie rezultaty? Staramy się dociec dlaczego uzyskaliśmy takie, a nie inne rezultaty, analizujemy wszystkie zmienne, zasoby oraz workflow.
4. Co chcemy utrzymać i co mamy poprawić? Teraz tworzymy plan. Zachęcam, żeby na tym etapie być maksymalnie konkretnym, np. zamiast „będziemy się częściej komunikować” które może być różnie interpretowane, wpisujemy „organizujemy dzienne spotkania Daily Scrum” , co już jest bardziej jednoznaczne.

Spójrzcie, jak my analizować elementy do poprawy: Kliknij żeby zobaczyć


Nasze doświadczenia z tym narzędziem są na tyle pozytywne, że zdecydowaliśmy się stosować je we wszystkich projektach, nawet tych, które są daleko od developmentu aplikacji i dotyczą choćby działań marketingowych. Obecnie pracujemy nad tym aby cotygodniowe retrospektywy miały formę AAR, tak aby jak najszybciej wyciągać wnioski z rzeczy dobrych, złych, tak aby jak najszybciej usprawniać proces developmentu. To narzędzie, które pozwala porządkować cele, gwarantuje transparentną komunikacje i chroni przed „zawracaniem w połowie drogi”. A Wy jakie macie doświadczenia z narzędziami do zarządzania projektami IT?