Nasza strona używa cookies. Korzystając ze strony, wyrażasz zgodę na używanie cookies, zgodnie z aktualnymi ustawieniami przeglądarki. Rozumiem

Jak wytłumaczyć biznesowi, że User Stories są ważne?

Krzysztof Pawłowski Scrum Master/ Agile PM Practitioner/ Project Manager
Dowiedź się jak przemówić do rozsądku wybranych. Poznaj najważniejsze argumenty, których warto użyć w dyskusji "dlaczego User Stories jest ważne".
Jak wytłumaczyć biznesowi, że User Stories są ważne?

Project Manager prowadzący projekty musi umieć porozumieć się z biznesem oraz osobami technicznymi — zazwyczaj zespołem deweloperskim. I choć Agile jasno stanowi "ludzie i interakcje ponad procesy i narzędzia", to jednak niektóre narzędzia istnieją i warto z nich korzystać. Jednym z nich jest user story.

User story, czyli historyjka użytkownika wbrew pozorom nie jest obligatoryjna. Jednak z powodu jej popularności i powszechności uznaje się to za standard.

Powyższe warto zapamiętać choćby jeżeli przygotowuje się do egzaminu Agile PM, ponieważ takie pytanie może  się pojawić.


Dlaczego user story jest tak popularne?

Wynika to z faktu jasnej struktury. Każdy komponent user story jest potrzebny i łatwy do zrozumienia. Implementacja wymaga już jednak wprawy, którą ze względu na lekkość i powszechność można na szczęście bez problemu nabyć.

Jako ktoś [odbiorca usługi] chcę coś [wartość dodana], aby [uzasadnienie wprowadzenia zmiany].

Z doświadczenia wiem, że dobrze napisane wymagania za pomocą user story, muszą być zrozumiałe zarówno dla zespołu deweloperskiego jak i biznesu. Najlepiej, żeby pracowali na tym samym dokumencie, dzięki czemu unikniemy rozbieżności wersji. O ile raczej programiści bez problemu zrozumieją dobrze napisane historyjki, o tyle biznes często możne je uznać za dziwne i sztuczne.

Dlatego przed powszechnym stosowaniem warto poświęcić trochę czasu na edukację otoczenia — dlaczego user story i czemu tak wygląda. Poniżej przedstawię, jak ja implementując użycie tego sposobu przedstawień wymagań biznesowych w organizacji, tłumaczyłem strukturę i celowość poszczególnych elementów historyjek użytkownika.

Korporacje kochają mówić, że klienta (albo żeby podkreślić szacunek, piszą wręcz Klienta) stawiają na pierwszym miejscu, w centrum uwagi. Nazywam to zjawisko "klientocentryzmem". Jako ciekawostkę zaprzeczającą takiemu podejściu podeprę się cytatem Sir Richarda Bransona, z którym osobiście się w pełni zgadzam, szczególnie w kontekście domniemanego “rynku pracownika”.

“Clients do not come first. Employees come first. If you take care of your employees, they will take care of the clients.”

Ma sens, patrząc na fakt, że wiele firm zaniedbuje pracownika kosztem klienta. Zazwyczaj zmiany wprowadzane są “z myślą o kliencie”, a ty, pracowniku, masz z uśmiechem na ustach przestawić się na narzucone zmiany. Rozumiesz? Nie musisz. Jesteś od wykonywania, a nie myślenia.

A wytłumaczenie zmiany, jak wpłynie na pracownika i jego pracę, pozwoli skrócić czas wdrożenia zmiany oraz zmniejszyć szansę porażki. Podejście powoli się zmienia, natomiast jeszcze dużo wody w Wiśle upłynie, zanim partnerskie podejście do pracownika, szczególnie w korporacjach nie będzie egzotyką, a wręcz standardem.


Wracając jednak do klientocentryzmu i samego user story

Prawidłowe zastosowanie historyjek użytkownika, szczególnie jej pierwszej części, a więc prawidłowego określenia podmiotu czy też adresata zmiany, pozwala powiedzieć takiej organizacji "sprawdzam". Jak? Zadać pytanie organizacji “Czy naprawdę myślisz o kliencie tak, jak mówisz?”

Jeżeli firma ABC powie, jako firma "chce dać klientowi możliwość zalogowania…" to znaczy, że nie stawia klienta na pierwszym miejscu. Tak, chcemy dać klientowi możliwość zalogowania. Ale to nie firma będzie się logować. To klient. Dlatego, aby lepiej zrozumieć, po co i dla kogoś coś robimy, wejdźmy w jego buty. Myślmy jak klient i starajmy się podążać jego ścieżką.

Nam jako organizacji może wydawać się, że 10 reklam na stronie będzie super, bo dzięki temu mamy większe szanse na sprzedaż. Ale ten sam klient po 3 się zdenerwuje i wyjdzie ze strony. Dlatego perspektywa tego użytkownika końcowego w historyjce jest taka kluczowa.


Kolejnym elementem jest opis wartości dodanej.

Ja to porównywałem do streszczenia książki, która ma w kilku słowach zdradzić treść, myśl przewodnią. W pisaniu wymagań biznesowych spotkałem się z 2 szkołami odnośnie użycia user story i przedstawienia wartości dodanej. Pisanie każdego zdania w wymaganiach biznesowych za pomocą user story jest wtedy próbą przedstawienia absolutnie wszystkiego w ten sposób, za pomocą wielu zdań.

