Taksonomia kompetencji jest tu produktem
W job boardzie ogólnym wyszukiwanie po słowach kluczowych wystarcza, bo kandydat i pracodawca używają tych samych słów. Ktoś szuka pracy jako księgowy, ogłoszenie ma w tytule słowo księgowy i dopasowanie jest trywialne. W rekrutacji technicznej ten mechanizm zawodzi natychmiast, bo ta sama kompetencja ma kilkanaście nazw, część z nich jest nazwą handlową konkretnego producenta, część skrótem branżowym, a część zależy od kraju i od tego, kto pisał ogłoszenie.
Spawacz z uprawnieniami do konkretnej metody, operator maszyny konkretnego producenta i inżynier znający normę obowiązującą w jednym kraju to trzy przypadki, w których wyszukiwanie tekstowe daje albo zero wyników, albo kilkaset niezwiązanych z niczym. Dlatego podstawą tej platformy nie jest silnik wyszukiwania, tylko uporządkowany słownik kompetencji: hierarchia, w której umiejętność ma nadrzędną kategorię, powiązania z kompetencjami pokrewnymi, wskazanie warunków wstępnych i poziom zaawansowania od podstawowego do eksperckiego.
Zbudowanie takiego słownika jest pracą merytoryczną, nie programistyczną, i to jest najczęściej niedoszacowany element w projektach tego typu. Kod dopasowujący, który powstaje nad słownikiem jeszcze niedomkniętym, trzeba przepisywać po każdej zmianie nazwy kategorii. Dlatego kolejność prac w tym wdrożeniu była odwrotna niż zwykle: najpierw słownik, potem wyszukiwanie i alerty nad gotowym słownikiem. Konsekwencja praktyczna jest taka, że dołożenie kolejnej branży po starcie jest pracą na danych, a nie na kodzie.
Czym jest Jobsin.co
Jobsin.co to job board dla wykwalifikowanych specjalistów technicznych z budownictwa, mechaniki, inżynierii i pokrewnych sektorów przemysłowych, łączący fachowców z pracodawcami na rynkach kilku krajów. Projekt trafił do nas w 2019 roku, a wdrożenie zajęło około sześciu tygodni. Układ i rozmieszczenie elementów dostarczył klient, więc czas, który w innych projektach schodzi na iteracje projektowe, poszedł tutaj na dwie rzeczy, które decydują o tym, czy job board się broni: na słownik kompetencji i na przepływ przenoszący aplikację między stanami.
Sektory techniczne mają kilka cech, których nie ma reszta rynku pracy. Specjalistów brakuje globalnie, więc kandydat ma przewagę i nie wypełni formularza na dwadzieścia pól. Duża część stanowisk zakłada relokację za granicę, więc do gry wchodzą wizy, uznawanie uprawnień i różnice w prawie pracy. Wymagania bywają bardzo wąskie, a znacząca część zleceń ma charakter kontraktowy i czasowy, co zmienia całą logikę powiadomień: oferta ważna przez trzy tygodnie musi dotrzeć do właściwej osoby w pierwszych dniach, bo w trzecim jest już nieaktualna.
Ogłoszenie ma datę ważności i to zmienia architekturę
Treść w typowym serwisie starzeje się powoli. Ogłoszenie o pracę starzeje się w zaplanowanym terminie i po tym terminie jest szkodliwe: kandydat, który aplikuje na nieistniejące stanowisko, traci czas, a serwis traci wiarygodność szybciej niż przy jakimkolwiek błędzie technicznym.
Z tego wynikają trzy decyzje. Po pierwsze, status ogłoszenia jest polem z zamkniętym zbiorem wartości i ma własny cykl życia, niezależny od treści. Po drugie, wygaśnięcie nie kasuje rekordu, tylko zmienia jego stan, bo historia aplikacji musi przeżyć ogłoszenie, do którego się odnosi. Po trzecie, wygasłe ogłoszenie musi przestać być widoczne dla wyszukiwarek, co jest w tym miejscu osobnym zadaniem, a nie efektem ubocznym: strona, która została zaindeksowana, żyje w wynikach jeszcze przez tygodnie i sprowadza ruch na ofertę, której nie ma.
Dane strukturalne dla ogłoszeń o pracę są w tej kategorii nie ozdobą, tylko głównym kanałem dystrybucji, bo wyszukiwarka pokazuje oferty w osobnym module. Znacznik musi więc zgadzać się ze stanem rekordu co do dnia, a nie co do treści strony, i to jest jedyny powód, dla którego data ważności siedzi w danych, a nie w akapicie napisanym przez rekrutera.
Wyszukiwanie, dopasowanie i to, czego ono nie obiecuje
Wyszukiwanie działa na słowniku opisanym wyżej i na atrybutach zamkniętych: lokalizacji z podziałem na kraj, region i miasto, branży, poziomie doświadczenia, rodzaju umowy, widełkach i walucie oraz opcji pracy zdalnej. Dopasowanie liczy zgodność kompetencji, wagę preferencji lokalizacyjnej, poziom doświadczenia i oczekiwania finansowe.
Warto powiedzieć wprost, czego taki mechanizm nie robi. Nie ocenia kandydata i nie przewiduje, czy sprawdzi się na stanowisku. Porządkuje listę według zgodności z tym, co obie strony same o sobie napisały, i tyle. Platformy tej klasy bywają opisywane językiem sugerującym więcej, a różnica jest istotna, bo od niej zależy, czy rekruter traktuje wynik jako podpowiedź, czy jako wyrok. Wskaźnik procentowy przy ofercie jest czytelny dla kandydata i jednocześnie jest najbardziej ryzykownym elementem interfejsu, bo liczba wygląda na pomiar, a jest sumą wag ustawionych ręcznie.
Technicznie wyszukiwanie idzie przez Elasticsearch, a nie przez zapytania do MySQL. Powód jest prozaiczny: filtrowanie po kilkunastu atrybutach naraz na kilkudziesięciu tysiącach rekordów to w relacyjnej bazie zapytanie z wieloma złączeniami, które na pustej instalacji zwraca wynik natychmiast, a na pełnym archiwum ogłoszeń zajmuje sekundy. MySQL zostaje przy tym jako źródło prawdy, bo indeks wyszukiwania jest strukturą pochodną i musi dać się odbudować od zera.
Alerty, czyli ruch, który generujemy sobie sami
Powiadomienia o nowych ofertach są w job boardzie mechanizmem powrotów i jednocześnie najłatwiejszym sposobem na zepsucie własnej reputacji nadawcy. Serwis, który przy każdym nowym ogłoszeniu wysyła wiadomość do wszystkich pasujących kandydatów, po miesiącu trafia do folderu ze spamem i przestaje docierać nawet do osób, które o alerty prosiły.
Rozwiązanie ma trzy warstwy. Wysyłka idzie przez kolejkę, więc publikacja ogłoszenia nie generuje setek wiadomości w jednej chwili, tylko zadania przetwarzane w tempie, które akceptuje dostawca poczty. Kandydat wybiera częstotliwość: natychmiast, dziennie albo tygodniowo, przy czym podsumowanie dzienne jest wartością domyślną, bo w rekrutacji technicznej oferta rzadko wymaga reakcji w ciągu godziny. Grupowanie odbywa się według trafności, a nie według daty, żeby jedna wiadomość zawierała kilka ofert wartych otwarcia, a nie dwadzieścia losowych.
Kolejka ma jeszcze jedną funkcję, o której się rzadko mówi. Odcina ciężkie operacje od żądania użytkownika. Publikacja ogłoszenia, przeliczenie indeksu wyszukiwania i wysyłka powiadomień to trzy różne zadania i tylko pierwsze musi zakończyć się, zanim rekruter zobaczy potwierdzenie.
Kandydat, jego dane i kontrola nad nimi
Profil kandydata w rekrutacji technicznej jest obszerny: kompetencje ze słownika, certyfikaty i uprawnienia wraz z datami ważności, historia zatrudnienia z opisem projektów, znajomość języków, preferencje lokalizacyjne wraz z gotowością do relokacji i oczekiwania finansowe w wybranej walucie. Z tych danych generuje się dokument aplikacyjny, można trzymać kilka jego wersji i aplikować jednym kliknięciem.
Najważniejszy element tej części nie jest jednak funkcją, tylko ustawieniem domyślnym. Kandydat aktywny zawodowo, który szuka pracy, nie chce, żeby jego profil zobaczył obecny pracodawca. Widoczność profilu, możliwość aplikowania anonimowo i rozstrzygnięcie, co dokładnie widzi firma przed kontaktem, są więc sterowane przez użytkownika, a wartości domyślne są zachowawcze. Serwis, który domyślnie pokazuje wszystko wszystkim, zbiera na starcie więcej profili i traci dokładnie tych kandydatów, którzy są najbardziej pożądani, bo oni mają najwięcej do stracenia.
Ochrona danych nie jest tu zatem tylko zgodnością z RODO rozumianą jako regulamin i pole zgody. Jest częścią produktu. Zarządzanie zgodami, przenoszenie danych, realizacja prawa do usunięcia i przechowywanie danych w Unii Europejskiej to wymagania, które w tej kategorii decydują o tym, czy kandydat w ogóle założy konto.
Strona pracodawcy i uczciwość ogłoszeń
Rekruter dostaje edytor ogłoszenia z uporządkowaną listą wymagań, obsługę wielu lokalizacji, widełki, terminy i bibliotekę szablonów, a po stronie kandydatów prosty system śledzenia aplikacji, porównywanie profili, planowanie rozmów i szablony korespondencji. Dostęp zespołowy oznacza, że nad jedną rekrutacją pracuje kilka osób, więc historia zmian statusu musi być przypisana do osoby, a nie do konta firmy.
Odrębnym zagadnieniem jest zaufanie. Na rynkach międzynarodowych fałszywe ogłoszenie jest realnym zagrożeniem dla kandydata, bo dotyczy pracy za granicą, kosztów relokacji i czasami opłat pobieranych z góry. Weryfikacja pracodawcy jest więc wielostopniowa, ogłoszenia podlegają moderacji, a zgłoszenia od użytkowników trafiają do ręcznego przeglądu. Automatyczne wykrywanie wzorców typowych dla oszustw jest tu pomocą, a nie rozstrzygnięciem: ostatni krok robi człowiek, bo koszt pomyłki w jedną stronę ponosi kandydat, a w drugą uczciwy pracodawca, któremu wstrzymano ogłoszenie.
Zgodność międzynarodowa bez fikcji jednego regulaminu
Platforma działająca w kilku krajach mierzy się z różnym prawem pracy, różnymi wymogami dotyczącymi danych i różnymi zasadami publikowania widełek. Najgorsze możliwe rozwiązanie to jeden regulamin napisany pod najbardziej liberalną jurysdykcję, bo wygląda na uporządkowanie, a jest przesunięciem ryzyka na użytkownika.
Zamiast tego warstwa zgodności jest modułowa: regulaminy i klauzule są przypisane do kraju, dane kierowane do właściwej lokalizacji, a różnice w wymaganiach opisane jako konfiguracja, nie jako kod. Dzięki temu dołożenie kolejnego rynku nie wymaga przeglądu całej aplikacji, tylko uzupełnienia zestawu reguł i przeglądu prawnego dla tej jurysdykcji.
Wydajność i stos technologiczny
Platforma stoi na WordPressie z autorskim motywem job boardu, mocno dostosowanym silnikiem ogłoszeń, zestawem własnych wtyczek i polami Advanced Custom Fields Pro. Warstwa danych to MySQL z replikacją, Redis na cache sesji i obiektów, Elasticsearch na wyszukiwanie oraz osobne miejsce na dane analityczne. Poza tym są integracje dystrybucji ofert i danych strukturalnych, bramki płatności i dostawcy poczty.
Praca wydajnościowa koncentruje się na listach ogłoszeń, bo to one generują większość ruchu i są najdroższe do policzenia. Cache trzyma wyniki dla najczęstszych kombinacji filtrów, zasoby statyczne idą z sieci dostarczania treści, a zapytania do bazy przeszły przegląd pod kątem tych, które rosną liniowo z liczbą ogłoszeń. Testy obciążeniowe robimy na kopii danych produkcyjnych, nie na pustej instalacji, i to jest w tym akapicie zdanie najważniejsze: zapytanie zwracające wynik natychmiast na zbiorze demonstracyjnym zachowuje się inaczej na archiwum z wieloletnią historią aplikacji podpiętą do ogłoszeń.
Aplikacja jako stan, nie jako wysłany formularz
W większości serwisów formularz kończy się wysłaniem wiadomości i to jest cały jego cykl życia. W job boardzie aplikacja jest obiektem, który żyje tygodniami i przechodzi przez stany: złożona, przejrzana, zaproszona na rozmowę, odrzucona, zamknięta razem z ogłoszeniem. Potraktowanie jej jak wiadomości e-mail wygląda na uproszczenie i jest źródłem dwóch problemów naraz.
Pierwszym jest cisza po stronie kandydata. Osoba, która wysłała dziesięć aplikacji i nie wie, co się z nimi stało, przestaje korzystać z serwisu szybciej niż wtedy, gdy dostaje odmowy. Panel ze statusem i powiadomienie przy każdej zmianie nie kosztują prawie nic, a rozstrzygają o tym, czy kandydat wraca. Drugim jest praca rekrutera: bez stanów nie da się powiedzieć, ile aplikacji czeka, ani zbudować żadnego zestawienia, które nie byłoby ręcznym liczeniem wiadomości w skrzynce.
Stany mają też znaczenie dla przechowywania danych. Aplikacja zawiera dane osobowe i musi zostać usunięta albo zanonimizowana po okresie, na który kandydat wyraził zgodę. Bez jawnego stanu i daty nie da się tego zrobić automatycznie, a robienie tego ręcznie oznacza, że po roku nikt już tego nie robi.
Urządzenie mobilne u kandydata na budowie
Profil odbiorcy tej platformy wygląda inaczej niż w rekrutacji biurowej. Znaczna część kandydatów przegląda oferty z telefonu, poza domem, często przy słabym zasięgu i w krótkich przerwach. To nie jest ciekawostka demograficzna, tylko ograniczenie projektowe: formularz wymagający dwudziestu pól i stabilnego łącza zostanie porzucony w połowie, a porzucona aplikacja wygląda w statystykach identycznie jak brak zainteresowania.
Z tego wynika kilka rzeczy. Profil wypełnia się etapami i zapisuje częściowo, aplikowanie z gotowego profilu jest jednym gestem, a dokument można dodać z aparatu albo z galerii, bo kandydat na budowie nie ma przy sobie skanera. Lista ofert jest zoptymalizowana pod dotyk i ładuje kolejne wyniki stopniowo, a nie wszystkie naraz, bo pierwsze dziesięć pozycji decyduje o tym, czy ktokolwiek przewinie dalej.
Waga pierwszego ekranu jest tu parametrem biznesowym, a nie techniczną ciekawostką. Na szybkim łączu różnicy nie widać wcale, i dlatego decyzje o kolejności ładowania podejmuje się patrząc na gorszy przypadek, nie na wygodniejszy.
Przebieg wdrożenia
Wdrożenie trwało około sześciu tygodni od analizy zakresu do startu. Kolejność prac była opisana wyżej i wynikała z jednej obserwacji: dwa najdroższe błędy w tej kategorii, czyli niedomknięty słownik kompetencji i wysyłka powiadomień bez kolejki, ujawniają się dopiero przy wolumenie, więc trzeba je rozstrzygnąć przed startem, a nie po pierwszym miesiącu.
Po starcie projekt przeszedł w utrzymanie: kopie zapasowe, aktualizacje bezpieczeństwa, okresowy przegląd wydajności i testy obciążeniowe przed okresami, w których rośnie liczba rekrutacji. Utrzymanie obejmuje też kontrolę jakości ogłoszeń i moderację, bo w job boardzie to nie jest praca redakcyjna, tylko bezpośrednia ochrona wiarygodności serwisu.
Podsumowanie
Jobsin.co pokazuje, że job board w rekrutacji technicznej nie jest listą ogłoszeń z wyszukiwarką. Jest słownikiem kompetencji, mechanizmem powiadomień, warstwą zgodności prawnej dla kilku rynków i procesem weryfikacji pracodawców, a interfejs jest ostatnią warstwą nad tym wszystkim. Rozstrzygnięcia techniczne opisane wyżej wynikają z tej kolejności: słownik przed dopasowaniem, indeks wyszukiwania osobno od źródła prawdy, kolejka przed wysyłką, ustawienia prywatności domyślnie zachowawcze i moderacja z człowiekiem w ostatnim kroku.
Na kolejne wdrożenie przenosi się sposób pracy. Nie przenosi się słownik ani integracje, bo powstały pod jeden rynek i pod dane jednego klienta. Kolejny projekt zaczyna się od analizy zakresu, a wycena idzie po niej.
Często zadawane pytania
Najważniejsze odpowiedzi, które pomagają wdrożyć temat w praktyce.
Jakiego zakresu dotyczył projekt Jobsin.co?
#Jak wyglądał przebieg prac przy Jobsin.co?
#Co było najtrudniejsze technicznie w Jobsin.co?
#Co z projektu Jobsin.co da się wykorzystać przy kolejnym wdrożeniu?
#Potrzebujesz FAQ dopasowanego do branży i rynku? Przygotujemy wersję pod Twoje cele biznesowe.
Porozmawiajmy