Nie da się tak po prostu siąść i zacząć pisać wymagania, aby następnie stworzyć z nich Backlog Produktu. Wielu Product Ownerów próbuje tak właśnie działać, łudząc się przy tym, że „wiedzą, co powinno znaleźć się w produkcie”. Nasuwa się od razu pytanie: skoro wszystko wiadomo, to właściwie po co ten Scrum? I po co Product Owner? Niechaj Developerzy pod wodzą sensownego managera projektu zrealizują to, co „powinno znaleźć się w produkcie” i sukces gwarantowany…

No, chyba że jednak nie będzie sukcesu, bo okaże się, że jednak nie do końca było wiadomo, co powinno znaleźć się w produkcie, a poza tym potrzeby interesariuszy (użytkowników, klientów itd.) nie zechciały ulec zamrożeniu i zmieniały się cały czas. Ot, taka ich natura.

Na początek przestańmy myśleć o Backlogu jako o innej formie listy rzeczy do zrobienia, którą da się z góry zdefiniować, a potem wykonać. Potraktujmy go jako ciągle zmienny plan osiągnięcia… no, właśnie: czego? I tu okaże się, że zanim zabierzemy się do konstruowania choćby zrębów Backlogu Produktu, trzeba pomyśleć o czymś innym

Krok 1: Wizja produktu

Potrzebujemy przede wszystkim odpowiedzi na pytanie, czym właściwie jest produkt. I nie chodzi tu wcale o obłożenie się różnymi narzędziami, które w takiej czy innej formie pozwolą nam zapisać puste, choć ładnie brzmiące hasła. Ten, kto mieni się Product Ownerem (a więc właścicielem produktu), powinien autentycznie chcieć wytworzyć coś, co przyniesie komuś (być może jemu samemu) realne korzyści. Musi więc wiedzieć:

  • Po co jest produkt, czyli jakie potrzeby zaspokaja, na jakie oczekiwania odpowiada.
  • Dlaczego warto go zbudować i co właściwie jest tą wartością.
  • Kto będzie z produktu korzystał i w jaki sposób.

Oczywiście nie chodzi tu o rozważania, jakie konkretne cechy czy funkcjonalności będzie miało rozwiązanie, które zbudują Developerzy. Chodzi o ogólny charakter rozwiązań, np. że produktem jest serwis internetowy, łączący weterynarzy z właścicielami zwierzaków – a nie o wymienianie kolejnych podstron i formularzy takiego serwisu.

Tu warto wskazać, że wizja produktu, jak i sam produkt jest czymś długoterminowym. Dopóki jest sens dalej rozwijać produkt, by zbliżyć się do pełniejszej realizacji wizji, dotąd ten produkt będzie „żył” i się zmieniał.

Sama wizja też nie musi być statyczna, bo jest jakimś odbiciem potrzeb i oczekiwań użytkowników produktu, wymiksowanych z powodami, dla których produkt w ogóle powstał i jest dalej rozwijany. Wizja nie jest również opisem „stanu docelowego”, jaki rozwój produktu ma pozwolić osiągnąć. Wytycza kierunek i być może zwrot działań, ale w pełni raczej nie zostanie nigdy osiągnięta.

Krok 2: Modelowanie produktu

Przyjmując, że istnieje sensowna wizja produktu, trzeba pomyśleć nad konkretami – ale wciąż nie będzie to jeszcze Backlog Produktu. Chodzi o stworzenie modelu (np. w formie popularnych canvasów różnego typu) tego, czym właściwie produkt ma być. To pozwoli postawić sobie i uzyskać odpowiedzi na istotne pytania, na przykład:

  • Ilu i jakich użytkowników produktu należy wziąć pod uwagę przy jego wytwarzaniu?
  • Czego oni potrzebują w produkcie i co sprawi, że będą chcieli z niego korzystać?
  • Jaką zmianę w stosunku do obecnego stanu spraw ma spowodować produkt?
  • Od czego zależy możliwość wytworzenia produktu?
  • W jaki sposób sfinansowanie jego rozwój?

