Kto jest kim w IT?

W obecnym etapie rozwoju przemysłowego oprogramowania można zaobserwować różnorodność ról produkcyjnych. Ich liczba rośnie, klasyfikacja staje się coraz bardziej skomplikowana z każdym rokiem, a co za tym idzie, proces rekrutacji specjalistów i zarządzania potencjałem kadrowym również staje się bardziej złożony. Technologie informacyjne (IT) to obszar wysoce wykwalifikowanych zasobów ludzkich i niedoboru kadr. Proces rozwijania talentów oraz potrzeba systematycznej pracy z potencjałem kadrowym są tu często znacznie efektywniejsze niż bezpośrednia rekrutacja za pomocą zasobów internetowych.

Artykuł porusza kwestie istotne dla specjalistów zajmujących się pracą z personelem w firmach IT: związki przyczynowo-skutkowe w ewolucji ról produkcyjnych, konsekwencje błędnej interpretacji treści ról dla pracy kadrowej jako całości oraz możliwe opcje zwiększenia efektywności rekrutacji specjalistów.

Produkcja IT dla niedoinformowanych

Kto jest kim w IT – to temat dyskusji na różnych forach. Istnieje on od początku całej branży IT, czyli od momentu pojawienia się na rynku konsumenckim pierwszych firm deweloperskich oprogramowania na początku lat 90. ubiegłego wieku. I przez ten czas brakowało jednolitego spojrzenia na tę kwestię, co stwarza trudności i obniża efektywność pracy kadrowej. Spróbujmy to rozwiązać.

Temat ról produkcyjnych w branży IT stał się dla mnie istotny i interesujący od momentu, gdy zacząłem pracować w firmie IT. Spędziłem dużo czasu i energii, aby zrozumieć proces produkcji. Te nakłady przekroczyły moje oczekiwania oraz koszty adaptacji do procesów w innych dziedzinach: edukacji, produkcji materialnej, małym biznesie. Miałem świadomość, że procesy są skomplikowane i nietypowe, ponieważ ogólnie człowiek lepiej przystosowuje się do świata materialnego niż do wirtualnego. Jednak miałem intuicyjny opór: wydawało się, że coś jest nie tak, tak nie powinno być. Proces adaptacji zajął mi prawdopodobnie rok, co, w moim przekonaniu, jest ogromnym czasem. W rezultacie wyraźnie zrozumiałem kluczowe role w produkcji IT.

Obecnie nadal pracuję nad tym tematem, ale na innym poziomie. Jako kierownik centrum rozwoju w firmy IT często muszę komunikować się ze studentami, wykładowcami uczelni, przyszłymi studentami, uczniami oraz innymi, którzy chcą wziąć udział w tworzeniu produktu IT w celu promocji marki pracodawcy na rynku pracy nowego terytorium (g. Jarosław). Ta komunikacja bywa trudna z powodu niskiej informacji moich rozmówców na temat organizacji procesu tworzenia oprogramowania (PO), co skutkuje brakiem zrozumienia tematu rozmowy. Po 5-10 minutach dialogu przestajesz otrzymywać feedback i zaczynasz czuć się jak obcokrajowiec, którego mowa wymaga tłumaczenia. Zazwyczaj wśród rozmówców znajduje się ktoś, kto podsumowuje rozmowę i przytacza ludowy mit z lat 90-tych: „I tak wszyscy informatycy to programiści”. Źródła powstania mitu są następujące:

• Branża IT dynamicznie się rozwija, w tych warunkach wszystkie fundamenty i zasady są w fazie formowania;
• w warunkach niepewności trudno istnieć, dlatego człowiek stara się ułatwić sobie zrozumienie nieznanego, tworząc mity;
• człowiek jest bardziej przyzwyczajony do postrzegania świata materialnego niż wirtualnego, przez co trudno mu definiować pojęcia wykraczające poza jego postrzeganie.

