Jak szef produktu buduje odpowiedzialność zespołów?

Czy masz wrażenie, że Twój zespół wykonuje zadania, ale nie czuje realnej odpowiedzialności za produkt? Brakuje u nich inicjatywy, zaangażowania i proaktywnego podejścia? Pokażemy Ci sprawdzone sposoby na wzmacnianie odpowiedzialności zespołów – bez micromanagementu i bez frustracji. To konkretna pigułka wiedzy dla liderów, którzy chcą budować silne, samodzielne i zaangażowane zespoły.

Porady dla szefa produktu pomagające budować odpowiedzialność zespołów

W ramach naszego podcastu, nagraliśmy odcinek o budowaniu odpowiedzialności za produkt, skierowany głównie do Product Ownerów i Scrum Masterów. Możesz go znaleźć na stronie www.porzadnyagile.pl/31, pod tytułem: „Wzmacnianie odpowiedzialności zespołu za produkt”. Dziś podejmujemy podobną tematykę, ale w zupełnie innych okolicznościach i z myślą o osobach zarządzających większymi strukturami – kilkoma zespołami, produktami lub całą strukturą produktową.

Mamy dla Ciebie dziesięć porad dotyczących tego, co osoba zarządzająca strukturą produktową może zrobić, aby budować odpowiedzialność zespołów wytwórczych za produkt, nad którym pracują.

Wyznaczaj ambitne cele

Wszystko zaczyna się od konkretnego, ambitnego i mierzalnego celu. Warto przy tym wykazać się wizjonerskim podejściem, pokazując zespołom perspektywę wykraczającą poza to, co obecnie są w stanie dostrzec. Takie podejście wiąże się z wyższymi oczekiwaniami, które motywują do poszukiwania mniej oczywistych rozwiązań.

Aby osiągnąć ambitny cel, zespół powinien poświęcić czas na przemyślenie sposobów realizacji i wzięcie odpowiedzialności za efekt końcowy. Ograniczenia – na przykład czasowe – mogą skłonić do kreatywnego podejścia: radykalnych uproszczeń, sięgnięcia po nowe technologie lub zastosowania nieszablonowych rozwiązań, które w danej organizacji będą zaskakujące i świeże.

Jeśli żaden z przypadków wymienionych wcześniej nie dotyczy Twojej sytuacji, ta porada jest tym bardziej dla Ciebie. W roli szefa produktu warto czasem samodzielnie stworzyć lub zasymulować warunki, w których pojawi się ambitny cel. Chodzi o świadome sprowokowanie sytuacji, która postawi zespoły przed wyzwaniem.Mamy na myśli odwrócenie niekorzystnej sytuacji, gdy zespoły są lekko rozleniwione, nie mają wyzwań, a cele, które przed nimi stoją, są miałkie, lekkie i letnie. Brak ambitnych celów może przyczyniać się do rozluźnienia i podejścia w stylu: „zrobię swoje, jakoś to się wszystko później złoży, będzie dobrze”.

Mamy jednak bardzo pozytywne doświadczenia z różnych organizacji, w których pojawienie się wyzwania – rozumianego jako ambitna aspiracja, a nie problem – działało motywująco. To właśnie taki cel sprawia, że zespół musi się zmobilizować, zebrać, przestać lekceważyć pewne sprawy, wysilić się i poszukać kreatywności. W efekcie zaczyna brać sprawy w swoje ręce i stara się osiągnąć coś, co na pierwszy rzut oka może wydawać się zbyt duże, zbyt trudne lub nierealne do wykonania w danym czasie.

Nieustannie przypominaj strategię firmy i produktu

Zakładamy, że zarówno strategia firmy, jak i produktu istnieje – w większości organizacji faktycznie tak jest. Jednak równie często zdarza się, że choć strategia jest dobrze znana na wyższych poziomach zarządzania i stanowi ich codzienność, to niekoniecznie dociera do zespołów operacyjnych ani liderów pierwszej linii. Właśnie dlatego rolą szefa produktu jest regularne, konsekwentne – a z perspektywy niektórych może nawet nadmierne – przypominanie, na czym polega strategia i dlaczego została przyjęta w takiej formie.

Warto też zaznaczać, czego w strategii nie ma oraz wyjaśniać, jak poszczególne tematy się ze sobą łączą i w jaki sposób podejmowane decyzje wpisują się w szerszy kontekst. O samych decyzjach powiemy więcej w kolejnych punktach.

Nieustanne przypominanie o strategii to w praktyce łączenie kropek między tym, co organizacja chce osiągnąć na poziomie strategicznym, a tym, co faktycznie dzieje się w zespołach. Z perspektywy codziennej pracy członkowie zespołu często koncentrują się na pojedynczych zadaniach, a w najlepszym wypadku – na realizowanych projektach, inicjatywach czy zmianach w produkcie. Brak jasnego powiązania między tymi działaniami a szerszym kontekstem strategicznym może prowadzić do niezrozumienia podejmowanych decyzji czy opracowania rozwiązań, które nie są tak trafne, jak mogłyby być.

Zrozumienie, dlaczego pewne działania są priorytetowe, a inne zostały odłożone na później lub całkowicie pominięte, pozwala zespołom lepiej dopasować swoje działania do kierunku, w jakim zmierza firma. Znajomość strategii firmy i produktu nie tylko ułatwia podejmowanie trafnych decyzji, lecz także wzmacnia poczucie odpowiedzialności w zespole – bo kiedy rozumiemy sens działań, łatwiej nam się z nimi utożsamić i brać za nie odpowiedzialność.

Włączaj zespoły w kreowanie rozwiązań

Głównym przesłaniem tej porady jest zachęta, aby nie traktować zespołów jak podwykonawców – czyli grupy, której zleca się precyzyjne zadania i oczekuje jedynie ich wykonania. Warto zamiast tego podejść do zespołu jak do partnera, który posiada samodzielność i świadomość celu. Zespół, rozumiejąc strategię firmy oraz produktu, powinien mieć przestrzeń do kreowania rozwiązań – takich, które najlepiej odpowiadają na potrzeby organizacji, uwzględniając dostępny czas, możliwości, a także ograniczenia technologiczne. Dobrze zbudowany zespół wytwórczy potrafi podejmować trafne decyzje operacyjne, często lepiej niż osoby spoza jego struktury. Wynika to z faktu, że wiele decyzji dotyczy szczegółów, które mogą umknąć radaru osobom zarządzającym wyższymi szczeblami. Właśnie dlatego tak ważne jest umożliwienie zespołowi wpływu na to, jak realizowane są zadania.

Oznacza to, że zespoły mogą być włączone w proces budowania roadmapy oraz aktywnie konsultowane podczas definiowania celów, większych inicjatyw czy kolejnych kroków rozwojowych, które mają zrealizować. W rozmowach na ten temat z osobami zarządzającymi często pojawia się jednak obawa o podejście zero-jedynkowe – słyszę wtedy: „Nie będę ich włączać, bo źle to wymyślą.” Warto więc podkreślić, że ta porada brzmi: włączaj zespoły, a nie przerzuć na zespoły całą odpowiedzialność.

W większości organizacji pełne oddelegowanie tematu rozwiązań na zespoły nie jest w pełni realne. Jeśli w Twojej firmie jest inaczej – to świetnie. W praktyce jednak wiele organizacji znajduje się w innym miejscu. Dlatego mówimy o współtworzeniu – o takim podejściu, w którym zarówno wyższa kadra zarządzająca, jak i zespoły oraz liderzy produktów angażują się we wspólne wypracowanie rozwiązań. Chodzi o unikanie sytuacji, w której zespołom zleca się z góry narzucone, zamknięte rozwiązanie – bez możliwości wpływu na jego kształt.

Wyjaśniaj kontekst biznesowy swoich decyzji

Ten temat pojawił się już przy omawianiu strategii, ale warto do niego wrócić. W trakcie rozwoju produktu pojawia się wiele decyzji biznesowych – niektóre mogą być dla zespołu niezrozumiałe, inne sprzeczne z wcześniejszymi ustaleniami. Czasami są to decyzje niepopularne, a nawet trudne do przyjęcia. Przykłady? Zamknięcie produktu, rezygnacja z obsługi konkretnego segmentu rynku lub przekazanie części biznesu innemu produktowi w ramach organizacji. Tego typu zmiany potrafią silnie zdemotywować zespół, a w skrajnych przypadkach prowadzić do biernego oporu, jawnego lub ukrytego sabotowania działań czy błędnych interpretacji podejmowanych kroków.

