Na obecnym etapie rozwoju oprogramowania przemysłowego można zaobserwować różnorodne role produkcyjne. Ich liczba rośnie, klasyfikacja z roku na rok staje się coraz bardziej skomplikowana, a w naturalny sposób procesy doboru specjalistów i pracy z zasobami ludzkimi stają się coraz bardziej skomplikowane. Informatyka (IT) to obszar wysoko wykwalifikowanych zasobów pracy i niedoborów kadrowych. Tutaj proces rozwoju kadr i potrzeba systematycznej pracy z potencjałem kadrowym są znacznie skuteczniejsze niż bezpośrednia selekcja z wykorzystaniem zasobów Internetu.
W artykule omówiono zagadnienia istotne dla specjalistów HR w firmach IT: związki przyczynowo-skutkowe w ewolucji ról produkcyjnych, konsekwencje błędnej interpretacji treści ról dla pracy HR w ogóle, a także możliwe możliwości zwiększenia efektywność rekrutacji specjalistów.
Produkcja IT dla niewtajemniczonych
Kto jest kim w IT to temat do dyskusji na różnych platformach. Istnieje tak długo, jak cała branża IT, czyli od pojawienia się na rynku konsumenckim pierwszych firm zajmujących się tworzeniem oprogramowania na początku lat 90-tych ubiegłego wieku. I przez ten sam czas nie było wspólnego stanowiska w tej kwestii, co stwarza trudności i zmniejsza efektywność pracy personelu. Spróbujmy to rozgryźć.
Dla mnie temat ról produkcyjnych w sektorze IT stał się aktualny i interesujący odkąd dołączyłem do firmy IT. Poświęciłem dużo czasu i nerwów, próbując zrozumieć proces produkcyjny. Koszty te przerosły moje oczekiwania i koszty dostosowania do procesów w innych obszarach: edukacja, produkcja materiałów, mały biznes. Zrozumiałem, że procesy są złożone i niezwykłe, ponieważ ogólnie rzecz biorąc, człowiek jest bardziej przystosowany do świata materialnego niż wirtualnego. Ale był intuicyjny opór: wydawało się, że coś tu jest nie tak, nie powinno tak być. Proces adaptacji trwał chyba rok, co w moim rozumieniu jest po prostu kosmiczne. W rezultacie dość jasno rozumiałem kluczowe role w produkcji IT.
Obecnie kontynuuję pracę nad tym tematem, ale na innym poziomie. Jako kierownik centrum rozwojowego firmy informatycznej często muszę komunikować się ze studentami, nauczycielami akademickimi, kandydatami, uczniami i innymi osobami, które chcą wziąć udział w tworzeniu produktu IT w celu promowania marki pracodawcy na rynku pracy nowego terytorium (Jarosław). Komunikacja ta nie jest łatwa ze względu na niską świadomość rozmówców dotyczącą organizacji procesu wytwarzania oprogramowania, a co za tym idzie, brak zrozumienia przez nich tematu rozmowy. Po 5–10 minutach dialogu przestajesz otrzymywać informacje zwrotne i zaczynasz czuć się jak obcokrajowiec, którego mowa wymaga tłumaczenia. Z reguły wśród rozmówców znajduje się ktoś, kto w dialogu rysuje linię i głosi ludowy mit z lat 90.: „Tak czy inaczej wszyscy informatyki są programistami”. Źródła mitu są następujące:
- Branża IT szybko się rozwija, w tych warunkach wszystkie podstawowe znaczenia i zasady są na etapie kształtowania się;
- Trudno jest istnieć w warunkach niepewności, dlatego człowiek stara się ułatwić sobie zrozumienie nieznanego, tworząc mity;
- człowiek jest bardziej przyzwyczajony do postrzegania świata materialnego niż wirtualnego, dlatego trudno mu zdefiniować pojęcia, które są poza jego percepcją.
Próba zwalczania tego mitu może czasami przypominać walkę z wiatrakami, ponieważ istnieje kilka aspektów problemu, którymi należy się zająć. Specjalista HR musi po pierwsze mieć jasny obraz ról produkcyjnych w firmie IT w idealnym i rzeczywistym wykonaniu, po drugie, rozumieć, jak i kiedy można najskuteczniej wykorzystać wewnętrzne zasoby firmy, a po trzecie, jakie realne metody pozwolą pomogą zwiększyć świadomość uczestników rynku pracy i przyczynią się do rozwoju marki pracodawcy. Przyjrzyjmy się bliżej tym aspektom.
Cykl życia oprogramowania jako podstawa ról produkcyjnych
Nie jest tajemnicą, że generalnie wszystkie stanowiska produkcyjne w każdej firmie IT mają za swoje źródło cykl życia oprogramowania. Dlatego też, jeśli postawimy sobie za zadanie koncepcyjne uzgodnienie jednolitego postrzegania tego zagadnienia w całej branży IT, musimy w szczególności oprzeć się na cyklu życia oprogramowania jako akceptowanej i jasno zrozumiałej przez wszystkich podstawie semantycznej. Dyskusja nad konkretnymi możliwościami realizacji zagadnienia ról produkcyjnych wpisuje się w płaszczyznę naszego twórczego podejścia do cyklu życia oprogramowania.
Przyjrzyjmy się zatem etapom, jakie obejmuje cykl życia oprogramowania, na przykładzie metodologii RUP. Są to linki dość dojrzałe pod względem treści i terminologii. Proces produkcyjny zawsze i wszędzie zaczyna się od modelowania biznesowego i formułowania wymagań, a kończy (oczywiście warunkowo) konsultacjami z użytkownikami i modyfikowaniem oprogramowania w oparciu o „potrzeby” użytkowników.
Jeśli wybrać się na historyczną wycieczkę do końca ubiegłego wieku (jak wiadomo, był to okres „automatyzacji wyspowej”), można zauważyć, że cały proces tworzenia oprogramowania wykonywał programista-programista. Oto korzenie mitu, że każdy informatyk jest programistą.
Wraz ze wzrostem złożoności procesów produkcyjnych, pojawieniem się zintegrowanych platform i przejściem do złożonej automatyzacji obszarów tematycznych, wraz z reengineeringiem procesów biznesowych, nieuniknione staje się pojawienie się wyspecjalizowanych ról powiązanych z etapami cyklu życia. Tak wygląda analityk, tester i specjalista wsparcia technicznego.
Różnorodność stanowisk na przykładzie roli analityka
Analityk (zwany także inżynierem analitykiem, nazywany także dyrektorem, metodologiem, analitykiem biznesowym, analitykiem systemowym itp.) pomaga „zaprzyjaźnić się” z zadaniami biznesowymi i technologiami ich realizacji. Opis sformułowania problemu dla programisty – tak można scharakteryzować główną funkcję analityka abstrakcyjnego. Pełni rolę łącznika pomiędzy klientem a programistą w procesach tworzenia wymagań, analizy i projektowania oprogramowania. W rzeczywistych warunkach produkcyjnych listę funkcji analityka wyznacza sposób organizacji produkcji, kwalifikacje specjalisty oraz specyfika modelowanego obszaru tematycznego.
Niektórzy analitycy są zlokalizowani bliżej klienta. Są to analitycy biznesowi (analityk biznesowy). Głęboko rozumieją procesy biznesowe w danym obszarze tematycznym i sami są ekspertami w procesach zautomatyzowanych. Posiadanie takich specjalistów w załodze przedsiębiorstwa jest bardzo ważne, zwłaszcza przy automatyzacji skomplikowanych metodologicznie obszarów tematycznych. W szczególności dla nas, automatyzatorów procesu budżetowego państwa, jest po prostu konieczne, aby wśród analityków znaleźli się eksperci merytoryczni. Są to wysoko wykwalifikowani pracownicy, posiadający dobre wykształcenie finansowo-ekonomiczne oraz doświadczenie w pracy we władzach finansowych, najlepiej na stanowiskach wiodących specjalistów. Doświadczenie nie w branży IT, a konkretnie w danej dziedzinie jest niezwykle ważne.
Druga część analityków jest bliżej deweloperów. Są to analitycy systemowi (Analityk systemu). Ich głównym zadaniem jest identyfikacja, usystematyzowanie i analiza wymagań klienta pod kątem możliwości ich zaspokojenia, przygotowanie specyfikacji technicznych i opisanie stwierdzeń problemowych. Rozumieją nie tylko procesy biznesowe, ale także technologie informacyjne, dobrze rozumieją możliwości oprogramowania dostarczonego klientowi, mają umiejętności projektowe i dlatego rozumieją, jak najlepiej przekazać deweloperowi interesy klienta. Pracownicy ci muszą posiadać wykształcenie w dziedzinie ICT oraz podejście inżynieryjno-techniczne, najlepiej doświadczenie w IT. Przy wyborze takich specjalistów posiadanie umiejętności projektowania z wykorzystaniem nowoczesnych narzędzi będzie niewątpliwym atutem.
Innym rodzajem analityków są autorzy tekstów technicznych. Zajmują się dokumentacją w ramach procesów wytwarzania oprogramowania, opracowywaniem instrukcji dla użytkowników i administratorów, instrukcji technologicznych, filmów szkoleniowych itp. Ich głównym zadaniem jest umiejętność przekazania informacji o działaniu programu użytkownikom i innym zainteresowanym osobom, zwięzłe i jasne opisanie rzeczy skomplikowanych technicznie. Pisarze techniczni w większości doskonale władają językiem rosyjskim, a jednocześnie mają wykształcenie techniczne i umysł analityczny. Dla takich specjalistów największe znaczenie ma umiejętność tworzenia jasnych, kompetentnych, szczegółowych tekstów technicznych zgodnie ze standardami, a także znajomość i opanowanie narzędzi dokumentacyjnych.
Widzimy więc tę samą rolę (a przy okazji pozycję w tabeli personelu) – analityka, ale w różnych jego specyficznych wcieleniach aplikacyjnych. Poszukiwanie specjalistów dla każdego z nich ma swoją własną charakterystykę. Warto wiedzieć, że tego typu analitycy muszą posiadać umiejętności i wiedzę, które często są nie do pogodzenia w jednej osobie. Jeden to humanista, skłonny do pracy analitycznej z dużą ilością dokumentów tekstowych, z rozwiniętymi umiejętnościami mowy i komunikacji, drugi to „technik” z myśleniem inżynierskim i zainteresowaniami w dziedzinie IT.
Czy czerpiemy z zewnątrz, czy rośniemy?
Dla dużego przedstawiciela branży IT skuteczność bezpośredniego doboru z zasobów Internetu maleje wraz z rozwojem projektów. Dzieje się tak w szczególności z następujących powodów: niemożliwa jest szybka adaptacja do skomplikowanych procesów w firmie, szybkość opanowania konkretnych narzędzi jest mniejsza niż szybkość realizacji projektu. Dlatego ważne jest, aby specjalista HR wiedział nie tylko, kogo szukać na zewnątrz, ale także jak wykorzystać wewnętrzne zasoby firmy, od kogo i jak wykształcić specjalistę.
Dla analityków biznesowych bardzo ważne jest doświadczenie pracy w realnych procesach z danego obszaru, dlatego rekrutowanie ich „z zewnątrz” jest skuteczniejsze niż rozwijanie ich wewnątrz firmy. Jednocześnie ważne jest, aby specjalista HR znał listę organizacji, które mogą być źródłem tego zasobu ludzkiego, a przy wyborze skupiał się na wyszukiwaniu od nich CV.
Wręcz przeciwnie, aby obsadzić wakaty na stanowiskach analityka systemowego i architekta oprogramowania, ogromne znaczenie ma proces szkoleń w firmie. Specjaliści ci muszą być kształceni w aktualnym środowisku produkcyjnym i specyfice konkretnej organizacji. Analitycy systemowi rozwijają się z analityków biznesowych, autorów tekstów technicznych i inżynierów wsparcia technicznego. Architekci oprogramowania – od projektantów (System Designer) i programistów (Software Developer) w miarę zdobywania doświadczenia i poszerzania horyzontów. Ta okoliczność pozwala specjaliście HR na efektywne wykorzystanie wewnętrznych zasobów firmy.
Przecięcie, integracja i ewolucja ról produkcyjnych
Jest jeszcze jedna trudna kwestia z punktu widzenia wdrożenia w procesie produkcyjnym – ustalenie wyraźnych granic pomiędzy rolami. Na pierwszy rzut oka może się wydawać, że wszystko jest oczywiste: wdrożenie zostało zakończone, podpisano dokumenty dotyczące komercyjnego uruchomienia oprogramowania i wszystko zostało przekazane wsparciu technicznemu. Zgadza się, jednak często zdarzają się sytuacje, gdy klient z przyzwyczajenia, będąc w bliskim kontakcie z analitykiem i postrzegając go jako „magiczną różdżkę”, nadal aktywnie się z nim komunikuje, mimo że system został już wdrożony i trwa etap wsparcia formalnego. Jednak z punktu widzenia klienta, kto lepiej i szybciej niż analityk, który wspólnie z nim ustalał zadanie, odpowie na pytania dotyczące pracy z systemem. I tu pojawia się pytanie o częściowe zdublowanie ról inżyniera wsparcia technicznego i analityka. Z biegiem czasu wszystko się poprawia, klient przyzwyczaja się do komunikacji z obsługą techniczną, jednak już na samym początku korzystania z oprogramowania takie „przejście wewnętrzne” nie zawsze może odbyć się bez stresu po obu stronach.
Przecięcie ról analityka i inżyniera wsparcia technicznego pojawia się również wtedy, gdy przepływ wymagań programistycznych następuje w ramach etapu wsparcia. Wracając do cyklu życia oprogramowania, widzimy rozbieżność pomiędzy rzeczywistymi warunkami produkcji a formalnym podejściem, że analizę wymagań i formułowanie problemów może przeprowadzić wyłącznie analityk. Specjalista ds. HR musi oczywiście rozumieć idealny obraz ról w cyklu życia oprogramowania; mają one jasne granice. Ale jednocześnie zdecydowanie należy pamiętać, że przecięcie jest możliwe. Oceniając wiedzę i umiejętności kandydata, należy zwrócić uwagę na obecność powiązanego doświadczenia, czyli przy poszukiwaniu inżynierów wsparcia technicznego mogą być brani pod uwagę kandydaci z doświadczeniem analityka i odwrotnie.
Oprócz nakładania się ról produkcyjnych często dochodzi do konsolidacji. Na przykład analityk biznesowy i autor tekstów technicznych mogą istnieć jako jedna osoba. Obecność architekta oprogramowania (Software Architect) jest obowiązkowa w przypadku dużych inwestycji przemysłowych, podczas gdy bardzo małe projekty mogą obejść się bez tej roli: tam funkcje architekta pełnią programiści (Software Developer).
Zmiany w okresach historycznych w podejściu do rozwoju i technologii nieuchronnie prowadzą do tego, że ewoluuje także cykl życia oprogramowania. Globalnie oczywiście jego główne etapy pozostają niezmienione, ale stają się coraz bardziej szczegółowe. Na przykład wraz z przejściem na rozwiązania internetowe i wzrostem możliwości zdalnej konfiguracji pojawiła się rola specjalisty ds. konfiguracji oprogramowania. Na wczesnym etapie historycznym byli to realizatorzy, czyli inżynierowie, którzy większość czasu pracy spędzali na stanowiskach pracy klientów. Zwiększona objętość i złożoność oprogramowania doprowadziła do pojawienia się roli architekta oprogramowania. Wymagania dotyczące przyspieszania wydawania wersji i poprawy jakości oprogramowania przyczyniły się do rozwoju testów automatycznych i pojawienia się nowej roli - inżyniera QA (inżyniera zapewnienia jakości) itp. Ewolucja ról na wszystkich etapach procesu produkcyjnego jest w istotny sposób powiązana z rozwojem metod, technologii i narzędzi.
Do tej pory przyjrzeliśmy się kilku interesującym punktom dotyczącym podziału ról produkcyjnych w firmie produkującej oprogramowanie w kontekście cyklu życia oprogramowania. Oczywiście jest to spojrzenie poufne, specyficzne dla każdej firmy. Dla nas wszystkich, jako uczestników rynku pracy branży IT i osób odpowiedzialnych za promowanie marki pracodawcy, spojrzenie z zewnątrz będzie szczególnie istotne. I tutaj pojawia się duży problem nie tylko w odnalezieniu znaczenia, ale także w przekazaniu tej informacji docelowemu odbiorcy.
Co jest nie tak z „zoo” stanowisk IT?
Zamieszanie w głowach specjalistów HR, kierowników produkcji i różnorodność podejść prowadzą do bardzo dużej różnorodności, istnego „zoo” stanowisk IT. Doświadczenia rozmów kwalifikacyjnych i po prostu kontaktów zawodowych pokazują, że ludzie często nie mają jasnego zrozumienia znaczenia, jakie powinno wynikać z nazw stanowisk. Na przykład w naszej organizacji na stanowiskach zawierających termin „inżynier analityk” zakłada się, że jest to osoba wyznaczająca zadania. Okazuje się jednak, że nie wszędzie tak jest: są organizacje deweloperskie, w których inżynier analityk jest wdrożeniowcem. Zupełnie inne rozumienie, zgodzisz się?
Po pierwsze, „zoo” stanowisk IT niewątpliwie obniża efektywność rekrutacji. Każdy pracodawca, rozwijając i promując swoją markę, chce w zwięzłej formie przekazać wszystkie znaczenia, jakie istnieją w jego produkcji. A jeśli sam często nie potrafi jasno powiedzieć, kto jest kim, naturalnym jest, że rozsieje niepewność na otoczenie zewnętrzne.
Po drugie, „zoo” stanowisk IT stwarza ogromne problemy w szkoleniu i rozwoju kadr IT. Każda poważna firma informatyczna, której celem jest kształtowanie i rozwój zasobów ludzkich, a nie tylko „dojenie” stanowisk pracy, prędzej czy później staje przed koniecznością interakcji z instytucjami edukacyjnymi. Dla wysoko wykwalifikowanych kadr IT jest to segment uczelni, i to najlepszych, przynajmniej tych z rankingu TOP-100.
Problem integracji z uczelniami przy budowaniu ciągłego procesu szkolenia specjalistów IT to w przybliżeniu o połowę brak zrozumienia przez uczelnie, kto jest kim w firmie IT. Mają o tym bardzo powierzchowne pojęcie. Z reguły uczelnie mają kilka specjalności, które w nazwie mają słowo „informatyka”, a często zdarza się, że prowadząc kampanię rekrutacyjną, opierają się na tezie, że wszystkie specjalności dotyczą w istocie tego samego. A wygląda to tak, jakbyśmy opierali się na popularnym micie, że wszyscy specjaliści IT są programistami.
Doświadczenia naszej ścisłej współpracy z uczelniami pokazują, że specjalność „Informatyka Stosowana (według branży)” dostarcza nam kadr do działów metodologii i wsparcia technicznego, ale nie do rozwoju. Natomiast „Podstawy informatyki”, „Inżynieria oprogramowania” przygotowują doskonały zasób ludzki dla programistów. Aby początkowo nie kierować wnioskodawcy na niewłaściwą dla niego ścieżkę, należy „rozproszyć mgłę” otaczającą produkcję IT.
Czy da się wszystko sprowadzić do wspólnego mianownika?
Czy można ujednolicić role produkcyjne i dojść do ich wspólnego zrozumienia wewnątrz i na zewnątrz firmy?
Oczywiście jest to możliwe i konieczne, ponieważ zgromadzone zbiorowe doświadczenie wszystkich przedsiębiorstw deweloperskich wskazuje na obecność wspólnych, ujednolicających koncepcji organizacji procesu produkcyjnego. Jest to konsekwencja faktu, że nadal istnieje jednoznacznie interpretowana koncepcja cyklu życia oprogramowania, a nowo pojawiające się role produkcyjne (DataScientist, QA-Engineer, Machine Learning Engineer itp.) są konsekwencją doprecyzowania i rozwoju cykl życia oprogramowania jako taki, występujący wraz z doskonaleniem technologii i narzędzi, a także rozwojem i poszerzaniem zadań biznesowych.
Jednocześnie trudno jest ujednolicić role produkcyjne, gdyż IT to jeden z najmłodszych i najszybciej rozwijających się sektorów gospodarki. W pewnym sensie jest to chaos, z którego wyłonił się wszechświat. Jasna struktura organizacyjna jest tu niemożliwa i niewłaściwa, ponieważ IT to dziedzina intelektualna, ale bardzo twórcza. Z jednej strony informatyk to „fizyk” – intelektualista z rozwiniętym myśleniem algorytmicznym i matematycznym, z drugiej – „liryk” – twórca, nosiciel i propagator idei. On, podobnie jak artysta, nie ma jasnego planu malarskiego, nie może rozłożyć obrazu na części, bo te przestaną istnieć. Jest władcą procesów informacyjnych, które same w sobie są abstrakcyjne, nieuchwytne, trudne do zmierzenia, ale szybkie.
Sposoby budowania efektywnej pracy personelu w produkcji IT
Co zatem powinien wiedzieć specjalista HR, aby budować efektywną pracę HR w kontekście różnorodności ról produkcyjnych IT.
Po pierwsze, każdy specjalista HR w firmie IT musi mieć pojęcie o sytuacji typowej konkretnie dla jego przedsiębiorstwa: kto co robi, kto jak się nazywa i co najważniejsze, jakie jest znaczenie tych ról w warunkach konkretną produkcję.
Po drugie, specjalista HR musi elastycznie rozumieć role produkcyjne. Oznacza to, że początkowo tworzy na ich temat idealne zrozumienie, co pozwala mu samemu wszystko zrozumieć. Musi zatem istnieć prawdziwy obraz produkcji: gdzie i w jaki sposób role się krzyżują i łączą, jakie jest postrzeganie tych ról wśród kierowników produkcji. Trudność specjalisty ds. personalnych polega na łączeniu w umyśle sytuacji rzeczywistych i idealnych, nie na próbie na siłę przebudowywania procesów tak, aby odpowiadały ich idealnemu zrozumieniu, ale na pomaganiu produkcji w zaspokajaniu zapotrzebowania na zasoby.
Po trzecie, zdecydowanie powinieneś mieć pojęcie o możliwych trajektoriach rozwoju poszczególnych specjalistów: w jakich przypadkach selekcja zewnętrzna może być skuteczna, a kiedy lepiej rozwijać pracownika w swoim zespole, zapewniając mu możliwości rozwoju, jakie cechy kandydatów pozwoli im rozwijać się w określonym kierunku, których cech nie da się pogodzić w jednej osobie, co jest początkowo istotne przy wyborze ścieżki rozwoju.
Po czwarte, wróćmy do tezy, że IT to dziedzina wysoko wykwalifikowanej kadry, gdzie wczesna integracja z uniwersyteckim środowiskiem edukacyjnym jest nieunikniona dla efektywniejszej pracy personelu. W tej sytuacji każdy specjalista HR musi rozwinąć nie tylko umiejętności poszukiwań bezpośrednich, pracy z ankietami i wywiadami, ale także zadbać o poruszanie się w środowisku uniwersyteckiego szkolenia specjalistów: jakie uczelnie przygotowują kadry dla firmy, jakie specjalizacje w ramach konkretnych uczelni pokrywają potrzeby kadrowe i co. Ważne jest, kto za tym stoi, kto zarządza i szkoli specjalistów na uczelniach.
Jeśli więc celowo obalimy mit, że wszyscy informatycy są programistami, to należy podjąć szereg kroków w tym kierunku i zwrócić szczególną uwagę na nasze uczelnie, na których kładzione są podwaliny pod postrzeganie przyszłego zawodu. Inaczej mówiąc, potrzebujemy ciągłej interakcji ze środowiskiem edukacyjnym, na przykład wykorzystania nowoczesnego formatu współpracy w centrach coworkingowych, „punktów wrzenia” i uczestnictwa w intensywnych zajęciach edukacyjnych. Pomoże to obalić błędne przekonania na temat przedsiębiorstwa IT, zwiększyć efektywność pracy personelu i stworzyć warunki do wspólnych działań w zakresie szkolenia różnych specjalistów z naszej branży.
Wyrażam wdzięczność kolegom, którzy brali udział w przygotowaniu i wspieraniu aktualności tego artykułu: Walentinie Wierszyninie i Jurijowi Krupinowi.
Źródło: www.habr.com