Próby walki z tym mitem czasami przypominają bój z wiatrakami, ponieważ istnieje kilka aspektów problemu, które wymagają opracowania. Specjalista ds. kadr musi, po pierwsze, mieć wyraźny obraz ról produkcyjnych w firmie IT w idealnym i rzeczywistym ujęciu, po drugie, rozumieć, jak i kiedy może być najskuteczniej wykorzystany wewnętrzny zasób firmy, po trzecie, jakie rzeczywiste metody pomogą zwiększyć wiedzę uczestników rynku pracy i przyczynią się do rozwoju marki pracodawcy. Przyjrzyjmy się tym aspektom szczegółowo.

Cykl życia oprogramowania jako podstawa ról produkcyjnych

Nie jest tajemnicą, że wszystkie role produkcyjne w każdej firmie IT opierają się na cyklu życia oprogramowania. Dlatego, aby konceptualnie porozumieć się w kwestii jedności postrzegania tego tematu w całej branży IT, należy oprzeć się na cyklu życia oprogramowania jako na akceptowanej i jednoznacznie rozumianej przez wszystkich podstawie znaczeniowej. Dyskusja o konkretnych wariantach realizacji kwestii ról produkcyjnych leży w płaszczyźnie naszego twórczego podejścia do cyklu życia oprogramowania.

Zatem przyjrzyjmy się etapie, który obejmuje cykl życia oprogramowania, na przykładzie metodyki RUP. Są to wystarczająco ukształtowane ogniwa w zakresie 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) na konsultacjach z użytkownikami i poprawkach oprogramowania na podstawie „zachcianek” użytkowników.

Jeśli dokonamy historycznego przeglądu końca ubiegłego wieku (jak wiadomo, był to okres „wyspowej automatyzacji”), można zauważyć, że cały proces tworzenia oprogramowania był zajęty przez programistę-dewelopera. To tutaj są korzenie mitu, że każdy informatyk to programista.

Wraz z komplikacją procesów produkcyjnych, pojawieniem się zintegrowanych platform i przejściem do kompleksowej automatyzacji obszarów tematycznych, z reinżynierią procesów biznesowych staje się nieuchronne pojawienie się specjalistycznych ról związanych z etapami cyklu życia. Tak oto powstają analitycy, testerzy i specjaliści wsparcia technicznego.

Różnorodność stanowisk na przykładzie roli analityka

Analityk (znany również jako inżynier analityk, autor wymagań, metodolog, analityk biznesowy, analityk systemowy itd.) pomaga „połączyć” biznesowe zadania z technologiami ich realizacji. Opis zadań dla programisty – tak można określić główną funkcję abstrakcyjnego analityka. Stanowi on ogniwo łączące między klientem a programistą w procesach formułowania wymagań, analizy i projektowania oprogramowania. W rzeczywistych warunkach produkcyjnych zakres funkcji analityka definiowany jest przez sposób organizacji produkcji, kwalifikacje specjalisty oraz specyfikę modelowanego obszaru tematycznego.

Część analityków znajduje się bliżej klienta. To analitycy biznesowi (Business Analyst). Doskonale rozumieją procesy biznesowe w danym obszarze tematycznym i sami są ekspertami w automatyzowanych procesach. Bardzo ważne jest, aby w firmie byli tacy specjaliści, szczególnie przy automatyzacji metodologicznie złożonych obszarów tematycznych. W szczególności dla nas, jako automatyzatorów budżetowego procesu państwa, jest niezbędne, aby wśród analityków byli eksperci w danym obszarze. To wysoko wykwalifikowani pracownicy z dobrą edukacją finansowo-ekonomiczną i doświadczeniem w instytucjach finansowych, najlepiej w roli głównych specjalistów. Niezwykle istotne jest doświadczenie, które nie ogranicza się do branży IT, ale dotyczy bezpośrednio obszaru tematycznego.