W zależności od tego, czym jest produkt, pytania te mogą być oczywiście różne. Mogą być np. związane z działaniami konkurencji, z dążeniem do dokonania przełomu technologicznego itd.

Celem modelowania nie jest stworzenie planu jako takiego, ale uzyskanie tak naprawdę trzech rzeczy:

  • Ujawnienia i jednoznacznego nazwania założeń, jakie czynimy, przymierzając się do budowania produktu.
  • Postawienia pytań i uzyskania na nie odpowiedzi.
  • Ustalenia miar, które pozwolą ocenić albo to, czy produkt w ogóle ma sens, albo – już później – czy jego rozwój przynosi wymierne korzyści.

Bardzo często próba stworzenia modelu biznesowego dla produktu o bardzo nośnej wizji ujawnia, że ten produkt, jakkolwiek „fajny”, sensu nie ma. Wtedy wracamy do kroku pierwszego. Dużo częściej zdarza się, że w trakcie modelowania dokonujemy oceny różnych strategii rozwoju produktu, np. szukamy najsensowniejszej grupy docelowej, najlepszego mechanizmu docierania do niej itd. W praktyce rzadko kiedy te rozważania zakończą się na stworzeniu jednego, świetnego modelu; częściej jest to proces iteracyjny, w którym modeli (np. canvasów) powstanie spora ilość.

Krok 3: Potwierdzenie kluczowych założeń

Czy już możemy tworzyć Backlog? Niekoniecznie, bo na razie mamy jedynie wizję i stertę założeń, często podpartych dość lichym zbiorem danych. Np. mamy model typowego użytkownika (albo persony, jeśli posłużyliśmy się techniką ich opisywania) oraz ocenę, ile takich użytkowników jest. Wciąż jednak możemy kompletnie się mylić, co do potrzeb takich ludzi albo choćby ich rzeczywistego istnienia lub ilości. To samo dotyczyć może każdego aspektu modelu, jaki wykreowaliśmy w kroku drugim.

Sprawdźmy więc to, co się da, w sposób pozwalający wiedzieć, a nie zgadywać, jak jest naprawdę. Poszukajmy tych użytkowników, o których istnieniu spekulujemy i porozmawiajmy z nimi. Ba, zbudujmy inny produkt (prosty i tani), który potwierdzi sens budowania czegoś dużego i kosztownego – jeśli nasza wizja jest nietrafiona albo model biznesowy nieracjonalny, ograniczymy w ten sposób ryzyko inwestycyjne (albo mówiąc wprost: straty).

Krok 4: Cel Produktu

Jeśli walidacja modelu biznesowego i wizji, na tyle, o ile w ogóle da się ją przeprowadzić bez budowania produktu, dała pozytywny wynik, możemy zabrać się za tworzenie zrębów pierwszej wersji Backlogu Produktu. Nie zaczniemy tego jednak od identyfikowania wymagań – bo to nie miałoby sensu. Backlog jest przecież ciągle zmiennym planem osiągania jakiegoś celu, a my jeszcze go nie wyznaczyliśmy.

Czym powinien być ten Cel Produktu? Określeniem tego, do czego dążyć będziemy w ramach realizacji wizji. Nie powinien to natomiast być opis „dużego kawałka produktu”, a jeśli już nie potrafimy się oderwać od myślenia w tych kategoriach, to Cel Produktu powinien stanowić odpowiedź na pytanie, czemu tego „dużego kawałka produktu” potrzebujemy i co on komukolwiek da.

Brzmi to bardzo ogólnie, więc warto posłużyć się przykładem, którym często posługuję się na szkoleniach. Wyobraźmy sobie firmę, która zajmuje się obsługą księgową różnych innych firm i osób. Pojawia się pomysł na podniesienie efektywności działania poprzez zastosowanie oprogramowania, które pomoże księgowym w pracy i pozwoli firmie obsługiwać więcej klientów w krótszym czasie. W uproszczeniu możemy uznać to za wizję produktu (bardzo kanciastą i zapewne wymagającą przemyślenia, ale na potrzeby przykładu wystarczającą).

