Jak radzić sobie z wieloma produktami w jednym zespole?

Porządny Agile

Praca nad wieloma produktami jednocześnie w jednym zespole może być wyzwaniem. Jak sobie z tym poradzić? Jednym ze sposobów jest skoncentrowanie całej organizacji na priorytetach i ograniczenie liczby otwartych tematów. Pozostałe praktyczne wskazówki, które pomogą Twojemu zespołowi lepiej organizować pracę i zwiększać wydajność, znajdziesz w tym nagraniu.

Porządny Agile · Jak radzić sobie z wieloma produktami w jednym zespole?

Spis treści

• Skup całą organizację na priorytetach i zredukuj liczbę otwartych tematów
• Zmniejsz liczbę tematów przekazywanych do zespołów jednocześnie
• Zreorganizuj zakres odpowiedzialności zespołów, aby obejmowały jeden konkretny produkt
• Realizuj inicjatywy produktowe w sposób sekwencyjny
• Wyodrębniaj esencję z tego, co jest do zrobienia
• Twórz dynamiczne podzespoły, skupione na wybranych obszarach
• Rozwijaj bardziej uniwersalny profil kompetencyjny członka zespołu
• Transkrypcja podcastu „Jak radzić sobie z wieloma produktami w jednym zespole?„

Skup całą organizację na priorytetach i zredukuj liczbę otwartych tematów

Zaczynając od pierwszej rekomendacji, skup całą organizację na priorytetach i zredukuj listę otwartych tematów. To fundamentalne zagadnienie, dlatego rekomendujemy rozpoczęcie od najwyższego szczebla. Działania na niższych poziomach, takich jak zespoły, mogą nie być tak skuteczne, jeśli nie rozwiążemy problemu u źródła. Tym źródłem jest strategia organizacji i jasna wizja tego, co ma być realizowane oraz dlaczego wybraliśmy konkretne inicjatywy. Redukcja liczby otwartych tematów na najwyższym poziomie to najbardziej systemowy i sensowny krok, jeśli chcesz ograniczyć liczbę inicjatyw w zespołach.

Mamy przykład z naszego doświadczenia zawodowego, kiedy mieliśmy przyjemność uczestniczyć w warsztatach strategicznych, gdzie wraz z całym zarządem analizowaliśmy strategię naszego produktu i porównywaliśmy ją z kluczowymi konkurentami, wobec których chcieliśmy się pozycjonować. Wsparci przez doświadczonych mentorów, zrozumieliśmy, że zarządzanie strategiczne polega na podejmowaniu kluczowych decyzji dotyczących tego, co będzie naszą przewagą konkurencyjną, z pełną świadomością rzeczy, które będą słabsze z naszej strony.

Dzięki tym warsztatom i świadomej, wspólnej decyzji o tym, na czym się skupiamy i co będzie cenione przez rynek oraz klientów, stworzyliśmy solidny fundament. Na jego podstawie mogliśmy wyznaczyć konkretne inicjatywy produktowe i określić, na czym poszczególne zespoły powinny się skupić.

W tej samej organizacji, zanim doszło do tej strategicznej rozmowy, przez kilka lat realizowano dość przypadkowe projekty. Przynosiły one wartość biznesową, generowały zyski i były sensowne z rynkowego punktu widzenia, ale pochodziły z bardzo różnych kategorii. W efekcie generowały dużą różnorodność wątków podejmowanych przez zespoły.

Ustalenie strategicznych priorytetów i wybór kluczowego aspektu, na którym skupia się cała organizacja, pozwoliły łatwo wyznaczyć priorytety dla poszczególnych zespołów.

Zmniejsz liczbę tematów przekazywanych do zespołów jednocześnie

Jeśli nie udało się osiągnąć zgody, o której wspominaliśmy w powyższej historii, i wciąż istnieje szeroka lista tematów oraz inicjatyw do realizacji przez zespoły, proponujemy ograniczenie liczby tematów przekazywanych jednocześnie. Chodzi o świadomość na poziomie najwyższego kierownictwa, że przekazywanie wielu tematów naraz niekoniecznie poprawi efektywność pracy, a w szczególności nie sprawi, że tematy zostaną dostarczone wcześniej.

Sensownym punktem wyjścia może być umowa, że jeden zespół otrzymuje jeden konkretny cel na raz. Ten cel nie musi oznaczać pojedynczego elementu w produkcie; może obejmować wiele zadań do zrealizowania w ramach konkretnego produktu. Jednak wciąż poruszamy się w wyselekcjonowanym, konkretnym obszarze.

Narzędziowo najczęściej przekłada się to na roadmapę skupioną na celach, gdzie cele są realizowane sekwencyjnie. Nawet jeśli organizacja nie ma w pełni przemyślanej strategii lub nie jest ona wystarczająco wyrazista, warto, aby zarządzający produktem, kluczowi sponsorzy czy menedżerowie większych obszarów skupili uwagę zespołu na jednym celu w danym momencie. Gdy ten cel zostanie zrealizowany w satysfakcjonujący sposób, można przejść do kolejnego.

Nawet jeśli cele są ze sobą luźno powiązane, ważne jest, aby zespół mógł pracować nad nimi w bardziej skoncentrowany sposób. W praktyce oznacza to stworzenie roadmapy skupionej na celach, co podkreślamy jako coś innego niż roadmapa z planowanymi funkcjami czy cechami produktu lub planem realizacji prac. Roadmapy często kojarzą się z datami, ale w tym przypadku wyobrażam sobie roadmapę przypominającą drzewko rozwoju technologii w Cywilizacji, gdzie najpierw skupiamy się na rozwoju metalurgii, a potem zmieniamy sposób zbierania owoców. Tę analogię można przenieść na Twój produkt.

Zreorganizuj zakres odpowiedzialności zespołów, aby obejmowały jeden konkretny produkt

