Alternatywa dla map drogowych

Ten cytat generała George'a Pattona zawsze mi się podobał:

„Nie mów ludziom, jak mają coś robić. Powiedz im, co mają zrobić, a zaskoczą cię swoją pomysłowością".

Niestety mapy drogowe robią dokładnie to, przed czym generał ostrzega

Mapy drogowe mówią zespołom, co i jak mają robić. Zazwyczaj dzieje się to w postaci priorytetowych list funkcjonalności lub projektów, co do których ktoś naprawdę wierzy, że rozwiążą problem (nawet jeśli problem często nie jest jeszcze jasny ani naprawdę zrozumiany).

Jeśli na Twojej mapie drogowej widnieje coś takiego jak „dodać PayPal jako dodatkową opcję płatności", to czy powodem jest to, że uważasz, iż są klienci, którzy nie mogą płacić Twoimi innymi metodami płatności? A może ma to coś wspólnego z płatnościami międzynarodowymi? Albo ktoś uważa, że brak tej opcji byłby wadą konkurencyjną?

W kilku artykułach wskazywałem już, że klasyczne mapy drogowe produktu uważam za źródło bardzo dużego marnotrawstwa w zespołach produktowych. Artykuł Produkty, które poniosły porażkę dotyczy tego tematu, a w Nieprzyjemne prawdy o wytwarzaniu produktów zagłębiam się dokładniej w tę koncepcję.

Ponieważ problem z mapami drogowymi zyskuje coraz więcej uwagi, w ostatnim czasie byłem częściej proszony o opowiedzenie więcej o alternatywie dla map drogowych.

Obszerny temat

W tym artykule chciałbym to spróbować. To duży temat, który wiąże się również z kwestiami kultury produktu, upełnomocnienia i autonomii. Zazwyczaj potrzebuję co najmniej godziny, aby komuś osobiście to wszystko wyjaśnić, ale mam nadzieję, że uda mi się tu zebrać esencję.

Zanim rzucimy się na alternatywę dla map drogowych, musimy sobie uświadomić, że mapy drogowe były używane przez długi czas, ponieważ służą dwóm konkretnym potrzebom – i te potrzeby nie znikną po prostu tak.

1) Kierownictwo chce mieć pewność, że zespoły pracują najpierw nad elementami o największej wartości dla firmy.

2) Ponieważ muszą zarządzać firmą, są sytuacje, w których potrzebują konkretnych terminów i zobowiązań – a mapy drogowe pozwalają im rejestrować i śledzić te zobowiązania.

Aby alternatywa dla klasycznych map drogowych została zaakceptowana przez firmy, obie te kwestie muszą być adresowane co najmniej równie dobrze jak dotychczas.

Mapy drogowe mają swoje korzenie w starym, scentralizowanym modelu dowodzenia i kontroli. Niektórzy interesariusze organizują spotkanie – zazwyczaj kwartalnie – aby zastanowić się nad priorytetami i projektami zespołów na następny kwartał.

W przeciwieństwie do tego, w modelu zespołu produktowego zespoły mają same wymyślać, jak rozwiążą poszczególne problemy biznesowe, którymi mają się zająć.

Ale do tego nie wystarczy tylko mieć dobrych pracowników. Zespół potrzebuje niezbędnego kontekstu. Członkowie zespołu muszą mieć zakorzenioną wiedzę o tym, dokąd zmierza firma, i muszą rozumieć, co ich własny zespół ma wnosić do tego nadrzędnego celu.

Wracając do generała Pattona:

Jak możesz już wiedzieć, wojsko również pracuje z koncepcją autonomicznych zespołów. Zespoły te (Squads) są celowo utrzymywane małymi i są w dużej mierze autonomiczne, zawsze mając na uwadze wspólne intencje, mogą jednak same decydować, co uważają za najlepszy sposób rozwiązania danego problemu.

Te wspólne intencje to kontekst, o którym właśnie wspomniałem. „Poprzez intencje precyzyjnie formułuje się nadrzędne cele i zamierzenia… Jasne intencje prowadzą do ukierunkowanych działań sił zbrojnych. Wyrażają to, co dowódca chce osiągnąć i dlaczego, i dają siłom zbrojnym poczucie wspólnoty. Zazwyczaj wyrażane są przez możliwe skutki, cele i pożądane rezultaty… Naprawdę dobrze sformułowane intencje są zrozumiałe dla podwładnych nawet bez dużej ilości dodatkowych szczegółów."

Firmy technologiczne mają różne możliwości zapewnienia tego kontekstu lub tych intencji. Jednak opowiadam się za dwoma bardzo konkretnymi komponentami:

Wizja produktu: opisuje holistyczne spojrzenie na rzeczy, które organizacja jako całość stara się osiągnąć.

Cele firmy: opisują konkretne, priorytetowe cele biznesowe dla każdego indywidualnego zespołu produktowego.

Istnieje kilka systemów i metodologii zarządzania tymi celami firmy. Moim ulubionym jest jednak obecnie system OKR (Objectives and Key Results).

Sama idea jest dość prosta: powiedz członkom zespołu, co mają osiągnąć i jak będą mierzone wyniki. Następnie pozwól zespołowi samemu zdecydować, co uważa za najlepszy sposób rozwiązania poszczególnych problemów.

Weźmy na przykład, że dla Twojego produktu potrzebujesz obecnie 30 dni na proces onboardingu nowych klientów. Aby jednak móc skutecznie skalować, trzeba to zredukować do 3 godzin lub mniej. To byłby dobry przykład celu dla jednego lub kilku zespołów produktowych: „Znacznie zredukować czas do uruchomienia klienta." Jednym z kluczowych wyników mógłby być: „Średni czas onboardingu poniżej 3 godzin."

Choć koncepcja celów zespołu brzmi dość prosto, istnieje wiele sposobów na jej instytucjonalizację w zespołach produktowych i organizacjach, a osiągnięcie korzyści z tej koncepcji może zająć kilka kwartałów.

Istnieje kilka spostrzeżeń dotyczących wizji produktu, a szczególnie dobrego stosowania systemu OKR, którymi zajmę się w kolejnych artykułach. W międzyczasie możesz już przejrzeć materiały Christiny Wodtke.

Ten kontekst jest więc bardzo ważny – czyli wizja produktu i cele zespołu.

Na początku wspomniałem, że musimy uwzględnić dwa główne powody dla tradycyjnych map drogowych. Pierwszym z nich było pragnienie pracy najpierw nad elementami o największej wartości dla firmy. Mam nadzieję, że jest jasne, że kierownictwo zajmuje się tą potrzebą, dostarczając konkretne cele dla organizacji i ich priorytetyzację. Różnica polega jednak na tym, że teraz priorytetyzują ważność wyników biznesowych zamiast subiektywnej wartości funkcjonalności.

Drugi powód to konieczność zobowiązań, którą adresujemy koncepcją zobowiązań o wysokiej integralności. Odnosi się to do sytuacji, w których naprawdę potrzebujemy zobowiązania co do daty lub określonego wyniku.

To podejście ma kilka zalet:

Po pierwsze, zespoły są o wiele bardziej zmotywowane, gdy mogą same wymyślić, co uważają za najlepsze rozwiązanie problemu.

Po drugie, zespół nie może po prostu dostarczyć żądanej funkcjonalności lub projektu; funkcjonalność musi również naprawdę działać (co jest mierzone za pomocą Key Results). Jeśli nie, zespół musi wypróbować inne podejście do rozwiązania problemu.

Po trzecie – bez względu na to, skąd pochodzi pomysł na rozwiązanie – bardzo często pierwsze podejście nie działa i zamiast temu zaprzeczać, jest się tego bardzo świadomym w tym modelu.

Chodzi bardziej o wyniki zamiast produktu – czyli uzyskanie sensownego rezultatu, zamiast tylko realizowania jakiegoś celu.

Często proszę zespoły, aby spojrzały wstecz na miniony rok i oceniły się na podstawie wskaźnika sukcesu swojej mapy drogowej, a mianowicie pod kątem tego, ile elementów faktycznie odpowiadało celom biznesowym. Jeśli to zrobisz i nie będziesz dumny z tego, co odkryjesz, mam nadzieję, że rozważysz tę alternatywę. Upewnij się, że Twoja organizacja produktowa ma przekonującą wizję produktu. Upewnij się, że każdy zespół produktowy ma jasno zdefiniowane i priorytetowe cele biznesowe. Upewnij się, że wszystkie zobowiązania, które muszą być podjęte, są zobowiązaniami o wysokiej integralności.
A teraz upełnomocnij swoje zespoły produktowe, aby mogły same decydować, jakie rozwiązania uważają za najbardziej odpowiednie dla określonych problemów biznesowych, i zobaczysz, ile Twoich zespołów zaskoczy Cię swoimi wynikami.

Niniejszy tekst pochodzi z bloga Marty'ego Cagana i został przez nas przetłumaczony na język polski.

Szkolenie Product Owner

=> Odwiedź teraz szkolenie Product Owner Agile Academy.

Product Backlog

=> Przeczytaj więcej o Product Backlogu w słowniku agile.

Rola Product Ownera

=> Dowiedz się więcej o roli Product Ownera.