Za dużo pomysłów, za mało czasu: jak PM może odzyskać kontrolę nad codzienną pracą

Krótko mówiąc: nie toniesz w pracy, tylko w braku systemu. Ten tekst pokazuje prosty sposób na opanowanie chaosu, gdy jako it product manager obsługujesz wiele zgłoszeń, klientów i projektów naraz. Zobaczysz, jak nazwać problem, podzielić strumienie pracy i priorytetyzować zadania tak, aby sprint i iteracja znów były przewidywalne.

Najważniejsze wnioski z artykułu

• Problemem zwykle nie jest ilość zadań, tylko brak filtrów decyzji.
• Podział pracy na cztery strumienie porządkuje zarządzanie backlogiem i firefighting.
• Inaczej ustawisz system dla dedykowanego, a inaczej dla współdzielonego zespołu.
• Prosta priorytetyzacja po wartości i koszcie opóźnienia zmienia roadmapę w realny plan.

Skąd jako it product manager wiedzieć, że problemem nie jest za dużo pracy, tylko brak systemu?

Problem nie polega na tym, że masz za dużo zadań, tylko na tym, że wszystko przechodzi bez filtrów. Problem it product managera rzadko polega na ilości pracy, częściej na braku prostego systemu decyzyjnego. Z mojego doświadczenia wynika, że typowy dzień product manager w software house to tsunami komunikatów: Slack, mail, kolejne call z klientem. W projekcie opartym o ruby on rails wygląda to tak samo jak w innych: każdy zgłasza swoje „na już”, a ty łapiesz to w locie.

Na pierwszy rzut oka wydaje się, że to normalne, bo „taka rola”. Gaszenie pożarów w projekcie IT to jednak znak, że system się skończył, a nie że jesteś za słaby. Sprint i iteracja rozpadają się po dwóch dniach, bo nie ma jasnych zasad, co może wejść do środka. Bez choćby najprostszego framework pracy PM-a każda nowa prośba ma taką samą wagę jak decyzje strategiczne. W efekcie plan istnieje tylko na papierze i w narzędziu, a nie w realnym dniu zespołu.

p=

Zastanów się, czy brzmi znajomo: każdy task ma priorytet „wysoki”, backlog puchnie, a ty nie umiesz wskazać trzech najważniejszych rzeczy na ten tydzień. Jeśli nie potrafisz spokojnie powiedzieć „tego nie robimy teraz”, działasz bardziej jak strażak niż it product manager z systemem. Pamiętam projekt, w którym klient mówił, że „wszystko jest ważne”, dopóki nie usłyszał, że wtedy nic nie będzie na czas. Głos eksperta, który lubię powtarzać, jest prosty: „Gdy wszystko jest ważne, nic nie jest ważne”.

Jak podzielić pracę it product managera na strumienie, żeby ogarnąć zarządzanie backlogiem i firefighting?

Praca PM-a robi się lżejsza, gdy przestajesz mieć jeden wielki worek zadań i dzielisz wszystko na cztery strumienie. Zarządzanie backlogiem ma sens dopiero wtedy, gdy osobno traktujesz parking pomysłów, backlog decyzyjny, committed work i firefighting w zespole developerskim. Parking pomysłów to miejsce na luźne idee. Backlog decyzyjny to lista rzeczy, które naprawdę rozważasz. Committed work to to, co wchodzi do sprintu. Firefighting to pożary, które tylko czasem mogą go przerwać.

Bez osobnego parking pomysłów każdy wpis trafia od razu na listę „do zrobienia”, a po chwili masz przeładowany backlog, którego nikt nie umie już przeczytać. Parking to nie obietnica realizacji, tylko bezpieczne miejsce na „może kiedyś”, które odciąża głowę i narzędzie. Zadania typu nowe badania czy dopracowanie projektowanie UX/UI lądują najpierw w parkingu, a dopiero potem, po rozmowie o wartości, wchodzą do backlogu decyzyjnego. Dzięki temu committed work zawiera tylko to, co przeszło świadomą decyzję, a nie wszystko, co ktoś wrzucił na kanał.

Firefighting w zespole developerskim ma swój własny strumień, bo inaczej po cichu zjada ci pół sprintu. Jeśli nie widzisz na wykresie, ile czasu idzie na pożary, zawsze będziesz myślał, że zespół „wolno dowozi”. Pomaga prosty próg: jeśli na awarie i blokerowe bugi schodzi więcej niż około jedna piąta czasu, to nie jest już wyjątek, tylko sygnał, że system przecieka. Do tego dochodzi jeden oficjalny kanał zgłoszeń i prosty format, który wymaga podania problemu, kogo dotyczy i czy to naprawdę blocker. Dzięki temu kanał zgłoszeń staje się filtrem, a nie kolejną ścianą płaczu.

Jak zmienia się podział strumieni pracy, gdy PM ma dedykowany zespół developerski, a jak przy współdzielonym?

