Cztery proste pytania. Jak szybko reagować na problemy w projekcie dzięki modelowi AAR?

* – tekst o metodzie BAR znajdziecie pod tym adresem.

Zdjęcie główne artykułu pochodzi z pl.depositphotos.com

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, 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łyby 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 zastosowaliśmy? 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 teamworkiem – 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:

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, że członkowie zespołu ze zdumieniem odkrywają, iż różnie rozumieli zadanie, jakie przed nimi postawiono. To moment, 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:

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.

AAR to narzędzie, które pozwala porządkować cele, gwarantuje transparentną komunikację i chroni przed „zawracaniem w połowie drogi”.

A Wy jakie macie doświadczenia z narzędziami do zarządzania projektami IT?

–

Zbyszek Waz

Managing Partner w Leaware

Trener biznesowy, fan metodyk związanych z tworzeniem i rozwojem produktów oraz efektywnym działaniem. Aktywnie pracuje ze startupami i pomaga je rozwijać – zarówno jako dostawca technologii jak i znienawidzony konsultant zadający trudne pytania. Od blisko 20 lat tworzy produkty i wprowadza je na rynek, dbając o to, by zderzenie z rzeczywistością nie było zbyt bolesne. Niestrudzony poszukiwacz odpowiedzi na pytanie „dlaczego w większości przypadków rzeczywistość wygrywa z ideą”.