Jaka jest różnica między Product Ownerem, Product Managerem, Project Managerem i Scrum Masterem? Kto jest do kogo bardziej podobny, jakie role lepiej łączyć, kto i kiedy jest bardziej potrzebny w organizacji? Ta dyskusja powraca jak bumerang, regularnie zarówno wewnątrz organizacji, jak i na konferencjach, szkoleniach czy w artykułach. Czasem dotyczy jedynie konkretnych ról, na przykład PM versus SM, a czasem szerzej całego sensu podejścia produktowego versus podejście projektowe. Znalezienie właściwej odpowiedzi na te pytania jest niezbędne, żeby działać skutecznie i wykorzystywać dobre praktyki zarządzania w obu typach organizacji.
Oba te podejścia są powszechnie wykorzystywane i w ostatnich latach mocno się rozwijają. I oczywiście oba mogą być bardzo przydatne. Żeby tak jednak się stało, niezależnie od tego, który profil jest nam osobiście bliższy, trzeba rozumieć kluczowe aspekty obu i być na bieżąco z ich ewolucją.
Będziemy współistnieć – zatem róbmy to skutecznie
W pierwsze kolejności przyjrzymy się zestawieniu obu koncepcji pamiętając o dwóch istotnych kwestiach:
- Po pierwsze trzeba wyjść poza własną intuicję i doświadczenie. Standardy i frameworki są różnie stosowane – czasem dlatego, że temu służą, ale czasem dlatego, że są mylnie interpretowane lub zmienia się istotę ich elementów. Istnieje sporo dobrych źródeł, które nie tylko omawiają założenia, ale także dostarczają dobrych praktyk i prezentują właśnie niejednorodne doświadczenia. Jednak biorąc udział w różnych dyskusjach wyraźnie widać, że wiele osób definiuje kategoryczne sądy pomijając zupełnie inne perspektywy, mimo że są one łatwo dostępne.
- Po drugie trzeba nastawić się na szukanie synergii. O ile podejście konfliktowe może być przydatne w początkowej burzy mózgów, o tyle złożenie sensownego, stabilnego rozwiązania trudno osiągnąć taką metodą.
W drugiej kolejności zachęcam do głębszego zrozumienia tych dwóch perspektyw i szukania różnic i części wspólnych wykorzystując kierunki rozwoju, jakie będą istotne dla każdej z tych dziedzin w najbliższych latach.
Produkt czy projekt, jajko czy kura, nasiona czy trawa…
Nie. Zdecydowanie nie warto rozwiązywać dylematu „co jest ważniejsze: produkt czy projekt”… To fałszywy dylemat. Warto jednak zrozumieć, jak podejście projektowe i produktowe przenikają się w codzienności organizacji. Obserwując tę codzienność można zauważyć trzy następujące modele.
Podejście projektowe
Zacznijmy od sytuacji, w której realizujemy projekt, a jednym z jego elementów jest produkt (oczywiście niekoniecznie tylko jeden). Podejście tradycyjnie obecne w przemyśle konstrukcyjnym, gdzie musimy na przykład dostarczyć most, wybudować i uruchomić fabrykę, ale także w IT, gdy klient zamawia dedykowane oprogramowanie.
Wybieram taki punkt na początek po pierwsze dlatego, że artykuł jest adresowany bardziej do środowiska projektowego, więc ta sytuacja jest dla nas naturalna, a po drugie historycznie: nowoczesne standardy i frameworki projektowe zagościły w zarządzaniu wcześniej i są już szeroko upowszechnione.
Wracając do podanych przykładów – taka inicjatywa będzie projektem. Według dobrych praktyk wystartuje od karty projektu i powołania kierownika projektu (trochę upraszczam i nawet idealizuję, ale nie o szczegóły inicjowania nam dzisiaj chodzi.) Jeżeli taki projekt będzie znacznych rozmiarów lub z dziedziny, w której kierownik projektu (PM) nie jest specjalistą będzie on potrzebował wsparcia dziedzinowego. Najprawdopodobniej kierowniczka lub kierownik tego projektu powoła do zespołu osobę odpowiedzialną za zakres projektu, mając świadomość, że pożądane jest wykorzystanie dobrych praktyk czy standardów z zakresu zarządzania produktem (ProdM/PdM), być może specjalistycznych, na przykład dziedzinowych. W rozbudowanych projektach będzie to może nawet cała grupa osób, jednak dla uproszczenia i uporządkowania przyjmujemy, że dla całego projektu będzie to jedna (kluczowa) osoba. Będzie ona najpewniej odpowiedzialna za gromadzenie i analizę wymagań oraz ich utrzymywanie, a następnie walidację i kontrolę ich realizacji (spełniania). Zapewne będzie też pełnić kluczową rolę w kontaktach z potencjalnymi użytkownikami lub innymi osobami w zespole klienta odpowiedzialnymi za odbiór produktów (wynikowych) projektu. W odniesieniu do zarządzania wymaganiami możemy mieć tu różne warianty szczegółowe, na przykład oddzielające wymagania projektowe od produktowych czy grupujące różne wymagania produktowe (jeśli mamy w projekcie wiele produktów), jednak pozostańmy przy wariancie najprostszym. Osoba ta – nazwijmy ją liderem produktu, wspiera PM-a w rozwoju produktu w całym zakresie planowania (analiza, mapa drogowa produktu itp.), wytwarzania oraz walidacji i weryfikacji. Pomaga skupić się na wytwarzaniu wartości dla użytkowników i klienta.
Podczas gdy kierownik projektu pozostanie odpowiedzialny ze skoordynowanie całości działań, w tym relacje z pozostałymi interesariuszami (np. biznesowe wewnątrz organizacji dostawcy), ogólny harmonogram projektu, zespół itd. W taki właśnie sposób w projektach IT, a później innych, zaczęto powszechnie wykorzystywać Scrum i rolę Product Ownera. W dzisiejszych projektach tę rolę pełni najczęściej ktoś z grona: kierownik projektu, główny analityk projektu, Product Owner, Product Manager lub osoba bez specjalnie nazwanej roli.
Podejście (czysto) produktowe
Jako organizacja (cała firma lub np. dział, czy zespół) pracujemy całościowo nad rozwojem (i sprzedażą) produktu, wraz z jego wzrostem możemy skupiać się na ciągłym rozwoju (nie tylko doskonaleniu) i możemy zupełnie zignorować zarządzanie projektami. Organizacja produktowa będzie chciała rosnąć: przeważnie powiększając produkt (jego zakres, funkcje itp.), a być może jedynie rozszerzając swój rynek (o nowe obszary), ale najczęściej wykorzystując oba elementy. Będzie powstawało coraz więcej zespołów, w różnych obszarach od pracy bezpośrednio nad rozwojem produktu, poprzez utrzymanie, obsługę klienta, analizę konkurencji, marketing czy sprzedaż oraz rozwój strategii. Niewątpliwie zatem taka organizacja będzie się skalowała. Skalowanie agile to dzisiaj bardzo modny temat, ważny i jednocześnie mocno krytykowany, zatem lepiej pozostawić go na osobny artykuł.
Dla organizacji produktowej ważniejszym kierunkiem może być DevOps lub jego dalsze wariacje, na przykład DevSecOps. Większe znaczenie będzie tam miała współpraca z innymi PO i Product Managerem. Jest spora szansa, że pojawią się tam role architektów (różnych poziomów czy typów) – ale raczej nie rola Project Managera. Myślenie ortodoksyjne w każdej dziedzinie grozi brakiem zdrowego rozsądku, stąd nie każda organizacja musi korzystać z podejścia projektowego.
Projekty w organizacji produktowej
W organizacji produktowej nadrzędne jest długoterminowe kierowanie wizją produktu. Jest ono częścią strategii organizacji lub jednostki organizacyjnej, często komunikowane z wykorzystaniem (funkcjonalnej) roadmapy produktu, ale obejmujące także elementy architektury (szczególnie dla złożonych produktów). W przypadku gdy nad rozwojem produktu pracuje pojedynczy zespół, za maksymalizację wartości jaką dostarcza produkt odpowiadać będzie Product Owner (bazując na Scrum Guide). Przy większej skali i złożoności wprowadzana jest rola Product Managera. Odpowiada on za całość rozwoju produktu; praca dzielona jest pomiędzy poszczególne zespoły, a Product Manager koordynuje zakres ich pracy współpracując z Product Ownerami tych zespołów.
Podejście projektowe może być skutecznie wykorzystywane w organizacji produktowej, na przykład we wdrożeniach czy zarządzaniu zmianą. Tam gdzie potrzebne jest jednorazowe wdrożenie produktu dla klienta, często z elementami kastomizacji – jednakże w ramach strategii i roadmapy produktu (projekt wdrożeniowy). Lub tam gdzie potrzebny jest dobrze skoordynowany, szeroki, skokowy rozwój (czy np. modernizacja) tego produktu (projekt rozwojowy).
Dla uzupełnienia klasyfikacji można jeszcze dodać podejście „produkty w organizacji projektowej”, czyli przypadek w którym organizacja zasadniczo działa projektowo, jednak rozwija produkt wewnętrzny, wspierający jej działalność lub podejmuje działania zmierzające do utworzenia produktów albo nawet już zarządza produktami – jednak jej głównym sposobem działania pozostaje podejście projektowe. Taka działalność i stosowane w niej rozwiązania są przeważnie miksem opisanych powyżej, a dodatkowo produkty mają zazwyczaj dłuższy cykl życia niż projekty. Dlatego opis czwartego podejścia nie wniósłby wiele nowego do rozważań.
W Tabeli 1. zestawione zostały:
- najważniejsze charakterystyki ról Project Managera oraz liderki lub lidera produktu (najczęściej Product Ownera lub Product Managera);
- kluczowe kierunki monitorowanie skąd/dokąd – nazwane tak zamiast „raportowania w górę / w dół” w celu podkreślenia mniejszego znaczenia hierarchii; obejmujące także dbanie o zgodność z wizją;
- kluczowe metody i standardy wskazujące najważniejsze źródła opisujące szeroko uznane, skoordynowane sposoby postępowania w poszczególnych podejściach.
Tabela 1. Porównanie podejścia projektowego, produktowego i projektów w organizacji projektowej
Źródło: opracowanie własneRazem do przodu: kierunki rozwoju bardziej różne, czy jednak zgodne
Niezależnie z którego podejścia będziemy korzystać – czy też z ich miksu – żeby być skutecznym, istotna jest znajomość kluczowych działań i kompetencji w każdej z ról: lidera projektu i lidera produktu. W coraz bardziej dynamicznych czasach warto skupić się na patrzeniu w przód. Dlatego drugie spojrzenie proponuję zrobić przez pryzmat kluczowych trendów w gospodarce (cyfrowej, choć nie tylko) i ich znaczenia dla omawianych obszarów. Jakie są zatem główne kierunki rozwoju, które dobry kierownik produktu i kierownik projektu powinni znać? Do tych rozważań zaproszę Was w kolejnej części artykułu.
Menedżer z wykształcenia i lider z doświadczenia z ponad 20-letnim stażem w zarządzaniu projektami i produktami. Jego codzienną pracą jest inspirowanie i wspieranie tworzenia optymalnych rozwiązań. Uwzględniając potrzeby, ograniczenia i dostępne metody: lean, agile, stewardship, leadership… ciągle szuka najbardziej skutecznych narzędzi. Promuje maksymalnie praktyczne podejście, jednak oparte na wiedzy i doświadczeniu z wielu źródeł. A efekty ocenia przez satysfakcję, jaką przynoszą zarówno klientowi, jak i zespołowi. Dzieli się swoją wiedzą jako lider, coach, mentor, trener. PMP®, SAFe® SM.