Przez kilkanaście lat pracowałem bez PO. Dlaczego? Bo to był turkus, wspólnie pracowaliśmy w małym zespole. Natomiast, kiedy proces IT się skomplikował (ot tak samo z siebie), pojawiła się potrzeba również specjalizacji biznesowej. O tym tu przeczytasz.

Role w projekcie informatycznym

Kiedy zaczynałem w 2005 nie było podziału ux/ui/backend/frontend/devops – był programista. I tak do roku 2014 trwałem w tej świadomości, że jest to OK. Wtedy odybłem kilkanaście lotów do UK na rozmowy o pracę, gdzie zobaczyłem zupełnie inny świat programowania: frontend, backend, testy jednostkowe, bardzo duże nastawienie na jakość, stabilność i inżynierię oprogramowania.

Zacząłem się tym interesować i w roku 2017 zacząłem pracować jako Fronted Developer, wykonując też inne czynności, jak backend, devops, scrum master. Zobaczyłem wielką machinę marnotrawstwa zasobów, długich spotkań, nieefektywnych procesów. Poznałem, jak pracuje się za granicą, powoli, spokojnie, jest czas i tak dalej. Zrozumiałem, że pewna złożoność wymaga innego podejścia.

W ten sam sposób urosła biurokracja na stanowiskach operacyjnych. Jest PM (Project Manager), PMO (Project Manager Officer), PO (Product Owner), AC (Agile Coach), SM (Scrum Master), Team Leader, Lider Techniczny  Architek, Analityk Biznesowy itp.

Pion Biznesowy – Dlaczego PO?

Z uwagi na skomplikowany proces informatyczny, do stworzenia produktu potrzeba wiecej osób. Wymagania klientów też rosną, a oczekiwanie prostych rozwiązań na skomplikowane problemy wymaga sporego nakładu pracy. Pion biznesowy/operacyjny też się rozrósł, głównie z tego powodu. 

Inaczej się pracuje, gdy mamy 3 specjalistów, a inaczej gdy takich osób jest 30. Są wymagane inne narzędzia. Agile mówi o małych zespołach, moje doświadczenie mówi o max. 4 osobach, które są w stanie pracować spójnie nad jednym problemem. Każdy taki “mini zespół” w większych strukturach tworzy silos i potrzebuje wsparcia w rozumieniu produktu i dalszych krokach.

Dlatego Pion Biznesowy, potrzebuje Product Ownera, osoby, która jest niezależna i asertywna, ma jasną wizję rozwoju i może przewodzić takim mikro zespołom w pomaganiu zrozumienia potrzeb klientów. 

W tej infografice zobaczymy strukturę skupienia w projekcie i to jak różnice mogą być widziane role PM oraz PO. 

Obowiązki projektowe Product Ownera

W każdym projekcie są potrzebne kompetencje finansowe, zarządcze jak i merytoryczne. Kluczowymi pytaniami, jest “Po co?” i “Dlaczego?” i tutaj jest najtrudniej znaleźć odpowiedź. I na tym bym mógł zakończyć. Natomiast odpowiadając na pytania “Po co” dochodzimy do decyzji o tworzeniu pewnej części systemu i tutaj pojawia się “Koszt”, a jak kosz to i zarządzanie budżetem.

W małych projektach wtedy rola PO/PM zazwyczaj jest w jednej osobie, więc sytuacja jest bardzo prosta. Osoba zarządzająca budżetem, zarządza kolejnością realizacji zakresu i bierze za to odpowiedzialność. 

W dużym projekcie już jest inaczej. Duże projekty, są to miejsca, gdzie zazwyczaj znajduje się Scrum Master, dlatego dalsza część artykułu będzie się skupiać właśnie na tym kontekście.

Kompetencje sprzeczne

Co powinno być realizowane pierwsze? Dług technologiczny? Rozwój oprogramowania? Czy pisać testy jednostkowe? Gdzie jest balans pomiędzy techniczną jakością oprogramowania a tworzonymi funkcjonalnościami. Dodatkowo dochodzą do nas wymogi klienta i organizacji. 