Co mogłoby być pierwszym Celem Produktu dla takiego oprogramowania? Wypisywanie mniejszych czy większych funkcjonalności nie ma sensu, bo ich posiadanie nie jest celem samym w sobie, tylko drogą do osiągnięcia jakiegoś celu. Wydaje się, że najbardziej na początek potrzebne będzie przeniesienie obiegu dokumentacji księgowej z wersji „papierowej” do elektronicznej, bo to pewien krok niezbędny do zrobienia czegokolwiek bardziej zaawansowanego. Dlatego sensownym Celem Produktu mogłaby być właśnie digitalizacja obiegu dokumentacji w firmie.

Tu przypominam, że Cel Produktu ma być jeden, ponieważ w jego kontekście będzie kształtowany Backlog Produktu (jego zawartość i kolejność). Gdybyśmy „Celów” (cudzysłów nieprzypadkowy) mieli wiele w tym samym momencie, w zależności od tego, który akurat byłby rozważany, kolejność i zawartość Backlogu Produktu musiałaby być inna – a to przepis na chaos. Poza tym, zmierzając w wiele stron naraz, zapewne nie dotrzemy nigdzie.

Przy czym Cel Produktu w pewnym momencie uda się osiągnąć albo zbliżyć do niego na tyle, że można uznać jego zaspokojenie za wystarczające. Wtedy wyznaczony zostanie nowy Cel. W naszym przykładzie, gdy digitalizacja będzie już niemal kompletna, Product Owner może uznać, że Celem Produktu (nowym, zastępującym ten poprzedni) jest teraz zautomatyzowanie typowych czynności, jakie wykonywane są przez księgowych tak, by nie wymagało to pracy ludzkiej i nie było obciążone ich tendencją do popełniania błędów. Znów: nie będzie to żadna „konkretna duża funkcjonalność”, ale cel, jaki produkt ma pozwolić osiągnąć.

Uwaga: czasami nie udaje się żadnego sensownego Celu Produktu określić. To silny sygnał, że coś może być „nie tak” z naszym modelem produktu lub wręcz jego wizją. Wtedy należy wrócić do poprzednich kroków i dokonać ich korekty z użyciem wglądów, jakie ujawniła próba ustalenia sensownego Celu Produktu.

I druga Uwaga: Cel Produktu jest pochodną przynajmniej tych czterech rzeczy:

  • wizji produktu,
  • modelu tego produktu (jeśli go mamy),
  • potrzeb i oczekiwań interesariuszy,
  • ocen i zamierzeń samego Product Ownera.

Nie da się więc „wytrząsnąć go z kapelusza” i liczyć, że jakoś to będzie, a potem się zobaczy. Product Owner, nim ustanowi Cel Produktu, musi bezwzględnie mieć dobry ogląd tego, czego oczekuje od niego interesariat, ale też własną koncepcję tego, jak chce przybliżyć się do realizacji wizji.

Krok 5 (opcjonalny): Modelowanie rozwiązań

Jeśli produkt jest stosunkowo niewielki i jego architektura (struktura rozwiązania) jest nieprzesadnie złożona, zapewne można przejść do kreowania Backlogu Produktu. Często jednak to nie wystarczy, bo istnieje zbyt wiele całkowicie różnych sposobów osiągnięcia wyznaczonego Celu Produktu, zbyt wiele, by sensowny plan jego osiągania zaproponować.

W takim przypadku podobnie jak to miało miejsce z modelem produktu jako takiego (czasami mówi się o tym „model biznesowy”, ale nie jest to zawsze prawda, albowiem różnych modeli można używać), warto stworzyć model samego rozwiązania. Oczywiście nie chodzi tu o projektowanie konkretnych kawałków produktu czy detaliczne opisywanie jego funkcjonalności – to zrobią Developerzy, realizując elementy Backlogu Produktu, który przecież jeszcze nie powstał. Ten „model rozwiązania” ma raczej za zadanie ujawnić, jakich funkcjonalności i w jakiej kolejności ułożonych potrzeba w produkcie.

