Rekrutując programistę. – Zanim zaczniesz, cofnij się!

foto: photosteve101

foto: photosteve101

Na rynku trwa zażarta walka o informatyków, w tym o programistów. Firmy prześcigają się w ofertach i sposobach kuszenia utalentowanych kandydatów a zwyczajne zamieszczenie ogłoszenia przestało być skutecznym sposobem na pozyskanie dobrego pracownika. Rekrutacje stają się trudniejsze, bardziej złożone i wymagające. Procesy trwają średnio kilka tygodni, kosztują kilkaset do kilku tysięcy złotych (w zależności o zastosowanych narzędzi) i wymagają zaangażowania czasu i pracy przynajmniej jednej, a często kilku osób z zespołu. Jednocześnie, pomimo tak znacznego nakładu środków, wcale nie dają gwarancji sukcesu.

Dla sprostania rosnącej konkurencji na rynku pracy, koniecznością staje się staranne zaplanowanie działań oraz przemyślana i konsekwentna ich realizacja. Gdy pojawia się potrzeba zatrudnienia kolejnego pracownika, warto cofnąć się o krok by przyjrzeć się faktycznym potrzebom i możliwościom firmy.

„Dlaczego chcemy kogoś zatrudnić?”

Rekrutujemy, bo: odchodzi pracownik, wzrosło obłożenie pracą, potrzebne są nowe kwalifikacje w zespole bądź zaczynamy nowy projekt. Dokładna analiza przyczyn rekrutacji ma odpowiedzieć na pytanie: „Czy, kogo i jak mamy szukać?”. Jeśli wakat spowodowały zbyt ambitne zadania, potrzebujemy osoby o wyższych kompetencjach, którą dodatkowo wesprzemy szkoleniami. Zupełnie inaczej postąpimy, gdy odszedł pracownik sfrustrowany brakiem jakichkolwiek wyzwań zawodowych. Wówczas rozwiązaniem jest zatrudnienie osoby, która dopiero uczy się zawodu, wyprowadzenie „nudnych” zadań z firmy (outsourcing) bądź wyeliminowanie potrzeby wykonywania tych zadań (np. system informatyczny). A dodatkowych kwalifikacji zespołowi, równie skutecznie, co nowozatrudniony pracownik, mogą dostarczyć dobrze dobrane i przeprowadzone szkolenia.

„Czym się zajmie nowa osoba?”

Lista zadań stanowi ważny kamień milowym. Umieszczamy na niej wszystkie obowiązki wynikające z definicji stanowiska pracy, ale i te zadania, które powinny w firmie być robione a robione nie są, bądź są robione źle. Wszelkie ogólniki typu: „Tworzenie serwisów internetowych.” rozbijamy na bardziej szczegółowe działania, jak: „Analiza wymagań projektowych.”, „Projektowanie i wytwarzanie aplikacji zgonie ze specyfikacją.”, „Tworzenie dokumentacji technicznej.”, itp. Jednocześnie ustalamy, z kim nowa osoba będzie współpracować (w firmie i poza nią), komu podlegać, kim zarządzać. Finalnie uzyskujemy szeroki obraz faktycznych potrzeb firmy i bazę do wykreślenia profilu kompetencyjnego przyszłego pracownika.

„Czy ktoś inny może wykonać te zadania?”

Często samo spisanie listy zadań jest wystarczającym bodźcem dla znalezienia optymalnych sposobów ich realizacji. „Naliczanie i kontrolę czasu pracy” wykona system automatycznie odnotowujący logowania bądź wejścia pracowników do budynku. Wykupienie powierzchni serwerowej wraz z obsługą w zewnętrznym Data Center okaże się bardziej opłacalne i rozsądne niż zatrudnianie administratora baz danych i utrzymywanie własnego zaplecza serwerowego. „Wykonywaniem elementów graficznych” z przyjemnością zajmie się firma zewnętrzna bądź grafik freelancer. „Tworzenie dokumentacji technicznej” można powierzyć jednej osobie zamiast obciążać tym zadaniem wszystkich developerów. Odciążeni programiści skupią się na programowaniu i będą wstanie wykonać wszystkie nadmiarowe zadania, które chcieliśmy przydzielić nowozatrudnionej osobie. Pomysły i rozwiązania można mnożyć, ale wniosek pozostaje niezmiennie jeden: rekrutacja nowego pracownika nie jest jedynym sposobem zaspokojenia potrzeb firmy a alternatywy bywają tańsze i łatwiejsze w realizacji.

Odpowiedziawszy na pytania „Czy potrzebujemy kolejnego pracownika” oraz „Do jakich zadań jest ta osoba potrzebna?” możemy wykonać kolejny krok. Nadal pracując nad listą zadań, rozdzielamy ją na dwie podlisty: zadania krytyczne (konieczne do wykonania) i uzupełniające (również ważne, ale jeśli nie zostaną wykonane, to „firma się nie zawali”). Podążając za przykładem programisty, krytyczne jest „Wytwarzanie wydajnych aplikacji”, a pożądane „Tworzenie dokumentacji technicznej.”. Bazując na tych ustaleniach określamy oczekiwania wobec nowego pracownika, które również grupujemy na wymagane (pracownik musi to wiedzieć, umieć) i pożądane (dobrze by było, gdyby to wiedział, umiał). Odnosząc się do przykładu, by „Wytwarzać wydajne aplikacje” pracownik musi umieć „Programować w języku PHP (Java, C++, czy jakimkolwiek innym stosowanym w firmie)”, „Znać metodyki wytwarzania oprogramowania” i „Znać wzorce projektowe”, ale przydatną umiejętnością by było również „Projektowanie testów oprogramowania”. Dużym błędem jest zawyżanie oczekiwać wobec kandydatów. Osoba posiadająca wszystkie wymagane kompetencje jest dobrym kandydatem i powinna być zatrudniona nawet, jeśli brakuje jej czegoś, co mogłoby okazać się przydatne.

W tym miejscu zapewne wielu szefów zespołów się ze mną nie zgodzi, gdyż chcą pracować z osobami zdolnymi, ambitnymi, doświadczonymi, o wysoko rozwiniętych kompetencjach interpersonalnych. I nie sposób się z nimi nie zgodzić, co niniejszym czynię. Zawsze trzeba wypatrywać talentów i być niezwykle czujnym, gdy pojawia się możliwość pozyskania takiej osoby. Tyle, że talenty są trudne do znalezienia i jeszcze trudniejsze do zatrzymania w firmie. Przy planowanej rekrutacji zdecydowanie lepiej sprawdza się racjonalizm.  Takie podejście daje szansę na obsadzenie stanowiska i nienarażanie firmy na konsekwencje otwartego przez dłuższy czas wakatu oraz nadmiernych kosztów rekrutacji. Ustrzeże nas również przed koniecznością powtórzenia poszukiwań, gdy jakimś cudem uda nam się pozyskać i zatrudnić „do parzenia kawy” osobę potrafiącą „projektować statki kosmiczne”. W najlepszym wypadku szybko odejdzie ona z firmy, w najgorszym będziemy mieć w zespole wysoce zdemotywowanego, sfrustrowanego pracownika, którego sami będziemy musieli zwolnić. A winą za tą sytuację będziemy mogli obarczyć wyłącznie siebie i naszą wybujałą ambicję posiadania w zespole „projektanta statków kosmicznych”.