Usprawniliśmy proces rekrutacji dzięki zwinnemu zarządzaniu

Aby zachęcić potencjalnych pracowników do aplikowania, firma Deloitte postanowiła dostosować system do ich oczekiwań, wykorzystując do tego celu zwinne metodyki zarządzania. Efekt? W ciągu roku liczba aplikacji rekrutacyjnych wzrosła o 30%.

Chociaż wiele organizacji przy każdej okazji podkreśla, że ich najważniejszym zasobem są ludzie, to w przypadku firmy takiej jak Deloitte taka deklaracja nie jest tylko popularnym sloganem. Podstawą zasobów firm konsultingowych są doradcy, których czas i wiedza są wynajmowane klientom. Jakość pracy pracowników przekłada się więc bezpośrednio na poziom świadczonych usług, dlatego nie sposób przecenić roli dobrze prowadzonego procesu rekrutacyjnego.

Niestety, prawie połowa osób, które zabierały się do wypełniania formularza rekrutacyjnego na stronie Deloitte, rezygnowała w trakcie tej czynności. Zaczęliśmy się zastanawiać, co sprawia, iż niemal połowie użytkowników ówczesnego systemu łatwiej było pogodzić się nawet z myślą, że nie będą pracować w Deloitte, niż przejść przez 11 ekranów formularzy, w których trzeba było wypełnić 18 pól i 30 razy kliknąć myszą. Odpowiedź przyszła sama. System rekrutacyjny był zbyt czasochłonny i za bardzo skomplikowany, w tym szczególnie dla młodych osób, które oczekują, że w sieci wszystko będzie się odbywać szybko i sprawnie. Sposób, w jaki korzystamy z internetu, bardzo zmienił się w ciągu ostatnich kilku lat. Chcemy szybko robić zakupy, bez utrudnień korzystać z konta bankowego, załatwiać formalności i uzyskiwać dostęp do filmów lub muzyki. Dlatego również system rekrutacji powinien być szybki i intuicyjny. Lista wad systemu była jednak znacznie dłuższa i nie ograniczała się jedynie do panelu dla kandydatów. Stara wersja portalu miała poważne niedociągnięcia również z punktu widzenia rekruterów, którzy z powodu ociężałości i małej funkcjonalności systemu mieli poważne trudności z przeczesywaniem firmowych baz danych.

Dołącz do klubu specjalistów od HR »

Archaiczne rozwiązanie

Poprzedni system IT wspierający procesy rekrutacyjne nie spełniał w naszej opinii swojej podstawowej funkcji: nie zachęcał kandydatów do aplikowania. Nie chcieliśmy jednak rozpoczynać zmiany, bazując tylko na naszych opiniach. Przeprowadziliśmy więc krótki projekt badawczy Envision & Design. W ciągu miesiąca trzyosobowy zespół specjalistów design thinking określił główne problemy, z którymi mają do czynienia kandydaci aplikujący do Deloitte. Zgromadził dane statystyczne potwierdzające stawiane hipotezy, a następnie opowiedział, jak powinien wyglądać proces rekrutacji. Tak powstał projekt, który zawierał również opis proponowanych funkcji, mogliśmy go więc przedstawić zarządowi. Początkowa reakcja na nasz pomysł nie była jednak budująca. Jeden z dyrektorów stwierdził, że sytuacja, w której 40% kandydatów rezygnuje już na etapie wypełniania formularza, jest dla nas faktycznie korzystna, bo zostają ci naprawdę zdecydowani.

Postanowiliśmy jednak nie składać broni i wyjaśniliśmy, że jeśli niemal połowa osób potencjalnie zainteresowanych pracą u nas rezygnuje z niej przy kontakcie z systemem rekrutacyjnym, to znaczy, że prawie połowa pieniędzy przeznaczonych na budowanie marki pracodawcy jest marnowana. Co więcej, w obecnej sytuacji rynkowej to pracownik stoi na uprzywilejowanej pozycji, a najbardziej utalentowane oraz najlepiej wykwalifikowane osoby mogą praktycznie przebierać w ofertach. Dlatego nie można mieć pewności, że będą one miały wystarczająco dużo cierpliwości i samozaparcia, by przejść przez nasz system rekrutacyjny. Gdy już zawiodły wszystkie argumenty, poprosiliśmy naszego wiceprezesa, aby sam wypełnił formularz rekrutacyjny. Gdy zmierzył się z tym zadaniem, od razu dał nam zielone światło na przebudowę aplikacji.