Dlatego tak ważne jest wyjaśnianie zespołom kontekstu podejmowanych decyzji. Pokaż szerszą perspektywę – to, co dla Ciebie jest oczywiste, wcale nie musi być zrozumiałe dla innych. Brak wiedzy o przyczynach danej decyzji może zadziałać demotywująco, a z kolei dobre wyjaśnienie potrafi zbudować zrozumienie i zaangażowanie. To działa także w drugą stronę – jeśli podejmujesz pozytywną decyzję, która otwiera nowe możliwości, pokaż zespołowi, skąd się wzięła. Pozwól im poczuć satysfakcję i entuzjazm, który towarzyszy ci w danym momencie.

Patrząc na tę poradę w dłuższej perspektywie, regularne wyjaśnianie kontekstu biznesowego sprawia, że zespoły z czasem znacznie lepiej rozumieją środowisko, w którym funkcjonują. Wiedzą, dlaczego z pewnych działań się rezygnuje, a inne należy realizować w określony sposób.Nic nie demotywuje tak bardzo jak komunikat: „Od teraz robimy tak” – bez podania przyczyn czy szerszego uzasadnienia. W praktyce często prowadzi to do frustracji. Zespoły, które wielokrotnie spotykają się z takim podejściem, zaczynają reagować z sarkazmem i dystansem. W skrajnych przypadkach pojawia się przekonanie: „Cokolwiek powiemy, i tak zrobią po swojemu”. To z kolei prowadzi do postawy: „Wykonujemy swoje zadania, ale efekt końcowy nas nie interesuje”. Taki zespół potrzebuje zrozumieć powody decyzji. To pozwala mu utożsamiać się z celem, podejmować lepsze decyzje na co dzień i realnie dbać o rezultat końcowy.

Pozwalaj eksperymentować i popełniać błędy

W tej poradzie pojawiają się dwa istotne elementy: eksperymentowanie i popełnianie błędów. Eksperymentowanie zazwyczaj przychodzi z łatwością, ale akceptacja ewentualnych pomyłek już niekoniecznie. W organizacjach, w których odpowiedzialność produktowa jest niska, zespoły często unikają podejmowania decyzji. Gdy dopytujemy, z czego to wynika, okazuje się, że w tle pojawiają się wspomnienia sytuacji, w których popełnione błędy spotkały się z nieprzychylną reakcją. Może to dotyczyć nietrafionych pomysłów produktowych, rozwiązań procesowych, które okazały się nieefektywne, albo decyzji prowadzących do problemów.

Przy budowaniu odpowiedzialności trzeba pamiętać, że nie każda decyzja zespołu będzie idealna. Błędy są częścią procesu i należy się ich spodziewać, szczególnie gdy zespół dopiero zaczyna podejmować samodzielne decyzje. Warto zacząć od mniejszych tematów, które w razie niepowodzenia nie spowodują dużych strat. Nawet jeśli pojawią się potknięcia, to będzie okazja do nauki.

Kluczowe jest to, by zespół miał przestrzeń do eksperymentowania, czuł wsparcie i wiedział, że ktoś mu ufa. Chodzi o to, by stopniowo budować odwagę i samodzielność, a jednocześnie zachować zdrowy balans. Szef produktu powinien pełnić rolę bezpiecznika – zadbać, by decyzje nie były podejmowane chaotycznie, bez przemyślenia.

Przy popełnionych błędach ważne jest, by zamiast skupiać się na pytaniu „dlaczego się pomyliliście?”, zapytać „czego się nauczyliście?” i „co możecie zrobić, żeby to się nie powtórzyło?”. Systematyczne wyciąganie wniosków z błędów jest kluczowe. W przypadku problemów procesowych chodzi o to, by zidentyfikować przyczynę i znaleźć rozwiązanie zapobiegające podobnym sytuacjom w przyszłości.

Jeśli chcesz jeszcze bardziej pogłębić swoją wiedzę zajrzyj na stronę porzadnyagile.pl/sklep. Znajdziesz tam nasze płatne produkty, które pomogą ci jeszcze skuteczniej rozwijać Twoje umiejętności. 

Oczekuj efektów, a nie dowożenia zakresów

Esencją tej porady jest myśl, że zespoły funkcjonują zupełnie inaczej, gdy mają od A do Z rozpisane, co dokładnie mają zrobić, w porównaniu do sytuacji, gdy stawia się im poprzeczkę wyżej. Najważniejsze są efekty – nie sposób, w jaki zespół zrealizuje założenia.

Przekazanie odpowiedzialności za osiągnięcie konkretnego rezultatu i pozostawienie zespołowi decyzji, jak do niego dojść, to moment, w którym rodzi się prawdziwa odpowiedzialność. Pojawiają się pomysły, koncepcje, a zespół zaczyna czuć więź z wypracowanymi rozwiązaniami. W efekcie wzrasta zaangażowanie i zmienia się podejście do pracy – jeśli coś jest „nasze”, bardziej nam na tym zależy. Małe sukcesy cieszą, a porażki stają się osobistą motywacją do poprawy.

Takiego podejścia często brakuje, gdy zespół pracuje w trybie „klepania tasków” – wykonuje zadania bez refleksji, czy wyjdzie dobrze, czy nie. Przesunięcie odpowiedzialności w stronę zespołu i pozwolenie mu decydować, jak osiągnąć cele, może diametralnie zmienić poziom zaangażowania i jakość pracy.

Zarządzającym bardzo łatwo zgodzić się z tą poradą – wielu może mieć odruch, że przecież stosują to od dawna. W praktyce jednak diabeł często tkwi w szczegółach. Przykład (wymyślony, niepowiązany z żadnym klientem): wielu zarządzających uważa, że dodanie funkcji do aplikacji to efekt. Tymczasem to jedynie zakres prac. Efektem będzie dopiero np. wzrost sprzedaży, który ta funkcja umożliwi.

Warto dać zespołom przestrzeń do szukania skrótów i odcinania się od utartych wyobrażeń. Nawet jeśli wydaje się, że konkretne elementy zakresu są kluczowe, priorytetem powinny być rezultaty biznesowe. Wracając do przykładu aplikacji – zwłaszcza w dużych organizacjach zespoły technologiczne często słyszą: „postawcie platformę” czy „zbudujcie aplikację” jako oczekiwany efekt. Tymczasem prawdziwym celem może być pierwsza sprzedaż na platformie, pozyskanie puli klientów czy osiągnięcie dochodu z oferowanych funkcji.

Takie spojrzenie poszerza perspektywę. Praca zespołu technologicznego to tylko część układanki. Efekt końcowy wymaga także marketingu, sprzedaży, wsparcia prawnego i operacyjnego. To z kolei mocno nawiązuje do tematu współpracy biznesu i IT, o którym pisaliśmy w jednym z wcześniejszych artykułów.

Zapewnij zespołom dostęp do feedbacku od klientów 

Chodzi o to, aby zespół miał stały dostęp do regularnych informacji zwrotnych – poprzez odpowiednie rozwiązania, narzędzia i systemy. Feedback od klientów jest kluczowy dla budowania poczucia odpowiedzialności. Nie mówimy tutaj wyłącznie o okazjonalnym wglądzie w wyniki badań, jednorazowych grupach fokusowych czy sporadycznym pytaniu kilku osób o opinię. Istotne jest stworzenie systemu, który umożliwi zespołom łatwe i ciągłe zbieranie informacji zwrotnej.

Zespół powinien mieć możliwość konsultacji oraz testowania swoich pomysłów z rynkiem – zarówno w przypadku rozwiązań będących w fazie rozwoju, jak i tych już funkcjonujących. Ważne jest odejście od ideii „wymyślić, wdrożyć i zapomnieć” na rzecz stałego kontaktu z klientem docelowym. Zaznaczając również, kto jest docelowym klientem. 

Choć można oczekiwać, że zespoły same będą myśleć w ten sposób, to rolą szefa produktu jest stworzenie w organizacji warunków do regularnego pozyskiwania prawdziwego feedbacku. Chodzi o informacje pochodzące bezpośrednio od klientów – a nie tylko od szefa, członka zarządu czy innej ważnej osoby w firmie. To właśnie głos klientów powinien być głównym źródłem wiedzy dla zespołów.

Po pierwsze – im bardziej bezpośredni i oryginalny jest feedback, tym lepiej. Chodzi o to, aby zespoły miały dostęp do rzeczywistych słów klientów, a nie do informacji przefiltrowanych przez kolejne osoby w organizacji. Bezpośrednie rozmowy, konkretne ankiety czy rzeczywiste wypowiedzi klientów są znacznie bardziej wartościowe niż przekazany „głuchym telefonem” komentarz, który może być już zniekształcony.

