pracaanalityka

Proces pracy analityka IT

Posted by admin

Często spotykam się z tym że każdy inaczej patrzy na to jak wygląda praca analityka IT. Słowa te wyglądają mniej więcej w stylu

„Analityk biznesowy zajmuje się […]”

albo ze znanym i lubianym słowem powinien

„Analityk biznesowy it powinien robić […]”

Dla mnie to jest sprawa która zawsze była nurtująca szczególnie jak pracowałem jako młodszy analityk biznesowy bo zawsze chciałem znać zakres swoich kompetencji. No poza tym znajomi zawsze się pytają czym się zajmuje analityk?? o czasu aż wziąłem i poukładałem sobie ten proces w głowie.

Teraz wychodzę każdemu początkującemu naprzeciw i prezentuję Ci kroki procesu w których analityk IT uczestniczy. Mam nadzieję że to Ci pomoże odpowiedzieć na pytanie jak zostać analitykiem biznesowym Jak proces to zacznijmy od diagramu(i nie będzie to ani BPMN ani UML a zwykła grafika bo jest ładniejsza 😛 )

Oczywiście zaznaczę jedną rzecz która jest moim zdaniem kluczowa w rozumieniu całej pracy

To że dane kroki procesu występują w procesie pracy analityka nie oznacza że wszystkie te kroki musi on wykonać osobiście.

Zadania powinny wręcz rozejść się na cały zespół ponieważ sam analityk by tego wszystkiego nie dźwignął. Stara jak świat zasada mówi jasno. Każdego specjalistę da się zniszczyć pod ciężarem zbyt wielu zadań do wykonania w skończonej jednostce czasu. Dlatego uważam że w tym procesie analityk musi uczestniczyć ale może np. tylko śledzić czy dane kroki zostały wykonane.

KROK 1 Definicja problemu i zakresu rozwiązania

Pierwszy krok w którym definiujemy jaki jest problem lub szansa i określamy zakres rozwiązania. Składa się to z różnych kroków do zrobienia. Przejdźmy przez nie.

  1. Zdefiniowanie właściciela

Czyli znana i lubiana analiza interesariuszy. Określamy osoby które mają siłę decyzyjną i wiedzę aby zdefiniować co chcemy osiągnąć(lub czego uniknąć), mają odpowiednią siłę do tego żeby daną sytuację wystarczająco opisać i zaakceptować określony cel biznesowy naszego działania.

2. Przygotowanie logistyki do opisu celu biznesowego

W tym kroku określamy:

  • Jakie informacje są potrzebne do aby opisać cel
  • Gdzie możemy takie informacje uzyskać (nie tylko ludzie! źródłem może być też np. ustawa ;P )
  • Określamy jak możemy takie informacje uzyskać (cała logistyka, wybór technik, wybór sposobu komunikacji w projekcie itd).
  • Określamy kolejność zbierania informacji(najpierw uszczegóławiamy proces czy konkretny obszar biznesowy?)

3. Zbieranie informacji o celu

Rozmawiamy, określamy, robimy warsztaty, burze mózgów itd. Wszystko po to aby ustalić co chcemy osiągnąć

4. Analiza celu biznesowego

Sprawdzamy czy cel jest spójny z misją firmy, sprawdzamy czy cel jest celem(czy np. spełnia zasady SMART). Upewniamy się czy to co chcemy zrobić jest na prawdę ważne. Sprawdzamy czy opisany cel biznesowy spełni oczekiwania interesariuszy związane z projektem.

5. Potwierdzamy cel biznesowy z interesariuszami

Tutaj ważna uwaga. Potwierdzamy z wyższym managementem. Chcemy uniknąć sytuacji gdzie zdefiniowany cel nie jest spójny z tym co chce osiągnąć wyższy management.

6. Definiujemy zakres rozwiązania celu biznesowego

Mamy cel biznesowy do osiągnięcia, kolejnym krokiem jest jasne zdefiniowanie w jaki sposób go osiągniemy. Czyli co musimy zrobić żeby jasno stwierdzić że cel został zrealizowany. To się nazywa ta mityczna wizja rozwiązania 🙂

UWAGA: To jest kluczowa kwestia. Bez określenia tego jak zrealizujemy nasz cel projekt z automatu jest uznawany za porażkę bo na dobrą sprawę możemy robić wszystko w jego ramach i cel naszego działania rozmywa się.

W tym kroku ustalamy kryteria akceptacji, ustalamy ludzi którzy podejmują kluczowe decyzje, identyfikujemy kluczowe ryzyka, wypracowujemy uzasadnienie biznesowe(słynny business case), określamy ograniczenia i ustalamy harmonogram(tu przeważnie nam pomaga project manager).

7. Wszystko na sam koniec dokumentujemy w jasny sposób i dajemy do akceptacji

Tutaj często powstaje ten wcześniej wspominany business case gdzie organizacja akceptuje projekt. Są różne komitety inwestycyjne czy inne tego typu procedury akceptowania wdrażania nowych zmian.

KROK 2 Udokumentowanie rozwiązania

