#031 – Wzmacnianie odpowiedzialności zespołu za produkt

34:27
 
Udostępnij
 

Manage episode 254530641 series 2440361
Stworzone przez Porządny Agile, odkryte przez Player FM i naszą społeczność - prawa autorskie są własnością wydawcy, a nie Player FM, a dzwięk jest przesyłany bezpośrednio z ich serwerów. Naciśnij przycisk Subskrybuj, aby śledzić aktualizacje Player FM, lub wklej adres URL kanału do innych aplikacji podcastowych.

Czym jest odpowiedzialność zespołu za produkt i dlaczego jest bardzo ważna? Co zrobić, aby zbudować odpowiedzialność za produkt w naszym zespole – poznaj 6 rad, które Ci w tym pomogą.

Dyskusje o odpowiedzialności za produkt:

6 rad na to, jak zbudować odpowiedzialność zespołu za produkt:

  • 08:30 – Zrozum i zdefiniuj produkt
  • 13:05 – Spędź czas z użytkownikiem
  • 17:50 – Znaj wizję produktu
  • 22:28 – Przypomnij sobie o powodach realizacji inicjatywy
  • 26:00 – Pracuj przyrostowo i wykorzystuj pętlę feedbacku
  • 28:43 – Monitoruj rezultaty

O czym jeszcze usłyszysz w odcinku?

Dodatkowe materiały, które wspominamy w nagraniu:

Daj nam znać co sądzisz o tym odcinku

Transkrypcja odcinka

Jacek: W dzisiejszym odcinku porozmawiamy o tym, jak budować odpowiedzialność zespołu za produkt. Bardzo często, kiedy pracuję z klientami, kiedy analizujemy sobie to, jak pracuje zespół, jak rozbudowuje konkretny produkt, prędzej czy później dochodzimy do zagadnienia odpowiedzialności zespołu za wykonywaną pracę w kontekście produktu i bardzo często wtedy słyszę pytanie: „To jak moglibyśmy sprawić, żeby ta odpowiedzialność za produkt w zespole rosła i żeby była większa?”.

Kuba: W ramach odcinka zdefiniujemy jeszcze ciutkę dokładniej, o co nam chodzi. Opowiemy, dlaczego warto taką odpowiedzialność mieć – mieć ją wysoką w zespole – i podzielimy się z Tobą sześcioma podpowiedziami, które naszym zdaniem warto zastosować. Warto albo spróbować, albo wzmocnić w swoim zespole, by tą większą odpowiedzialność za produkt uzyskać.

Zaczniemy od definicji tego, o co nam chodzi, jeśli mówimy o odpowiedzialności za produkt. Najprościej, niestety, negatywnie to ująć, przypadkami, które też niestety od czasu do czasu w niektórych firmach spotykamy, że są zespoły – czy pojedyncze osoby w zespole – które trochę nie zważają na to, co robią, po co robią, po prostu wykonują swoje zadania – może nawet wykonują je dobrze technicznie czy dobrze jakościowo, ale nie składa się to w całość, nie uzyskujemy też takiego zaangażowania czy zrozumienia tego, co jest realnie potrzebne. Czasami też tej odpowiedzialności za produkt potrzeba, gdy kreowane są zupełnie nowe rozwiązania, gdy przebudowywany jest produkt – i w toku dyskusji pojawia się problem, że zespół albo nie rozumie, po co coś robimy, nie rozumie klienta. Albo niestety się okazuje, że te rozwiązania, które przychodzą od zespołu, one są już ze startu, z gruntu, w ogóle od samego początku nieadekwatne, niedopasowane, bo nagle się okazuje, że trochę zabrakło kontekstu i te pomysły są do poprawienia. Product Backlog nie jest wystarczająco dobry.

Jacek: Przykładem takiego braku odpowiedzialności za produkt jest sytuacja, w której Zespół Deweloperski wyprodukuje kawałek produktu i to rozwiązanie nie do końca odpowiada na potrzeby, pomimo tego, iż – tak jak wspominałeś – technicznie trudno cokolwiek zarzucić, no i rozpoznaję brak odpowiedzialności, kiedy słyszę w takiej sytuacji od strony osób, które wytwarzają ten produkt, że: „No przecież tak to było zdefiniowane, no przecież tak to mieliśmy zrobić. No, ja nie wiem, czy to jest dobre biznesowo, ja tu po prostu odpowiadam za to, żeby ten guzik był czerwony i jak się go nadusi, żeby się wygenerował raport. A reszta? Co mnie to tam… obchodzi?”.

Kuba: I żeby nie być tylko takim negatywnym, bo świadomie chcieliśmy tego uniknąć i tak średnio nam chyba wyszło [śmiech], to powiedzmy sobie pozytywnie, jakie są korzyści, jeśli tą odpowiedzialność w produkcie mamy.

Jacek: Pierwsza myśl, która mi zawsze przychodzi, to jest taka, że Zespół Deweloperski wytwarzający produkt – w sensie, zespół, który jest odpowiedzialny – powoduje to, że ta odpowiedzialność za produkt – taka na wielu płaszczyznach, jakościowa, techniczna, taka, żeby faktycznie rozwiązywać problemy użytkowników – ona spoczywa i rozkłada się na cały zespół. Czyli nie jest na barkach tylko jednej osoby, która musi to szerokie zagadnienie opanować, tylko ma wsparcie w członkach Zespołu Deweloperskiego w tym, żeby ten produkt na koniec dnia dawał wartość użytkownikom. I zależy nam na tym, żeby zespół jako całość po prostu tą odpowiedzialność i tą taką chęć tworzenia dobrego produktu posiadał.

Kuba: Drugim argumentem za tym, żeby mieć dużą odpowiedzialność za produkt, wydaje mi się taka możliwość u wszystkich członków zespołu w dokładaniu dobrych pomysłów, w zrozumieniu, po co coś robimy, zrozumieniu, jakie problemy rozwiązujemy, no i wtedy wraz z tą odpowiedzialnością idzie też dużo trafnych, kreatywnych pomysłów, te innowacje przychodzące od każdego możliwego członka zespołu, one są trochę lepsze, wszyscy się może tak troszkę bawią w takie kreatywne rozwiązywanie problemów, wzajemnie inspirując do tego, co powoduje, że rozwiązania są lepsze niż ktokolwiek zakładał, gdy w ogóle rozpoczynaliśmy pracę. I wszyscy też mają takie poczucie satysfakcji, że uczestniczymy w bardzo kreatywnym procesie, bo się zaangażowaliśmy, mamy spory kontekst, mamy swoją wiedzę techniczną, jak to robić, więc to się wszystko w sumie składa też w fajne rozwiązanie, jeśli chodzi o wartość biznesową, a przy okazji też satysfakcję i motywację do kontynuacji pracy w ten sposób. Bo tutaj, no, wydaje mi się, może to nawet jest osobny punkt, że to też jest takie samonakręcające się – „Wiem, po co to robię, więc robię to fajnie. Dostaję jakąś informację zwrotną, że to się sprawdza, więc dalej mi się chce” – i to takie jest podtrzymywanie również po prostu motywacji, już niezależnie od tego, jaka jest wartość biznesowa poszczególnych czy to iteracji, czy to poszczególnych przyrostów.

Jacek: Trzecia rzecz, która mi przychodzi do głowy, gdy myślę o tym, dlaczego dobrze, gdy jest duża odpowiedzialność rozłożona na cały zespół to to, że ostatecznie jakość produktu potencjalnie może być wyższa. I tu taki pamiętam przykład sprzed paru lat, kiedy pracowałem z zespołem i zespół zgodził się, że – co do zasady – to, co wyprodukowali, jest bez zarzutu. W sensie: działało, działało tak, jak miało działać, było zgodne z makietą i pamiętam jak jeden z deweloperów wstał i powiedział: „Słuchajcie, ale przecież my nie możemy tego puścić do użytkowników”. I to było mocne. To było dla części zespołu zaskakujące, natomiast to jest… tego rodzaju zachowania ja bym się spodziewał, czyli z jakiegoś powodu wszyscy przespali czy nie zauważyli, że coś nie do końca jest z rozwiązaniem, które chcemy dać użytkownikom, no i znalazł się po prostu ktoś, kto powiedział: „Słuchajcie, no nie, no… Tak nie możemy zrobić”. W sensie, że to „będzie wstyd”.

Kuba: Taka twoja wersja anegdoty o squirrel burgerze, po prostu wstyd przed dostarczeniem czegoś słabego, tak?

Dobra, to przejdźmy do konkretnych rozwiązań – już wiemy po co taka odpowiedzialność w produkcie jest wartościowa. Zanim przejdziemy do tych sześciu konkretnych porad czy konkretnych sugestii praktycznych, co można zrobić, to chciałbym zacząć od takiego bardzo ważnego zastrzeżenia, do kogo się kierujemy w ramach tego nagrania, bo wiele z tych porad, jak sobie je przygotowaliśmy z Jackiem przed odcinkiem, będzie w liczbie mnogiej: „Zróbcie coś”, „Idźcie gdzieś”, „Posłuchajcie” czy „Przygotujcie”. Ja myślę, że te rady są dosyć uniwersalne – one mogą być dla Scrum Mastera i wtedy rozum je jako – jeśli jesteś Scrum Masterem lub Scrum Masterką – zrozum je jako sposób na wprowadzenie czy jakieś konkretne porady, praktyki – wprowadź je w swoim zespole, zainspiruj swój zespół, zaproponuj im te rzeczy. Jeśli jesteś Product Ownerem lub Product Ownerką, to zastanów się, które z tych praktyk możesz też przenieść do swojego zespołu. Jeśli jesteś członkiem Zespołu Deweloperskiego, to może zaproponuj na najbliższej Retrospektywie takie usprawnienie. A jeśli jesteś managerem, który obserwuje czy nadzoruje czy kieruje, jakąś grupą zespołów w swojej firmie, zobacz, czy czasami to nie jest jeden z tych elementów, który trochę brakuje w tym, jak zarządzane są zespoły produktowe, jak prowadzone są też prace w gronie Product Ownerów.