Poszukujesz praktycznych rozwiązań rekrutacyjnych?»

System od nowa

Naszym celem był prosty, intuicyjny system rekrutacyjny, który sprawdzi się w polskim oddziale firmy Deloitte. Mieliśmy już pierwotne założenia, ale to wciąż było za mało. Brakowało nam pełnej listy cech, jakimi powinien się charakteryzować nowy system, a więc nie zdawaliśmy sobie do końca sprawy, jakie funkcje powinniśmy rozwijać. Gdyby tworzyć aplikację według bardziej tradycyjnego modelu (tzw. waterfall), przed przystąpieniem do pracy musielibyśmy przygotować szczegółowo rozpisaną hierarchię osób zaangażowanych w projekt i dokładnie rozpisaną specyfikację finalnego systemu. Ryzyko polegało jednak na tym, że tworząc taki rozbudowany katalog funkcji, nie mielibyśmy pewności, które z nich faktycznie wspierają proces rekrutacyjny, a które są jedynie mniej lub bardziej atrakcyjnym dodatkiem. Co gorsza, nie moglibyśmy też mieć pewności, że nie pominęliśmy jakiegoś ważnego aspektu przedsięwzięcia. Zbyt długa lista funkcji zwiększa też prawdopodobieństwo, że finalny projekt nigdy nie powstanie, ponieważ każdy dodatkowy element może znacząco wydłużyć pracę nad systemem. Ryzykowalibyśmy więc opracowaniem produktu obfitującego w być może niepotrzebne moduły, których wykonanie kosztowałoby wiele godzin pracy programistów (a więc też pieniędzy). Innymi słowy, model waterfall kojarzył się nam z ponoszeniem znacznych nakładów czasu, sił i kosztów przy bardzo wysokim stopniu niepewności co do wartości końcowej produktu. Z tego powodu zdecydowaliśmy się na zwinne podejście, zakładające stworzenie najprostszej, ale już funkcjonalnej wersji produktu, a potem dodawanie do niej kolejnych elementów aż do uzyskania wymaganych efektów. Ponadto istotą metody agile jest sztywno założony czas zakończenia projektu oraz nieprzekraczalny budżet, co ogranicza ryzyko związane z niepotrzebnym przeciąganiem pracy nad rozwiązaniem. Ponieważ zwinność cieszy się w wielu nowoczesnych organizacjach rosnącym zainteresowaniem, dysponujemy szerokim wachlarzem tego typu metodyk.

Poprzedni system IT wspierający procesy rekrutacyjne nie zachęcał kandydatów do aplikowania. Nie chcieliśmy jednak rozpoczynać zmiany, bazując tylko na naszych opiniach.

Scrum na Saskiej Kępie

Nasz wybór padł na metodykę scrum, opierającą się na podziale całego realizowanego przedsięwzięcia na mniejsze fazy nazywane sprintami. To jednakowej długości, maksymalnie miesięczne, odcinki, w trakcie których opracowuje się taką wersję produktu, którą można pokazać na rynku. Tym sposobem najpóźniej po upływie miesiąca jest gotowa pierwsza koncepcja produktu, która wymaga udoskonalenia, ale stanowi już określoną całość i dobrze ilustruje dalszy kierunek rozwoju. W kolejnych sprintach poszczególne wersje są uzupełniane oraz doskonalone. Ważne jest, by długość pojedynczego sprintu nie przekraczała jednego miesiąca, co pozwala ograniczyć ryzyko finansowe oraz związane ze zmieniającymi się oczekiwaniami rynku. Nic nie stoi na przeszkodzie, by podzielić proces na odcinki dwutygodniowe. W ten sposób można często korygować i uzupełniać produkt.