Trzecia porada dotycząca radzenia sobie z wieloma produktami to zreorganizowanie zakresu odpowiedzialności zespołów, aby każdy obejmował jeden konkretny produkt. Zakładamy tutaj, że mnogość jednocześnie realizowanych zadań wynika z nieoptymalnie ustalonych granic odpowiedzialności zespołu. Może warto ponownie przedyskutować, czy zespół nie obejmuje zbyt dużego obszaru lub nie jest przypisany do niego w niefortunny sposób, co skutkuje koniecznością jednoczesnej realizacji kilku tematów. W efekcie w tym konkretnym zespole pojawia się więcej niż jeden priorytet, który dodatkowo jest pilny, przez co nasze dwie poprzednie porady nie mogą zostać zastosowane. Jak to może wyglądać w praktyce?

Pomagaliśmy pewnej organizacji w usprawnieniu funkcjonowania zespołów, aby osiągnąć lepsze wyniki biznesowe. Zespoły te były zorganizowane wokół technologii, co powodowało, że nawet drobna, czysto biznesowa zmiana wymagała zaangażowania wielu zespołów, zanim użytkownicy mogli z niej skorzystać.

Management postanowił więc zreorganizować zespoły tak, aby nie były one skupione na konkretnej technologii, lecz na określonych obszarach biznesowych. Powstała konkretna tabela w Excelu, która proponowała, jakie to mogłyby być obszary biznesowe.

Równocześnie zespoły przygotowały listę tematów technologicznych, nad którymi pracują. Na tej podstawie rozpoczęła się wieloetapowa, trwająca kilka tygodni dyskusja na temat najlepszego sposobu przeorganizowania się. Celem było, aby zespoły mogły maksymalnie skoncentrować się na konkretnym produkcie, wykorzystując jednocześnie posiadaną wiedzę technologiczną i minimalizując zmiany w składzie zespołów.

Oczywiście nie było to w pełni możliwe, więc wprowadzona zmiana uwzględniała, że niektóre osoby musiały zmienić zespół. Pojawiły się też nowe odpowiedzialności technologiczne w zespołach, a niektóre dotychczasowe obowiązki zostały przekazane innym zespołom.

Z naszego doświadczenia udziału w kilku takich sytuacjach wynika, że nie ma gotowej odpowiedzi na to, jak podzielić zespoły. Nawet podział według kryteriów biznesowych to dość ogólne stwierdzenie. Doświadczenie podpowiada nam, że organizacje wypracowują odpowiedni dobór produktów iteracyjnie, najczęściej w trakcie dłuższych dyskusji, uwzględniając wiele czynników. Co ważne, prawdopodobnie za pierwszym razem nie uda się osiągnąć idealnego i trwałego efektu. Dlatego warto z góry założyć, że sposób podziału będzie doskonalony w przyszłości, a może organizacja przejdzie na tryb ciągłego, elastycznego reorganizowania zespołów, ponieważ produkt się zmienia, zmienia się cykl życia lub chcemy dostosować się do nowych rynków czy trendów.

Realizuj inicjatywy produktowe w sposób sekwencyjny

Zbliżamy się tutaj do bardziej realistycznego podejścia, może nawet nieco pesymistycznego. Załóżmy, że poprzednich zaleceń nie udało się wdrożyć lub nie przyniosły one pełnych oczekiwanych efektów. W takiej sytuacji nawet jeśli na poziomie strategii, zadań przekazywanych zespołom czy odpowiedniej struktury organizacyjnej panuje pewne zamieszanie, wciąż można wiele zrobić na poziomie osoby decydującej o priorytetach w zespole.

W niektórych zespołach taką osobą jest Product Owner, w innych Product Manager. Niezależnie od nazwy, jest to decydent, który może postanowić, że mimo mnogości zleceń, inicjatyw, pomysłów czy różnych celów, będą one realizowane w danym zespole w sposób sekwencyjny, czyli po kolei. Najpierw jedna rzecz — ta najważniejsza lub najpilniejsza — a dopiero potem kolejne. Dzięki temu ograniczamy wielozadaniowość, minimalizujemy przełączanie kontekstu i być może przyspieszamy realizację tego, co jest naprawdę istotne.

Ten przykład doskonale pokazuje, jak ważne jest, aby osoba na ww. wspomnianym stanowisku wykazała się odwagą, praktycznością oraz asertywnością w mówieniu „nie”. Konieczne będzie zatrzymanie pewnych inicjatyw, wyraźne wskazanie, co musi poczekać i co zostanie zrealizowane w dalszej kolejności, aby stworzyć przestrzeń na realizację tego, co w danym momencie jest najważniejsze.

Trudno jednoznacznie określić, co jest w danej chwili najważniejsze — może to być najbardziej obiecująca inicjatywa, pilne spłacenie długu technologicznego (na przykład z powodu utraty wsparcia dla używanej technologii) lub dostosowanie się do konkretnych, nieprzesuwalnych terminów. Na przykład musimy wprowadzić zmiany w produkcie ze względu na nadchodzące zmiany prawne i upewnić się, że nasz produkt spełnia nowe wymagania.

To podejście nie jest intuicyjne; wciąż pokutuje przekonanie, że jeśli robimy wiele rzeczy naraz, ukończymy je szybciej. Nie wiemy, skąd to się bierze. Literatura i praktyka są tu bezlitosne. Mantra „zacznij kończyć, przestań zaczynać” jest naszym zdaniem czymś, na czym warto się oprzeć.

Wyodrębniaj esencję z tego, co jest do zrobienia

Jedną z przyczyn, dla których zespoły mają trudności z realizacją wielu inicjatyw produktowych jednocześnie, może być fakt, że te inicjatywy są zbyt duże i trwają długo. Pod naporem priorytetów lub spraw, które nie mogą już czekać, pojawia się wielozadaniowość, która zaczyna być uciążliwa.