Jacek: Jak o tym mówiłeś, to w sumie zdałem sobie sprawę, że na metapoziomie to też jest przykłada tego, że ta odpowiedzialność za to, żeby było dobrze w zespole, spoczywa na wielu rolach, więc trudno też czekać na to, żeby ktoś zareagował, kiedy my widzimy, że możemy działać, tak więc…

Kuba: Można się tego dopomnieć, jako członek zespołu, można to zaproponować jako Product Owner, można jako Scrum Master czy Agile Coach w swoim zespole wnieść to, przynieść to jako propozycję praktyki czy sposób na pracę trochę inaczej.

Jacek: Pierwszą poradą, którą chcieliśmy się z Tobą podzielić, to jest porada, która brzmi: „Zrozum i zdefiniuj produkt”. Zrozumienie i właściwa definicja produktu jest to krok konieczny do tego, żeby zespół był w stanie połączyć to, co robi na co dzień – często bardzo takie techniczne, niskopoziomowe działania – z tym ostatecznym celem, który chcemy osiągnąć. I kiedy prowadzę konsultacje czy prowadzę szkolenia, ten temat: „A co tak naprawdę z naszym produktem?” – on wraca. W szczególności jeżeli pracowaliśmy długo w sposób projektowy, gdzie tak nie do końca się zastanawialiśmy nad produktem, bardziej myśleliśmy o tym, żeby dostarczyć jakiś umówiony efekt projektowy – no, ten produkt bywa taką zagadką. W sensie, pierwsze skojarzenie to jest takie, że przecież produkt musi być fizyczny – nie do końca tak jest. Tak więc ta jasna definicja, co jest naszym produktem, jak my go definiujemy, jakie on ma cechy, jak szeroki jest zakres tego produktu, uważamy za kluczowy punkt startowy.

Kuba: Ja bym nawet dorzucił, bo powiedziałeś „efekt projektu” – w wielu przypadkach spotykam się wręcz z tym, że oczekiwany jest po prostu zakres. Zdefiniowaliśmy kilka punktów, kilka feature’ów, po prostu to zrobimy – i to może prowadzić w wielu zespołach do tego, że zespół jest traktowany jako taka „fabryka feature’ów”, a niekoniecznie zespół, który odpowiada za konkretny produkt. Natomiast idąc jeszcze głębiej – nawet jeśli zespół czuje, że jest zespołem od produktu i ma jakiś system albo jakąś aplikację, jakieś rozwiązanie IT pod swoją opieką, to często ta definicja produktu będzie zbyt zawężona – „My tu jesteśmy od tego, żeby utrzymać aplikacje wewnętrzne albo budować intranet, albo budować jakąś tam apkę”. I to często jest jednocześnie prawdą, ale czasami zbyt zawężające, że to jest zespół, który zajmuje się jakimś konkretnym rozwiązaniem IT, a nie tym czymś trochę czasami abstrakcyjnym, że to jest zespół, który pomaga rozwiązać problem jakiejś grupy klientów albo osiągać jakiś rezultat biznesowy, pomagać naszej firmie zarabiać, rozwiązywać jakieś konkretne działanie dla klienta.

I czasami taka redefinicja w danym zespole może bardzo rozszerzyć sposób postrzegania zespołu i na przykład z zespołu, który zajmuje się intranetem, zespołem intranetowym, zamieniamy się w zespół, który zapewnia lepszą propagację informacji w firmie, co może oznaczać, że być może mamy brakujące kompetencje w zespole, a na pewno zakwestionujemy czy zadamy sobie pytanie, czy dotychczasowe rozwiązania, które dotychczas rozwijaliśmy, faktycznie rozwiązują ten problem, który sobie zdefiniowaliśmy na być może trochę bardziej ogólnym poziomie.

I mam takie doświadczenie z zespołem – użyłem tego przykładu intranetu – podobny zespół, zajmujący się komunikacją produktu, który na początku definiował swoją rolę czy swój sens istnienia, jako zespół, który po prostu raz w tygodniu nadaje komunikaty do całej firmy na temat tego, co się zmienia w naszej ofercie produktowej. I tak zawężona definicja produktu powodowała, że w zasadzie cały zespół zajmował się po prostu copywritingiem coraz lepszych maili, tydzień w tydzień wysyłanych do klientów. Gdy zredefiniowali sobie to, czym się zajmują, że nie chodzi o to, żeby nadać komunikat, tylko żeby skutecznie propagować informacje, raptem jeden krok bardziej abstrakcyjnie, to nagle się okazało, że zupełnie zmieniło się podejście do tego, czym mamy się zajmować, bo nadawanie okazało się nieskuteczne i ta informacja nie docierała, więc zespół nie zajmował się relatywnie prostym problemem, jak nadawać lepsze komunikaty, tylko jak docierać z rozwiązaniem.

I to jest dosyć prosty przypadek – niekoniecznie adekwatny w każdej sytuacji – ale znajduję wiele analogii tego typu sytuacji. Wiele zespołów zbyt mocno widzi siebie jako zespół, który wytwarza apkę, system, kawałek jakiejś procedury, rozwiązania, zmiany w procesie, a raptem dosłownie krok wyżej w abstrakcji jest rezultat biznesowy, efekt, skuteczność, taka prawdziwa przydatność – i czasami całkiem dobre odświeżenie całemu zespołowi i poprawienie odpowiedzialności za produkt, robi właśnie takie zdefiniowanie sobie tego naszego produktu. Być może trochę bardziej abstrakcyjnie, ale o wiele bardziej tak namacalnie biznesowo.

Jacek: To, co ja słyszę w tym, co opowiadasz, to zbliża nas do punktu drugiego, do drugiej porady, która brzmi: „Spędź czas z użytkownikiem”, bo jak mówiłeś o tej skuteczności nadania tego komunikatu, no to nieuchronnie tutaj zbliżamy się do tego, żeby się zastanowić, kto odbiera te komunikaty i może upewnijmy się, że one są dobre albo dowiedzmy się, że może nie do końca i zastanówmy się, co można usprawnić. Tak więc druga nasza porada brzmi: „Spędź czas z użytkownikiem” i to jest porada – czy taka wskazówka – która zwykle wywołuje gęsią skórkę u osób, z którymi rozmawiam na ten temat, ponieważ w przeciętnej firmie odległość zespołu wytwarzającego produkt do tego użytkownika, który faktycznie będzie z tego produktu korzystał, zwykle jest całkiem spora. W sensie, co najmniej kilka poziomów dzieli zespół od osoby, która ostatecznie z produktu korzysta. Natomiast ta możliwość wejścia w interakcję z użytkownikiem, możliwość zobaczenia, jak on korzysta z produktu, pewien czas, który mamy na to, żeby wysłuchać, co ten użytkownik chce nam powiedzieć, to, co chce nam zaprezentować, wyrazić – jest niezwykle istotne. Pamiętam, jak parę lat temu wspierałem zespół, który dostarczał produkt, aplikację do osób, które pracowały na tej aplikacji na co dzień i dosyć dużo niejasności pojawiło się w trakcie dewelopmentu, jak pewne rzeczy powinny być rozwiązane i reprezentacja, w osobie Product Ownera + paru reprezentantów zespołu (tam też się pojawiła osoba UXowa), podjęła decyzję, że może warto byłoby pojechać faktycznie do fizycznego miejsca, gdzie użytkownicy korzystają z produktu i zobaczyć, jak oni wchodzą w interakcje z tym produktem. I pamiętam, że jak wrócili z tej takiej jednodniowej wizytacji, no to byli mocno w szoku, w takim sensie, że zobaczyli, jakie problemy mają użytkownicy z produktem, dowiedzieli się zupełnie nowych rzeczy o tym produkcie, na zasadzie: to jest nieintuicyjne, a tu musimy niepotrzebnie pięć razy kliknąć, jakiś element procesu w tym produkcie w ogóle był pomijany i sobie jakieś takie robili użytkownicy obejścia na boku, w jakiejś innej aplikacji, tak więc wrócili z pełną głową pomysłów na to, co można byłoby usprawnić w produkcie – i to jest superfajna rzecz, ale dodatkowo to, co się zadziało, moim zdaniem, to oni „zempatyzowali” się z tym użytkownikiem, czyli poczuli, jak to jest używać tego produktu, co powodowało, że jak później rozmawiali o tym, jak ten produkt rozwijać, no to wracały te historie i te obrazy, które zbudowali sobie w trakcie tej wizytacji, tak więc jeżeli możesz się zbliżyć do klienta, jeżeli jesteś w stanie takie spotkanie zaaranżować – może z jakąś grupą zaprzyjaźnionych użytkowników na początku – to zdecydowanie warto po to rozwiązanie sięgnąć.