Scrum zakłada również istnienie samoorganizujących się zespołów mających wszystkie kompetencje potrzebne do wykonania zadania. Obok zespołów funkcjonują również takie role, jak właściciel produktu (PO, product owner) oraz scrum master. Pierwsza z tych osób odpowiada za zarządzanie listą oczekiwanych cech finalnego produktu, a także reprezentuje interesariuszy. U nas właścicielem produktu była osoba prowadząca projekt Envision & Design, która – z racji swojego doświadczenia – najlepiej rozumiała oczekiwania dotyczące nowego systemu. Z kolei scrum master to osoba (lub osoby) będąca tzw. służebnym liderem zespołu wykonującego działania przewidziane w danym sprincie.

Pracując jako scrum masterzy, byliśmy odpowiedzialni przede wszystkim za usuwanie przeszkód, które mogłyby rozpraszać zespół lub w inny sposób utrudniać mu wykonanie powierzonego zadania. Dlatego podjęliśmy decyzję o przeniesieniu się na pół roku z nowego, atrakcyjnego biura w eleganckim wieżowcu Q22 w samym centrum Warszawy do biura na Saskiej Kępie, oferującego kameralny klimat, bardziej typowy dla start‑upów niż korporacji. Obawialiśmy się, że specyfika pracy w biurze oznacza, że członkowie zespołu byliby równolegle angażowani przez przełożonych do innych zadań, które mogłyby zagrozić terminowemu powstaniu tworzonego systemu. W podejściu zwinnym bardzo ważne jest eliminowanie strat i opóźnień, które mogą wynikać z dekoncentracji lub pracy nad wieloma wątkami naraz. Badania pokazują, że człowiek potrzebuje około 20 minut, by powrócić do zagadnienia, nad którym pracował, jeśli ktokolwiek zawróci mu głowę pytaniem. Chcieliśmy uniknąć tych niepotrzebnych strat. Ponadto angażowanie członków zespołu w inne inicjatywy w oczywisty sposób zabiera czas na dokończenie zadań przewidzianych w danym sprincie. Dlatego też zdecydowaliśmy się stworzyć naszemu zespołowi odrębną przestrzeń do pracy, z pomieszczeniami pozwalającymi na kreatywne myślenie, wspólne posiłki oraz odpoczynek, tak jak jest to zorganizowane w firmie Spotify, znanej ze zwinnej kultury.

Zaraz po otrzymaniu zielonego światła od naszych przełożonych poprosiliśmy o wyłączenie z innych zadań zespołu programistów pracujących nad systemem. Nieformalna atmosfera pracy oznacza również brak dress code’u czy też możliwość wydawania budżetu przyznanego na projekt bezpośrednio z karty firmowej, bez konieczności rozpisywania przetargów i prowadzenia czasochłonnych rozliczeń. Jeśli więc uznaliśmy, że potrzebujemy określonego modelu monitora, to po prostu go kupowaliśmy. Gdy organizowaliśmy imprezę integracyjną dla członków zespołu, to również płaciliśmy za nią z karty firmowej. Mogliśmy sobie na to pozwolić, bo jednymi z kluczowych założeń scrum są otwartość i zaufanie.

Zaczęliśmy od pokera

Pracę nad nowym systemem rozpoczęliśmy od dwudniowego warsztatu, podczas którego zastanawialiśmy się wraz z całym zespołem nad uszczegółowieniem wizji produktu, która powstała w fazie Envision & Design (projektowanie). Analizując rezultaty tej fazy oraz wskazania szefowej działu HR i jej pracowników, opracowaliśmy listę oczekiwanych cech systemu. Zostały sformułowane w postaci 80 tzw. historii ilustrujących doświadczenia poszczególnych użytkowników aplikacji, np. kandydata do pracy, który ma mieć możliwość przesłania CV za pośrednictwem smartfona, aby móc starać się o pracę w Deloitte nawet podczas podróży metrem. Innym przykładem historii było stworzenie globalnej bazy kandydatów, tak aby aplikacja złożona w Warszawie była widoczna również dla rekruterów w zagranicznych oddziałach Deloitte. Zgodnie z założeniami metodyki scrum lista takich planowanych cech produktu jest określana jako product backlog. Do każdego sprintu członkowie zespołu deweloperskiego samodzielnie wybierają poszczególne elementy opracowywanego systemu, kierując się swoją oceną nakładów czasu i pracy potrzebnych do ukończenia danego komponentu. Scrum zakłada bowiem, że to osoby bezpośrednio zaangażowane w realizację zadania mogą najlepiej ocenić, na ile realne jest wykonanie danego elementu w danym czasie.

