Jedną z wielu zalet metodyk zwinnych jest fakt, że umożliwiają skalowanie i są podatne na wprowadzanie rozszerzeń (ScrumAnd) usprawniających komunikację. Dobrym tego przykładem jest powołanie Product Ownera po stronie dostawcy IT. Czy sprawdzi się to w twoim projekcie?
Zarządzanie projektem IT: przez nas czy przez nich?
Kiedy Product Owner (PO) umiejscowiony jest po stronie klienta, zespół deweloperski może tracić odpowiedzialność za czasowe ramy projektu, a bieżąca komunikacja i priorytetyzowanie zadań jest utrudnione. W kliencie jednak obawy często wzbudza powołanie PO niebędącego na co dzień pracownikiem jego firmy. Najwięcej wątpliwości budzi to, czy będzie on w stanie pełnić specyficzne obowiązki PO i dbać jednocześnie o potrzeby produktu. Problem jest złożony i powinien być rozpatrywany z uwzględnieniem specyfiki projektu i obu organizacji. Warto wziąć tutaj pod uwagę stopień dojrzałości organizacji w stosowaniu metodyk zwinnych.
Product Owner po stronie klienta: najczęstsze problemy
Chociaż poniższe problemy wydają się dotykać głównie zespołu deweloperskiego, z perspektywy całościowej cierpi na tym cały projekt. Z jakimi wyzwaniami najczęściej przychodzi się mierzyć w przypadku projektów, w których Product Owner jest po stronie klienta?
- Komunikacja utrudniona ze względów czasowych – rzadko kiedy PO może w pełni poświęcić się obowiązkom wynikającym z jego roli. Najczęściej jest to dodatkowe zajęcie, które powinien godzić z dotychczas pełnionymi obowiązkami. W praktyce oznacza to, że PO permanentnie nie ma czasu dla zespołu deweloperskiego, a jego aktywność sprowadza się do bycia dostępnym dla interesariuszy. Zamiast backlogiem produktu, PO w takiej konfiguracji zajmuje się priorytetowo obowiązkami związanymi z jego głównym stanowiskiem, a funkcję PO traktuje jako mniej istotną.
- Brak kompetencji Product Ownera – funkcja PO jest często nadawana osobom, które są specjalistami w innych dziedzinach – były rekrutowane na stanowiska, w których znajomość specyficznej roli PO nie jest wymagana. To może prowadzić do nieporozumień we współpracy z zespołem deweloperskim, który sprawnie funkcjonuje w metodyce zwinnej.
- Różnice w interpretacji Agile – każda firma posiada własną kulturę pracy i interpretację metodyki zwinnej, co w przypadku projektów związanych z produktami cyfrowymi jest szczególnie istotne. Na sposób postępowania Product Ownera wpływa rodzaj organizacji, z której się wywodzi, a w której metodyka zwinna stosowana jest zazwyczaj nie w całości (ScrumBut) lub zamiennie z typowym zarządzaniem kaskadowym. W praktyce, gdy przychodzi do współpracy z zespołem, dla którego Agile jest naturalnym i jedynym sposobem współdziałania, powstają konflikty i nieporozumienia.
- Relacje, kultura i język – dobrze funkcjonujący zespół składa się z ludzi, których łączy relacja, a tę najłatwiej zbudować w bezpośrednim kontakcie. Product Owner niewspółpracujący na co dzień z zespołem deweloperskim może napotykać trudności w kontaktach z poszczególnymi członkami zespołu. Jeśli dodatkowo zachodzą różnice wynikające z posługiwania się innymi językami, przebywania w innych strefach czasowych i kulturze – problem może eskalować.
Product Owner po stronie dostawcy – co zyskujesz?
Coraz częściej spotykanym rozwiązaniem dla wyżej wymienionych problemów jest umiejscowienie PO po stronie dostawcy. Niekiedy rola ta nazywana jest Proxy Product Ownerem, a przy projektach, w których skalowanie jest niezbędne dla zachowania flow, wydaje się to być jedyne skuteczne rozwiązanie. Co możemy zyskać wprowadzając taką konfigurację?
- Stała dostępność PO – najczęściej współpracuje on wraz z zespołem deweloperskim w tej samej lokalizacji i w tych samych przedziałach czasowych. Umożliwia to bieżącą komunikację zarówno w zakresie zadań z backloga, jak i nadawanie im kontekstu biznesowego “na miejscu”.
- Jeden backlog, jeden Product Owner – tylko w takiej konfiguracji ta złota zasada Agile ma szansę na wprowadzenie jej w życie. PO po stronie dewelopera w pełni poświęca się pełnionej roli, nie dzieląc jej z innymi obowiązkami. To rozwiązanie niweluje stres spowodowany przydzieleniem funkcji PO pracownikowi po stronie klienta.
- Relacja i motywacja – PO pracujący z zespołem deweloperskim, dostępny, komunikatywny i znany jego członkom, ma szerokie możliwości w zakresie ich motywowania i pozytywnego wpływania na wydajność ich pracy.
- Partnerstwo – gdy zostają usunięte przyczyny konfliktów wymienione wyżej, współpraca między klientem a dostawcą przechodzi na wyższy poziom. Z perspektywy klienta zewnętrzny zespół deweloperski wywiązujący się z ustaleń, doskonale zmotywowany przez zaangażowanego Product Ownera staje się nie tyle wykonawcą, co partnerem w tworzeniu produktu.
Kiedy warto powołać proxy Product Ownera?
Jeśli dotychczasowy sposób prowadzenia projektów nie spełniał naszych oczekiwań i zauważyliśmy występowanie wyżej wymienionych problemów – to czas wypróbować nowe rozwiązanie. Doświadczenie wskazuje, że chociaż klienci miewają obawy związane ze stopniem zaangażowania biznesowego i zrozumieniem specyfiki projektu przez Product Ownera w takiej konfiguracji, wymierne efekty współpracy szybko przynoszą oczekiwane rezultaty.