Ogromne idee, dalekosiężne plany, które mają zmienić niejeden biznes oraz…ta jedna wielka niewiadoma, jak to wszystko zrealizować! I to najlepiej w jak najkrótszym czasie! Chciałoby się mieć ten słynny “overnight success”, ale byłoby prościej gdyby tylko ludzie, z którymi pracujemy rozumieli, o co dokładnie nam chodzi.
Niby wszystko jasne, a potem jest release i wychodzą niespodzianki. Nie? Czasem jednak warto wziąć głęboki oddech i zrozumieć, że są na to lekarstwa.
O tych właśnie lekarstwach na (prawie) całe zło naszej produktowej pracy pisze w swojej książce Jeff Patton, ojciec user story mappingu (USM). Swoimi bardzo trafnymi, choć często sarkastycznymi, analogiami pokazuje, jak współpracować nad kompleksowymi rozwiązaniami, aby nie było przy tym zbędnych ofiar.
Jeśli jesteś jeszcze przed lekturą tej pozycji, to tu będziesz miał mały sneak peek – może to wzmoży Twój apetyt na całość. Natomiast jeśli lekturę masz już za sobą, to niech ten artykuł pozwoli odkurzyć przyprószone czasem lekcje produktowe, bo rady, jakimi żongluje J. Patton na kartkach swojej książki, powinny się nam wszystkim dobrze zakotwiczyć w pamięci.
3 lekcje na temat zwinności
To jak? Gotowi? Zatem lecimy! Oto trzy subiektywnie wyselekcjonowane produktowe lekcje godnych zapamiętania z książki “User story mapping”:
1. Uwaga, nadchodzi produktowy frankenstein!

W tym artykule miały być lekcje wprost of Jeffa Pattona, ale muszę to trochę naciągnąć, bo już w samej przedmowie od Alana Coopera pojawiło się kilka zdań, które dzięki swojej wysokojakościowej ironii zachowały się w moim produktowym sercu na zawsze i które warto tu przywołać:
“In Mary Shelley’s famous science-fiction novel, Frankenstein, the mad Doctor Frankenstein builds a creature from disparate pieces of dead humans and brings the creature to life with the then-new technology of electricity. Of course, we know that this is not actually possible. You cannot create life by sewing together random body parts. … Yet this is what software developers attempt to do all the time.”
A jak tam Wasze produktowe Frankensteiny? Jeszcze żyją, czy tylko straszą na produkcji?;)
Rada, jaką daje nam A. Cooper w tych kilku zdaniach, jest prosta – nie zapominajmy o designie, bo nie samym developmentem żyje produkt. Projektując system i planując jakikolwiek release musimy pamiętać, że nasz produktowy pacjent powinien mieć ręce i nogi i oczywiście musi przeżyć. I właśnie do tego kilka rozdziałów potem odnosi się także sam J.Patton:
2. Czy pacjent przeżył po releasie?

Każdy z nas, produktowców, zna termin MVP. Każdy – zapewne – używa tego regularnie, bo przecież to jest takie “zwinne”, nie?
Ale ilu z nas podchodzi do “minimum viable product” jako naprawdę MINIMUM i jako naprawdę VIABLE?
Samo słowo minimum może być subiektywne, więc najpierw musimy ustalić co jest tym minimum dla naszych użytkowników. Nie, nie dla nas produktowców, ani też nie dla szeroko pojętego biznesu, tylko dla użytkowników końcowych. To dla nich dane rozwiązanie, nawet w tej minimalnej wersji, ma przynieść wartość.
Jednak więcej kłopotu może sprawić słowo viable. Oto co na jego temat pisze Patton:
“When we use the term VIABLE when talking about a living organism, it means that an organism can survive in the world on its own without dying. And when we talk about software, we mean the same thing.”
I pamiętajmy, że feature, który okrył się fałdami kurzu, bo nikt nigdy go nie użył, ciężko też nazywać żyjącym. To takie wpół umarłe rozwiązanie, przez które płuca serwera ledwo zipią. Ale tak tylko mówię…
Nie bądźmy jednak tak surowi. Ustalmy, że zakres naszego releasu jest już zdefiniowany na tyle mądrze, że nie jest to Frankenstein i jest na tyle mały, że nie trzeba rozpisywać roadmapy na kilka lat wprzód. Ustalmy, że rzeczywiście idziemy w nasze zwinne MVP, które przeżyje samo na produkcji. To będzie proste, nie?
Niekoniecznie. Ile razy przecież planowaliśmy coś prostego, a finalnie efekt zaskoczył nie tylko nas, ale też wszystkich wokół.
“Przecież nie to miałem na myśli!” – choć na takie komentarze jest już wtedy za późno. Co można było zrobić lepiej?
3. Opowiedz mi historię, a nie pisz mi listów!

