Przejdź do treści

Od menedżera do właściciela produktu

darth_vader_product_ownerDzień był szary, deszczowy i mglisty. Wystarczyłaby chwila spojrzenia na zasłonięty mgłą świat, aby zadumać się nad jesienią, przemijaniem i sensem… Na szczęście nikt w wielkim budynku biurowca nie miał czasu na patrzenie za okno – klimatyzacja utrzymywała stałą temperaturę 22 stopni Celsjusza, grube szyby broniły przed deszczem, a ludzie wpatrzeni byli w niebieskie ekrany monitorów, które wyświetlały raporty, maile, kody oraz – od czasu do czasu – zdjęcia małych kotków.

Do pokoju Stefana, młodego i zdolnego menedżera projektu, wszedł dyrektor działu rozwoju oprogramowania, przysunął sobie krzesło, usiadł na nim i powiedział tak:

– Słuchaj, jest taka sprawa. Centrala chce bardzo, żebyśmy byli adżajl i żebyśmy teraz projekty robili w skramie. Wybraliśmy twój projekt jako pilotaż, bo kiedyś mówiłeś, że coś o tym słyszałeś. Także zróbcie szybko tego skrama, wprowadźcie te biegi czy sprinty. Oczywiście cała zmiana nie może mieć wpływu na budżet – jest już ustalony z klientem, terminy są napięte, także nie możemy już niczego przesuwać. Tak za miesiąc potrzebuję prezentacji, która podsumowuje zalety skrama, będzie to rekomendacja dla pozostałych projektów.

Zanim Stefan zdołał unieść opadniętą szczękę, dyrektor wstał i skierował się do drzwi. Stefan szybko opanował się i zdołał jeszcze wykrztusić:

– Ale do tego będziemy potrzebować innej współpracy z klientem, trzeba go wciągnąć w planowanie, w sam framework, musimy mieć Właściciela Produktu…

– Stefan, sam wiesz, jaka jest sytuacja w projekcie. Sam wiesz, z kim ostatnio musimy negocjować. Nie możemy teraz powiedzieć klientowi, że jeszcze czegoś od niego wymagamy. A jak potrzebujesz tego, no, właściciela, to najlepiej sam nim zostań – przecież najlepiej wiesz, co musicie zrobić w projekcie!

Powyższa scenka jest wymyślona. Natomiast czasami naprawdę zdarza się sytuacja, kiedy Stefan, który do tej pory zarządzał zadaniami osób w zespole (i tak naprawdę nie ma większego znaczenia, czy robił to ze stanowiska kierownika zespołu czy menedżera projektu), nagle i nieoczekiwanie zostaje scrumowym Właścicielem Produktu. Kim jest właściciel produktu? Scrum Guide definiuje, iż jest to jedyna osoba jest jedyną osobą zarządzającą Backlogiem Produktu, czyli tak naprawdę definiująca i priorytetyzująca wszystko to, czym zespół ma się zajmować (więcej na ten temat znajdziemy w na stronie 5 Scrum Guide’a). Co się wtedy zmienia w życiu Stefana? Najkrócej mówiąc: wszystko.

Ale zacznijmy od początku. Załóżmy, że mamy kilkuosobowy zespół, który pracuje nad projektem. Naturalnym podejściem, które stosuje wiele organizacji, jest podział zadań między członków zespołu: Franek przygotowuje schemat bazy danych, Łukasz zajmuje się komunikacją z zewnętrznym modułem, a Andrzej tworzy interfejs użytkownika. Jak Franek skończy swoje zadanie, to zostanie mu przydzielone następne – i tak się to wszystko toczy.

