Właścicielstwo produktowe – w Biznesie czy w IT?

Gdzie powinno znajdować się właścicielstwo produktowe w organizacji? W IT? W biznesie? A może to temat, który wymaga zupełnie innego podejścia? Poznaj różne modele umiejscowienia odpowiedzialności za produkt i analizę ich wpływu na współpracę zespołów, podejmowanie decyzji i skuteczność wdrażania strategii. Sprawdź, w którym miejscu na osi znajduje się Twój zespół i oceń, czy można w tej kwestii uzyskać usprawnienia.

Możliwe modele umiejscowienia właścicielstwa produktowego

Pisząc o właścicielstwie produktowym, mamy na myśli miejsce w strukturze organizacyjnej, w którym znajdują się osoby zarządzające produktem, a także ich podległość służbowa. W zależności od firmy, mogą to być Product Ownerzy, Product Managerowie lub specjaliści odpowiedzialni za rozwój funkcjonalności. W niektórych organizacjach te stanowiska mają inne nazwy, jednak ich rola pozostaje zbliżona. W niektórych organizacjach stanowiska te mogą mieć inne nazwy, na przykład specjaliści ds. rozwoju funkcjonalności lub podobne role. Nie będziemy tutaj szczegółowo wymieniać wszystkich możliwych wariantów, ale na potrzeby tego tekstu będziemy używać określeń Product Owner i Product Manager, mając na myśli także inne, podobne stanowiska.

W różnych organizacjach spotykamy różne modele umiejscowienia właścicielstwa produktowego. Czasami te osoby znajdują się po stronie IT lub technologii, co oznacza, że są częścią zespołu technologicznego i współpracują głównie z działem inżynieryjnym. W innych przypadkach są przypisane do działu biznesowego, gdzie ich rola koncentruje się na strategii i rozwoju produktu z perspektywy rynku. Istnieją też organizacje, w których właściciele produktu funkcjonują jako osobna struktura, często podlegająca bezpośrednio zarządowi.

Przeanalizujemy najczęściej spotykane modele i omówimy, jakie konsekwencje niesie za sobą każdy z nich. Nie chodzi o wskazanie, który układ jest najlepszy, ale o przedstawienie, z czym wiąże się każda z tych opcji.

Brak jasnego właścicielstwa 

Pierwszym punktem na tej osi, od którego warto zacząć, jest sytuacja, w której właścicielstwo produktowe nie jest wyraźnie zdefiniowane. Oznacza to, że trudno wskazać, w jakim konkretnym obszarze organizacji się znajduje – czy jest po stronie IT, czy po stronie biznesu.

Jak rozpoznać taki stan rzeczy? Najczęściej przejawia się to w braku spójnej odpowiedzialności za decyzje. Praca nad produktem odbywa się głównie poprzez realizację losowych zleceń, które przychodzą z różnych źródeł. W skrajnym przypadku taka sytuacja prowadzi do równoległego funkcjonowania wielu inicjatyw, projektów i zmian, które nie są ze sobą skoordynowane. W efekcie mogą one konkurować ze sobą, a nawet wzajemnie się wykluczać.

W rzeczywistości zawsze znajdzie się ktoś, kto podejmie decyzję, w jakim kierunku mają podążać zespoły wytwórcze. Problem pojawia się wtedy, gdy jest to osoba, która podejmuje decyzje z konieczności, a nie z faktycznej odpowiedzialności za produkt.

Często rolę tę przejmuje ktoś bez kontekstu biznesowego, kto skupia się wyłącznie na priorytetyzacji zadań w sposób reaktywny, na przykład minimalizując ryzyko niezadowolenia różnych interesariuszy. W praktyce oznacza to, że lider zespołu czy inna osoba pełniąca tę rolę nie kieruje się myśleniem produktowym, lecz stara się jedynie zbalansować różne zlecenia, projekty i zmiany, tak by uniknąć problemów.

Podkreślamy to, ponieważ model, w którym nie ma wyraźnego właścicielstwa produktowego, ma głównie wady. Rozumiemy, że niektóre organizacje mogą się w takim stanie znajdować, ale jest to sytuacja, którą warto zmienić. 

Zarządca Backlogu w IT

Jest to krok w dobrą stronę, ponieważ w organizacji pojawia się osoba, którą można wskazać jako odpowiedzialną za zarządzanie pracami zespołu. Może to być Product Owner, lider zespołu, a czasem nawet Product Manager, choć w tym przypadku nazewnictwo bywa różne. Taka osoba znajduje się po stronie IT, jest częścią konkretnego zespołu, albo funkcjonuje w niewielkiej strukturze w ramach działu technologii. Jej rola polega na zbieraniu inicjatyw i zleceń od interesariuszy biznesowych, organizowaniu projektów oraz przekazywaniu ich do zespołu.

Jednak w tym modelu kluczową kwestią jest to, że osoba zarządzająca Backlogiem nie tworzy produktu ani nie ma realnego wpływu na jego kształt. Jej rola sprowadza się do koordynowania przepływu zadań i dbania o ich realizację, ale bez faktycznej sprawczości produktowej.

Należy zaznaczyć, że w tym artykule, nawet gdy używamy określeń takich jak Backlog czy Product Owner, nie odnosimy się stricte do Scruma. Te pojęcia na tyle mocno przeniknęły do firm, że stały się naturalnym sposobem opisywania ról i procesów w organizacjach.

W przypadku modelu zarządcy Backlogu kluczowe jest to, że taka osoba nie podejmuje decyzji o tym, co zostanie zrealizowane. Jej rola sprowadza się raczej do biernego wykonywania oczekiwań interesariuszy, bez realnego wpływu na kształt produktu. 

Warto uczciwie przyznać, że rola zarządcy Backlogu w IT, mimo swoich ograniczeń, ma pewne zalety w porównaniu do modelu, w którym właścicielstwo produktowe w ogóle nie istnieje. Przede wszystkim daje szansę na ucywilizowanie strumienia prac, na uporządkowanie zgłaszanych inicjatyw, minimalną dyskusję z interesariuszami oraz ewentualne grupowanie lub dzielenie inicjatyw w bardziej sensowne części. 

Zarządzanie produktem po stronie IT

Trzeci model to zarządzanie produktem po stronie IT. W przeciwieństwie do wcześniejszego podejścia, w tym przypadku mamy już wyraźnie określoną rolę, którą można nazwać Product Ownerem. Nie jest to jedynie osoba pasywnie realizująca oczekiwania interesariuszy, lecz ktoś, kto rzeczywiście zarządza produktem. Może posiadać własną wizję, roadmapę, a nawet określone wskaźniki mierzące postęp.

Choć taka osoba nadal funkcjonuje w strukturach IT i musi uwzględniać potrzeby różnych interesariuszy, to jednak jej rola wykracza poza mechaniczne realizowanie napływających zadań. W tym modelu pojawia się już myślenie długofalowe, a decyzje dotyczące produktu zaczynają być bardziej świadome i strategiczne.

Jest to model, w którym zarządzanie produktem staje się aktywne i opiera się na realizacji konkretnej wizji. Osoba odpowiedzialna za produkt może mieć realny wpływ na kierunek jego rozwoju, a nawet prawo do odrzucania niektórych pomysłów czy oczekiwań poszczególnych interesariuszy. Dzięki temu możliwe jest skupienie się na priorytetach i konsekwentne podążanie za przyjętą strategią, zamiast realizowania przypadkowych zachcianek.

Po stronie korzyści znajduje się możliwość konsekwentnej realizacji spójnej wizji. W niektórych produktach ma to kluczowe znaczenie, ponieważ pozwala eliminować przypadkowe inicjatywy i skupić się na istotnych aspektach. Istnieje jednak ryzyko oddalenia się od kontekstu biznesowego, strategii firmy czy współpracy z działami takimi jak sprzedaż, marketing czy wsparcie klienta.

Dodatkowym zagrożeniem jest skłonność do preferowania rozwiązań technologicznych. Często pojawiają się zarzuty, że osoby zarządzające produktem od strony IT wybierają priorytety w postaci migracji systemu, aktualizacji technologii czy pełnej refaktoryzacji, zamiast dostarczenia nowych funkcji, które mogłyby przełożyć się na korzyści biznesowe.

Jednocześnie są produkty, w których taki model jest optymalny. W szczególności dotyczy to rozwiązań technologicznych, produktów infrastrukturalnych lub firm dostarczających wysoce zaawansowane technologie, gdzie naturalnym miejscem dla zarządzania produktem pozostaje struktura IT.

Podwójne właścicielstwo 

Model czwarty, umiejscowiony dokładnie na środku omawianej osi, to podwójne właścicielstwo. Niektóre organizacje, często pod wpływem doradców i firm konsultingowych, zdecydowały się na takie rozwiązanie, aby uniknąć dylematu dotyczącego umiejscowienia właścicielstwa produktowego.

W tym modelu funkcjonuje dwóch właścicieli produktu – jedna osoba po stronie biznesu i druga po stronie technologii. W założeniu ma to pozwolić na podział odpowiedzialności: osoba z biznesu wnosi perspektywę strategiczną i rynkową, natomiast właściciel techniczny dba o kwestie funkcjonalne, bezpieczeństwo, wydajność oraz długoterminowe koszty utrzymania systemu. Chodzi o to, aby uzupełnić kompetencje i zapewnić, że kluczowe aspekty produktu nie zostaną pominięte.

W praktyce oznacza to, że w tym modelu istnieje dwóch Product Ownerów, którzy muszą wspólnie podejmować decyzje dotyczące rozwoju produktu. Ich stanowiska mogą różnie się nazywać, jednak istotą rozwiązania jest konieczność uzgadniania priorytetów i współdecydowania o kierunku działań. To może prowadzić zarówno do lepszego bilansu interesów, jak i do potencjalnych wyzwań związanych z procesem decyzyjnym.

Gdybyśmy mieli wskazać największe zagrożenie lub ryzyko tego modelu, to na pewno byłby to dualizm decyzyjny. W skrajnym, negatywnym scenariuszu dwie osoby odpowiedzialne za produkt mogą nie współpracować, wysyłać zespołowi sprzeczne sygnały i ciągnąć produkt w różnych kierunkach.

Mocny przedstawiciel biznesu może ignorować potrzeby technologiczne, na przykład zaniedbywać spłatę długu technologicznego lub odkładać aktualizację bibliotek czy frameworków, które wymagają zmian ze względów bezpieczeństwa. Z kolei dominujący lider techniczny może skupić się wyłącznie na aspektach technologicznych, zaniedbując potrzeby biznesowe, co w efekcie może hamować rozwój produktu w kontekście rynkowym.

Zarządzanie produktem po stronie biznesowej 

Kolejny model, który przybliża nas do przeciwnego końca osi, to zarządzanie produktem po stronie biznesowej. W tym przypadku za produkt odpowiada osoba o silnym profilu biznesowym – może to być Product Manager lub Product Owner wywodzący się z biznesu. Taka osoba ma pełne zrozumienie produktu i patrzy na niego w szerszym kontekście – nie traktuje go jedynie jako aplikacji czy rozwiązania technologicznego, ale jako część większego ekosystemu.

Taki lider rozumie, po co istnieje produkt, jaki jest jego cel i jakie wartości ma dostarczać. Dzięki temu wnosi do zespołu głęboką perspektywę biznesową. Jeśli do tej pory zespołowi brakowało takiego kontekstu, to taka osoba potrafi w stosunkowo krótkim czasie przekazać go zespołowi, pokazując, dlaczego realizowane działania są istotne. Dzięki temu praca zespołu nabiera nowego sensu i głębszego znaczenia, co może pozytywnie wpłynąć na jego zaangażowanie i motywację.

Nadal istnieje wyraźne rozróżnienie – jest ktoś, kto posiada wiedzę, ma dostęp do strategii i zarządu, i to ta osoba przekazuje ją zespołowi. Oczywiście można to zrobić w odpowiedni sposób, z dbałością o współpracę, ale wciąż występuje dynamika, w której jedna strona ma pełne zrozumienie kontekstu i decyduje o kierunku działań, a druga strona te decyzje realizuje. Nadal można to ulepszyć, a poniżej wyjaśniamy w jaki sposób.

W wielu organizacjach ten model ma również swoje zalety, ponieważ wzmacnia mechanizm wspólnej odpowiedzialności zarówno struktur biznesowych, jak i technologicznych. Strona biznesowa decyduje o priorytetach, podczas gdy technologia zajmuje się sposobem realizacji, efektywnością i produktywnością zespołu. Wszyscy są w ten proces zaangażowani, a ewentualne korekty wymagają współpracy menedżerów ze wszystkich obszarów organizacji.

Umocowane zespoły produktowe

W porównaniu do wcześniejszych układów mamy tutaj interdyscyplinarny zespół, który łączy kompetencje produktowe, biznesowe, technologiczne oraz szeroko rozumiane wsparcie. Członkowie zespołu wspólnie tworzą rozwiązania, a ich role nie są wyraźnie rozgraniczone według pionów organizacyjnych – w praktyce trudno określić, kto reprezentuje którą część organizacji.

Wszyscy zaangażowani uczestniczą zarówno w fazie kreatywnej, jak i w realizacji. Nadal istnieje funkcja lidera produktu, jednak jego rola jest bardziej włączająca – nie przynosi on gotowych rozwiązań, lecz współpracuje z resztą zespołu i podejmuje ostateczne decyzje. W efekcie granica między biznesem a technologią zaciera się, a cały zespół działa wspólnie, dążąc do realizacji strategii i wizji produktu.

Gdyby wskazać ryzyka czy słabsze strony tego modelu, to największym problemem jest jego realna trudność w osiągnięciu. Wymaga on istotnych zmian na poziomie mentalnym organizacji. Wymaga też innego profilu kompetencyjnego u członków zespołu – najlepiej sprawdzają się osoby o profilu T, cechujące się dużą otwartością.

W takich zespołach trudno jednoznacznie określić, kto pochodzi z jakiego działu. Przykładowo, o użyteczności aplikacji może wypowiadać się zarówno tester, jak i developer, a niekoniecznie osoba dedykowana do obszaru UX. Jest to kosztowny model, a jeśli nie funkcjonował od samego początku istnienia firmy, to jego wdrożenie może być trudne i bolesne.

Dla organizacji, które znajdują się na wcześniejszych etapach naszej osi i nie mają jeszcze jasno określonego właścicielstwa produktowego, przejście na ten model może być zbyt dużym skokiem. Mogą pojawić się pytania i wątpliwości dotyczące odpowiedzialności, co wymaga dużych zmian mentalnych i kulturowych w organizacji.Jeśli chcesz pogłębić wiedzę jeszcze bardziej, możesz znaleźć nasze płatne materiały na stronie porzadnyagile.pl/sklep

Jak w praktyce podejść do zmiany właścicielstwa produktowego?

Zdefiniuj gdzie jesteś

Pierwsza porada jest dość prosta – określ, w jakim miejscu się znajdujesz. Sprawdź, gdzie na przedstawionej przez nas osi lub na własnej, jeśli masz inne podejście, plasuje się Twoja organizacja. Warto oprzeć się nie tylko na własnej intuicji, ale także zebrać opinie zespołów, interesariuszy biznesowych i managerów, aby uzyskać pełniejszy obraz sytuacji. Jednym z największych zagrożeń jest błędne postrzeganie własnej organizacji – gdy wydaje się, że jest się na poziomie 5 lub 6, podczas gdy w rzeczywistości firma dopiero osiągnęła poziom 2. Każdy model wymaga odrębnej strategii zmiany, dlatego kluczowe jest dokładne zrozumienie punktu wyjścia.

Ma to szczególne znaczenie w większych organizacjach, gdzie różne zespoły mogą znajdować się na różnych etapach dojrzałości produktowej. Często zdarza się, że w jednej firmie istnieją zespoły bardziej progresywne, funkcjonujące w sprzyjającym środowisku, podczas gdy inne obszary wciąż pozostają na wcześniejszym etapie rozwoju. Firmy obsługujące różne rynki czy posiadające wiele linii biznesowych mogą mieć odmienne potrzeby i poziom zaawansowania, co wymaga szczególnej uwagi przy planowaniu zmian. Dlatego kluczowe jest właściwe określenie punktu startowego, aby nie narzucać zbyt ambitnych zmian, które w niektórych obszarach mogą okazać się nierealne – np. jeśli firma nigdy nie miała jasno określonego właścicielstwa produktowego, próba natychmiastowego wdrożenia zespołów produktowych może być zbyt dużym skokiem i zakończyć się fiaskiem.

W praktyce może to oznaczać, że wprowadzane zmiany nie obejmą całej organizacji, lecz będą dotyczyć wybranego fragmentu struktury. Może to być konkretny obszar, określony value stream lub inna jednostka organizacyjna funkcjonująca w Twojej firmie. W takiej sytuacji zmiana będzie miała bardziej ograniczony zasięg, niż początkowo można by zakładać.

Ustal jakich rezultatów oczekujesz po zmianie

Warto określić spodziewane efekty w sposób jak najbardziej konkretny i mierzalny. Im precyzyjniejsze wskaźniki, tym łatwiej będzie ocenić skuteczność przeprowadzanych działań. Przykładem takich mierników mogą być lead time lub cycle time, czyli – upraszczając – czas od pomysłu do realizacji lub czas od rozpoczęcia pracy do jej zakończenia. To aspekty, które można stosunkowo łatwo zmierzyć i śledzić w czasie.

Jednak oprócz mierzalnych parametrów warto uwzględnić również czynniki trudniejsze do ujęcia w liczbach, ale mające istotny wpływ na funkcjonowanie organizacji. Przykładem mogą być odczucia zespołów dotyczące sensu ich pracy czy subiektywna ocena realizacji potrzeb biznesowych. Choć trudno je wyrazić w konkretnych wartościach liczbowych, nadal stanowią istotne aspekty, które warto uwzględnić jeszcze przed rozpoczęciem procesu zmiany.

Istnieją organizacje, w których pomiary są na wysokim poziomie, co pozwala na wybór odpowiednich wskaźników do monitorowania oraz określenie poziomu aspiracji i oczekiwanych rezultatów po wprowadzeniu zmian. Jednak nie wszystkie firmy dysponują dobrze rozwiniętym systemem mierników, co może utrudniać ocenę efektów transformacji.

W takich przypadkach warto rozważyć wdrożenie nowych metod pomiaru jako element zmiany w zakresie umiejscowienia właścicielstwa produktowego czy funkcjonowania zespołów produktowych. Może to obejmować wykonanie pomiaru bazowego przed wprowadzeniem zmian, aby później, po ich wdrożeniu i ustabilizowaniu, możliwe było dokonanie rzetelnego porównania. Przykładem takiego podejścia może być mierzenie poziomu satysfakcji ze współpracy w zespołach – przeprowadzenie ankiety przed i po zmianie pozwoli określić, czy przyniosła ona oczekiwane rezultaty.

Aby móc realnie ocenić, czy sytuacja się poprawiła, warto z wyprzedzeniem określić, jakie aspekty będą mierzone, oraz przygotować odpowiednie narzędzia do ich monitorowania, zwłaszcza jeśli obecnie firma lub jej część strukturalna nie posiada rozwiniętego systemu pomiarowego.

Określ argumenty przemawiające za utrzymaniem obecnego stanu rzeczy

Trzecia porada może wydawać się nieco przewrotna – określ argumenty przemawiające za utrzymaniem obecnego stanu rzeczy. Warto zastanowić się, co może powodować opór wobec zmiany, ponieważ każda transformacja – zwłaszcza strukturalna – spotka się z pewnym poziomem sprzeciwu. Dotyczy to szczególnie sytuacji, w której właścicielstwo produktowe przechodzi na stronę biznesową, ponieważ taki ruch niesie ze sobą całą pulę potencjalnych wyzwań.

Dobrze jest więc z góry przewidzieć możliwe źródła oporu, określić, jakie argumenty mogą się pojawić przeciwko zmianie i kto może je podnosić. Pozwoli to lepiej zaplanować proces komunikacji, zarówno pod kątem przedstawienia racjonalnych argumentów, jak i opracowania mechanizmów wspierających transformację. Dzięki temu możliwe będzie odpowiednie zarządzanie obawami oraz dostarczenie kontrargumentów lub wskazanie korzyści, które przewyższą potencjalne trudności. Kluczowe jest, aby każdy uczestnik zmiany dostrzegł w niej wartość i miał poczucie, że nowy model przynosi mu konkretne korzyści.

Cztery najczęściej spotykane powody oporu:

Biznes nie rozumie IT. To często pojawiająca się obawa, która prowadzi do utrzymania status quo – na zasadzie: „My zajmujemy się biznesem, a IT niech robi swoje, i lepiej nie wchodźmy sobie w drogę.” W takiej sytuacji warto zainwestować w zwiększenie wzajemnego zrozumienia. Osoby rozwijające produkty w firmach technologicznych nie muszą być ekspertami ani umieć programować, ale powinny rozumieć podstawowe aspekty technologiczne i konsekwencje decyzji technicznych. W drugą stronę, osoby odpowiedzialne za technologię powinny znać kontekst biznesowy i rozumieć realne potrzeby użytkowników oraz strategię firmy.Na rynku istnieją specjaliści, którzy łączą oba światy, ale takie kompetencje można też rozwijać wewnętrznie. Dobrym rozwiązaniem może być także zapewnienie wsparcia w postaci ról takich jak architekt czy Tech Lead, którzy będą partnerami dla osób biznesowych i pomogą im stopniowo lepiej rozumieć kwestie technologiczne.

Biznes i IT nie mówią tym samym językiem, więc musi być ktoś, kto będzie ich tłumaczem. W szczególności dotyczy to modeli, w których Product Owner pozostaje po stronie technologii i pełni funkcję pośrednika. Zwolennicy tego podejścia często argumentują, że tacy Product Ownerzy rozumieją zarówno biznes, jak i technologię, więc lepiej, aby to oni nadal pełnili tę rolę.
To argument, który można skutecznie podważyć. Fakt, że dzisiaj obie strony mogą mieć trudności w komunikacji, nie oznacza, że tak musi pozostać. Zbliżenie biznesu i IT, o którym pisaliśmy w odcinku 130, może w dużej mierze rozwiązać ten problem.

Kluczowe działania to:
Integracja zespołów – zamiast działać osobno, zespoły biznesowe i technologiczne mogą pracować bliżej siebie.
Stworzenie wspólnego słownika – określenie jednoznacznych definicji i terminologii, które będą zrozumiałe dla obu stron.
Wypracowanie sposobu komunikacji – umiejętność zadawania pytań, zatrzymywania się, parafrazowania i doprecyzowywania, tak aby nie było miejsca na błędne interpretacje.
Oczywiście, przesunięcie właścicielstwa produktowego do biznesu może oznaczać pewien okres przejściowy, w którym pojawią się tarcia, nieporozumienia czy śmieszne sytuacje wynikające z różnic w interpretacji tych samych terminów. Jednak w dłuższej perspektywie zespół nauczy się efektywnej komunikacji i nie będzie potrzebował tłumacza między dwiema stronami.,

Trzecim często spotykanym argumentem przeciwko zmianie jest przekonanie, że Biznes nie ma czasu na angażowanie się w pracę z zespołami produktowymi. To podejście stanowi istotne ograniczenie. W jednej z firm, z którą mieliśmy styczność, prezes jasno zakomunikował: „Transformujmy się, zmieniajmy, ale osoby z biznesu nie będą pracować z zespołami – nie mają na to czasu”. Ta decyzja spowodowała, że w rolę Product Ownerów biznesowych weszli Project Managerowie.Było to jakieś rozwiązanie – na pewno lepsze niż brak właścicielstwa produktowego. Jednak brak prawdziwego kontekstu biznesowego sprawił, że zespoły produktowe cierpiały. W praktyce rola Product Ownera została sprowadzona do przekazywania wymagań i pilnowania ich realizacji, a nie do faktycznego zarządzania produktem w sposób uwzględniający potrzeby rynku i strategię firmy.

Czwartym często podnoszonym argumentem przeciwko zmianie jest przekonanie, że tylko technologiczny Product Owner zagwarantuje, że aspekty technologiczne będą odpowiednio priorytetyzowane i zaopiekowane.W niektórych organizacjach towarzyszy temu obawa, że jeśli odpowiedzialność za priorytety zostanie przekazana stronie biznesowej, to wszystkie najważniejsze kwestie technologiczne,  takie jak migracje, automatyzacje czy spłata długu technicznego, zostaną natychmiast odrzucone. Może pojawić się presja, aby dostarczać rozwiązania szybciej, kosztem jakości i długofalowego utrzymania systemów.Kluczową rolę odgrywa tutaj jasna umowa między liderami technologicznymi a liderami biznesowymi. Organizacja powinna wypracować mechanizmy zapewniające odpowiednią równowagę między potrzebami biznesowymi a koniecznością dbania o stabilność i rozwój technologiczny.Formalna alokacja części przepustowości zespołu na zadania technologiczne. W jednej z organizacji przyjęto zasadę, że 20% zasobów zespołu zawsze jest przeznaczane na kwestie technologiczne. W takim układzie Product Owner z biznesu może decydować o priorytetach wewnątrz tej puli, ale nie może jej całkowicie wyeliminować. Warto zadbać o przejrzyste Definition of Done, które określa niepodlegający negocjacjom standard jakości. To chroni zespoły przed presją na przyspieszanie kosztem długoterminowej stabilności systemów i pozwala uniknąć scenariusza, w którym „zrobimy to szybko teraz, a poprawimy później” – bo w praktyce często to „później” nigdy nie następuje.Istnieje wiele sposobów na zabezpieczenie równowagi między biznesem a technologią. Kluczowe jest, aby organizacja świadomie wypracowała model, który pozwoli zaopiekować obie te sfery, zamiast przyjmować założenie, że tylko technologiczny Product Owner może o nie zadbać.

Zachęcamy jednak do samodzielnego przeanalizowania sytuacji w swojej organizacji, ponieważ w Twojej firmie mogą występować inne powody lub dodatkowe obawy, które nie zostały tutaj wymienione.

Nie sposób wyczerpać wszystkich możliwych argumentów, dlatego warto świadomie pochylić się nad tą kwestią, aby zrozumieć, co może powodować opór wobec zmian i jak najlepiej na te obawy odpowiedzieć.

Narysuj mapę sojuszników i przeciwników zmiany 

Czwarta porada dotyczy sposobu na skuteczną zmianę właścicielstwa produktowego w organizacji. Zbudowanie mapy sojuszników i przeciwników zmiany pozwala lepiej zrozumieć układ sił i zaplanować działania tak, aby zmiana miała większe szanse powodzenia.

Zdefiniuj kluczowe osoby – zastanów się:

• Kto wesprze zmianę i będzie aktywnie pomagał w jej wdrożeniu?
• Kto pozostanie neutralny – nie sprzeciwi się, ale też nie będzie inicjatorem działań?
• Kto może być przeciwnikiem – czy to z obawy przed zmianą, czy z powodów organizacyjnych?

Takie zmiany, zwłaszcza te dotyczące przesuwania odpowiedzialności w strukturze organizacyjnej, często budzą sprzeciw. Ważne jest, aby rozpoznać zależności i wpływy, a następnie budować krąg sojuszników, którzy pomogą przekonać osoby sceptyczne.

Jeśli mówimy o stworzeniu mapy, dosłownie warto ją narysować. Może tu pomóc technika Stakeholder Bottleneck Mapping opisana m.in. w materiale wideo Geoffa Watsa  https://www.youtube.com/watch?v=B_WfnnNUC6o, . To proste narzędzie, które często prowadzi do odkrycia złożonych zależności w organizacji.

Ciekawym wnioskiem może być to, że nawet przeciwnicy zmiany mają w swoim otoczeniu osoby, które na nich wpływają. Może to być przełożony wyższego szczebla, ale też ktoś, kogo opinię dana osoba ceni. Identyfikacja takich powiązań pozwala na bardziej strategiczne działanie – jeśli nie możesz przekonać kogoś bezpośrednio, możesz znaleźć osobę, która ma na niego wpływ.

Warto więc zaplanować sprytną, dyplomatyczną akcję, aby zbudować poparcie dla zmiany i przeprowadzić ją skutecznie.

Myśl o strukturze jak o żyjącym bycie, a nie finalnym ustawieniu

Przedostatnia porada dotyczy postrzegania struktury organizacyjnej jako dynamicznego, ewoluującego bytu, a nie finalnego, niezmiennego ustawienia.

Nie należy zakładać, że zmiana modelu właścicielstwa produktowego lub przesunięcie się po omawianej wcześniej osi to jednorazowy proces. W rzeczywistości organizacje stale ewoluują, a struktury zmieniają się w odpowiedzi na nowe potrzeby, wyzwania i możliwości.

Z doświadczenia wynika, że apetyt na usprawnienia rośnie. Organizacje, które odniosły sukces, nie przywiązują się zbyt mocno do aktualnego modelu, lecz iteracyjnie doskonalą sposób, w jaki produkty są rozwijane i zarządzane.

Warto przyjąć otwartość na przyszłe zmiany, bo w dobrze funkcjonujących organizacjach ciągła refleksja nad strukturą prowadzi do kolejnych usprawnień. Z czasem pojawiają się nowe pomysły na to, jak można zwiększyć efektywność, skrócić czas dostarczania wartości i lepiej organizować współpracę.

Dlatego zamiast traktować nowy model jako ostateczny, warto myśleć o nim jako o kolejnym kroku w kierunku doskonalenia organizacji.To, że struktura produktowa podlega zmianom, nie jest błędem – wręcz przeciwnie, to naturalna część planu.

Otoczenie rynkowe jest zmienne, strategia organizacji może ewoluować, a niektóre produkty mogą się rozwijać szybciej lub zmieniać swoje miejsce na rynku. Wszystkie te czynniki są racjonalnymi argumentami za tym, by nieustannie doskonalić i dostosowywać strukturę produktową – a czasami nawet cofać wprowadzone zmiany, jeśli okazują się one mniej efektywne, niż zakładano.

Dodatkowym aspektem, który ma kluczowe znaczenie, jest wyczucie właściwego momentu na wprowadzenie zmiany. Czasami pojawia się okienko możliwości – nowy lider w organizacji, wyraźna potrzeba korekty procesów lub inna okazja, którą można wykorzystać do usprawnienia modelu zarządzania produktem. W takich sytuacjach warto działać szybko i odpowiednio reagować na kontekst biznesowy.

Z drugiej strony, mogą zdarzyć się sytuacje, w których lepszym wyborem jest wstrzymanie zmian i przeczekanie do bardziej sprzyjających warunków. Najlepszym podejściem jest posiadanie wizji stanu docelowego, przemyślany plan kilku kroków naprzód, ale jednocześnie elastyczność w dostosowywaniu tempa zmian. Daty wdrożenia nie powinny być sztywne – może się okazać, że niespodziewane okoliczności wymagają zarówno przyspieszenia, jak i wstrzymania transformacji.

Przyjmij, że lepsze jakiekolwiek właścicielstwo niż jego brak

Choć każdy z modeli ma swoje plusy i minusy, a umiejscowienie właścicielstwa produktowego w organizacji może być mniej lub bardziej efektywne, to przejście z modelu całkowitego braku właścicielstwa na jakikolwiek model – nawet niedoskonały – jest krokiem naprzód.

Nawet jeśli organizacja jest na etapie, gdzie jedyną możliwą opcją jest zarządzanie Backlogiem po stronie IT, to nadal jest to lepsze rozwiązanie niż brak odpowiedzialności i funkcjonowanie w chaotycznym modelu bez jasno określonego kierunku.

Jeśli w Twojej firmie lub strukturze właścicielstwo produktowe praktycznie nie istnieje, warto zastanowić się, co stoi na przeszkodzie jego wprowadzeniu i spróbować pokonać te bariery. Nawet minimalne właścicielstwo może przynieść znaczną poprawę, niezależnie od tego, czy zostanie ono umiejscowione po stronie IT, czy po stronie biznesu. Najważniejsze jest, aby wykorzystać najlepsze możliwe rozwiązanie, na jakie organizacja jest gotowa w danym momencie.

Jak w praktyce podejść do zmiany właścicielstwa produktowego? 

1. Zdefiniuj sobie gdzie w ogóle jesteś 
2. Ustal jakich rezultatów oczekujesz po zmianie
3. Określ argumenty przemawiające za utrzymaniem obecnego stanu rzeczy
4. Narysuj mapę sojuszników i przeciwników zmiany
5. Myśl o strukturze jak o żyjącym bycie, a nie finalnym ustawieniu
6. Przyjmij, że lepsze jakiekolwiek właścicielstwo niż jego brak

Jeśli czujesz, że potrzebujesz pomocy we wdrożeniu takich zmian u siebie, wspieramy liderów technologicznych w skutecznych transformacjach konkretnie i praktycznie. Pomagamy dostosować modele do specyfiki Twojej organizacji i działamy razem z Tobą. Porozmawiamy. Napisz na adres kontakt@porzadnygagile.pl

Dodatkowe materiały

• Stakeholder battlemapping
• Jak zbliżyć do siebie biznes i IT

Transkrypcja podcastu „Właścicielstwo produktowe – w Biznesie czy w IT?”

Jacek: Rozmawiałem ostatnio z szefem produktu, który dołączył do nowej firmy. Chwilę rozmawialiśmy o tym, jak wygląda środowisko pracy. Wspomniał, że jest tam dosyć spory podział, taki klasyczny między IT i biznesem. I temat, któremu poświęciliśmy najwięcej uwagi, to była dyskusja o właścicielstwie produktowym. Gdzie to właścicielstwo produktowe powinno być umieszczone w organizacji oraz porozmawialiśmy o możliwych rozwiązaniach.

Kuba: I abstrahując od tej konkretnej Jacka rozmowy, postanowiliśmy wspólnie, że to jest dobry temat na szeroki, konkretny, pełnoskalowy odcinek. Więc poopowiadam o tym, gdzie umiejscowić właścicielstwo produktowe i ewentualnie jak je zmienić, jeśli w Twojej organizacji czujesz, że zmiana powinna nastąpić. I co mamy na myśli, gdy mówimy w ogóle o właścicielstwie produktowym? Mamy tutaj na myśli umiejscowienie osób, a w zasadzie ich raportowanie w strukturze, konkretna podległość służbowa osób, które zarządzają produktem, jakkolwiek te osoby w Twojej firmie są nazwane. To mogą być Product Ownerzy, to mogą być Product Managerowie. W niektórych organizacjach z różnych przyczyn te stanowiska mogą się jeszcze jakoś inaczej nazywać. Nie będziemy tutaj świadomie za długo wyliczać tych możliwych kombinacji, ale powiedzmy w miarę możliwości zamiennie będziemy mówić właśnie Product Ownerzy, Product Managerowie i mamy na myśli również na przykład specjalisty rozwoju, funkcjonalności albo tego typu odmiany. No i spotykamy różne organizacje, modele funkcjonują różne. Te osoby mogą być bardziej po stronie IT czy technologii, jakkolwiek to w firmie się nazywa, czasami są po stronie biznesu, czasami są osobną strukturą gdzieś zaczepioną pod zarządem. Zarysujemy tutaj te możliwe pozycje strukturalne według takich najpopularniejszych modeli, jakie spotykamy. Trochę też scharakteryzujemy te przypadki. Na pewno nie chcemy powiedzieć, że który jest lepszy lub gorszy, ale po prostu pokazujemy, co naszym zdaniem wiąże się z takim, a nie innym układem.

Jacek: I dlaczego w ogóle ten temat jest ważny? Jest to naszym zdaniem ważny kawałek układanki dotyczącej tego, jak blisko bądź jak daleko współpracuje ze sobą biznes i IT. No, mamy tutaj z Kubą wyraźną preferencję. Nasze doświadczenie pokazuje, że im bliżej te dwa byty funkcjonują, im bardziej to jest taka naturalna współpraca ponad granicami departamentów czy strukturalnych, tym po prostu jest lepiej. Nie będziemy o samych korzyściach zbliżania biznesu i IT rozmawiać w tym odcinku, bo mamy cały odcinek nagrany tylko o tym temacie. Jeżeli jesteś zainteresowany tym tematem, to odsyłamy do odcinka „Jak zbliżyć do siebie biznes i IT”. Jest to odcinek numer 130.

Kuba: Do znalezienia pod adresem porzadnyagile.pl/130. Ale taka teza, która jest gdzieś z tyłu tego odcinka, to to, że odpowiednie umiejscowienie właścicielstwa produktowego może wpływać na zaangażowanie zespołu wspólną, odpowiedzialność czy takie poczucie odpowiedzialności, sprawność podejmowania decyzji i pewnie jeszcze parę innych kwestii. Więc jest to aspekt ważny i przejdźmy teraz do konkretnych. O czym opowiem w tym odcinku?

Jacek: Spis treści na dzisiaj. Opowiemy, jakie widzimy możliwe modele umiejscowienia właścicielstwa produktowego w organizacji. W drugiej części nagrania podzielimy się tym, jak w praktyce podejść do zmiany właścicielstwa produktowego.

Kuba: Ok, to zaczynając od pierwszego rozdziału, jakie są możliwe modele umiejscowienia właścicielstwa produktowego?

Jacek: Tak, no to pierwszym punktem na tej osi, takim punktem startowym, to jest brak jasnego właścicielstwa. Oznacza to, że ono nie jest wyraźnie zdefiniowane, czyli nie możemy powiedzieć, że jest w jakimś konkretnym obszarze organizacji. W szczególności nie możemy powiedzieć, czy jest bardziej po stronie IT, czy po stronie biznesu. Po czym poznać taką sytuację? Jest yo bardziej praca, która jest realizowana na losowych zlecaniach, na zasadzie one skądś przychodzą, pewnie jest jakaś osoba, której zależy, ale tak na koniec dnia nie ma pełnej jasności, gdzie leży odpowiedzialność za decyzje. W takim gorszym scenariuszu może to oznaczać, że w organizacji jednocześnie toczy się wiele inicjatyw, czy wiele projektów, czy wiele zmian, które mogą ze sobą bądź konkurować, a czasem w też przez brak koordynacji i takiego spojrzenia z lotu ptaka mogą się nawet wzajemnie wykluczać.

Kuba: Realnie pewnie ktoś istnieje, kto na końcu podejmie pewną decyzję, czym się zajmują zespoły wytwórcze, ale może być to ktoś, kto robi to z musu, robi to osoba, która na przykład nie ma żadnego kontekstu biznesowego, tylko po prostu zajmuje się priorytetyzacją zadań, na przykład na minimalizację krzyku. Czyli na przykład lider zespołu skupia swoją uwagę na tym, żeby jak najmniej podpaść i jakoś tam balansuje między zapytaniami, zleceniami, projektami, jakimiś zmianami, ale tak naprawdę tam nie ma żadnego myślenia produktowego, jest co najwyżej gdzieś tam kierowanie strumieniem prac. Tak chcemy to może uwypuklić, bo jednak na początku trochę powiedzieliśmy, że będziemy oceniać, tak wydaje się, że ten model, w którym nie ma w ogóle żadnego właścicielstwa, od niego zaczynamy, on raczej głównie ma wady i ma mało zalet. Rozumiem organizacje, w których w takim stadium istnieją, funkcjonują, ale ten akurat stan na pewno warto zmienić, o czym będziemy mówili w drugim rozdziale.

Kuba: Drugi model to zarządca Backlogów IT. Tu już jest trochę lepiej, gdyby kogoś zapytać, kto tutaj zarządza produktem, to być może przynajmniej część członków zespołu i być może część reszty organizacji powiedziałaby: No jest taki ktoś, może to jest Product Owner, może to jest lider zespołu, może to jest nawet Product Manager, chociaż najczęściej takich akurat nazw na to bym nie dawał. Jest ktoś, kto siedzi po stronie IT, albo jest częścią konkretnego jednego zespołu, albo jest częścią jakiejś dodatkowej niewielkiej struktury w ramach struktury całego IT czy technologii. Jest to osoba, która gromadzi zlecenia, zbiera inicjatywy od interesariuszy biznesowych, realizuje te projekty, odbiera i przekazuje do zespołu, tak chcę może to trochę wypuklić, realnie nie tworzy produktu. Realnie tylko jakby skupia się na tym, żeby wiedzieć, czego się oczekuje od zespołów w miarę sprawnie przekazać to do realizacji. Nie ma tam żadnej sprawczości produktowej.

Jacek: Taki generalny komentarz do tego odcinka, nawet jak mówimy Backlog, czy jak mówimy Product Owner, to nie mamy tutaj na myśli Scruma. Natomiast te pojęcia tak bardzo już przeniknęły do firm, że właściwie są stosowane jako takie naturalne określenia. Drugi komentarz jest taki, że tutaj w szczególności w tym przypadku ten zarządca Backlogu raczej nie decyduje o tym, co jest realizowane, więc jest takim trochę bezwiednym realizatorem tego, co chcą ludzie w oku, interesariusze. Co też może prowadzić do tego, że trochę te krzyki, o których Kuba powiedział, ten nacisk, będą wygrywać te osoby, które będą miały większą siłę przebicia, a to niekoniecznie będzie przekładać się na wartość dostarczonego rozwiązania czy produktu. Ale dla bycia fair powiedzmy, że ma to już pewną zaletę.

Kuba: Ale dla bycia fair warto dodać, że takich zarządca w Backlogu w IT, no to w porównaniu do poprzedniego modelu, gdzie nie ma w ogóle żadnego właścicielstwa, ma już tę zaletę, że być może jest szansa na jakieś ucywilizowanie strumienia prac, być może jakieś poukładanie, chociaż minimalną dyskusję z tymi interesariuszami, może jakieś łączenie tych inicjatyw w jakieś większe sensowne kawałkialbo świadome ich dzielenie, ale w każdym razie minimalne wpływanie na ten strumień. I to już jest coś, to tutaj bądźmy fair, jakkolwiek może krytycznie przed chwilą to charakteryzowaliśmy. Taki model najczęściej jest in plus w momencie, gdy się go wprowadzi w porównaniu do poprzedniego etapu.

Jacek: Trzeci model, zarządzanie produktem po stronie IT. Czyli tutaj w porównaniu do poprzedniego modelu, mamy jednak jakiegoś, już nazwijmy to Product Ownera, czyli kogoś, kto nie jest pasywnym realizatorem wizji okolicznych interesariuszy, tylko jednak samodzielnie zarządza. Może ma jakąś wizję, może ma jakąś własną Road mapę, może nawet ma jakieś wskaźniki. W każdym razie już próbuje w zależności od umiejętności i możliwości tym produktem zarządzać. Nadal on jest po stronie IT, więc chcąc nie chcąc, na pewno ma jakąś grupę interesariuszy, których musi opanować, którymi musi zarządzić, ale już nosi to jakieś takie znamiona tego, że ktoś spędza czas na tym, żeby o produkcie myśleć trochę bardziej długofalowo, niż tylko róbmy taski, bo ktoś chce i te taski do nas spływają.

Kuba: Jest to model, w którym to zarządzanie produktem już jest aktywne, to jest realizacja konkretnej wizji, to jest model, w którym ten zarządzający produktem być może nawet ma prawo odmawiać konkretnie, skupiać się tylko na tym, co sobie wymyślił czy wymyśliła, niezależnie od tego, co konkretny jakiś inny interesariusz sobie marzy. Po stronie plusów jest już faktycznie realizacja konkretnej wizji, ta wizja w niektórych produktach jest super istotna, bo pozwala odrzucać wiele zachcianek. Ewentualnym zagrożeniem czy ryzykiem takiego modelu pozostaje oddalenie się od kontekstu biznesowego, od strategii firmy, od pozostałych zespołów biznesowych, jakichś sprzedaży, jakiegoś marketingu, jakiegoś wsparcia, jakkolwiek to wygląda w danej firmie i w jej specyfice branży. No i jest też takie zagrożenie, że być może będą preferowane rozwiązania technologiczne. To spotykamy takie narzekanie na tych Product Ownerów czy managerów technologicznych, że wybrali migrację systemu, update kolejnej wersji języka, czy totalny refactoring, zamiast dołożyć jeszcze kolejną funkcję, za którą by w tym roku albo w tym kwartale dało się jeszcze trochę zarobić biznesowo. Więc tutaj istnieje zagrożenie takiej świadomej intencji preferowania rozwiązań technologicznych. I kontra do samego siebie, ale są też produkty, w których to jest absolutnie taki end state, to już jest ten moment i to umiejscowienie, które jest właściwe, no bo chociażby rozwiązania bardzo technologiczne z jakichś takich może niższych warstw albo w firmach, które zapewniają bardzo technologiczne produkty albo chociażby w którejś z produktów. Po prostu to będzie naturalne umiejscowienie zarządzania produktem właśnie w zespole technologicznym.

Kuba: Model czwarty, taki jak powiedzieliśmy o osi, to model ewidentnie na samym środku tej osi, to podwójne właścicielstwo. Są organizacje, tutaj są doradcy, konsultingi, które to podpowiadają, żeby tak właśnie to rozwiązać, które wybrnęły z dylematów, gdzie umiejscowić się właścicielstwo produktowe w dosyć niezbyt fajny sposób, bo tutaj nie ukrywam, że mam zdanie na ten temat. Po prostu ustanowiono podwójnego na przykład Product Ownera, właściciela produktu, zarówno osobę z biznesu i drugą osobę po stronie technologicznej. No i w takim powiedzmy pozytywnym świetle, patrząc na sprawę, no to chodzi o to, żeby ustanowić pewną odpowiedzialność biznesową u kogoś, kto przychodzi z tego świata biznesowego i ta osoba ma współdecydować o rozwiązaniu razem z właścicielem technicznym, który właśnie skutkuje się na tych aspektach, które wymieniałem też w poprzednim modelu, czyli jakieś kwestie związane na przykład z wymaganiami funkcjonalnymi, bezpieczeństwem, wydajnością, kwestiami związanymi z kosztami utrzymania systemu w drugim okresie, czyli tak naprawdę jakby takie uzupełnienie tych rzeczy, o których można się spodziewać, że osoba ze strony biznesowej albo nie będzie do końca rozumieć, albo nie będzie uznawać ich wielkich wagi. Więc realnie taki zespół w tym modelu ma po prostu dwóch Product Ownerów. Oni mogą się różnie nazywać, bo też my tutaj nie bawimy się w etykiety, ale po prostu jest dwóch decydentów o tym, co jest ważne i ci decydenci się w jakiś sposób muszą dogadać, żeby faktycznie ostatecznie zespół dostał priorytet.

Jacek: Gdybym miał wskazać takie z mojej perspektywy największe zagrożenie czy ryzyko tego modelu, no to na pewno ten dualizm. Czyli w takim skrajnym, negatywnym przypadku, no to te dwie osoby mogą nie współpracować. Mogą dawać zespołowi sprzeczne sygnały, no i mogą bardzo mocno ciągnąć produkt w swoją stronę. Czyli mocny biznesowiec może trochę zagłodzić potrzeby technologiczne, np. potrzeby spłaty długu albo zmiany jakiejś biblioteki czy frameworka, który już wymaga np. ze względów bezpieczeństwa zmiany, ale też w drugą stronę silny, techniczny, może ciągnąć we wszystkie te rzeczy, zagładzając z kolei potrzeby biznesowe.

Jacek: Kolejny model i już dosyć mocno tutaj zbliżamy się do przeciwnego końca osi, to model, w którym zarządzanie produktem występuje po stronie biznesowej. Czyli mamy tutaj osobę odpowiedzialną biznesowo, jakiegoś Product Managera, Product Ownera, który pochodzi z biznesu, jest osobą biznesową i absolutnie czuje, o co chodzi z produktem. Patrząc na produkt, patrzę na niego szerzej, to nie jest tylko apka, to nie jest tylko rozwiązanie technologiczne, ale rozumie tak naprawdę cały ekosystem. Rozumie, po co jest ta aplikacja, częścią, jakiego większego produktu ona jest. No i tak naprawdę czuje po co, dlaczego i w jakim celu pewne rzeczy są realizowane. Taka osoba przynosi takie bardzo mocne spojrzenie biznesowe do zespołu, więc jeśli zespół dotychczas nie miał takiego kontekstu, no to taka osoba potrafi w miarę w dosyć krótkim okresie czasu zarazić zespół, pokazać po co, dlaczego, dać ten szerszy obrazek, który spowoduje, że praca w tych zespołach może nabrać kompletnie nowego sensu i nowego wymiaru.

Kuba: Jeśli myślisz, że to jest już ostatni i ten piękny obraz, no to ja tutaj zwrócę uwagę na słowo przynosi, którego Jacek użył. Mimo wszystko ten model ma pewną wadę w związaniu z tym, że jest nadal jakieś takie odróżnienie, że jest ktoś, kto wie, ktoś, kto jest mądry, ktoś, kto ma połączenie ze strategią z odpowiednio wysokimi zarządzającymi i to ta osoba do tego zespołu przynosi właśnie, jakby oznajmię, pokazuje. Oczywiście można to zrobić na miękko, można to zrobić w dobrej otoczce, ale nadal jest tego rodzaju dynamika, że jest ktoś, kto wie, ktoś, kto myśli, ktoś, kto jest dobrze wtajemniczony i ten ktoś przenosi pewną wytyczną do zespołów. Nadal da się lepiej, za chwilę opowiemy jak. Oczywiście w wielu organizacjach ten model jest też dla równowagi bardzo korzystny, bo tak faktycznie uruchamia mechanizm odpowiedzialności wspólnej zarówno struktur biznesowych, jak i tych struktur technologicznych za sukces, no bo tak naprawdę o priorytetach tego, co jest realizowane, decyduje strona biznesowa, o sposobie dostarczenia, o takiej też może wydajności czy produktywności zespołu, no to siłą rzeczy pozostaje odpowiedzialność technologiczna i w pewnym sensie wszyscy są w to zamieszani. Są w to włączeni i ewentualne korekty też tego modelu, wymagają już też zaangażowania wszystkich managerów z każdej możliwej takiej stereotypowej struktury Biznesu i IT.

Kuba: No i zapowiedziany ostatni model to umocowane zespoły produktowe. W porównaniu do poprzedniego układu mówimy tutaj o sytuacji, gdzie tak naprawdę stworzony został mocny, interdyscyplinarny zespół, posiadający kompetencje zarówno te produktowe, biznesowe, szeroko rozumiane wsparciowe, jak i technologiczne. Wszyscy razem tworzą zespół i tak naprawdę nie do końca, gdyby wejść na jakąś sesję kreatywną, warsztatową, to byśmy tak bardzo odróżniali, kto jest z którego pionu. Chyba że stereotypowo jedni noszą swetry, a inni nie. Ale wracając na poważnie, wszyscy są zaangażowani, starają się zarówno uczestniczyć w tej fazie kreatywnej wymyślania rozwiązania, jak i poświęcają swoją energię również na te etapy dostarczenia. I faktycznie w zespole prawdopodobnie pozostaje jakaś osoba naznaczona jako lider produktu, ale ta osoba jest bardzo mocno demokratycznie wciągnięta w całą resztę. Powiedziałbym, jest to osoba, która ostatecznie decyduje, a nie przynosi, jak w poprzednim Jacek modelu to zarysował. Więc tutaj takie umocowane zespoły produktowe zacierają tę granicę biznesu i technologii. Tak naprawdę wszyscy razem staramy się zaopiekować i przesunąć produkt w pożądanym kierunku, zgodnym ze strategią, zgodnym z wizją całego produktu.

Jacek: Gdybym miał wskazać ryzyka czy jakieś takie słabsze elementy tego modelu, wydaje mi się, że chyba największym problemem jest to, że to jest realnie dosyć trudne do osiągnięcia. Wymaga sporych zmian na poziomie mentalnym w organizacji. Trochę myślę też innego profilu kompetencyjnego, jeśli chodzi o ludzi w zespole. Szukałbym pewnie tutaj osób o tym profilu kompetencji, typu T, osób o dużej otwartości. Tak jak Kuba mówił, często na tych sesjach, gdzie pracują, trudno powiedzieć, kto jest skąd, z jakiego macierzystego działu, bo na przykład o użyteczności aplikacji wypowiada się i tester, i developer, a niekoniecznie na przykład osoba, którą byśmy gdzieś tam wsadzili do ogródka UX-owego. Więc myślę, że jest to kosztowny dosyć model, do którego jeżeli on od początku powstania firmy nie funkcjonuje, no to przejście może być dosyć bolesne, no bo wyobraźmy sobie, że rozmawiamy o firmie, które jest na początku naszej osi, nie ma w ogóle jasnego właścicielstwa, no to dojście do tego, że są umocowane zespoły produktowe, to w ogóle może być zbyt duży przeskok na zasadzie, jak to możliwe, wszystkie te teksty, jak nikt jeden konkretny nie odpowiada, to kto odpowiada i tak dalej. Tak więc na pewno jest to model, który jest sporym wyzwaniem, żeby po prostu mentalnie i kulturowo do niego w organizacji dotrzeć. 

Kuba: I zanim przejdziemy do drugiej części nagrania, przypominam, że jeżeli chcesz pogłębić wiedzę, jeszcze bardziej niż robimy to w podcaście, to znajdziesz nasze płatne produkty na stronie porzadnyagile.pl/sklep

Jacek: Powiedzieliśmy, jakie są naszym zdaniem modele, oczywiście to jest nasza definicja, nasza oś, pewnie mogłabyś/mógłbyś stworzyć taki model, taką ośkę po swojej stronie. Natomiast teraz skupimy się na tym, jak w praktyce podejść do zmiany właścicielstwa produktowego. Co byś, Kuba, radził?

Kuba: Pierwsza porada jest dosyć prosta. Zdefiniuj sobie, gdzie w ogóle jesteś. I chodzi o to, żeby na narysowanej przez nas osi, albo swoje własnej, jeśli czujesz, że masz lepsze podejście lub pożyczone od jeszcze kogoś innego mądrzejszego od nas, zobacz, gdzie jesteś. Umiejsców swoją organizację, ale może też wyjść poza swoją własną intuicję i odczucie, ale też zbierz feedback. Zapytaj zespoły, zapytaj interesariuszy biznesowych, zapytaj managerów, żeby sobie wyrobić zdanie, bo jedno z gorszych zjawisk, jakie może być, to jest przesuwanie się między punktem 5 a 6 w swoich oczach, gdzie tak naprawdę w organizacji jesteś raptem na punkcie 2. i te modele niestety, wymagają swojej oddzielnej taktyki do zmiany i też z tego powodu lepiej wiedzieć, co w ogóle naprawiasz i gdzie w tej chwili jesteś. To ma też o tyle istotne znaczenie, że zwłaszcza w większej organizacji może się tak zdarzyć, że firma w różnych częściach jest na różnych etapach dojrzałości. I sam tego jestem często świadkiem. Jedna sprawa to to, że zawsze się znajdą takie trochę bardziej zespoły, trochę bardziej progresywne, może z trochę lepszym klimatem, może się dobór osobowy też zrobił jakiś taki w miarę szczęśliwy, że po prostu mogą i robią trochę więcej. Ale też mogą być organizacje, które mają więcej linii biznesowych, mają na przykład trochę różne rynki, które obsługują i to wszystko może rzutować na to, że ta dojrzałość produktowa może być różnorodna i to tym bardziej wtedy jeszcze jest wyższa szkoła jazdy, żeby sobie zdefiniować, jaką ona w zasadzie jest, żeby czasami nie aplikować na przykład wytycznej, użyjmy tego przykładu ostatniego, że od teraz wszyscy tworzymy zespoły produktowe, a gdzieś tam w firmie może się okazać, że oni tam nawet nie mają właścicielstwa i nigdy do tej pory nie mieli, więc w ogóle rozmawiamy jakieś bajki o smokach i nie jesteśmy w stanie tego przeprowadzić.

Kuba: I zanim przejdziemy do drugiej części nagrania, przypominam, że jeżeli chcesz pogłębić wiedzę, jeszcze bardziej niż robimy to w podcaście, to znajdziesz nasze płatne produkty na stronie porzadnyagile.pl/sklep

Jacek: Powiedzieliśmy, jakie są naszym zdaniem modele, oczywiście to jest nasza definicja, nasza oś, pewnie mogłabyś/mógłbyś stworzyć taki model, taką ośkę po swojej stronie. Natomiast teraz skupimy się na tym, jak w praktyce podejść do zmiany właścicielstwa produktowego. Co byś, Kuba, radził?

Kuba: Pierwsza porada jest dosyć prosta. Zdefiniuj sobie, gdzie w ogóle jesteś. I chodzi o to, żeby na narysowanej przez nas osi, albo swoje własnej, jeśli czujesz, że masz lepsze podejście lub pożyczone od jeszcze kogoś innego mądrzejszego od nas, zobacz, gdzie jesteś. Umiejsców swoją organizację, ale może też wyjść poza swoją własną intuicję i odczucie, ale też zbierz feedback. Zapytaj zespoły, zapytaj interesariuszy biznesowych, zapytaj managerów, żeby sobie wyrobić zdanie, bo jedno z gorszych zjawisk, jakie może być, to jest przesuwanie się między punktem 5 a 6 w swoich oczach, gdzie tak naprawdę w organizacji jesteś raptem na punkcie 2. i te modele niestety, wymagają swojej oddzielnej taktyki do zmiany i też z tego powodu lepiej wiedzieć, co w ogóle naprawiasz i gdzie w tej chwili jesteś. To ma też o tyle istotne znaczenie, że zwłaszcza w większej organizacji może się tak zdarzyć, że firma w różnych częściach jest na różnych etapach dojrzałości. I sam tego jestem często świadkiem. Jedna sprawa to to, że zawsze się znajdą takie trochę bardziej zespoły, trochę bardziej progresywne, może z trochę lepszym klimatem, może się dobór osobowy też zrobił jakiś taki w miarę szczęśliwy, że po prostu mogą i robią trochę więcej. Ale też mogą być organizacje, które mają więcej linii biznesowych, mają na przykład trochę różne rynki, które obsługują i to wszystko może rzutować na to, że ta dojrzałość produktowa może być różnorodna i to tym bardziej wtedy jeszcze jest wyższa szkoła jazdy, żeby sobie zdefiniować, jaką ona w zasadzie jest, żeby czasami nie aplikować na przykład wytycznej, użyjmy tego przykładu ostatniego, że od teraz wszyscy tworzymy zespoły produktowe, a gdzieś tam w firmie może się okazać, że oni tam nawet nie mają właścicielstwa i nigdy do tej pory nie mieli, więc w ogóle rozmawiamy jakieś bajki o smokach i nie jesteśmy w stanie tego przeprowadzić.