Po drugie – choć ta porada może brzmieć oczywiście, w praktyce nie zawsze jest tak łatwo wdrożyć ją w życie. W wielu firmach, mimo dostępu do danych i feedbacku, system pracy zespołów jest zorganizowany w taki sposób, że sięganie po te informacje wydaje się zbędne lub postrzegane jest jako strata czasu. Priorytetem staje się programowanie, testowanie czy projektowanie, a analiza danych od klientów spychana jest na dalszy plan. Warto więc zwrócić uwagę, czy zespoły rzeczywiście korzystają z możliwości pozyskiwania feedbacku. Jeśli nie – warto zrozumieć, co stoi za takim podejściem i co sprawia, że mimo dostępnych danych, zespoły po nie nie sięgają.

Znajdź czas na pracę 1 na 1 ze swoimi ludźmi

To wskazówka z innego poziomu – bardziej managerska – ale niezwykle istotna. Choć może wydawać się oczywista, nasze doświadczenia pokazują, że takie rozmowy nie odbywają się tak często, jak mogłyby. Wiele osób pracujących w rolach produktowych lub technologicznych, zwłaszcza na poziomie zespołów, przyznaje, że ich przełożeni nie znajdują dla nich czasu. Słyszymy komentarze w stylu: „Mój szef za bardzo ze mną nie rozmawia” albo „Nie ma dla mnie czasu”.

Mówiąc o rozmowach jeden na jeden, mamy na myśli regularne spotkania – najlepiej raz w tygodniu lub co dwa tygodnie. Tymczasem w wielu organizacjach takie rozmowy odbywają się co kwartał lub jedynie podczas oficjalnych podsumowań. Trudno oczekiwać, że zespół przejdzie naturalną drogę od braku odpowiedzialności do jej pełnego przejęcia, jeśli nie ma okazji do regularnych rozmów, wymiany myśli i wspólnego reflektowania nad pracą.

Rozmowy z przełożonym, który staje się mentorem i inspiruje do działania, mają ogromne znaczenie. Co ważne, to niewielka inwestycja – wystarczy poświęcić czas i pełną uwagę,. Dlatego szczególnie zachęcamy do wprowadzenia tej praktyki, zwłaszcza jeśli do tej pory takich spotkań nie organizujesz. Regularny dialog to jedno z najprostszych, a zarazem najskuteczniejszych narzędzi budowania odpowiedzialności i zaangażowania w zespole.

Każdy ma swój styl prowadzenia rozmów jeden na jeden. Są jednak dwa kluczowe elementy, które warto w takich spotkaniach uwzględnić.

• Pierwszy to pytania o bieżące wyzwania, potrzeby i rozterki danej osoby. Chodzi o to, by skupić się na konkretnej osobie i zrozumieć, z czym aktualnie się mierzy. 
• Drugi element to regularne przekazywanie informacji zwrotnej – bez odkładania jej na później. Zamiast czekać na półroczne czy roczne podsumowania, warto reagować na bieżąco. Jeśli zauważysz coś istotnego, rozpocznij rozmowę jak najwcześniej i w spokojnej atmosferze.

Tego typu spotkania to również świetna okazja, by poruszyć tematy, o których mówiliśmy wcześniej: przypomnieć strategię, wyjaśnić podjęte decyzje – zwłaszcza te mniej popularne – czy omówić popełnione błędy i wyciągnięte z nich wnioski. 

Stwórz ścieżki rozwoju dla członków zespołu

To wskazówka mocno managerska, wynikająca z częstego przekonania, które często słyszymy od osób kierujących zespołami: „Mój zespół nie może dostać większej odpowiedzialności, bo jeszcze nie jest na to gotowy.” Taka opinia zwykle opiera się na konkretnej historii – może dotyczyć zbyt małego doświadczenia, braku udziału w dużych inicjatywach lub niewystarczająco rozwiniętych umiejętności. Czasem odnosi się do pojedynczych Product Ownerów, czasem do liderów zespołów, a bywa, że dotyczy całych struktur.

Rozwiązaniem tego problemu jest zaplanowany, długofalowy rozwój członków zespołu. Chodzi o to, by już na etapie zatrudnienia – nawet przy przyjmowaniu juniora – mieć wizję tego, jak dana osoba może się rozwijać. Może dziś nie jest gotowa, może za dwa lata wciąż będzie potrzebować wsparcia, ale z odpowiednim planem i pracą za pięć lat może stać się kluczowym członkiem zespołu gotowym na większą odpowiedzialność.

W niektórych organizacjach od razu zatrudnia się doświadczonych specjalistów. W innych – ze względu na budżet, specyfikę firmy lub sytuację rynkową – nie zawsze jest to możliwe. Bez względu na podejście, warto rozwijać pracowników nawet wtedy, gdy są już na wysokim poziomie. Dobrze zaplanowana ścieżka rozwoju pozwala im osiągać kolejne szczeble kariery i przejmować coraz bardziej odpowiedzialne role.

Zarządzając zespołem, warto również myśleć o budowaniu następców. To ważne zwłaszcza dla osób na wyższych stanowiskach managerskich. Brak kogoś, kto może przejąć obowiązki, często blokuje awanse. Z kolei posiadanie przygotowanego następcy otwiera drzwi do nowych możliwości – zarówno dla przełożonego, jak i dla całej organizacji.

Ścieżki rozwoju mogą być w różnych firmach traktowane na wiele sposobów. Często mają one charakter ogólny – na przykład dla Product Managera istnieje jasno zdefiniowana ścieżka z poziomami rozwoju, od juniora do eksperta. To podejście jest pomocne, ale nie wyklucza bardziej indywidualnego podejścia do rozwoju konkretnej osoby.

Pracując z członkami zespołu jeden na jeden, warto ustalać także spersonalizowane cele. Jacek w swojej pracy managerskiej, gdy zarządzał strukturą Product Ownerów, stosował właśnie takie podejście. Oprócz standardowej ścieżki rozwoju, opracowanej we współpracy z działem HR, Jacek uzgadniał z poszczególnymi osobami dodatkowe cele dopasowane do ich bieżących wyzwań i potrzeb. Te indywidualne cele nie były sprzeczne ze ścieżką rozwoju – raczej ją uzupełniały, wypełniając najważniejsze luki kompetencyjne.

Jak dojść do tego, co warto rozwijać? Kluczowe są rozmowy oraz moja dobra znajomość projektów, w których dana osoba uczestniczy. Dzięki temu łatwo jest określić, jakie konkretne umiejętności są potrzebne w danym momencie. Ustalasz wspólnie, co należy wzmocnić, wyznaczasz ramy czasowe i określasz, jakie wsparcie będzie potrzebne, aby osiągnąć zamierzony cel.

Zaplanuj proces wzmacniania odpowiedzialności

Wspomnieliśmy już o tym wcześniej, ale ten punkt podkreśla, że przekazywanie odpowiedzialności nie jest czymś, co wydarzy się z dnia na dzień. To proces zmiany, którym warto świadomie zarządzać. Przede wszystkim potrzebna jest decyzja, że chcesz nad tą zmianą pracować. Kluczowe będzie przeprowadzenie rozmów z osobami, których ta zmiana dotyczy. Ich zrozumienie i wsparcie są niezbędne, a na drodze pojawi się zapewne wiele wątpliwości, które należy zaadresować.

Budowanie odpowiedzialności wiąże się również z koniecznością zdobycia odpowiedniej wiedzy i umiejętnością jej praktycznego wykorzystania. Istotne jest także monitorowanie efektów tego procesu. Warto celebrować momenty, w których wzmocnienie odpowiedzialności przyczynia się do widocznych sukcesów zespołu. Jednocześnie należy być przygotowanym na sytuacje, w których zmiany nie przynoszą oczekiwanych rezultatów – wtedy dobrze mieć gotowy plan działań korygujących.

Jednym z elementów planowania procesu przekazywania odpowiedzialności może być jawne pokazanie uprawnień decyzyjnych. Warto określić, kto i w jakich sytuacjach ma prawo podejmować decyzje. Czasami zespół może decydować od razu, innym razem uprawnienia te będą przekazywane stopniowo, w miarę rozwoju kompetencji.

W praktyce pomocne może być narzędzie Delegation Board – jedno z rozwiązań proponowanych w nurcie Management 3.0. Pozwala ono jasno wypisać konkretne przypadki i obszary, w których podejmowane są decyzje. Celem jest osiągnięcie pełnej przejrzystości oraz uniknięcie nieporozumień w zespole. Taki dokument może również stać się punktem wyjścia do długofalowej rozmowy o tym, co musi się wydarzyć, by zespół mógł decydować samodzielnie, a także w jakich sytuacjach potrzebna będzie konsultacja czy akceptacja przełożonego.