Gdzie w tym całym układzie jest Stefan, który jest menedżerem czy liderem projektu? Tak naprawdę wszędzie. Definiuje zadania, tworzy jakiś harmonogram projektu, sprawdza czy terminy wykonania zadań będą dotrzymane, czasami pomaga członkom zespołu w wykonaniu tych zadań – albo osobiście, albo przydzielając do zadania dodatkowe osoby. Czasami również dookreśla wymagania lub wprowadza jakieś kryteria jakościowe. To na ile Stefan własną ręką wykonuje te zadania, zależy głównie od kompetencji i od samodzielności zespołu. W zespole samych zielonych świeżynek trzeba się mocno napocić nad koordynacją ich pracy. W dojrzałym i kompetentnym zespole często wystarczy rzucić hasło „musimy zrobić to i to”, a zespół sam już zabiera się za dekompozycję i wykonanie projektu. Jeżeli zadanie jest ciekawe i atrakcyjne – to istnieje duża szansa, że je szybko i sprawnie wykonana. Ale nawet gdy zespół jest samodzielny i zmotywowany, to nie zwalnia to Stefana z odpowiedzialności za dostarczane rezultaty.

Nagle zjawia się jakiś impuls do zmiany, chcemy coś poprawić i wprowadzamy Scruma. Zadania przestają być przypisane do poszczególnych osób. Za to zaczynają być przypisane do timebox’ów sprintowych – „te cztery rzeczy robimy w tym sprincie, a tamte zmiany powinny być zrobione w następnym”. A Stefan z menedżera staje się właścicielem produktu.

Pierwszą zmianą w życiu Stefana jest to, że znika element przydzielania zadań do osób. To zespół dostaje w sprincie do wykonania zestaw zadań i zespół sam decyduje, kto czym się będzie zajmował. Znika również pilnowanie terminów wykonania zadań – wszyscy wiedzą, kiedy się kończy sprint i co powinno być w nim ukończone. Praca przy pomaganiu członkom zespołu również powinna być zminimalizowana – po to zespół dzieli się zadaniami i rozmawia o bieżących pracach podczas codziennych scrum’ów, aby sobie wzajemnie pomagać.

Z zadań, które zostają, najważniejsze jest porządkowanie backlogu produktu. To Stefan odpowiedzialny jest za właściwe zdefiniowanie i uporządkowanie zadań. Co więcej, często zespół będzie wymagał od Właściciela Produktu więcej informacji o zadaniach niż od menedżera. W rozmowie o zadaniach może również pojawić się zupełnie nowe pytanie: „po co my właściwie wykonujemy to zadanie, jaki jest jego sens” – i Stefan musi umieć na nie odpowiedzieć.

Ujmując to jednym zdaniem: Stefan przestaje się przejmować tym, jak pracuje zespół, a zaczyna mocno się przejmować tym, co zespół ma robić.

Tak naprawdę współpraca Stefana z Zespołem Deweloperskim jest skoncentrowana na początku i na końcu sprintu. Na początku definiuje, co powinno być w sprincie wykonane. Na końcu – odbiera pracę i udziela informacji zwrotnej. To oczywiście nie znaczy, że Stefan musi zniknąć w trakcie sprintu – dobrze, jeżeli będzie dostępny i będzie udzielał zespołowi na bieżąco odpowiedzi na ewentualne pytania oraz wątpliwości. Może być również proszony o renegocjację zakresu sprintu. Ale w trakcie sprintu Właściciel Produktu ma zdecydowanie mniej pracy niż menedżer.

Jednak nie wszystkie zmiany są dla Stefana tak przyjemne. Pierwsze poważne zaskoczenie może czekać go przy planowaniu sprintu…

– Słuchajcie, zaczynamy nowy sprint i chciałbym żebyście zrobili w nim te trzy zadania: rozdzielili bazę na dwie instancje, stworzyli skrypty synchronizujące i dodali prosty mechanizm monitoringu.
– Stefan, ale to rozdzielenie baz to będzie niezła jazda. Jesteśmy w stanie to zrobić, synchronizację też możemy zrobić, ale z monitoringiem już nie zdążymy.
– Ale przecież to jest proste, przecież tylko przejrzycie tabele, gdzie która ma trafić i potem to już będzie proste przenoszenie. Można to załatwić jednym skryptem. No nie mówicie mi, że to wam zajmie więcej niż dwa dni!
– A co jeżeli jakaś tablica będzie potrzebna w obu instancjach? A co jeżeli trzeba będzie przeciąć jakąś tabelę na pół? Wolimy to zrobić wolniej, ale porządnie.
– Słuchajcie, ale ja naprawdę potrzebuję tego monitoringu już teraz, bez niego produkcja nie ruszy!
– To zdecyduj się, czy ważniejszy jest dla ciebie monitoring czy synchronizacja…