Zanim jednak zespół włączy do sprintu określone zadania, należy upewnić się, że wszyscy członkowie jednakowo rozumieją poszczególne elementy planowanych cech produktu. To bardzo ważny element pracy, gdyż ogranicza ryzyko wystąpienia nieprzewidzianych opóźnień, wynikających z nieprawidłowej oceny złożoności elementów finalnego produktu. W przypadku znacznego niedoszacowania czasu potrzebnego na ukończenie jakiegoś zadania realizacja projektu może się znacznie opóźnić. Aby uniknąć takich sytuacji, zastosowaliśmy tzw. scrum poker, który uznaliśmy za tak skuteczne rozwiązanie, że postanowiliśmy go wykorzystać podczas wszystkich kolejnych sesji planistycznych. Jest to popularna wśród zwinnych zespołów technika szacowania czasu i pracy potrzebnych do wykonania określonych zadań. Najpierw daną funkcję należy rozbić na możliwie najmniejsze elementy, a następnie wskazać ten spośród nich, który sprawia wrażenie najłatwiejszego i najmniej kosztownego czasowo. Wybranemu zadaniu jest przypisywana pewna niska wartość, najlepiej 1. Następnie każdy członek zespołu otrzymuje karty z zapisanymi liczbami i przy szacowaniu skali trudności kolejnych elementów backlogu wszyscy na sygnał odwracają kartę z liczbą punktów, jakie im przyznali. Jeśli liczba punktów przyznawana przez poszczególnych członków zespołu jest podobna, oznacza to, że wszyscy prawidłowo zrozumieli zakres pracy. W przypadku wystąpienia znacznych rozbieżności, trzeba dokładnie wyjaśnić oczekiwania.

Szybki debiut

W tym momencie nasz zespół mógł wybrać zadania do pierwszej fazy projektu. W myśl zasad metodyki scrum wynikiem każdego sprintu ma być opracowanie możliwej do wykorzystania wersji produktu. I tu, niestety, pojawiły się pierwsze poważniejsze trudności. Początkowo postanowiliśmy, że będziemy pracować w tygodniowych sprintach. Ten czas okazał się jednak zbyt krótki, aby faktycznie mogła powstać działająca wersja nowego systemu. Konieczne okazało się ich wydłużenie do dwóch tygodni. Na początku podzieliliśmy projekt na zbyt krótkie sprinty, dlatego nie udało nam się od razu dostarczyć działającej wersji produktu. Ten cel zrealizowaliśmy dopiero po czwartym sprincie. Pierwsza wersja oferowała już praktycznie komplet funkcji osobie aplikującej, która na tym etapie mogła np. wczytać swoje dane oraz CV. Chociaż w trakcie pierwszego sprintu wykonaliśmy dopiero wstępną wersję systemu, to umożliwiała ona rozpoczęcie procesu rekrutacyjnego przy założeniu, że rekruter przeprowadzi resztę manualnie. Dział HR nie miał więc jeszcze podglądu statusu poszczególnych kandydatów, co oznacza, że system nie pokazywał, czy są oni po pierwszych rozmowach, testach, czy dopiero przesłali CV. Mimo niedociągnięć ta wersja produktu była już możliwa do uruchomienia i dobrze pokazywała kierunek, w jakim chcieliśmy dalej go rozwijać.

Wkrótce odwiedził nas wiceprezes działu doradczego Deloitte, który szybko uwierzył w nasz projekt i służył ogromnym wsparciem. Chciał poznać postępy w pracy, a my byliśmy przygotowani do zaprezentowania pierwszych rezultatów. Spodziewał się zobaczyć jasno rozpisane role zespołu, prezentację w PowerPoincie i wykres pokazujący wykorzystanie budżetu projektu. W zespołach pracujących zgodnie z metodyką scrum nie ma innych ról niż członek zespołu, właściciel produktu i scrum master. Założenia zastosowanej metodyki każą też skupić się na sednie projektu, a nie na raportach. Uznaliśmy więc, że o postępach najlepiej będą świadczyć namacalne rezultaty pracy.

