Analityk Systemowy – człowiek, który rozumie klienta

Specjaliści – dlaczego bez nich nie byłoby projektu?

Na to pytanie odpowie 5 ekspertów z branży IT w cyklu „Beze mnie nie byłoby projektu”, uzasadniając rangę i wagę swojego stanowiska oraz jego znaczenie dla projektu.

Pierwszą rozmowę przeprowadziłam z analitykiem systemowym, Jackiem Witesem. Znam Jacka osobiście, jako analityka i jako kolegę. Wybór rozmówcy był nieprzypadkowy – to pasjonat swojego zawodu, stymulowany ciekawością, a także praktyk z ogromnym zapleczem teoretycznym, dzięki czemu poszerza horyzonty – nie tylko swoje, o czym możecie się przekonać, czytając poniższy wywiad. Zapraszam do lektury.

„Analityk systemowy to osoba, która jest pośrednikiem pomiędzy klientem a programistą”. Czy zgadzasz się z tym stwierdzeniem?

Tak, to prawda. Analityk musi zrozumieć funkcjonowanie biznesu klienta, następnie przełożyć tę wiedzę na system, czyli zapisać wymagania w postaci zrozumiałej nie tylko dla programistów, ale dla całego zespołu zaangażowanego w projekt, więc również dla project managera, projektanta, architekta czy testera. Bycie analitykiem wymaga umiejętności zadawania pytań i przekazywania odpowiedzi. To również umiejętność rozumienia pytań i poszukiwania odpowiedzi. W tym rozumieniu analityk rzeczywiście jest pośrednikiem. Również na poziomie „dogrywania” szczegółów, to analityk konsultuje je z klientem i przekazuje ustalenia programistom. Na to, na co nie odpowiada dokumentacja, odpowiedzieć musi analityk.

Spotkałem się też z porównaniem analityka w projekcie informatycznym do architekta w projekcie budowlanym i z tym zgadzam się tylko częściowo, ponieważ analityk, podobnie jak architekt, zbiera wymagania podyktowane potrzebami i wizją klienta, ale nie zagłębia się w szczegóły techniczne (jak to robi architekt). Tu zatem widziałbym duet: analityk plus architekt aplikacji jako odpowiednik architekta budowlanego. Niestety, nie jesteśmy tak kompleksowi (śmiech).

Jaka jest rola analityka w całym cyklu życia projektu?

Analityk już w pierwszym etapie życia projektu tworzy różne artefakty, aby zapewnić realizację celów klienta, jak również przekazuje tę wiedzę zespołom programistycznym. Pod pojęciem artefakty kryją się różnego rodzaju diagramy (UML, BPMN), prototypy interfejsów, przypadki użycia (ang. use case) lub historyjki użytkownika (ang. user stories) w przypadku metody Agile czy dokumenty funkcjonalne. Aby wytworzyć te artefakty, korzystamy z różnego rodzaju technik zbierania wymagań np.:

• warsztaty analityczne,
• wywiady,
• sesje brainstormingowe,
• analizy dokumentacji zewnętrznych,
• modelowanie procesów,
• prototypowanie.

Pojawiamy się we wszystkich etapach życia projektu, przy czym w różnych etapach wytwarzane są różne artefakty pracy analitycznej. W początkowej fazie zazwyczaj skupiamy się na poznaniu procesów biznesowych, w kolejnych pojawiają się bardziej skomplikowane diagramy (np. UML), interfejsy. Podczas etapów projektowania i implementacji doradzamy, wyjaśniamy, pomagamy zaprojektować i wytworzyć wcześniej utworzone wymagania. Następnie uczestniczymy w testach, sprawdzamy system pod kątem realizacji biznesowych założeń. Szkolimy pracowników klienta podczas wdrożenia produkcyjnego systemu.

Moja rola jest również ważna z punktu widzenia odpowiedzialności – mój błąd, jeśli się zdarzy, prawdopodobnie przejdzie dalej i może wpłynąć na czas, koszt lub jakość wdrażanej aplikacji. Mam tego świadomość.