Istnieje wiele technik (Story Mapping, Event Storming, Customer Journey itd.), którymi można się posłużyć. Rozważamy w nich nie to, jak zbudować produkt, ale jak on ma działać od strony funkcjonalnej i użytkowej.

Przy okazji najczęściej uda się zidentyfikować kluczowe elementy produktu, bez których on zwyczajnie nie zadziała. Każdy produkt ma coś takiego, choć często nie zdajemy sobie z tego sprawy: rzeczy, których teoretycznie nikt nie chce, ale gdyby ich nie było, produkt by nie działał. Przykład: czy ktoś desperacko chce rozrusznika w samochodzie z silnikiem spalinowy? Nie, nikt nie kupuje auta, by mieć rozrusznik. Nie da się jednak zbudować tego typu pojazdu bez rozrusznika, bo jakoś silnik trzeba uruchomić. Bez tego samochód przestałby służyć podstawowemu celowi, dla jakiego powstał.

I tu ważna uwaga: to, że istnieją takie kluczowe funkcjonalności, które być może uda nam się zidentyfikować, nie oznacza wcale, że mamy je zapisać w Backlogu Produktu jako rzeczy do zrobienia. Jeszcze nie i być może w ogóle tego nie zrobimy.

Krok 6: Tworzenie zrębów Backlogu Produktu

Tak, to już! Teraz można zacząć to robić. Już wiemy jaki produkt (wizja i modele) i po co (Cel Produktu) chcemy zbudować, więc możemy zacząć układać plan, który pozwoli nam to zrobić. Przy czym nie polega to na tym, iż Product Owner zamyka się w jakimś pomieszczeniu na miesiąc i próbuje wykreować „kompletny Backlog Produktu”. Trzeba to zrobić zupełnie inaczej.

Wychodząc od Celu Produktu, Product Owner powinien zadawać sobie pytania o to, co najbardziej jest potrzebne, by cel ten osiągnąć. Przy czym najlepiej, by opisywał nie funkcjonalności i sposób implementacji produktu, ale jego sposób działania – lub wręcz potrzeby użytkowników.

Dobrym schematem działania może być taki:

  1. Najpierw identyfikujemy kluczowe potrzeby, jakie trzeba zaspokoić, by Cel Produktu mógł w ogóle być osiągnięty.
  2. Potem dodajemy do tej listy to, co bezwzględnie musi być zrobione, aby osiągnięcie Celu Produktu w ogóle miało wartość.
  3. Na koniec uzupełniamy Backlog o te rzeczy, które nie wynikają ani z Celu Produktu, ani nie muszą być z jakiegoś innego powodu zrobione teraz, ale są potrzebne, by produkt po prostu zadziałał w sposób spójny.

Punkt pierwszy jest oczywisty, natomiast nad pozostałymi dwoma na moment trzeba się pochylić.

Backlog Produktu co do zasady powinien zawierać tylko to, co Product Owner ma intencję zrobić w produkcie, aby uzyskać wartość (przybliżyć się do osiągnięcia Celu Produktu i poprzez to do realizacji wizji). Nie wszystkie takie rzeczy wynikać będą z Celu Produktu. Wyobraźmy sobie bank, w którym Celem Produktu jest umożliwienie dokonywania przelewów walutowych. Czy wystarczy skupić się wyłącznie na tym i mamy pewność, że gdy tylko będzie dało się technicznie przelewy wykonać, Cel Produktu zostanie osiągnięty? I tak, i nie.

Technicznie tak, w praktyce potkniemy się o wytyczne KNF, bez których spełnienia w ogóle przelewów nie będzie nam wolno robić. Inaczej mówiąc, musimy zrobić to, co zaspokoi wymogi regulatora rynku, choć bezpośrednio do osiągnięcia Celu Produktu jest to zbędne – ale ma „odblokować” możliwość skonsumowania wartości, jaką przyniesie jego osiągnięcie.