Z wiceprezesem spotkaliśmy się w pustej salce konferencyjnej, gdzie nie było ani laptopa, ani projektora, ani wydruków slajdów czy arkusza kalkulacyjnego. Zamiast tego przesłaliśmy mu link do pierwszej wersji nowego serwisu rekrutacyjnego. Zaskoczony, że w tak krótkim czasie udało nam się wypracować jakieś efekty, otworzył link w telefonie i zobaczył formularz do wypełnienia. Składał się z tylko jednego ekranu i wymagał podania jedynie podstawowych danych. Szybkość, z jaką zwinna metodyka pracy pozwoliła nam zaprezentować pierwsze efekty, była wiarygodnym argumentem świadczącym o tym, że to dobry sposób prowadzenia pracy nad projektami.

Nie tylko dla programistów

Zwinne metodyki zarządzania (agile) różnią się od tradycyjnego podejścia do pracy nad tworzeniem produktów, oferując znacznie prostszy i efektywniejszy model realizacji zadania. Nie ma w nich tworzenia rozbudowanych planów, hierarchii organizacyjnej i sztywnych zasad. Zwinność opiera się na samoorganizujących się zespołach, elastyczności i otwartości. Początkowo zwinne metodyki były wykorzystywane przede wszystkim przez programistów. Stanowiły alternatywę dla tradycyjnego modelu wytwarzania oprogramowania (waterfall), polegającego na tworzeniu szczegółowych planów i dokumentacji, a następnie długotrwałym i szczegółowym realizowaniu założonych celów, co prowadzi do późnego dostarczenia wartości dla klienta. Popularność zwinnych metodyk wynika m.in. z częstych zmian, jakim mogą podlegać oczekiwania klientów oraz zewnętrzne uwarunkowania, przez które tradycyjna metoda budowy systemów prowadziła do niedopasowania produktu do wymagań użytkowników. Obecnie ze zwinnych metodyk korzysta coraz więcej firmowych działów, m.in. marketing, sprzedaż, HR.

Scrum jest jedną z najpopularniejszych zwinnych metodyk. Definiuje się go jako ramy postępowania wykorzystywane do wytwarzania złożonych produktów w sposób przyrostowy. Sednem tej metodyki jest niewielki i elastyczny zespół, posiadający pełne spektrum umiejętności niezbędnych do budowy danego systemu. Scrum rozkłada pracę nad produktem na tzw. sprinty, czyli jednakowej długości odcinki. Rezultatem każdego sprintu powinno być opracowanie kolejnej wersji produktu (tzw. przyrostu), która jest możliwa do wypuszczenia na rynek. Bezpośrednio po zakończeniu każdego sprintu rozpoczyna się kolejny, podczas którego produkt jest dalej rozwijany i udoskonalany z uwzględnieniem m.in. informacji zwrotnej od klienta.

Sprint z przeszkodami

Nie oznacza to jednak, że nie wiążą się z nią wyzwania. Jednym z zadań scrum mastera jest dbanie o to, aby praca przebiegała zgodnie z zasadami przyjętej metodyki. Zwinność nie jest tożsama z brakiem uporządkowanego procesu. Wręcz przeciwnie – wszystkie spotkania mają z góry ustalony maksymalny czas trwania. Pozwala to na zwiększenie przejrzystości procesu oraz ułatwia planowanie pracy. Niemniej na początku, jako scrum masterzy, musieliśmy włożyć sporo wysiłku w to, aby członkowie zespołu nie przedłużali spotkań. Musieliśmy także pilnować, aby założone spotkania w ogóle się odbywały. Scrum zakłada, że raz dziennie należy dokonać krótkiego (maksymalnie 15‑minutowego) przeglądu dotychczasowej pracy oraz zaplanować działania na kolejne 24 godziny, tak aby zwiększyć transparentność procesu, co zapewnia dobrą kooperację. Aby skrócić czas przeznaczany na te poranne spotkania, założyliśmy, że będą odbywać się na stojąco. Ponadto umówiliśmy się z zespołem na wprowadzenie kar za spóźnienia lub przedłużanie spotkań. Nie były one zbyt dotkliwe i polegały albo na robieniu pompek, albo na kupowaniu słodyczy dla całego zespołu. Mimo to pomysł się sprawdził i po pewnym czasie spotkania odbywały się, nawet kiedy nie było nas w biurze.

