Słowa i produkty. Jak zapisywać pomysły w backlogu?

Wyrażanie pomysłów za pomocą słów potrafi sprawić nam wiele problemów. Nie każdy z nas jest mistrzem pióra, a przecież backlog chcemy mieć możliwie dobry. Chcielibyśmy osiągnąć taką formę, która prowokuje do kreatywnego myślenia (jak odpowiedzieć na dany problem biznesowy), znalezienia właściwych rozwiązań, a potem pomaga deweloperom napisać kod zgodny z tymi pomysłami. Jak to zrobić?

Większość z nas zapisuje pomysły (dotyczące rozwoju produktu) w formie elementów backlogu. Nazywamy je zadaniami, taskami, historyjkami. Ten tekst jest właśnie o tym: jak robić to w sposób przyjazny, czytelny, prowokujący do kreatywnego myślenia. Tekst będzie nie tylko o klasycznych user stories, ale też alternatywach (problem stories i job stories).  

Czym są historyjki?

Historyjki to pewnego rodzaju ramy, które pomagają nam opisać nasz problem biznesowy czy pomysł na zmiany w produkcie. Można o nich myśleć, jak o wskazówkach albo szablonie. Tak czy siak – historyjki to metoda na pisanie w sposób zrozumiały, nawet gdy nie posługujemy się słowem z gracją literata.  Pierwszym popularnym formatem tworzenia historyjek były tzw. user stories. Klasyczna historyjka prezentuje się tak: jako [użytkownik/persona] chcę [czynność/funkcja], aby [cel/po co?]. Konkretny przykład może wyglądać tak: jako osoba prywatna chcę wyróżnić moje ogłoszenie w wynikach wyszukiwania, aby dotrzeć do szerszego grona użytkowników. Taka historyjka użytkownika składa się zatem z trzech elementów:

1. persona, użytkownik = to, dla kogo będzie dana zmiana w produkcie,
2. co = opis tego, co chcemy zmienić,.
3. dlaczego, po co = cel, motywacja, która przyświeca naszemu użytkownikowi. 

Z tych trzech pytań najważniejsze, w mojej opinii, jest pytanie o motywację, chociaż oczywiście „user” w określeniu user stories wskazuje na to, że to persona jest najistotniejsza. Kiedyś miało to dużo sensu, bo stare dokumentacje nie skupiały się za bardzo na użytkownikach, więc autorzy formatu user stories chcieli to zmienić. Obecnie większość z nas rozumie już, że użytkownik powinien być w centrum naszej uwagi i dobrze znamy jego (czyli persony) charakter . W takiej sytuacji odnoszenie się w historyjkach do użytkownika niektórym wydaje się nadmiarowe. Jeśli pozbawilibyśmy historyjkę tego elementu i elementu czynności (tego, co chce  zrobić użytkownik), ale pozostawili motywację (problem biznesowy, po co), to moglibyśmy nadal prowokować do ciekawych rozmów. I to „dlaczego, po co” jest wspólną cechą wszystkich rodzajów historyjek, także alternatyw dla klasycznego user story, o których w dalszej części tekstu. 

Wiele razy obserwowałem frustrację deweloperów, którzy nie wiedzieli, po co danemu użytkownikowi jakaś funkcja. Przez to nie rozumieli, jaki problem mają rozwiązać, trudniej im było zaproponować odpowiedź. Gdy znają „dlaczego”, są w stanie wyjść poza szablonowe myślenie, podsunąć coś swojego. Ba! Czasem, w trakcie dewelopmentu, mogą dzięki dobremu „dlaczego”, zmienić delikatnie koncepcję (jak ma działać dana funkcja), bo rozumieją, że w historyjkach nie chodzi o to, aby ślepo realizować wymagania, ale myśleć o najlepszym rozwiązaniu problemu. 