Inna część analityków jest bliżej programistów. To analitycy systemowi (System Analyst). Ich głównym zadaniem jest identyfikacja, systematyzacja i analiza wymagań klienta pod kątem ich spełnienia, przygotowanie specyfikacji technicznych oraz opisywanie zadań. Rozumieją nie tylko procesy biznesowe, ale także technologie informacyjne, dobrze znają możliwości dostarczanego klientowi oprogramowania, posiadają umiejętności projektowania i w związku z tym wiedzą, jak najlepiej przekazać interesy klienta programiście. Ci pracownicy niewątpliwie mają wykształcenie w dziedzinie ICT i inżynieryjno-techniczny sposób myślenia, a doświadczenie w IT byłoby dużym plusem przy ich doborze. Obecność umiejętności projektowania z wykorzystaniem nowoczesnych narzędzi będzie zdecydowanym atutem.

Inny rodzaj analityków to pisarze techniczni (Technical Writer). Zajmują się dokumentowaniem w ramach procesów rozwoju oprogramowania, przygotowują instrukcje dla użytkowników i administratorów, instrukcje technologiczne, materiały szkoleniowe wideo itp. Ich głównym zadaniem jest przekazanie użytkownikom i innym zainteresowanym osobom informacji o działaniu programu, opisanie technicznych aspektów w sposób zwięzły i zrozumiały. Pisarze techniczni zazwyczaj doskonale opanowują język polski, mają wykształcenie techniczne i analityczne podejście do problemów. Dla takich specjalistów najważniejsze są umiejętności tworzenia zrozumiałych, poprawnych i szczegółowych tekstów technicznych zgodnie z normami oraz znajomość narzędzi dokumentacyjnych.

W ten sposób widzimy tę samą rolę (a przy okazji stanowisko w ramowym układzie zatrudnienia) – analityka, ale w różnych jego konkretnych zastosowaniach. Poszukiwanie specjalistów dla każdego z nich ma swoje specyfikacje. Ważne jest, aby wiedzieć, że te rodzaje analityków muszą posiadać często niezgodne umiejętności i wiedzę. Jeden to humanista, skłonny do analizy dużych wolumenów dokumentów tekstowych, z rozwiniętą mowę i umiejętnościami komunikacyjnymi, drugi to „technokrat” z inżynieryjnym sposobem myślenia i zainteresowaniami w dziedzinie IT.

Wziąć z zewnątrz czy wychować samodzielnie?

Dla dużego przedstawiciela branży IT skuteczność bezpośredniego pozyskiwania pracowników z zasobów internetowych maleje wraz ze wzrostem projektów. Dzieje się tak, między innymi, z następujących powodów: niemożność szybkiej adaptacji do skomplikowanych procesów wewnątrz firmy, tempo przyswajania specyficznych narzędzi jest niższe niż tempo rozwoju projektu. Dlatego specjalista HR powinien wiedzieć nie tylko, kogo szukać na zewnątrz, ale także jak zaangażować wewnętrzne zasoby firmy, z kogo i jak wychować specjalistę.

Dla analityków biznesowych niezwykle istotne jest posiadanie doświadczenia w rzeczywistych procesach w danej dziedzinie, dlatego ich pozyskiwanie z zewnątrz jest bardziej efektywne niż rozwijanie ich wewnętrznie w firmie. W związku z tym ważne jest, aby specjalista HR znał listę organizacji, które mogą być źródłem tego zasobu kadrowego, i podczas rekrutacji skupił się na poszukiwaniu CV z tych źródeł.

Z kolei w przypadku zamknięcia takich wakatów, jak analityk systemowy czy architekt oprogramowania, proces szkolenia kadry wewnątrz firmy ma ogromne znaczenie. Ci specjaliści muszą powstać w warunkach działającego środowiska produkcyjnego oraz specyfiki danej organizacji. Analitycy systemowi rozwijają się z analityków biznesowych, pisarzy technicznych oraz inżynierów wsparcia technicznego. Architekci oprogramowania powstają z projektantów systemów i programistów oprogramowania w miarę zdobywania doświadczenia i poszerzania horyzontów. Ta okoliczność pozwala specjalistom HR efektywnie wykorzystywać wewnętrzne zasoby firmy.

Przecięcie, połączenie i ewolucja ról produkcyjnych

