W tym odcinku opowiadam o rolach projektach i stanowiskach, jakie można spotkać przy realizacji projektów w branży IT.

Transkrypcja odcinka

Cześć, nazywam się Krzysztof Rychlicki-Kicior i witam cię serdecznie w podcaście „Software z każdej strony”, w którym dowiesz się, jak łączą się ze sobą świat biznesu i IT.

To jest odcinek 27. Junior, senior i pryncypał, czyli o rolach w projektach IT słów kilka. Za nami już rok obecności w Internecie, rok obecności podcastu. No i niektóre tematy w naturalny sposób będą stawać się kontynuacją tych już omówionych. Było tak w poprzednim odcinku, w którym mówiłem o utrzymywaniu pracowników IT, zwłaszcza w kontekście domniemanego kryzysu, ale opowiadałem też o zatrudnianiu właśnie w odcinku 13. Dzisiaj będę kontynuować temat metodyk oprogramowania, który rozpocząłem niejako w odcinku 17. Przy czym wtedy mówiłem właśnie o metodykach, o procesach, o pojęciach jako takich, natomiast dziś skupię się na rolach projektowych, w projektach informatycznych, zwłaszcza że coraz częściej te pojęcia przenikają do szeroko pojętego świata biznesu, jak choćby omówienie, mówienie o rolach typu junior, regular czy też mid lub senior.

Zacznijmy od tego, że nie ma takiego jednego zbioru ról projektowych. Gdybym chciał być niezwykle precyzyjny, to musiałby stworzyć cały cykl odcinków, przeanalizować role w poszczególnych metodykach oprogramowania, także skupić się dość szczegółowo na różnicach. Ja oczywiście poruszę różne role takie najistotniejsze, natomiast mimo wszystko nie jest to trzydziestogodzinny wykład na uczelni a około dwudziesto-, trzydziestominutowy odcinek podcastu. Tak że postaram się zrobić wersję skróconą. Materiału na pewno by starczyło na takie długie omówienie, no ale nie o to jednak chodzi, aby spędzać nad tym aż tyle godzin. Po tych dwudziestu paru odcinkach nie będzie cię pewnie dziwić, drogi słuchaczu, droga słuchaczko, że opisując przykłady, będę odwoływał się do branży, która jest mi najlepiej znana, czyli do software house’ów, do branży tworzenia oprogramowania. Natomiast metodyka pracy, metodyka pracy w projektach – to jest ważne – może być stosowana w szeroko pojętym IT, ale też także i poza IT. Wszędzie tam, gdzie chodzi o dowiezienie, tak? O realizację jakiegoś projektu, uzyskanie pewnych konkretnych efektów, ale też takich, w których pojawiają się pewne role nadzorcze, wspierające, takie organizacyjne.

Zacznijmy od tego tradycyjnego trójpodziału ról właśnie już przywołanego we wstępie, czyli junior, regular, senior. I konia z rzędem temu, kto byłby w stanie ujednolicić to nazewnictwo wśród różnych firm IT. Zazwyczaj używa się do rozróżnienia tych ról takiej najbardziej oczywistej wartości, jaką jest staż czy też liczba lat doświadczenia, zwłaszcza jeżeli mówimy o konkretnej technologii. Takim podziałem, który używamy u nas wewnętrznie w Makimo, ale także z którym spotykam się od pewnego czasu w różnych firmach, to jest to, że junior to ktoś, kto ma do dwóch lat doświadczenia, mid z reguły 2 do 5, a senior to powyżej 5. Natomiast to jest mega umowne, to jest strasznie umowne, bo co w przypadku, gdy ktoś OK, ma na przykład 1,5 roku doświadczenia w technologii React, ale w ogóle przy tworzeniu oprogramowania pracował lat 5? Albo w ogóle ktoś jest bardzo doświadczonym programistą, programistką, ale dopiero zaczyna przygodę z technologią, z daną konkretną technologią? No, nie będę mówił po imionach, po nazwiskach, ale znam takie osoby, które dokładnie w takich sytuacjach były czy są. I takie sytuacje się zdarzają, natomiast pokazują one jedynie, że trudno napisać sobie jakiś prosty algorytm, zbiór reguł, który dopasuje nam kandydata, kandydatkę do stanowiska. Osobnym problemem jest to, że nie każda firma stosuje się do podanych wcześniej przeze mnie reguł takich przykładowych. Spotkałem się z sytuacją, że już po trzech miesiącach można być mid, jeżeli spełni się pewne założenia. A po dwóch latach seniorem. No i znowu – nawet nie jestem w stanie powiedzieć, że to podejście musi być z definicji złe, bo zależy, kogo pozyskują jako juniorów. No to niestety, jakby to powiedzieć, jest funkcja wielu zmiennych i trudno od razu na podstawie takiego jednego stwierdzenia stwierdzić, że to jest dobre bądź złe podejście. No ale dobrze. Przejdźmy może jednak do bardziej konstruktywnych wniosków.

Kim jest junior? Junior to ktoś, kto w swej pracy nie jest samodzielny. Otrzymuje do zrobienia zadania, natomiast, choć z reguły jest w stanie je zrobić, to jednak potrzebuje wsparcia, bo zwłaszcza tutaj w IT ważne jest nie tylko osiągnięcie zadanego efektu, że nie wiem, po kliknięciu przycisku ma nastąpić wyszukiwanie produktu w sklepie, ale ważne jest też to, jak to jest faktycznie zrobione, można powiedzieć, pod maską. Zwłaszcza ta druga sfera, ta można powiedzieć – niewidoczna – jest ważna pod tym kątem, że wymaga opieki kogoś z zespołu, kogoś bardziej doświadczonego. Bo o ile, no nie wiem, na przykład po otrzymaniu wytycznych, jak ma wyglądać taki przycisk do wyszukiwania, co ma się dokładnie zdarzyć, czy ma być jakaś animacja ładowania, to to jest stosunkowo łatwo zweryfikować, czy to działa, czy nie, o tyle utrzymanie pewnych standardów jakościowych właśnie pod maską, no, nie jest już takie oczywiste, trudno może być takiemu juniorowi ocenić, czy zadanie zostało zrobione dobrze, czy też nie.

Mid-developer czy w ogóle mid-specjalista, zwany czasem regularem, czyli takim regularnym specjalistą to osoba samodzielna, która otrzymuje zadania i je realizuje. Jest odpowiedzialna przede wszystkim za swoją pracę, choć w niektórych sytuacjach może też wspierać w rozwoju jakiegoś juniora. I ta samodzielność, to, że dając jej pewne zadanie do wykonania, zostanie ono zrealizowane, jest tutaj kluczowa. I to jest tylko tyle i aż tyle. Jeśli chodzi o to, że tutaj pojawiają się dwa określenia – no, firmy używają ich zamiennie. W jednej firmie spotkałem się, że chyba było w ogóle osobno rozróżnione role mid i regular, aczkolwiek to jakaś taka trochę aberracja. Natomiast z reguły oznacza to przede wszystkim pracownika samodzielnego.

No i senior. Senior to specjalistka, specjalista, który wyróżnia się doświadczeniem. I tu zaczynają się schody. Czasami w mniejszych projektach to będzie człowiek, który pociągnie cały mały projekt, na przykład MVP dla jakiegoś startupu, jakąś małą pierwszą wersję wręcz całego projektu. W większych może zająć się pracą z małym zespołem, ale co do zasady raczej kompetencje związane z dowodzeniem zespołem traktujemy nieco odrębnie. Z pewnością seniorzy służą doświadczeniem swoim młodszym stażem kolegom, koleżankom, czy to juniorom, czy to midom. No bo to z reguły u nich właśnie te zasoby wiedzy i doświadczenia są w zakresie danych technologii największe. Jest to naturalne, że takiego wsparcia od nich można oczekiwać.

No dobrze. A co dalej? Wyżej, można tak by rzec, mamy role, które w pewien sposób dzielą się na dwie grupy. Jeśli ktoś dobrze radzi sobie z pracą zespołową, to może zostać team czy też technical liderem, który nie tylko zna się na technologii, ale jest w stanie skoordynować pracę zespołu. Oczywiście team leader to osoba bardziej skoncentrowana na koordynowaniu zespołu. Tutaj to czasem ma właśnie podwójne znaczenie, bo to jest także rola przywództwa technicznego, a bardzo różne są losy życiowe programistów. Niektórzy chcą bardziej angażować się w technologie, inni właśnie w bardziej w te miękkie aspekty, dlatego to te funkcje traktuję czasem wymiennie. Ale tak, jest to w danym projekcie osoba centralna, jeśli chodzi o kwestie technologii. Zależy tutaj jakby konkretne znaczenie od metodyki, ponieważ na przykład w typowym Scrumie raczej takiej roli wprost nie wyróżniamy, bo mamy dużo inny ścisły podział ról, choć siłą rzeczy może być taki nawet nieformalny przywódca, po prostu osoba najbardziej doświadczona od strony danej technologii. Jeżeli prowadzenie, wspieranie, mentorowanie zespołu takiego seniora nie kręci, to można przejść do roli architekta, czyli osoby odpowiedzialnej nie za taką techniczną realizację wykonanie systemu, tylko za przygotowanie jego struktury, zwanej też właśnie architekturą. No, tak jak w budownictwie, tak jak przy konstruowaniu budynków architekt nie zajmuje się tym fizycznym aspektem wykonania, tylko przygotowuje projekt, tak i tutaj architekt oprogramowania przygotowuje projekt do realizacji, dbając o to, aby on uwzględniał równe wytyczne, nie tylko to, co ma robić danych system, ale czy będzie we właściwy sposób się skalował, obsługiwał ruch, będzie stabilny, także kwestie bezpieczeństwa. Bardzo często właśnie architektami są osoby z dużym doświadczeniem też w programowaniu, którzy chcą się zająć już nie samym programowaniem, tylko takimi zadaniami bardziej wysoko poziomowymi. Tutaj warto zwrócić uwagę, że oczywiście w mniejszych projektach, gdzie mamy jakiś taki zespół kilkuosobowy, to bardzo często rola architekta łączy się z rolą team leadera, technical leadera, bo często zdarza się, że ta osoba, która jest w stanie poprowadzić zespół od strony technicznej, no, potrafi też przygotować architekturę takiego systemu.

Przedstawiony podział na role na pewno może wyglądać inaczej, zwłaszcza w dużych organizacjach. Ja siłą rzeczy nieco bardziej orientuję się, z doświadczenia znam te role z mniejszych firm, ale na przykład w dużych korporacjach można spotkać się z rolą principal software engineer, czyli taką najwyższą rolą techniczną, powyżej których są już role stricte zarządcze. I to jest taka osoba, która raczej nie prowadzi sama dużych projektów, to znaczy nie jest bezpośrednio zaangażowana w realizację projektów, tylko pełni taką rolę doradczą w różnych projektach, no, jest to osoba, która ma dużo doświadczenia, dużo wiedzy i szkoda, żeby marnowało się to doświadczenie w jednym projekcie. Tutaj też warto zwrócić uwagę, że to w zasadzie nie jest rola projektowa, a bardziej stanowisko, co też może się mieszać, bo ktoś może być deweloperem, zatrudniony jako deweloper, ale mieć na przykład w danym projekcie jeszcze rolę team leadera. Tutaj oczywiście taki principal może na przykład pełnić rolę architekta w jednym projekcie, doglądać inne, natomiast chodzi o to, aby taką osobę jak najlepiej zastosować w organizacji, jej doświadczenie, jej wiedzę.

Wreszcie w mniejszych organizacjach, często startupach, choć oczywiście również i w większych firmach, kilkusetosobowych, tak naprawdę w korporacjach, ale to też może nie jest aż tak używane bezpośrednio to pojęcie, chodzi o CTO – Chief Technology Officer – czyli taki naczelny decydent w zakresie technologii. W startupach pojawia się bardzo często, tak naprawdę w dużych firmach czasami po prostu jest to nazywane inaczej, nie wiem, jakiś tam wiceprezes do spraw IT czy technologii, natomiast to już jest taki zdecydowanie decydent, to już jest też członek kadry zarządczej, który jednakże wciąż ma kluczowy wpływ na podejmowanie decyzji technologicznych. Tutaj na tej roli czy też stanowisku kończymy omówienie techniczne.

Ja też oczywiście dodam, bo w sumie powinienem był to powiedzieć trochę wcześniej. To nie jest tak, że przedstawiony przeze mnie obraz świata będzie się zawsze i wszędzie powtarzał, zresztą zwracam uwagę, że to nazewnictwo może wyglądać trochę inaczej w startupach, trochę inaczej w dużych firmach, natomiast staram się przede wszystkim wskazać kierunki, pewien poziom zrozumienia, czym może zajmować się taki specjalista. Nie oznacza to, żę w jakiejś konkretnej firmie to znaczenie będzie po prostu inne. No dobrze.