Dziwisz się. Było napisane czarno na białym. Acceptance criteria jasno, w punktach, zgodnie ze standardami, a efekt nie jest taki jak oczekiwany.
“Co poszło nie tak? Przecież user stories były tak dobrze opisane!” …Ale czy aby na pewno? Oto co mówi Patton na ten temat:
“Stories get their name from how they’re supposed to be used, not from what should be written”
Jedną z najważniejszych lekcji z USM jest fakt, że sensem dokumentacji nie jest dokumentacja, a rozmowa i zwieńczenie jej WSPÓLNYM ZROZUMIENIEM. Tu caps lock nie jest przypadkowy.
Zatem, drodzy produktowcy, opowiadajmy historię w oparciu o user stories, a nie piszmy długie listy, myśląc, że każdy kto je przeczyta, odbierze je w ten sam sposób! Wymagania, jak każdy pisany tekst, mogą mieć tyle interpretacji, ile mają czytelników. I to jest piękne w książkach i poezji, ale już mniej nam jakoś to odpowiada w przypadku dokumentacji.
I dlatego J. Patton niejednokrotnie powtarza, że dokumentacja – w jakiejkolwiek formie – to tylko snapshot jakieś rozmowy (lub wielu rozmów). To wycinek ze wspólnego zrozumienia całości. Wycinek, do którego łatwo się będzie odwołać przy kolejnych dyskusjach, czy później w developmencie. Bo przecież – i tu uwaga, nadchodzi kolejny świetny cytat – jak należy podkreślić:
Shared documents aren’t shared understanding
Apetyt rośnie w miarę czytania
Ale to tylko skrawek z naprawdę wielu cennych lekcji zwinności od J. Pattona. Mam nadzieję, że zaciekawieni sięgniecie kiedyś po ten tytuł. Wybaczcie mi, ale zrobię tu mały spoiler:
Książka “User story mapping” jest nie tylko o USM. 😉
W oparciu o USM J. Patton przemyca nam dużo więcej – porusza on temat inżynierii wymagań, budowania zespołów, planowania rozwoju produktu, jak i tak popularny teraz temat discovery. Zatem warto, bo do lekcji o USM dostajecie w pakiecie wiele rad na temat prawdziwej zwinności.
I to tyle. Nie zabieram więcej Waszego cennego produktowego czasu. Na koniec tylko pozwolę sobie sparafrazować J.Pattona:
Just like a good software, this article isn’t really done 😉
Bio

Jest to wpis gościnny, którego autorką jest Anna Bąkiewicz (LinkedIn) – pasjonatka zwinności. Jej droga do product managementu rozpoczęła się sześć lat temu od wspierania międzynarodowych projektów IT od strony PMO. Później zaś, szukała swojej ścieżki bliżej developmentu, odkrywając rolę analityka oraz scrum mastera. To jednak wciąż nie było jej przeznaczenie. Finalnie odkryła swoje miejsce i obecnie pracuje jako product owner, tworząc globalną aplikację z obszaru PPM w międzynarodowej korporacji. Poza pracą: miłośniczka przyrody, pasjonatka zagadnień związanych z różnorodnością międzykulturową oraz typ społecznika.
Darmowy fragment „Mapowanie historyjek użytkownika. Przepis na produkt idealny”

Ten artykuł zawiera linki partnerskie. Korzystając z nich wspierasz działalność bloga Project Makers. Dziękuję!