Jest jeszcze jeden trudny do zrealizowania w procesie produkcyjnym temat – ustalenie wyraźnych granic pomiędzy rolami. Na pierwszy rzut oka może się wydawać, że wszystko jest oczywiste: zakończyło się wdrożenie, podpisano dokumenty dotyczące wprowadzenia oprogramowania do eksploatacji i przekazano wszystko do wsparcia technicznego. To prawda, jednak często pojawiają się sytuacje, gdy klient, przyzwyczajony do bliskiego kontaktu z analitykiem i widząc w nim „różdżkę”, nadal aktywnie z nim rozmawia, mimo że system został już wdrożony, a formalnie trwa etap wsparcia. Jednak z perspektywy klienta, kto lepiej i szybciej niż analityk, który razem z nim stawiał zadanie, odpowie na pytania dotyczące pracy z systemem? I tutaj pojawia się kwestia częściowego dublowania ról inżyniera wsparcia technicznego i analityka. Z czasem wszystko się unormowuje, klient przyzwyczaja się do kontaktów z obsługą techniczną, ale na początku eksploatacji oprogramowania taki „wewnętrzny transfer” nie zawsze udaje się zrealizować bez napięć po obu stronach.

Przecięcie ról analityka i inżyniera wsparcia technicznego występuje także wtedy, gdy przepływ wymagań dotyczących rozwoju trwa w ramach etapu wsparcia. Wracając do cyklu życia oprogramowania, widzimy niezgodność między rzeczywistymi warunkami produkcyjnymi a formalnymi ustaleniami, że analiza wymagań i postawienie zadania mogą być wykonane wyłącznie przez analityka. Specjalista ds. kadrowych zdecydowanie musi rozumieć idealny obraz ról w ramach cyklu życia oprogramowania, które mają wyraźne granice. Ale jednocześnie konieczne jest, aby mieć na uwadze, że może nastąpić przecięcie. Przy ocenie wiedzy i umiejętności kandydata należy zwrócić uwagę na posiadanie pokrewnego doświadczenia, to znaczy przy poszukiwaniu inżynierów wsparcia technicznego mieszkańcy mogą być rozważani kandydaci z doświadczeniem analityka i odwrotnie.

Oprócz przecięcia, często obserwuje się łączenie ról produkcyjnych. Na przykład analityk biznesowy i pisarz techniczny mogą istnieć w jednej osobie. Obecność architekta oprogramowania (Software Architect) jest niezbędna w dużym przemyśle, podczas gdy całkowicie małe projekty mogą obejść się bez tej roli: tam funkcje architekta pełnią programiści (Software Developer).

Zmiana okresów historycznych w podejściu i technologiach rozwoju nieuchronnie prowadzi do ewolucji cyklu życia oprogramowania. Globalnie, rzecz jasna, jego główne etapy pozostają niezmienne, jednak następuje ich szczegółowe rozróżnienie. 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 wdrożeni, czyli inżynierowie, którzy większość swojego czasu pracy spędzali w miejscach pracy klientów. Wzrost objętości i złożoności oprogramowania doprowadził do powstania roli architekta oprogramowania (Software Architect). Wymagania dotyczące przyspieszenia wydania wersji i zwiększenia jakości oprogramowania sprzyjały rozwojowi automatyzowanego testowania i pojawieniu się nowej roli – inżyniera QA (Quality Assurance Engineer) itd. Ewolucja ról na wszystkich etapach organizacji procesu produkcyjnego jest w znacznym stopniu związana z rozwojem metod, technologii i narzędzi.

Przeanalizowaliśmy kilka interesujących aspektów związanych z podziałem ról w firmach zajmujących się tworzeniem oprogramowania w kontekście cyklu życia oprogramowania. Oczywiście, jest to spojrzenie z wnętrza, które jest specyficzne dla każdej firmy. Dla nas wszystkich, jako uczestników rynku pracy w branży IT i osób odpowiedzialnych za promowanie marki pracodawcy, szczególnie ważne będzie również spojrzenie z zewnątrz. A tutaj istnieje duży problem nie tylko w wyszukaniu sensów, ale także w dotarciu z tą informacją do docelowej grupy odbiorców.

Czym jest zły „zoo” stanowisk IT?

