Podsumowanie kwartału na linii Biznes & IT – case study RynekPierwotny.pl

90 dni, kilka tysięcy przepracowanych godzin, setki zrealizowanych zadań i… jedynie 40 minut na efektywne zaprezentowanie efektów kwartalnych. Czy to w ogóle możliwe?

Właśnie takie pytanie zadaliśmy sobie 13 miesięcy temu przy organizowaniu pierwszych dedykowanych podsumowań okresowych dla zespołów IT & Produkt.

Po ponad roku pracy nad udoskonalaniem formuły oraz zauważalnym (15,5%) wzrostem efektywności pracy zespołów możemy śmiało odpowiedzieć: Możliwe!

A wszystko przez jedno małe RETRO…

Nieco ponad rok temu w gronie Headów i Product Ownerów omawialiśmy wyniki kwartalne – standardowo, w excelu. Wypełnialiśmy wiersze na zielono (zadanie ukończone), żółto (zadanie w trakcie realizacji) i czerwono (zadanie usunięte z realizacji w trakcie trwania kwartału). Wydawało nam się, że jest pięknie, niezbyt kolorowo bo w większości na zielono.

Zadowoleni, razem z CTO, uścisnęliśmy sobie dłoń i ruszyliśmy na kolejne spotkanie jakim była cykliczna retrospektywa. Retro według naszych oczekiwań miało być przyjemne… Atmosfera w zespole była utrzymywana na wysokim poziomie, taski opisywane w sposób klarowny, a sprint zamknięty w 95%.

Co mogło pójść nie tak?

Okazało się, że… bardzo dużo rzeczy. Karteczki MAD i SAD na retrospektywie sprawiły, że nasze poczucie GLAD z poprzedniego spotkania odpłynęło bardzo szybko.

„Zrealizowałem trzy taski i żaden aktualnie nie jest na produkcji”. „Nie wiem czy moja praca wpływa na ogólny rozwój portalu”. „Słyszałem, że podnieśliśmy konwersję, ale nie wiem czy to zasługa mojej pracy czy może zmieniła się koniunktura na rynku.”
W tym momencie zrozumieliśmy, że poziom komunikacji działań produktowych w zespole IT jest na niższym poziomie niż nam się wydawało. Można by nawet uznać, że problem wystąpił na poziomie pryncypialnym ➡️ „Po co w ogóle wykonuję określone zadania i jaki mają one wpływ na naszą organizację?”.

Pytania zadane przez programistów sprawiły, że postanowiliśmy szerzej komunikować wprowadzane zmiany produktowe. Postanowiliśmy zorganizować pierwsze spotkanie podsumowujące efekty pracy IT w kontekście wpływu na ogólne zmiany produktowe w organizacji.

Plan spotkania kwartalnego

Przed pierwszym spotkaniem zastanawialiśmy się nad takimi aspektami jak:

• Czy omówienie tak wielu zadań nie zajmie kilku godzin?
• W jaki sposób wprowadzić mierzalność podsumowań tak aby w następnych kwartałach móc dokonać porównania?
• Czy wprowadzać przestrzeń na wyciąganie wniosków? (lesson learned).

Postawiliśmy na minimalizm. Wprowadziliśmy trzy główne elementy, na których oparliśmy 40 minutowe spotkanie:

1️⃣ Liczba wykonanych zadań w kwartale

Podliczyliśmy wszystkie taski zrealizowane w kwartale, zarówno te mniejsze jak i większe. Liczba ta wyszła totalnie kosmiczna bo idąca w tysiące… Następnie na wybranych przykładach omówiliśmy jak te zadania wpłynęły na pracę organizacji.

Czasami, niepozorne na pierwszy rzut oka zadania, potrafiły zwiększyć konwersję o kilkanaście procent – chcieliśmy aby programiści wykonujący np. zmianę copy przy buttonach wiedzieli, że ich zadania mają realny wpływ na sposób funkcjonowania całego portalu.

2️⃣ Omówienie testów A/B

Omówienie polegało na przedstawieniu głównych założeń, metryk oraz finalnych wyników w pigułce. Dla zainteresowanych linkowaliśmy bardziej obszerne treści do zgłębienia po spotkaniu.

Głównym celem było zaprezentowanie zespołom deweloperskim wniosków, tak aby widzieli, że ich praca jest tak samo wartościowa w przypadku finalnego wdrożania wersji testowej jak i kontynuacji prezentowania wersji bazowej.

3️⃣ Omówienie badania NPS

Nikt nie jest w stanie lepiej zaopiniować Twojego produktu niż użytkownicy. Uznaliśmy zatem, że krótkie omówienie wyników NPS wraz z najbardziej pozytywnymi i negatywnymi komentarzami wpłynie na bardziej świadome postrzeganie produktu przez cały zespół programistyczny.

Efekty po pierwszym spotkaniu