Podczas planowania nagle okazuje się, że to nie Stefan decyduje, jak wiele zadań zespół bierze do wykonania w sprincie. Tylko i wyłącznie Zespół Deweloperski decyduje, co jest w stanie osiągnąć w sprincie. Jeżeli Stefan ma wiedzę merytoryczną w temacie, jeżeli wcześniej wyznaczał członkom swojego zespołu zadania i terminy – może być to dla niego sytuacja trudna. Może on uważać, że zespół byłby w stanie zrobić więcej czy pracować szybciej – tymczasem zespół podejmuje decyzję „weźmiemy mniej”.

Drugie zaskoczenie może czekać Stefana podczas sprintu, kiedy zespół musi podjąć jakąś decyzję – czy to techniczną, czy organizacyjną. Stefan może mieć własny pomysł, może uważać go za najlepszy w świecie, może być również przyzwyczajony do tego, że wcześniej narzucał takie decyzje zespołowi. Nic z tego – teraz to zespół podejmuje decyzję. Można mu coś podpowiedzieć, coś zasugerować – ale nie można mu nic narzucić.

Trzecie i największe zaskoczenie pojawia się w momencie, gdy w projekcie pojawia się nieoczekiwane i pilne zadanie.

– Franek, produkcja nam zgłosiła, że w monitoringu jest błąd i nie są wyrzucone alarmy o zgubionych transferach. Musisz to szybko poprawić!
– Czyli wpiszesz to do backlogu na następny sprint?
– Ale do jakiego backlogu, człowieku, to błąd produkcyjny, gubimy transfery, trzeba to naprawić już teraz! Jutro będzie za późno!
– Już teraz, mówisz… To które zadanie ze sprintu wyrzucimy, żebym mógł to zrobić?

W modelu klasycznym Stefan idzie do Franka i mówi: „słuchaj, do jutra poprawić monitoring”, a Franek odpowiada „tak jest, zabieram się do roboty!”. Menedżerzy z reguły uczeni się szybkiego reagowania na sytuacje wyjątkowe. Jeżeli dzieje się coś nieoczekiwanego, to zadaniem menedżera jest rozwiązanie tego problemu – kiedy się nam coś sypie w systemie, to trzeba jak najszybciej znaleźć osobę, która to obsłuży. Ale teraz zasady gry się zmieniły – albo zadanie wędruje na następny sprint, albo negocjujemy zakres sprintu. Dla Stefana jest to sytuacja mocno niekomfortowa i kontrintuicyjna – musi tutaj zadziałać wbrew swoim wcześniejszym przyzwyczajeniom i nawykom. A to jest trudne.

Scrum nie daje tutaj jasnej recepty, która byłaby lekarstwem na całe zło. Najważniejsze wydaje się wypracowanie zasad, które będą akceptowalne i dla Stefana, i dla zespołu. Określenie w jakich warunkach zespół bierze wrzuty na klatę, w jakich je przerzucamy na następny sprint, a w jakich przerywamy sprint, bo nie ma sensu ciągnąć go dalej. Ale żeby do takiego konsensu doszło, trzeba najpierw zrozumieć wzajemnie swoje argumenty – Stefan musi zrozumieć, że minimalizacja wrzut zwiększa szanse zespołu na osiągnięcie celu sprintu, pozwala zespołowi skupić się nad zadaniami, które są przez niego spiorytetyzowane. A zespół musi zrozumieć, że krytyczne problemy produkcyjne musimy rozwiązywać bardzo szybko, bo inaczej przestaniemy mieć pracę. I wtedy rodzi się szansa na porozumienie.

Oczywiście takie porozumienie ma szansę zadziałać dopiero wtedy, gdy takie sytuacje alarmowe nie zdarzają się zbyt często. Jeżeli niemalże każdy sprint jest przerywany przez nagłe poprawki i zespół regularnie nie dowozi celu sprintu – to tak naprawdę powinniśmy się skupić na tym, dlaczego mamy tak dużo wrzut, a nie na próbach nieskutecznego planowania.