Sprawienie, by deweloperzy dostrzegli wartość spotkań scrum, stało się dopiero pierwszym krokiem na ścieżce zmiany filozofii pracy, która utrwaliła się w nas w wyniku realizacji projektów w metodykach tradycyjnych. Programiści przyzwyczajeni do budowy systemów w tradycyjnym modelu waterfall traktują siebie jako zleceniobiorców, odpowiedzialnych jedynie za mały wycinek projektu, czyli zakodowanie pewnej funkcjonalności według dostarczonej im wcześniej specyfikacji. W scrumie natomiast są często angażowani również w inne zadania, takie jak opracowanie funkcjonalne danego fragmentu systemu czy przetestowanie pewnych elementów aplikacji. Ponadto metodyka ta zakłada, że za sukces sprintu jest wspólnie odpowiedzialny cały zespół i nie ma żadnego lidera, który mówi deweloperom, co i jak mają robić. Taka zmiana podejścia do pracy może zwiększyć zaangażowanie członków zespołu, którzy czują odpowiedzialność za efekty swojej pracy. Jednak w przypadku nieudanego sprintu często dochodzi do kłótni oraz przerzucania odpowiedzialności za porażkę. Jako scrum masterzy nieraz musieliśmy interweniować w takich sytuacjach i starać się, by poszczególni członkowie zespołu zrozumieli, że przypisywanie komuś winy do niczego dobrego nie doprowadzi. Każdy powinien myśleć o tym, jak poprawić pracę całego zespołu, a nie tylko część pracy, którą wykonuje.

Musieliśmy zmierzyć się też z samą kompozycją zespołu, w skład którego początkowo wchodziły oprócz nas oraz właściciela produktu jeszcze trzy osoby, co stanowi minimalną liczbę przewidzianą w metodyce scrum. Przy tak niewielkiej liczebności zespołowi brakowało jednak niektórych kompetencji, co mogło zagrozić realizacji zadania w terminie. Rekrutacja kolejnych osób do projektu za pomocą dotychczasowego narzędzia Deloitte była więc prawdziwym wyzwaniem, co jeszcze raz uświadomiło nam potrzebę jego zmiany. Ostatecznie zatrudniliśmy dodatkowe osoby dzięki rekomendacjom znajomych z pracy. Udało nam się skomponować zespół różnorodny pod względem płci oraz wieku. W zespole pracowały również programistki, co w dalszym ciągu nie jest jeszcze powszechnym zjawiskiem w wielu firmach, a wiek jego członków wahał się od 25 do 45 lat. Początkowo obawialiśmy się, że ten element może stanowić barierę w komunikacji, jednak szybko okazało się, że różnica wieku i doświadczenia bardzo pozytywnie wpłynęła na realizację poszczególnych zadań. Starsi programiści często służyli radą młodszym kolegom, którzy nieco odważniej deklarowali cele, z jakimi chcieli się zmierzyć. Ich entuzjazm działał natomiast mobilizująco na bardziej doświadczonych członków zespołu. Tylko raz musieliśmy zrezygnować z jednego z uczestników projektu, który nie odnajdował się w grupie i preferował indywidualny styl pracy. Tymczasem zależało nam na tym, aby poszczególne osoby wymieniały się swoimi zadaniami, dzięki czemu zyskiwały lepszy ogląd całości projektu. Ponadto w przypadku losowych nieobecności w ten sposób znacznie łatwiej było znaleźć zastępstwo.

Proces powstawania nowego systemu

Co za dużo, to niezdrowo

Tworzony przez nas system musiał być nie tylko wygodny w użytkowaniu, ale również całkowicie bezpieczny. Dlatego też na pewnym etapie projektu pojawiła się kwestia cyberbezpieczeństwa oraz ochrony danych osobowych. W efekcie nie mogliśmy upublicznić naszej platformy tak szybko, jakbyśmy tego chcieli. Potrzebowaliśmy w zespole kogoś, kto zna się na cyberbezpieczeństwie oraz zagadnieniach prawnych związanych ze zmianami w regulacjach o ochronie danych osobowych w Unii Europejskiej, czyli rozporządzeniu RODO. W przypadku cyfrowego bezpieczeństwa poprosiliśmy naszych kolegów zajmujących się tym obszarem w Deloitte o testy penetracyjne, które na szczęście zakończyły się pomyślnie. Również w przypadku zagadnień prawnych zdobyliśmy niezbędną wiedzę, pozwalającą nam przebudować system przed jego wdrożeniem. W efekcie musieliśmy pogodzić się z tym, że nasz harmonogram uległ modyfikacjom o jakieś trzy tygodnie w stosunku do pierwotnego planu.