Zdolność do dzielenia zadań jest umiejętnością, której trzeba się nauczyć. Zespoły, które to potrafią, oraz osoby zarządzające priorytetami, umiejące określić, co w danym projekcie jest kluczowe, a co mniej istotne, są w stanie szybko dostarczać mniejsze fragmenty inicjatywy. Dzięki temu mogą podjąć decyzję, co zrobić z pozostałą częścią: czy ją wstrzymać i przystąpić do kolejnej inicjatywy, czy może całkowicie z niej zrezygnować, jeśli tak wskaże feedback z rynku. Czasem okazuje się, że po dostarczeniu pewnej części, reszta nie jest już tak bardzo potrzebna.

Klasycznym przykładem, który niezmiennie obserwujemy, jest przepisywanie systemu, zmiana platformy czy technologii, gdzie mamy już gotowy produkt z pewnymi funkcjami, z którego można korzystać, ale mimo to przepisujemy go od zera. Bardzo często takie przepisywanie odbywa się moduł po module, dosłownie jeden do jednego. Przechodzimy kolejno przez produkt i dopiero gdy wszystko zostanie przepisane, możemy powiedzieć: „OK, to jest zrobione.”

Zdecydowanie rekomendujemy krytyczne podejście do takiego przepisywania. Warto zastanowić się, co tak naprawdę jest esencją tego produktu i co jest najczęściej używane. Należy zaczerpnąć informacji zwrotnej od faktycznych użytkowników systemu i dopiero wtedy podjąć decyzję, co warto dostarczyć na wczesnym etapie. Przy okazji pojawi się refleksja, że nie wszystko dosłownie jeden do jednego, co znajduje się w obecnym produkcie, jest nam potrzebne w nowej wersji.Jeśli potrzebujesz wsparcia w dekompozycji produktu, zachęcamy do obejrzenia naszego webinaru, gdzie przedstawiamy 9 sposobów na podział produktu i omawiamy na przykładach, jak wdrożyć je w zespole produktowym. Materiał znajdziesz pod adresem porzadnyagile.pl/deko.

Twórz dynamiczne podzespoły, skupione na wybranych obszarach

Akceptujemy fakt, że tematów jest wiele, więc warto podejść do tego zwinnie i elastycznie. Możemy mądrze podzielić zespół, tak aby wybrane osoby, dysponujące konkretnymi kompetencjami, skupiły się na określonych obszarach. Zamiast sytuacji, w której wszyscy są zaangażowani we wszystko, co bywa przytłaczające, warto określić priorytety i przydzielić podzespoły lub grupy w ramach zespołu do konkretnych zadań. Dzięki temu członkowie zespołu będą pracować w bardziej komfortowych warunkach, skupiając się na wybranych, konkretnych obszarach.

Oczywiście to podejście zakłada, że zespół jest nieco większy, że jest kogo dzielić, że można na przykład podzielić go na pół, a zespół nadal zachowa zdolność dostarczania rozwiązań. Sami byliśmy świadkami kilku odmian realizacji tej praktyki i w skrócie najczęściej wygląda to tak: podczas planowania iteracji czy Sprintu albo planowania dłuższego okresu — na przykład kwartału czy czasu realizacji największej inicjatywy trwającej kilka tygodni — zespół w ramach samoorganizacji ustala, kto jest potrzebny do zrealizowania danego przedsięwzięcia. Ludzie tymczasowo przydzielają się do tej inicjatywy i na czas jej realizacji działają jako podgrupa w ramach zespołu, aż nie potrzebują wrócić do swojego pierwotnego zespołu, czy to po pomoc, czy dlatego, że zakończyli dane przedsięwzięcie w satysfakcjonujący sposób.

Mamy tu więc do czynienia z pewnego rodzaju podziałem. Ten podział jest tymczasowy, więc nie ma potrzeby dokonywania większych reorganizacji. Jest on również bardzo elastyczny; są zespoły, które częściowo go stosują, a częściowo nie. To oznaka dojrzałości zespołu, który potrafi się dostosować i być może przełamać zasadę, że absolutnie wszyscy robią wszystko równocześnie — wspólne wielkie Daily, wspólne wielkie planowania, wspólne wielkie warsztaty — co może przynosić niewielką wartość dodaną, a generować duże koszty. Jest to oczywiście kwestia dojrzałości zespołu, umiejętność, którą trzeba z zespołem wypracować, ale jest to jeden z ostatnich w naszym przypadku sposobów na poradzenie sobie z wieloma produktami realizowanymi jednocześnie.

Rozwijaj bardziej uniwersalny profil kompetencyjny członka zespołu

Zdarza się, że obecne kompetencje w zespole sugerują zrównoleglenie inicjatyw, ponieważ w jednej z nich brakuje pracy dla niektórych specjalistów. Prowadzi to do sytuacji, w której Product Owner, Product Manager lub inna osoba decydująca o zadaniach zespołu jest zmuszona uruchamiać kolejne wątki, aby zapewnić pracę wszystkim członkom. Czyli po prostu, żeby każda osoba miała zajęcie.

Przykładem ilustrującym tę sytuację jest historia z pewnego zespołu IT, z którym był owocny okres współpracy. Podczas planowania kolejnego etapu prac jedna z programistek zauważyła: „Ciągle robię API”. Wszyscy myśleli, że po prostu zgłasza się po kolejne zadanie, ale po chwili dodała: „Chciałabym robić coś innego”. Ten moment okazał się przełomowy dla zespołu. Zamiast przydzielać te same zadania tym samym osobom, postanowiono zamienić się rolami i podjąć inne wyzwania niż zazwyczaj.

W efekcie doszło do wartościowego miksu kompetencji i transferu wiedzy na różnych częściach systemu. Nowe osoby zaczęły pracować nad obszarami, które wcześniej były rozwijane przez jedną lub dwie osoby, co pozwoliło na refaktoryzację i świeże spojrzenie na projekt. Zespół stał się bardziej uniwersalny, co odciążyło Product Ownera od konieczności generowania pracy dla wysoko wyspecjalizowanych specjalistów. Teraz mógł skupić się na celach produktu, wiedząc, że zespół samodzielnie poukłada swoją pracę.

