Dzień pracy…analityka systemowego
Dziś zapraszam na kolejny post z serii Dzień pracy!
Oczekiwany przez wiele osób, które już wiedzą, że chcą pracować w IT, ale niekoniecznie w roli programisty.
Przyjrzymy się jak wygląda rzeczywistość pracy analityka systemowego. Przyjmę też kilka założeń, które realnie wpływają na to jak taki dzień pracy może wyglądać.
Założenia:
- Analityk systemowy na poziomie Junior lub Mid
- Firma: software house, 50-100 osób
- Zespół: do 10 osób
- Projekt: 6-12 msc, etap analizy i implementacji
- Model pracy: Praca hybrydowa, 2-3 dni w biurze, reszta zdalnie
- Etat: Pełen etat, godziny standardowe, dopasowane do reszty zespołu
- Inne: Zwinne metodyki wytwarzania oprogramowania, klient z sektora publicznego
Dlaczego tyle założeń?
Każde z wymienionych wyżej założeń ma bezpośredni wpływ na to jak dzień analityka będzie wyglądał. Postanowiłam zaprezentować w miarę standardową „konfigurację” stanowiska, dla osób rozpoczynających swoją karierę w IT.
No i jak to wygląda?
Kawa. Najpierw kawa.
09:00 – Rozpoczęcie dnia pracy, najlepiej spotkaniem zespołu typu daily (piszę „typu daily”, gdyż nie chcę opisywać sposobu pracy w konkretnej metodyce a tylko zaznaczyć konkretne wydarzenia z danego dnia). Jeśli w biurze – to spotkanie w salce konferencyjnej lub największym pokoju zespołu. Jeśli online to wszyscy widzimy się na zoomie/teamsach. Spotkania wyglądają różne – jeśli prowadzone zgodnie z pewną popularną metodyką projektową – trwają 15 minut i każdy z członków zespołu wymienia swoje zadania na dany dzień. Jeśli służą omówieniu zadań, wyzwań (czyt. problemów) oraz priorytetów – potrafią trwać nieco dłużej. Dobrze jest, jeśli w oprogramowaniu pomocniczym typu asana, gitlab czy trello są opisane zadania, przydzielone osoby, określone terminy i priorytety. Analityk często prowadzi interakcje z wieloma członkami zespołu – od testera, programisty aż do kierownika projektu. Analityk, też co ważne, MA KONTAKT Z KLIENTEM!
Co dalej?
Analityk w swoim planie dnia ma przeważnie sporo spotkań. Analityk jako osoba, która odpowiada za szczegółową specyfikację wymagań na system, sam musi je dobrze poznać i zrozumieć. Do tego wymagany jest dobry dialog z zamawiającym (klientem). Analityk musi też rozumieć jak przetłumaczyć czasem niezbyt klarowne wymagania klienta na język zrozumiały z kolei dla programistów. Sposobów opisu wymagań oraz systemów czy programów do tego celu jest sporo. Może być to notacja BPMN, może być to UML. Mogą być to dokumenty wymagań funkcjonalnych i niefunkcjonalnych, przypadków użycia. Mogą być do diagramy graficzne o rożnym poziomie szczegółowości. Czasem jest to excel :). Jednak oprócz formalnego wyglądu, który często narzucony przez standardy korporacyjne, ważniejsza jest zawartość merytoryczna i szczegółowość opisu założeń.
Analityk musi zrozumieć, że dokument analizy jest bronią obosieczną. Opisuje tak szczegółowo jak się da system, nie tylko po to aby programista zrozumiał jak funkcjonalność napisać. Ale też.. a może i przede wszystkim jest to dokument, który, zaakceptowany przez klienta służy do sprawnego przeprowadzenia testów odbiorczych. Pozwala na szybką identyfikację różnic między błędami a zmianami. Dzięki szczegółowym opisom, w czasie trwania gwarancji powdrożeniowej klient nie może powiedzieć – to błąd, myślałem, że to inaczej ma działać. Nie – ma działać tak jak jest to opisane w analizie. Dlatego każde słowo, każda strzałka, każdy znak logiczny musi być przemyślany aby uniknąć sytuacji w której zarzucane jest błędne działanie systemu – a tak naprawdę jest to próba wymuszenia zmian w ramach testów odbiorczych czy gwarancji.
Jest też jeszcze jeden ważny argument dlaczego analiza powinna być szczegółowo i poprawnie opisana. Rotacja pracowników pracujących w firmach IT jest duża. Projekt IT, który zakłada wykonanie systemu informatycznego to nie przedmiot na studiach gdzie zasada 'zrobić, zdać i zapomnieć’ jest zasadą nadrzędną. Systemy mają być tworzone by korzystać z nich co najmniej kilka lat, a w praktyce się okazuje, że i dłużej. Częstą praktyką jest, że firma, która wykonuje system, dalej przez wiele lat jest odpowiedzialna za jego utrzymanie oraz rozwój. W sytuacji (nierzadkiej), że po wdrożeniu systemu z oryginalnego zespołu wytwórczego zostaje 1 lub 0 osób a klient wymaga utrzymania, asysty technicznej i zleca wykonywanie zmian, dokumenty analityczne stanowią całą bazę wiedzy o tym jak system działa, z czego się składa, jak poszczególne moduły ze sobą powiązane itd. Dlatego tak istotne jest posiadanie dobrych jakościowo dokumentów i opisów systemu.
Do kompletu, w ramach zadań analityka tworzone są różnego rodzaju dokumentacje użytkowników końcowych, a w szczególności uwielbiane ( ;)) przez wszystkich analityków instrukcje użytkownika. Jednak dobre przygotowanie instrukcji, w prosty i przejrzysty sposób, pozwala później zaoszczędzić sporo czasu na odpowiadanie na maile z pytaniami, zarzutami, że coś nie działa i na odbieranie telefonów od użytkowników nie wiedzących jak mają sie właściwie poruszać po zamówionym przez siebie systemie.
Do obowiązków analityka należą też często przeprowadzanie prezentacji systemu oraz szkolenia dla użytkowników. Cenną umiejętnością jest też więc łatwość prowadzenia wystąpień oraz ciekawy styl opowiadania. W takich momentach też kluczowe jest zrozumienie branży klienta oraz posiadanie wiedzy dziedzinowej. Więcej o tym piszę w swoim ebooku IT – sektor marzeń?
I tak po całym dniu spotkań, prezentacji, kolejnych spotkań, telefonów, zoomów, teamsów, opisów, maili, dokumentów…nagle jest 17:00. I jako, że w założeniach mamy wczesny etap projektu to jeszcze wszyscy mają czas. Dla siebie, dla zadań. Można zamknąć komputer.
A tak z przymrużeniem oka – zostawiam tu ten klasyk 🙂 :
To jak Ci się rzeczywistość pracy analityka w firmie IT podoba?
