Wgryźć się w projekt – czyli o rozwoju kompetencji w IT

Wgryźć się w projekt – czyli o rozwoju kompetencji w IT nf.pl

Za rozwój umiejętności oraz pogłębianie wiedzy, jesteśmy odpowiedzialni my sami. Firma może jedynie w tym pomóc. Kolejny projekt, kolejne nowe technologie, kolejna firma realizująca kontrakt na dostarczenie systemu informatycznego lub świadcząca usługi outsouringowe. Można śmiało napisać, projekt projektowi nie jest równy, chociażby ze względu na specyfikę i bariery wejścia nowej osoby do zespołu. Jednym z wymiarów wydajnej pracy w IT są kompetencje, czyli wszędzie szumnie wygłaszane praktyczne umiejętności kandydatów. Czym są zatem kompetencje? Kompetencja to nie tylko umiejętności stricte praktyczne. Kompetencje programisty to przede wszystkim jego osobowość, postawa czy też motywacja do pracy, która w skomplikowanej teraźniejszości jest najtrudniejsza do podtrzymania. Kompetencja to również nabyta wiedza. Niekiedy padają stwierdzenia, że teoria nie jest tak ważna jak umiejętności praktyczne. Tylko z czego miałyby wykształcić się te tak obecnie pożądane umiejętności praktyczne? Oczywistym jest, że najpierw przyswaja się teorię, pozyskuje się wiedzę, a następnie staramy się zastosować wiedzę w praktyce. Błędnym jest ogłoszeniem kogoś typowym teoretykiem, jeśli nabytą wiedzę osoba ta stosuje w praktyce. Kolej na umiejętności. Każdy z nas posiada wiele cennych umiejętności. Jedni potrafią naprawić urządzenia sanitarne, pomalować mieszkanie, inni potrafią biegle posługiwać się kilkoma językami programowania, projektować systemy lub tworzyć harmonogramy projektów. Bez wątpienia te umiejętności są bardzo przydatne. Postęp cywilizacyjny stale przyspiesza, powstają nowe technologie, programy oraz metodyki realizacji projektów. To co jest bezdyskusyjnym sednem wartości specjalisty to umiejętności „wysokopoziomowe” takie jak umiejętności analitycznego myślenia – kojarzenia faktów, umiejętności planowania, opracowywania strategii działania oraz umiejętności osobiste np. asertywność. Elementy te mogą stać się kluczowymi dla organizacji. Nowe osoby chcące współpracować z zespołem powinni posiadać kompetencje, które są obligatoryjne dla wszystkich pracowników oraz wynikają one z misji, wartości i kultury organizacji. Jeśli szkolenia są tylko nagrodą i narzędziem motywacji ... W branży IT obok wiedzy i umiejętności typowo technicznych, w zależności od specyfiki projektu niezbędnym jest posiadanie „backgroundu” z innych dziedzin np. sektora ubezpieczeń, księgowości lub logistyki. Z praktyki wynika, że wielu z nowych project managerów, architektów lub programistów nabywa tą wiedzę jedynie poprzez ostatnio modny „learning by doing”. A gdzie podstawy? Codzienność pokazuje, że nie są one niezbędne, ponieważ celem jest poprawnie działający system. W wielu przypadkach przygotowanie do pracy kończy się w trakcie procesu rekrutacyjnego. Często panuje przekonanie, że testy weryfikujące szczegółową znajomość technologii i narzędzi pozwolą „złowić” odpowiedniego kandydata np. na stanowiska związane z rozwojem oprogramowania. Z pewnością jest to jakieś podejście. Ale co dalej? W zależności od specyfiki projektu, poziomu rozwoju procesów wewnętrznych firmy, klienta lub produktu, scenariuszy rozwoju dalszych wydarzeń jest wiele. Jedni dochodzą do wniosku, że zatrudnili eksperta, czyli osobę która w krótkim czasie po wypłynięciu na głęboką wodę będzie pływać jak mistrz olimpijski. Płacimy, wymagamy. Jest to z pewnością kolejne jakieś podejście. Inni stosują tanie zamienniki. Zwiększając rozwój dobrych stosunków międzyludzkich delegowany jest życzliwy opiekun nowego developera, który wyjawiając wiedzę plemienną, często też „za karę” tłumaczy i wprowadza nową koleżankę lub kolegę w meandry projektu. Modne przedsiębiorstwa IT, wyznające metodyki lekkie ang. agile, działających w sposób zwinny, wielokrotnie stosują programowanie w parach jako sposób na podciągnięcie nowicjuszy. Jest to z pewnością sensowne i tanie rozwiązanie na trudne czasy. Kolejni, którzy mają odpowiedni kapitał informacyjny, ludzki lub finansowy stawiają np. na szkolenia wewnętrzne. To w czasie kryzysu firmy będą w tym obszarze szukać oszczędności. Żeby wysiłek nie poszedł na marne, działy HR analizują luki kompetencyjne pracowników oraz potrzeby szkoleniowe. Podejść jest wiele. Wdraża się założenia „startujemy od zera”, niekiedy rozsyła się ankiety, czasami przeprowadza się wywiady z kierownikami lub uruchamia analizę behawioralną zespołu. Etap projektowania i przeprowadzenia szkolenia są już wypadkową poprzedniego kroku procesu. No tak, a co po szkoleniu? Czy efektem ma być jedynie stwierdzenie, że szkolenie się odbyło, trener wykonał zadanie – czyli wystąpił na scenie oraz wszyscy wskazani bądź z własnej woli brali w nim udział? Kwintesencją wszelkich wysiłków jest oczekiwany stan wiedzy i umiejętności pracowników podczas codziennej pracy w projekcie, czyli stan gdzie nabyty kapitał jest prawidłowo wykorzystywany praktycznie. Przekładając to na procesy rozwoju oprogramowania mowa jest o testowaniu wypracowanych efektów szkoleń. W przypadku szkoleń „twardych” np. z konkretnego języka programowania lub bibliotek efekty widać we wzroście wydajności pracy programistów. „Tickety schodzą” szybciej lub o zaplanowanym czasie. Metryki, jakość kodu źródłowego uległy znacznej poprawie. Tworzona jest użyteczna dokumentacja. Zmniejszyła się ilość zgłaszanych błędów przez klienta. W przypadku szkoleń „miękkich” skuteczność działań może być mierzona przez pryzmat realnych zmian w postawie i postępowaniu. Wielokrotnie efekty mierzone są subiektywnie, obserwując wyrywkowo zespół. Prosta obserwacja jest podatna na wiele zniekształceń, „podlewana” jest niekiedy sympatią lub antypatią do konkretnych osób. Nie sugerując się wrażeniami i emocjami można zastosować metody, które pozwolą w bardziej efektywnie sfinalizować zmianę i obiektywnie ocenić osiągnięcia. Jedną z nich jest zastosowanie modelu Kirkpatricka. Składa się ona z czterech etapów ewaluacji (rysunek), a mianowicie z oceny dokonanej przez uczestników szkolenia, oceny wyników nauczania i pozyskanej wiedzy, oceny korzyści biznesowych i inwestycji oraz oceny zachowań wdrożonych w pracę ang. behaviour in the workplace. Zachowanie obiektywizmu pomiaru jest nieodłącznie związane z narzędziami umożliwiającymi ocenę. Za najbardziej popularne uznać można postawianie konkretnych, związanych z tematyką szkolenia nowych zadań do realizacji lub wdrożenie kosztownej oceny 360. Model Kirkpatricka nie jest rozwiązaniem idealnym. Model Kirkpatricka pozwala w obiektywny sposób przyjrzeć się wypracowanym efektom wdrożonych szkoleń. Trudność stosowania tego rozwiązania wynika z dwóch powodów. Ludzie zachowują się zgodnie z tym, co uważają za stosowane. Ich zachowania w danych sytuacjach mogą być silniej uwarunkowane wpływem innych czynników i wydarzeń, niż związanych tylko szkoleniem. Po drugie, oczekiwane rezultaty mogą pojawić się bezpośrednio po szkoleniu, znacznie później lub mogą wcale się nie pojawić – co generuje wniosek, że cel szkolenia nie został osiągnięty. Jak wgryźć się w nowy projekt? Podobnie jak w procesie zarządzania zmianą, odpowiedź na to pytanie nie należy do łatwych. Z jednej strony zależy to od doświadczenia, nastawienia i determinacji nowej osoby w projekcie. Z drugiej strony duży wpływ ma wsparcie firmy lub zespołu. Osoby pozostawione same sobie niekiedy zniechęcają się zbyt szybko. Przejście do innego projektu nigdy nie gwarantuje diametralnej zmiany sytuacji w kwestii poznawania nowych, obszernych zagadnień. Początki bywają bolesne. Firmy czasami pozostają w przekonaniu słuszności minimalizacji ryzyka związanego z inwestycjami w kompetencje kadr, a ewentualnym swobodnym odejściem pracownika. Wydaje się że błędne koło się zamyka i nie ma wyjścia. Diagnozując, wspierając i dbając o stały rozwój zespołów, zaczynając już od początku, czyli od procesu rekrutacji można wydobyć potencjał, który z czasem stanie się trwałym i cennym kapitałem dla organizacji. Czego każdemu życzę.

Łukasz Lechert