Oczywiście w krótkim okresie takie podejście może wiązać się z tym, że osoby mniej doświadczone w danym obszarze będą pracować trochę wolniej. Jednak w średnim okresie sytuacja zaczyna się wyrównywać, a w długim zespół zyskuje zdolność do podejmowania różnorodnych zadań. Dzięki temu może szybko realizować to, co jest w danym momencie najważniejsze dla produktu.

Jeśli nawet te ostatnie punkty, które sugerowaliśmy — będące już pewnym kompromisem lub wykorzystaniem dostępnych nam możliwości — nie wydają się realistyczne w twoim kontekście, obawiamy się, że możesz mieć inny, znacznie większy problem niż tylko radzenie sobie z wieloma inicjatywami produktowymi jednocześnie. Co mamy na myśli, pisząc takie enigmatyczne stwierdzenia?

W naszym materiale zawarliśmy wiele porad. Pierwsze z nich są strategiczne, systemowe i ogólnoorganizacyjne. Kolejne dotyczą podejmowania decyzji. Ostatnie skupiają się na tym, jak radzić sobie poprzez zorganizowanie się. Jeśli nie jesteś w stanie zapewnić, że zespół się organizuje, lub istnieją blokady uniemożliwiające to, obawiamy się, że zespół może nie mieć możliwości decydowania o swoim procesie pracy. Może też być tak, że osoby pełniące role liderskie w zespole nie są słuchane. Może się okazać, że brak usprawnień w tym aspekcie jest jedynie symptomem tego, jak niesamodzielne i nadmiernie kontrolowane managersko są zespoły czy zasoby, które bezpośrednio w tym zespole nie pracują. To tylko hipoteza, być może nietrafna, ale postanowiliśmy zostawić to pytanie i refleksję na koniec.

Jak radzić sobie z wieloma produktami w jednym zespole?

• Skup całą organizację na priorytetach i zredukuj liczbę otwartych tematów.
• Zmniejsz liczbę tematów przekazywanych do zespołów jednocześnie
• Zreorganizuj zakres odpowiedzialności zespołów, aby obejmowały jeden konkretny produkt.
• Realizuj inicjatywy produktowe w sposób sekwencyjny
• Wyodrębniaj esencję z tego, co jest do zrobienia
• Twórz dynamiczne podzespoły, skupione na wybranych obszarach
• Rozwijaj bardziej uniwersalny profil kompetencyjny członka zespołu

Ten artykuł to jedynie fragment tego, co oferujemy w naszych programach rozwojowych dla osób zarządzających produktami w zwinnych zespołach. Wspieramy rozwój kluczowych kompetencji: budowanie strategii, tworzenie Roadmap, dzielenie pracy na mniejsze zadania oraz efektywne planowanie pracy w zespole. Nasze podejście łączy praktyczne warsztaty, mentoring i superwizję realnych inicjatyw, aby maksymalnie wspierać uczestników w codziennej pracy. Jeśli potrzebujesz takiego wsparcia, skontaktuj się z nami przez stronę porzadnyagile.pl/kontakt.

Dodatkowe materiały

• Mamy zbyt wiele projektów, co robić?

Transkrypcja podcastu „Jak radzić sobie z wieloma produktami w jednym zespole?„

Kuba: Ostatnio z Jackiem mieliśmy okazję wziąć udział w dyskusji z pewnym Product Ownerem. Chciał się poradzić w temacie radzenia sobie z wieloma produktami rozwijanymi w jego zespole równocześnie. Wynikiem tej rozmowy była lista porad, którą postanowiliśmy zamienić na treść tego odcinka.

Jacek: Tematem odcinka jest „Jak radzić sobie z wieloma produktami w jednym zespole”. Będziemy starali się w tym odcinku być bardzo wyraziści i bardzo konkretnie rekomendować pewne kroki. Natomiast już nawet krok w stronę tych rekomendacji może dla Twojego kontekstu okazać się usprawnieniem.

Kuba: Jeśli pracujesz w projektach z typowym podejściem związanym z zarządzaniem projektami i inicjatywami projektowymi, możemy polecić inny materiał, więc ten, który właśnie się rozpoczyna. Nagraliśmy kiedyś odcinek „Mamy zbyt wiele projektów, co robić”. Do znalezienia pod adresem porzadnyagile.pl/67. Ten odcinek jest podobny do tego, co właśnie zaraz przedstawimy. Ale jednak w tamtym bardziej skupiamy się na perspektywie projektów i portfeli projektów. A ten konkretny odcinek, który właśnie się zaczyna, będzie skupiony wokół wątku rozwoju produktu.

Jacek: Ok. Czyli przechodząc do sedna odcinka. Jak radzić sobie z wieloma produktami? Pierwsza porada brzmi. Skup całą organizację na priorytetach i zredukuj liczbę otwartych tematów. Temat jest dosyć fundamentalny i jak słyszysz, rekomendujemy, żeby zacząć od samej góry. Wszystkie inne działania, które możesz realizować gdzieś niżej na poziomie zespołów, mogą nie być już tak skuteczne, jeżeli nie zaczniemy rozwiązywać problemu u źródła. A źródłem jest strategia organizacji, pewna wizja na to, co będzie realizowane i dlaczego właśnie konkretnie takie, a nie inne inicjatywy. Redukcja otwartych tematów na poziomie od samej góry jest naszym zdaniem takim najbardziej systemowym i sensownym punktem zaczepienia, jeśli chcesz ograniczyć liczbę inicjatyw w zespołach.