Zachęcamy do tego, by nie odkładać tego tematu i nie zakładać, że odpowiedzialność „zbuduje się sama”. Warto podejść do niej świadomie, stopniowo przekazując ją poszczególnym osobom lub zespołom, wspierając ich rozwój i jednocześnie dbając o stabilność całej struktury.

W ramach tego punktu przypomina nam się sytuacja z początków pracy jako konsultanta w 202 Procent. Wspieraliśmy wtedy firmę, która mierzyła się z interesującym problemem. Product Ownerzy twierdzili, że nie mają odpowiedzialności, natomiast osoba z zarządu odpowiedzialna za ich pracę komunikowała, że „oni w ogóle nie biorą odpowiedzialności”. Sprzeczne sygnały z obu stron były dość zaskakujące.

Rozwiązaniem okazały się dwie rozmowy z wykorzystaniem narzędzia Delegation Board, o którym wspominaliśmy wcześniej. Technika ta pomogła wyjaśnić wzajemne oczekiwania: Product Ownerzy uświadomili sobie, że mają znacznie większe możliwości decyzyjne, niż zakładali, a osoby zarządzające zobaczyły, że można bez obaw przekazać część odpowiedzialności zespołom.

To pokazuje, że temat ten wcale nie jest oczywisty. Warto o nim rozmawiać i doprecyzować, gdzie leżą granice odpowiedzialności – dla dobra obu stron i sprawniejszego funkcjonowania organizacji.

Podsumowując, wzmacnianie odpowiedzialności za produkt przez szefa produktu polega na wyznaczaniu ambitnych celów, regularnym przypominaniu strategii firmy i produktu, angażowaniu zespołów w kreowanie rozwiązań oraz wyjaśnianiu kontekstu biznesowego podejmowanych decyzji.

Równocześnie warto umożliwiać eksperymentowanie i dbać o to, żeby z tych eksperymentów były wyciągane wnioski. Kluczowe jest oczekiwanie efektów zamiast realizowania sztywnych zakresów. Pomocne może być również zapewnienie zespołom dostępu do feedbacku od klientów, regularna praca jeden na jeden oraz stworzenie ścieżek rozwoju.Jeżeli Twoja firma korzysta z technik pracy zespołowej inspirowanej Scrumem i masz poczucie, że efektywność pracy twoich zespołów wymaga poprawy, odezwij się do nas po diagnozę i eksperckie rekomendacje dotyczące procesu wytwórczego. Dopasujemy nasze porady do konkretnego kontekstu Twojej firmy i wesprzemy zmiany, których potrzebujesz. Sprawdź naszą ofertę na stronie porzadnyagile.pl/diagnoza.

Dodatkowe materiały

Wzmacnianie odpowiedzialności zespołu za produkt

📄Transkrypcja podcastu „Jak szef produktu buduje odpowiedzialność zespołów?”

Poniżej znajdziesz pełny zapis rozmowy z tego odcinka podcastu „Porządny Agile”.

Jacek: Dawno temu nagraliśmy z Kubą odcinek o budowaniu odpowiedzialności za produkt. Ale był to odcinek kierowany bardziej do Product Ownerów i do Scrum Masterów. Znajdziesz go pod adresem porzadnyagile.pl/31. Tytuł brzmiał: „Wzmacnianie odpowiedzialności zespołu za produkt”. Był to jeden z naszych ostatnich odcinków przed covidem, przed lockdownem. Pamiętam nagrywany w aucie zaparkowanym gdzieś w jakimś lasku koło opuszczonej żwirowni. Dzisiaj chcemy nagrać w trochę innych realiach podobną tematykę, ale adresowaną świadomie do osób zarządzających kilkoma zespołami, kilkoma produktami czy większą strukturą produktową.

Kuba: Mamy dla Ciebie 10 porad na temat tego, co zarządzający taką strukturą produktową może zrobić, żeby zbudować odpowiedzialność zespołów wytwórczych za produkt, którym się zajmują te jego zespoły.

Jacek: Spis treści na dzisiaj jest następujący. Jakie mamy porady dla szefa produktu, by budować odpowiedzialność zespołów? Wyznaczaj ambitne cele. Nieustannie przypominaj strategię firmy i produktu. Włączaj zespoły w kreowanie rozwiązań. Wyjaśniaj kontekst biznesowy swoich decyzji.

Kuba: Pozwalaj eksperymentować i popełniać błędy. Oczekuj efektów, a nie dowożenia zakresów. Zapewnij zespołom dostęp do feedbacku od klientów. Znajdź czas na pracę jeden na jeden ze swoimi ludźmi. Stwórz ścieżki rozwoju dla członków zespołu i zaplanuj proces wzmacniania odpowiedzialności.

Jacek: I mówimy w tym odcinku szef produktu i sobie to tak zdefiniowaliśmy, że w ten sposób będziemy komunikować, o kim myślimy, podczas nagrywania tego odcinka. Natomiast to może oznaczać zbiór bardzo różnych funkcji, które przyjmują różne nazwy w filmach. To może być Chief Product Owner, to może być jakiś taki wyżej gdzieś zamocowany Product Manager, to może być osoba, która ma tytuł Head of Product, to może być Product Director, to może być Head of Product and Technology, więc jakby bardzo pojemna grupa osób, których dla uproszczenia, no bo każda struktura jest inna, nazywamy po prostu szefem produktu. Opisowo chodzi nam tutaj o osoby, które zarządzają Product Ownerami, Product Managerami, całymi zespołami rozwijającymi produkt. Osoby, które są odpowiedzialne nie tylko za poszczególny produkt czy produkty, ale też za cały proces wytwarzania, strukturę, która jest z tym procesem powiązana oraz pewną filozofię, filozofią zarządzania rozwojem.

Kuba: Ok, to przechodząc do konkretu, pierwsza porada z naszej strony. Jak szef produktu może wzmocnić odpowiedzialność zespołów za produkt?

Jacek: Pierwsza porada, którą przygotowaliśmy, brzmi wyznaczaj ambitne cele. Wszystko zaczyna się od konkretnego, ambitnego, namacalnego celu i chcemy tutaj podkreślić, że warto w tej kwestii być wizjonerem, pokazywać trochę dalszy obrazek niż być może zespoły na ten moment są w stanie zobaczyć. To jest też powiązane z tym, że chcielibyśmy oczekiwać więcej i sprawiać, że zespół w kontekście rozwiązywania tego ambitnego celu będzie musiał poszukać jakiegoś mniej oczywistego rozwiązania. Czyli troszeczkę się napracować i troszeczkę się zastanowić, jak do tego rozwiązania podejść, co jak słyszysz, już jest pewną taką zachętą do tego, żeby wziąć sprawy w swoje ręce, żeby tą odpowiedzialność budować. Te rozwiązania mogą być nieoczywiste, natomiast może jest jakieś ograniczenie czasowe i trzeba się zastanowić, jak przy ograniczonym czasie stworzyć coś, co ma sens. Może będzie trzeba dokonać jakichś radykalnych uproszczeń, może będzie trzeba sięgnąć na jakąś nową technologię, albo zrobić coś, co z perspektywy organizacji, w której jesteś, jest nieoczywiste, jest nowe, jest czymś zupełnie zaskakującym i świeżym.

Kuba: A jeśli czujesz, że żaden z tych przypadków wymienionych przez Jacka akurat u Ciebie nie ma miejsca, to tym bardziej ta porada jest dla Ciebie, bo być może z perspektywy szefa produktu trochę tę sytuację trzeba utworzyć, zasymulować, tak troszkę sprowokować czy postawić zespoły w takiej sytuacji, w której jednak ten ambitny cel się pojawia. Bo mamy tu na myśli odwrócenie tej sytuacji, taką niekorzystną sytuację, gdy zespoły są takie troszkę rozleniwione, nie mają wyzwań, te cele, które są przed nimi, są takie miałkie, takie lightowe, takie letnie. No i wtedy te cele, brak tych ambitnych celów między innymi przyczynia się do jakiegoś takiego rozluźnienia i takiego poczucia, dobra, zrobię swoje, jakoś to tam się wszystko później złoży, będzie dobrze. A sami mamy doświadczenia bardzo pozytywne z bardzo różnych organizacji, że coś, co jednak jest jakimś rodzajem wyzwania, w tym pozytywnym znaczeniu nie problemu, tylko jakiegoś rodzaju pewnej dosyć ambitnej aspiracji, są jednym z takich bazowych fundamentów tego, że zespół jednak musi się ogarnąć, zebrać, nie żartować z pewnymi sprawami, wysilić, poszukać kreatywności i w efekcie faktycznie wziąć sprawę w swoje ręce i spróbować osiągnąć coś, co może na pierwszy rzut oka wydaje się trochę za duże, za trudne albo za krótki horyzont czasowy.