A co z punktem trzecim? Gdybyśmy budowali tylko to, czego użytkownicy potrzebują i jawnie nazwali, mogłoby się okazać, że produkt po prostu nie da się w ogóle użyć. Bo braknie „spinającej” części rozwiązania, która łączy to, co jest potrzebne użytkownikom, w spójną całość. To „techniczne modelowanie” produktu, o którym mówiłem (krok 5), pozwala w ujawnieniu listy takich rzeczy.

Przy czym dobrą praktyką nie jest dorzucanie ich wprost do Backlogu Produktu jako osobne rzeczy do zrobienia. Jeśli da się tego uniknąć, nie róbmy tego. Najlepiej byłoby połączyć realizację takich funkcjonalności z potrzebami biznesowymi, których uzupełnienie stanowią. W ten sposób Backlog Produktu nie utonie pod listą zadań technicznych do realizacji przez Developerów.

W każdym kroku: Unikanie „raz-a-dobrzyzmu”

Najpierw wyjaśnię, czym jest ów „raz-a-dobrzyzm”: to próba zdefiniowania tego, jak ma działać i być zrealizowany produkt z góry, od razu do stanu docelowego. Lub też próba przewidzenia wszystkiego z góry. Jeśli funkcjonujemy w domenie złożonej, jest to skazane z góry na niepowodzenie.

Sygnałem, że tak się dzieje, jest często dążenie do wykreowania „kompletnego Backlogu Produktu” przez Product Ownera na początku, zanim zacznie się budowanie produktu. Innym sygnałem jest dążenie do tego, żeby wszystkie elementy Backlogu były precyzyjnie opisane, niezależnie od tego, czy da się to w ogóle zrobić i jak nisko na liście się znajdują (im są niżej, tym większe prawdopodobieństwo, że sporo się jeszcze zmieni).

Backlog Produktu powinien być minimalny, ale wystarczający, z elementami opisanymi wystarczająco, ale nie wyczerpująco. W istocie kreowanie Backlogu Produktu po tym, jak powstanie jego pierwsza wersja, staje się procesem ciągłym, który zatrzymuje się dopiero wtedy, jeśli faktycznie nie ma sensu dalej rozwijać produktu.

Warto też pamiętać, że Backlog Produktu nie powinien mieć „zapasu pomysłów na przyszłość”, które zalegają na końcu listy elementów i starzeją się, niedotykane przez kogokolwiek miesiącami. Backlog Produktu to ciągle zmienny plan osiągnięcia Celu Produktu, więc trzymanie w nim rzeczy, które nie są do tego potrzebne, jest błędem.

Dlatego Product Owner powinien regularnie poddawać wszystkie elementy Backlogu Produktu przeglądowi pod względem tego, czy są:

  • wciąż potrzebne – i jeśli nie, usunąć je z Backlogu,
  • wciąż aktualne – i jeśli nie, uaktualnić.

W ten sposób w Backlogu znajdą się tylko te rzeczy, które są niezbędne do osiągnięcia Celu Produktu, albo bez których jego osiągnięcie nie miałoby sensu. Im bliżej będziemy osiągnięcia Celu Produktu, tym prawdopodobniej Backlog stanie się mniejszy – to może być sygnałem, że pora wytyczyć kolejny Cel, który zastąpi ten poprzedni, a po zrobieniu tego dostosować odpowiednio zawartość i kolejność Backlogu.

A co, jeśli Backlog ciągle jest ogromny i się nie skraca nigdy, albo elementy związane z Celem Produktu są w nim w mniejszości – wszystko inne jest potrzebne, ale z zupełnie różnych powodów? Cóż, coś jest nie tak z samą definicją produktu lub być może jest on w schyłkowej fazie, gdzie tak naprawdę siłą rozpędu robione są zmiany, które nie prowadzą do realizacji wizji. Czy warto inwestować w taki produkt? Być może nie, Zespół mógłby poświęcić czas na coś dającego więcej korzyści, a do tego produktu wrócić dopiero wtedy, jak uzbiera się dość pracy, którą naprawdę warto wykonać.