Jesteś Product Ownerem? Zaangażuj swój zespół!

Źródło Flickr.com na podstawie Common Licence

Źródło Flickr.com na podstawie Common Licence

Kierownik zespołu, lider, scrum master. Jaki jest wspólny, jeden z wielu mianowników dla tych ról? Odpowiedzialność za budowanie zaangażowania, motywacji zespołu. A jak Product Owner (Właściciel Produktu, PO) może wpływać na motywację pracowników, którzy razem z nim realizują prace? Czy w ogóle może? W niniejszym artykule chciałbym wam pokazać na przykładzie konkretnych zachowań, że tak!

Bardzo powierzchowne postrzeganie roli Product Ownera może prowadzić go do stwierdzenia “Mam zespół i powinien on robić dla mnie pracę, którą zlecam. A o motywację zespołu niech się troszczy ktoś inny. Jest przecież kierownik, scrum master.” Bardziej rozgarnięty PO stwierdzi, że w sumie to może to robić, ale nie wie jak. No właśnie. Poniżej lista konkretnych zachowań, które z pewnością mogą wpłynąć na postrzeganie pracy przez zespół jako bardziej interesującej i motywującej.

Na pewno jednym z głównych elementów budowania zaangażowania zespołu jest danie im miejsca na twórczą pracę. Pracując jeszcze jako Kierownik Projektu dostrzegałem, że motywację bardzo trudno zbudować, kiedy przychodzi się do developerów z gotowym zakresem spisanym np. w formie specyfikacji funkcjonalnej. Pomijam tutaj cały proces zbierania i przekazywania wymagań oraz jego skrzywienie. Jeżeli tak to wygląda, to z jednej strony mamy klienta, który nie chciał dostać właśnie “tego”, a z drugiej strony zespól, który dostaje do wykonania rozplanowaną już pracę i przy okazji być może z narzuconym sposobem wykonania. A po oddaniu “gotowego” produktu rozpoczyna się faza zgłaszania przez klientów change requestów, przez co zespół jeszcze długo nie może skończyć tematu. Jak można by to było zrobić inaczej? Na pewno poprzez wykorzystanie technik User eXperience, ale nie dając tego zadania specjaliście od UX, ale co najwyżej prosząc go, aby zmoderował zespół w konkretnym użyciu tych technik. Możemy zaangażować zespół na przykład w:

Część z w/w technik razem z jednym z “moich” Product Ownerów wykorzystaliśmy razem z zespołem. Efekt był taki, że programiści chodzili po biurze i pytali postronne osoby, co myślą na temat przygotowanych na papierze makiet. Wielkość zaangażowania zespołu dzięki temu ćwiczeniu była powalająca.