Kuba: Druga porada. Nieustannie przypominaj strategię firmy i produktu. Z zasady w tej poradzie przyjmujemy założenie, że ta strategia i dla firmy, i dla produktu jest i to w większości organizacji jest prawda, ale też dla wielu organizacji prawdą jest to, że ta strategia firmy i produktu, choć żyje na wyższych poziomach zarządzania i jest jakąś codziennością, to niekoniecznie jest znane na pamięć i niekoniecznie żyją tym konkretne zespoły czy konkretne osoby będące liderami pierwszych poziomów. Dlatego rolą szefa produktu może być ciągłe, nieustanne, może nawet troszkę nadmierne z tej perspektywy tej osoby przypominanie, co jest w tej strategii i dlaczego jest właśnie to w strategii. Może też z taką dopowiedzią, a czego nie ma, albo jak pewne tematy się ze sobą łączą, czy pewne decyzje się układają. Ale o decyzjach jeszcze powiemy za chwilę.

Jacek: Teraz nieustanne przypominanie, ja bym to tak nazwał, że to jest takie łączenie kropek pomiędzy tym, co organizacja chce strategicznie osiągnąć i dokąd zmierza, a tym, co się dzieje faktycznie na poziomie zespołu, gdzie jednak ludzie patrzą na prace trochę bardziej z perspektywy, jakieś zadań, tasków, może patrząc nawet trochę wyżej pewnych być może jednak projektów, inicjatyw czy zmian, które są realizowane w produkcie. Natomiast brak tego połączenia może powodować, że pewne decyzje będą niezrozumiałe, pewne rozwiązania będą stworzone nie tak dobrze, jak mogłyby być stworzone, gdyby ktoś rozumiał bardzo dobrze, w jaki sposób to będzie wykorzystywane, dlaczego to robimy tak, a nie inaczej, czy też łatwiej jest zrozumieć decyzję, że z pewnych rzeczy rezygnujemy, chociaż ktoś mógłby mieć apetyt na to, żeby jakieś konkretne funkcje do produktu dołożyć. Więc znajomość tego, jaka jest strategia firmy, jaka jest strategia produktu, pomaga podejmować decyzje i też umożliwia budowanie poczucia odpowiedzialności. No bo tak naprawdę zaczynamy rozumieć, po co to wszystko się dzieje.

Jacek: Trzecia porada dla szefa produktu to włączaj zespoły w kreowanie rozwiązań. Myślę, że taką główną myślą, która stoi za tą poradą, jest myśl, żeby nie traktować zespołów jak podwykonawców, czyli taką grupę, której zleca się bardzo precyzyjnie, co jest do zrobienia no i oczekujemy, że po prostu zostanie ta praca wykonana. A raczej chciałbym tutaj mieć raczej do współpracy zespół, który ma pewną samodzielność, ma pewną świadomość i chciałbym pozwolić takiej grupie nie tylko wykonywać pracę, ale też rozumiejąc strategię firmy, produktu, rozumiejąc cel, kreować rozwiązania. Kreować najlepsze możliwe rozwiązania, biorąc pod uwagę dostępny czas, dostępne możliwości, ale też pewne szanse czy ograniczenia, które wynikają z technologii. Nikt lepiej, jak dobrze skonstruowany zespół wytwórczy, nie będzie w stanie podjąć pewnych decyzji. Bo są to decyzje zwykle dosyć niskopoziomowe, które po prostu mogą być troszeczkę poniżej radaru osób znajdujących się powyżej poziomu zespołów.

Kuba: Oznacza to też, że zespoły mogą być włączone w proces budowania Roadmap’y, w jakiś mocny sposób konsultowane też w tym procesie kreowania celów, konkretnych większych inicjatyw, które to są zrobienia czy pewnych kroków rozwojowych, jakie te zespoły mogą zrealizować. Natomiast takie zastrzeżenie, gdy rozmawiam w guście tej porady z niektórymi zarządzającymi, to często widzę, że mój rozmówca słyszy takie bardzo zero-jedynkowe podejście, że nie, nie będę ich włączał, bo oni źle to wymyślą. Jednak akcent położymy na to, jak brzmi ta porada, włączaj zespoły, a nie przerzuć całość zespołom. W większości organizacji pewnie będzie to nie do końca realne, żeby całkowicie oddelegować temat rozwiązań na zespoły i zostawienia im pełnej swobody. Jeśli w twojej organizacji tak jest, to gratuluję. W większości organizacji jednak jest w trochę innym miejscu. No i tutaj mamy na myśli jakiś rodzaj bycia współrealizatorem pewnego procesu. Zarówno wyższy zarządzający, zespoły, liderzy produktów w tych zespołach, wszyscy razem mogą być w jakiś mądry i ciągle doskonalony sposób angażowani, włączani w to, żeby uniknąć tego, od czego Jacek zaczął, czyli takiego zjawiska po prostu zlecenia zespołom z góry zamkniętego kawałka rozwiązania.

Kuba: Czwarta porada, wyjaśniaj kontekst biznesowy swoich decyzji. Trochę już to zaznaczyliśmy przy strategii i tutaj jakby temat wraca. W czasie rozwoju produktu będzie wiele decyzji biznesowych, niektóre z nich niezrozumiały dla zespołu, niektóre być może sprzeczne z poprzednimi decyzjami. Będą też decyzje bardzo niepopularne, żeby tutaj z najgrubszego kalibru rzucić rzeczy. Zamknięcie produktu, rezygnacja z pewnego segmentu rynkowego, do którego przestajemy adresować nasze rozwiązania, czy na przykład decyzja o tym, że jakiś inny produkt, jaki jest w portfelu tej organizacji, przejmuje jakiś kawałek biznesu. To są wszystko rzeczy, które powodują sporą demotywację w zespołach. Mogą być też jawnie lub niejawnie sabotowane, czy powodować jakieś błędne zachowania w zespołach. Dlatego tutaj mocna porada, mocna przestroga. Wyjaśniaj te decyzje, pokaż większy obrazek. Pokaż to, co dla Ciebie jest oczywistością, bo zapadła taka decyzja i wiesz, dlaczego tak jest. Ale w zespołach może to być niezrozumiane, źle odebrane i na tej bazie akurat demotywująco działać na zespoły. Ale w drugą stronę też może to zadziałać, czyli jeśli są jakieś ciekawe, fajne potencjały, to pokażmy tę szansę. Pokażmy, dlaczego zapadła pewna też pozytywna decyzja, żeby zespoły poczuły ten sam smak satysfakcji, czy jakiejś takiej emocji pozytywnej, jaką też Ty czujesz w tej sytuacji.

Jacek: I długoterminowo patrząc na tę poradę, no to po pewnym czasie zespoły będą o wiele lepiej rozumieć środowisko biznesowe, w którym się poruszają, doskonale wiedząc, dlaczego z pewnych rzeczy rezygnujemy, doskonale rozumiejąc, dlaczego pewne rzeczy powinniśmy realizować w jakiś tam konkretny sposób. Myślę, że nie ma nic bardziej demotywującego, niż komunikat z góry od teraz jest tak, bez wyjaśnienia kontekstu. Wielokrotnie doświadczałem frustracji w zespołach, które w pewnym momencie już po prostu zaczynają podśmiechiwać się i tak trochę sarkastycznie z przekąsem komentować, że cokolwiek powiedzą to zrobimy, no i po prostu robią swoje, ale to nie jest taki zespół, o którym my w tym odcinku mówimy, to nie jest zespół, który jest odpowiedzialny, który jest zmotywowany, tylko niestety każda taka bezkontekstowa decyzja, niewyjaśniona raczej moim zdaniem, spycha ich na tę stronę. Będziemy robić to, co nam każą i w sumie nie interesuje nas rezultat końcowy.