RODO postawiło przed nami więcej wyzwań, niż się nam pierwotnie wydawało. Na początku projektu chcieliśmy jak najszybciej pokazać efekty naszych prac, więc stworzyliśmy rozwiązanie, które pozwalało, by rekruterzy sami dodawali kandydatów do bazy danych. Poświęciliśmy kilkadziesiąt dni na rozwój tej funkcji. Jednak potem okazało się, że musimy ją jeszcze zmienić właśnie pod kątem RODO. Postawiliśmy więc na rozwiązanie, w którym system wysyłał zaproszenie do kandydatów, tak aby sami mogli wyrazić niezbędne zgody na przetwarzanie danych.

Prawdziwa trudność pojawiła się jednak na dwa, trzy miesiące przed terminem oddania finalnego produktu. W trakcie zbierania listy oczekiwanych cech systemu każda osoba, z którą go konsultowaliśmy, dodawała od siebie jakiś element. Wszystkie były oczywiście uzasadnione i z pewnością mogłyby przyczynić się do poprawy doświadczenia użytkownika. Czas założony na realizację projektu nie pozwalał na uwzględnienie wszystkich oczekiwań. Zrozumieliśmy, że jeśli będziemy dążyć do realizacji każdego aspektu z listy zadań, nie zdążymy opracować w terminie wersji systemu, którą będziemy mogli przesłać do testów. W takiej sytuacji testowanie systemu nie przyniosłoby nam żadnej korzyści, bo wiele elementów nie było jeszcze gotowych. Zwinność umożliwia jednak wprowadzanie zmian w planowanych cechach produktu. Dlatego ponownie skonsultowaliśmy się z interesariuszami projektu, by dowiedzieć się, które elementy są faktycznie niezbędne dla uruchomienia systemu. Początkowo wiele osób broniło swoich pomysłów.

Skuteczność nowego systemu zachęciła również inne oddziały Deloitte do wykorzystania go na swoich rynkach. Obecnie nasz system rekrutacyjny jest wdrażany w 15 krajach Europy Środkowej i Wschodniej.

Wyjaśniliśmy jednak, że wcale nie kwestionowaliśmy sensowności tych pomysłów, jednak ze względu na ograniczenia czasowe nie mogliśmy pozwolić sobie na wszystko. Dlatego każdemu interesariuszowi zadaliśmy to samo pytanie: „Jeśli w systemie nie znajdzie się proponowana przez ciebie cecha, to czy nadal uważasz, że powinniśmy nad nią pracować?”. Takie postawienie sprawy pozwoliło nam na sporządzenie krótkiej listy najważniejszych funkcji. Z drugiej strony nasi interesariusze wiedzieli, że w systemie znajdą funkcje, które pierwotnie nie były planowane do realizacji, jak np. raporty w formacie XLS, które pozwalają na analizę efektywności działań rekrutacyjnych.

Jednocześnie zdobyliśmy wiedzę o elementach, z których mogliśmy zrezygnować. Finalna wersja systemu nie oferuje na przykład integracji z profilem kandydata na portalu LinkedIn. Taka opcja na pewno wyglądałaby atrakcyjnie, ale nie była kluczowa dla uruchomienia systemu, który może się bez niej obyć. Gdybyśmy natomiast zdecydowali się dodać opcję integracji z LinkedIn, kosztowałoby to znacznie więcej czasu oraz opóźniłoby uruchomienie systemu. Tymczasem, zgodnie z metodyką scrum, nie mogliśmy przesuwać terminu zakończenia projektu. To właśnie ten rygor pozwala na wybór koniecznych elementów produktu. Przykładów funkcji, które w ten sposób odrzuciliśmy, było więcej. Wśród nich znalazł się też proces integracji z systemem do wykonywania testów językowych i numerycznych albo przygotowanie ekranów dla menedżerów, aby mogli sami sprawdzać status procesów rekrutacyjnych.

