W dzisiejszym dynamicznym świecie oprogramowania, sukces zależy nie tylko od technologii, ale także od skutecznego zarządzania i komunikacji z klientem.
Jednym z naszych głównych wyzwań w projekcie DealerCRM było umożliwienie użytkownikom przeprowadzania prerejestracji kont w zewnętrznej aplikacji, do których dostęp jest ograniczony. To właśnie takie wyzwanie podjęliśmy w naszym projekcie.
To wyzwanie samo w sobie stanowiło istotny krok w kierunku zwiększenia konwersji oraz liczby dokonywanych prerejestracji, co z kolei przyczyniło się do sukcesu naszego Klienta.
W tym artykule zgłębimy, jakie kroki podjęliśmy, aby spełnić ten cel i jak dobrze rozpisane User Story stało się kluczowym narzędziem w naszym sukcesie. Poznamy także przykładowe User Story, które pomogły nam osiągnąć zamierzone cele i uczynić nasz projekt jeszcze bardziej efektywnym.
Niedokładna analiza wymagań prowadzi do wzrostu kosztów projektów.
Klasyczny przykład wygląda następująco: oczekiwania klienta są spisywane w formie zadania z lakonicznym opisem i bardzo szybko przekazywane do programisty. Programista w swoim zrozumieniu napisał kod, który potem umieścił na wybranej instancji testowej. Podczas testów Klient wskazuje, że dostarczone rozwiązanie nie spełnia jego oczekiwań. Zwraca uwagę na aspekty, które nie były wcześniej określone w specyfikacji, lecz z jego perspektywy są kluczowe i dostawca powinien je uwzględnić. W efekcie pojawia się szereg zmian i nowych funkcjonalności, które wymagają modyfikacji obecnej struktury, nieprzewidzianej w pierwotnej analizie.
Niestety, taki niefortunny układ zdarzeń prowadzi do zwiększenia kosztów i czasu realizacji projektu. Rośnie irytacja klienta oraz frustracja po stronie dostawcy, ze względu na niedotrzymywane terminy oraz dowiezienie aplikacji, które kompletnie nie zaspokaja potrzeb Klienta.
Jak tego uniknąć?
Od samego początku projektu wiedzieliśmy, że kluczem do osiągnięcia celu będzie precyzyjne zarządzanie wymaganiami i ścisła komunikacja z klientem. To właśnie tutaj dobrze rozpisane User Story miało kluczową rolę.
Jednakże czym jest to "User Story"?
User Story, czyli "opowieść użytkownika", to krótka, zrozumiała i łatwa do przyswojenia forma opisu wymagań w projektach związanych z rozwojem oprogramowania. Jest to narzędzie często stosowane w metodyce Agile, które pomaga zrozumieć, jakie funkcje lub zadania są potrzebne, aby sprostać oczekiwaniom użytkowników.
Typowe User Story skupia się na tym, kto jest użytkownikiem, co chce osiągnąć i dlaczego to jest istotne. Stanowi prostą i klarowną bazę do komunikacji między zespołem projektowym a klientem lub interesariuszami. User Story jest zaproszeniem do dyskusji nad konkretnymi potrzebami i funkcjonalnościami, pomagając zrozumieć, co jest najważniejsze dla użytkowników, a jednocześnie dostarcza wartość wytwarzanego oprogramowania.
Przykłady:
Jako Sprzedawca mogę dokonać wstępnej rejestracji konta Klienta za pośrednictwem dedykowanego formularza, dzięki czemu będzie mu łatwiej dokończyć ten proces samodzielnie.
Jako Sprzedawca otrzymuję przypominające zadanie o dokonaniu wstępnej rejestracji konta Klienta, dzięki czemu nie muszę pamiętać o tej czynności za każdym razem.
Jako Sprzedawca mogę wgrać skan zgody, jaką wyraził Klient do procesu sprzedażowego, dzięki czemu można w łatwy sposób wrócić do tego dokumentu.
Sformułowanie "zaproszenie do dyskusji" jest w tym przypadku kluczem. Po spisaniu takiego wymagania należy się spotkać i porozmawiać o konkretnym przypadku. Należy zadać sobie kilka pytań: Dlaczego to jest istotne? Jaka jest tego wartość? A co, jeżeli X? Skąd użytkownik będzie to wiedział? Jak to można zrobić?
Uwaga! Niektóre analizy potrafią wciągnąć na kilka godzin, więc takowe spotkania analityczne należy dawkować z rozsądkiem ;)
W naszym przypadku każde oczekiwanie Klienta było spisane w formie opisanego powyżej User Story, które niejednokrotnie było omawiane i zatwierdzane, zanim trafiło do obróbki przez Developera.
Nie wchodząc w szczegóły metod zwinnych jak np. Scrum, należy dodać, że samo rozpisanie User story umożliwia ich ocenę w abstrakcyjnej jednostce "Story point". Pozwala to na łatwiejsze zarządzanie i planowanie realizacji poszczególnych historii.
No dobra, ale jak to działa w praktyce?
Wyobraź sobie, że w swoim projekcie posiadasz zdefiniowaną listę kilkunastu User Story. Każdy z nich jest oszacowany przez Developera w Story Pointach, które z kolei przyjmują jedną z wartości: 1, 2, 3, 5, 8 i 13 (tak, to jest ciąg Fibonacciego). Prostym sumowaniem wyliczasz, że rozmiar projektu to np. 52 Story Pointy. Wiesz, że Developer w ciągu dwóch tygodni potrafi zrealizować 15 Story Pointów. Prostym dzieleniem 52/15 otrzymujesz informację, że projekt potrzebuje (przy zaokrągleniu) czterech sprintów, czyli ok. dwóch miesięcy aby zakończyć etap produkcyjny.
Jest to jedna z najdokładniejszych metod szacowania. Oczywiście nie jest ona najdokładniejsza (bo taka po prostu nie istnieje), ale pozwala na odpowiednie zalokowanie zasobów i budżetu na najbliższy czas.
Tak samo działaliśmy w przypadku tego projektu, i tak naprawdę każdego innego. Mieliśmy drobne zmiany na późnym etapie projektu, jednak nie były one na tyle krytyczne, aby nie dowieźć rozwiązania na czas.
Najbardziej w User Story lubimy to, że angażują każdą ze stron, dając miejsce do wspólnego rozmawiania na konkretny temat. Nie omawialiśmy w tym artykule sposobów na wzbogacenie User Story elementami, takimi jak: kryteria akceptacji, propozycje implementacji w formie makiet lub prototypów. To jest obszerny temat, do którego być może kiedyś wrócimy.