Czterdziesto minutowe spotkanie rozwiązało wiele pytań, które pojawiły się podczas wspomnianej wcześniej retrospektywy – wszyscy wiedzieliśmy dokąd zmierzamy i np. dlaczego niektóre rozwiązania zostały usunięte z produkcji.

Poniżej podsumowanie okiem jedengo z naszych Developerów.

Łukasz Amróz, Frontend Developer:

Podsumowanie daje możliwość zweryfikowania poziomu realizacji naszych założeń w kontekście wszystkich projektów. Jest to szczególnie istotne z punktu widzenia zespołu deweloperów, który przygotowuje wyceny zaplanowanych w danym kwartale zadań. Podsumowanie pozwala nam określić dokładność estymat i korygować obszary, w których nasze szacunki nie zostały spełnione w zaplanowany sposób.

 

Dodatkowo, podsumowanie jest okazją do sprawdzenia jak, realizowane w ramach kwartału, zadania wpłynęły na cele biznesowe oraz zadowolenie użytkowników. Wnioski płynące z tej wiedzy wyznaczają kierunek rozwoju naszych produktów.

Kolejne usprawnienia

Po pierwszym podsumowaniu kwartalnym wyciągnęliśmy również sporo wniosków, które pozwoliły nam usprawnić formułę spotkania:

1️⃣ Dodaliśmy podział zadań ze względu na czas realizacji

Zauważyliśmy, że liczba wykonanych tasków w kwartale okazała się totalnie niewymierna bez podziału na czas realizacji. W jednym kwartale wykonaliśmy (przykładowo) 20 zadań a w drugim 50. Bez określenia złożoności zadania liczby te nie stanowiły większej wartości.

Dodaliśmy zatem wskaźnik zadań podstawowych oraz złożonych. Dzięki temu mogliśmy monitorować nie tylko naszą sprawczość ale również zobaczyć, że z kwartału na kwartał nasze projekty stają się coraz bardziej ambitne i skomplikowane.

2️⃣ Mierzenie zadowolenia wewnątrz zespołu

Rozpoczęliśmy cykliczne mierzenie zadowolenia zespołu poprzez przydzielanie dedykowanych punktów na spotkaniach RETRO – zebraliśmy wszystkie karteczki ze spotkań restrospektywnych i przełożyliśmy je na wykres liniowy. Dzięki temu mogliśmy w jasny sposób zderzyć konkretne emocje zespołu z wydawaniem większych projektów i sprawdzić jak wpłynęły na ogólne samopoczucie.

3️⃣ Lessones learned

Do naszych spotkań dodaliśmy także czas na „lesson learned”, Celowo usunęliśmy go podczas pierwszego podsumowania kwartalnego. Uznaliśmy, że dopiero posiadając pełny zakres danych – takich jak poziom zadowolenia zespołu w konkretnych miesiącach, podział zadań ze względu na ich złożoność oraz pełne dane odnośnie testów A/B wraz z NPS – pozwolą nam na rzetelne wprowadzenie modułu lesson learned i wyciąganie wniosków na przyszłość.

Wprowadzone zmiany sprawiły, że nasze spotkania wydłużyły się do 60 minut. Możemy jednak śmiało powiedzieć, że było warto. Godzina poświęcona na podsumowanie działań oraz nakreślenie wizji na następne 3 miesiące zwróciła się blisko sześciokrotnie…

W jaki sposób zmierzyliśmy efektywność spotkań?

Podczas pracy w sprintach trackujemy nie tylko czas poświęcony na wykonywanie zadań programistycznych ale również na doprecyzowanie tasków oraz dodatkowe konsultacje (np. odnośnie wizji rozwoju funkcjonalności w kolejnych etapach).

Po wprowadzeniu spotkań kwartalnych zauważyliśmy, że czas spędzony na doprecyzowywaniu wizji produktowej, a tym samym na analizę zadań przez programistę zmniejszył się o około 1 godzinę w trakcie trwania sprintu. Oznacza to, że dzięki sprawnemu komunikowaniu potrzeb wykreowaliśmy aż 6 dodatkowych godzin w kwartale na realizowanie zadań roadmapowych. Przy większych zespołach programistycznych taka zmiana spowodowała wzrost globalnej efektywności na poziomie 15,5%.

Podsumowując

Podczas pracy nad rozwojem produktu często wychodzimy ze spotkań z wnioskiem “this meeting could have been an email”. Czasami jednak tendencja może się odwrócić i zorganizowanie spotkania o tematyce tytułu maila może podnieść efektywność pracy w sposób nieprzewidywalny.

Warto jednak podkreślić, że praca nad jakością sprintów czy komunikacją to proces ciągły. Zaprezentowanie Keynote’a popartego liczbami to jedynie pierwsza cegiełka w budowaniu mostu produktywności, który powinien być oparty na filarach takich jak zaufanie, szacunek i empatyczna komunikacja.