Zapraszam Cię bardzo serdecznie do obejrzenia filmu, w którym omawiam co warto wiedzieć na początku w IT.

A jeśli lepiej przyswajasz tekst, poniżej znajdziesz transkrypcję wystąpienia.

IT na wesoło

Zacznijmy od krótkiej wesołej historyjki. Zdjęcie, które teraz widzisz jest bardzo popularne w IT i pokazuje jak na wesoło wygląda proces budowy oprogramowania dla Klienta. Na obrazku oprogramowanie przedstawione jest jako huśtawka.

Na początku klient wyjaśnia jaką huśtawkę potrzebuje. Następnie widzimy jak wymagania klienta zostały zrozumiane przez Lidera Projektu. W kolejnym kroku jak Analityk zaprojektował rozwiązanie. Następnie jak Programista je zaimplementował. Jak zostało opisane przez Konsultanta dla Klienta. Jak rozwiązanie zostało udokumentowane. Następnie zainstalowane. Za co Klient zapłacił. Jak wygląda wsparcie i utrzymanie produktu. I co tak naprawdę Klient potrzebował. Jak widać sam proces wytwarzania oprogramowania jest złożony, składa się z wielu etapów i zaangażowanych jest wiele osób, ale szczegóły omówimy za chwilę.

Jak wygląda proces wytwarzania oprogramowania?

Najbardziej znanymi modelami wytwarzania oprogramowania są model kaskadowy (tzw. Waterfall) oraz model ewolucyjny. Model ewolucyjny zwany jest również modelem iteracyjnym.

W każdym modelu występują fazy takie jak na przykład analiza, projektowanie czy testowanie. Natomiast główna różnica między nimi jest taka, że w modelu kaskadowym jest tylko jeden cykl, każda faza występuje tylko jeden raz, z dowolnej fazy możemy przejść tylko do następnej bądź poprzedniej. Na przykład po zakończeniu wytwarzania nie możemy już powrócić do fazy planowania.

W modelu iteracyjnym jest wiele cyklów, podczas których występują fazy: planowanie, wymagania, analiza i projekt, testowanie, ocena. Model iteracyjny jest obecnie bardzo popularny, ponieważ umożliwia szybszą prezentację postępów klientowi w wytwarzaniu oprogramowania. Nie trzeba oczekiwać, aż do fazy testowania, jak w modelu kaskadowym, aby zobaczyć działające oprogramowanie. W modelu iteracyjnym dostarczamy działające oprogramowanie częściej, ale fragmentami.

Cykl wytwarzania oprogramowania omówimy na modelu kaskadowym, ponieważ analogiczne fazy występują w modelu iteracyjnym.

Każdy projekt rozpoczyna się od etapu planowania, w którym prowadzone są pierwsze rozmowy z Klientem. Podczas tych rozmów uzgadniany jest zakres projektu, czyli definiujemy wówczas listę wymagań Klienta wraz z priorytetami. Ustalany jest również budżet projektu, harmonogram projektu oraz osoby pracujące nad projektem.

Podczas fazy analizy uszczegóławiamy oraz dokumentujemy listę wymagań zdefiniowaną przez Klienta podczas fazy planowania. Dokonujemy klasyfikacji wymagań na funkcjonalne oraz niefunkcjonalne.

Wymagania funkcjonalne opisują zachowanie oprogramowania. Wymagania niefunkcjonalne opisują jakość oprogramowania. Na przykład czas uruchomienia aplikacji. Podczas tej fazy dokumentujemy wymagania za pomocą diagramów UML i/lub BPMN. Dodatkowo wymagania opisywane są za pomocą tzw. przypadków użycia. W dalszej części prezentacji zaprezentujemy przykładowe diagramy BPMN/UML i przypadki użycia.

Podczas fazy projektowania należy przygotować architekturę techniczną oprogramowania. Architekt IT odpowiedzialny jest za przygotowanie technicznej specyfikacji oprogramowania. Specyfikacja techniczna zawiera również informacje o infrastrukturze oprogramowania, czyli serwerach, na których zostanie zainstalowane oprogramowanie.

Wytwarzanie oprogramowania polega na implementacji rozwiązania zgodnie z dokumentacja dostarczona przez Analityka oraz Architekta. Wykonywane są także testy developerskie, przeważnie automatyczne. Następnie aplikacja jest instalowana na środowisku testowym i przekazywana do testów.

Testowanie polega na przeprowadzeniu testów oprogramowania. Wykonywane są testy manualne oraz automatyczne przygotowane przez testerów. Testowanie wykonywane jest w oparciu o przygotowane scenariusze testowe. Wszystkie wykryte błędy oprogramowania zgłaszane są do deweloperów w celu poprawy.

Faza utrzymania jest ostatnią fazą w cyklu wytwarzania oprogramowania. W tej fazie oprogramowanie jest już użytkowane przez Klienta oraz jego użytkowników. Na tym etapie przede wszystkim monitorujemy poprawność działania oprogramowania oraz rozwiązujemy zgłaszane incydenty i problemy.

Jakie są role w projektach IT?