Analityk odgrywa zatem ważną rolę w całym projekcie, nie tylko na etapie analizy. Twoja wiedza jest potencjałem, z którego korzystają inni. To wymaga umiejętności współpracy, a pokutuje wyobrażenie o analityku-introwertyku (śmiech). Z kim, z jakimi innymi rolami współpracujesz w trakcie trwania projektu i na czym polega Wasza współpraca?

Jestem osobą, która w największym stopniu ma okazję poznać i zrozumieć dziedzinę klienta, a co za tym idzie – jestem w stanie pomagać w jej rozumieniu innym osobom w projekcie, które mają wiedzę na temat poszczególnych zadań bez oglądu na całość, stąd można powiedzieć, że współpracuję z całym zespołem, oczywiście na różnych etapach z różnymi osobami.

Kiedy projekt jest na etapie sprzedaży, współpracuję z opiekunem handlowym klienta. Służę wsparciem w zakresie konsultacji wymagań czy doprecyzowania zakresu. Często też uczestniczę w spotkaniach z potencjalnymi klientami, pomagam przy wypracowaniu koncepcji rozwiązań na potrzeby powstającej oferty.

Na etapie analizy opracowuję zakres funkcjonalny aplikacji. Beze mnie nie byłoby projektu :-) Wówczas najmocniej współpracuję bezpośrednio z klientem. Próbuję trochę „wejść w jego buty”, zrozumieć jego biznes, spojrzeć na projekt z punktu widzenia potencjalnych potrzeb (często potrzeby komunikowane przez klienta są zupełnie różne od tych, które rzeczywiście mogą mu przynieść korzyść – trzeba umieć to zweryfikować).

Kiedy projekt jest już na etapie projektowania ściśle współpracuję z projektantem interfejsów (UX designerem). Jest to etap, na którym łączymy pomysły i wymagania w interfejsy i logiczną całość – wymaga to uwagi i skrupulatności. To moment, w którym klient zaczyna „oglądać” swój przyszły system. Często dopiero w tym miejscu upewnia się, że tworzone jest coś, czego oczekiwał lub weryfikuje to ze swoim wyobrażeniem i wtedy też pojawiają się zmiany. To naturalne działanie w myśl zasady: I know it when I see it (Wiem to, kiedy to widzę) – makiety czy prototypy pokazują to, co na poziomie dokumentacji ciężko sobie wyobrazić, więc właśnie w wyniku zderzenia specyfikacji z makietami wizje są ostatecznie przekuwane w decyzje.

Konsultuję się też z innymi analitykami, wymieniamy informacje oraz doświadczenia z innych projektów. Czasem pracujemy w jednym projekcie, ale w różnych jego obszarach.

Podczas implementacji na bieżąco wspieram programistów. Odpowiadam na pytania, pomagam w interpretacji zapisów ze specyfikacji. Czasem zdarza się, że dokumentacja ma tzw. „białe plamy” – jest nieszczelna, nie doprecyzowuje jakiegoś wymagania, nie odpowiada na pytania programistów. Wówczas uszczelniam dokument na etapie realizacji.

Jestem też zaangażowany na etapie testów. Współpracuję z testerami, odpowiadając na ich pytania co do zgodności działania aplikacji z założeniami, czyli: „Jak to miało działać?”, bo to, że jakaś funkcja działa, wcale nie oznacza, że spełnia wymagania wytworzone podczas analizy (często opisane w postaci use case’ów lub user stories).

Niezależnie od etapu współpracuję z project managerem. Ułatwiam mu podejmowanie decyzji ;-) Komunikuję zmiany, za których wprowadzenie do projektu odpowiedzialny jest project manager, zgłaszam ryzyka czy opóźnienia.

Skoro jesteśmy przy zmianach… Zmiany w projekcie mogą mieć wpływ na wiele innych funkcji systemu, a w efekcie mogą sporo kosztować, z drugiej strony ciężko je ograniczyć w dobie zmieniających się dynamicznie wymagań. Jak sobie z nimi radzisz?

Zmiany są obecne na każdym etapie wytwarzania oprogramowania. Stosuję kilka metod zarządzania zmianą. W metodykach zwinnych odpowiada za to Backlog Produktu, a w metodykach waterfall’owych zarządzamy zmianą poprzez tzw. „change request”, który trafia na listę zmian, a następnie jest procesowany przez project managera, często z naszą pomocą.