Jacek: Piąta porada, pozwalaj eksperymentować i popełniać błędy. Jest to taka porada, która jest powiązana z tym, że odpowiedzialność, czy jak przy przekazywaniu odpowiedzialności, budowanie odpowiedzialności jest pewnym procesem, no i musisz być gotowy na to, że decyzje, które będą podejmowane przez zespół, nie zawsze będą idealne, nie zawsze będą właściwe. Mogą pojawić się błędy, mogą pojawić się drogi, które okażą się ślepymi uliczkami, ale to jest część procesu. Oczywiście należy przemyśleć, jakie decyzje dawać zespołowi w pierwszej kolejności, na początku ich przygody. No i pewnie będą to decyzje czy zmiany mniejszego kalibru, które spowodują, że nawet jeżeli zespół się potknie, nawet jeżeli popełni błąd, jeżeli wyjdzie na przykład w procesie wytwarzania jakiejś zmiany, że zabrakło pewnego kontekstu, która dla Ciebie jest oczywista, no to nadal to jest OK. W tej poradzie zachęcamy do tego, żeby była przestrzeń na eksperymenty, żeby zespół poczuł pewną autonomię, że mogą, że ktoś im ufa, żeby troszeczkę ich też, tak bym powiedział, rozkręcić w tym, żeby coraz śmielej funkcjonować. No ale pamiętajmy nadal, jako szef produktu jest też bezpiecznikiem, który zapewnia, że z tego nie zrobi się jakieś YOLO i podejmowanie losowych decyzji. No tylko, że jednak to będzie pewien uporządkowany proces i odpowiedzialność stopniowo i w jakiś tam konkretny, sensowny, zaplanowany sposób będzie na poziomie zespołu się zwiększać.

Kuba: A ja tak trochę z przekąsem zaakcentuję mocniej, że w poradzie są dwa zjawiska łącznie, czyli eksperymentowanie i popełnianie błędów, bo eksperymentowanie przychodzi z łatwością, zgoda na eksperymentowanie, ale niekoniecznie łatwo idzie za nią zgoda na to, że mogą się pojawić błędy. Jak patrzę na organizacje, w których ta odpowiedzialność produktowa nie jest na wystarczającym poziomie, to jednym ze zjawisk, jak się zaczynam pytać głębiej, z czego wynika to, że na przykład nie bierzecie na siebie pewnych decyzji, albo boicie się zaryzykować, boicie się wejść w coś bardziej kreatywnego niż takie z góry zlecone kawałki, to dosyć często się pojawia jednak jakieś wspomnienie, na przykład niekorzystnych reakcji na to, że jednak ta decyzja była błędna, jednak jakiś pomysł produktowy nie wyszedł, jakieś rozwiązanie procesowe okazało się kłopotliwe albo wręcz szkodliwe. Więc tutaj bardzo ważne komunikaty, które warto ciągle powtarzać, to to, że zwłaszcza jeśli zespół ma być innowacyjny, kreatywny, jeśli zespół ma brać na siebie pewne ryzyko, to częścią tego ryzyka również będzie popełnianie błędów i to jest ok, że te błędy są popełnione. Ważne, że z nich są wyciągnięte wnioski, więc to, co Jacek na samej końcówce mówiłeś, że jest jakby systematyczność pewna, to nie chodzi o systematyczność w unikaniu błędów, tylko systematyczność w tym, żeby błędy dawały wnioski. Czyli bardziej nie dopytuj, dlaczego popełniono błąd, a może większy nacisk postaw na to, czego nauczyliście się z tego błędu i może ewentualnie i co zrobicie, żeby ten błąd się nie powtórzył. Zwłaszcza jeśli to jest coś procesowego, bo eksperymenty z rynkiem pewnie ciągle będą miały przygody, ale już zwłaszcza takie rzeczy, że popełniliśmy jakiś błąd i z tego powodu mieliśmy awarie, to to jest dobry temat. Ok, to, czego się nauczyliście i na tej bazie co zrobicie, żeby to już się nie powtórzyło albo żeby nawet podobne przypadki również przewidzieć i uniknąć ich w przyszłości.

Kuba: I, zanim przejdziemy do szóstej porady, przypominamy, że jeżeli chcesz pogłębić wiedzę jeszcze bardziej, niż robimy to w podcaście, to nasze płatne produkty znajdziesz na stronie porzadnyagile.pl/sklep.

Jacek: Szósta porada, oczekuj efektów, a nie dołożenia zakresów. Esencją tej porady jest taka myśl, że zupełnie inaczej funkcjonują zespoły, które od A do Z mają rozpisane dokładnie, co mają zrobić, a zupełnie inaczej zespoły, którym stawiamy poprzeczkę wyżej. Czyli na koniec dnia nie interesuje mnie, w jaki sposób zrealizujecie pewne założenia, mnie tak naprawdę interesują efekty. W momencie, kiedy przekazujemy tę odpowiedzialność, że jest pewien efekt do osiągnięcia, a w zespole, po stronie zespołu pozostaje decyzja, w jaki sposób do tego dojdziemy, to to jest to miejsce, gdzie zaczyna się rodzić odpowiedzialność. Rodzą się pewne pomysły, rodzą się pewne koncepcje, zespół czuje więź z tymi pomysłami, to jest ich, zależy im na tym no i jest zupełnie inny poziom zaangażowania, zupełnie inny poziom podejścia do pracy. Jeżeli to jest nasze, jeżeli mamy na to wpływ, bo wtedy każdy mały sukces cieszy, każda porażka jest odbierana tak bardzo osobiście, na zasadzie musimy to zrobić lepiej za kolejnym razem. No i niestety nie obserwuję tak głębokiego zaangażowania, jeżeli zespół jest po prostu w trybie klepania tasków. Robią, wyjdzie dobrze, nie wyjdzie trudno i to jest to miejsce, gdzie można bardzo dużo ugrać, przesuwając suwaczek trochę mocniej w stronę tego, że to zespół decyduje, w jaki sposób pewne rzeczy zostaną zrealizowane. 

Kuba: I zarządzającym bardzo łatwo zgodzić się z tą poradą, a może nawet wielu ma odruch, przecież już od dawna to stosuje, natomiast w praktyce może czasami tkwić pewien diabeł w tych szczegółach. Użyje takiego dosyć wymyślonego przykładu, to nie jest powiązane z żadnym z klientów, z którym współpracuję. Wielu zarządzających niestety myśli, że np. dodanie pewnej funkcji do aplikacji to jest efekt, a to jest tylko i wyłącznie pewien zakres albo jakiś uogólniony kawałek zakresu. No bo efektem będzie np. dodatkowa sprzedaż, która ta funkcja w tej aplikacji uruchomi. Dajmy zespołom wymyślić się jakieś ścieżki na skróty, dajmy im możliwość odcięcia pewnych wyobrażeń, nawet jeśli jest mocne przypuszczenie, że pewne kawałki zakresu są superważne, niech priorytetem, niech taką osią wszystkiego, co zespół realizuje, są rezultaty biznesowe. I wracając do tej aplikacji, może też jest często tak, zwłaszcza w zespołach technologicznych, które są częścią większych struktur, większych organizacji, no to dochodzi też do takiego uproszczenia, postawcie mi platformę, zbudujcie tą appkę albo dodajcie coś do appki jako efekt oczekiwany, a nie to, że na tym wszystkim ma być zbudowany pewien biznes. I zwłaszcza jeśli tym efektem ma być np. pierwsza sprzedaż na tej platformie, funkcjonowanie jakichś puli klientów na tej aplikacji lub faktyczny dochód z jakichś funkcji, które są sprzedawane, to też fajnie to otwiera czy rozszerza perspektywę, że to wszystko, co zespół technologiczny zrobi, musi być jeszcze opakowane w marketing, w sprzedaż, we wsparcie, w oprawę prawną, co bardzo mocno wraca do naszego odcinka o wsparciu czy zbliżeniu współpracy biznesu i IT.

Kuba: Siódma porada brzmi, zapewnij zespołom dostęp do feedbacku od klientów. Istotą tego jest to, żeby zespół miał stały dostęp, regularne jakieś rozwiązania, narzędzia, systemy do feedbacku od klientów. Feedback od klientów jest istotą takiej pracy w poczuciu odpowiedzialności, ale nie chodzi nam w tej poradzie wyłącznie o to, że okazjonalnie jest jakiś wgląd w jakieś badanie, albo raz na jakiś czas zrobimy jakąś grupę fokusową, czy zapytamy parę osób, tylko o to, żeby tak ustawić system, tak rozwiązać jakieś narzędzia, struktury, całą filozofię zarządzania, całą organizacją, żeby zespoły miały na wyciągnięcie ręki temat feedbacku. Możliwość konsultacji, możliwość iterowania z rynkiem, włącznie z tym, co jest dopiero jeszcze w trakcie, ale również z rozwiązaniami, które już od dawna są funkcjonujące. Czyli zerwanie z ideą, zrealizowania tej pracy tak bardzo projektowo, wymyślić, wdrożyć i zapomnieć, ale bycie w takim ciągłym kontakcie. Ciągłe pamiętanie o tym, kto jest tym klientem docelowym. I teraz można tego oczekiwać od zespołów, żeby w ten sposób myślały, ale tutaj szef produktu może zrobić wiele, żeby w całej organizacji po prostu były do tego rozwiązania, które zapewniają, że zespoły stale łatwo dostają dostęp do informacji zwrotnej. I to tej informacji zwrotnej, tej prawdziwej, która się liczy. Nie od szefa, prezesa, członka zarządu, czy innej ważnej osoby z ważnego gabinetu, tylko od tych prawdziwych klientów docelowych.