Kuba: I mam tutaj przykład z osobistego doświadczenia w miarę na początku swojej kariery zawodowej. Miałem bardzo dużą przyjemność wziąć udział w takich warsztatach strategicznych, gdzie całą organizacją, a w zasadzie to managementem całej organizacji zastanowiliśmy się nad tym, jaka jest strategia naszego produktu, jak wypada nasza strategia na tle najważniejszych konkurentów, względem których chcieliśmy się pozycjonować. No i mieliśmy w tym materiale też bardzo ważnych mentorów, którzy nam bardzo pomogli z jednym założeniem. Zarządzanie strategiczne wiąże się z podejmowaniem kluczowych decyzji na temat tego, co będzie naszą przewagą, co chcemy, żeby było naszą przewagą, ale też z pełną świadomością pewnych rzeczy, które będą słabsze z naszej strony. Czyli odwracając, będą przewagą konkurencji na naszym tle. No i tutaj zrealizowane warsztaty strategiczne i świadoma wspólna decyzja na temat tego, na czym się skupiamy, co będzie przewagą konkurencyjną, co jest naszym założeniem, co do tego, co będzie też cenione przez rynek, przez klientów, było pewnym fundamentem, z którego później dopiero wyciągaliśmy wątki typu konkretne inicjatywy produktowe, konkretne rzeczy, nad którymi kolejne zespoły produktowe mogły się skupić. W tej samej organizacji bez tej rozmowy o strategii wcześniej, przez parę lat, realizowane były rzeczy dość losowe, które przynosiły wartość biznesową, które zarabiały na siebie, które nawet były rozsądne rynkowo, ale one były naprawdę z bardzo różnych kategorii i w efekcie też generowały bardzo dużą różnorodność wątków podejmowanych przez wybrane zespoły. Dzięki ustaleniu strategicznych priorytetów, dzięki wybraniu tego kluczowego aspektu, na którym się cała organizacja skupia, z tego łatwo było później wywieźć też priorytety dla pojedynczych zespołów.

Jacek: I takiego podejścia byśmy życzyli każdej organizacji. Natomiast jeżeli nie jesteś w stanie czegoś takiego zrealizować, no to mamy listę kolejnych rekomendacji. Druga rekomendacja. Zmniejsz liczbę tematów przekazywanych do zespołów jednocześnie. Czyli wyobraźmy sobie, że nie ma takiej zgody, o której Kuba opowiedział w tej swojej historii, no i nadal jest dosyć szeroka lista tematów, inicjatyw, które mają być realizowane przez zespoły. To, co proponujemy w takim przypadku, to jest ograniczenie liczby tematów, które jednocześnie są przekazywane do zespołów, czyli taka świadomość na poziomie top managmentu, że przekazywanie wielu tematów naraz niekoniecznie poprawi efektywność pracy, a w szczególności nie sprawi, że te tematy będą dostarczone wcześniej. Propozycja, od której można zacząć, być może takim bardzo sensownym punktem startu, jest umówienie się, że jeden zespół otrzymuje jakiś jeden konkretny cel na raz. Ten cel nie musi oznaczać, że to jest jakiś jeden feature w produkcie, to może być sporo rzeczy, które jest do zrealizowania w ramach jakiegoś konkretnego produktu. Natomiast nadal poruszamy się w tym przypadku w jakimś konkretnym, wyselekcjonowanym obszarze.

Kuba: I narzędziowo to się najczęściej zamienia w pewną Road map skupioną na celach, przy czym te cele są realizowane w jakiś sposób szeregowy. Nawet jeśli niestety organizacja nie do końca ma przemyślaną strategię, albo ta strategia nie jest tak wyrazista, jak byśmy sobie tego życzyli, no to może chociaż niech zarządzający produktem, też osoby kluczowe, jacyś sponsorzy, jacyś też zarządzający większymi obszarami, niech chociaż skupią uwagę danego zespołu, czy skupią uwagę danego produktu na jednym celu w danym momencie, by zabrać się za kolejny cel, gdy tamten zostanie zrealizowany w satysfakcjonujący sposób. No i być może te cele ze sobą będą powiązane bardzo luźno, no ale chociaż na dany moment niech będą procesowane i polepszane przez zespół w jakiś taki bardziej skupiony sposób. W praktyce to oznacza Road mapę skupioną na celach, to bardzo mocno podkreślę i powtórzę, jako coś innego niż Road mapę, w której mamy planowane funkcje w produkcie, planowane cechy tego produktu, czy też coś innego niż jakiś taki plan realizacji, prac, bo Road mapy często się kojarzą raczej właśnie z datami. Wyobrażam sobie, że to jest Road mapa, która bardziej przypomina drzewko rozwoju technologii w Cywilizacji, gdzie najpierw skupimy się na rozwoju metalurgii, a potem zmienimy sposób, w jaki zbierane są owoce, no i to oczywiście da się taką tę analogię przenieść na wybrany twój produkt.

Kuba: Trzecia porada, jak radzić sobie z wieloma produktami, to zreorganizuj zakres odpowiedzialności zespołów, aby obejmowały jeden konkretny produkt. Założenie w tej poradzie jest takie, że być może wielość rzeczy, które jest realizowana jednocześnie, wynika z tego, że zespół ma nieoptymalnie ustawione granice tego, czym się zajmuje. Być może tu trzeba przedyskutować ponownie temat, czy czasami zespół nie obejmuje za dużego obszaru, albo obejmuje ten obszar w jakiś taki nieszczęśliwy sposób, że organizacja musi jednocześnie realizować kilka rzeczy i w tym konkretnym zespole się to ujawnia jako więcej niż jeden priorytet i to w dodatku priorytet, który nie może czekać. Czyli te dwie nasze poprzednie porady nie są możliwe do zastosowania. Jak to może w praktyce wyglądać, Jacek?