Jacek: I w praktyce może to oznaczać, że zmiany, które będziesz przeprowadzać czy przeprowadzała, to nie będzie taka zmiana globalna dotycząca całej organizacji, może być tak, że tylko pewien wybrany wycinek struktury, jakiś konkretny obszar, jakiś konkretny value stream, jakkolwiek to jest nazwane w Twojej firmie, to będzie ten obszar Twojego zainteresowania i zmiana będzie prowadzona w trochę mniejszej skali, niż można byłoby mieć tak pierwotnie apetyt.

Jacek: Druga porada, ustal, jakich rezultatów oczekujesz po zmianie. Mamy tutaj na myśli taki stan, w którym postaramy się nazwać spodziewane efekty. Konkretnie im bardziej jesteśmy w stanie to zrobić na namacalnych miernikach, tym lepiej. Jednak też z drugiej strony warto pamiętać, że są też takie trochę mniej mierzalne aspekty, które również mogą mieć znaczenie, czyli przykładowo coś, co jest bardzo mierzalne, to może być jakaś odmiana lead time’u czy cycle time’u, czyli upraszczając bardzo mocno, jak długo czekamy od pomysłu do realizacji, czy jak szybko od podjęcia pracy jest ona realizowana. I to jesteśmy w stanie bardzo łatwo zmierzyć. Ale takie bardziej niemierzalne aspekty, mniej liczbowe, no to mogą być jakieś takie odczucia, na przykład zespołów, czy czują, albo w jakim stopniu czują, że ich praca ma sens, to mogą być też z drugiej strony reakcja czy ocena taka ze strony biznesowej, na ile ich potrzeby są realizowane, to może być bardziej takie opisowe, może bez jakiejś konkretnej cyferki w tle, ale nadal mogą to być bardzo istotne aspekty, na które warto zwrócić uwagę i wziąć je w ogóle pod uwagę, zanim zaczniemy przeprowadzać zmianę.

Kuba: Istnieją organizacje bardzo dobrze pomierzone, w których po prostu trzeba wybrać, który spośród mierników będzie tym, który obserwujemy, jaki mamy poziom aspiracji, czy co jest naszą ambicją, żeby było po pewnej zmianie. W innych organizacjach aż tak różowo nie jest, jeśli chodzi o tę sferę mierzenia. No i być może w ramach zmiany sposobu umiejscowienia właścicielstwa produktowego, czyli całego funkcjonowania zespołów produktowych, trzeba również uruchomić nowe pomiary, zrobić jakiś pomiar bazowy, do którego będziemy się porównywać, na przykład, jaki jest obecny poziom satysfakcji ze współpracy w zespołach, no i powtórzyć to po jakimś czasie już po zmianie, jak się zmiana ustabilizuje, jak wtedy zespół oceni, na przykład w jakiejś ankiecie satysfakcji, współpracy czy inne kwestie, które Jacek już też po kolei wymieniał. Czyli żeby później powiedzieć, czy jest lepiej, musisz przewidzieć, co w ogóle chcesz mierzyć i chcesz sobie przygotować odpowiednie pomiary, jeśli firma lub Twoja część struktury na razie tego nie ma.

Kuba: Trzecia porada jest dosyć przewrotna. Określ argumenty przemawiające za utrzymaniem obecnego stanu rzeczy. To jest taka trochę trikowa kwestia, żeby się zastanowić, co takiego może być argumentem za oporem przed zmianą. Będzie opór. Takie zmiany są bardzo trudne. One są najczęściej strukturalne, zwłaszcza jeśli mówimy o tym magicznym przeskoczeniu przez środek, że na przykład właścicielstwo produktowe przechodzi do strony biznesowej, to z automatu możemy mówić o całej puli problemów. Kilka wymienimy. I dobrze jest wiedzieć, dobrze jest sobie przewidzieć, dobrze jest sobie wyczuć, co to w ogóle mogłoby być, nazwać sobie te powody, żeby też ewentualnie w ramach zarówno komunikacji takiej racjonalnej, jak i też przygotowania pewnych mechanizmów przewidzieć, co może stawiać opór, kto może widzieć jakieś problemy, no i się odpowiednio zaplanować pod kątem właśnie przewalczenia tego oporu, powiedzmy wysunięcia kontrargumentów czy podkręcenia narracji w stronę korzyści, które przykryją problem z tym oporem. Żeby każdy widział interes w tej zmianie i każdy poczuł, że jest w tym coś dla mnie.

Kuba: Jakie to mogą być argumenty przemawiające za tym, żeby się nie zmieniać?

Jacek: Podzielimy się czterema takimi popularnymi, to nie jest zamknięta lista. Pierwsze, biznes nie rozumie IT. To może być taki argument, który usłyszymy, argument, który ma utrzymać aktualny podział, na zasadzie my róbmy biznes, wyróbcie IT i tam sobie za bardzo w drogę nie wchodźmy. Co możesz tutaj zrobić? Warto zainwestować w to, żeby to zrozumienie po obu stronach rosło. Moim zdaniem osoby rozwijające produkty w firmach technologicznych muszą rozumieć technologię. Nie muszą być ekspertami, nie muszą umieć programować itd., ale muszą rozumieć, co się do nich mówi. Muszą rozumieć, jakie są konsekwencje pewnych wyborów technologicznych. I w drugą stronę, czyli osoby odpowiedzialne za technologię muszą rozumieć kontekst biznesowy. Takie osoby są na rynku. Takie osoby można też rozwijać w ramach organizacji. Być może też rozwiązaniem jest zapewnienie odpowiedniego wsparcia na zasadzie, czy od strony technologii to jest jakiś architekt, czy Tech lead. Ktoś, kto będzie wsparciem i supportem dla takiej osoby biznesowej, po to, żeby ona stopniowo coraz lepiej rozumiała całą tę otoczkę technologiczną.

Kuba: I coraz lepiej rozumiała to mój kontrargument, bo pojawia się też pewna odmiana tego, co ja sobie wymienił, że biznes i IT się nie rozumieją, nie mówią odpowiednim językiem, więc musi być ktoś pomiędzy, kto będzie to tłumaczył. To zwłaszcza takie modele, w których ten Product Owner jest taki jakby wyspecjalizowany, ale jednak pozostaje po stronie technologii, mogą być bronione właśnie pod tym kątem, że mamy takich fajnych Product Ownerów, którzy rozumieją zarówno biznes, jak i rozumieją stronę technologiczną i tak powinno pozostać. Nie zmieniajmy tego, bo ci biznesowcy to się zrażą, albo zespoły się obrażą, bo biznesowiec mówi jakimś dziwnym innym językiem. To jest taki argument dla mnie do zbicia, ale rozumiem, dlaczego on się pojawia. Tutaj cała sfera związana ze zbliżeniem biznesu i IT odcinka wspomnianego 130. Właśnie jest też o tym, zintegrujmy te zespoły, zróbmy sobie wspólny słownik, zawiążmy też kontrakt, dajmy sobie sposób dla zespołu, oczekujemy, że zespół sam sobie to znajdzie oczywiście. Umieją się dogadać, umieją sobie zadać pytanie, umieją się zatrzymać, umieją poprosić o parafrazę i tego typu rozwiązania. Czyli fakt, że dzisiaj się nie dogadują, fakt, że dzisiaj może nie mają wspólnego słownika, jest tylko pewną przestrogą, ok, ta zmiana, zbliżenie się, na przykład przesunięcie właścicielstwa w stronie biznesu może wiązać się z takim okresem przejściowym, będzie trochę trudniej, będzie trochę niedoskonale, być może będą odrobinę tarcia, czy nawet takie dosyć śmieszne niedogadania się. No bo, po prostu to samo słowo znaczyło dla dwóch stron, układamy trochę co innego i z tego powodu cały kawałek prac poszedł nie w tę stronę, co trzeba.

Jacek: Trzeci taki argument, który można usłyszeć, biznes nie ma czasu. Nie zawracajcie nam głowy, jesteśmy zajęci, róbcie te swoje rzeczy, to co potrzebujecie wam dane, ale nie ma szans, że się zaangażujemy mocniej. Moim zdaniem to jest spore ograniczenie. Pracowałem w jednej z firm, gdzie wyraźnym sygnałem od szefa, od prezesa było coś w stylu zmieniajcie się, transformujmy się, ale nie ma opcji, że osoby z biznesu będą pracować z zespołami, nie mają na to czasu. I to była taka wyraźna linia odcięcia, co spowodowało, że w rolę Product Ownerów, takich biznesowych, weszli Project Managerowie. No i jakby słuchając całego tego odcinka, zapewne domyślasz się, że było to jakieś rozwiązanie, pewnie lepsze niż brak zupełny właścicielstwa, no ale niestety zespoły cierpiały i brakowało tego prawdziwego kontekstu biznesowego. Trochę bardziej było to przekazywanie pewnych wymagań do zespołu, które mają zostać zrealizowane.

