wyniki zespołu scrum agile product owner

Czy Twój zespół zna wartość swojej pracy?

Agile

Lubię znać wyniki swojej pracy. To mnie motywuje do kolejnych działań. Jednocześnie obiektywnie pomaga ocenić czy to co robię jest w ogóle sensowne. Sądzę, że większość z nas ma podobnie. Jednocześnie często pędzimy, razem z naszymi zespołami, z projektu w projekt, z zadania w zadanie i nie sprawdzamy czy przypadkiem nie jest to bieg w niewłaściwą stronę 😉

 

Prosta sprawa – dziel się wynikami

Dużo będzie zależało od charakteru produktu czy sposobów pracy (Twoich, organizacji), ale zapewne w większości wypadków uznasz, że lepiej pracować z zespołem, który jest faktycznie zaangażowany w rozwój produktu i rozumie kierunek jego rozwoju, niż z kimś kto tylko dostarcza materiały (np. kod) i nie interesuje się efektami. Większa szansa, że owoce pracy będą lepsze jakościowo, pomysły bardziej kreatywne, ludzie chętniej będą się wspierali itd. To powoduje, że atmosfera pracy jest lepsza, produkt szybciej rozwijany, skupiamy się na rozwiązywaniu problemów, a nie bezrefleksyjnym klepaniu kolejnych projektów. Brzmi sensownie?

Mimo tylu korzyści, nie każdy buduje takie środowisko. Nie trzeba jednak dużo, aby zacząć to robić. Jedną z pozytywnych praktyk jest dzielenie się, z zespołem, wynikami biznesowymi wdrożonych funkcjonalności czy projektów. Chodzi o to, aby zespół rozumiał jakie znaczenie ma jego praca, mógł obserwować i komentować wyniki, dzielił się pomysłami na ich poprawę i cieszył sukcesami.

 

Jak to zrobić?

W praktyce może to przyjmować przeróżne formy. Ważne jest, aby dzielić się wynikami, na które zespoły bezpośrednio mają wpływ, które dotyczą ich codziennej pracy i widać bezpośredni związek z ich zadaniami. Menadżerowie często pokazują bardziej ogólnofirmowe wyniki – te też bywają ciekawe, ale w tym poście chodzi o te bliższe codzienności zespołu.

Przykładowo: wrzuć “na Slacka”  wykres z wynikami testów A/B, który robiliście i opatrz je komentarzem + po wdrożeniu lepszej wersji, przez jakiś czas dziel się informacjami na temat konwersji (spada, rośnie itd.). Kiedy indziej można zrobić większe podsumowanie np. kwartału i pokazać kilka większych klocków (np. konwersja przez kwartał – na jednym wykresie z zaznaczonymi ważniejszymi wdrożeniami produkcyjnymi).

Nic trudnego, prawda?

Dobrze też, gdy zespół rozumie czemu ma zbudować jakąś funkcjonalność. Zatem np. na sesji doskonalenia backlogu, podczas omawiania pomysłów warto przytaczać dane, które za nimi stoją – “zmieńmy formularz kontaktowy, bo jak wynika z danych obecny sprawia użytkownikom dużo problemów – ciach, pokazanie wybranych nagrań z Hotjara ”. To nie tyko sprawia, że ludzie rozumieją tło, ale znają też powód proponowanych zmian i problem do rozwiązania – przez to mogą sami wpaść na pomysł, który zmieni Twój produkt 🤩 Niby oczywista rzecz, ale nie widziałem zbyt często by ktoś tak robił.

Jedną z okazji do dzielenia się wynikami może być też Sprint Review. Jeśli zatem pracujesz w Scrumie i robisz Przegląd Sprintu, to czemu nie wpleść tego elementu w agendę wydarzenia? Częściej widzę jak zespoły po prostu prezentują kolejne ficzery, analizy wyników mało. Jeśli Twoi interesariusze poprosili Wasz zespół o wykonanie jakiejś funkcjonalności, to czemu nie mieliby sami przyjść z wynikami i ich krótko omówić? “Prosiliśmy Was 4 tygodnie temu, abyście pomogli nam, tworząc LP do kampanii marketingowej. Oto jakie udało się uzyskać, do tej pory, wyniki dzięki tym stronom”. Dużo zależy od układu zespół-otoczenie, ale rozmowy o wynikach na każdej płaszczyźnie są ważne.

 

Podsumowanie

Mocno wierzę, że ludzie potrzebują wiedzieć jaki wpływ ma ich praca na rzeczywistość – w tym także tę produktową. Dzięki temu mogą zyskać dumę z tego do czego przykładają rękę, chętniej utożsamiać się z produktem, proponować ciekawe rozwiązania realnych problemów. Ponadto pomaga im to zyskać poczucie, że rozumieją kierunek rozwoju produktu i mają w ogóle na ten kierunek wpływ. Product Ownerzy czy kierownicy projektów mogą być świetnymi dostawcami takiej wiedzy i inspiracji, chciałbym jeszcze częściej widzieć jak potrafią to robić – chociaż każdy może wpaść na ten pomysł i promować tego typu praktyki. Jak łatwo się domyślić, nie wystarczy ograniczać się do pokazania wyników, bo przyda się jeszcze wytworzenie dobrej atmosfery do dyskusji o wynikach, ale przy dobrej podstawie to przyjdzie – trzeba zrobić tylko pierwszy krok 😎


Może zainteresuje Cię także post „Scrum i metryki – co może się przydać zespołom zwinnym?

2 komentarze w “Czy Twój zespół zna wartość swojej pracy?

  1. To o czym nie wspomniałeś w podsumowaniu to to, że taki pokazanie wyniku, w mniejszym lub większym gronie, może być dużym motywatorem. W końcu nic tak nie motywuje jak owoce własnej pracy, prawda? Jest to też doskonała okazja by zebrać trochę pochwał, to również może zmotywować zespół.
    Warto również pokazywać wyniki słabsze od oczekiwanych, wtedy zdecydowanie rośnie zrozumienie dla decyzji sterujących rozwojem produktu.

Dodaj komentarz

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *