Analityk, czyli kto? Rola, narzędzia, metody pracy

Rola analityka

Rola analityka we współczesnym software house uległa istotnemu przedefiniowaniu w odniesieniu do tradycyjnego modelu rozwoju oprogramowania, gdzie analityk często był jedynym interfejsem pomiędzy szeroko rozumianym Biznesem a zespołem wykonawczym.

Intensywny rozwój metodyk zwinnych istotnie zmienił oczekiwania oraz wyzwania, wobec których staje obecnie analityk. Warsztat w zakresie tradycyjnych technik modelowania i dokumentowania rozwiązań nadal stanowi niezwykle cenną umiejętność, która pozwala na sprawną syntezę i weryfikację spójności pozyskiwanych wymagań. Natomiast nacisk na formalne odzwierciedlenie tej wiedzy w postaci dokumentacji nie jest już bezwzględnie kluczowy[1]. Owszem, są dziedziny, gdzie formalna dokumentacja systemu stanowi absolutnie niezbędne kryterium Definiton of ready/done. Niemniej jednak praktyka pokazuje, że w obszarze tworzenia oprogramowania Building right things wydaje się być znacznie istotniejsze niż Building things right 😉 Wszystkich nieprzekonanych i nie tylko – zachęcamy do dalszej lektury 🙂.

Kim jest analityk w nowoczesnym software house?

Odpowiedź na to pytanie jest w dużym stopniu uzależniona od specyfiki projektu, w którym będziemy pracować. W zależności od standardów oraz wymogów organizacyjnych uzgodnionych z Klientem na etapie planowania przedsięwzięcia udział analityka w projekcie może mieć bardzo różny charakter.

Zależnie od tego czy projekt będzie realizowany w tradycyjnym podejściu typu waterfall, czy w którejś z metodyk zwinnych, produkty pracy analityka mogą być dostarczane na różnych etapach cyklów realizacyjnych i cechować się różnym poziomem szczegółowości.

Bez względu na powyższe, należy przyjąć, że w każdym projekcie, przekraczającym pewien minimalny poziom złożoności, pojawia się potrzeba realizacji prac o charakterze analitycznym. Typowo są to zadania związanie z:

• potwierdzeniem potrzeb biznesowych,
• pozyskiwaniem oraz weryfikacją spójności i kompletności wymagań oraz ustalaniem ich priorytetów,
• identyfikacją potencjalnych rozwiązań zapewniających realizację potrzeb biznesowych,
• dekompozycją funkcjonalną tych rozwiązań,
• modelowaniem procesów biznesowych,
• estymacją oraz planowaniem zakresu poszczególnych przyrostów.

Optymalnej realizacji tych zadań służy cały warsztat technik wspomagających. Począwszy od typowych technik warsztatowych, brainstormingowych i ankietowych, aż po bardziej zaawansowane techniki takie jak: Event storming, Impact mapping, User Story mapping, czy Domain storytelling.

Obecnie techniki te wymagają dodatkowej adaptacji do współpracy w trybie zdalnym.  Więcej o narzędziach, które nam w tym pomagają, opowiemy w dalszej części artykułu.

Prawdziwą skarbnicę wiedzy w zakresie organizacji procesu analizy nawet w najbardziej złożonych projektach stanowi BABOK® Guide opracowany przez International Institute of Businesss Analysis. Wskazane w dokumencie dobre praktyki oraz techniki należy wykorzystywać adekwatnie do etapu realizacyjnego, specyfiki, oraz złożoności realizowanego przedsięwzięcia. Optymalny dobór środków służących zapewnieniu oczekiwanej jakości produktów analitycznych powinien mieć na uwadze także związane z tym koszty.

W kontekście metodyk zwinnych niezwykle cennym opracowaniem przygotowanym przez IIBA jest także Agile Extension to the BABOK® Guide. Perspektywa, z której postrzegane są typowe zadania analityczne w podejściu zwinnym istotnie różni się od tradycyjnego podejścia obowiązującego w modelu kaskadowym. Polecamy zwięzłe opracowanie najważniejszych aspektów wyróżniających te podeście przygotowane przez ekspertkę z Altkom Software & Consulting: Analiza w podejściu zwinnym według BABOK – Altkom Software & Consulting.