Jacek: Tak, i tu dwa komentarze do tego. Taka trochę parafraza tej ostatniej myśli, Twojej Kuba, czyli im bardziej to jest bezpośredni, oryginalnie brzmiący feedback, a nieprzekształcony przez jakiś tam głuchy telefon, tym lepiej. Czyli konkretne słowa, których używa klient, te konkretne ankiety, ten konkretny człowiek, z którym mogę porozmawiać, a nieprzefiltrowane, no bo to zawsze będzie jakiś tam efekt już zniekształcający. Natomiast druga sprawa, ta porada też brzmi tak bardzo, oczywiście na zasadzie, w czym problem. Spotkałem wiele firm, w których był dostęp do takich feedbacków i do klientów, natomiast systemowo praca zespołów była tak zorganizowana, że nikomu do głowy nie przyszłoby marnować czas, no bo tak naprawdę cały system krzyczy, masz programować, masz robić testy, masz tworzyć designy i takie sięgnięcie do tych danych może być traktowane jako strata czasu, jako coś nie na teraz, na kiedyś, na później. Więc z jednej strony banalna porada, a z drugiej zwróć uwagę, czy ludzie korzystają z tej możliwości. Jeśli ludzie nie korzystają, to myślę, że bardzo ciekawe może być zrozumienie przyczyn, dlaczego jest tak, że mamy te dane, ale jednak z jakiegoś powodu do nich nie sięgamy.

Jacek: Kolejna porada, znajdź czas na pracę jeden na jeden ze swoimi ludźmi. Jest to taka porada troszeczkę z innego poziomu, porada taka bardziej managerska, natomiast bardzo ważna i bardzo istotna. Również może się wydawać, że to jest oczywiste, jednak obserwacja nasza z Kubą jest taka, że jednak te rozmowy jeden na jeden nie są tak często prowadzone, jak mogłyby być. Ja osobiście spotykam wiele osób, które są w rolach produktowych, czy w rolach technologicznych na poziomie zespołów. No i smutny komentarz od tych osób, które słyszę, jest taki, że za bardzo mój szef ze mną nie rozmawia, za bardzo nie ma dla mnie czasu. Jak ja mówię o jeden na jeden, to bardziej mam na myśli taką częstotliwość w stylu raz na tydzień, raz na dwa tygodnie, a tam częściej słyszę raz na kwartał, albo rozmawiamy na podsumowaniach. Trudno jest oczekiwać, że nastąpi jakaś zmiana, że zespół będzie poddany jakiejś tam dłuższej ścieżce zdrowia pod tytułem, no dzisiaj nie bierzemy odpowiedzialności, ale kiedyś byśmy chcieli jednak, żeby ta odpowiedzialność rosła, jeżeli ktoś nigdy wcześniej tego nie robił. W takim momencie możliwość usłyszenia tego od przełożonego, który może stać się mentorem, osobą, która inspiruje, jest nieocenione. I z drugiej strony jednak dosyć tanie, w sensie no potrzebujemy tylko czas i skupienie na to, żeby tę mądrość transferować, inspirować, żeby po prostu rozmawiać. Natomiast tak jak mówię, nie jest to zbyt oczywiste, więc jakby do tej porady tak osobiście czuję, że w szczególności chciałbym Cię zachęcić, jeśli teraz takich rozmów jeden na jeden nie prowadzisz.

Kuba: I każdy ma swój styl realizacji takich jeden na jeden. Natomiast jeśli miałyby być dwie rzeczy, które warto w tego typu spotkaniach uwzględnić to jakieś rodzaj pytania o to, jakie są bieżące rozterki, jakie są bieżące potrzeby czy wyzwania tej konkretnej osoby, bo to jeden na jeden tej konkretnej osoby, z którą się aktualnie pracuje. No i druga rzecz to bieżące przekazywanie informacji zwrotnej. Nie kiszenie tego, nieczekanie na jakiś tam cykl półroczny, roczny, czy jaki funkcjonuje w danej organizacji HR-owo. Tylko jednak jeśli jest coś, co się zauważa, to przekazanie czy rozpoczęcie pewnej rozmowy tak wcześniej, tak spokojnie jak to tylko możliwe. Co się wiąże bardzo mocno z wieloma innymi poradami z tego odcinka, że tak naprawdę wiele z tych wątków to się świetnie nadaje na to, żeby w trakcie właśnie rozmowy jeden na jeden wyjaśnić, czy przypomnieć strategię, wyjaśnić podjęte niepopularne decyzje, porozmawiać o popełnionych błędach i wnioskach z nich wynikających. To są wszystko rzeczy, które się świetnie realizuje właśnie w formacie jeden na jeden.

Kuba: Przedostatnia porada, którą mamy, to stwórz ścieżki rozwoju dla członków zespołu. Też porada bardzo managerska, ale wynikająca z pewnego bardzo poważnego założenia, które bardzo często słyszę. „Mój zespół nie może dostać większej odpowiedzialności”, to cytat z jakiejś osoby zarządzającej pewną większą strukturą, ponieważ oni nie są jeszcze na to gotowi. I tu się pojawia jakaś konkretna szczegółowa historia o tym, że na przykład są jeszcze zbyt młodzi, albo jeszcze nie wzięli udział w takiej wielkiej inicjatywie. To może dotyczyć pojedynczych Product Ownerów, to może dotyczyć konkretnych liderów zespołów, albo nawet i całych struktur zespołów, gdzie na przykład w całym moim zespole nie ma wystarczająco mocnych osób, żeby zdelegować im odpowiedzialność za rozwiązanie, więc muszę się mocno w to angażować. No i tutaj rozwiązanie bardzo długofalowe oczywiście to, żeby rozwój tych osób był zaplanowany, było to przewidziane, żeby tak naprawdę już od świeżo zatrudnionego juniora mieć tę perspektywę, że teraz jeszcze nie i za dwa lata też jeszcze nie, ale już za pięć, być może ta osoba będzie na tyle cierpliwie rozwijana, będzie na tyle z nią prowadzona pewna praca i przechodzenie przez kolejne stopnie, żeby tą odpowiedzialność mogła na siebie wziąć i w efekcie całe zespoły mogły też tę odpowiedzialność brać. I w niektórych organizacjach po prostu zatrudnia się od razu osoby, które już są tak rozwinięte jak trzeba, w innych nie bardzo można sobie na to pozwolić, albo też po prostu sytuacja rynkowa na to nie pozwala, że na rynku nie ma takich osób, żeby brać gotowych, ale nawet w tych firmach, które mogą sobie pozwolić na już naprawdę porządnie rozwiniętych ludzi, dalej ma to znaczenie, żeby te osoby rozwijać, również na kolejne poziomy bym powiedział organizacyjne. Czyli nawet jak już mam super świetnego szefa produktu, no to pytanie, co nas broni przed tym, żeby tę osobę wciągnąć na wyższy poziom, tu taka już z doświadczenia porada bardzo managerska, managerska wyższego stopnia, jak mam swoich następców, to mogę awansować, a jak nie mam komu przekazać swojego obszaru, to być może decyzja o awansie zostanie powstrzymana, no bo po prostu jestem niezastąpiony w swoim obszarze.