Kuba: Mam bardzo podobną historię związaną z zespołami, które zajmowały się rozwojem systemu do call center – używam liczby mnogiej, bo w dwóch różnych firmach mieliśmy bardzo podobną historię, że zupełnie zmieniło się postrzeganie tego, z jakimi emocjami wiąże się obsługa systemu, gdy po prostu operator na słuchawce musi pracować i w jakim on jest stresie, jakie ma informacje dostępne, co mu pomaga, a co mu przeszkadza w tym, żeby realizować swoje zadania, no i zespoły wychodziły pełne pomysłów, ale też pełne dostrzeżenia takich drobnych niedoskonałości, bo ja tutaj zwrócę uwagę na jedną rzecz – co innego ludzie nam mogą zlecić, powiedzieć – może jakiś manager przyśle „10 pomysłów na usprawnienie”, a co innego my sami zauważymy, jak zaobserwujemy w naturalnym środowisku naszego klienta i zrozumiemy, w jakim kontekście on pracuje i co mu pomaga, co mu przeszkadza, co by może mu pomogło – ten klient może nawet nie umieć powiedzieć, że: „No, tak tu jakbym miał jakiś fajny podpowiadacz, ile jeszcze czasu zostało”, to my dopiero widząc go w praktyce i rozmawiając z nim, możemy odkryć, czego jemu faktycznie brakuje – on nawet może sam nam tego nie powiedzieć. I wszystkie te spotkania, ten spędzony czas z użytkownikiem, to jedna kwestia to jest właśnie to naturalne środowisko, ale też okazja do głębokiego zrozumienia, jaka jest potrzeba. A nie bazowanie na tym, że ktoś nam zlecił, że komuś się coś wydaje, czy takie trochę zgadywanie, tylko autentyczne zgłębienie, czego klient potrzebuje. Nie nawet co zamówił, tylko czego potrzebuje.

Kolejną poradą, którą chcielibyśmy przekazać w tym odcinku, to jest rada dla całego zespołu: „Znaj wizję produktu”. I dla niektórych zespołów to jest: „Zbuduj tą wizję, bo jej w ogóle nie masz”, a w wielu innych zespołach będzie to raczej: „Pamiętaj, przypominaj ją sobie, być może odświeżaj z jakąś regularnością wizję tego, co jest do zrobienia”. „Wizja produktu” to jest bardzo pojemny temat – być może nadający się na zupełnie osobny odcinek, ale w skrócie zazwyczaj wizje produktu zawierają jakąś formę definicji, kim jest klient i jakie ma potrzeby, co świetnie mapuje się z tą drugą poradą, ale też jakaś taktyka, jak chcemy zaspokoić te potrzeby, jak chcemy się pozycjonować względem konkurentów, w czym chcemy być unikalni, jakie mamy pomysły na realizację, jakie będziemy też czerpać korzyści, jak będziemy je realizować, na czym zarabiamy. Kilka takich elementów, które w różnych narzędziach różnie są sformułowane, ale szereg takich definicji, czym produkt jest, czym jest klient i jak dalej go chcemy rozwijać. I to może się wydawać trochę takim, powiedzmy, opowiadaniem biznesowym, niekoniecznie namacalnym, ale jeśli zamienimy to w konkretne historie, konkretne przykłady, konkretne też takie bardzo namacalne powody, dla których chcemy pewne rzeczy zrobić, to to są po prostu przypomnienia czy w ogóle zbudowania sobie uzasadnienia, po co coś robimy.

Jacek: Ja właściwie to, co powiedziałeś, skomentuję w ten sposób: „Nie zaczynam pracy z nowym zespołem inaczej niż od wywołania tematu wizji produktu – czy ona jest, jeśli tak, to ją sobie odświeżmy, jako cały zespół. Jeśli tej wizji produktu nie ma, to również zbudujmy ją, jako cały zespół”. Oczywiście to zwykle wygląda tak, że osoba biznesowa, jakiś reprezentant klienta czy klient, on zwykle ma jakąś wizję i jakiś pewien szkic czy zarys tej wizji, zwykle jest w stanie powiedzieć, natomiast włożenie tego, czy poddanie tego szkicu pod dyskusję z zespołem, zwykle generuje dodatkowe pytania, wątpliwości – dosyć mocno to może mieć wpływ na to, jakimi ścieżkami ten produkt będziemy rozwijać i dla mnie to jest taki absolutny kamień węgielny pod budowanie odpowiedzialności i właściwie bez tej wizji się nie ruszam, natomiast to, co warto dodać do tego, co powiedziałeś – bo wymieniłeś kilka różnych możliwości, co w tej wizji może być – to myślę, że warto tutaj dodać, że jest całkiem sporo różnych narzędzi dostępnych, z których można skorzystać, tak więc w zależności od Waszych potrzeb, można dobrać sensowne narzędzia z całkiem szerokiej palety dostępnej na rynku, w sensie: w internecie.