Powyższe opracowania dotyczą głównie dobrych praktyk w dziedzinie analizy biznesowej. Należy także wspomnieć o szczególnych aspektach pracy analityka w obszarze analizy systemowej. Tradycyjnie rola analityka systemowego wymagała większego zaangażowania w prace z pogranicza projektowania systemów, baz danych oraz szeroko pojętej architektury rozwiązań.  Niemniej obecnie w znacznej części projektów podział na rolę analityka biznesowego i analityka systemowego zaciera się. W Altkom Software & Consulting zakładamy, że analityk powinien łączyć zarówno umiejętności w dziedzinie analizy biznesowej jak i systemowej. Jest to szczególnie uzasadnione w kontekście pożądanego wysokiego stopnia interdyscyplinarności poszczególnych członków zespołów projektowych. Niesie także szereg korzyści dla samego analityka, który dzięki temu może poszerzać swoją wiedzę i umiejętności zarówno w dziedzinie biznesowej jak i technicznej.

Niezwykle istotnym aspektem codziennej pracy analityka są również tzw. umiejętności miękkie. Korzyści wynikające z adekwatnego stosowania różnych technik: komunikacji, moderowania i facylitacji spotkań oraz warsztatów, a także praktyczna znajomość technik negocjacji i współpracy zespołowej są u analityka nie do przecenienia.

Analityk bardzo często staje w sytuacji, w której musi pogodzić wiele, czasem sprzecznych interesów, formułowanych przez różnych udziałowców projektu. W takich sytuacjach umiejętność doprowadzenia do akceptowalnego przez wszystkich kompromisu jest często krytyczna w kontekście powodzenia realizowanego przedsięwzięcia.

W jaki sposób pracujemy z Klientem?

Dokumentacja

Kiedy Klient oczekuje dostarczenia formalnej dokumentacji rozwiązania, ale nie narzuca określonych standardów dokumentacji, Altkom Software & Consulting może pochwalić się sprawdzonymi rozwiązaniami stosowanymi w takich przypadkach. Nasza autorska metodyka tworzenia dokumentacji – SWiAR [2] bazuje na najlepszych praktykach w zakresie dokumentowania wymagań, opisanych przez Goiko Adzic’a w Specification by example. Wykorzystujemy ją z dużymi sukcesami w nawet najbardziej złożonych projektach. Większość projektów, które inicjujemy w dziedzinie ubezpieczeniowej i bankowej bazuje właśnie na wykorzystaniu tego standardu. Dzięki niskiemu „progowi wejścia” pozwala on na szybkie dokumentowanie wymagań w formie czytelnej zarówno dla Biznesu jak i dla zespołu wykonawczego/utrzymaniowego. Prosty i ustandaryzowany opis User stories, kryteriów akceptacji oraz procesów biznesowych zapewnia jednolity „język komunikacji” nie tylko w ramach poszczególnych projektów, ale także cross-projektowo.

W projektach, gdzie standardy dokumentacji są wyznaczone przez organizację Klienta, w większości jest to dokumentacja bazująca na powszechnie obowiązujących standardach takich jak UML i/lub BPMN – zazwyczaj wykorzystująca także ustandaryzowany opis User stories.

Narzędzia

Narzędzia stosowane w projektach są w dużym stopniu uwarunkowane wymogami konkretnego projektu. Przy czym jako pewien standard należy przyjąć narzędzia typu JIRA, CONFLUENCE, Enterprise Architect, Balsamiq, Figma. Szczególne miejsce wśród narzędzi wykorzystywanych przez analityka zajmuje u nas także modeler Camunda. Ze względu na liczne projekty realizowane przez Altkom Software & Consulting w oparciu o ten sprawdzony silnik procesów biznesowych, bardzo często produkty pracy analityka powstają w tym narzędziu.