Historyjki użytkownika stały się popularne wiele lat temu, bo były jak powiew świeżego powietrza w długo zamkniętym pomieszczeniu klasycznych dokumentacji. Były alternatywą dla opasłych opisów projektów, pisanych przez wiele dni, w bezosobowy sposób, przedstawiających wymagania biznesowe. Historyjki użytkownika to nie wymagania, a użytkownik powinien być w centrum naszej uwagi. One opowiadają o kimś – o naszych klientach i ich problemach. Nie mówią też od razu, jak coś trzeba rozwiązać. Przedstawiają potrzeby. Zachęcają do dyskusji. Efekt tych dyskusji można potem do tych historyjek dopisać (np. w postaci kryteriów akceptacyjnych), dzięki czemu doprecyzowujemy je i podczas dewelopmentu nasz zespół wie, co ma zrealizować. 

Alternatywy dla klasycznych user stories

User stories były powiewem świeżego powietrza w podejściu do opisywania naszych pomysłów, problemów biznesowych i projektów. Jednak z czasem stały się standardem i… okazało się, że nie każdemu one odpowiadają. Oprócz tego, że niektóre zespoły uznały za nadmiarowe pisanie każdorazowo o tym, dla kogo coś robią, to wydawały się często długie i niewygodne w szybkim pisaniu (a często piszemy podczas zespołowych dyskusji i chcemy sprawnie zamienić myśli na słowa). Mamy kilka alternatyw, a dwie z nich są naprawdę proste i świetnie potrafią zastąpić klasyczne historyjki użytkownika.

Job stories – historyjki o tym, co jest do zrobienia (i po co)

Job stories zostały ponoć wymyślone przypadkowo przez pracowników Intercom, o czym można przeczytać na ich firmowym blogu. Jak nazwa wskazuje, nie skupiają się one już na użytkownikach, ale na tym, co jest do wykonania. Ich format wygląda w ten sposób: gdy [sytuacja], chcę [zdarzenie], po to, aby [coś osiągnąć, cel, oczekiwany rezultat].  Na przykład: gdy dodam ogłoszenie, chcę je dodatkowo wyróżnić (etykieta na zdjęciu) w wynikach wyszukiwania, po to, aby dotrzeć do szerszego grona użytkowników. 

Nie ma tu zatem mowy o użytkowniku – teoretycznie z takiego zapisu nie wiemy, dla kogo mamy wykonać jakąś zmianę w produkcie. Job stories skupiają się zatem na dookreśleniu naszego pomysłu na zmianę, określamy sobie nieco bardziej szczególne warunki (część „gdy [sytuacja]”), co powoduje, że historyjka zdaje się być bardziej konkretna niż otwarty klasyczny format user stories. Oczywiście, nie każdemu będzie ten format odpowiadał. Czasem zdania wychodzą całkiem długie. Jeśli zatem zależy nam na jeszcze większej prostocie, można spróbować problem stories. 

Opowiedz mi o problemie, czyli problem stories

Dobre zespoły produktowe skupiają się na użytkowniku, chcą rozwiązać jego problem. I tu przychodzą nam z pomocą problem stories. Format takiej historyjki to: w celu [rozwiązania jakiegoś problemu] zbudujemy [funkcja, zmiana]. Na przykład: w celu zwiększenia oglądalności wybranych ogłoszeń zbudujemy system ich wyróżnień. 

To niezwykle łatwa konstrukcja szablonu, dzięki czemu  łatwo ją wyjaśnić zespołowi i wcielić w życie. A jednocześnie skupia się ściśle na tym, co istotne  – na problemie biznesowym. Problem stories opowiadają o najważniejszym, czyli „dlaczego, po co?” w najbardziej bezpośredni sposób (porównując do wyżej wspomnianych alternatyw). Przy okazji są najkrótsze, co według mnie jest ich kolejną zaletą. No i dość precyzyjne – w historyjce piszemy od razu o tym co chcemy zbudować. Ale uwaga na pewna pułapkę, czyli  narzucenie zespołowi rozwiązania problemu, a więc niejako zamknięcie dyskusji. Jak ją ominąć? Świetnie do tego nada się sesja doskonalenia Backlogu – tzw. Backlog Refinement. Na tym spotkaniu macie czas i przestrzeń, aby rozmawiać o szczegółach pomysłów. Regularne odbywanie takich spotkań bardzo pomaga utrzymać Backlog w dobrym stanie. Wystarczy zespołowi zaprezentować pierwszą część Problem Story, a drugą wypracować z zespołem wspólnie, np. na takiej sesji doskonalenia Backlogu właśnie. Przykładowo najpierw do niego dodać element “W celu zwiększenia konwersji…”, a potem w wyniku dyskusji można uzupełnić o to co nam z nich wyjdzie “zmienimy formularz zamówienia”. 

