Blog

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 po co właściwie ten Scrum? I po co Product Owner? Niechaj Developerzy pod wodzą sensownego kierownika 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 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 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 czyje i jakie oczekiwania odpowiada.
• Dlaczego warto go zbudować i co właściwie jest tą wartością, którą przyniesie.
• Kto będzie z produktu korzystał i w jaki sposób.

Oczywiście nie chodzi tu o rozważania, jakie konkretne cechy lub funkcjonalności będzie miało rozwiązanie, które zbudują Developerzy. Chodzi o ogólny charakter rozwiązań, np. o ustalenie, ż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 tak wizja produktu, jak i sam produkt, są 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 zawsze 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 jakiegoś stanu docelowego, jaki dzięki rozwojowi produktu ma zostać osiągnięty. 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 – wciąż jednak nie będzie to jeszcze Backlog Produktu. Chodzi o stworzenie modelu (np. w formie popularnych canvasów różnego typu) tego, czym produkt ma być. To pozwoli sformułować istotne pytania i uzyskać odpowiedzi na nie. Przykłady takich pytań:

• 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 sfinansowany zostanie jego rozwój?

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

Celem modelowania nie jest stworzenie planu projektu ani nawet Backlogu Produktu, ale uzyskanie trzech rzeczy:

• Jawnej i jednoznacznej listy wszelkich założeń, jakie poczynione zostały w trakcie rozważań nad produktem.
• Odpowiedzi na kluczowe pytania, od których zależy sensowność i kierunek rozwoju produktu.
• Definicji miar, które najpierw pozwolą ocenić, czy produkt w ogóle ma sens, a 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 i staramy się przeformułować wizję. 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. Być może dysponujemy modelem typowego użytkownika (albo persony, jeśli posłużyliśmy się techniką ich opisywania) oraz oceną liczby takich potencjalnych użytkowników. Wciąż jednak możemy kompletnie się mylić co do potrzeb takich ludzi albo choćby ich rzeczywistego istnienia lub liczebnoś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ć na pewno, 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 przeprowadzona w takim zakresie, w jakim 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? Wyjaśnieniem, do czego dążyć będziemy w ramach realizacji wizji, co chcemy osiągnąć. 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órego często używam 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 na początek najbardziej potrzebne będzie przeniesienie obiegu dokumentacji księgowej z wersji papierowej do elektronicznej, bo to krok niezbędny do zrobienia czegokolwiek bardziej zaawansowanego. Dlatego sensownym Celem Produktu mogłaby być właśnie digitalizacja obiegu dokumentacji w firmie. Oczywiście nie chodzi o samo posiadanie możliwości przeprowadzenia digitalizacji, ale o faktyczne przeniesienie obiegu dokumentacji do domeny cyfrowej.

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.

Aktualnie obowiązujący Cel Produktu w pewnym momencie uda się osiągnąć albo zbliżyć do jego osiągnięcia w stopniu wystarczającym, by pojawiła się potrzeba wytyczenia Celu kolejnego. 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 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 chodzi o to, by wytworzyć mechanizmy automatyzacji, ale o wykorzystanie automatyzacji do zredukowania ilości pracy wykonywanej przez księgowych.

Po osiągnięciu tego drugiego Celu Produktu wyznaczony zostaje Cel kolejny i proces się powtarza. Dzieje się tak, dopóki Product Owner uznaje za opłacalną dalszą pracę nad produktem, a potrzeby interesariuszy pozwalają na definiowanie kolejnych Celów wartych osiągnięcia.

Uwaga: czasami nie udaje się żadnego sensownego Celu Produktu określić. To silny sygnał, że coś może być nie tak z 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ę Celu wytrząsnąć 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 oczekują od niego interesariusze, 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 jest nieprzesadnie złożona, zapewne można przejść od razu do kreowania Backlogu Produktu. Jeśli produkt jest bardzo rozbudowany lub gdy istnieje wiele różnych sposobów osiągnięcia wyznaczonego Celu Produktu, konieczne może okazać się stworzenie jednego lub wielu modeli, które pozwolą na eksplorację możliwych rozwiązań.

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ł. Wspomniane powyżej modele rozwiązań mają za zadanie ujawnić, jakich funkcjonalności potrzeba w produkcie, który pozwoli osiągnąć przyjęty Cel bez wnikania w sposób ich implementacji.