W zespole IT możemy wyróżnić: Kierownika Projektu, Analityka, Architekta, Programistę, Testera, Administratora oraz Specjalistę wsparcia IT. Wybrani członkowie zespołu komunikują się z Klientem.

W bardziej złożonym projektach informatycznych może być wielu Analityków, Architektów, Programistów, Administratorów, Testerów i Specjalistów wsparcia IT. Wówczas struktura zespołu jest bardziej hierarchiczna. Każdy z liderów odpowiedzialny jest za swój zespół przed Kierownikiem Projektu.

Kierownik projektu pełni rolę koordynatora dbającego o to, aby projekt został wykonany na czas, w założonym budżecie wykorzystując do tego przydzielone zasoby ludzkie i materialne. Kierownik zarządza budżetem, harmonogramem projektu oraz zespołem. Jest także osobą, która rozwiązuje konflikty dbając o dobre relacje w zespole, tak aby praca jego członków była jak najbardziej efektywna. Kierownik jest także, osobą pierwszego kontaktu z Klientem.

Każdy projekt ma zdefiniowany zakres, czyli listę funkcji, które należy zbudować. Musimy być pewni, że zbudowana aplikacja jest przetestowana i działa poprawnie, czyli zachowana jest wymagana jakość. Rola kierownika projektu polega na tym, aby dostarczyć projekt zgodnie ze zdefiniowanym zakresem i przy zachowaniu jakości manipulując parametrami takimi jak czas projektu, koszty projektu oraz zasoby projektu. Jest to tzw. trójkąt zarządzania ryzykiem.

Przejdźmy do kolejnej roli Analityka. Analityk odpowiada za zebranie oraz udokumentowanie problemów oraz potrzeb klienta. Przykładową potrzebą może być zbudowanie narzędzia raportujące liczbę zamówień w sklepie czy zbudowanie narzędzia monitorujące w czasie rzeczywistym status zamówień. Klient może również zgłaszać problemy. Zrozumienie potrzeb oraz problemów klienta jest zadaniem analityka. Kolejne zadanie polega na zebraniu oraz udokumentowaniu wymagań funkcjonalnych oraz niefunkcjonalnych. Analityk komunikuje się z klientem oraz zespołem projektowym, czyli Kierownikiem Projektu, Architektem, Developerem, Testerem czy Administratorem.

Podczas analizy przygotowywane są diagramy procesów biznesowych w notacji BPMN. Przykładowy diagram procesu składania zamówienia został przedstawiony na slajdzie. Kupiec wypełnia kwestionariusz, następnie zamówienie jest akceptowane lub odrzucane. Jeśli zamówienie zostało zaakceptowane, wówczas równolegle następuje obsługa zamówienia oraz wysyłki. Na końcu następuje przegląd zamówienia przez kupca. Notacja BPMN jest bardzo popularna i łatwa do zrozumienia przez osoby techniczne oraz nietechniczne.

Analityk wykorzystuje również notację UML. UML jest językiem wykorzystywanym do modelowania oprogramowania. Umożliwia przygotowanie różnych diagramów opisujących system informatyczny. Popularnymi diagramami są diagram przypadków użycia, aktywności, sekwencji, komponentów, klas, wdrożenia oraz stanów. Przykładowy diagram przypadków użycia zaprezentowany jest na slajdzie.

A teraz omówmy rolę Architekta. Przede wszystkim odpowiada za zaprojektowanie architektury rozwiązania na podstawie wymagań funkcjonalnych oraz niefunkcjonalnych dostarczonych przez Analityka. Przygotowuje dokumentacje techniczna zawierającą również diagramy w notacji UML. Podczas prac nad architekturą spotyka się z innymi członkami zespołu projektowego jak Kierownik Projektu, Analityk, Developer, Tester czy Administrator.

Architekt wykorzystuje diagramy notacji UML w celu przedstawienia architektury oprogramowania. Popularnymi diagramami są diagram przypadków użycia, aktywności, sekwencji, komponentów, klas, wdrożenia czy stanów. Przykładowy diagram komponentów zaprezentowany jest na slajdzie powyżej.

Programista odpowiada za implementację rozwiązania na podstawie dokumentacji opracowanej przez Architekta oraz Analityka. Przygotowuje oraz wykonuje automatyczne testy developerskie. Podczas pracy jest w stałym kontakcie z pozostałymi członkami zespołu projektowego.

Administratorzy przygotowują infrastrukturę zgodnie z projektem Architekta. Przygotowanie infrastruktury polega na instalacji systemu operacyjnego, bazy danych, serwerów aplikacyjnych czy konfiguracji sieci na serwerach. Taka instalacja wykonywana jest na kilku środowiskach - developerskim, testowym oraz produkcyjnym. Liczba środowisk uzależniona jest od poziomu skomplikowania projektu. Z reguły jest od 3 do 6 środowisk. Podczas pracy Administrator jest w stałym kontakcie z Architektem, Developerem czy Testerem.

