O efektywnej realizacji projektu IT decyduje zespół specjalistów IT, złożony nie tylko z programistów, którzy w danym projekcie pełnią różnorodne role. Dzisiaj skoncentrujemy się nad zadaniami i rolą, jaką w projekcie pełni analityk. Dlaczego jego rola jest tak istotna? Dlaczego analityk analitykowi nierówny i czym w zasadzie różnią się role analityczne w IT? Na serio i czasami z lekkim przymrużeniem oka rozmawiamy z Michałem Kojtychem o temacie analizy w IT.
DCG: A więc? Jaka jest rola analityka?
Michał Kojtych: Odpowiem - jak przystało na analityka – to zależy :)
Odpowiadając krótko – analizuje sytuacje i w ustrukturyzowany sposób, zgodnie ze standardami i metodykami, podaje wnioski i opis sytuacji. Z naciskiem na „ustrukturyzowany.”
DCG: A nieco bardziej obszernie…
MK: Oczywiście odpowiedź wymaga rozwinięcia, bo pytanie jest wbrew pozorom złożone i wymaga dłuższego wstępu. Zanim przejdę dalej, musimy „uspójnić nasze słowniki.” Musimy doprecyzować, co rozumiemy pod konkretnymi pojęciami, czy mamy podobne rozumienie ogólne sytuacji (co de facto jest pierwszym zadaniem analityka w projekcie).
Przede wszystkim należy bardzo jasno powiedzieć, że nie każdy analityk musi być związany z IT...oraz... nie każdy analityk związany z IT musi się tym IT zajmować (w sensie rozwoju systemu komputerowego).
DCG: Parafrazując - analityk analitykowi nierówny.
MK: Dokładnie. Dla przykładu: są analitycy finansowi, którzy oceniają wskaźniki ekonomiczne przedsiębiorstwa. Albo tacy co sprawdzają, czy można dać Ci kredyt na podstawie różnych parametrów – analitycy Ci korzystają z oprogramowania, ale nie są w IT. Mogą być analitycy danych – „grzebią” w raportach, a Ci „bardziej techniczni” wyciągają dane bezpośrednio z baz danych i takie raporty tworzą. Czasem nazywa się ich analitykami biznesowymi (spotkałem się z tym na portalach amerykańskich), bo wspierają biznes w decyzjach (np. po kampanii marketingowej oceniają różne wyniki sprzedaży, wyliczają statystyki itp.). W Polsce chyba bardziej przyjęło się, że są analitykami danych. Mamy analityków bezpieczeństwa, wojskowych, wywiadu i jeszcze kilku innych.
DCG: Czy coś ich łączy?
MK: Oczywiście. To, co łączy te wszystkie role, to analiza sytuacji – a więc dokonanie oglądu sytuacji, połączenia jej z pewnymi dodatkowymi informacjami, ustrukturyzowanie tego w formie raportu z konkluzjami/rekomendacjami.
DCG: Porozmawiajmy o analitykach w IT
MK: W naszym IT też prosto nie jest. Są choćby analitycy biznesowi, procesowi, analitycy systemowi, czy wdrożeniowcy. Każda z tych ról jest inna, ale ich wspólnym mianownikiem jest produkt w postaci ustrukturyzowanej analizy danej sytuacji, z wykorzystaniem jednego z kilku dostępnych standardów, zrobiony jedną z kilku metodyk. Nie wszyscy z tych wymienionych analityków muszą zajmować się konkretnie systemami komputerowymi – np. analityk biznesowy zbiera wymagania biznesowe, czyli wszystko to, co się musi zadziać, aby zostały spełnione oczekiwania biznesu. Na ich podstawie zostanie podjęta decyzja. Decyzja, którą nie koniecznie musi być zbudowanie/modyfikacja systemu komputerowego, ale np... zatrudnienie dodatkowych 10 osób. Bo tak będzie efektywniej, taniej, szybciej (a to mogą być kluczowe kryteria). Procesowiec może oczywiście zmapować proces, zoptymalizować go, a decyzja, czy będzie go wspomagał system komputerowy i jak, to już osobna kwestia.
Dopiero analityk systemowy i wdrożeniowiec patrzą na oczekiwania biznesu oczami IT – przekuwają wymagania biznesowe na wymagania adekwatne do świata sytemu i mają wspólny język z deweloperami. Innymi słowy, zawężając odpowiedz tylko do analityków IT, rolą analityków na projekcie jest dostarczenie jasnych, precyzyjnych wymagań, czego oczekujemy od rozwiązania (którym na koniec nie koniecznie musi być system komputerowy), które ktoś inny wybierze/zbuduje. Drogą zaś do tego celu jest udokumentowanie i analiza obecnej sytuacji, wyciąganie wniosków, identyfikowanie obszarów wymagających wsparcia/doprecyzowania, a najważniejsze – zrozumienie, po co to robimy i dlaczego (co jest wartością dla biznesu).
DCG: Dlaczego rola analityka jest tak ważna?
MK: I znów – szybka odpowiedz - bo bez analityka bardzo łatwo jest „pójść w las” :) Szerzej - dla przykładu: wyobraźmy sobie, że chcesz zbudować pensjonat w Tatrach. Wynajmujesz ekipę, co już zbudowała dziesiątki domów, uznajesz, że nie potrzeba Ci architekta, planów – Ty wiesz, że chcesz pensjonat, oni zbudowali dziesiątki domów. Co może się nie udać? :) Odpowiedź brzmi - dużo.
Przykładowo po miesiącu ekipa pochwaliłaby się, że już stoją pierwsze ściany, a Ty zadasz pytanie, a gdzie jest podziemny parking dla samochodów...
Gdybyśmy potraktowali pensjonat jako projekt IT i zatrudnili analityków, i rozpoczęli pracę z analitykiem biznesowym, a następnie analitykiem systemowym (jeśli budowalibyśmy dom wedle naszego projektu) lub z wdrożeniowcem (jeśli to jakiś gotowy projekt). Analityk biznesowy wypytałby nas o wszystko, zaczynając od tego, po co nam pensjonat, skoro jest tyle pensjonatów wokół:). Chciałby poznać naszą motywację. Przy okazji mogłoby się okazać, że to, co my nazywamy pensjonatem, jest w rzeczywistości hotelem z salą konferencyjną, a nie góralskim domkiem z 5. pokojami 2-osobowymi. A może okaże się, że chcemy mieć swoją odskocznię w górach, która poza czasem, gdy tam jesteśmy, zarobi na siebie. A dokona tego w ten sposób, że wypyta nas o proces – np. pozyskiwania klientów, czy ich rejestracji. Z tego procesu już wyjdzie, czy będą to klienci korporacyjni (i również samo wyjdzie, że potrzebujemy salki konferencyjnej lub pięciu i parkingu) czy może rodziny z dziećmi i zamiast obszernego parkingu ma być plac zabaw.
Analityk biznesowy spisze nasze oczekiwania w formie wymagań biznesowych (np. goście mają mieć pełen komfort akustyczny, a więc celem biznesowym ma być to, by mieć spokój i nie słyszeć, co się dzieje w innych pokojach). Następnie do projektu wejdzie albo analityk systemowy, które te wymagania przekuje już na wymagania bardziej techniczne – a więc np. na to odnośnie komfortu akustycznego – „pokój ma mieć barierę akustyczną zmniejszającą hałas o 30db”, albo jeśli zdecydujemy się na gotowe rozwiązanie – zapoznamy się z ofertą na rynku, czy spełnia wymagania spisane przez analityka biznesowego. Wybierzemy rozwiązanie (spełniające kryteria, cenę, czas budowy, dostępność ekipy), a następnie wykonawca wyśle do nas wdrożeniowca, który zna produkt i który dopyta – np. jak bardzo grube ściany chcemy mieć:).
A koniec wejdzie ekipa budowlana, nomen omen developerska i zbudują nam to, co… jest w dokumentacji. Podsumowując - im lepsza dokumentacja tym większa szansa, że nie będziemy zawiedzeni. Bo budowanie piwnicy, o której się zapomniało (tzw, Change Request) pod istniejącym budynkiem jest dość kłopotliwe...
DCG: I wszystko jasne. Dziękuję za obrazowy przykład i za rozmowę.
_______________________________________________
Michał Kojtych - analityk z zamiłowania, ukończył Politechnikę Warszawską ze specjalizacją w kierunku analizy wielokryterialnej. Przygodę z komputerami zaczął w podstawówce od Bruce'a Lee na Timex'ie, by następnie napisać prostego wirusa, który dał mu naganne zachowanie (po zainfekowaniu komputera nauczyciela) i 6-tkę z informatyki by "zakończyć developerkę" - na studiach odkrywając uroki analizy. Zawodowo - w IT pojawił się wpierw w dziale HR pracując jako rekruter i Resource Manager, by po "zadaniach na 6-tkę" w postaci optymalizacji procesów HR na dobre osiąść w analizie.
TECHNOLOGIE, ANALIZA IT