Moim zdaniem zmian w projekcie nie należy się obawiać, należy umieć nimi zarządzać. Zmiany występują zawsze, najważniejsza jest umiejętność przewidzenia i zrozumienia ich konsekwencji dla projektu, a także właściwe wprowadzenie ich zarówno do dokumentacji, jak i do powstającego oprogramowania, przy jednoczesnym upewnieniu się, że nie będą miały negatywnych skutków i wpływu na inne elementy systemu. To właśnie z tego powodu zmiany wydają się straszne.

Praca analityka to niemal aptekarska dokładność i szwajcarska precyzja. Jakie cechy i kompetencje są potrzebne na tym stanowisku?

Bardzo ważne cechy to umiejętność komunikowania i słuchania – tylko dobre zrozumienie potrzeb klienta, a także właściwe ich odzwierciedlenie mogą zapewnić sukces w realizacji. Nawiązując do Twojego pierwszego pytania, to my jesteśmy mostem między biznesem a programistami.

Umiejętność analitycznego myślenia, mapowania „jak jest”, a „jak ma być”, także dokładność i sumienność. Tak, jak powiedziałaś – błąd na etapie analizy będzie sporo kosztował na etapie implementacji, dlatego tak ważne jest napisanie dobrej jakościowo specyfikacji wymagań.

Ponadto ważne są:

• Umiejętność wizualizacji zależności oraz powiązań pomiędzy różnymi elementami systemu
• Umiejętność identyfikowania powiązań i zależności z różnych obszarów systemu – daje to możliwość „przewidzenia” reakcji systemu na proponowane zmiany
• Kreatywne myślenie i umiejętność opracowania rozwiązania, które ostatecznie jest potwierdzone przez działający system
• Umiejętność podejmowania decyzji – takich momentów, kiedy trzeba odpowiedzieć sobie na pytanie i podjąć decyzję jest na etapie analizy czy projektowania bardzo dużo
• Umiejętność rozwiązywania problemów – podobnie, jak konieczność podejmowania decyzji, konieczność rozwiązywania problemów jest nieunikniona. Staram się traktować je raczej jak wyzwania ;-)
• Otwarty umysł, ciekawość i umiejętność uczenia się – to przede wszystkim. Trzeba nadążać za zmieniającym się światem potrzeb klientów, realiów biznesowych, konkurencją, a co za tym idzie – odkrywać i poznawać nowe narzędzia, które powstają w odpowiedzi na te pierwsze.

Gdyby Ciebie zabrakło…

Podobno nie ma ludzi (a może i ról?) niezastąpionych? (śmiech). A tak całkiem poważnie, inne osoby miałyby więcej obowiązków, bo wymagania trzeba zebrać i zapisać. Mógłby to wówczas robić na przykład handlowiec lub project manager – osoby, które niekoniecznie posiadają wiedzę jak zbierać wymagania. Wzrosłoby, zatem ryzyko niedoszacowania kosztów projektu, bowiem zakres mógłby wydawać się mniejszy, niż by to wyniknęło z niskopoziomowej analizy. Z drugiej strony klient kupowałby trochę „kota w worku” – nieprecyzyjne wymagania, dające się różnie interpretować, a przede wszystkim różnie zaprogramować… Jeśli znasz ten przykład z huśtawką, krążący w Internecie, to wiesz o czym mówię (śmiech).

Odzywa się we mnie głos PM’a i spokój ducha związany z tym, że rola analityka jednak istnieje. Dziękuję za miłą rozmowę.

Jacek Wites, analityk systemowy, absolwent Uniwersytetu Rolniczego na kierunku o specjalności Agroekonomia. Zacięcie analityczne nie pozwoliło mu jednak pozostać w wyuczonym zawodzie, a wrodzona skrupulatność i dociekliwość w połączeniu z zamiłowaniem do biznesu pokierowały go w stronę analizy właśnie.

Prywatnie mąż, właściciel psa, jamnika, który wabi się Fika. Pasjonat gór (szczególnie Bieszczad), nowych technologii (można by długo wymieniać), a także dobrej lektury nie tylko do poduszki, ale w każdej wolnej chwili. W czasie wolnym remontuje dom – to forma relaksu po tygodniu pełnym analitycznych zmagań.