Diagram wdrożenia UML przedstawia projekt infrastruktury przygotowany przez Architekta. Z diagramu możemy odczytać jaki ma zostać zainstalowany system operacyjny, ile serwerów aplikacji, jaka baza danych i w jakiej wersji. W przedstawionym rozwiązaniu ma być również wykorzystany Load Balancer.

Tester odpowiada za testowanie rozwiązania. Wykonywane są testy manualne oraz automatyczne w oparciu o przygotowane scenariusze testowe. Wszystkie wykryte błędy oprogramowania zgłaszane są do Deweloperów w celu poprawy. Tester korzysta z różnych narzędzi oraz urządzeń w celu przeprowadzenia testów. Przykładowo podczas testów aplikacji należy przetestować ją na różnych urządzeniach mobilnych, tabletach czy komputerach z różnymi systemami operacyjnymi.

Specjalista wsparcia IT wspiera użytkowników w obsłudze aplikacji. Odpowiada za rozwiązywanie problemów zgłaszanych przez użytkowników. W przypadku usterek rejestruje je oraz przekazuje do zespołu utrzymującego oprogramowanie. Najczęściej specjalistą wsparcia IT jest osobą pierwszego kontaktu z użytkownikami aplikacji.

Jakie kompetencje posiada każda z ról w projektach IT?

Wszystkie kompetencje możemy podzielić na kompetencje miękkie oraz kompetencje twarde.

Kompetencje miękkie obejmują umiejętności interpersonalne/komunikacyjne oraz umiejętności osobiste.

Umiejętności interpersonalne i komunikacyjne to:

• zdolność uważnego słuchania oraz formułowania jasnych komunikatów,
• umiejętność pracy w zespole
• umiejętność radzenia sobie z konfliktami, negocjacje i wypracowywanie kompromisów.

Umiejętności osobiste to np.:

• kreatywność,
• asertywność,
• umiejętność pracy pod presja czasu,
• radzenie sobie ze stresem,
• umiejętność organizacji pracy.

A teraz omówmy kompetencje twarde. Przykładowe kompetencje twarde to:

• znajomość języków obcych,
• umiejętność obsługi programów komputerowych,
• znajomość języków programowania,
• czy prawo jazdy.

W zależność od pełnionej roli w projekcie informatycznym wymagane są różne kompetencje. Przykładowo Analityk musi posiadać dużo bardziej rozwinięte kompetencje miękkie niż kompetencje twarde. Natomiast Administrator musi posiadać więcej rozwiniętych kompetencji twardych niż miękkich.

Zespól IT jest na tyle rozbudowany, że umiejętność programowania nie zawsze jest wymagana. Przykładowo w testowaniu, utrzymaniu, zarzadzaniu projektem, zarzadzaniu produktem, marketingu, sprzedaży czy analizie biznesowej umiejętność programowania nie jest wymagana.

Na powyższym slajdzie przedstawiliśmy macierz kompetencji oraz ról. Na osi poziomej znajdują się kompetencje twarde. Im bardziej w prawo, tym bardziej rozwinięte kompetencje twarde. Na osi pionowej znajdują się kompetencje miękkie. Im bardziej do góry tym bardziej rozwinięte kompetencje miękkie. W zależności od roli wymagany jest inny poziom kompetencji twardych i miękkich. Analityk jest osobą, która musi mieć najbardziej rozwinięte kompetencje miękkie. Musi również posiadać kompetencje twarde, aby być w stanie komunikować się z technicznymi osobami takimi jak Architekt czy Programista. Programista jest osobą, która musi posiadać najbardziej rozwinięte kompetencje twarde, natomiast kompetencje miękkie nie są tak bardzo istotne w jego roli. Ciekawą rolą jest rola Architekta, który ma bardzo rozwinięte zarówno kompetencje miękkie, jak i twarde.

Zdobywając doświadczenie oraz nowe kompetencje będziecie mieli możliwość zmiany stanowiska. Popularne ścieżki kariery przedstawiliśmy na slajdzie. Przykładowo osoba zajmująca się testowaniem oprogramowania może rozwijać się w kierunku Analityka, Programisty bądź Kierownika Projektu. Rozwijając tylko swoje kompetencje miękkie może zostać Kierownikiem Projektu. Jeśli jednak zdecyduje się na rozwój tylko kompetencji twardych wówczas może zostać Programistą. Rozwijając zarówno kompetencje miękkie oraz twarde może zostać Analitykiem.

Porozmawiajmy pokrótce jeszcze o trendach przyszłości w IT. Obecnie widać coraz większe zainteresowanie chmura obliczeniowa, sztuczna inteligencja, Internetem Rzeczy, VR i AR oraz Blockchain. Będą to umiejętności wymagane coraz bardziej przez pracodawców.

Gdybyś chciał podzielić się ze mną swoim komentarzem napisz do mnie na marcin@marcinziemek.com

Jeśli chcesz rozwinąć swoją wiedzę z zakresu projektowania architektury IT, sprawdź też moją książkę dostępną pod adresem: https://architektura.marcinziemek.com

Jeśli chcesz rozwinąć swoją wiedzę z zakresu projektowania integracji systemów IT, sprawdź też moją książkę dostępną pod adresem: https://integracja.marcinziemek.com