Dołóżmy do tego specjalistów, którzy chcą wykonywać swój zawód na możliwie najwyższym poziomie i plany wydań.

Tego wszystkiego w projekcie nie jest w stanie ogarnąć jedna osoba, a aby podjąć pragmatyczną decyzję należy znać każdy aspekt projektu.

Scrum Master i Scrum

No i tutaj pojawia się pewien styl pracy “Scrum”. Na rosnącą złożoność, potrzeba nowych metod, nowego słownictwa, aby się lepiej zrozumieć. Scrum Master jest odpowiedzialny za tworzenie środowiska, w którym Product Owner ma możliwość układania pracy w skomplikowanym problemie. 

Oznacza to, że Scrum Master współpracuje z PM jak i z PO oraz z Developerami. Przejmuje na siebie ogarnianie procesu pracy pozwalając PO skupić się na merytoryce, w branży zwanej domeną. 

Dokładnie tak – aby PO mógł spokojnie działać, potrzebuje Scrum Mastera, czyli osoby zajmującej się ułożeniem procesu pracy, pomocy w organizacji dnia, wsparcia w komunikacji ze specjalistami.

Te role nie muszą się tak nazywać, kiedy nie pracujemy “w Scrum” , natomiast chodzi o to, aby osoba skupiona na zakresie pracy nie musiała też skupiać się na tym, czy komunikacja jest poprawna. Często taka osoba wspiera w technicznym aspekcie wykorzystania narzędzi a kompetencje techniczne scrum mastera opisuję tutaj.

Zmiana procesu pracy

Mamy moment przełomowy. Kiedy znamy już poziom skomplikowania i widzimy problemy w łączeniu domenowych i finansowych kompetencji powinniśmy pomyśleć o zmianie procesu pracy. Czyli jak oddzielić Kierownika Liniowego, Project Managera i Product Ownera.

Tutaj pomoże Scrum Master, który z pomocą swoich magicznych karteczek i facylitacją procesu pomoże ustalić wewnętrzny proces podziału obowiązków. 

Zazwyczaj Kierownik Liniowy odpowiada za sprawy kadrowe i rozwojowe osoby, Project Manager – biznesowe ujęcie pracy, a Product Owner – za kolejność wykonywania zakresu pracy.

Efektywność zamiast produktywność

Kluczem w tej kolejności jest efektywność. Czyli najbardziej optymalne wykorzystanie posiadanych możliwości. Podstawą pracy PO jest posiadanie pewności, że to, co jest aktualnie realizowane, ma największy sens.

Dawny styl zarządzania, pochodzący z fabryki stali (Gantt) zakłada, jako nadrzędny cel, najlepsze wykorzystanie zasobów.  

Przy pracy abstrakcyjnej, twórczej, kluczem efektywności jest najdłuższy możliwy czas pracy w skupieniu. Przykładowo, spotkania w trakcie dnia, mogą wybić z rytmu pracy, a tracąc jeden dzień, możemy stracić cały tydzień. Piszę te słowa jako osoba, która przepracowała jako programista ponad 15 lat. Nie jestem teoretykiem starającym się robić problemy devom.

Obowiązki PO

No i tutaj na wjeżdża nam PO. Rozumiejąc, jak pracują specjaliści w kreatywnym otoczeniu, jak bardzo skomplikowana jest to materia, dobiera kolejność pracy, aby efekty był maksymalnie efektywny, czyli optymalny. Taka osoba rozumie potrzeby interesantów, czyli osób, które płacą, używają i czekają na kolejne wersje produktu.

Ta grafika pokazuje, że w momentach przestoju, należy wykonywać mniej wartościowe, elementy z listy wymagań, i ktoś powinien ponosić odpowiedzialność, bo to są przecież koszta.

PO przy tym nie skupia się na czynniku, kto ile zarabia, który dev ma jaką efektywność, ile wynosi czas pracy w dniach/godzinach konkretnego programisty nad zadaniem X. 

Skupia się tylko na sensowności kolejności wykonywania działań, mając na uwadze złożoność procesu.

Obowiązki PM