Innymi sposobami, które Właściciel Produktu może wykorzystać, aby podnieść zaangażowanie są z pewnością takie “techniki” jak:

  • “well done”– powiedzieć od siebie, że wykonana praca jest dobra, albo nawet bardzo dobra. Ważne w tej “technice” jest to, aby chwalić z głową i argumentować. Znaczy to tyle, aby nie przesadzić i po sprincie zakończonym nie oddaniem celu i/lub całego zakresu nie rozpływać się w zachwytach,
  • “przybliżenie” do zespołu interesariuszy i klientów. Chodząc po różnych podsumowaniach (review) sprintów widzę, że bardzo motywująco wpływa obecność samego zainteresowanego i jego opinia na temat dostarczonej przez zespół pracy. Oczywiście super, jeżeli ta opinia jest pozytywna. Ale nie zamykałbym się. Negatywne opinie (ale bez przesady) też mają swoje zalety, choćby takie, że pokazują zainteresowanie końcowych odbiorców. Nie ma chyba nic gorszego niż brak zainteresowania interesariuszy (w tym klientów) przez cały okres developmentu, a na końcu rzucanie wielu, czasami mało konstruktywnych uwag,
  • zlecanie przez PO zadań, które są rozwijające, budujące zaangażowanie. Zdaję sobie sprawę, ze nie zawsze tak się da.  Często jest tak, że trzeba zrobić zadania, które nie są motywujące, jak np. maintenance, czy też błędy. Ale warto jako PO zastanowić się, aby co jakiś czas przerywać taką żmudną pracę, dając zespołowi zadania, które z chęcią zrobi, a może przy okazji się nawet czegoś nowego nauczy,
  • pokazanie celu realizowanych zadań. Jako PO masz tę “władzę”, ze znasz powód, dla którego trzeba zrobić jakieś zadanie. Zespół zazwyczaj go nie zna. Poświęcenie kilkunastu sekund albo minut nie jest stratą czasu i warto wytłumaczyć, po co to mamy zrobić,
  • wspominałem o tym wyżej, ale warto to napisać jeszcze raz – jako Właściciel odpowiadasz za “co”, a zespół odpowiada za “jak”. I umożliwienie im definiowania jak zrobić dane wymaganie biznesowe jest wartością, która pozytywnie wpływa na motywację. To “jak” ma dla mnie dwa wymiary – pierwszy, o którym wspomniałem wyżej, to wymiar czysto techniczny, kiedy zespół, znając produkt od strony kodu, decyduje, jak zaimplementuje dane wymaganie. Drugi wymiar jest biznesowy. Optymalne, aczkolwiek nie zawsze możliwe rozwiązanie doskonalenia backlogu (backlog refinement) jest takie, że jako PO przychodzisz do zespołu z pewną ideą, pomysłem, problemem. I zespół, jako zbiór ludzi znających produkt nie tylko od strony technicznej, ale również biznesowej (nie zapominajmy o tym!) zastanawia się, jak dane wymaganie zrealizować. Zespoły developerskie naprawdę potrafią myśleć biznesowo, o czym przekonałem się już wielokrotnie,
  • podzielenie się współodpowiedzialnością. To nie jest tak, że jako PO w 100% odpowiadasz za to, jak dany produkt wygląda i jak się sprzedaje. Odpowiadacie za to całym zespołem, tylko trzeba tą odpowiedzialność zbudować. Traktowanie zespołu nie tylko jak wykonawcy zadań, zaangażowanie ich w rozwój produktu również biznesowy (np poprzez użycie jednej z w/w technik) pomaga podzielić się tą odpowiedzialnością. A człowiek, który jest za coś odpowiedzialny, który chce tę odpowiedzialność na siebie wziąć, na pewno jest do tego zmotywowany,
  • pokazanie efektów prac – trochę ten punkt się wiąże z powyższym zaangażowaniem interesariuszy, ale tutaj chodzi o coś więcej. Nawet jak nie ma na review interesariuszy i klientów, przynieś jako Właściciel i pokaż zespołowi miary produktu. Pokaż, jak Wasze zmiany wpłynęły na produkt. Jak się kształtuje jego kondycja. Jak postrzegają go użytkownicy, jak się sprzedaje, czy zarabiacie na nim i jaki wpływ na te miary miała praca zespołu,
3 factors

Kluczowe elementy motywacji wg Dana Pinka

O części w/w punktów wspomina w swoich wystąpieniach i książkach Dan Pink. Więcej możecie poczytać w artykule Jacka. Dla mnie najważniejsze w przesłaniu  Dana są trzy rzeczy pokazane na niniejszym, załączonym obok screen shot’cie z TEDa.

Ostatnia rzeczą, która motywuje i angażuje zespół jest sam Product Owner. Zaangażowanie i entuzjazm właściciela produktu przekłada się na zaangażowanie zespołu. Innymi słowy musisz być liderem. Jak się nim stać? Opowiem o tym w kolejnym artykule. A do tego czasu polecam Wam obejrzeć krótkie wystąpienie Banjamina Zandlera, który co prawda jest dyrygentem, ale o byciu faktycznym liderem wie dużo więcej niż my.

Jeden komentarz do wpisu: “Jesteś Product Ownerem? Zaangażuj swój zespół!

  1. Dobry artykuł. Zwraca uwagę na istotne kwestie.
    Odnośnie „well done” – to rzeczywiście b. ważne by przyłapywać zespół na tym, że robi coś dobrze i głośno to wyrażać. Jeżeli nie – by właściwie udzielić reprymendy.
    Niestety wciąż zbyt zakorzenione jest podejście: skoro na Ciebie nie krzyczę to znaczy, że jest dobrze, nie?

    W ogóle to metodologia Scrum bardzo fajnie zazębia się z jednominutowym zarządzaniem (polecam całą serię jednominutowego menedżera). Ogólnie rzecz biorąc: jest aktywator w postaci wyznaczenia celów (i to jednominutowych!) w trakcie planningu , co wyzwala działanie zespołu deweloperskiego w trakcie sprintu i na końcu konsekwencja w postaci pochwały lub reprymendy w czasie review (a może już w czasie retro jeśli uczestniczy w nim PO?) – zgodnie z wcześniej wyznaczonymi ustalonymi kryteriami, na podstawie definition of done.


Dodaj komentarz

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

*

Ta strona używa Cookies. Korzystając ze strony wyrażasz zgodę na używanie ciasteczek zgodnie z aktualnymi ustawieniami przeglądarki.
Akceptuję, bo lubię Was czytać.
x