Jacek: Tu z kolei ja podzielę się historią. Pomagałem pewnej organizacji w usprawnieniu tego, jak funkcjonują zespoły, no celem osiągania lepszych efektów biznesowych. Zespoły te były skupione wokół technologii, co powodowało, że nawet drobna zmiana taka czysto biznesowa powodowała, że wiele zespołów było angażowanych w to, żeby to doprowadzić do stanu, kiedy użytkownicy mogą z jakiejś tam konkretnej zmiany w produkcie korzystać. To, na czym skupił się management, to była reorganizacja zespołów, tak, aby nie były one skupione na konkretnej technologii, tylko raczej, żeby były skupione na konkretnych obszarach biznesowych. Powstała tam bardzo konkretna tabelka, która w Excelu proponowała, jakie to mogłyby być obszary biznesowe. Jednocześnie zespoły przygotowały listę tematów technologicznych, którymi się zajmują, no i na tej podstawie uruchomiła się taka wielocyklowa, wielotygodniowa dyskusja na temat tego, w jaki sposób najlepiej się przeorganizować, żeby z jednej strony zespoły maksymalnie skupiały się na konkretnym produkcie, z drugiej strony, żeby wykorzystać już tę wiedzę technologiczną, którą mają, jednocześnie nie robiąc zbyt dużych zmian, jeśli chodzi o skład zespołu. Oczywiście nie było to do końca możliwe, więc zmiana uwzględniała to, że pewne osoby będą musiały zmienić zespół, jak również pojawiły się pewne nowe odpowiedzialności technologiczne w zespołach, a pewne odpowiedzialności z kolei były przekazywane do innych teamów.

Kuba: I z naszego doświadczenia udziału w kilku tego typu sytuacjach, no nie mamy gotowej odpowiedzi, jak się podzielić. Nawet ten podział biznesowy to i tak jest dosyć wysokopoziomowe stwierdzenie, ale coś, co nam podpowiada doświadczenie, to to, że organizacje ten dobór odpowiednich produktów wypracowują iteracyjnie. Najprawdopodobniej w dłuższych dyskusjach, uznając wiele czynników. No i co też ważne, prawdopodobnie za pierwszym razem nie uda się idealnie uzyskać takiego efektu stałego, więc tu z góry sobie załóżmy też to, że być może ten sposób podziału będzie doskonalony w przyszłości, a może w ogóle przejdzie organizacja na taki tryb ciągłego, lekkiego reorganizowania zespołów, bo zmienia się produkt, zmienia się jakiś cykl życia, czy może chcemy dopasować się do nowych rynków czy nowych trendów.

Kuba: Czwarta rada w tym odcinku to, realizuj inicjatywy produktowe w sposób sekwencyjny. Schodzimy tak coraz bardziej z realizmem w stronę może nawet pesymizmu. Czyli załóżmy, że te wybrane wcześniej rzeczy albo nie dało się zrealizować, albo nie dały jeszcze kompletu efektów, o których chodzi, więc może jest tak, że nawet jeśli jest swego rodzaju zamieszanie z poziomu strategii, z poziomu zadań zlecanych do zespołów, czy z poziomu odpowiednio poukładanej struktury, to nadal dużo da się zrobić na poziomie osoby, która decyduje o tym, co jest priorytetem w danym zespole. W niektórych zespołach ta osoba się nazwie Product Ownerem, w innych Product Managerem. W każdym razie jest jakiś decydent, który może zdecydować o tym, że niezależnie od tego, jaka jest mnogość zleceń, inicjatyw, pomysłów, czy nawet różnych celów, mogą one być w tym konkretnym jednym zespole realizowane w sposób sekwencyjny, czyli po kolei. Najpierw jedna rzecz, z jakiegoś powodu najważniejsza, może najpilniejsza, dopiero potem kolejna rzeczy, żeby ograniczyć wielozadaniowość, żeby ograniczyć przyłączanie kontekstu, być może też przyspieszyć realizację tego, co jest najważniejsze.

Jacek: I ten przykład pięknie pokazuje, jak ważne jest, żeby osoba, która znajduje się na stanowisku, o którym Kuba wspomniał, potrafiła wykazać się odwagą, potrafiła wykazać się praktywnością, ale też asertywnością w odmawianiu. Bo tak naprawdę będzie trzeba pewne inicjatywy zastopować, powiedzieć wyraźnie, co musi poczekać i co będzie tak naprawdę zrealizowane w dalszej kolejności, żeby stworzyć miejsce i przestrzeń na to, żeby zrealizować to, co w danym momencie jest najważniejsze. Trudno powiedzieć, co jest najważniejsze w danym momencie, bo to może być najbardziej obiecująca inicjatywa. Z drugiej strony to może być pilne spłacenie jakiegoś długu technologicznego, na przykład z tego powodu, że jakaś tam technologia, na której bazujemy traci wsparcie, a może to być też powiązane z jakąś konkretną, sztywną datą. Czyli na przykład musimy pewne rzeczy zmodyfikować w naszym produkcie ze względu na to, że od jakiegoś momentu w czasie na przykład zmieni się prawo no i tak naprawdę będziemy musieli być zgodni, jeśli chodzi o to, czy ten nasz produkt spełnia te wymagania prawne, czy niekoniecznie. Nie jest to intuicyjne podejście, mam wrażenie, że nadal pokutuje takie myślenie, że jak wiele rzeczy naraz robimy, to one będą szybciej. Nie wiem z czego to wynika. Literatura tutaj i praktyka jest bezlitosna. Mantra, zacznij kończyć, przestań zaczynać, z mojej perspektywy tutaj jest czymś, na czym warto się oprzeć.

