W tym cyklu artykułów opisuję – wynikające z mojego doświadczenia – czynniki sukcesu analizy biznesowej w SCRUM. Tym razem kontynuujemy kwestię kompetencji miękkich „zwinnego” Analityka Biznesowego.
W poprzednim poście skupiłem się na komunikacji werbalnej. Teraz pora na pozostałe cechy osobowości, które w moim mniemaniu ułatwiają analizę wymagań.
Wariantowe podejście
W projektach zwinnych, często jest tak, że komponent służący do realizacji danego procesu zajmuje więcej czasu niż jeden sprint. W takiej sytuacji ważne jest, aby umieć zaproponować kilka wariantów osiągnięcia celu, utrzymując przy tym zaangażowanie klienta w proces wytwórczy.
Przykład dla projektu, gdzie sprint trwa 2 tygodnie, a pełna funkcjonalność zajmie 4.
Wariant 1: „Przekażemy wszystko do testów za 4 tygodnie”. W tym przypadku ryzykujemy zmniejszeniem zaangażowania klienta z uwagi na odległy termin prezentacji.
Wariant 2: „Za 2 tygodnie oddamy do testów obsługę składania wniosków przez pracownika, a po 4 tygodniach również przez jego przełożonego.” Utrzymujemy zaangażowanie na średnim poziomie.
Wariant 3: „Przez 2 tygodnie ustalimy kształt powiadomień mailowych, po 2 tygodniach oddamy składanie wniosków przez pracownika a po 4 tygodniach włączymy ustalone powiadomienia mailowe oraz składanie wniosku przez przełożonego.” Klient jest zaangażowany przez cały czas wytwarzania.
Umiejętność negocjacji
SCRUM polega na iteracyjnym dostarczaniu działających funkcjonalności. Niektórzy klienci (nieświadomie) dążą do ciągłego udoskonalania elementów będących w fazie wytwarzania (często koncentrując się głównie na wyglądzie), oddalając w ten sposób wdrożenie produkcyjne. Jeżeli nie dysponujemy w zespole dobrym grafikiem lub specjalistą od UX – może się okazać, że klient ma rację. W przeciwnym wypadku mamy prawie największe wyzwanie analityczne: „w jaki sposób powstrzymać niekończący się koncert życzeń?”.
Tu pomocne mogą być następujące argumenty i pytania merytoryczne:
- Czy zmiana koloru tła i modyfikacja wyglądu przycisków działającego produktu jest równie istotna jak dostarczenie modułu do wyszukiwania dokumentów?
- Zmiana kolejności pól na formularzach delegacji zajmie nam 2 dni robocze, przez ten czas moglibyśmy zautomatyzować wyliczanie kosztu podróży krajowej. Która z tych rzeczy pozwoli wam zaoszczędzić więcej czasu w codziennej pracy?
- Umówiliśmy się na wskazany zakres funkcjonalny, zrealizowaliśmy go zgodnie z założeniami. Jeżeli potrzebne są kolejne zmiany koloru tła/wyglądu to proponujemy teraz udostępnić funkcjonalność do testów biznesowych (dzięki czemu dostaniemy komunikat zwrotny o tym czy funkcjonalność realizuje cele biznesowe) i jeżeli testy wykażą problemy z interfejsem użytkownika, wtedy go zmodyfikujemy (bazując na opinii użytkowników końcowych).
Dociekliwość
Zbierając wymagania na najbliższy sprint, staramy się je doprecyzować możliwie dokładnie. Zespoły deweloperskie patrzą na wymagania z innej perspektywy niż klienci. Klient myśli o tym, co chce zrealizować (widzi scenariusz sukcesu). Zespół patrzy na to, co może pójść nie tak (widzi wszystkie bramki decyzyjne, niedomówienia, potencjalne problemy).
Obie te dopełniające się wizje są niezbędne do osiągnięcia sukcesu, dlatego dobry analityk oprócz tego, że dużo rozmawia z klientem – robi to równie często z zespołem. Dopytuje o ograniczenia systemowe, niedopatrzenia w poprzednich analizach czy nawet prosi o wskazówki (tu szczególnie pomocni mogą być testerzy). Dzięki temu grooming (backlog refinement) i planowanie sprintów przebiegną sprawniej a spotkania z klientem pozwolą na szybsze zdobycie informacji wartościowych również z perspektywy zespołu.
W kolejnym poście zapraszam na rozważania dotyczące znajomości dziedziny, czyli tego, jak znajomość i wyczucie biznesu pozwalają Analitykowi nie „utonąć” w burzliwym morzu wymagań projektowych.
***
Wszystkie artykuły z serii znajdziesz tutaj:
Zostaw komentarz