Nie można uciec od zmian, ale można się na nie przygotować. Większość pracodawców na rynku oferuje możliwość rozwoju – awanse pionowe, poziome i zmiany zakresu obowiązków
Czy duża firma to zawsze szansa na zdobycie nowych umiejętności i kompetencji?
Opowiem historię mojego zatrudnienia w Comarchu, żeby udowodnić, że dojrzała, rozwinięta pod względem procesowym i duża firma, może sprzyjać rozwojowi pracownika, ale też pokazać, że wielkość organizacji nie jest warunkiem wystarczającym do stworzenia dynamicznego środowiska pracy wspierającego zmiany.
Swoją przygodę z IT rozpocząłem około 10 lat temu jako tester oprogramowania w sektorze firmy zajmującym się projektami telekomunikacyjnymi. To była moja pierwsza praca w biurze. Wcześniej pracowałem zdalnie jako web developer w niewielkiej agencji reklamowej.
Pierwsze dni pracy pamiętam dość dobrze, poznawałem oprogramowanie typu OSS (Operations Support System), używane przez operatorów telekomunikacyjnych na całym świecie. Nie czułem wtedy, aby studiowanie telekomunikacji holistycznie przygotowało mnie do pracy w IT Software House, produkującym oprogramowanie dla największych telekomów na świecie. Część technicznych pojęć była zrozumiała, ale kompletnie nie czułem biznesu. Nie rozumiałem, w jakim celu ktoś kupuje takie produkty i jak używa ich w pracy operacyjnej po zakończeniu wdrożenia.
Pierwsza poważna praca rządzi się swoimi prawami
Raz, że trzeba poznać meandry dziedziny, w której przychodzi nam się poruszać, a dwa, że człowiek często musi przyswoić choćby podstawy prawa pracy - to, ile przysługuje Ci urlopu, jak o niego poprosić, w którym progu podatkowym się znajdujesz itd.
Swoją drogą, rozmawiałem ostatnio z doświadczonym kierownikiem projektu IT, który w swojej pierwszej pracy podczas przerwy między świętami nie przyszedł do pracy i nie wziął urlopu. „Bo na studiach było wolne, myślałem, że w pracy jest tak samo”.
Praca w dziale Quality Assurance to świetny sposób na poznanie portfolio produktów oferowanych przez firmę. Niektórzy mówią, że świetnie przygotowuje do pracy w dziale wsparcia lub wdrożeń. Dzisiaj wiem, że koszt naprawy bugów jest najniższy, jeśli wykryjemy go na wczesnym etapie produkcji oprogramowania, a sporo wyższy podczas zgłoszenia otrzymanego od klienta, który używa już wdrożonego systemu.
I nawet niespecjalnie trudno jest policzyć, ile organizacja może oszczędzić, czyli zarobić, na dobrej organizacji działów zapewniających jakość. Inna sprawa, że koszt zapewnienia jakości nie może być większy od konsekwencji jej niedotrzymania.
Po niecałym roku pracy jako tester, dostałem propozycję objęcia nowej roli System Engineer/Support Team Managera. Nie wydawało mi się to podejrzane ani dziwne, ponieważ działy wsparcia, QA, dokumentacji oraz szkoleń, były zarządzane przez jednego kierownika. „Pewnie teraz jest potrzeba zaangażowania tam większej ilości osób” – pomyślałem.
To była świetna pozycja! Z jednej strony bardziej wyeksponowana na klienta, z drugiej również mocno techniczna. W dziale wsparcia klient kontaktuje się z Tobą wtedy, jak coś w systemie nie działa i operacje biznesowe są utrudnione lub zablokowane. Jesteś w stanie nauczyć się obsługi „trudnego” klienta i jeszcze lepiej poznać sektorowe produkty.
Na szkoleniu z ITIL-a dowiedziałem się, że osoby z działów Support są naturalnymi kandydatami na kierowników projektów, przez ten kontakt z trudnym klientem właśnie.
Artykuł stanowi fragment publiakcji "Czy wielkość organizacji pomaga w odnalezieniu swojej ścieżki?" Pawła Cula, Head Of Project Management Office w Comarch dla portalu Bulldogjob.