Który format wybrać? 

Możesz mieć wątpliwości, który format będzie najlepszy. Tak naprawdę jednak nie ma znaczenia, jaki format wybierzesz – ważne jest to, aby odpowiadać na najważniejsze pytania: dlaczego, po co,  co, dla kogo? Dopóki to robisz, to jesteś na dobrej drodze. Formaty mogą w tym pomóc i, co do zasady, odpowiadają na te pytania (albo mogą być o takie odpowiedzi łatwo uzupełnione). Różnią się jedynie tym, na czym się skupiają (użytkowniku, zmianie, problemie). Nie musisz się ich ściśle trzymać. 

Mieszanie formatów albo własny format

Nikt nie powiedział, że formatów nie można mieszać albo wymyślać własnych. To w końcu backlog Twojego produktu i to Ty, razem ze swoim zespołem, decydujesz o jego charakterze czy kształcie. Dlatego formaty należy traktować jako ramy, ale bardzo elastyczne. Możesz zatem do każdej historyjki stosować dowolne podejście lub  je mieszać. Możesz też wypracować swój własny styl czy sposób, ale weź pod uwagę kilka kwestii. Stosowanie jednego formatu to ułatwienie dla wszystkich – w pewnym momencie każdy potrafi pisać w danym stylu i praca idzie szybciej. Jednocześnie jest to ograniczające – stosując job stories możesz gubić persony, a np. akurat dla danego pomysłu personę warto byłoby podkreślić. Niestety, nie podam Ci finalnej, uniwersalnej odpowiedzi rozwiązania tego problemu, trzeba to po prostu przetestować na swoim produkcie. 

Wypracuj wspólny standard ze swoim zespołem

Oczywiście w praktyce może być tak, że tylko jedna osoba tworzy elementy backlogu produktu. Najczęściej będzie to Product Owner lub osoba o podobnej roli. Jak pisałem wyżej, możemy w ten sposób ograniczyć wkład deweloperów, a tego byśmy nie chcieli. Praktyka pokazuje, że historyjki, niezależnie od formatu, najlepiej gdy są wypadkową rozmów osób o różnych specjalizacjach (biznes, Product Owner, technologia i deweloperzy, doświadczenie użytkownika, dizajner…) – w ten sposób uzyskujemy holistyczne podejście. Ale jak to zrobić, aby każdy potrafił posługiwać się formatami w podobny sposób i rozumiał ich istotę? Trzeba wypracować wspólny standard. I jest na to dość prosty przepis. 

W szczegółach o warsztacie pisania historyjek  pisałem na blogu k85.pl. Zasadniczo polega to na tym, aby w podgrupach (lub każdy osobno, w zależności od rozmiaru zespołu), stworzyć początkowe, pierwsze wersje historyjki, a następnie przekazać je dalej kolegom do oceny i korekty. Przykładowo: Kasia napisała historyjkę i przekazała Jackowi, Jacek swoją przekazał Gosi, a Gosia poprosiła o ocenę i korektę Kasię. Następnie wypada przedyskutować i ustalić ewentualne zasady. W ten sposób każdy doświadcza tego samego procesu i na konkretnych przykładach kształtujemy swój standard. Można, przed napisaniem tych historyjek, narzucić format lub pozostawić go dowolnym, ale zaznaczyć, że historyjki muszą odpowiadać na wybrane pytania (np. dlaczego, po co?). 