Tutaj zaczyna się cała zabawa z inżynierią wymagań. Mamy projekt zaakceptowany, mamy zdefiniowany problem biznesowy i możemy lecieć z dokumentowaniem rozwiązania. Przejdźmy przez kroki definiowania i dokumentowania rozwiązania.

  1. Logistyka zbierania wymagań

Szykujemy plan działania dla aktywności zbierania wymagań:

  • Definiujemy co musimy zebrać aby zdefiniować rozwiązanie
  • Definiujemy gdzie możemy zebrać wymagania (dokumenty, ludzie, procesy, zdarzenia, systemy współpracujące). Tutaj też robimy znaną i lubianą analizę interesariuszy
  • Definiujemy jak możemy zbierać wymagania (wybór technik zbierania wymagań)
  • Definiujemy w jakiej kolejności będziemy zbierać wymagania
  • Definiujemy sposób komunikacji z interesariuszami
  • Szukamy ludzi, procesów, systemów które mogliśmy pominąć przy analizie interesariuszy.

2. Zbieramy wymagania

No i mamy najciekawszą część pracy w analizie biznesowej. Zbieranie wymagań. Wybraliśmy techniki i pracujemy z interesariuszami. Warto tutaj pamiętać żebyśmy:

  • Starali się zrozumieć w 100% po co to robimy(najczęściej wypominanym przez programistów brakiem w analizie jest brak uzasadnienia biznesowego)
  • Używali rekomendowanych technik i dobrych praktyk(nie bez powodu mądre głowy tego świata je stworzyły, są użyteczne)
  • Potwierdzał z interesariuszami że wszystko dobrze zrozumiałeś(parafrazowanie się kłania)

3. Analizujemy wymagania

To w tym momencie:

  • Kategoryzujemy zebrane wymagania od interesariuszy
  • Modelujemy wymagania (model procesu, model dziedziny)
  • Analizujemy reguły biznesowe
  • Definiujemy ograniczenia
  • Wypracowujemy rozwiązania (tutaj możemy podejść do wymagań z różnych perspektyw behawioralnej, funkcjonalnej, danych, czy tworzymy przypadki użycia).

UWAGA: Pamiętaj że tutaj na bieżąco pracujemy z interesariuszami. Nie tworzymy tego wszystkiego sami.

4. Dokumentujemy wymagania

Tutaj zapisujemy wszystkie nasze piękne wymagania w formie dokumentu (czy tam Confluence, czy tam wiki czy znany i lubiany Word). Pamiętamy tutaj o wszystkich dobrych praktykach związanych z dokumentacją(spójna, przejrzysta, modyfikowalna, kompletna, nie oderwana od rzeczywistości) i wymaganiami(zaakceptowanie, niedwuznaczne, aktualne, spójne, sprawdzalne, realne, możliwe do śledzenia, kompletne, zrozumiałe)

Pamiętamy tutaj też o tym żeby rozwiązanie było zrozumiałe dla obu stron projektu (interesariusze/zespół developerski).

5. Sprawdzamy wymagania

Cała nasza praca idzie do sprawdzenia do każdej ze stron projektu. Walidować powinien:

  • Zespół developerski
  • Interesariusze
  • Testerzy
  • Architekci
  • inni analitycy
  • eksperci dziedzinowi (ludzie od bezpieczeństwa, RODO, Prawnicy itd)
  • inni ludzie którzy „fajnie jakby zerknęli”

Technik jest masa(przeglądy, inspekcje, czytania oparte na perspektywie, checklisty itd).

6. Akceptujemy wymagania

Po sesjach walidacji wymagań uzyskujemy akceptację od osób które są zdefiniowane jako decyzyjne(oczywiście je wcześniej wyznaczyłeś prawda?)

KROK 3 Utrzymywanie wymagań biznesowych

Tutaj dopiero zaczyna się zabawa. Każdy z nas wie o tym że wymagania cały czas ulegają zmianie. Czy tego chcemy czy nie. Nikt nie lubi reworku(a szczególnie programiści).

No ale niestety. Tutaj wjeżdża na scenę krok który jest bardzo ważny w naszej pracy. A jest nim utrzymywanie wymagań. Co przez to rozumiem?

  • Sprawdzanie czy wymagania które developujemy są dalej aktualne
  • Sprawdzanie czy wymagania które wdrożyliśmy są dalej aktualne
  • Sprawdzanie wpływu zgłaszanych nowych zmian na zaimplementowany system
  • Sprawdzanie wpływu zgłoszonych zmian na cel biznesowy naszego projektu

Musimy sprawdzać czy są potrzebne zmiany. Musimy sprawdzać czy interesariusze chcą coś pozmieniać. Musimy sprawdzać czy przypadkiem nie rozjedziemy kosztów naszego projektu.

Co do kosztów to bywa różnie. Zmiana nazwy labelki jest tania ale przebudowanie całego procesu to już nie jest taka piękna sprawa.

Dlatego właśnie powstała cała gałąź wymagań dotycząca ich śledzenia. Całe to śledzenie wymagań robi się po to żeby ten krok był łatwy i przyjemny(no dobra, nie będzie ani łatwy ani przyjemny ale będzie łatwiejszy 🙂 )