Należy także zwrócić uwagę, że techniki  i metody stosowane przez nas wcześniej na bezpośrednich warsztatach z Klientem musiały zostać zaadaptowane do zdalnego trybu pracy. Wypracowane przez nas metody zdalnej organizacji warsztatów bazują na wykorzystaniu sprawdzonych narzędzi ułatwiających takie prace w rozproszonym środowisku cross-organizacyjnym jak np. Miro, MS SharePoint / Google Docs, draw.io, bpmn.io.

Techniki i organizacja pracy

W projektach realizowanych w metodykach zwinnych zakładamy sporą interdyscyplinarność poszczególnych członków zespołu wytwórczego. Formalnie Scrum guide nie przewiduje wydzielonej roli analityka. W przeważającej większości projektów mamy do czynienia z zadaniami, które najsprawniej są realizowane przez osoby dysponujące odpowiednim doświadczeniem i warsztatem analitycznym. Część zadań analitycznych mogą realizować również developerzy, czy testerzy, jak i w drugą stronę – analityk może angażować się w prace w obszarze testów czy zadania realizowane standardowo przez Product Ownera. W dużym stopniu wynika to ze sporej autonomii organizacyjnej poszczególnych zespołów wykonawczych.

W przypadku większych projektów realizowanych w metodykach zwinnych zawsze pewnym wyzwaniem jest „skalowanie Scruma”, wraz ze wszystkimi wyzwaniami z tego wynikającymi (m. In. podział na optymalnej wielkości zespoły, synchronizacja prac, propagacja wiedzy). Analiza wymaga wówczas szczególnej dyscypliny oraz dodatkowych standardów współpracy międzyzespołowej, które wypracowaliśmy realizując od wielu lat złożone projekty tego typu. Pewną alternatywą jest oczywiście w takim przypadku metodyka typu Kanban/Lean. Przykładowo w Kanban nie jesteśmy w żaden sposób ograniczeni „timeboxami” tj. sprintami. Oczywiście są projekty, gdzie sprawdza się lepiej jedno z tych dwóch podejść, jak i takie, gdzie najlepiej zadziała połączenie obydwu – jest to temat na tyle obszerny, że należałoby poświęcić mu osobny artykuł .

Ważnym elementem naszej pracy z Klientem są techniki warsztatowe pozyskiwania i porządkowania wiedzy. Wiele z nich znalazło na stałe miejsce w naszej autorskiej metodyce wdrożeniowej Software as a journey. Wśród powyższych należy wymienić między innymi:

• Event storming – niezastąpiona technika warsztatowa wczesnej fazy pozyskiwania wiedzy o potrzebach i domenie biznesowej;
• User Story mapping – technika pierwszego wyboru do inwentaryzacji oraz priorytetyzacji zadań w backlogu projektu;
• Value-Effort Matrix, efektywna technika wstępnej priorytetyzacji konkurencyjnych inicjatyw pod kątem relacji nakładów do zwrotu z inwestycji;
• Impact mapping – najlepszy przyjaciel Product Owner’a efektywna technika pozwalająca na optymalne planowanie i kontrolowanie działań służących osiągnięciu określonych celów biznesowych w projekcie;
• Domain storytelling, technika odkrywania domeny biznesowej pozwalająca eksplorować głębiej wiedzę pozyskaną w ramach Event Stormingu;
• Example mapping, technika walidowania zidentyfikowanych na wcześniejszych etapach scenariuszy biznesowych.

W kolejnym artykule przedstawimy praktyczne case’y z naszych projektów – na przykładzie wybranych doświadczeń pokażemy jak bardzo różnorodne zadania i wyzwania ma w codziennej pracy analityk.

Autorzy: Katarzyna Zalewska, Aleksander Dańko.

Redakcja: Kamila Binkowska

[1] Patrz https://agilemanifesto.org/

[2] SWiAR – Specyfikacja Wymagań i Architektury Rozwiązania