Jacek: Ścieżki rozwoju mogą być w różnych firmach traktowane w różny sposób. Czyli na przykład może być ścieżka rozwoju taka bardzo generyczna, czyli jest na przykład ścieżka rozwoju dla Product Managera, która ma ileś tam poziomów. Od jakiegoś takiego absolutnego juniora do eksperta. Natomiast to, co jest myślę istotne, to to, że to nie wyklucza tego, że pracując osobą jeden na jeden, możesz z tą osobą umawiać się też na cele spersonalizowane. To jest sposób, który wykorzystywałem w swojej pracy managerskiej, gdy zarządzałem między innymi strukturą Product Ownerów. Oprócz rozwoju Product Ownera, która wynikała ze ścieżki rozwoju, która była stworzona między innymi przy pomocy osób, które funkcjonowały w obszarze HR, umawiałem się też z tymi osobami na indywidualne cele. To nie były cele, które stały w sprzeczności ze ścieżką rozwoju, a raczej bym powiedział, były takim dopełnieniem, takimi brakującymi, najbardziej istotnymi puzzlami dla danej osoby w tym konkretnym momencie. No i skąd wiedziałem, co jest tym brakującym puzzlem, jak do tego dochodziliśmy? Po prostu rozmawialiśmy, ja bardzo dobrze wiedziałem, co się dzieje w projektach, które te osoby prowadzą z konkretnymi klientami. Stąd też bardzo łatwo było nam dojść do porozumienia, że oprócz tego, co widzisz na tej oficjalnej ścieżce, to musisz rozwinąć jakieś tam konkretne kompetencje no i dajemy sobie na to jakiś tam czas i wsparcie, które będzie do tego potrzebne.

Jacek: Ostatnia porada dzisiejszego odcinka, zaplanuj proces wzmacniania odpowiedzialności. Trochę o tym powiedzieliśmy już w tym odcinku, natomiast ten punkt akcentuje to, że proces przekazywania odpowiedzialności to nie jest coś, co się wydarzy z dnia na dzień. Jest to pewna zmiana, no i jak z każdą zmianą, warto taką zmianą zarządzić. Wymaga to przede wszystkim pewnej świadomości, że od dzisiaj chcielibyśmy nad taką zmianą pracować, wymaga to rozmowy z ludźmi, których ta zmiana będzie dotyczyć. Na pewno będziemy potrzebowali ich zrozumienia, ich wsparcia. Tam może być cała masa wątpliwości. Należałoby te wszystkie wątpliwości zaadresować. Odpowiedzialność wiąże też się z pewną wiedzą, którą trzeba zdobyć. Tę wiedzę trzeba umieć wykorzystać w praktyce, no i dobrze by też było, żebyśmy w tym procesie byli w stanie oceniać efekty. Celebrować te momenty, kiedy odpowiedzialność w widoczny sposób pomogła zespołowi uzyskać jakieś efekty, ale żebyśmy byli też gotowi na to, że jeżeli to nie idzie tak, jak byśmy się spodziewali, no to żeby zaplanować działania korygujące.

Kuba: Jedną z rzeczy, która może być częścią takiego zaplanowania procesu przekazywania odpowiedzialności, może być też bardzo jawne pokazanie uprawnień decyzyjnych. Kto kiedy, w jakich sytuacjach ma prawo, o czym decydować? Ma prawo decydować teraz, ma prawo decydować, być może za jakiś czas, czyli jakby jak ewolucyjnie będziemy te uprawnienia decyzyjne przekazywać. W praktyce, gdyby szukać konkretnego narzędzia, tej konkretnej praktyki, to tutaj często rekomenduję, często mi się sprawdza Delegation Board. Jedno z narzędzi jest nurtu Management 3.0. I tutaj upraszczając, chodzi o to, żeby bardzo jawnie wypisać konkretne przypadki, konkretne sytuacje czy konkretne obszary, w których podejmowane są pewne decyzje, czy następują jakieś procesy związane z decyzjami i jasne sobie powiedzenie między osobami w strukturze, kto, na jakim poziomie ma jaki poziom zdelegowania odpowiedzialności. Tak, żeby w ogóle na pierwszym, w pierwszym kroku, żeby w ogóle mieć tutaj jasność i brak nieporozumień pomiędzy poszczególnymi osobami, ale również, żeby rozpocząć rozmowę taką długotrwałą. OK, to co musi się wydarzyć, żebyście zupełnie samodzielnie o czymś decydowali? Co musi się wydarzyć, żebym ja się czuł spokojnie jako zarządzający strukturą? Kiedy potrzebuję, żebyście jednak na przykład przyszli się skonsultować albo przyszli pokazać jakiś pomysł, żebym się w jakiś sposób z nim zgodził albo pod nim podpisał. Więc tutaj mocno zachęcamy do tego, żeby nie odkładać tematu, nie zakładać, że on się wydarzy sam albo że jest oczywisty, tylko jednak budować tę odpowiedzialność cierpliwie, trwale, wraz z rozwojem swoich ludzi, również kroczek po kroczku ją przekazywać do konkretnych osób czy do konkretnych zespołów.

Jacek: W ramach tego punktu przypomina mi się historia z początku moich działań jako konsultant w ramach 202 Procent, gdy wspierałem pewną firmę, która borykała się z następującym problemem. Product Ownerzy komunikowali mi, że nie dostali odpowiedzialności, natomiast osoba z zarządu, która odpowiadała za opiekę nad nimi, dostawałem komunikat, oni w ogóle nie biorą odpowiedzialności. I to było takie bardzo wyjątkowe usłyszeć, takie trochę sprzeczne komunikaty z obu stron i okazało się, że jedna, dwie rozmowy właśnie przy użyciu Delegation Board, techniki, o której przed chwilą Kuba wspomniał, pozwoliło rozwiązać ten problem. Na zasadzie Product Ownerzy odkryli, że mogą o wiele więcej, natomiast osoby zarządzające dostrzegły, że jest przestrzeń na to, żeby to osoby faktycznie pewną odpowiedzialność wzięły. Więc tak, to nie jest oczywiste i tak zdecydowanie warto o tym rozmawiać i sobie ten temat przegadać.

Kuba: Ok, podsumowując. Wzmacnianie odpowiedzialności za produkt przez szefa produktu polega na wyznaczaniu ambitnych celów. Regularnym przypominaniu strategii firmy i produktu. Angażowaniu zespołów w kreowanie rozwiązań oraz wyjaśnianiu kontekstu biznesowego podejmowanych decyzji.

Jacek: Równocześnie warto umożliwiać eksperymentowanie i zadbać o to, żeby z tych eksperymentów były wyciągane wnioski. Oczekiwać efektów, zamiast tylko realizować sztywne zakresy. No i pomocna może być zapewnienie dostępu do feedbacku od klientów. Regularna praca jeden na jeden oraz stworzenie ścieżek rozwoju.

Kuba: Wzmacnianie odpowiedzialności to proces, który warto dobrze zaplanować i systematycznie realizować.

Jacek: Jeżeli twoja firma korzysta z technik pracy zespołowej inspirowanej Scrumem i masz poczucie, że efektywność pracy twoich zespołów wymaga poprawy, odezwij się do nas po diagnozę i eksperckie rekomendacje na temat procesu wytwórczego w twoich zespołach. 

Kuba: Dopasujemy nasze porady do konkretnego kontekstu Twojej firmy i wesprzemy zmiany, których potrzebujesz. Sprawdź naszą ofertę na stronie porzadnyagile.pl/diagnoza.

Jacek: I na koniec takie trochę luźniejsze ogłoszenia, ale istotne zarówno dla mnie i dla Kuby, jak i dla Słuchaczy. Warto zaakcentować pewną taką świadomą zmianę, którą wprowadziliśmy ostatnio w naszym podcaście. Jeżeli śledzisz nas regularnie, możesz zauważyć, że ostatnie kilka odcinków ma trochę inną tematykę. Jest to z naszej strony świadome i chcemy jawnie zadeklarować i obiecać, że będziemy kolejne materiały kierować głównie do osób zarządzających zespołami, organizacją oraz produktem. Siłą rzeczy może to oznaczać trochę mniej adekwatne tematy dla członków konkretnych zespołów.

Kuba: Ale jeśli jesteś Scrum Masterem, Scrum Masterką, Product Ownerem, Product Ownerką i jesteś z nami długo, to mimo wszystko zachęcamy do pozostania z nami, bo te tematy być może niedługo będą również dotyczyć Ciebie, bo prędzej czy później przydarzy się jakiś awans właśnie na grono zarządzające. A może jesteś w relacji z osobami zarządzającymi i możesz pewne rzeczy doradzić, poradzić, słuchając tego, jak my to robimy. Być może możesz w jakiś sposób odtworzyć pewien ciąg myślowy i również zainspirować swojego przełożonego czy swoją szefową.

Jacek: Natomiast niezmiennie notatki do tego odcinka, artykuł, transkrypcję oraz zapis wideo znajdziesz na stronie porzadnyagile.pl/132.

Kuba: I to by było wszystko na dzisiaj. Dzięki Jacek.

Jacek: Dzięki Kuba.

Kuba: I do usłyszenia. Wkrótce.

———

To była pełna transkrypcja odcinka podcastu „Porządny Agile”. Dziękujemy za lekturę!