KROK 4 Przygotowanie przypadków testowych na podstawie kryteriów akceptacji

Mamy udokumentowane i aktualne wymagania. Zespół developerski sobie ładnie rozwiązanie tworzy i potem nadchodzi czas weryfikacji. Ktoś to musi przetestować. Czy są to interesariusze? Czasem tak, czasem nie.

Niezależnie od tego kto to testuje to musimy się upewnić że zaimplementowane rozwiązanie spełnia pokładane w nim nadzieje. A jak to zrobić? No poprzez odpowiednie testowanie. A żeby odpowiednio coś przetestować i tym zarządzać to warto przygotować pod to przypadki testowe.

Dlatego w kolejnym kroku:

  1. Tworzymy przypadki testowe które udowadniają że zaimplementowany system spełnia cel biznesowy
  • Przypadki powinny być „realizowalne”(jakie ładne polskie słowo, ciekawe czy istnieje w języku polskim) przez zwykłego Kowalskiego
  • Wyniki tych przypadków testowych powinny być zrozumiałe dla każdej ze stron projektu (czyli interesariusze też) abyśmy mogli udowodnić że implementacja spełnia cel biznesowy

2. Bierzemy udział w testach

  • Sami testujemy rozwiązanie
  • Koordynujemy testy
  • Współpracujemy z testerami w celu upewnienia się czy testy zostały odpowiednio przeprowadzone
  • Zapisujemy i ew. wprowadzamy zmiany w wymaganiach które wypłynęły podczas testów akceptacyjnych
  • Zapisujemy zmiany które chcemy ewentualnie zaimplementować po wdrożeniu obecnego rozwiązania

KROK 5 Umożliwienie aby rozwiązanie wdrożono na produkcję

Nie mówię tutaj o tym żeby własnoręcznie instalować nowe wersje aplikacji na urządzenia użytkowników. Mówię tutaj o innej dziedzinie a mianowicie o dziedzinie za którą może odpowiadać analityk.

W kroku piątym:

  1. Przygotowujemy biznes do tego że zaraz wejdzie nowe rozwiązanie
  • Wysyłamy komunikację
  • Organizujemy szkolenia
  • Zmieniamy istniejące procedury (lub wdrażamy nowe)
  • Przygotowujemy dokumentację dla użytkownika (np. manuale)
  • Wyszukujemy i niszczymy opór użytkowników końcowych przed zmianą(UWAGA: Kluczowy punkt. Musimy namierzać każdy możliwy opór aby dać rozwiązaniu uczciwą szansę zaistnieć i być wykorzystywana przez użytkowników)

2. Monitorujemy wdrożone rozwiązanie

  • Obserwujemy jak użytkownicy korzystają z rozwiązania aby upewnić się że cel biznesowy został osiągnięty
  • Rejestrujemy wszystkie sugestie użytkowników mające na celu usprawnienie procesu
  • Poprawiamy błędy(w idealnym świecie błędy nie istnieją ;))

KROK 6 Rozpoczęcie procesu na nowo

Każda nowa zmiana to właściwie rozpoczynanie procesu na nowo. Różne organizacje różnie zarządzają zmianą. W różnych sytuacjach będziesz zaczynał proces od innych kroków(bo może być tak że zgoda i cel już został określony co nie zwalnia cię z odpowiedzialności o tym żeby się dowiedzieć jaki ten cel był). Koniec końców w każdym produkcie informatycznym takie są zadania do wykonania.

Podsumowanie

Jak widać przy implementacji nowych rozwiązań jest co robić(nie wspominając tutaj o zadaniach kierownika projektu, administratorów itd.) Jak zdobyć wiedzę o tym jak wykonywać pracę. Jest masa książek, masa poradników, blogów(jak np. ten) czy kursów online(jak np. ten który polecam). Jeszcze nie widziałem studiów licencjackich czy magisterskich z analizy biznesowej. Są tylko certyfikaty oraz studia podyplomowe. Temat jest szeroki więc nie zdziwię się jak takie studia powstaną. Jeśli chcesz zostać analitykiem IT to gorąco polecam bo praca jest ekscytująca i wymagająca(i przy okazji dobrze płatna bo to IT oczywiście ;P )

Bibliografia

  • A Guide to the Business Analysis Body of Knowledge (BABOK Guide)
  • Steven P. Blais – Business Analysis Best Practices for Success
  • Klaus Pohl, Chris Rupp – Requirements Engineering Fundamentals
  • PMI Business Analysis For Practicioners

Chcesz zostać Analitykiem IT? Kliknij w baner poniżej

DARMOWA checklista jakości wymagań!

Zapisz się na listę mailową a dam Ci za darmo checklistę jakości wymagań biznesowych.

Uzupełnienie powyższego pola stanowi zgodę na otrzymywanie od analizowac.pl newslettera zawierającego treści marketingowe. Zgodę można wycofać w każdym czasie. Wycofanie zgody nie ma wpływu na zgodność z prawem przetwarzania dokonanego przed jej wycofaniem.