W Manifeście programowania zwinnego można przeczytać, że w pracy bardziej powinno się cenić: ludzi i interakcje od procesów i narzędzi; działające oprogramowanie od szczegółowej dokumentacji; współpracę z klientem od negocjacji umów oraz reagowanie na zmiany od realizacji założonego planu. Jak w takim razie wprowadzić te zasady do pracy analityka biznesowego? O tym, a także o różnicach między dokumentacją biznesową w podejściach klasycznym i zwinnym oraz wyzwaniach, jakie stoją przed analitykami biznesowymi w szybko ewoluującym środowisku pracy, rozmawiamy z Magdaleną Straś, Senior Business Analyst w Sii Polska.
Po co jest nam potrzebna dokumentacja biznesowa?
Właściwie tylko i wyłącznie w jednym celu – jako analitycy biznesowi wchodzimy do organizacji i staramy się znaleźć powód, dla którego coś zmieniamy, przedstawić wszystkie zapotrzebowania klienta, związane z tą zmianą. Dlatego też naszym zadaniem jest zebranie informacji na temat stanu faktycznego. Tworzymy również wizję stanu przyszłego, pożądanego, oraz analizujemy to, w jaki sposób ma się do niego dojść. Już na tym wstępnym etapie możemy zmierzyć się z kilkoma wyzwaniami.
Nierzadko różni interesariusze mają zupełnie inną wizję przyszłości. Bardzo często także spotykamy się z sytuacją, kiedy coś powinno działać w jakiś sposób, a działa w zupełnie inny. Część interesariuszy zdaje sobie z tego sprawę, ale jest też grupa, która zupełnie nie ma o tym pojęcia i dlatego naszym pierwszym krokiem jest zdefiniowanie wymagań, które kształtują się z rozmów, wywiadów i warsztatów, przeprowadzonych przy okazji badania potrzeb różnych stron. Pamiętajmy, że powinny to być wymagania relewantne i zwalidowane, a nie lista życzeń interesariuszy. Po nas może przyjść ktoś, kto z tych wymagań będzie budował system albo usprawniał proces, a bez właściwie sporządzonej dokumentacji biznesowej, pozwalającej na dokonywanie szybkich korekt, przedstawienie interesariuszom aktualnego stanu czy walidacji nie będziemy mogli ocenić sytuacji, ani ruszyć z kolejnymi działaniami.
Jak wygląda Pani praca na co dzień?
Praca analityka biznesowego oznacza notowanie, zapisywanie, wypunktowywanie oraz łączenie niewidocznych gołym okiem kropek. Rejestrujemy wszystko, co się dzieje: kontekst sytuacyjny, zachowania ludzi, a nawet sposób, w jaki oni walidują wymagania i odnoszą się do tego, co do nas mówią. Z tych wielowątkowych opowieści powstaje jedna uwspólnotowiona wersja rzeczywistości. To ma być biblia. Dokumentacja biznesowa, która powstaje, nie może pozostawiać wątpliwości żadnym użytkownikom co do tego, jak ma się interpretować różne elementy, które są jej składową, oraz jak ma być kształtowana przyszłość. Pamiętajmy, że z tej samej dokumentacji będzie korzystał klient, zespół projektowy oraz inni interesariusze, którzy będą brać udział w tworzeniu i wdrażaniu systemu.
Na czym polega wykorzystywanie podejścia klasycznego w dokumentacji biznesowej?
W analizie tzw. waterfallowej, czyli takiej, w której analityk przychodzi jako pierwszy i robi tzw. prestudy, pracowaliśmy w odosobnieniu. Działaliśmy z klientem, z którym przeprowadzaliśmy wywiady i robiliśmy warsztaty. Staraliśmy się także sprawdzić, jak zachowują się pracownicy, a jak użytkownicy systemu, oraz odnosiliśmy to do jakiegoś danego stanu rzeczy. Cała nasza dokumentacja była tworzona jeszcze przed procesem wytwórczym, co oznacza, że mieliśmy dużo czasu na przygotowania, ale nie mogliśmy później zrewidować informacji ani z konsumentami, ani z deweloperami.
W efekcie powstawał twór z doskonałą strukturą metodologii, który nie do końca był zrozumiały dla różnych grup, mających brać udział w tworzeniu np. software’u. Deweloperzy nie rozumieli, co napisaliśmy, a nawet znajdowali w dokumencie luki. Podobnie testerzy – nie umieli się odnaleźć w treściach, które wyprodukowaliśmy. Wychodziliśmy w większości sytuacji z metodologicznych podstaw analizy biznesowej, więc tworzyliśmy osobne rozdziały poświęcone np. przypadkom, w jakich korzysta się z software’u, grupom docelowym, zasadom biznesowym, walidacji czy interfejsowi, z którym będą pracować końcowi użytkownicy. Sczytując rozdział po rozdziale, można było zebrać pełen obraz sytuacji oraz wyciągnąć potrzebne informacje, ale brakowało czasem tego najważniejszego, czyli połączenia wszystkiego w spójną całość, a nie przechodzenia od rozdziału do rozdziału w poszukiwaniu potrzebnych informacji.
Z czym odbiorcy takiej klasycznej dokumentacji biznesowej mieli największy problem?
Odbiorcy przechodzili przez zestaw wszystkich wymagań biznesowych, który – choć ujęty w kompletną całość – nie ułatwiał odniesienia się tylko do jednego interesującego nas elementu, jak np. ekranów użytkownika. Podczas takiego procesu, z jakim mamy do czynienia w przypadku klasycznej dokumentacji, łatwiej o popełnienie błędu. Nie jesteśmy bowiem w stanie poruszać się po tak obszernym dokumencie, w którym jedna funkcjonalność może być analizowana pod różnymi aspektami w kilku rozdziałach. A nawet jeśli wyszuka się wszystkie odniesienia do jednego elementu projektu, to wymaga to bardzo dużo czasu. W dodatku, tego rodzaju dokumentacja była w dużej mierze tekstowa, z małą liczbą elementów wizualnych. Pojawiały się jedynie modele, które wymagały od odbiorcy zrozumienia. Dlatego też powstała ogromna potrzeba zmiany optyki.
Czym charakteryzuje się więc wykorzystywanie metodyk zwinnych w dokumentacji biznesowej?
W metodykach zwinnych zarówno zespół projektowy, jak i analityk biznesowy, a także product owner skupiają się na dostarczaniu wartości biznesowej w każdym sprincie. Oznacza to także, że nie jesteśmy w stanie powiedzieć, że akurat teraz budujemy wszystkie walidacje, a za chwilę zbudujemy wszystkie ekrany, z jakimi ma do czynienia użytkownik. Naszym zadaniem jest wypracowanie procesu, który ma przynieść wartość. I tu napotykamy na podstawowy problem: jak znaleźć informacje, które dotyczą tylko jednego malutkiego wycinka tego kawałeczka? Podstawowym narzędziem naszej dokumentacji są tzw. historyjki użytkownika. Mówią one bardzo konkretnie o tym, jakiej funkcjonalności użytkownik potrzebuje, aby otrzymać określoną wartość. Historyjkę zwykle przygotowujemy w jednym – najczęściej dwutygodniowym – sprincie, jest ona niepodzielna, a takich historyjek w sumie może być przynajmniej kilka.
Od czego zacząć proces tworzenia historyjki?
Zaczynam od tego, kim jest nasz użytkownik, w jaki sposób loguje się do systemu oraz czy w ogóle musi być zalogowany, aby z niego korzystać. To już jest dla nas pierwszy rozdział dokumentacji biznesowej. Jeśli użytkownik ma do czynienia z interfejsem, na którym musi uzupełnić dane lub np. dodać produkty do koszyka, to już mamy do opisania ekran, walidację danych oraz cały mechanizm, przez który musi przejść użytkownik. Oznacza to podanie definicji, czym jest produkt, czym koszyk oraz w jaki sposób następuje dodanie produktu do koszyka. A to już kolejny element dokumentacji. W klasycznej jej odsłonie te informacje były rozproszone w całym pliku. Oznaczało to, że należało przejść przez cały materiał, aby wyciągnąć te dane. Tymczasem w historyjce użytkownika zawiera się wszystkie te elementy, czy to w formie preconditions, postconditions lub kryteriów akceptowalności.
Dyskusja nad jedyną słuszną drogą w dokumentacji jest wciąż żywa. Jakie wyzwania stoją przed zwolennikami historyjek użytkowników?
Podczas tworzenia historyjek dochodzimy do momentu, w którym mamy jakiś wycinek, który może być pokazany z innej perspektywy, co powoduje, że nierzadko podnoszony jest argument o braku kontekstu. Może to powodować trudności w aktualizowaniu, usprawnianiu i poprawianiu historyjek, jeśli np. dojdzie do nowego wdrożenia lub gdy w międzyczasie znajdziemy jakiś błąd. Pojawiają się także głosy, że historyjki użytkowników powinno się traktować jedynie jako dokumentację tymczasową, która pomaga w projekcie, a później działać tylko i wyłącznie na ticketach, które są dedykowane deweloperom, a analitycy biznesowi są cały czas obecni i opiekują się tym projektem, zarządzając procesem. W tym przypadku widzę alternatywę. To poszukiwanie metod, które pozwolą nam na wykorzystywanie historyjek, ale jednocześnie tworzenie ustrukturyzowanej dokumentacji.
Jakimi narzędziami możemy wesprzeć się, tworząc taką właśnie dokumentację?
Istnieją narzędzia, które z jednej strony pozwalają pokazać rzeczywistość, a z drugiej pracować z ticketami oraz podpiąć wszystko do procesu. To np. tandem Jira i Confluence. Właśnie jako tandem te dwa narzędzia pozwalają łączyć perspektywę wartościową z punktu widzenia dewelopera, czyli typowy system ticketów (Jira), z perspektywą nieco bardziej dokumentacyjną, czyli warstwą wizualno-tekstową (Confluence). Opisujemy w nich historyjki i jednocześnie podpinamy je do innych struktur, czyli większych historyjek, które nazywamy epikami. Nie zapominajmy także o podstawowym narzędziu analitycznym, jakim jest dekompozycja funkcjonalna.
W momencie, w którym wchodzimy w projekt, zanim jeszcze dojdziemy do tych wszystkich historyjek, i tak wykonujemy pracę, która polega na podzieleniu naszego tzw. scope’u na części, tworzące komponenty systemu. To mogą być duże epiki, które opisują nam jakąś rzeczywistość np. komponent – klient, komponent – portal klienta, komponent – portal handlowca, komponent – koszyk. Tworząc rzeczywistość z takich elementów, jesteśmy w stanie wchodzić jeszcze bardziej w szczegóły, a jednocześnie zachować identyfikowalność. Historyjka wiąże się z epikiem, który należy do komponentu, a ten z kolei został zgłoszony przez interesariusza. Na tym etapie osiągamy dokładnie to samo, o czym mówimy w klasycznej dokumentacji w matrycy identyfikowalności, ale jednak w zupełnie inny sposób, bardziej dynamiczny.
Co jest najważniejsze podczas tworzenia dokumentacji?
Agile Manifesto zakłada, że w przypadku metodyk zwinnych cenniejsze są dla nas działający software czy relacje z ludźmi niż pełna dokumentacja i negocjacje umów. Idąc tym tropem, należy także zmieniać cały proces tworzenia dokumentacji biznesowej. Coraz więcej firm odchodzi od klasycznych dokumentów, np. Volere, które wymieniają wszystkie wymagania użytkownika, przechodząc w stronę bardziej dynamicznych – i co ważniejsze – wizualnych metod.
Dlaczego metody wizualne są tak ważne w dokumentacji biznesowej?
Nie ma prostszej rozmowy z klientami czy deweloperami niż omawianie procesu, który jest modelem. Obraz przecież znaczy więcej niż 1000 słów. Jeżeli pokazujemy użytkownikowi proces, który jest dobrze opisany i zmodelowany, to jesteśmy w stanie wyłapać więcej problemów i znaleźć wszystkie obszary do poprawy, a także w odpowiedni sposób pokazać naszemu zespołowi projektowemu celowość zadań. Wszystkim jest łatwiej pracować nad czymś, co się rozumie, wytwarzać coś, co daje faktycznie wartość, a to dodatkowo pozwala w bardziej kreatywny sposób podejść do tematu. Jako analitycy biznesowi zawsze rozpatrujemy wygląd rzeczywistości w kontekście celów, ale już niekoniecznie na tym, jak ona ma dokładnie wyglądać. Jeśli będziemy dawać więcej kontekstowych informacji deweloperom, to będą oni w stanie zaproponować odpowiednie rozwiązania. Dokumentacja wizualna pozwala również na przejrzyste raportowanie do project managerów, informując ich na bieżąco o postępie prac. W ten sposób można w jasny i przejrzysty sposób, a przede wszystkim nie tak czasochłonny, tworzyć kolejne etapy procesu.
Chcesz otrzymać podsumowanie artykułów?