Taki dokument, szczególnie na początku może być trudny do zrozumienia dla biznesu. Zdecydowanie łatwiej, gdy zastosujemy hybrydę, to znaczy dodamy do tego kryteria sukcesu. Są one również znane i popularne, a dodatkowo pisane bardziej “ludzkim” językiem o wiele łatwiejsze do zrozumienia. W takim przypadku historyjka jest tylko zajawką, natomiast szczegóły przedstawia się dalej. Poniżej krótki przykład takiego podejścia.

Jako klient chce mieć przycisk rejestracji, abym mógł założyć konto w serwisie.
- przycisk ma być w prawym górnym rogu
- przycisk ma być niebieski
- przycisk ma być umieszczony po lewej stronie przycisku do logowania
...

Taki sposób zapisu pozwala stworzyć dokument uniwersalny dla obu stron, to znaczy zawierający na tyle dużo konkretnych informacji, że powinien być zrozumiany przez wszystkie zaangażowane strony. Osobiście piszę go w taki sposób, że przedstawiam go biznesowi do zaakceptowania, potem do grafików, żeby stworzyli makiety, do działu prawnego celem przygotowania regulaminu itd., aż na jego podstawie tworzę wymagania dla zespołu deweloperskiego. Staram się go tak utworzyć, aby konkretne zadania dla dev teamu były niemal tworzone na zasadzie "kopiuj — wklej" z dokumentu.


Uzasadnienie

Ostatni element z doświadczenia mogę powiedzieć, jest najtrudniejszy do wytłumaczenia i zrozumienia przez biznes. Uzasadnienie. Po co coś jest robione. Gdy próbowałem innych osób uczyć korzystanie z user story, opór w stosowaniu uzasadnienia był największy. Dlaczego? Bo to najtrudniej napisać. Padały też argumenty, po co mam pisać, dlaczego to chcę?! Chce i koniec!

Tłumaczenie wymagało ode mnie największej dawki cierpliwości i miękkiego podejścia. Odpowiedź w stylu "stosujemy user story, to jest część i ma się znaleźć" jest najgorsza z możliwych. Nie dość, że zamiast mostu porozumienia zbudujemy mur, zrazimy ludzi do siebie i do historyjek to jeszcze nie uzyskamy efektu jakościowego. Czyli po prostu będą one pisane w zły sposób. Czyli zamiast sprawdzać, będziemy ciągle poprawiać.

Jak w takim razie to wytłumaczyć? Pisząc maila czy wysyłając zaproszenie na spotkanie często opieram to na elementach user story z mocno rozbudowanym uzasadnieniem. Poniżej przykład wiadomości proszącej o to samo:

Wyślij mi wyniki sprzedaży produktu X od początku roku.
Albo:
Wyślij mi wyniki sprzedaży produktu X od początku roku. W czwartek spotykamy się z marketingiem by sprawdzić w których miesiącach produkt sprzedaje się słabiej i należy wzmocnić kampanią marketingową.

W obu przypadkach proszę o to samo. Ale zdecydowanie lepszy wynik odniosę drugą wiadomością. Pisząc po co (spotkanie i analiza miesięcznej sprzedaży) nie dostanę cyfry zbiorczej, ale mam większą szansę otrzymania wyników comiesięcznych. Być może odbiorca nawet przygotuje wykres obrazujący tę sprzedaż :).

Na marginesie druga wiadomość zostanie również lepiej odebrana i szybciej wykonana. Ludzie lubią czuć, że ich praca jest ważna i istotna dla innych. Że od nich coś zależy. W tym przypadku raport sprzedażowy będzie analizowany, a nie pójdzie do szuflady.  Dlatego będzie lepszej jakości, a dwa — ktoś poczuje się istotny, chętniej coś wykona i prawdopodobnie dostaniemy to, co chcemy, zdecydowanie szybciej.

Powyższy przykład bardzo dobrze obrazuje konieczność stosowania uzasadnienia (nie tylko) w user story. Dzięki temu osoby pracujące nad naszą funkcjonalnością zrozumieją, po co coś robimy. Znacząco to ograniczy ryzyko innego zrozumienia zagadnienia, zwiększy jakość oraz efektywność wykonywanych zadań.


User story jako nośnik informacji w wymaganiach biznesowych

Pozwala to na ograniczenie dokumentacji, jest dokładne i przejrzyste. Dzięki temu łatwo wyłapać braki lub nieścisłości (w pewnym stopniu zahacza o pryncypium Komunikuj się ciągle i JASNO). Uniwersalność wyklucza konieczność przepisywania i tłumaczenia, co ogranicza ryzyko potencjalnych błędów i rozbieżności. 

Oczywiście są i inne sposoby pisania wymagań biznesowych. Również dość często spotykany był brief, czyli jak ja to nazywam opis słowno-muzyczny wymagań. Ma jednak to taką wadę, że bardziej przypomina opowieść, co chcę mieć. Podczas pisania łatwiej jest coś pominąć lub nie dopowiedzieć, oraz dla programistów nie stanowi takiej wartości jak opis bazujący na user story.

Często dzieląc zadania do sprintów i tak trzeba przerobić to na user story. Dlatego, aby polepszyć efektywność i zrozumienie warto od razu przyjąć ten standard pisania jako obowiązujący.

Rozpocznij dyskusję

Lubisz dzielić się wiedzą i chcesz zostać autorem?

Podziel się wiedzą z 160 tysiącami naszych czytelników

Dowiedz się więcej