Kuba: Jeśli miałbym wymienić jedną konkretną rzecz, czy jedno konkretne narzędzie, to ja sam rekomenduję zazwyczaj wykorzystanie Product Vision Board od Romana Pichlera – jest to fajnie opisane też w książce „Strategize” właśnie tego autora, ale te materiały są też dostępne na jego stronie internetowej, gdzie można sobie pobrać szablon, gdzie jest trochę opisane, co to znaczy, jak to zrobić – oczywiście bierzcie takie rzeczy z dostosowaniem do swoich potrzeb, ale jeśli chcecie od czegoś zacząć wizję produktu, to to może być dobry pierwszy trop.

Jacek: To z kolei rekomendacja z mojej strony, ostatnio bardzo często używam podejścia czy filozofii „Start with Why” Simona Sinka, czyli zaczynam od zdefiniowania „dlaczego?”, dopiero potem sobie idziemy w „jak?” i na końcu w „co?”, czyli co tak naprawdę ma być tym produktem. I to jest trochę inny poziom abstrakcji niż to, co ty mówisz, powiedziałbym, że bardziej ogólny, natomiast w szczególności jeśli produkt kompletnie jest niezdefiniowany, to jest coś supernowego, no to to jest fajna taka pierwsza iteracja wizji, którą można narzędziami takimi chociażby jak wymieniłeś, pogłębiać w kolejnych krokach.

Zanim przejdziemy do kolejnego punktu, chciałem zaprosić Cię na trzecią już edycję warsztatów „Labirynty Scruma”. Są to warsztaty, podczas których wraz z uczestnikami rozbieram na części pierwsze najpopularniejsze pułapki Scruma, szukając najlepszych rozwiązań. Najbliższe takie warsztaty odbędą się 26 i 27 marca w Warszawie, a wszystkie informacje na temat tych warsztatów znajdziesz na stronie warsztaty.labiryntyscruma.pl.

Kuba: Czwarta rada, którą chcemy się podzielić, to: „Przypominaj sobie o powodach realizacji inicjatywy”. Brzmi to trochę może oczywiście, no przecież wiemy, po co coś robimy, ile razy można o tym wspominać? Ale to jest takie wracanie do „dlaczego?”, wspomniałeś właśnie „Start with Why”. Przypominaj sobie, po co chcesz coś zrobić, to może być na każdym pojedynczym elemencie w backlogu, przypomnienie, po co, co chcemy osiągnąć, jaki problem rozwiązujemy, ale to też może być praca – czy to właściciela produktu czy przedstawiciela klienta, może interesariusza – w zależności od tego, kto to jest, kto nam ten kontekst dostarcza – przypominanie, dlaczego coś jest ważne, przypominanie, po co chcemy to zrobić, cierpliwe wyjaśnianie – bo to też czasami jest po prostu potrzebne, ta odpowiedzialność produktowa to nie jest przełącznik, który: „kiedyś jej nie było, a teraz zrobiliśmy trzy magiczne kroki i już to mamy”. To będzie też cierpliwe pracowanie, żeby wyjaśnić niezrozumienie, być może przypomnieć, być może trochę sparafrazować pewne rzeczy, które nie dotarły do tej pory dodanego członka zespołu, no i tutaj jest to raczej cierpliwa, organiczna, długofalowa praca, członkowie zespołu też się zmieniają – czasem ktoś o czymś zapomina, ktoś czegoś nie zrozumiał – te kropki regularnie trzeba łączyć.

Jacek: Ja nie zapomnę, jak kiedyś Product Owner, z którym pracowałem z klientem, zwrócił mi uwagę na to, jak reprezentant klienta rozpoczyna każde zdanie. I ta osoba, która była konsultantem z Wielkiej Brytanii, ona faktycznie, kiedykolwiek padało pytanie, jakiekolwiek były wątpliwości, zawsze startowała z takiego bardzo ogólnego poziomu, upewniając się, że zanim przejdziemy do dochodzenia do konkretnej odpowiedzi, czyli do jakiegoś rozwiązania, to wszyscy w pokoju mają takie samo zrozumienie, jaki jest problem, dlaczego w ogóle tutaj jesteśmy – i malował bardzo, bardzo szeroki obrazek. I ktoś mógłby powiedzieć, patrząc z boku: „Po co ta historia? Po co takie rozwlekanie?”. Z mojej perspektywy to jest konieczne, jeżeli chcemy dojść do sytuacji, w której – tak jak powiedziałeś – na początku zespół jest doradcą produktowym i, jakby, mamy w każdej osobie w zespole wsparcie w tym, żeby ten produkt, który powstaje, był jak najlepszej jakości, żeby te rozwiązania, które przekazujemy do użytkowników, były po prostu jak najlepsze.