Przyjęte podejście pozwoliło na realizację celu polegającego na zwiększeniu liczby kandydatów do pracy w Deloitte. Między czerwcem a listopadem 2016 roku liczba aplikacji, jakie otrzymaliśmy od użytkowników za pośrednictwem starej wersji systemu, wyniosła 11,7 tysiąca. Rok później w tym samym okresie, gdy korzystaliśmy już z nowej wersji, otrzymaliśmy 15,2 tysiąca aplikacji. O ile wcześniej jedynie 60% użytkowników kończyło wypełnianie formularza rekrutacyjnego, to obecnie ten odsetek wynosi blisko 100%. Finalnie w opracowanej przez nas wersji systemu użytkownik musi wypełnić tylko cztery pola znajdujące się na jednym ekranie i raz kliknąć myszą. O łatwości, z jaką udaje nam się pozyskiwać nowych pracowników, dobrze świadczą też badania satysfakcji użytkowników nowej wersji systemu. Wynikało z nich, że ich zadowolenie utrzymywało się na wysokim poziomie przez cały czas pracy z nowym formularzem. Gwałtownie spadało dopiero po naciśnięciu ostatniego przycisku wysyłającego wszystkie potrzebne informacje do Deloitte. Okazało się, że nowa wersja systemu jest tak prosta w obsłudze – zwłaszcza w porównaniu z poprzednią – że wielu użytkowników nie miało pewności, że udało im się przesłać CV. Oczywiście otrzymują potwierdzenie otrzymania aplikacji e‑mailem, ale i tak postanowiliśmy zlikwidować nawet ten drobny dyskomfort. Dlatego po wypełnieniu wszystkich dokumentów oraz po przesłaniu ich do nas system wyświetla kolejny ekran z komunikatem „tak, to już wszystko”. Badania wykazały, że po wprowadzeniu tej drobnej zmiany satysfakcja użytkowników utrzymuje się już na niezmiennie wysokim poziomie. Co więcej, badanie satysfakcji naszych rekruterów wykazało, że 9 na 14 ankietowanych jest zadowolonych z nowej wersji systemu, a 9 na 13 uznało, że jest lepsza od poprzedniej. Wreszcie aż 93% chciałoby, aby to nasza wersja systemu była wykorzystywana podczas przyszłych rekrutacji w Deloitte.

Skuteczność naszego nowego systemu zachęciła również inne oddziały Deloitte do wykorzystania go na swoich rynkach. Obecnie nasz system rekrutacyjny jest wdrażany w 15 krajach Europy Środkowej i Wschodniej, m.in. na Litwie, Łotwie, Estonii oraz w Serbii, Rumunii czy Słowenii. Równolegle prowadzimy w tej sprawie rozmowy z kilkoma innymi oddziałami Deloitte w Europie Zachodniej oraz na Bliskim Wschodzie.

Kiedyś mówiło się, że metodyki zwinne należy stosować w przypadku projektów, które cechuje duża niepewność wymagań i zmienność otoczenia technologicznego. W założeniu miały pozwalać na dostosowanie się do zmieniającego się otoczenia. Dziś jednak widać, że w metodykach zwinnych chodzi o coś więcej. To podejście jest wskazane dla firm, w których wierzy się w kreatywność i pracowitość ludzi, wysoko ceni się transparentność i zaufanie oraz buduje się struktury organizacyjne promujące przekazywanie zespołom wyzwań, a nie sposobów wykonania. W agile chodzi o to, aby nie krępować najlepszych ludzkich cech.

PRZECZYTAJ TAKŻE: Nieprzyjazna rekrutacja »

Firmy tracą klientów przez nieprzyjazną rekrutację 

Zatrudnianie Weronika Podhorecka PL, Joanna Malinowska-Parzydło PL

Profesjonalnie i przyjaźnie prowadzona rekrutacja przekłada się na działalność biznesową i wyniki sprzedażowe przedsiębiorstwa. 

Pobierz artykuł pdf niezabezpieczony

Pobierz artykuł pdf zabezpieczony