Kuba: Ok, to przechodząc do następnej rekomendacji. Wyodrębniaj esencję z tego, co jest do zrobienia. Jedną z przyczyn, dla których zespoły borykają się z tym, że mają do realizacji wiele inicjatyw produktowych jednocześnie, może być to, że te inicjatywy są za duże, ciągną się długo i po prostu pod naporem priorytetów, czy takich rzeczy, jak Jacek powiedział, rzeczy, które po prostu już nie mogą czekać, zaczyna się ten multitasking i zaczyna on boleć. Zdolność do dzielenia jest czymś, czego się trzeba nauczyć, ale zespoły, które umieją to robić, również osoby zarządzające priorytetami, umiejące zdecydować na temat tego, co jest w tym czymś, co robimy, z tym ważną cząstką i tę trochę mniej ważną, one dzięki temu są w stanie uzyskać możliwość dostarczania mniejszych kawałków inicjatywy szybko. No i ewentualnej decyzji, co dalej jest z tą pozostałą częścią, albo zapauzowanie jej i przepuszczenie przodem kolejnej inicjatywy, albo w ogóle może zrezygnowanie z tego, jeśli tak pokaże feedback rynku, albo tak się okaże, że jak już mamy coś, jakąś cząstkę, to tej pozostałej części już tak bardzo nie potrzebujemy.

Jacek: No i tutaj takim klasykiem, który niezmiennie z Kubą obserwujemy, to jest przepisywanie systemu, zmiana jakiejś platformy, zmiana technologii, gdzie mamy pewien gotowy produkt, on posiada już jakieś funkcje, można z tego produktu korzystać, no ale przepisujemy go od zera. Bardzo często to przepisywanie, to jest takie przepisywanie moduł po module, dosłownie jeden do jednego, idziemy po kolei z tym naszym produktem i jak wszystko przepiszemy, no to tak naprawdę możemy powiedzieć, OK, to jest zrobione. Tutaj zdecydowanie byśmy rekomendowali, żeby podejść krytycznie do takiego przepisywania, zastanowić się, co tak naprawdę jest esencją tego produktu, co jest najczęściej używane. Zaczerpnąć trochę informacji zwrotnej od faktycznych użytkowników tego systemu no i dopiero wtedy podjąć decyzję, co tak naprawdę byłoby mądrze dostarczyć na wczesnym etapie, jak również refleksja, która na pewno się pojawi, że tak naprawdę nie wszystko dosłownie jeden do jeden, co znajduje się w tym produkcie jest nam potrzebne w tej naszej nowej wersji.

Kuba: Jeśli temat dekompozycji produktu to coś, czego potrzebujesz, sprawdź nasz webinar, gdzie podajemy 9 sposobów na dzielenie produktu i omawiamy na przykładach, jak to zrealizować w zespole produktowym. Sprawdź nasz materiał pod adresem porzadnyagile.pl/deko.

Jacek: Przechodzimy do przedostatniej rekomendacji na dzisiaj, czyli twórz dynamiczne podzespoły skupione na wybranych obszarach. Płyniemy coraz bardziej z nurtem, jak słyszysz w tej poradzie już, no tak właściwie zaakceptowaliśmy, że tych tematów jest sporo. No i to, co można zrobić, to podejść tak generalnie dosyć zwinnie i płynnie. Czyli zastanowić się, w jaki sposób możemy się mądrze podzielić w zespole, tak, żeby pewne wybrane osoby, zestaw też jakichś konkretnych kompetencji, był skupiony na wybranych obszarach. Czyli zamiast sytuacji, w której wszyscy są skupieni na wszystkim, tego jest bardzo dużo, no to jednak powiedzieć sobie dobrze w tym wielkim natłoku tematów, nie musimy robić wszystkiego, nadal tego jest sporo, no to powiedzmy sobie, co to jest to sporo i przydzielmy podzespoły czy jakieś takie grupy w ramach naszego zespołu, które jednak będą, no nazwijmy to w miarę komfortowych warunkach, na tyle na ile to jest możliwe, jednak skupione na jakimś wybranym, konkretnym obszarze.

Kuba: Oczywiście to podejście zakłada, że zespół jest odrobinę większy, że jest kogo dzielić, że tutaj na przykład podziale na pół i ten zespół dalej zachowuje zdolność do dostarczania rozwiązania. Ale sam byłem świadkiem kilku odmian realizacji tej praktyki i w skrócie najczęściej to wygląda tak, że albo na planowaniu iteracji czy Sprintu czy na planowaniu jakiegoś dłuższego okresu, na przykład kwartału czy czasu realizacji dla największej inicjatywy takiej trwającej kilka tygodni, zespół w ramach samoorganizacji ustala kto jest potrzebny do tego, żeby zrealizować dane przedsięwzięcie. Ludzie się tak nazwę tymczasowo przydzielają do tej inicjatywy, no i na czas realizacji tej inicjatywy być może działają po prostu jako pewna podgrupa w ramach zespołu, aż nie potrzebują wrócić do swojego oryginalnego zespołu, czy to po pomoc, czy po prostu wracają, bo już wyczerpali dane przedsięwzięcie, zakończyli je w satysfakcjonujący sposób. Więc tutaj mamy do czynienia z pewnego rodzaju podziałem. Ten podział jest tymczasowy, czyli tutaj nie ma potrzeby jakichś większych reorganizacji. Ten podział jest też bardzo taki elastyczny, więc są zespoły, które też tak troszkę go stosują, ale troszkę go łamią, ale to jest taka dojrzałość zespołu w tym, żeby dostosowywać się, być może przełamać taką przede wszystkim zasadę, że absolutnie wszyscy wszystko robią równocześnie wspólne wielkie Daily, wspólne wielkie planowania, wspólne wielkie warsztaty, gdzie to po prostu może być mało wartości dodane, a za to wielki koszt. Jest to oczywiście poziom dojrzałości zespołu, pewna umiejętność, na którą trzeba z zespołem wejść, ale jest to jeden z przedostatnich w naszym przypadku ze sposobów na to, żeby sobie poradzić z wieloma produktami realizowanymi jednocześnie.

Jacek: I ostatnia porada na dzisiaj. Rozwijaj bardziej uniwersalny profil kompetencyjny członka zespołu. Może być tak, że czasami te kompetencje, które mamy w zespole będą podsuwały pomysł, że być może powinniśmy pewne inicjatywy zrównoleglić, bo w jednej z nich nie ma pracy dla kompetencji pozostałych członków zespołu. I prowadzi to do sytuacji, w której ten Product Owner czy Product Manager, czy dowolna inna osoba decydująca o tym, czym zajmuje się zespół, w pewnym sensie jest zmuszany do uruchamiania kolejnych wątków po to, żeby wysycić dostępne osoby w zespole. Czyli po prostu, żeby każda osoba miała pracę.

