Wyobraź sobie trzeci miesiąc projektu. Zespół zewnętrzny, pięć osób, pracuje w dwutygodniowych sprintach i dostarcza regularnie. Wykres spalania wygląda dobrze, demo odbywa się zgodnie z kalendarzem. Na jednym z nich dyrektor sprzedaży, który pojawił się pierwszy raz od dwóch miesięcy, pyta, dlaczego moduł rabatów działa według cennika z zeszłego roku i czemu nikt nie zrobił eksportu do systemu partnera, „przecież to było najważniejsze”. Zespół pokazuje backlog: eksport był na dwudziestym miejscu, bo nikt go nie przesunął. Kierownik projektu po stronie dostawcy przypomina, że o kolejność pytał trzy razy, mailem.
Nikt tu nie zawalił w oczywisty sposób. Programiści zrobili to, co było na górze listy. Dostawca raportował postęp. Firma płaciła faktury. A jednak przez trzy miesiące projekt płynął w kierunku, którego nikt świadomie nie wybrał. To właśnie jest dryf: zespół pracuje, ale nikt nie steruje.
Ten artykuł jest dla prezesów, właścicieli firm i szefów produktów, którzy zlecają budowę oprogramowania zewnętrznemu zespołowi. Teza jest prosta i dla części czytelników niewygodna: rola Product Ownera to jedyna rola w projekcie, której nie da się kupić od dostawcy. Możesz kupić programistów, testerów, analityka, architekta, kierownika projektu, a nawet osobę, która będzie prowadzić backlog. Nie kupisz kogoś, kto za Ciebie zdecyduje, co jest ważniejsze, i kto za Ciebie przyjmie gotową pracę. Jeśli nie masz w firmie osoby, która to zrobi, lepiej uruchomić mniejszy zespół albo poczekać, niż płacić pełnemu zespołowi za budowanie w nieznanym kierunku.
Czym jest dryf projektu i dlaczego zaczyna się od pustego miejsca po stronie klienta?
Dryf to stan, w którym projekt stopniowo oddala się od celu biznesowego, choć każda pojedyncza decyzja wygląda rozsądnie. Nie ma jednego momentu porażki, jest seria drobnych przesunięć. Zespół wybiera interpretację wymagania, która jest prostsza technicznie. Analityk dostawcy uzupełnia lukę w specyfikacji według swojej najlepszej wiedzy. Funkcja, o którą głośno prosił jeden dział, wyprzedza funkcję, która przyniosłaby więcej pieniędzy, ale nikt jej nie bronił. Po kilku sprintach suma tych przesunięć jest już widoczna, a cofnięcie jej kosztuje.
Dlaczego to częściej zdarza się z zespołem zewnętrznym niż z własnym? Bo własny zespół ma naturalny dostęp do kontekstu firmy. Programista na etacie słyszy rozmowy przy kawie, zna klientów, wie, że zarząd właśnie zmienił strategię cenową. Zespół dostawcy wie tylko to, co ktoś mu powiedział. Każda decyzja, której klient nie podjął, i tak zostanie podjęta, tylko przez kogoś, kto ma mniej informacji. Zespół nie przestaje pracować, gdy brakuje odpowiedzi. Robi to, co uważa za najrozsądniejsze, albo bierze następne zadanie z listy, której nikt nie uporządkował.
Druga przyczyna jest ekonomiczna. Dostawca jest rozliczany za dostarczanie pracy, nie za trafność decyzji produktowych. To nie jest zarzut, tylko opis modelu. W modelu czasu i materiałów zespół, który buduje niewłaściwą funkcję, wystawia tę samą fakturę co zespół, który buduje właściwą. W modelu stałej ceny dostawca ma motywację, żeby interpretować zakres możliwie wąsko. Szerzej opisujemy to w tekście o tym, kto naprawdę płaci za przeniesienie ryzyka w fixed-price. W żadnym z tych modeli dostawca nie ma powodu, żeby sam z siebie bronić Twojego wyniku biznesowego mocniej niż Ty.
Dryf zaczyna się więc od pustego miejsca: od roli, która w umowie i w harmonogramie wygląda na obsadzoną, bo ktoś ma ją wpisaną obok nazwiska, ale w praktyce nie ma czasu, mandatu albo wiedzy, żeby ją wykonywać.
Co Scrum Guide naprawdę mówi o Product Ownerze i czego nie mówi?
Warto zacząć od źródła, bo wokół roli Product Ownera narosło sporo mitów. Scrum Guide w wersji z listopada 2020 roku, autorstwa Kena Schwabera i Jeffa Sutherlanda, mówi, że Product Owner odpowiada za maksymalizację wartości produktu wynikającego z pracy zespołu Scrum. Odpowiada też za skuteczne zarządzanie backlogiem produktu, co obejmuje cztery rzeczy: wypracowanie i jasne zakomunikowanie celu produktu, tworzenie i jasne komunikowanie elementów backlogu, ustalanie ich kolejności oraz zapewnienie, że backlog jest przejrzysty, widoczny i zrozumiały.
Trzy zdania z tego samego fragmentu mają bezpośrednie znaczenie dla projektu z zewnętrznym zespołem. Pierwsze: Product Owner może wykonywać tę pracę sam albo delegować ją innym, ale niezależnie od tego pozostaje odpowiedzialny. Drugie: żeby Product Owner mógł odnieść sukces, cała organizacja musi szanować jego decyzje. Trzecie: Product Owner to jedna osoba, a nie komitet. Może reprezentować potrzeby wielu interesariuszy, a ci, którzy chcą zmienić backlog, mogą to zrobić, przekonując Product Ownera.
Z tych zdań wynika więcej, niż się wydaje. Skoro pracę można delegować, a odpowiedzialności nie, to analityk dostawcy może pisać historyjki użytkownika, ale decyzja, czy dana historyjka w ogóle powinna powstać i kiedy, zostaje u Product Ownera. Skoro organizacja musi szanować jego decyzje, to Product Owner, którego ustalenia może w każdej chwili unieważnić dyrektor z innego pionu, nie jest w praktyce Product Ownerem. Skoro to jedna osoba, to „komitet sterujący decyduje o priorytetach” nie jest rozwiązaniem, tylko przepisem na decyzje zapadające raz w miesiącu.
Scrum Guide daje Product Ownerowi także konkretne uprawnienia w wydarzeniach. Podczas planowania sprintu proponuje, jak produkt może zwiększyć swoją wartość i użyteczność w danym sprincie. W trakcie sprintu zakres może być doprecyzowywany i renegocjowany z Product Ownerem, w miarę jak zespół dowiaduje się więcej. Tylko Product Owner ma prawo anulować sprint. Na przeglądzie sprintu zespół pokazuje wyniki pracy kluczowym interesariuszom, a praca, która nie spełnia Definition of Done, nie może być wydana ani nawet pokazana.
Czego Scrum Guide nie mówi? Nie podaje liczby godzin, które Product Owner ma poświęcić zespołowi. Nie mówi, że musi to być osoba z firmy zamawiającej, bo w ogóle nie zajmuje się relacją klient–dostawca. Nie mówi też, że Product Owner musi pisać specyfikacje. To ważne, bo wiele firm rezygnuje z obsadzenia tej roli, zakładając, że wymaga ona pełnego etatu pisania dokumentacji. Nie wymaga. Wymaga decydowania, wyjaśniania i przyjmowania pracy. Pisanie szczegółów można delegować.
Jeszcze jedno zastrzeżenie: nie każdy projekt z zewnętrznym zespołem pracuje w Scrumie. Jeśli Twój zespół działa w Kanbanie, nazwa roli może brzmieć inaczej, ale potrzeba jest identyczna. Ktoś musi ustalać kolejność pracy wchodzącej do systemu i ktoś musi mówić, kiedy rzecz jest gotowa. Wybór metody to osobna decyzja, zależna od rodzaju pracy, a nie od tego, kto ustala priorytety. Ten artykuł używa nazwy Product Owner, bo jest najbardziej rozpoznawalna, ale argument dotyczy funkcji, nie etykiety.
Których decyzji dostawca nie może podjąć za klienta?
Najprościej podzielić decyzje w projekcie na trzy grupy. Pierwsza to decyzje techniczne: jak coś zbudować, jakiej biblioteki użyć, jak podzielić system na moduły. Te decyzje dostawca podejmuje lepiej niż klient i powinien je podejmować, w granicach uzgodnionych standardów. Druga grupa to decyzje organizacyjne zespołu: kto co robi, jak wygląda przegląd kodu, kiedy jest wydanie. Te także należą do zespołu i jego kierownictwa. Trzecia grupa to decyzje o wartości: co budujemy, w jakiej kolejności, czego nie budujemy, co uznajemy za gotowe. Tych dostawca nie może podjąć za klienta, choćby był najlepszy na rynku.
Dlaczego nie może? Z trzech powodów.
Brak informacji. Decyzja o kolejności funkcji wymaga wiedzy, której dostawca nie ma i mieć nie będzie: jakie są cele sprzedażowe na kolejny kwartał, który klient grozi odejściem, jakie zmiany prawne wpłyną na proces, ile kosztuje firmę obecne obejście ręczne, czego oczekuje zarząd. Część tych informacji jest poufna, część zmienia się z tygodnia na tydzień, a część istnieje tylko w głowach ludzi, z którymi dostawca nigdy nie rozmawia.
Brak mandatu. Nawet jeśli dostawca zgadnie właściwy priorytet, nie ma prawa go narzucić interesariuszom klienta. Gdy dyrektor finansowy i dyrektor sprzedaży chcą różnych rzeczy w tym samym sprincie, rozstrzygnąć to może tylko ktoś z ich organizacji. Kierownik projektu dostawcy może najwyżej zebrać argumenty i eskalować, czyli wrócić do klienta z pytaniem, na które klient i tak musi odpowiedzieć.
Konflikt interesów. Decyzja „tego nie budujemy” jest dla dostawcy decyzją o mniejszym przychodzie albo o krótszej współpracy. Uczciwy dostawca ją podpowie, ale nie powinieneś budować projektu na założeniu, że każdy dostawca w każdej sytuacji będzie bronił Twojego budżetu przed własnym zespołem.
Konkretnie, decyzje, które muszą zostać po stronie klienta, to: cel produktu i to, jak mierzymy jego osiągnięcie; kolejność pozycji w backlogu; rezygnacja z funkcji albo przesunięcie jej na później; rozstrzyganie konfliktów między interesariuszami; akceptacja przyrostu jako spełniającego potrzebę biznesową; decyzja o wydaniu na produkcję z punktu widzenia biznesu; decyzja o zmianie zakresu, która wpływa na budżet lub termin. Wszystko inne można w większym lub mniejszym stopniu delegować.
Dlaczego „proxy PO” od dostawcy wygląda na rozwiązanie, a jest przesunięciem ryzyka?
Proxy Product Owner to osoba, która pełni funkcję Product Ownera w imieniu kogoś, kto formalnie tę rolę ma, ale nie ma na nią czasu. Gdy proxy pochodzi od dostawcy, schemat wygląda zwykle tak: klient wskazuje osobę z nazwiskiem w umowie, dostawca dodaje do zespołu analityka albo konsultanta produktowego, który prowadzi backlog, pisze historyjki, prowadzi planowanie i demo. Osoba po stronie klienta pojawia się raz na kilka tygodni, żeby zatwierdzić kierunek.
Na papierze to rozsądny podział. Klient oszczędza czas, dostawca dostaje kogoś, kto szybko odpowiada na pytania zespołu, a backlog jest wreszcie uporządkowany. Problem w tym, że rozwiązuje to objaw, nie przyczynę. Zespół przestaje czekać na odpowiedzi, ale odpowiedzi daje ktoś, kto nie zna wszystkich ograniczeń firmy i nie może ich rozstrzygać. Opóźnienie decyzji zamienia się w ryzyko błędnej decyzji, a to drugie jest droższe, bo ujawnia się później.
Spójrz na to, co faktycznie się dzieje. Proxy PO musi podejmować decyzje codziennie, bo zespół codziennie pyta. Kiedy nie zna odpowiedzi, ma dwie drogi. Może zapytać prawdziwego decydenta i czekać, co przywraca problem, który miał rozwiązać. Może też zdecydować sam, na podstawie najlepszej wiedzy. Wtedy każda taka decyzja jest zakładem, który klient zweryfikuje dopiero na demo, jeśli przyjdzie, albo po wdrożeniu, jeśli nie przyjdzie.
Do tego dochodzi kwestia akceptacji. Proxy PO od dostawcy, który przyjmuje pracę własnego zespołu, ocenia sam siebie. Nawet przy najlepszych intencjach to słaba kontrola: kryteria akceptacji pisała ta sama strona, która je spełnia, a jedyny sprawdzian zgodności z potrzebą biznesu odbywa się bez udziału biznesu. Scrum Guide pozwala delegować pracę Product Ownera, ale nie po to, żeby funkcja kontrolna przeszła na stronę, którą ma kontrolować.
Nie oznacza to, że analityk albo konsultant produktowy dostawcy jest złym pomysłem. Często jest bardzo dobrym. Różnica polega na tym, czy jest wsparciem decydenta, czy jego zastępstwem. Wsparcie przygotowuje opcje, zbiera pytania, pisze szczegóły, pilnuje porządku w backlogu i przychodzi do Product Ownera z decyzjami do podjęcia, a nie z decyzjami podjętymi. Zastępstwo decyduje samo i informuje klienta po fakcie. Pierwsze skraca czas pracy Product Ownera, drugie usuwa go z projektu.
| Obszar | Product Owner po stronie klienta | Analityk/proxy od dostawcy jako wsparcie | Proxy od dostawcy jako zastępstwo |
|---|---|---|---|
| Cel produktu | Ustala i komunikuje | Pomaga go zapisać i rozbić na etapy | Wywodzi go z dokumentów, często nieaktualnych |
| Kolejność backlogu | Decyduje | Proponuje z uzasadnieniem | Decyduje sam |
| Historyjki i kryteria akceptacji | Zatwierdza sens i kryteria biznesowe | Pisze szczegóły | Pisze i zatwierdza |
| Odpowiedzi na pytania zespołu | Odpowiada na pytania biznesowe w ciągu dnia–dwóch | Odpowiada na pytania o szczegóły, resztę zbiera | Odpowiada na wszystko według najlepszej wiedzy |
| Akceptacja przyrostu | Przyjmuje albo odrzuca | Sprawdza zgodność z kryteriami przed akceptacją | Przyjmuje pracę własnego zespołu |
| Konflikty interesariuszy | Rozstrzyga | Przygotowuje zestawienie stanowisk | Eskaluje albo omija |
| Ryzyko dla klienta | Opóźnienia, jeśli PO ma za mało czasu | Niskie przy jasnym podziale | Wysokie, ujawnia się późno |
Jeśli dostawca proponuje Ci model „dostarczymy też Product Ownera”, zapytaj wprost, kto będzie akceptował przyrost, kto rozstrzyga konflikt między dwoma Twoimi dyrektorami i kto zdecyduje o rezygnacji z funkcji. Jeśli odpowiedź na którekolwiek z tych pytań brzmi „nasz konsultant”, dostajesz zastępstwo, a nie wsparcie.
Ile czasu Product Owner musi dać zespołowi zewnętrznemu?
To pytanie, na które większość firm odpowiada „kilka godzin w tygodniu”, i to jest główny powód, dla którego rola zostaje pusta. Scrum Guide nie podaje liczby godzin, więc poniższe wyliczenie jest szacunkiem zbudowanym z limitów czasowych wydarzeń Scruma i typowych czynności, a nie normą. Pokazuje jednak rząd wielkości, który warto znać przed podpisaniem umowy.
Załóżmy jeden zespół, pięciu programistów i testera, sprinty dwutygodniowe. W takim rytmie pracuje na przykład ARDURA w projektach tworzenia oprogramowania. Scrum Guide ogranicza planowanie sprintu do maksymalnie ośmiu godzin dla sprintu miesięcznego, a przegląd sprintu do czterech godzin, z zaznaczeniem, że dla krótszych sprintów te wydarzenia są zwykle krótsze. Wcześniejsza wersja przewodnika, z 2017 roku, podawała, że doprecyzowywanie backlogu zwykle zajmuje nie więcej niż 10% pojemności zespołu deweloperskiego; wersja z 2020 roku tę liczbę usunęła, ale jako punkt odniesienia nadal się przydaje.
| Czynność | Szacunek na sprint dwutygodniowy | Od czego zależy |
|---|---|---|
| Planowanie sprintu | 2–4 h | Dojrzałość backlogu, liczba nowych tematów |
| Przegląd sprintu i przygotowanie interesariuszy | 2–3 h | Liczba interesariuszy, potrzeba pokazów dla kilku działów |
| Doprecyzowywanie backlogu z zespołem | 4–8 h | Niepewność zakresu, jakość przygotowania przez analityka |
| Rozmowy z interesariuszami, zbieranie i ważenie potrzeb | 6–12 h | Liczba działów, polityka wewnętrzna, tempo zmian w firmie |
| Odpowiedzi na pytania zespołu w trakcie sprintu | 5–10 h | Czy pytania są zbierane, czy przychodzą pojedynczo |
| Akceptacja przyrostów, testy akceptacyjne | 3–6 h | Złożoność funkcji, potrzeba danych testowych |
| Pomiar efektów i aktualizacja celu | 2–4 h | Dostępność danych, dojrzałość produktu |
| Razem | 24–47 h, czyli ok. 30–60% etatu |
Ten przedział to szacunek, nie wynik badania. Górną granicę osiągniesz w pierwszych miesiącach nowego produktu, przy wielu interesariuszach i niejasnym zakresie. Dolną przy dojrzałym produkcie, z dobrym analitykiem, który przygotowuje szczegóły. Przy dwóch zespołach pracujących nad tym samym produktem obciążenie nie podwaja się, ale wyraźnie rośnie, bo rośnie liczba pytań i liczba przyrostów do przyjęcia.
Ważniejsze od liczby godzin jest ich rozłożenie. Product Owner, który daje zespołowi osiem godzin w piątek, ale nie odpowiada na wiadomości od poniedziałku do czwartku, jest dla zespołu mniej użyteczny niż osoba, która daje pięć godzin rozłożonych na każdy dzień. Zespół potrzebuje odpowiedzi wtedy, gdy powstaje pytanie. Jeśli musi czekać trzy dni, albo zgaduje, albo bierze inne zadanie i traci kontekst. Manifest Agile, opublikowany w 2001 roku, ujmuje to w czwartej zasadzie: ludzie biznesu i programiści muszą codziennie ze sobą współpracować przez cały czas trwania projektu. Słowo „codziennie” jest tu kluczowe.
Teraz porównaj ten koszt z kosztem braku decyzji. Przy stawkach seniorów z przedziału 180–260 zł za godzinę pięcioosobowy zespół przepracowujący po 80 godzin w sprincie kosztuje, licząc przy stawce 200 zł, około 80 000 zł na sprint. Jeśli z powodu niewłaściwego priorytetu choćby jedna czwarta sprintu idzie na funkcję, którą trzeba potem przerobić albo wyrzucić, to 20 000 zł straty, nie licząc opóźnienia rzeczy ważnych. Połowa etatu menedżera po stronie klienta kosztuje firmę mniej, a przede wszystkim jest kosztem kontrolowanym, a nie ukrytym.
Jak rozpoznać, że projekt już dryfuje?
Dryf jest trudny do zauważenia właśnie dlatego, że wskaźniki dostarczania wyglądają dobrze. Zespół zamyka zadania, sprinty kończą się w terminie, raporty są zielone. Sygnały trzeba szukać gdzie indziej.
Pytania czekają dłużej niż dwa dni. Jeśli zespół prowadzi listę otwartych pytań do klienta i ta lista rośnie, decyzje nie nadążają za pracą. Poproś dostawcę o tę listę z datą zadania każdego pytania. Średni wiek pytań powie Ci więcej niż jakikolwiek wykres prędkości.
Kolejność backlogu nie zmienia się między sprintami. Produkt w rozwoju uczy się z każdego przyrostu, więc priorytety powinny się przesuwać. Backlog, którego kolejność od miesiąca stoi w miejscu, oznacza zwykle, że nikt go nie porządkuje, a zespół po prostu bierze kolejne pozycje z góry.
Na przeglądzie sprintu nie ma nikogo z biznesu. Jeśli demo ogląda tylko osoba kontaktowa i kierownik projektu dostawcy, przyrosty nie są konfrontowane z użytkownikami. Zespół dowie się o rozbieżności dopiero przy wdrożeniu.
Akceptacja jest odkładana do końca etapu. Gdy przyrosty czekają na przyjęcie tygodniami, a akceptacja ma odbyć się „zbiorczo przed wdrożeniem”, wracasz do modelu kaskadowego z odbiorem na końcu, tylko z dłuższą listą zaległości.
Zespół zaczyna sam wymyślać wymagania. Słychać to w zdaniach „założyliśmy, że”, „przyjęliśmy domyślnie”, „zrobiliśmy tak jak w podobnym systemie”. Pojedyncze założenie jest normalne. Gdy staje się metodą pracy, zespół przejął rolę, która do niego nie należy.
Interesariusze omijają Product Ownera. Dyrektorzy piszą bezpośrednio do programistów albo do kierownika projektu dostawcy z prośbami „na szybko”. To znak, że organizacja nie szanuje decyzji Product Ownera, czyli dokładnie warunku, który Scrum Guide uznaje za konieczny.
Cel produktu nie jest zapisany albo nikt go nie pamięta. Zapytaj trzy osoby z zespołu, po co budują ten system i jak poznają, że się udało. Jeśli dostaniesz trzy różne odpowiedzi albo listę funkcji zamiast celu, zespół nie ma punktu odniesienia dla swoich codziennych wyborów.
Retrospektywy sprintu są dobrym miejscem, żeby te sygnały wyciągnąć na powierzchnię, pod warunkiem że kończą się decyzją, a nie listą życzeń. Jeśli trzy retrospektywy z rzędu wskazują „czekamy na odpowiedzi klienta”, to nie jest problem zespołu, tylko organizacji klienta.
Kto w firmie powinien zostać Product Ownerem, a kto nie?
Dobry Product Owner po stronie klienta łączy trzy cechy: wiedzę o problemie, mandat do decyzji i realny czas. Brak którejkolwiek z nich wystarczy, żeby rola przestała działać.
Wiedza o problemie oznacza, że ta osoba rozumie proces, który oprogramowanie ma zmienić, zna jego użytkowników i wie, ile kosztuje obecny stan. Nie musi znać technologii. Musi umieć powiedzieć, czy dana funkcja rozwiązuje prawdziwy problem, czy tylko wygląda na rozwiązanie.
Mandat do decyzji oznacza, że może zdecydować o kolejności i zakresie bez zwoływania spotkania z przełożonym przy każdej zmianie. W praktyce przydaje się zapisanie tego mandatu: do jakiego poziomu wpływu na budżet i termin Product Owner decyduje sam, od jakiego musi pytać sponsora. Bez takiego zapisu każdy konflikt kończy się eskalacją, a eskalacja trwa.
Realny czas oznacza, że ktoś z kierownictwa świadomie zdjął z tej osoby część innych obowiązków. Dopisanie roli Product Ownera do pełnego kalendarza kierownika działu daje Product Ownera z nazwy.
Z tych kryteriów wynikają typowe dobre i złe kandydatury. Dobra to najczęściej menedżer z linii biznesowej, która najbardziej skorzysta z systemu: kierownik obsługi klienta przy portalu klienta, kierownik logistyki przy systemie magazynowym, szef produktu przy produkcie sprzedawanym klientom. Dobra bywa też osoba, którą firma zatrudnia specjalnie na tę rolę, jeśli produkt jest strategiczny i będzie rozwijany latami.
Złe kandydatury są równie powtarzalne. Członek zarządu ma mandat, ale nie ma czasu i staje się wąskim gardłem. Pracownik działu IT ma czas i zna technologię, ale często nie ma mandatu do rozstrzygania sporów między działami biznesowymi i zna proces z drugiej ręki. Asystent albo młodszy specjalista ma dostępność, ale ani wiedzy, ani mandatu, i zamienia się w przekaźnik wiadomości. Komitet złożony z przedstawicieli kilku działów ma wiedzę i mandat, ale nie jest jedną osobą, więc decyzje zapadają wolno i są kompromisem zamiast wyboru.
Osobny przypadek to analityk. Rola analityka biznesowego jest bliska roli Product Ownera i często się z nią myli. Analityk rozpoznaje potrzeby, modeluje procesy i zapisuje wymagania. Product Owner decyduje, które z tych potrzeb i w jakiej kolejności zespół zaspokoi. Jedna osoba może łączyć obie funkcje, ale wtedy jej czas musi to uwzględniać. Różnice między analitykiem biznesowym a systemowym opisujemy w tekście analityk biznesowy czy systemowy.
Jak podzielić pracę między Product Ownera klienta, analityka i zespół dostawcy?
Najwięcej nieporozumień w projektach z zespołem zewnętrznym bierze się nie z braku ról, tylko z niejasnych granic między nimi. Dlatego podział warto zapisać przed pierwszym sprintem, w jednej tabeli, i pokazać ją wszystkim interesariuszom.
| Czynność | Product Owner (klient) | Analityk (klient lub dostawca) | Zespół dostawcy | Kierownictwo dostawcy |
|---|---|---|---|---|
| Cel produktu i miary sukcesu | Decyduje | Pomaga zapisać | Zna i stosuje | Raportuje postęp wobec celu |
| Kolejność backlogu | Decyduje | Proponuje | Zgłasza zależności techniczne | Sygnalizuje wpływ na budżet i termin |
| Szczegóły historyjek | Zatwierdza sens | Pisze | Doprecyzowuje technicznie | — |
| Kryteria akceptacji | Zatwierdza | Pisze projekt | Weryfikuje wykonalność | — |
| Definition of Done | Zna i akceptuje | — | Ustala i stosuje | Pilnuje spójności między zespołami |
| Akceptacja przyrostu | Decyduje | Sprawdza zgodność z kryteriami | Demonstruje | — |
| Zmiana wpływająca na budżet | Wnioskuje lub zatwierdza | Opisuje wpływ | Szacuje | Wycenia i proponuje zmianę umowy |
| Skład i organizacja zespołu | Informowany | — | Organizuje się | Decyduje |
Dwie kolumny wymagają komentarza. Po pierwsze, analityk może być po stronie klienta albo dostawcy. Jeśli jest po stronie dostawcy, to dokładnie to wsparcie, o którym była mowa przy proxy PO: przygotowuje, ale nie decyduje. Po drugie, Definition of Done należy do zespołu, a kryteria akceptacji do Product Ownera. To dwa różne sprawdziany. Definition of Done mówi, że praca jest technicznie skończona: przetestowana, przejrzana, wdrażalna. Kryteria akceptacji mówią, że rozwiązuje konkretny problem biznesowy. Więcej o tej różnicy w tekście Definition of Done: jak jedna lista chroni jakość lepiej niż dodatkowy etap testów i w haśle słownika kryteria akceptacji.
Kolumna kierownictwa dostawcy celowo jest wąska. Kierownik projektu albo delivery manager po stronie dostawcy odpowiada za to, jak zespół dostarcza: skład, ciągłość, jakość, ryzyka, raportowanie. Nie odpowiada za to, co zespół dostarcza w sensie biznesowym. Kiedy te dwie odpowiedzialności zlewają się w jednej osobie po stronie dostawcy, wracamy do problemu zastępstwa. Szczegółowy podział między kierownikiem projektu klienta a delivery managerem dostawcy, wraz z macierzą RACI dla tych ról, opisujemy w tekście delivery manager i project manager: kto za co odpowiada; tutaj ważne jest tylko to, że żadna z tych ról nie zastępuje Product Ownera.
Jak wygląda akceptacja, która nie zamienia się w odbiór na końcu?
Akceptacja to moment, w którym Product Owner mówi: to, co zespół zbudował, rozwiązuje problem, dla którego to zamówiliśmy. W projektach prowadzonych iteracyjnie powinna odbywać się w rytmie sprintów, na bieżąco, a nie raz, przed wdrożeniem. W praktyce często dzieje się odwrotnie: przyrosty są pokazywane, ale nikt ich formalnie nie przyjmuje, a „prawdziwy odbiór” zaplanowano na koniec etapu.
Taka odłożona akceptacja ma trzy skutki. Po pierwsze, rozbieżności wychodzą na jaw w momencie, gdy na poprawki zostało najmniej czasu. Po drugie, kumulują się: funkcje zbudowane na błędnym założeniu stają się fundamentem kolejnych. Po trzecie, rozmowa o odbiorze zamienia się w spór o to, co było w zakresie, zamiast w rozmowę o tym, czy produkt działa.
Akceptacja ciągła wymaga kilku prostych rzeczy. Każda pozycja backlogu ma przed rozpoczęciem pracy kryteria akceptacji zatwierdzone przez Product Ownera. Zespół zgłasza pozycję do akceptacji, gdy spełnia Definition of Done. Product Owner przyjmuje albo odrzuca ją w ustalonym czasie, na przykład w ciągu dwóch dni roboczych, a odrzucenie zawiera konkretny powód odwołujący się do kryteriów. Pozycja odrzucona z powodu zmiany zdania co do potrzeby nie wraca jako błąd zespołu, tylko jako nowa pozycja w backlogu. To ostatnie jest uczciwe wobec dostawcy i chroni relację.
Testy akceptacyjne użytkowników warto zaplanować jako część tej pracy, nie jako osobną fazę. Product Owner nie musi testować wszystkiego sam, ale musi wskazać użytkowników, którzy sprawdzą przyrost w realnym scenariuszu, i zapewnić im czas. Praktyczne wskazówki opisujemy w przewodniku po testach akceptacyjnych UAT.
Co zapisać w umowie z dostawcą o roli Product Ownera?
Umowa o budowę oprogramowania zwykle szczegółowo opisuje obowiązki dostawcy i bardzo ogólnie obowiązki klienta. Tymczasem w projekcie iteracyjnym wynik zależy od obu stron. Zapisanie roli Product Ownera w umowie nie jest biurokracją. Jest sposobem, żeby obie strony zobaczyły, ile ta rola wymaga, zanim projekt ruszy.
Warto zapisać sześć rzeczy.
Kto jest Product Ownerem i kto go zastępuje. Imię i nazwisko, zakres mandatu, osoba zastępująca na czas urlopu i choroby. Brak zastępcy to najczęstsza przyczyna sprintów bez decyzji w sezonie urlopowym.
Deklarowana dostępność. Liczba godzin w sprincie i maksymalny czas odpowiedzi na pytania zespołu. Nie chodzi o karanie klienta za opóźnienia, tylko o to, żeby obie strony miały wspólny punkt odniesienia.
Konsekwencje braku decyzji. Co się dzieje, gdy pytanie czeka dłużej niż ustalono: zespół przechodzi do następnej pozycji, a pozycja zablokowana jest raportowana jako zablokowana po stronie klienta. W modelu stałej ceny brak decyzji w terminie powinien przesuwać harmonogram; w modelu czasu i materiałów powinien być widoczny w raporcie jako koszt oczekiwania.
Tryb akceptacji. Kto przyjmuje przyrosty, w jakim terminie, co oznacza brak odpowiedzi w terminie i jak wygląda odrzucenie.
Rola analityka lub konsultanta dostawcy. Jeśli dostawca dostarcza wsparcie produktowe, umowa powinna mówić wprost, że przygotowuje decyzje, a nie je podejmuje, i że nie przyjmuje pracy w imieniu klienta.
Prawo do zatrzymania projektu. Klient powinien mieć prawo wstrzymać albo zmniejszyć zespół, jeśli nie jest w stanie zapewnić decyzji. To zabezpieczenie po stronie klienta, nie dostawcy: lepiej świadomie zwolnić tempo, niż płacić za pracę bez kierunku. Przy wyborze partnera dla nowego produktu warto o te zapisy zapytać już na etapie ofert; więcej na ten temat w tekście o wyborze partnera do budowy MVP i warunkach umowy.
Dostawca, który na te zapisy reaguje niechętnie, sygnalizuje, że wolałby nie mieć jasnego podziału odpowiedzialności. Dostawca, który sam o nie pyta, rozumie, że bez decydenta po stronie klienta jego zespół będzie pracował gorzej, i to on poniesie część kosztów reputacyjnych.
Co zrobić, gdy w firmie po prostu nie ma osoby z czasem?
To najczęstsza sytuacja i najważniejsze miejsce tej tezy. Firma potrzebuje systemu, ma budżet na zespół, ale nie ma nikogo, kogo mogłaby oddelegować na połowę etatu. Odruchowa odpowiedź brzmi: dostawca to ogarnie. Ten artykuł argumentuje, że to najgorsza z dostępnych opcji. Są lepsze.
Zmniejsz zespół do przepustowości decyzji. Liczba decyzji, których wymaga zespół, rośnie z jego wielkością. Jeśli dostępny decydent ma dwanaście godzin w sprincie, może prowadzić dwuosobowy zespół, ale nie sześcioosobowy. Mniejszy zespół, który buduje właściwe rzeczy, dostarczy więcej wartości niż większy, który buduje w dryfie. To rozwiązanie wydaje się wolniejsze, ale porównuj tempo dostarczania wartości, a nie tempo zamykania zadań.
Zrób najpierw discovery, potem decyduj o zespole. Krótka faza rozpoznania potrzeb pozwala zapisać cel produktu, podzielić zakres na etapy i ustalić, jakich decyzji będzie wymagał każdy z nich. W ARDURA projekty tworzenia oprogramowania zaczynają się od fazy discovery, która trwa 1–2 tygodnie i służy zdefiniowaniu zakresu oraz architektury. Po takiej fazie łatwiej ocenić, czy masz w firmie osobę, która udźwignie rolę, i ile czasu będzie jej potrzebne. Opis samego procesu znajdziesz w haśle proces product discovery.
Zwolnij kogoś z części obowiązków. Najlepszy kandydat na Product Ownera prawie zawsze jest zajęty, bo jest dobry w tym, co robi. Decyzja zarządu o przekazaniu części jego obowiązków komuś innemu na czas projektu jest tańsza niż projekt bez kierunku. To decyzja, którą musi podjąć sponsor projektu, nie dostawca.
Zatrudnij Product Ownera do firmy. Jeśli produkt jest strategiczny i będzie rozwijany latami, osoba zatrudniona na tę rolę zwraca się szybko. Ważne, żeby była pracownikiem klienta albo co najmniej działała wyłącznie w jego imieniu, z mandatem od jego zarządu.
Wzmocnij decydenta analitykiem, ale nie zastępuj go. Analityk po stronie dostawcy albo klienta może zdjąć z Product Ownera większość pracy przygotowawczej: pisanie historyjek, zbieranie pytań, przygotowanie danych do decyzji. Przy dobrym podziale czas Product Ownera spada w stronę dolnej granicy szacunku. Nie spada do zera.
Czego nie robić? Nie uruchamiaj pełnego zespołu z założeniem, że decydent „znajdzie czas później”. Pierwsze sprinty ustalają architekturę i fundamenty, na których zbudowane zostanie wszystko inne. To właśnie wtedy decyzje są najważniejsze i najdroższe do zmiany.
Jakie są kluczowe wnioski?
Zewnętrzny zespół potrafi zbudować prawie wszystko, ale nie potrafi chcieć za Ciebie. Każda decyzja o wartości, której nie podejmie klient, i tak zostanie podjęta, tylko przez kogoś, kto ma mniej informacji, mniej mandatu i inny interes. Stąd dryf, który nie wygląda jak porażka, dopóki nie zobaczysz sumy drobnych przesunięć.
Zapamiętaj sześć rzeczy. Po pierwsze, Product Owner to jedna osoba po stronie klienta, której decyzje szanuje cała organizacja; komitet i osoba kontaktowa bez mandatu jej nie zastąpią. Po drugie, dostawca może przejąć pracę przygotowawczą, ale nie decyzje o priorytetach, rezygnacji z funkcji i akceptacji. Po trzecie, proxy PO od dostawcy ma sens wyłącznie jako wsparcie, które przychodzi z decyzjami do podjęcia, a nie z decyzjami podjętymi. Po czwarte, licz realny czas: przy jednym zespole w dwutygodniowych sprintach szacunkowo od 30 do 60% etatu, rozłożonego na każdy dzień, a nie skumulowanego w piątek. Po piąte, zapisz rolę w umowie: osobę, zastępcę, dostępność, tryb akceptacji i konsekwencje braku decyzji. Po szóste, jeśli nie masz w firmie osoby z czasem, zmniejsz zespół albo zacznij od discovery, zamiast płacić pełnemu zespołowi za pracę bez kierunku.
Jeśli planujesz projekt z zewnętrznym zespołem i chcesz ustalić podział ról, zanim ruszy pierwszy sprint, zobacz, jak pracujemy w tworzeniu oprogramowania na zamówienie, albo umów rozmowę. Faza discovery trwa 1–2 tygodnie i kończy się zakresem, architekturą oraz jasnym obrazem tego, jakich decyzji projekt będzie wymagał od Twojej strony.