Backlog nie musi być tylko zapisem słownym. Jego treści można prezentować na wiele sposobów i uzupełniać o różne załączniki. 

Wizualizacja

Moc obrazu ciężko przecenić. Dlatego tam, gdzie to możliwe, wspieraj się załącznikami: makiety, dizajny, nawet luźne szkice ołówkiem – wszystko to pomaga wyrazić w inny sposób, często bardziej zrozumiały,  istotę problemu lub rozwiązania. Ponadto:  im bardziej złożony problem, tym większa potrzeba używania obrazów. Innymi słowy – czasem jedno zdanie nam wystarczy, aby przejść do działania. Kiedy indziej okaże się, że bez rozbudowanych diagramów lub makiet nie uda nam się ustalić porozumienia. Świadome używanie narzędzi i dodawanie obrazów to ważna umiejętność przy budowaniu backlogu produktu. Jednocześnie przestrzegam przed jedną pułapką: makiety czy dizajny sugerują ostateczne rozwiązanie. Ważne jest zatem, aby podkreślić, że „jeszcze możemy zmienić to, co widzicie” lub stosować tzw. wersje lo-fi, które swoim wyglądem sugerują, że są niejako szkicami, gotowymi na komentarze i zmianę. 

Dane

Oprócz obrazków pomocne mogą okazać się dane. Jeśli dołączymy do historyjki metryki, dotyczące np. zachowań naszych użytkowników w części naszego produktu, którą chcemy zmienić, to otwiera się przed nami całe spektrum możliwości do dyskusji. Polecam stosować szczególnie  wtedy, gdy chcemy:

• rozbudzić dyskusję o problemie biznesowym,
• uczyć zespół produktu, np.  tego jak zachowują się użytkownicy,
• zwiększyć świadomość deweloperów o stanie produktu.

Dalszym krokiem może być sprawdzenie tych samych metryk za jakiś czas,  np. miesiąc po oddaniu zmiany lub funkcji naszym użytkownikom. 

Krótko i na temat

Dokładniejsze opisy naszych pomysłów i problemów biznesowych to złudne poczucie kontroli nad tym, że otrzymamy na koniec to, co chcemy otrzymać. Dlatego niektórzy z nas mają tendencje do rozbudowanych opisów, dodawania wielu załączników. Jednocześnie członkowie zespołu, widząc że opis jest szeroki, a zatem w domyśle nieźle przemyślany, mogą niekoniecznie chcieć go zmieniać – widzą, że ktoś się już napracował lub mają poczucie, że temat został wyczerpany albo muszą przebrnąć przez dużo treści, aby zrozumieć wszystko dokładnie. W ten sposób tracimy szansę na dyskusję, a pierwotnie to m.in. o to chodziło w historyjkach: aby dyskutować. Mało tego, na pewnym poziomie ilość treści jest tak duża, że zaburza nam wręcz tę czytelność. 

Zachęcam zatem do czegoś innego. Zacznijcie z minimalną ilością treści – taką, która jest wystarczająca do wyjaśnienia o co chodzi, ale nic więcej. Czasem będzie to zwykłe „30% użytkowników porzuca proces zakupu na kroku 4 z 5 – jak to rozwiążemy?”. W wyniku rozmów możecie uzupełnić opis (np. o kryteria akceptacji, więcej szczegółów). Najpierw warto rozpocząć dyskusję, a potem ich wynik ubrać w ramy historyjek, opisów i wszystkiego, co będzie potrzebne do dewelopmentu. 

Nie trzeba być dobrym w posługiwaniu się słowem, aby backlog robił to, co ma robić: aby  prezentował pomysły i problemy biznesowe (a potem rozwiązania) w przejrzysty i zrozumiały sposób.  Jeśli mamy trudności z jego prowadzeniem, to możemy skorzystać z kilku pomysłów: dobrać odpowiednie formaty zapisu, świadomie kierować dyskusjami (zaczynając od minimum) czy uzupełniać historyjki o właściwe dodatki. Kilka prostych praktyk – czasem tylko tyle trzeba do świetnego backlogu.