Kuba: Czwarty pojawiający się często powód, który wymienimy, to taki argument, tylko technologiczny Product Owner zapewni, że sprawy technologiczne będą równie ważne i zaopiekowane. Trochę już to sygnalizowaliśmy wcześniej i ten argument w wybranych organizacjach się pojawia. W jednej z nich to czułem takie dosyć ciężkie dyskusje, że no nie, biznes w pierwszej chwili, jak tylko opisze mnie odpowiedzialność za priorytety, wywali natychmiast te wszystkie migracje, te wszystkie automatyzacje, te wszystkie usuwania długu. Zamknie nam te wszystkie ważne dla nas rzeczy technologiczne, zaczną napierać, żebyśmy robili to byle jak i tego typu argumenty. No i jakby nie neguję takiej obawy. Natomiast ja myślę tutaj o rozwiązaniu takim wyprzedzającym, które powinno to zabezpieczyć. Ważne, żeby zwłaszcza liderzy organizacji, w każdym z tych pionów, więc liderzy technologiczni, liderzy biznesowi, bardzo twardo ustawili sobie jakąś umowę na temat tego, jak zaopiekowane będą rzeczy technologiczne, jeśli priorytety nadaje strona biznesowa. W idealnym świecie to Jacek już wspominał, siłą rzeczy ci właściciele biznesowi zostaną zaznajomieni z tą technologią. Jeśli dać im dobre wsparcie, to w długim okresie będą rozumieli, że dług technologiczny trzeba usuwać, że rzeczy technologiczne wymyślone przez zespół są ważne. No, ale jeśli taka nadzieja to za mało, no to wszedłbym w jakieś twarde umowy. W jednej z organizacji po prostu zostało to zadekretowane, przyjęte jako pewna umowa obowiązująca, jako taka twarda reguła, że 20% przepustowości zespołu idzie na rzeczy technologiczne i tutaj, no jakby Product Owner z biznesu nie może tego zanegować, co najwyżej może wpływać na priorytety wewnątrz tego strumienia prac. Nie każdej organizacji je sugeruje, żeby ustawić sobie aż taką sztywną regułę, ale to może być jeden z kierunków, czyli takie pomyślenie o tym, że mamy pewną umowę na temat tego, jakie prace w ogóle w zespole są prowadzone, a druga rzecz, która też może być super istotna, to zadbanie o to, żeby było bardzo klarowne i bardzo jakby respektowane przez całą organizację Definition of Done. Umowa na temat tego, jaki standard jakości jest absolutnie nie do obniżenia, żeby nie było tej presji biznesowej na to, że no to teraz weźcie, przyspieszcie, robicie to byle jak, a później się poprawi i się nigdy nie poprawia. Więc jest kilka rozwiązań, jest kilka praktyk na to, żeby zapewnić czy wyprzedzić tę obawę, że jak technologiczny Product Owner nie zadba, to już nikt nie zadba. Warto się tym dogadać.

Jacek: To, co Kuba powiedział, to był taki czwarty, ostatni powód, który chcieliśmy wymienić w ramach określania, zachęcenia do tego, żeby określić argumenty przemawiające za utrzymaniem obecnego stanu rzeczy. Natomiast zapewne w Twojej firmie mogą to być albo inne powody, albo tych powodów może być więcej. Nie wyczerpiemy tutaj wszystkich wątków. Zdecydowanie rekomendujemy, żebyś zastanowił się, zastanowiła się no i po prostu podjął czy podjęła decyzję na temat tego, jakie to są argumenty samodzielnie.

Kuba: No to czas czwartą poradę, jak można zmienić właścicielstwo produktowe, jak zmienić umiejscowienie właścicielstwa w organizacji. Porada brzm,i narysuj mapę sojuszników i przeciwników zmiany. Zdefiniuj sobie, kto przewidujesz, że będzie wspierał zmianę, kto będzie być może bardzo neutralny i ani nie wesprze, ale też na szczęście nie będzie przeciwnikiem. Takie zmiany, zwłaszcza trudne, zwłaszcza z przesuwaniem odpowiedzialności w ramach struktur, mogą mieć też swoich przeciwników ze swoimi argumentami, o których wymieniliśmy kilka chwil temu. Narysuj to zrozum, zobacz jak to wygląda, zastanów się też, jakie są zależności i na tej bazie spróbuj sobie zaplanować pracę taką właśnie polityczną, dyplomatyczną ze zbudowaniem kręgu sojuszników, którzy będą wspierać tę zmianę i wpływać na te osoby, które są niechętne. Jak mówię, narysuj mapę, mam dosłownie na myśli narysowanie sobie mapy, tutaj może się przydać taka technika, która nazywa się Stakeholder bottle mapping. Jest ona do znalezienia między innymi na YouTube, podlinkujemy filmik na ten temat autorstwa Geoffa Wattsa w notatkach do tego odcinka. Proste narzędzie, wykorzystałem je kilka razy, najczęściej fajnym efektem tego ćwiczenia było wow, nie zdawaliśmy sobie sprawy, jaka to jest plątanina zależności, ale też jednym z obiecujących elementów jest to, że nawet ci, którzy są przeciwni naszej zmianie, mają kogoś, kto na nich wpływa. To może być przełożony wyższego szczebla, to jest prosty przypadek, ale to też mogą być osoby, które np. dany przeciwnik uważa za istotne w podejmowaniu decyzji osoby, których opinia jest dla tej osoby ważna. Może się okazać, że tak pośrednio jesteśmy w stanie znaleźć sposób na wpłynięcie na te osoby niechętne i zaplanowanie takiej naprawdę cwanej, dyplomatycznej, sprytnej akcji, żeby przekonać nieprzekonanych, żeby podjąć wspólnie pewną decyzję i faktycznie odważyć się na konkretne kroki.

Jacek: Przedostatnia porada, myśl o strukturze jako żyjącym bycie, a nie w finalnym ustawieniu. Nie spodziewałbym się, że jakakolwiek zmiana modelu czy przesuwanie się po tej osi, o której z Kubu mówiliśmy, że to jest coś, co się wykonuje raz i koniec, raczej bądź gotów i gotowa na to, że te modele będą się zmieniać. Myślę, że apetyt może rosnąć. Przynajmniej raczej w tę stronę widzę, że organizacje się przesuwają. Więc moim zdaniem nie ma co zbytnio przywiązywać się do aktualnego stanu czy do tego nowego stanu, który właśnie się w organizacji pojawił, bo najlepsze organizacje, które widziałem, raczej iterują na temat tego, jak ustawiona jest struktura pod kątem wytwarzania produktów i raczej zbyt długo nie są w stanie usiedzieć w tym modelu, w którym aktualnie się znajdują. No bo bardzo szybko na skutek refleksji pojawiają się pomysły usprawnieniowe, co można usprawnić, co można zrobić lepiej, żeby praca była bardziej efektywna, żeby dostarczać szybciej więcej wartościowych rzeczy.

Kuba: I fakt, że struktura produktowa żyje, to nie jest błąd, tylko to jest część planu. Zmienia się otoczenie rynkowe, być może strategia organizacji się też trochę zmienia, karząc pewnym produktom być większym, albo przesunąć się na jakieś inne pole, to wszystko są bardzo racjonalne argumenty za tym, żeby ciągle to poprawiać, ciągle to zmieniać i ewentualnie nawet cofać, bo to też może mieć miejsce. A z drugiej strony, oprócz tego, co Jacek powiedział, jest też tak, że takie zmiany są strasznie podatne na moment, czyli taką regułę najlepszy moment jest teraz, zróbmy tę zmianę, bo się otworzyło jakieś okienko, ktoś zarządzający właśnie nowy przyszedł, albo jest jakaś niedoskonałość procesowa i możemy się wstrzelić w okazję. Więc tutaj zarządzający mogą mieć fajne plany, mogą być gotowi, mogą to gdzieś może rozłożyć mocno w czasie i tydzień później będzie jakieś spotkanie, na którym trzeba szybko zareagować i wskoczyć do odpowiedniego pociągu ze zmianą, albo wyczuć, że teraz trzeba te zmiany zapauzować, bo to nie jest po prostu czas na to. Więc tutaj zachęcamy do takiej elastyczności w podejściu. Najlepiej byłoby mieć wizję stanu docelowego i pewne przemyślenie na temat paru kroków w przód, ale nie przywiązywać się zwłaszcza do dat w tym planie, bo zarówno może nastąpić poważne przyspieszenie, jak i też zapauzowanie pewnych marzeń do lepszych okoliczności.

Kuba: I ostatnia porada z trochę innego poziomu abstrakcji, tak podsumowująca również wszystko to, co powiedzieliśmy. Przyjmij, że lepsze jakiekolwiek właścicielstwo niż jego brak. O ile widzimy plusy i minusy różnych modeli i różnego umiejscowienia organizacji na osi, którą zarysowaliśmy w pierwszej części, tak zdecydowanie zgadzamy się, że przejście z modelu brak właścicielstwa na jakiekolwiek, na jakie stać organizacje, nawet jeśli to jest ten model super niedoskonały, związany z zarządzaniem Backlogu, zleceń po stronie IT, to i tak jest lepsze niż nic. Więc tutaj mocno zachęcamy do tego, że zwłaszcza jeśli słuchasz nas i czujesz, że jesteś w tej okolicy albo część, chociaż Twojej struktury jest w okolicy i z tego samego braku właścicielstwa produktowego to naprawdę rozważ, co cię stopuje i spróbuj pokonać tę barierę, żeby choć minimalne właścicielstwo powołać w ramach swojej struktury technologicznej albo oczekiwać, że Twoja struktura IT, jeśli jesteś po tej stronie biznesowej, że chociaż takie właścicielstwo powoła, najlepsze na jakie stać organizacje na ten moment.

Jacek: Podsumowując. Jak w praktyce podejść do zmiany właścicielstwa produktowego? Zdefiniuj sobie, gdzie w ogóle jesteś. Ustal, jakich rezultatów oczekujesz po zmianie. Określ argumenty przemawiające za utrzymaniem obecnego stanu rzeczy.

Kuba: Narysuj mapę sojuszników i przeciwników zmiany. Myśl o strukturze jak o żyjącym bycie, a nie finalnym ustawieniu. Przyjmij, że lepsze jest jakiekolwiek właścicielstwo niż jego brak.

Jacek: Być może po przesłuchaniu tego odcinka czujesz, że potrzebujesz pomocy we wdrożeniu takich zmian u siebie. Wspieramy z Kubą liderów technologicznych w skutecznych transformacjach konkretnie i praktycznie. Pomagamy dostosować modele do specyfiki Twojej organizacji i działamy razem z Tobą. Porozmawiamy. Napisz na adres kontakt@porzadnygagile.pl

Kuba: Notatki do tego odcinka, artykuł, transkrypcje, wspomniany link do Stakeholder mapingu, zapis wideo znajdziesz na stronie porzadnyagile.pl/133

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

Kuba: Dzięki Jacek.

Jacek: I do usłyszenia wkrótce.