1 Poziom: wiedza techniczna – 0
Scrum Master, Project Manager, Program Manager, Agile Coach
Są to role, które nie wymagają wiedzy i umiejętności technicznych. Tu jednak skupię się przede wszystkim na Scrum Masterze, jako że jet to najbardziej egzotyczna nazwa stanowiska dla kogoś spoza kontekstu informatycznego.
W przypadku Scrum Mastera kluczowa będzie porządna znajomość Scruma. Wymusza to już sama nazwa stanowiska, które sugeruje „mistrzostwo” w rozumieniu istoty i praktyk scrumowych.
Czym jest Scrum?
Krótko mówiąc, jest to jedno z narzędzi do realizowania założeń zwinnych metod wytwarzania oprogramowania – Agile. Czyli najbardziej popularnych i chyba również efektywnych podejść do software developmentu.
Co powinien wiedzieć Scrum Master?
Więc po pierwsze, w tym przedziale ról trzeba znać sposób pracy w produkcji oprogramowania. Bycie dobrym organizatorem, koordynatorem i egzekutorem tych praktyk. Po drugie, dostrzeganie problemów i sygnalizowanie ich zespołowi, managementowi i innym zainteresowanym oraz proponowanie rozwiązań.
Dalej, usuwanie problemów tzw. blockerów, które wstrzymują, czy opóźniają pracę. Monitorowanie pracy zespołu, zarówno bieżącej w cyklu dziennym (daily standup), jak i podczas planowania ilości zadań na daną iterację. Często na kilka kolejnych sprintów do przodu. Tu trzeba pilnować, żeby ilość punktów zaplanowanych na iterację nie przekraczała średniej ilości spalanych punktów z przeszłych iteracji, czyli tzw. velocity zespołu.
Coś jeszcze?
Tak, ale to dopiero na końcu. Będzie to wiedza techniczna, która na pewno ułatwi komunikację z zespołem, ale będzie to raczej w kategoriach nice to have.
Istotne jednak będzie zrozumienie cylku pracy w dostarczania kodu. Od zdefiniowania wymagań, poprzez zakodowanie, przetestowanie, zademowanie i wdrożenie na środowisko produkcyjne. Warto też wiedzieć, jak osadzone są te etapy w rutynie scrumowej oraz tzw. cyklach releasowych (wdrożeniowych).
Widziałem w tej roli osoby ze skrajnie różnym doświadczeniem zawodowym oraz wykształceniem. Byli to m.in. prawnik, pracownik recepcji, ale również programiści, testerzy. Była też praktyka, żeby członkowie zespołu wymieniali się tą rolą cyklicznie. Oczywiście nie jest najbardziej optymalnym rozwiązaniem.
2 Poziom: wiedza techniczna – „coś tam”
Product Owner, Analityk
Tu głównie potrzebna będzie wiedza biznesowa, analityczne myślenie (które w zetknięciu z praktyką może przyjść samo). Niesie to ze sobą umiejętność definiowania wymagań i pracy z produktem. Nie oznacza to, że wejście do IT w tej roli wymagać będzie bezwzględnie doświadczenia w każdej z tych ról. Choćby jeden z wymienionych elementów będzie już dobrym punktem zaczepienia na wejściu.
Techniczna wiedza będzie tu na korzyść o tyle, że pomoże ona w komunikacji z zespołem technicznym. A dobrze jest umieć rozmawiać z nimi ich językiem. Nie chodzi tu oczywiście o umiejętności kodowania, ale ogólne rozumienie tego, co oni tam robią, będzie na pewno na plus i ułatwi współpracę.
Z przypadków, z którymi się zetknąłem na tych stanowiskach, mógłbym również wymienić sporo skrajności, bo wszystko zależy od branży dla której robi się software. Hotelarze, pracownicy obsługi klienta (wszelkie branże), handlowcy, pracownicy lotnisk, ale również programiści, którzy poczuli się w tej roli lepiej.
3 Poziom: wiedza techniczna – tu się takowa zaczyna
Testerzy
Jest to pierwsza rola w tym zestawieniu, gdzie pojawia się mocniejszy aspekt techniczny. Wielu może się teraz zbulwersować, i słusznie. Jednak ja biorę tu pod uwagę również testerów manualnych, których jest już może coraz mniej w przyrodzie, ale jednak.
W przypadku takich testerów kluczowe będą raczej dobre praktyki i standardy testerskie. Pamiętajmy, że każda aplikacja jest inna, więc do manualnego testowania każdej z nich i tak trzeba będzie nauczyć się jej od nowa.
Dalej w grę wchodzić może testowanie z poziomu interakcji z API, za pomocą narzędzi typu POSTMAN, czy Soap UI. W parze może też iść wyciąganie informacji z baz danych.
Na końcu do gry wchodzą testerzy automatyczni, którzy coraz częściej są po prostu programistami, którzy skupieni są na testowaniu właśnie. Takich jest coraz więcej i coraz bardziej są pożądani.
Zetknąłem się z różnymi podłożami testerów jak: matematyk, fizyk, ekonomista, pracownik recepcji, czy specjalista od BHP.
4 Poziom: wiedza techniczna – punkt kulminacyjny
Programista
To jest punkt kulminacyjny umiejętności technicznych, gdzie bezwzględnie już muszą się pojawić, choć poziom może być różny. Od „coś tam umie zakodować” do „sprawdzimy cię na 3-etapowej rozmowie kwalifikacyjnej, gdzie zweryfikujemy twoją teorię, znajomości technologii i doświadczenia oraz przestrzeganiu standardów i biegłość w pisaniu kodu, a także poruszania się po IDE”
5 Poziom: wiedza techniczna – teoretycznie jeszcze więcej
DevOps
Miałem porblem z osadzieniem tego stanowiska, ale z racji tego, że formalnie jest to połączenie roli programisty (developera) oraz Operations, znalazł się szczebelek ponad developerem.
W praktyce bywa różnie. To docelowo szuka się ludzi z takimi kompetencjami. W rzeczywistości raczej odpuszcza się aspekt dev na rzecz ops, czyli częściej będą to ludzie, od których oczekuje się raczej skryptowania, wdrażania, przygotowania i konfiguracji środowisk oraz ich skalowalności. Wówczas, umieszczam taki zestaw umiejętności poniżej developera.
6 Poziom techniczny: bardziej już być nie może
Architekt Aplikacji
Często jest to zwieńczenie pracy programisty eksperta, ale nie zawsze. Na takich stanowiskach, często nie ma się już okazji do „zwykłego” codziennego kodowania, i części ludziom będzie tego brakować.
Mimo utraty możliwości codziennego bawienia się kodem, to odpowiedzialność za techniczną stronę aplikacji i technicznych rozwiązań będzie tu największa. To architekt nadaje kierunek technicznym rozwiązaniom i strategii rozwoju. To on jest pierwszą osobą kontaktową i najbardziej obleganą, co oczywiście wpływa na ogrom pracy, dostępność (niezależnie jaki dzień tygodnia oraz jego pora)
Podsumowanie
Nie każdy pracownik IT to osoba techniczna. Niemniej jednak bycie technicznym w jakimkolwiek stopniu przemówi zawsze na Twoją korzyść.
Co do kodowania – nie trzeba uczyć się go na uczelni i studiować przez pięć lat, kończąc tytułem naukowym. Piękno tego zawodu polega na tym, że wystarczy samozaparcie, chęć i konsekwencja, by zdobyć wszystkie potrzebne umiejętności do wykonywania tego zawodu. Cała wiedza jest w zasięgu ręki. Kompetencje i tak zostaną sprawdzone podczas rekrutacji.
Poznałem programistów z różnych dziedzin – od matematyków, przez polonistów do bliżej nieokreślonych samouków, którzy robili spektakularne kariery w IT, jako programiści (i wyżej) właśnie.
Szukam branży przyszłości, która podniesie komfort życia.
Jeśli jesteś zainteresowany pracą w IT, zachęcam do eksplorowania bloga. Dużo bardziej szczegółowo omawiam software development w książce Almanach Informatyczny – Lite.
Jej założeniem jest wprowadzenie każdego do świata IT w 100 słowach i turbo kompaktowych definicjach. Wszystko, czego potrzebujesz, żeby świadomie wybrać rolę dla siebie i czuć się komfortowo, kiedy już zaczniesz.
Powiązane artykuły:
- Jak dostać awans
- Jak znaleźć pracę w korporacji
- Praca w IT bez doświadczenia
- Praca w IT bez programowania
- Czy angielski jest konieczny w IT
- Humanista w informatyce
- Rekrutacja w IT
- (Nie)techniczna skala wejścia do IT
- Jak się pracuje w IT – czy to wszystko mit?
- Czym zajmuje się Scrum Master
- Czym zajmuje się Product Owner
- Co to jest Scrum w IT?
- Co to jest Agile w IT?
Zobacz także:
- Cechy dobrego Product Ownera
- 8 cech dobrego Scrum Mastera
- Co to jest API
- Co to jest REST API
- Co to jest CRUD
- Co to jest Product Backlog w IT?
- Estymowanie w Scrumie
- Jak pisać User Story
- Jak dobrze napisać historyjkę użytkownika, a jak robić to źle?
- Zmysły sztucznej inteligencji.
- Czy to wszystko mit? – czyli jak na prawdę pracuje się w IT?
- Humanista pośród informatyków
- Czym zajmuje się Scrum Master?
- Informatyk w informatyce.
- Umysł ścisły w informatyce
- AI w IT. Koniec dominacji ludzkiego intelektu?
- Geograficzna eksploracja IT
Dodaj komentarz