Kuba: Co oznacza, że taki na przykład Product Owner scrumowy, czy klient, czy interesariusz pracujący przy projekcie, powinien mieć i bardzo krótką wersję, nazwę to, najwyższego poziomu mantrę, po co coś robimy, ale też był bardzo otwarty i gotowy na to, żeby powyjaśniać szczegóły, poprzypominać pewne rzeczy, opowiedzieć też o kontekście użycia danego rozwiązania – i nie bać się o tym wspominać, nie bać się, nie przejmować się ewentualnym zarzutem o stratę czasu, no, w najgorszym razie po prostu sobie to w zespole dopracujemy, że może jest tego za dużo, ale chętnie raczej rekomendowałbym, dobrnijmy do tego momentu, w którym cały zespół stwierdza: „Nie, za dużo już tego kontekstu biznesowego, za dużo tego wyjaśnienia powodów, mamy tego wystarczająco” – póki nie ma takich głosów, to ja uważam, że zawsze warto przypomnieć, po co.

Jacek: Kolejną radą, którą chcieliśmy się z Tobą podzielić, to jest rada: „Pracuj przyrostowo i wykorzystuj pętlę feedbacku”. Co mamy tutaj na myśli? „Pracuj przyrostowo”, czyli na koniec konkretnych iteracji, czy co jakiś okres czasu, dostarczaj przyrost produktu, czyli trochę lepszy produkt niż mieliśmy go chwilę temu. I dlaczego to jest istotne? Dlatego, że jeżeli faktycznie przyrostowo budujemy produkt i on rośnie w naszych oczach – i od superprostego produktu przechodzimy do coraz bardziej zaawansowanego rozwiązania. Jeżeli my czymś takim dysponujemy, to my możemy pokazać ten produkt interesariuszom, klientowi czy naszym użytkownikom. I to jest o tyle ważne, że pokazując coś takiego namacalnego, jesteśmy w stanie wywołać dyskusję i uruchomić pętlę informacji zwrotnej. I bardzo dobrze wspominam wszystkie momenty podczas Przeglądów Sprintu czy jakichś takich Przeglądów Produktu, gdzie Zespół Deweloperski pokazując taki namacalny przyrost, wywoływał uśmiech na twarzy interesariuszy czy uśmiech na twarzy użytkowników, którzy werbalnie wyrażali to, że podoba im się to, co zobaczyli – często wręcz dziękując zespołowi za to, że jakiś tam konkretny problem, który zgłaszali na przykład dwa czy trzy miesiące temu, został w końcu rozwiązany. I to jest takie, można powiedzieć, błahe, ale wielokrotnie przekonałem się, słuchając echa tych rozmów, czy w trakcie Retrospektyw, czy w trakcie trwania Sprintów czy iteracji, że te drobne pochwały, te drobne takie… wzmocnienia płynące od tych osób, dla których wytwarzamy produkt – są dla zespołu superważnym paliwem, dlatego nie rezygnowałbym z tego, natomiast, no, nie mając tych przyrostów, to no tak naprawdę nie mamy tego czegoś, co może wywołać dyskusję, która – jak tu przed chwilą powiedziałem – jest wartościowa z perspektywy teamu.

Kuba: Mam dokładnie świeże takie przemyślenie i podsumowanie pewnego etapu z zespołem, z którym aktualnie pracuję, że właśnie coś, co ja już nawet sobie nie uświadamiałem, jak bardzo motywuje ich wszystkich w zespole fakt, że uzyskujemy przyrosty. Ty mówisz: „Klient podziękuje”, ale to też jest ta perspektywa – zespół, mając już częściowo zbudowaną odpowiedzialność, sam nakręca się dalej, widząc, że: „Tak, każdy kolejny Sprint przynosi nam dobrą pracą wykonaną, widzimy różnicę” – to są takie małe kroki, które prowadzą nas we właściwą stronę.

Ostatnią poradą, którą chcemy się podzielić w tym odcinku, to rada: „Monitoruj rezultaty”. Ona jest pewnie adekwatna zwłaszcza do zespołów, które rozwijają swój produkt już w dłuższym okresie czasu i mają ten produkt na rynku czy w użyciu przez użytkowników – wspominaliśmy o tym trochę ostatnio w odcinku o Przeglądzie Sprintu, że czasami brakuje niektórych elementów – tutaj, z perspektywy budowania odpowiedzialności za pracę i za efekty produktowe – czasami brakuje takiego elementu zastanowienia się, jak ten nasz produkt działa, jakie są rezultaty biznesowe, jakie jest użycie tego produktu, jakie są czasy użycia, jak zadowoleni są klienci – i to w zależności od tego, jaki jest nasz produkt, to mogą być bardzo różne rzeczy, bo jeśli mamy apkę, to jakie są oceny w sklepie, jeśli mamy produkt, który jest na rynku, to ile osób to zamawia, ile osób kupuje, jak idzie nam sprzedaż, czy klienci wracają – jeśli to jest rozwiązanie bardziej fizyczne, taki Scrum użyty do rzeczy poza IT, no to może możemy wprowadzić jakiś cykliczny monitoring – czy to wykorzystania, czy to zadowolenia z naszych rozwiązań – w każdym razie, to jest pewnie pewien wysiłek, pewna kreatywność, żeby to zrobić, ale jeśli mamy domkniętą tą pętlę informacji zwrotnej, nie tylko, że w czasie rozwoju produktu, w czasie rozwoju czy nawet projektu, sprawdzamy jak nam idzie, ale też po prostu, jak już teoretycznie zrobiliśmy wszystko, co chcieliśmy, w takim jakimś obszarze, to warto też wiedzieć, jak to się sprawdza – żeby mieć takie po prostu, takie domknięcie, takie podziękowanie – „Tak, idzie świetnie” – i to naprawdę super daje paliwo na przyszłość, że zrobiliśmy świetną pracę i ona w dodatku dała sukces. A gdyby miało się okazać w drugą stronę – że niestety są jakieś niedociągnięcia, no to wracamy do tego, co zrobiliśmy, możemy to poprawić, możemy poszukać – w najgorszym razie po prostu możemy się nauczyć, dlaczego nam nie wyszło, zastanowić się nad tym, a nie bezrefleksyjnie po prostu klepać kolejne kawałki, kolejne feature’y czy kolejne rozwiązania biznesowe.