Kiedy Stefan wyjdzie już z pierwszego szoku („Nie mogę im kazać tego zrobić? Jak to możliwe?!”), najczęściej przychodzi czas na refleksję. Czasami menedżer broni swoich poprzednich uprawnień do ręcznego sterowania, mówi że cały ten Scrum jest bez sensu, utrudnia pracę i obniża elastyczność zespołu. A czasami odnajduje się w nowej roli i zaczyna dostrzegać, że i bez jego doglądania Zespół Deweloperski potrafi działać sprawnie i skutecznie.

Jedno jest pewne – przejście z roli menedżera do Właściciela Produktu nie jest proste i nie każdy Stefan będzie potrafił odnaleźć się w nowej roli.

2 komentarze do “Od menedżera do właściciela produktu”

  1. William of Baskerville

    Zgadzam się z ostatnim akapitem. Czy dany Stefan odnajdzie się w nowej roli, będzie tak naprawdę zależało od tego, czy ambicja i charakter a także zawodowe ego pozwolą mu przeistoczyć się z zarządcy zespołu w jego partnera. A jeśli dla Stefana nadrzędnym dobrem jest sukces projektu, to nie powinien mieć z tym problemu. Jeżeli natomiast bardziej zależy mu na splendorze kierownikowania, to jego przełożeni powinni zastanowić się, co tak naprawdę taki Stefan wnosi do organizacji.

    Sam Scrum nie jest lekarstwem na całe zło tego świata, o czym niektórzy (via dyrektor z opowieści na wstępie) zdają sie zapominać. Taki styl wprowadzania wszelkich zmian – zróbmy to tak, bo inni tak robią / bo tak kazała nam firma, która zrobiła nam audyt za wagon euro – jest zupełnie bez sensu, gdyż w większości przypadków rodzi tylko opór i potęguje niezrozumienie sensu zmian wsród szeregowych pracownikow.

  2. Bardzo dobry artykuł. Rzeczywiście oddanie roli decyzyjnej odnośnie tego co ma być zrobione w sprincie zespołowi bywa wyzwaniem dla kierownika. Przy dobrych i zaangażowanych fachowcach nie ma z tym problemów (zazwyczaj lepiej wiedzą ile czasu może coś im zająć). Zdarzają się też jednak takie składy, które nadużywają zaufania i biorą mniej bo tak im wygodniej, lub opłacalniej (szczególnie na outsourcingu). Czasem zespół mocno stawia na jakość kosztem zakresu. Znalezienie balansu pomiędzy wartością biznesową sprintu, a jakością wykonania nie jest trywialnym zagadnieniem i wydaje mi się, że Product Owner powinien mocno pracować nad argumentacją , aby zespół nie popadł w drobiazgowość.
    Zazwyczaj to kierownik ma też wiedzę i doświadczenie pozwalające ocenić co jest ważne, kosztowne, zbyt czasochłonne, sprzeczne z celami innych projektów itp. Dlatego wyłączenie kierowników z planowania sprintów nie koniecznie jest optymalne z punktu widzenia całej organizacji.
    Świetnie ujęty problem serwisu w projektach Scrumowych. Ja zazwyczaj uczulam zespół że powinni założyć jakiś bufor w sprincie na nieprzewiziane zgłoszenia (wielkość bufora zależna od jakości produktu).
    Chętnie poczytałbym rad na temat przeciwdziałania prawu Parkinsona w projektach Scrumowych (https://pl.wikipedia.org/wiki/Prawo_Parkinsona). Zetknąłem się niestety z sytuacjami „przewożenia” historyjek ze sprintu na sprint jeśli nie budowane było odpowiednie „ciśnienie” na ukończenie projektów ze strony kierowników.

Skomentuj William of Baskerville Anuluj pisanie odpowiedzi

Twój adres e-mail nie zostanie opublikowany. Wymagane pola są oznaczone *

Witryna wykorzystuje Akismet, aby ograniczyć spam. Dowiedz się więcej jak przetwarzane są dane komentarzy.