Ale jak jesteśmy już po omówieniu technicznym, przejdziemy teraz do ról nietechnicznych czy też organizacyjnych, nadzorczych – jak zwał, tak zwał, ale można powiedzieć, że programować czy też wykonywać jakichś technicznych działań w nich nie trzeba. A może jednak? Tutaj chciałbym przede wszystkim poruszyć taką jedną rzecz. Ale ona jest niezwykle ważna, która jakby wynika z różnic pomiędzy podejściami zwinnymi a takimi klasycznymi, z Waterfallem a Scrumem przede wszystkim, bo to jest temat, który spotykam, czasem współpracując z innymi firmami. Kiedy współpracujemy z innymi firmami, widzimy pewne niuanse w tym, jak są interpretowane różne role i mam ochotę po prostu zająć stanowisko w tym – można powiedzieć – sporze.

Otóż w klasycznym podejściu, takim powiedzmy Waterfallowym, czy też czasami wręcz nie mówi się, że to jest Waterfall, tylko po prostu mamy zakres, robimy projekt, oddajemy. Często mówi się, że mamy po prostu kierownika projektu, project managera, kogoś, kto, no – powiedzmy wprost – weźmie projekt za twarz i doprowadzi do końca. Oczywiście nie chodzi tutaj o aspekty techniczne, tylko o skoordynowanie pracy różnych osób, różnych ról i zadba po prostu o końcowy sukces projektu. Jest to model – można by rzec – tradycyjny, natomiast zasadniczo odmienny w porównaniu do bardzo popularnej metodyki Scrum, w której pojawia się inne podejście do realizacji projektu, bo w Scrumie mamy przecież ten zespół deweloperski, czyli krótko mówiąc – ekipę wykonawczą. Natomiast nie ma kierownika projektu. Mamy dwie osoby, które nie chcę powiedzieć, że dzielą między sobą te obowiązki, bo to jest w ogóle inne podejście do realizacji. Trochę, może nawet bardzo. Natomiast mamy product ownera, który odpowiada za koordynowanie interesariuszy, który dba o rozwój produktu, natomiast mniej zagłębia się w te techniczne aspektu. Mamy Srcum Mastera, który z kolei pilnuje tego, aby projekt podążał, był realizowany zgodnie z metodyką Scrum, czyli też, krótko mówiąc, pilnuje pewnego rodzaju porządku. Tutaj warto zwrócić uwagę, że jeżeli ktoś mówi, że robi projekt Scrumem i jeżeli taka klasyczna rola project managera… Przy czym nie mówię tu o nazwach, chociaż zdaniem purystów te nazwy też są ważne, bo ktoś może mieć etykietkę PM, tak? Project manager, kierownik projektu, tylko raczej o podział zadań. No jeżeli ktoś mówi, że właśnie robi Scruma, ale ma takiego kierownika, który trzyma wszystkich za twarz i po prostu przydziela im zadania i pilnuje realizacji, to to nie jest taki typowy Scrum. I to jest właśnie coś, na co chciałbym zwrócić uwagę, bo to w praktyce… no, wiecie. To nie jest język programowania, który ma bardzo precyzyjne, wręcz matematyczne reguły, albo program da się uruchomić, albo nie, skompilować, powiedzmy. Tutaj mówimy już o metodyce, która może być kompilowana, wdrażana z różną dokładnością. I moim zdaniem trzeba wiedzieć, na co się pisze. Te metodyki też mają swoje zastosowania. Powiedziałbym, że w kontekście realizacji projektów związanych z tworzeniem oprogramowania to Scrum jest statystycznie częściej lepszy, przynajmniej przy projektach takich, przy których ja miałem okazję pracować, natomiast zdecydowanie pamiętajmy, że te role w tych projektach klasycznych, nazwijmy to, i Scrumowych, Agile’owych, różnią się.

Na zakończenie dodam tylko, że celowo nie mówiłem tutaj o takim podziale, można powiedzieć, w innym wymiarze, czyli na programistów, bazodanowców, administratorów, dewopsów, testerów, bo jakby chciałem się skupić na takim podziale związanym właśnie z kryteriami takimi jak staż, doświadczenie czy ewentualnie role miękkie i twarde, a nie wchodzić po prostu jakby w różne rodzaje specjalności bycia informatykiem. Mam nadzieję, że takie spojrzenie niejako z wewnątrz branży pomoże ci zrozumieć, co kryje się za tymi mniej lub bardziej jasnymi pojęciami i jeżeli będziesz miał, miała okazję właśnie współpracować z jakimkolwiek zespołem informatycznym, to będzie ci łatwiej zrozumieć, jakie można mieć oczekiwania wobec poszczególnych członków zespołu.

Na dzisiaj to już wszystko, bardzo dziękuję za wysłuchanie tego odcinka. Kłaniam się nisko i do usłyszenia.

KONIEC