Zamieszanie w świadomości specjalistów HR, organizatorów produkcji i różnorodność podejść prowadzi do bardzo szerokiego zróżnicowania, wręcz „zoo” stanowisk IT. Doświadczenie rozmów kwalifikacyjnych i po prostu kontaktów zawodowych pokazuje, że często ludzie nie mają jednoznacznego zrozumienia semantycznego obciążenia, które powinno wynikać z nazw stanowisk. Na przykład w naszej organizacji stanowiska, które zawierają pojęcie „inżynier analityk”, zakładają, że jest to osoba zajmująca się definiowaniem zadań. Jednak okazuje się, że nie wszędzie tak jest: są organizacje-deweloperzy, gdzie inżynier analityk to osoba wdrażająca. To zupełnie inne zrozumienie, nieprawdaż?

Po pierwsze, „zoo” stanowisk IT z pewnością obniża efektywność rekrutacji. Każdy pracodawca rozwijający i promujący swoją markę chce w zwięzły sposób zakomunikować wszystkie znaczenia, które istnieją w jego produkcji. A jeśli sam często nie jest w stanie jasno powiedzieć, kto jest kim, to naturalnie będzie transmitować na zewnątrz niepewność.

Po drugie, „zoo” stanowisk IT stwarza ogromne problemy przy kształceniu i rozwoju kadr IT. Każda poważna firma IT, która ma na celu formowanie i rozwijanie potencjału kadrowego, a nie tylko „dojenie” stron z ofertami pracy, prędzej czy później napotyka potrzebę współpracy z instytucjami edukacyjnymi. W przypadku wysoko wykwalifikowanych pracowników IT to segment uczelni, najlepiej tych, które znajdują się w rankingu TOP-100.

Problem z integracją z uczelniami w budowaniu ciągłego procesu kształcenia specjalistów IT polega w dużej mierze na braku zrozumienia przez uczelnie, kto jest kim w firmie IT. Mają na ten temat bardzo powierzchowną wiedzę. Zazwyczaj uczelnie oferują kilka specjalności z słowem 'informatyka' w nazwie, a często w trakcie przeprowadzania rekrutacji opierają się na tezie, że wszystkie specjalności w zasadzie dotyczą tego samego. To wygląda tak, jakby bazować na popularnym micie, że wszyscy informatycy to programiści.

Doświadczenie naszej bliskiej współpracy z uczelniami pokazuje, że specjalność 'Informatyka stosowana (w branżach)' dostarcza nam kadry do działów metodologii i wsparcia technicznego, ale nie do rozwoju. Z kolei 'Informatyka fundamentalna', 'Inżynieria oprogramowania' przygotowują doskonały zasób kadrowy dla programistów. Aby nie skierować studenta na niewłaściwą ścieżkę, należy 'rozproszyć mgłę', która otacza produkcję IT.

Czy można wszystko sprowadzić do wspólnego mianownika?

Czy można zunifikować role produkcyjne i dojść do jednolitego zrozumienia ich wewnątrz i na zewnątrz firmy?

Oczywiście, że można i należy, ponieważ zgromadzone doświadczenie zbiorowe wszystkich firm deweloperskich pokazuje istnienie wspólnych, łączących koncepcji organizacji procesu produkcji. To jest konsekwencją tego, że istnieje jednoznacznie interpretowane przez wszystkich pojęcie cyklu życia oprogramowania, a nowe role produkcyjne (DataScientist, QA-Engineer, MachineLearning Engineer itd.) są wynikiem doprecyzowania i rozwoju cyklu życia oprogramowania jako takiego, co zachodzi wraz z doskonaleniem technologii i narzędzi oraz rozwojem i powiększaniem zadań biznesowych.