Ten sam model czterech strumieni działa w obu konfiguracjach, ale inaczej go ustawisz. Przy dedykowany zespół developerski możesz budować rytm wokół jednego klienta, przy współdzielony zespół developerski musisz pilnować limitów na projekty. W pierwszym scenariuszu parking pomysłów, backlog decyzyjny, committed work i firefighting dotyczą jednego produktu. Wtedy łatwiej uzgodnić priorytety i zbalansować pożary z planem, bo interesariuszy jest mniej i mają wspólny kontekst.

W projekcie z jednym dużym klientem możesz ustalić stałą pulę czasu na firefighting i wspólnie patrzeć na liczby. Dedykowany zespół developerski daje PM-owi większą kontrolę nad rytmem sprintów i reagowaniem na zmiany. Widziałem zespoły, które na tej bazie budowały bardzo stabilne iteracje, bo klient wiedział, że ma osobny slot na awarie i osobny na rozwój. W takim układzie strumienie są proste, a wyzwanie polega raczej na trzymaniu dyscypliny decyzji niż na pogodzeniu wielu światów naraz.

Przy środowisko multi-klientowe sprawa robi się ciekawsza, bo jedna iteracja dotyczy kilku produktów jednocześnie. Współdzielony zespół developerski wymaga jasnych limitów, ile committed work i firefighting może przypadać na każdego klienta. Dobrze widać to w przeglądzie różnych projektów, takim jak portfolio IT: różne branże, różne SLA, ale wspólny problem z zarządzanie oczekiwaniami interesariuszy. W praktyce pomaga prosty podział na sloty dla klientów i jawne zasady, kto ma pierwszeństwo w pożarach. Dzięki temu cztery strumienie dalej działają, tylko są docięte do realiów współdzielonego zespołu.

Jaką prostą metodę priorytetyzacji powinien stosować it product manager, żeby roadmapa produktu nie była listą życzeń?

Priorytetyzacja zadań nie służy temu, żeby ładnie pokolorować backlog, tylko żeby jasno powiedzieć „to teraz, tego nie teraz”. Priorytetyzacja zadań dla it product managera to sztuka mówienia „nie teraz” na podstawie wartości, a nie głośności zgłaszającego. Roadmapa produktu przestaje być listą życzeń, gdy każde zadanie ma uzasadnioną wartość biznesową funkcji i znany koszt opóźnienia. Z mojego doświadczenia wynika, że sama zmiana rozmowy z „czy damy radę?” na „co się stanie, jeśli przesuniemy to o sprint?” robi ogromną różnicę.

Najprostszy model, który dobrze działa w software house, to Impact/Effort z dołożonym kontekstem klienta. Szuka się zadań o wysokim wpływie przy rozsądnym wysiłku, zamiast realizować to, co akurat najgłośniej wybrzmi na spotkaniu. Przy produktach typu dedykowane oprogramowanie zawsze jest pełna lista „must have”. Gdy do tego dochodzą jeszcze dedykowane aplikacje mobilne, liczba próśb podwaja się od razu. Wtedy prosty framework pracy PM-a z jednym modelem priorytetów daje więcej niż najbardziej rozbudowany arkusz kalkulacyjny.

Żeby to zadziałało w sprint i iteracja, potrzebujesz kilku stałych pytań przed przepchnięciem pozycji do committed work. Krótka lista kontrolna przed sprintem potrafi uratować roadmapa produktu przed przemianą w śmietnik życzeń.

1. Kto konkretnie płaci za to zadanie albo funkcję.
2. Jaka jest wartość biznesowa funkcji w najbliższych trzech miesiącach.
3. Jaki jest koszt opóźnienia, jeśli przesuniemy to o jeden sprint.
4. Co dokładnie wypadnie ze sprintu, jeśli to zadanie wejdzie do środka.
5. Czy umiemy zdefiniować minimalny zakres, który daje realną wartość, bez rozdmuchiwania pracy.

Jak przestać być strażakiem i znowu być PM-em z planem?

Pytanie 1: Jak jako pm ogarnąć chaos zadań i zgłoszeń żeby nie tonąć codziennie w slaku i mailach?

Podziel pracę na cztery strumienie: parking pomysłów, backlog decyzyjny, committed work i firefighting. Do sprintu wpuszczaj tylko to, co przeszło przez backlog decyzyjny. Wszystkie nowe pomysły wrzucaj najpierw na parking, a nie od razu do „do zrobienia”.

Pytanie 2: Jak ustawić priorytety z klientem kiedy wszystko ma status ważne i pilne?

Rozmawiaj o wartości biznesowej i koszcie opóźnienia, a nie o samym „ważne”. Pytaj, co się stanie, jeśli przesuniecie zadanie o jeden sprint. Gdy klient mówi, że wszystko jest ważne, pokaż, co wypadnie ze sprintu, jeśli coś nowego wejdzie do środka.

Pytanie 3: Jak mierzyć i ogarniać firefighting żeby nie zjadał całego sprintu?

Traktuj firefighting jako osobny strumień pracy i licz, ile czasu na niego schodzi. Jeśli pożary biorą więcej niż około jedną piątą czasu, to sygnał, że system przecieka. Ustal jeden kanał zgłoszeń z prostym formatem opisu problemu i progiem, co naprawdę jest blockerem.