W tej sytuacji PM dba o środowisko, o zasoby potrzebne do realizacji. Sytuacja z życia, potrzebne większe zasoby na serwerze, zespół informuje o blokadzie, PO reaguje i “załatwia zasoby”. Platform Manager, Project Manager, osoba odpowiedzialna za koszty reaguje, “załatwiając” większą inwestycję w sprzęt.

Od czasu zgłoszenia potrzeby na zasoby do ich dostarczenia może minąć i tydzień.

Co w tym czasie ma robić zespół? Tutaj znów wracamy do PO, z zakresu projektu, dogaduje się z developerami na temat tego co można robić. Czy funkcjonalności niewymagające zasobów, czy może realizować dług technologiczny, albo opracować przyszłe wymagania od strony technicznej. 

Jednym słowem – “kapelusz” PM jest do nakładany w przypadku konieczności finansowych, operacyjnych na poziomie projektu.

Ryzyko łączenia

Kiedy mamy styczność z inteligentnymi i utalentowanymi osobami, nie ma ryzyka łączenia. Takie istoty są ambitne i dociekliwe dlatego skrupulatnie wykonają pracę. Jednak w większych projektach struktura może wyglądać bardzo inaczej.

PM ma wiele obowiązków finansowych, a PO w postaci kilku Analityków Biznesowych obsługuje wspólnie kolejność. Oczywiście istnienie “Głowny PO” ale to rola organizacyjna, a nie decyzyjna.

Po prostu, ryzyko się pojawia gdy istnieje konieczność poświęcenia więcej czasu aniżeli jest to możliwe dla jednej osoby. Proste?

Dobrze obrazuje tu rozkład odpowiedzialności w rozdzieleniu na konkretne osoby.

Dostarczanie Wartości

Tutaj prezentuje 4 elementy, związane z efektywnością, niepewnością, ryzykiem i kosztami. Jako “PLUS” zaznaczam tylko działania związane z kodowaniem, coś jak gra w zielone/czerwone w lean albo cycle time/lead time w kanbanie. Otóż w procesie wytwarzania oprogramowania jedyną czynnością dodającą wartość to “kodowanie”. Już nie nawet programowanie, czyli kreatywna czynność, tylko dodawanie kodu, z którego powstają funkcjonalności.

Oczywiście nie ma kodowania, bez analizy, czynności “programowania”, obmyślania rozwiązań, dlatego nie zaznaczam ich jako “waste” albo “MINUS”, tylko jako konieczne czynności do wykonania “PLUS”.

Współpraca

Kontekst, jaki opisuję, porusza duże projekty, minimum 50 osób na pokładzie. Jest to skala, w której pojawiają się tarcia pomiędzy PM a PO. Po prostu, przy tylu osobach, jest tyle problemów, i tyle miejsc styku komunikacji, że wymagane są oddzielne osoby.

Podstawą jak zawsze jest komunikacja i ramy kompetencji, decyzji.

To właśnie w takich zespołach poszukuje się scrum mastera, czyli osoby, która podejmuje się pomocy w procesie, zazwyczaj dążąc do pracy w ramach scrum albo będąc osobą na posyłki czy to PO czy PM, albo co najgorsze robiąc wszystkiego po trochu.

Ale to inny temat.

Podsumowanie

W małych projektach, gdzie poziom skomplikowania jest niski (np mniej niż 20 osób) takie rozważania raczej nie mają miejsca. To kompleksowość rozwiązań, zależności, liczba komunikatów, dojrzałość klienta wymagają, aby z jednej osoby Kierownik, wyłoniły się specjalizacje, PO, Scrum Master, Architekt, Lider Frontend, Lider Backend.

Czasem jest tak, że projekt powoli rośnie, dochodzą nowy specjaliści, a dział operacyjny zostaje taki sam. PM jest rozważany jako PO, czy SM, na barki jednego człowieka spada bardzo dużo odpowiedzialności. Tym artykułem chciałem wskazać na ten kontekst, bo to jest zazwyczaj sytuacja, gdy zatrudnia się Scrum Mastera. Czasem nawet prędzej niż PO.