Jednocześnie trudne jest ujednolicenie ról w produkcji, ponieważ IT jest jedną z najmłodszych i najszybciej rozwijających się branż gospodarki. W pewnym sensie to chaos, z którego powstał wszechświat. Jasna struktura organizacyjna tutaj jest niemożliwa i nieodpowiednia, ponieważ IT to dziedzina intelektualna, ale bardzo twórcza. Z jednej strony specjalista IT to 'fizyk'-inteligent z rozwiniętym myśleniem algorytmicznym i matematycznym, z drugiej strony to 'poeta'-twórca, nosiciel i promotor idei. Tak jak artysta, nie ma jasnego planu pisania obrazu, nie może rozłożyć wizerunku na części, ponieważ ostatni przestanie istnieć. Jest władcą procesów informacyjnych, które same w sobie są abstrakcyjne, nieuchwytne, trudne do zmierzenia, ale szybkie.

Drogi do zbudowania efektywnej pracy kadrowej w produkcji IT

Cóż, co ważne powinien wiedzieć specjalista HR, aby zbudować efektywną pracę kadrową w warunkach różnorodności ról w produkcji IT.

Po pierwsze, każdy specjalista do spraw kadr w firmie IT musi mieć pojęcie o sytuacji, która jest charakterystyczna dla jego przedsiębiorstwa: kto i czym się zajmuje, kto i jak się nazywa, i przede wszystkim – jakie znaczenie wiąże się z tymi rolami w konkretnej produkcji.

Po drugie, specjalista HR powinien mieć elastyczne pojęcie o rolach produkcyjnych. To znaczy, na początku powinien mieć idealne zrozumienie tych ról, które pozwala mu samodzielnie się w tym rozeznać. Następnie powinna być koniecznie realna wizja produkcji: gdzie i w czym role się krzyżują, łączą, jakie postrzeganie tych ról mają kierownicy produkcji. Trudność dla specjalisty ds. kadr polega na tym, aby połączyć w swoim umyśle sytuację realną i idealną, nie próbować na siłę przekształcać procesów do idealnego ich zrozumienia, a raczej pomagać produkcji w zaspokajaniu potrzeb w zakresie zasobów.

Po trzecie, ważne jest, aby mieć pojęcie o możliwych trajektoriach rozwoju poszczególnych specjalistów: kiedy efektywny może być zewnętrzny dobór, a kiedy lepiej wykształcić pracownika we własnym zespole, dając mu możliwości rozwoju, jakie cechy kandydatów pozwolą im rozwijać się w danym kierunku, które z cech mogą być wykluczone w jednej osobie, co jest na początku ważne przy wyborze trajektorii rozwoju.

Po czwarte, wrócimy do tezy, że IT to obszar wysoko wykwalifikowanych kadr, gdzie dla skuteczniejszej pracy z personelem konieczna jest wczesna integracja ze środowiskiem edukacyjnym uczelni wyższych. W tej sytuacji każdy specjalista HR powinien rozwijać nie tylko umiejętności bezpośredniego poszukiwania, pracy z formularzami i przeprowadzania wywiadów, ale także koniecznie orientować się w środowisku kształcenia specjalistów: które uczelnie przygotowują kadrę dla firmy, jakie specjalności w konkretnych uczelniach zaspokajają potrzeby kadrowe, a co ważne, kto za tym stoi, kto kieruje i realizuje przygotowanie specjalistów na uczelniach.

W ten sposób, aby celowo obalić mit, że wszyscy specjaliści IT to programiści, należy wykonać szereg kroków w tym kierunku i zwrócić szczególną uwagę na nasze uczelnie, gdzie kładzione są podstawy postrzegania przyszłej profesji. Innymi słowy, potrzebna jest stała interakcja z środowiskiem edukacyjnym, na przykład przy użyciu nowoczesnego formatu wspólnej pracy w centrach coworkingowych, 'punktach kipienia', uczestnictwie w intensywach edukacyjnych. To pozwoli zburzyć błędne wyobrażenia o przedsiębiorstwie IT, zwiększy efektywność pracy z personnel i stworzy warunki do wspólnej działalności w przygotowywaniu różnych specjalistów w naszej branży.

Chciałbym wyrazić wdzięczność kolegom, którzy wzięli udział w przygotowaniu i utrzymaniu aktualności tego artykułu: Walentynie Werszinie i Jurijowi Krupinowi.

Źródło: habr.com