Kuba: I tutaj przed oczami mam takie wspomnienie pewnego konkretnego zespołu IT, z którym miałem bardzo fajny okres współpracy, gdzie pewna programistka w czasie planowania kolejnego etapu pracy zaczęła właśnie od stwierdzenia – Kurczę, ciągle robię API. I wszyscy jej słuchający myśleli, że właśnie zgłasza się po kolejną metodę, którą będzie brała, no ale ona bardzo wyraźnie tak z odrobiną pauzy dopowiedziała i chciałabym robić coś innego. I to był fajny moment dla tego zespołu, bo to był moment, gdy jakby przestali ciągle ci sami brać ciągle te same zadania, tylko właśnie z inicjatywy jednej z programistek spróbowali trochę zamienić sobie kartki, na których rysują i po prostu wziąć trochę inne zadania niż zazwyczaj brali. W efekcie w tym konkretnym zespole doszło do fajnego miksu kompetencji, do pewnego transferu wiedzy i umiejętności, na innych częściach systemu niż zawsze. No i też efekt taki bym powiedział wielowymiarowy, no bo nowe osoby trafiły do części systemu, które zwyczajowo były rozwijane przez jedną albo maksymalnie dwie osoby, więc tam było okazji trochę do refaktoringu, trochę do popatrzenia na sprawy świeższym okiem. Ale też zespół stał się właśnie uniwersalny, zdejmując trochę to zmartwienia, od którego zaczął Jacek ten punkt, że Product Owner w tym przypadku musiał generować pracę dla wysoko wyspecjalizowanych profesjonalistów, zamiast po prostu skupiać się na tym, co jest celem i pogodzić się z tym, że zespół sobie sam poukłada pracę. Oczywiście w podejście w krótkim okresie wiąże się z tym, że ta konkretna programistka weźmie się za kawałek, na którym się mniej zna, więc prawdopodobnie jej chwilowa wydajność będzie lekko słabsza, ale już w średnim okresie to się powinno zacząć fajnie balansować. A w długim okresie zespół uzyskuje dużą zdolność do tego, żeby brać się za różne rzeczy, móc się też intensywnie zabrać za jedną, jedyną rzecz, która jest w danym momencie najbardziej potrzebna i dzięki temu maksymalnie szybko zrealizować to, co jest ważne dla produktu.

Jacek: Taka domykająca myśl dzisiejszego odcinka jest taka, że jeśli nawet te ostatnie punkty, które sugerowaliśmy, które trochę już są takim kompromisem albo granie tymi kartami, które mamy dostępne, jeśli one nawet nie brzmią realistycznie dla Twojego kontekstu, to obawiamy się, że być może masz inny, znacznie większy problem, niż jak poradzić sobie z wieloma inicjatywami produktowymi jednocześnie.

Kuba: I co mamy na myśli, mówiąc takie enigmatyczne stwierdzenia? No, w materiale zawarliśmy dużo porad. Pierwsze z nich są bardzo takie strategiczne, systemowe, ogólno organizacyjne. Kolejne już wiążą się z podejmowaniem decyzji. Te ostatnie wiążą się z tym, jak sobie po prostu radzić na zasadzie zorganizowania się. Jeśli nie jesteś w stanie zapewnić, że zespół się organizuje, albo są pewne blokady, że to w ogóle jest niewykonalne, to bardzo obawiam się o to, czy na przykład zespół ma możliwość stanowienia o swoim procesie pracy, na ile w ogóle słuchane są osoby, które mają jakieś pozycje liderskie bezpośrednio z tym zespołem. I może się okazać, że to, że nieusprawniony jest ten aspekt, to jest tylko pewien symptom tego, jak bardzo niesamodzielne, jak bardzo dociśnięte managersko są zespoły czy zasoby, które w tym zespole bezpośrednio nie pracują. To tylko hipoteza, być może nietrafna, ale postanowiliśmy zostawić takie zawieszone pytanie i refleksje na koniec.

Kuba: Podsumowując, jak radzić sobie z wieloma produktami w jednym zespole? Skup całą organizację na priorytetach i zredukuj liczbę otwartych tematów. Zmniejsz liczbę tematów przekazywanych do zespołów jednocześnie. Zreorganizuj zakres odpowiedzialności zespołów, aby obejmowały jeden konkretny produkt.

Jacek: Realizuj inicjatywy produktowe w sposób sekwencyjny. Wyodrębniaj esencję z tego, co jest do zrobienia. Twórz dynamiczne podzespoły skupione na wybranych obszarach i rozwijaj bardziej uniwersalny profil kompetencyjny członka zespołu.

Kuba: Ten odcinek to tylko fragment tego, co oferujemy w naszych programach rozwojowych dla osób zarządzających produktami w zwinnych zespołach. Wspieramy rozwój kluczowych kompetencji takich jak budowanie strategii produktowej, tworzenie Road map produktowych, dzielenie pracy na mniejsze elementy i efektywne planowanie pracy w zespole. Nasze podejście łączy praktyczne warsztaty, mentoring oraz superwizje realnych inicjatyw, by maksymalnie wspierać uczestników w codziennej pracy. Jeśli czujesz, że potrzebujesz takiego wsparcia, skontaktuj się z nami przez porzadnyagile.pl/kontakt.

Jacek: Notatki do tego odcinka, artykuł, transkrypcję oraz zapis wideo tej rozmowy znajdziesz na stronie porzadnyagile.pl/128.

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

Jacek: Dzięki, Kuba. I do usłyszenia wkrótce.

The post Jak radzić sobie z wieloma produktami w jednym zespole? first appeared on Porządny Agile.