Jacek: Tu robiąc tą poradę, gotową do praktycznego użycia, no to co najmniej takie dwa przykłady mi przychodzą do głowy. Pierwszy przykład to jest użycie dostępnych radiatorów informacyjnych – czy to w postaci jakichś tablic offline, czy w postaci narzędzi online, jakichś monitorów – i na bieżąco komunikowanie tych rezultatów do zespołu – w formie jakichś dashboardów, czy nawet po prostu zwykłych takich… chociażby kartek z jakimiś danymi, które przyklejane są w przestrzeni zespołu. Po co? Po to, żeby te dane gdzieś były, żeby można było w prosty sposób zrobić do nich referencje, albo żeby można było powiedzieć: „Zobaczcie, dzisiaj pobiliśmy jakiś tam rekord”. Znów, ktoś powie, że to są błahe rzeczy, że to są drobiazgi, natomiast nie ma magicznej różdżki, za dotknięciem której zespół stanie się odpowiedzialny za produkt, natomiast możemy robić takie małe, drobne rzeczy, które sumarycznie tą odpowiedzialność będą wzbudzać. Z drugiej strony – inny przykład jest taki, że kiedy rozmawiamy z zespołem o dalszych kierunkach rozwoju produktu czy o jakichś konkretnych funkcjach, atrybutach, które chcielibyśmy do produktu dodać, to też warto pamiętać, żeby posilić się jakimiś konkretnymi rezultatami, jakimiś konkretnymi danymi, żeby te nasze pomysły, czyli często też rzeczy, które są przedstawiane jako wymagania, żeby one miały jakieś osadzenie w rzeczywistości. Znów, żeby łączyć to, że na końcu jest jakiś użytkownik, jest jakiś klient, który ma jakiś problem, a my – co do zasady – naszym produktem chcemy mu pomóc ten problem rozwiązać.

Kuba: I zamknę przykładem bardzo mocno z naszego własnego świata, czyli podcastu, bardzo sami jesteśmy zainteresowani tym, ilu z Was nas słucha, co sądzicie o tych odcinkach w komentarzach, jakie dajecie oceny w tych miejscach, gdzie te recenzje można zrobić, czy nawet, jak dzielicie nasze odcinki – czy podsyłacie, czy lajkujecie, czy gdzieś jeszcze komentujecie w sieci społecznościowej – no i to po prostu daje nam kolejne paliwo, wiemy, że jest cenione, ale też wsłuchujemy się w te głosy, gdzie ktoś podpowiada, co jeszcze można by nam prowadzić, co jeszcze możemy robić lepiej w naszych nagraniach. Więc jeśli jest jeszcze coś, co możemy zrobić, to koniecznie się tym z nami podziel.

Jacek: To tylko dodam, że w styczniu pobiliśmy razem rekord słuchalności – od początku, jak podcast publikujemy z Kubą, no to styczeń 2020 był rekordowy, no i mogę powiedzieć za siebie – jak się ogląda takie statystyki, no to chce się jeszcze bardziej, w sensie: dostarczyć więcej wartości, zrobić jeszcze lepszy materiał, docierać do jeszcze większej grupy osób, tak że… dziękuję Ci za to, słuchaczu.

Kuba: Podsumowując cały odcinek, jakie rady dajemy na to, żeby zbudować odpowiedzialność za produkt – zrozum o zdefiniuj produkt, spędź czas z użytkownikiem, znaj wizję produktu, przypominaj sobie o powodach realizacji inicjatywy, pracuj przyrostowo i wykorzystuj pętlę feedbacku i monitoruj rezultaty wykonanej pracy w swoim produkcie.

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

Jacek: Dzięki, Kuba.

Kuba: I do usłyszenia…

Jacek i Kuba: …wkrótce!

53 odcinków