Dowiedz się o różnicach pomiędzy pracą w obu podejściach w sposób zwinny. Czym jest projekt, a czym produkt i jak my rozumiemy w nich zwinność – jakie są różnice między nimi? Czy w ogóle istnieje jakaś gotowa lista kontrolna, która pozwala sprawdzić zwinność? Jaką w tym wszystkim odgrywa rolę lider projektu? O tym mówimy w 36. odcinku podcastu Porządny Agile.
Zobacz wersję wideo
💡 BEZPŁATNA KONSULTACJA DLA LIDERÓW 💡
Porozmawiajmy o efektywności w Twojej firmie!
Bezpłatną konsultację kierujemy do osób zarządzających technologią lub produktem w średnich i dużych firmach, które mają pod sobą co najmniej kilka zespołów wytwarzających.
Rozmowa trwa zwykle 45 minut, które możesz wykorzystać na skonsultowanie ważnego dla Ciebie tematu związanego z procesem dostarczania produktów cyfrowych.
UMÓW BEZPŁATNĄ KONSULTACJĘ →Dodatkowe materiały, które wspominamy w nagraniu:
Transkrypcja podcastu „Zwinne projekty i produkty”
Kuba: W tym odcinku chcielibyśmy opowiedzieć trochę o różnicach między podejściem projektowym, a produktowym i pracą w obu tych podejściach w sposób zwinny. Treścią tego odcinka będzie zdefiniowanie najpierw pojęć, czyli co rozumiemy pod projektem i co rozumiemy pod rozwojem produktu. Podzielimy się też naszym zrozumieniem zwinności w projektach i produktach. Na końcu przedyskutujemy subtelne różnice i też trochę w pewnym sensie zagrożenia jakie są między tymi podejściami. Natomiast coś o czym ten odcinek na pewno nie będzie, to nie będzie to krytyka ani porównywanie wyższości jednego podejścia nad drugim. W szczególności chcemy uniknąć krytykowania słabych projektów i przeciwstawiania tego dobremu podejściu produktowemu i na odwrót. Słabe podejście produktowe kontra świetne projekty. Od tego chcemy się dystansować. Mamy nadzieję, że nam się w tym odcinku to uda.
Jacek: Tak. Chcielibyśmy zacząć generalnie od takiego zdefiniowania sobie o czym tak naprawdę mówimy. Jeżeli myślimy o projektach w trakcie dzisiejszego odcinka, no to myślimy o projektach, że jest to pewne tymczasowe przedsięwzięcie, które tworzymy mając jakiś konkretny cel z tyłu głowy. To może być wyprodukowanie jakiegoś unikalnego produktu, to może być wyprodukowanie jakiejś usługi lub jakiś rezultat, który chcemy uzyskać. Projekty w naszym rozumieniu dzisiejszej rozmowy zawsze mają początek, zawsze mają koniec i jakiś konkretny zakres do zrealizowania. Mamy też przeznaczone jakieś konkretne zasoby, w tym zasoby ludzkie, żeby taki projekt zrealizować.
Kuba: Mówiłeś Jacek w naszym rozumieniu. Natomiast to nie jest tak, że teraz we dwóch ukuliśmy jakąś definicję projektu. Żeby też być bardzo poprawnym metodycznie w tym miejscu, po prostu posiłkowaliśmy się definicją projektów. Akurat skorzystaliśmy z materiałów udostępnianych przez Project Management Institute.
Jacek: Ok. Czyli tak będziemy definiować projekt. Jak zdefiniujemy produkt Kuba?
Kuba: Produktu akurat nie będziemy definiować, bo jest to dosyć abstrakcyjne pojęcie. Natomiast takie podejście rozwoju produktu, to coś mam przygotowane jako swoją definicję. Tutaj podejście produktowe, czy zarządzanie rozwojem produktu to szereg działań podejmowanych, żeby dostarczyć na rynek coś, co spełnia życzenia, albo potrzeby klienta. I to jest bardzo konkretna definicja, chociaż ona może być dosyć wieloznaczna. Zdajemy sobie z tego sprawę. Mówimy tutaj o szeregu różnych działań zarządczych, wymyślania kreacji, rozwoju i utrzymania czegoś, co odpowiada na potrzeby klienta.
Jacek: W dobie dużej popularności zwinności zaczęliśmy się z Kubą zastanawiać po czym byśmy poznali czy zwinny projekt, czy zwinny rozwój produktu? Bardzo łatwo dzisiaj do zarządzania projektem dodać słowo zwinne, do zarządzania produktem dodać słowo zwinne. Na prawo, na lewo operować pojęciem, że realizujemy pewne projekty czy produkty w zwinny sposób. Tak więc przygotowaliśmy konkretną listę przykładów, które naszym zdaniem odróżniają projekty i produkty realizowane w sposób zwinny od projektów i produktów realizowanych w sposób nazwijmy to klasyczny.
Kuba: Tak jak wstępnie zaznaczyłem, to nie jest rozmowa o tym, czy coś jest zwinnym projektem czy zwinnym produktem. Tylko po czym w ogóle poznajemy, że coś jest zwinne. Wcale tutaj nie chcemy rozróżniać, które z nich jest lepsze, przynajmniej w tej części rozmowy. Możecie potraktować to, jako taką budowaną przez nas check-listę. Bo to też nie jest tak, że usiedliśmy i nagle to wymyśliliśmy. To jest raczej efekt wszystkich naszych działań, podejść i też pewien sposób pracy, jeśli trafiamy do nowego zespołu, do nowej firmy i sobie sami chcemy sprawdzić, czy to co właśnie doświadczamy, co obserwujemy, pracę tego zespołu, którą mamy okazję zobaczyć na własne oczy, czy to jest praca zwinna czy nie.
Jacek: Yhm.
Kuba: Nie jest to takie trywialne. Zanim przejdziemy do konkretnie do tej listy. Bo też tworząc tę listę sami sobie zadawaliśmy trochę pytań. Nie istnieje nigdzie jakaś taka jedna jedyna słuszna lista. Łatwo o różne interpretacje tego, co to znaczy podejście zwinne. Również z zagrożeniami tej myśli. Możemy na przykład zbyt wąsko pewne rzeczy potraktować. Jeśli korzystamy ze Scruma to pracujemy zwinnie. Ale też na przykład stwierdzić – kurczę mamy zakres zdefiniowany na początku, albo termin, to na pewno nie jest praca zwinna. O tym mówiliśmy w jednym z poprzednich odcinków. Teraz przejdźmy do konkretnych przykładów po czym poznajemy, że jakaś praca jakiegoś zespołu to zwinna praca, zwinny projekt albo zwinny rozwój produktu.
Jacek: Pierwsze co mi przychodzi do głowy to na pewno takie rozróżnienie czy proces pracy, który stosujemy oraz ten nasz produkt usprawniamy w trakcie. Czyli przekładając to na jakieś konkretne praktyki, które mogą być dla Ciebie znane, no to myśląc o usprawnianiu pracy mam na myśli chociażby praktykowanie regularne jakieś formy retrospektywy. Czyli dbanie o to, że wraz z upływem czasu usprawniamy proces i wchodzimy w każdy kolejny dalszy krok rozwoju mądrzejsi, bardziej usprawnieni, z jakimiś usuniętymi przeszkodami, które torują efektywność naszych działań. Natomiast równocześnie mam tutaj na myśli też usprawnienie w takim rozumieniu, że ten nasz produkt pracy on również podlega usprawnieniom. Czyli to nie jest tak, że sobie blokujemy – powiedzmy, nie wiem – pół roku czasu i cały czas bez sprawdzania tego w jakikolwiek sposób by z rynkiem, z użytkownikami, z klientem pracujemy nad tym, tylko staramy się tę informację zwrotną na temat tego produktu zbierać. No i ten produkt po prostu wraz z jego rozwojem równocześnie usprawniać.
Kuba: Następną kwestią, po której możemy poznać czy praca przebiega w sposób zwinny to odpowiedzenie sobie na pytanie: Jak przebiega współpraca i jak wyglądają interakcję między członkami zespołu? Praca zwinna dla nas charakteryzuje się bardzo ścisłą współpracą, wzajemną pomocą, wzajemną jakąś tam wymianą doświadczeń. Być może również przełamywaniem swoich ścisłych specjalizacji. Traktowanie się jako silnego zespołu, który realizuje pracę we wspólnie obranym celu. Nie chcę za mocno epatować jakby negatywną stroną, no ale gdzieś dla mnie niezwinne to jest traktowanie się jako osoba, która ma po prostu zrobić swój kawałek zadania, odhaczyć, zaraportować, że zostało to zrealizowane – to z perspektywy osobistej, ale też akceptowanie, że cały zespół ma takie podejście, czy nawet całe struktury w całej firmie – jeśli patrzymy z perspektywy managera czy lidera całej organizacji.
Jacek: Kolejna rzecz, która z naszej perspektywy wpływa na to, że możemy powiedzieć o produkcie czy projekcie, że jest realizowany w sposób zwinny, to zadbanie o to, żeby odpowiedzialność za to, co jest produkowane została przekazana również do zespołu, który te produkty, te usługi, czy cokolwiek co wytwarza, produkuje. Czyli takie umożliwienie osobom, które faktycznie wykonują pracę, żeby posiadały faktyczny wpływ na rezultat tej pracy. Żeby była tam przestrzeń na podejmowanie decyzji. Żeby była tam przestrzeń na też jakąś taką co-kreację produktową, a nie tylko wykonywanie – tak bym powiedział, podwykonawczo jakichś konkretnych działań. No takie dobre staropolskie słowo na to, a jednocześnie bardzo pojemne to empowerment. Natomiast, po to cały ten długi wstęp, żeby przedstawić tak bardziej obrazowo, co konkretnie tutaj mamy na myśli.
Kuba: Kolejną też bardzo podobną kwestią związaną z zespołowością czy zwinnym zespołem, to funkcjonowanie samoorganizacji w zespole. Jakby współkreowanie pomysłu na rozwiązanie, współtworzenie planu pracy całego zespołu. I też takie wzajemne fajne wspólne reagowanie na to co rzeczywistość później nam pokazuje. Tutaj świadomie uwypuklę zarówno takie podejście projektowe, jak i produktowe. W projekcie to mam na myśli brak funkcjonowania jakiegoś dyktatora, lidera czy takiego w cudzysłowie „mocnego” kierownika projektu, który mówi tu szczegółowo, kto co ma zrobić. Rozdaje ludziom zadania i ich surowo rozlicza. To jest dla mnie zaprzeczenie samoorganizacji. I może istnieć projekt, być może nawet istnieje w tym projekcie rola kierownika projektu, ale w mądry sposób przekazuje odpowiedzialność do całego zespołu. I to zespół tworzy swoje plany, to zespół zastanawia się jak to zrealizować. Zespół wymyśla też sposób na przykład monitorowania swojej pracy. Jakby samo podejście projektowe tutaj nie zabrania samoorganizacji. Ale też, żeby nie było tylko słodko. Byliśmy też świadkami podejścia, w którym teoretycznie jest wykorzystywany na przykład Scrum. Praca zespołu jest zogniskowana wokół wytworzenia i dalszego rozwoju jakiegoś konkretnego produktu. No, ale w zespole dalej tej samoorganizacji może nie być, bo na przykład funkcjonuje jakaś bardzo silna osobistość. Nie jest to w żaden sposób ani korygowane, a wręcz może nawet jest zachęcane przez jakieś systemowe rozwiązania w całej organizacji. Niestety pewne rzeczy pewne rzeczy się nie wyłaniają przez wzajemną samoorganizacji inspirację, ponieważ jest to bardzo monopolizowane.
Jacek: Kolejna rzecz, która z naszej perspektywy rozgranicza zwinne projekty i zwinny rozwój produktu od tych takich niezwinnych – to jest skupienie na tym, żeby jak najwcześniej, jak najczęściej dostarczać rezultatów. Czyli mówimy tutaj o tej sytuacji, w których co pewien określony czas, co pewien określony krok dostarczamy, dostajemy coś namacalnego. W kontrze do podejścia, w którym długo długo długo nie ma nic, nie ma żadnych produktów, nie ma żadnych rezultatów. No i dopiero na końcu projektu, czy na końcu prac nad produktem dostajemy coś co mówimy – to teraz jest zrobione, teraz jest to gotowe. W podejściu zwinnym spodziewałbym się jakichś przyrostów, jakichś takich produktów pośrednich od takich najbardziej nieoszlifowanych, niedoskonałych, ale już spełniających jakieś podstawowe potrzeby odbiorców klienta, użytkowników. Poprzez takie mądre dokładanie kolejnych atrybutów, czy jakichś funkcji tego produktu, które będą powodowały, że będzie on coraz lepszy.
Kuba: Podobny temat też powiązany z tym wczesnym dostarczaniem rezultatów, to też wczesne dostarczenie tych fragmentów rozwiązań, które w pierwszej kolejności realizują potrzebę klienta. Czyli spośród wszystkich rzeczy, które można zrealizować w całym produkcie, jakaś forma priorytetyzacji, selekcji, też trochę dekompozycji. Żeby poszukać takie rozwiązanie, które w jak największym stopniu odpowiada na potrzebę i spróbować je dostarczyć wcześniej, czyli ten punkt, o którym powiedziałeś wcześniej. I żeby to zamieniać na konkret, na przykład z realiów pracy projektowej, no to szczególnym anty wzorcem zarówno tego mojego, jak i tego twojego punktu, no to będzie idea – dostarczymy całość rozwiązania na koniec projektu, wtedy będzie wielkie wdrożenie, wielkie bum. Zarówno w projekcie można sfazować pewne etapy dostarczenia rozwiązania. Jak i w produkcie warto dbać o to, żeby jak najczęściej dostarczać fragmenty produktu, te najbardziej wartościowe i też dać sobie miejsce na to, żeby zrealizować kolejną z charakterystyk podejścia zwinnego.
Jacek: Kolejna rzecz, to jest jakby zwinności dopatrujemy się w momencie, kiedy jesteśmy w stanie reagować na zmiany. Czyli to jest taka kontra do podejścia, w którym zakochujemy się w naszych pomysłach na projekt, czy na produkt. No i konsekwentnie długo nie dopuszczamy żadnych sygnałów, informacji, które wskazywałyby na to, że być może można zrobić to lepiej. Być może można zrobić to inaczej. Albo w skrajnym przypadku no w ogóle wymyśliliśmy sobie coś, co odpowiada na naszą potrzebę, ale tak naprawdę nikt oprócz nas nie jest zainteresowany rezultatem. Tak więc taka umiejętność też wzięcia na klatę tego, że coś nie do końca jest doskonałe jak myśleliśmy. No to też jest coś, co z naszej perspektywy definiuje tą otwartość na zmiany, czyli coś, czego byśmy szukali w podejściu zwinnym.
Kuba: I to reagowanie na zmiany może wynikać z ostatniej z tej listy naszych przykładów czy pytań, o której myślimy. Ostatni z punktów, który byśmy dodali to kontakt z odbiorcą docelowym w toku prac rozwojowych. W wielu projektach, ale też i w wielu pracach produktowych często zapominany jest ten aspekt pierwsza z zasad Manifestu Zwinnego Wytwarzania Oprogramowania, czyli kontakt i skupienie się na potrzebach odbiorcy. Wiele projektów realizowanych jest do szuflady. Projekty cyfrowe są realizowane na środowisko testowe. A tymczasem właśnie możemy się odkochać od naszych pomysłów dzięki temu, że wcześnie dostarczymy rozwiązanie do klienta docelowego. Czy to poprzez jakąś formę badań, czy to poprzez formę jakiegoś pierwszego wdrożenia i wsłuchamy się w to, co ten klient docelowy ma do powiedzenia? Co o tym sądzi, co jeszcze by się przydało? Jak realnie używa tego naszego produktu? Co nam otwiera dużo możliwych decyzji na temat tego, czy kontynuujemy nasze prace w pierwotnym pomyśle, ale może są nowe sugestie, nowe potrzeby. Odkrywamy, że w ogóle jest coś o czymś wcześniej nie pomyśleliśmy. Czyli podsumowując – kontakt z odbiorcą docelowym w toku prac też jest jedną z charakterystyk tego, czy pracujemy w sposób zwinny. Niezależnie od tego, czy mówimy o projekcie czy o rozwoju produktu.
Zanim przejdziemy do drugiej części mam pewien kawałek reklamowy. Jeżeli czujesz, że potrzebujesz poszerzenia tematów związanych ze zwinnością, to mamy dla Ciebie nową propozycję. Uruchamiamy z Jackiem unikalną usługę bezpośredniego wsparcia w postaci zdalnych konsultacji. Uzyskasz dzięki temu sto procent uwagi jednego z nas i wspólnie pogłębimy zarówno Twoją perspektywę, jak i przykłady z naszego dziesięcioletniego doświadczenia. Jeżeli szukasz czegoś więcej niż losowych porad w Internecie pochodzących od niezweryfikowanych autorów, porozmawiaj z nami. Gwarantujemy tylko konkrety z zaufanego i doświadczonego źródła. Więcej informacji i możliwość umówienia się znajdziesz na Porzadnyagile.pl/konsultacje.
Jacek: Wracając do tematu projektów i produktów, chcielibyśmy z Kubą pokazać, gdzie widzimy subtelne różnice między projektami, a produktami zwinnymi. No bo, ten cały poprzedni blok, można powiedzieć wskazał, co to naszym zdaniem jest zwinność. Możesz odnieść wrażenie, że tak naprawdę to nie ma to znaczenia czy to jest projekt, czy produkt. No bo skoro, któryś z tych aspektów, który wymieniliśmy są spełnione, no to w sumie jaka jest różnica? Stąd zebraliśmy kilka takich aspektów, które z naszej perspektywy charakteryzują podejście projektowe i podejście produktowe. Pierwsza główna różnica, to ja bym powiedział, że jest w miejscu, gdzie kładziemy akcent. W sensie, moje doświadczenie, jeśli chodzi o projekty – zarówno kiedy pracowałem jako Project Manager, czy też pracując z organizacjami, w których zarządza się projektami. To widzę, że w momencie, kiedy pracujemy nad konkretnym projektem – jest to jakiś jeden z wielu projektów, którymi będziemy się zajmować – istnieje dosyć duża pokusa, żeby skupić się w pracy na realizowaniu projektów z sukcesem. Z sukcesem w takim rozumieniu, że nie przekroczyliśmy budżetu, albo tylko nieznacznie został przekroczony. Z sukcesem, to znaczy, że dostarczyliśmy ten konkretny, czy zrealizowaliśmy ten projekt na czas, czy też nie przekroczyliśmy jakichś tam konkretnych przydzielonych do tego projektu zasobów. I to powoduje, że jakby produkt może ucierpieć na tym, że będziemy podejmować decyzje mające na celu doprowadzenia do sytuacji, w której projekt wygląda bardzo ładnie, bardzo dobrze. W sensie nikt nie może nam nic zarzucić. Trójkąt projektowy perfekcyjnie lśniący. Zrealizowaliśmy z sukcesem projekt. Natomiast wielokrotnie widziałem przykłady, w których na przykład takie zapewnienie, że projekt zostanie zrealizowany w czasie, było opłacone tym, że zespół bardzo mocno ciął po jakości, albo mocno przycinał zakres. Co powodowało, że de facto, no to rozwiązanie nie było takie, jak byśmy się spodziewali, ale mało kto na to zwraca uwagę, no bo wszyscy patrzyli jak ten projekt wygląda i jak został zrealizowany. Tak więc, tutaj w tym kontekście na szali jest z jednej strony taka tymczasowość projektu, który chcemy, żeby się fajnie zakończył – kontra takie długofalowe myślenie o sukcesie produktu, na przykład w postaci zaciągniętego długu technologicznego, który po prostu kiedyś będzie trzeba spłacić.
Kuba: Kolejna subtelna różnica – też wywodząca się z tego, co przed chwilą powiedziałeś, to taki niuans związany z definicją projektu, że projekt najczęściej oznacza – jeśli mówimy o projekcie takim cyfrowym, projekcie, który ma coś wytworzyć – no to projekt jest skończony po stworzeniu produktu. Czasem w niektórych podejściach w danej firmie jeszcze przewiduje się jakiś krótki czas zaraz po wdrożeniu, może jakiegoś rozkręcenia. Być może podłączenie jakichś klientów. Ale mimo wszystko – jest ta perspektywa, że wdrożenie jest tym finiszem, albo jednym z etapów końca prac. Natomiast podejście produktowej akurat tutaj nie jest aż takie wesołe. Podejście produktowe mówi, że koniec produktu jest wtedy, gdy produkt się zestarzeje. Co to znaczy zestarzeje? To w różnych produktach może być przede wszystkim czasowo bardzo różna perspektywa. Bo produkt na przykład, model danego telefonu komórkowego przez rok będzie może modny, po roku już zaczyna być już stary i już w szczególności firma, która go produkuje już raczej go wycofuje. Być może jeszcze przez chwilę go przecenia, może paru spóźnionych gości jeszcze się załapie na to, ale tak naprawdę trzeba go wycofywać z rynku. Tak, czy tak nawet używając tego przykładu telefonu komórkowego – w wielu przypadkach w podejściu projektowym, projektem byłoby wprowadzić nowy model na rynek. Natomiast zarządzenie produktem będzie oznaczało wprowadzić go na rynek, podtrzymać go przy życiu, być może poszukać jakichś modyfikacji, może jakichś rozszerzeń, albo chociaż wyciągnąć wnioski, gdy ten etap już końcowy się zbliża i trzeba się zastanowić jakim nowym modelem, jakim nowym produktem zastąpimy tą starą Nokię, albo ten stary model Ericssona, który do tej pory rozwijaliśmy. Tutaj jest takie wyjście naprzeciw, czy taka trochę kontra do punktu, o którym ty Jacek mówiłeś. Zarządzenie produktem bardzo często zwraca uwagę na takie rzeczy jak Total Cost of Ownership – w skrócie TCO, czyli ile nas kosztuje ten produkt, czy zarządzenie, czy własność tego produktu w całym okresie. No i wiele pomysłów, które mogą na etapie projektu przejść, że teraz przyoszczędzimy, a w przyszłości niech inni się martwią – w podejściu produktowym jest bardzo mocno niewskazane. Oczywiście organizacja może też zrobić szereg działań korygujących, na przykład standardy jakościowe wprowadzać, na przykład rozliczać sukces projektu z perspektywy zyskowności biznesowej. Ale z ręką na sercu, w praktyce rzadko to widzimy. No i tutaj obaj z Jackiem mocno o tym dyskutowaliśmy. No mimo wszystko ta optyka na koniec projektu i takie dążenie do tego, żeby projekt zrealizować w czasie, ale też w pozostałych założonych czynnikach – i tu nie mówię wcale negatywnie, bo też osiągnięcie rezultatu, który był przewidywany, czy potrzebowany często niestety powoduje, że patrzymy zbyt krótkoterminowo, zbyt krótką perspektywę sobie przyjmujemy.
Jacek: Kolejną subtelną różnicą między projektem, a produktem, to jest ten punkt, gdzie poświęcamy nasze skupienie. Bardzo często, kiedy obserwuję pracę projektową, to skupienie jest na stopniu realizacji konkretnego projektu. Czy to jest jakiś stopień realizacji wielu projektów w ramach jakiegoś portfela, czy nawet jakiegoś programu? Bardzo często to jest analiza alokacji osób w projekcie, kto już jest trochę wolny, kto jeszcze nie. Kogo gdzieś tam możemy przesunąć. Plus jakieś często to takie są wskaźniki w stylu, czy jest jakieś zagrożenie związanie z projektem. Przeróżne kolory się pojawiają – czerwony, żółty, zielony i tak dalej. Natomiast jakby w całej tej dyskusji bardzo mało jest rozmowy o faktycznych wskaźnikach, które by mówiły nam, czy w ogóle ten produkt, który wytwarzamy używając do tego mechanizmu projektowego – czy on się sprawdza na rynku, czy on przynosi rezultaty, czy na razie tylko wydaliśmy pieniądze, a produktu namacalnie nadal nie ma. Czy może wydajemy pieniądze, ale już to co nam spływa z rynku jako zapłata za używanie tego produktu, w pewnym stopniu już nam opłaca dalszy development? Tak więc, zwykle obserwuję skupienie w projekcie na wskaźnikach mówiących o tym, jak nam idzie proces realizacji. Natomiast w firmach, które decydują się bardziej takie zarządzanie produktowe, widzę więcej dyskusji o jakichś konkretnych wskaźnikach przypiętych do produktu. To są wskaźniki często bardziej finansowe, które mówią nam o tym jak zarabiamy, ile zarabiamy, jaka jest konwersja. Czyli takie wskaźniki bardziej z mojej perspektywy bardziej biznesowe i skupione na produkcie, a nie na samym procesie prac.
Kuba: Jak mówisz o wskaźnikach biznesowych, to rozszerzyłbym jeszcze oprócz tych finansowych, to też na przykład zwrócenie uwagi na satysfakcję klienta. Czy to będzie Net Promoter Score, czy to będą jakieś na przykład analizy konwersji – jeśli chodzi tam o kolejne lejki sprzedażowe w naszym produkcie? No, ale w każdym razie zwracanie uwagi o wiele bardziej na to jak produkt funkcjonuje, a nie jak nam idą prace. Kolejna z subtelnych różnic, które też byśmy chcielibyśmy tutaj wyróżnić, czy zwrócić na to uwagę – to rola lidera. W obu tych podejściach, to liderstwo może być w rękach różnych osób. W podejściu projektowym o wiele częściej spotykamy się z o wiele mocniejszym umocowaniem roli kierownika, koordynatora, lidera, managera – jakkolwiek nazwiemy. Osoba, która została powołana w organizacji do tego, żeby z sukcesem poprowadzić ten projekt. I wiele osób w bardzo w neutralny sposób, tak mniej więcej definiuje rolę PM-a, czy właśnie kierownika projektu, że no jesteś tutaj po to, żeby te projekty się działy. Żeby one miały rezultaty, żeby szły do przodu, żeby też ewentualnie było wiadomo, że są z tymi projektami problemy. Tutaj ta optyka tej osoby jest o wiele mocniej na to, żeby była sprawczość realizacyjna, powiązane z tym, co mówiłeś o tych metrykach, czy mierzeniu. Mierzymy. czy projekt idzie do przodu i też powołujemy osobę, którą mocno dopingujemy do tego, żeby te projekty szły do przodu. W podejściu produktowym oczekiwałbym, że liderstwo jest mocno położone w rękach osoby, która jest zarządzającym produktem. Czy to będzie jakiś dyrektor produktu, głowa produktu, Product Owner scrumowy. W każdym razie ktoś, kto ma decyzyjność w kwestii tego, gdzie ten produkt jest, w którą stronę zmierza. Podejmuje na końcu jakieś, być może odważne decyzje na temat trudnych czasami dylematów na temat tego, gdzie może iść nasz produkt. Natomiast nie oczekujemy od tej osoby, że będzie sprawiała, że rzeczy się dzieją w całej firmie. Raczej oczekujemy, że to będzie osoba, która albo sama podejmuje decyzje, albo tworzy zespół – pewnie to jest lepsze podejście, w którym podejmowane są mądre decyzje na bazie danych z rynku, i tak dalej i tak dalej. Czyli tutaj trudno byłoby na raz powołać i lidera produktowego i jeszcze jednocześnie lidera projektowego. No i tutaj podejście projektowe bardziej preferuje mocnych Project Managerów. Podejście produktowe będzie preferowało mocne osoby produktowe. Dużo refleksji na ten temat mieliśmy, nie wiem czy nie będzie nam ciężko teraz je wszystkie przywołać. Ale jest taka myśl i spróbuje ją powiedzieć z jak najmniejszym ładunkiem jakimkolwiek emocjonalnym. Są po prostu organizacje, które w dzisiejszym sposobie funkcjonowania, są przyzwyczajone do mocnej struktury. Mają też już bardzo dużo swojego normalnego biznesu, którym się zajmują obecnie istniejące struktury. No i tam podejście projektowe z mocną rolą lidera projektu – osobą, która też będzie sprawiała, że pewne rzeczy w tej organizacji się dzieją, że zmiana następuje – no to będzie najbardziej adekwatne podejście, jeśli patrzymy z perspektywy skuteczności pracy. Więc, to też nie jest tak, że tutaj niektórzy mogą mieć skojarzenia z tego, co mówimy, że może preferujemy którąś ze stron – tak prywatnie, pewnie tak. Ale rozumiemy też, że są konkretne firmy, w których podejście projektowe, dawanie mocnego liderstwa osobom zarządzającym projektem, po prostu są racjonalną decyzją na temat tego ze strony już samego topu zarządzania całą firmą, że jeśli chcemy, żeby w tej firmie się coś zmieniło, to być może – tu i teraz, gdzie jesteśmy, bez większych reorganizacji – to po prostu, to zarządzanie projektem jest tym sposobem, żeby sprawy szły do przodu.
Jacek: Tak podsumowując, cofnęliśmy się trochę do Przewodnika po Scrumie, żeby też złapać to ujęcie jak twórcy Scruma patrzą na projekt. Takie ciekawe zdanie, które możecie, czy możesz znaleźć w Scrum Guidzie, to jest zdanie, w którym mowa jest o tym, że sprint można uznać za projekt z określonym horyzontem. Jakby zakończenia, na zasadzie – początek i koniec. Trochę z Kubą o tym porozmawialiśmy na takiej zasadzie, że moje podejście przynajmniej jest takie, że bardzo często w podejściu zwinnym projekt jest traktowany w sposób taki negatywny, czyli, że projekty są nie dobre, a produkty są dobre. Jakby też o wiele bliżej mi jest personalnie do całej tej takiej koncepcji produktu, gdzie budujemy zespół wokół produktu, gdzie osoby są bardzo dobrze obeznane domenowo, zaangażowane. Jakby ustawiamy sobie świat, gdzie to produkt jest centrum. Natomiast niekoniecznie musi tak być. Jakby też sam widziałem wiele organizacji, które były zorientowane produktowo i to nie działało dobrze. Jednocześnie wyobrażam sobie organizację, która może funkcjonować projektowo. Jakby zważając na to wszystko, co powiedzieliśmy wcześniej o tym jak można zwinnie prowadzić te projekty i to też może funkcjonować. Czyli jakby tutaj ta końcówka tej naszej dyskusji, ale też ten cały proces przygotowywania się, był bardzo wartościowy z takiej perspektywy, żeby sobie bardzo dobrze przepracować temat, co może działać, w jakich okolicznościach i dlaczego.
Kuba: Ja spróbuję dowalić do pieca. Zarówno mogą istnieć niezwinne rozwoje produktu, czyli kompletnie niereagujące na potrzebę klienta. Kiszące przez długi czas jakieś tam półprodukty niewypuszczane na rynek. Zakochane w swoich pierwotnych pomysłach, też bardzo z jakimiś toksycznymi podejściami do pracy w zespole. No i jak niezwinne projekty. Te akurat trochę prościej sobie wyobrazić, bo to jest zawsze podejrzany, czy taki chłopiec do bicia. Niezwykle prosto nam wyjaśnić Scruma poprzez zmaganie złego projektu z tyranem – Project Managerem i mało racjonalnym komitetem sterującym. Natomiast fakty są takie, i to też warto sobie uświadomić – w zależności od tego, w której perspektywie jesteśmy – czy o wiele bardziej projektowej czy produktowej. Dla nas, takim bardzo ważnym podsumowaniem tego odcinka jest to, że w firmie mocno projektowej mogą istnieć produkty, i po prostu są powody, że pomimo że mamy produkty, rozwijamy je projektami – ale w firmie mocno produktowej można użyć projektu, można użyć narzędziówki zarządzania projektem, można tworzyć zespoły projektowe. Zwłaszcza najwięcej miejsca na to jest, gdy jesteśmy na tym etapie w ogóle tworzenia produktu, tworzenia zrębów zespołu, tworzenia struktur. Wytwarzania samego produktu, czy być może wprowadzania go na rynek. Tam może się okazać, że te narzędzia, które być może niektórym zbyt pryncypialnie czy religijnie kojarzą się z tym zakazanym Waterfallem. Tak naprawdę to nie w Waterfallu jest problem, tylko w złej realizacji tych narzędzi, które zarządzanie projektami często ma w sobie. Natomiast każdemu Scrum Masterowi, każdemu Agile Coachowi, nie jednemu Product Ownerowi polecę zapoznanie się z narzędziami związanymi z zarządzaniem projektami i zastanowienie się jak to zrobić jak to zrobić, żeby pracować zwinnie nad swoim rozwojem produktu, czy realizować projekty w sposób zwinny.
Jacek: I do takiej refleksji też na temat czym są projekty, czym są produkty, jak sensownie z tych podejść korzystam – zachęcam Cię. To by było wszystko na dzisiaj. Dzięki Kuba.
Kuba: Dzięki Jacek.
Jacek: I do usłyszenia.
Kuba: Wkrótce.