Istnieje wiele technik (User 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. Są to mechanizmy, których teoretycznie nikt nie potrzebuje, ale gdyby ich nie było, produkt byłby bezużyteczny. Na przykład, czy ktoś desperacko chce rozrusznika w samochodzie z silnikiem spalinowym? 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 urządzenia samochód przestałby służyć podstawowemu celowi, dla jakiego powstał.

I tu ważna uwaga: to, że da się zidentyfikować kluczowe funkcjonalności, nie oznacza bynajmniej, że należy je od razu zapisać w Backlogu Produktu jako rzeczy do zrobienia. Być może ostatecznie tak właśnie się stanie, ale niekoniecznie w każdym przypadku.

Krok 6: tworzenie zrębów Backlogu Produktu

Tak, to już! Teraz można zacząć to robić. Już wiemy jaki produkt chcemy zbudować (bo istnieje jego wizja i modele) i wytyczony został Cel Produktu, więc można zacząć tworzyć plan, który umożliwi jego osiągnięcie. Przy czym nie polega to na tym, że 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, których zaspokojenie skutkować będzie przybliżaniem się do osiągnięcia Celu.

Dobrym schematem działania przy tworzeniu Backlogu jest poniższa krótka lista:

1. Najpierw identyfikujemy kluczowe potrzeby, których zaspokojenie będzie równoznaczne z osiągnięciem Celu Produktu.
2. Potem dodajemy do tej listy to, co bezwzględnie musi być zrobione, aby Cel Produktu w ogóle był osiągalny.
3. Na koniec uzupełniamy Backlog o rzeczy, które są potrzebne, by produkt działał w ogóle i aby działanie to było spójne, stabilne, bezpieczne itd.

Punkt pierwszy jest oczywisty, bo obejmuje to wszystko, czego ukończenie efektywnie przybliża produkt do osiągnięcia wytyczonego Celu. Inaczej mówiąc, są to rzeczy, które wprost związane są z Celem Produktu.

Drugi punkt już nie jest tak oczywisty. Backlog Produktu co do zasady powinien wynikać z Celu Produktu, bo jest planem jego osiągnięcia, ale nie jest tym Celem sztucznie ograniczony. Product Owner ma prawo, a nawet obowiązek umieścić na liście również opisy takich zmian w produkcie, które są niezbędne z innych powodów niż podążanie ku Celowi Produktu. Niezrobienie tych rzeczy spowodowałoby, że rozwój produktu zostanie zablokowany, a jeśli uda się wytworzyć w nim pożądane mechanizmy i cechy, z jakiegoś powodu (np. prawnego) produktu nie będzie można używać.

Wyobraźmy sobie bank, w którym Celem Produktu jest umożliwienie dokonywania przelewów walutowych. Czy w momencie, gdy już będzie można przelewy wykonywać, Cel zostanie osiągnięty? Teoretycznie tak, ale w praktyce potkniemy się o wytyczne KNF, bez których spełnienia mechanizm przelewów w ogóle nie będzie mógł zostać udostępniony klientom banku. Inaczej mówiąc, musimy zaspokoić wymogi regulatora rynku, mimo iż bardziej utrudniają one, niż ułatwiają osiągnięcie Celu Produktu, bo dokładają pracy i narzucają różne ograniczenia. To jedyny sposób, aby odblokować możliwość wykorzystania wartościowych rozwiązań, jakie zostały wytworzone w ramach prac nad Celem Produktu.

Ktoś powie, że wspomniane w przykładzie wymogi KNF są częścią prac nad Celem Produktu i nie ma powodu, by wydzielać je do osobnej kategorii. To prawda i wielu Product Ownerów postąpi właśnie tak, a w praktyce nie wpłynie to na zawartość Backlogu Produktu. Ja jednak zachęcam do takiego dzielenia zbioru zmian w produkcie na różne kategorie z trzech powodów:

• żeby sprowokować do przyjęcia różnych perspektyw, postawienia właściwych pytań i w ten sposób zminimalizować ryzyko pominięcia czegoś, co bezwzględnie musi być zrobione,
• żeby ułatwić identyfikację zależności i ustalenie najsensowniejszej kolejności realizacji poszczególnych elementów,
• a przede wszystkim po to, by Developerzy lepiej rozumieli, dlaczego coś jest potrzebne, czyli żeby nie dostawali jedynie informacji, że coś ma być zrobione, bez wyjaśnienia powodów.

A co z punktem trzecim? Gdybyśmy budowali tylko to, czego użytkownicy potrzebują i co narzucają nam różne standardy, przepisy itd., mogłoby się okazać, że produktu po prostu nie da się w ogóle użyć. Brakowałoby w nim kluczowych mechanizmów, które spinają w spójną całość to, co jest potrzebne użytkownikom. Modelowanie rozwiązań, o którym pisałem w kroku piątym, pomaga 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 łączyć realizację takich funkcjonalności z tymi 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 z góry tego, jak ma działać i być zrealizowany produkt, jego stanu docelowego. Jeśli funkcjonujemy w domenie złożonej, jest to skazane 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ć z dużym wyprzedzeniem 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, kiedy faktycznie nie ma sensu dalej rozwijać produktu.

Warto też pamiętać, że Backlog Produktu nie powinien zawierać w sobie listy pomysłów na przyszłość, które na razie nie będą realizowane, 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 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, natomiast 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 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ć.