Kontekst cyklu artykułów
To jest druga część cyklu artykułów o projektowaniu praktyk i rozwiązywaniu problemów z tym powiązanych. Poprzednia część:
W części pierwszej pozostawiliśmy Was z pytaniem “Jak zaprojektować i zbudować rozwiązanie, które faktycznie dostarcza to, co miało być dostarczone”.
W tym artykule mamy zamiar na to odpowiedzieć.
Jak wprowadzać zmiany nie polegając wyłącznie na szczęściu?
Czy spotkaliście się z kiedyś z sytuacją, że wprowadzając z pozoru małą zmianę, obserwowaliście kaskadę niespodziewanych problemów? Czy znacie kogoś, kto twierdzi żeby nie poprawiać czegoś, co działa?
Czy wprowadzając zmianę nie jesteście pewni po co to robić i na co to wpłynie?
Szczęście jest bardzo ważnym elementem każdego sukcesu, ale nie należy polegać na nim w stu procentach. Wyobraźcie sobie budowniczego drapaczy chmur, który w trakcie budowy liczy na to, że nigdy nie zawieje żaden wiatr - bo budynek się zawali.
Trudno byłoby sobie wyobrazić taki brak odpowiedzialności, prawda?
Zmiany są czymś wpisanym w nasz zawód i powinniśmy się nauczyć witać je z otwartymi rękami i pokorą.
Problem klęski urodzaju
W 2014 roku stanęliśmy niespodziewanie przed problemem nowego typu. Nasze praktyki zrobiły się dość popularne, w związku z czym stanęliśmy przed tak zwaną „klęską urodzaju”.
Trzeba było ocenić 111 rozwiązań - kalkulatorów napisanych w języku C#, nadesłanych przez różnych kandydatów.
Z uwagi na ograniczenia czasowe związane z tym, że odrzuceni kandydaci musieli mieć możliwość aplikowania do innych firm na praktyki, całość rekrutacji musiała zamknąć się w 3 dni.
Tak się pechowo złożyło, że te 3 dni przypadły na święta wielkanocne.
W 2014 roku ten problem został rozwiązany przez wykorzystanie dużej ilości osób oceniających. Przez trzy dni, sześć technicznych osób oceniało te kalkulatory – około 200 godzin pracy.
Co gorsza, jakość kodu tych kalkulatorów w żadnym stopniu nie przekładała się na to, jak później ci studenci radzili sobie na praktykach, lub – co gorsza – w projektach.
Stop. Coś tu nie gra. Zatrzymajmy się tu na moment.
Co mieliśmy i czego szukaliśmy?
Omówienie sytuacji
Autor: Arleta Rynk
Zainwestowaliśmy sporo czasu w ocenę rozwiązań zadań rekrutacyjnych studentów przy jednoczesnym braku praktycznie żadnych korzyści biznesowych. Ten brak korzyści był podwójnie bolesny, bo wszystkim oceniającym bardzo zależało na tym, by zrobić to jak najlepiej. Mieliśmy wrażenie, że gdybyśmy się tak nie starali to też by się udało.
By zrozumieć naszą sytuację, zebraliśmy następujące dane:
- Praktycznie każda osoba która podesłała CV odesłała rozwiązanie,
- Część kalkulatorów to były po prostu kopie cudzych rozwiązań z internetu (np: z githuba),
- Część kalkulatorów to była ciężka praca ludzi, którym bardzo zależało, by się dostać,
- Jakość kodu kalkulatorów nie przekładała się na powodzenie studenta na praktykach. Co gorsza, nie przekładała się też na przyszłe powodzenie praktykanta w projekcie.
- Sukces studenta na praktykach – a potem w projekcie – był silnie skorelowany z umiejętnością pracy zespołowej, kreatywnością, znajdowaniem przyjemności w programowaniu, adaptacją kulturową oraz poziomem zaangażowania i radzenia sobie z frustracją i niepowodzeniami,
- Co roku coraz więcej ludzi aplikowało na praktyki i podejrzewaliśmy problem ze skalowaniem aktualnego rozwiązania (na stan 2018 roku – około 230 osób na 15 miejsc)
- Żaden praktykant nie napisał potem kalkulatora w C# w trakcie pracy :)
Pod jakim kątem rekrutowaliśmy?
Jakie korzyści przynosi forma rekrutacji przez “kalkulator”? Co tak naprawdę testowała nasza rekrutacja?
Ano, testowaliśmy umiejętność dostarczenia kalkulatora w odpowiednim czasie. Nawet nie “napisania kalkulatora” a jedynie “dostarczenia kalkulatora”.
Z uwagi na mnóstwo potencjalnych rozwiązań tego problemu w internecie, nie byliśmy w stanie nawet znaleźć wszystkich możliwych plagiatów.
Strategią wygrywającą (co odkryliśmy dopiero po pewnym czasie) było wykorzystanie dobrze napisanego kalkulatora z internetu, przerobienie go i dodanie czegoś od siebie - oszczędzało to czas kandydata, a jednocześnie zwiększało szansę, że sprawdzającemu ten kalkulator się spodoba.
No dobrze, ale to powyższe nie było tym, co chcieliśmy promować.
Co chcieliśmy naprawdę osiągnąć?
Wyłonić z liczby kandydatów tych, którzy potrafią programować w stopniu wystarczającym, byśmy mogli na praktykach zrobić z nich dobrej klasy programistów i jakościowców (dev i QA). Tą grupę chcieliśmy zaprosić na drugi etap rekrutacji, by sprawdzić ich umiejętności pracy w zespole, myślenia kreatywnego, autoprezentacji.
Innymi słowy, promowaliśmy zupełnie nie to, co chcieliśmy uzyskać.
Jak dostarczyć rozwiązanie? Najpierw trzeba się upewnić, że promujemy i mierzymy właściwe rzeczy.
Od problemu do planu
Oczywistym było, że rekrutacja zaprojektowana pod kątem wyboru 15 z 70 osób (edycja 2013) nie skalowała się dobrze na wybór 15 z 111 osób (edycja 2014). Ale, co gorsza, ta rekrutacja dodatkowo sprawdzała niewłaściwe rzeczy.
W tym momencie już wiedzieliśmy, że pierwszy etap procesu - który w 2013 roku spełniał nasze oczekiwania - przestał być użyteczny.
Cały proces rekrutacyjny wymagał poprawy.
W 2013 i 2014 tym, co było dla nas istotne to czas. Z uwagi na brak czasu na przygotowanie programu rekrutacji wykorzystaliśmy typowe zadanie rekrutacyjne jakie znaliśmy.
Gdy sobie to uświadomiliśmy, nasze zadanie stało się oczywiste - zmienić proces rekrutacji w taki sposób, by nadal spełniać oczekiwania wszystkich interesariuszy, w tym nowego zidentyfikowanego interesariusza, jakim byliśmy my - rekrutujący.
Zmiany - jak zmniejszyć wpływ szczęścia oraz ograniczyć koszta?
Czy da się całkowicie wykluczyć szczęście?
Zacznijmy od tego, że nie da się całkowicie usunąć szczęścia z rekrutacji. Ktoś może mieć gorszy dzień, kogoś może zżerać stres, ktoś może się zwyczajnie rozchorować.
To, co możemy jednak zrobić to skupić się na redukowaniu roli szczęścia. Mierzyć nie to, co jest łatwe, ale to, co jest dla nas istotne i wybierać ludzi pod kątem tego co istotne.
Nie uda nam się w ten sposób wykluczyć szczęścia, ale przynajmniej będzie miało ono mniejszy wpływ - bo skupiamy się na ocenie nie tego, co łatwe (kod kalkulatorów niezależnie od ich pochodzenia) a tego, co ważne (umiejętność rozwiązywania problemów przy użyciu programów).
Dlaczego rekrutacja 2013 zadziałała?
Podczas analizy procesu rekrutacji najbardziej zaskoczył nas fakt, że była tak ogromna różnica pomiędzy tym, pod jakim kątem rekrutowaliśmy a tym, co wskazywało na sukces praktyk.
A jednak większość z osób, które zakończyły praktyki 2013 radziła sobie potem dobrze w projektach – nie mieliśmy oczywistych błędów rekrutacyjnych.
To nie miało sensu. Czegoś wyraźnie nie rozumieliśmy.
Co się okazało - drugi etap rekrutacji 2013 to był warsztat kreatywny.
Z 40 osób wybieraliśmy 15 osób, obserwując, jak ci ludzie pracują w grupie. To powodowało, że osoby niedopasowane w sposób oczywisty tak czy inaczej nie były wybierane do finałowej piętnastki.
Nie do końca świadomie, ale w drugim etapie sprawdzaliśmy rzecz „właściwą”.
Oznaczało to jednak, że w pierwszym etapie odrzucaliśmy część osób, których nie powinniśmy odrzucać (i przepuszczaliśmy do drugiego etapu osoby, których nie powinniśmy przepuścić).
Zrobiliśmy sito “przypadkowe” - coś podobnego do anegdoty o podrzucaniu CV do góry i odrzucaniu tych osób, które nie miały szczęścia i ich CV spadło na podłogę. Szczęśliwie, drugi etap stanowił już sito “właściwe”. Niestety, przez sito przypadkowe zmniejszyliśmy populację osób pożądanych w drugim etapie rekrutacji.
Z tego wynikało, że naszym zadaniem było właściwe zbudowanie pierwszego etapu rekrutacji, by nie był sitem “przypadkowym” a stał się sitem “właściwym”.
Rozwiązawszy niezwykle trapiący nas problem “dlaczego to w ogóle działało?”, mogliśmy zacząć optymalizować rekrutację pod kątem istotnych dla wszystkich interesariuszy parametrów.
Jak dostarczyć rozwiązanie?
Trzeba spojrzeć na system całościowo (rekrutacja na praktyki), nie tylko na poszczególne etapy w izolacji (etap pierwszy i etap drugi). W innym wypadku ryzykujemy pogorszenie sytuacji lub ruchy nie przynoszące korzyści.
Sprzeczne cele interesariuszy
By zrozumieć jak bardzo problematyczny może być proces projektowania zmiany, wróćmy na chwilę do naszych interesariuszy. Przyjrzyjmy się dwóm interesariuszom oraz ich wymaganiom.
Z perspektywy rekrutujących:
- Jeśli ilość studentów będzie rosła co rok, nie możemy sprawdzać wszystkich nadesłanych rozwiązań. Najlepiej, jeśli studenci sami się powykluczają, jeżeli nie pasują do poszukiwanego przez nas profilu kandydata.
Co zrobiliśmy w tym zakresie?
- Zaprojektujmy pierwszy etap rekrutacji tak, by większość studentów niezgodnych z profilem idealnego kandydata sama zdecydowała o tym, by zrezygnować, nie przechodząc do drugiego etapu.
Przykładowo, wymagamy języka angielskiego – zatem niech studenci otrzymają dokumentację w języku angielskim i dodajmy do wymogów konieczność komunikacji z nami w języku angielskim. To powoduje, że część osób sama zdecyduje się nie kontynuować rekrutacji.
Wykorzystanie tego typu podejścia (kilku elementów tego typu) sprawiło, że:
- W roku 2018 na początku lejka rekrutacyjnego było około 230 osób
- Rozwiązania zadań pierwszego etapu odesłało nam tylko około 60 osób
Z perspektywy studenta:
- Jeśli student nie będzie wybrany, całość czasu spędzonego na rekrutację będzie zmarnowana. Ogólnie, student chce zmarnować jak najmniej czasu. Pisanie aplikacji rekrutacyjnej niemożliwej do wykorzystania w innym kontekście jest właśnie takim marnowaniem czasu.
Co zrobiliśmy w tym zakresie?
- Niech rekrutacja – zarówno pierwsza jak i druga faza – będzie jednocześnie szkoleniem.
- Niech pierwsza faza zawiera tutorial, dzięki któremu student może nauczyć się umiejętności potrzebnych do przejścia przez rekrutację.
- Niech na pierwszy etap student ma miesiąc czasu - dzięki temu jest w stanie się nauczyć rozwiązywać problemy nawet startując ze stosunkowo niskiego poziomu.
- Niech zadanie wymaga nie więcej niż kilka dni pracy idealnego kandydata (idealnie, dwa lub trzy wieczory). W ten sposób marnowanie czasu jest zredukowane do minimum.
- Niech druga faza będzie szkoleniem z budowania produktów, zgodnie z pełnym cyklem Kolba. Dzięki temu podejście do rekrutacji da korzyści nawet osobom odrzuconym.
Sam warsztat rekrutacyjny (z 40 kandydatów wybieramy 15 praktykantów) to dwie edycje czterogodzinnego szkolenia, podczas którego studenci pracują w pięcioosobowych grupach.
My prowadzimy warsztat, a specjaliści z Działu Rekrutacji obserwują ich zachowania, radzenie sobie ze stresem, pracę zespołową itp.
Po warsztacie spotykamy się z Działem Rekrutacji i wybieramy 15 najbardziej kompatybilnych osób z celami firmy.
Zaproponowane rozwiązanie jest naszym zdaniem rozwiązaniem “lepszym” niż to w 2013 roku i jesteśmy w stanie to udowodnić analizując cele powyższych interesariuszy.
Co więcej, jest to rozwiązanie szybsze:
- selekcja osób na warsztat trwa około 3-4 godzin naszej pracy.
- selekcja finałowej piętnastki trwa ~10 godzin pracy nas oraz 4 specjalistów z Rekrutacji.
- daje zdecydowanie lepsze efekty niż „kalkulator + warsztat kreatywny”, który był do 2014 roku.
Jak dostarczyć rozwiązanie? Projekt musi uwzględniać dostarczenie wartości wszystkim interesariuszom. Bardzo często interesy nie są sprzeczne i da się je pogodzić.
Podsumowując
Nie da się usunąć wpływu szczęścia, ale da się ten wpływ zmniejszyć
Szczęście jest czymś, czego nie da się całkowicie usunąć. Możemy jednak skupić się na tym, co jest najważniejsze, by maksymalizować sukces niezależnie od szczęścia.
Zauważcie, że nawet wiedząc, czego szukaliśmy - “dobrej klasy studentów” - nasze pierwsze podejście do rekrutacji było błędne.
Pierwszy etap rekrutacji był “kalkulatorem” a dostarczone rozwiązanie zupełnie nie było skorelowane z dalszym powodzeniem.
Zamiast ułatwiać sobie pracę, utrudniliśmy ją sobie. Mierzyliśmy to, co jest łatwe a nie to, na czym nam zależało.
Zmiana pojedynczego ogniwa łańcucha wymaga spojrzenia na całość łańcucha
Przez przypadek, drugi etap rekrutacji korygował nasze błędy z pierwszego etapu rekrutacji. Jeżeli mamy sprawny łańcuch czynności, to niektóre błędy na poszczególnych ogniwach mogą nie zostać zauważone przez działania kompensujące kolejnych ogniw tego łańcucha.
Jaki z tego wniosek?
Nie można rozpatrywać ogniw łańcucha w izolacji. Musimy spojrzeć na system całościowo oraz musimy spojrzeć na każdy element tego systemu z osobna.
Jeśli tego nie zrobimy, ryzykujemy wprowadzenie porażki w zupełnie innym miejscu systemu przez to, że usunęliśmy element kompensujący.
By rozwiązać problem, trzeba zrozumieć z jaką skalą się mierzymy.
Nasza rekrutacja na praktyki była pierwotnie zaprojektowana na około 50 osób i nie skalowała się do około 120 osób. Jednocześnie, nasza rekrutacja w roku 2018 jest zaprojektowana na około 100-400 osób.
Jeśli przekroczymy tą ilość osób na początku lejka, to będziemy musieli przeprojektować wszystko jeszcze raz (to samo dotyczy nie uzyskania 100 osób na początku lejka).
Wniosek: tak w systemach informatycznych, jak i w każdych innych, skala jest wartością, która może wymagać zupełnie innego podejścia.
Inaczej rekrutuje się 1, 10, 100 czy 1000 osób. Techniki działające dla 1 osoby niekoniecznie zadziałają dla 1000 osób - i vice versa.
Bardzo często sprzeczne cele interesariuszy da się jakoś pogodzić
Schodząc już do samego poziomu projektowania - wzięliśmy pozornie sprzeczne cele różnych interesariuszy i spróbowaliśmy je pogodzić.
Ani studenci ani rekrutujący nie mają tak naprawdę sprzecznych celów w wypadku tego problemu - jesteśmy w stanie rekrutacją dostarczyć wartość wszystkim zainteresowanym stronom. Wymaga to jednak tego, co robiliśmy w poprzednim artykule - identyfikacji interesariuszy i zrozumienia ich celów.
Co płynnie prowadzi nas do połączenia tych dwóch artykułów.
W poprzednim artykule skupiliśmy się na następujących krokach:
- Zidentyfikujcie interesariuszy projektu.
- Zrozumcie, jakie są ich wymagania wobec projektu oraz jakich korzyści oczekują od nas ci interesariusze.
- Zmieniajcie jeden parametr naraz, toczcie dialog z interesariuszami, aż uda się zbudować wizję tego, co należy dostarczyć.
- Zaprojektujcie i zbudujcie rozwiązanie, które faktycznie dostarcza to, co miało być dostarczone.
W tym artykule proponujemy następujące kroki jako podpunkty punktu czwartego:
- Upewnijcie się, że Wasze rozwiązanie odpowiada na konkretny problem. Upewnijcie się, że mierzycie to, co jest ważne, a nie to, co jest łatwe.
- Upewnijcie się, że macie ogląd na cały system, zanim zmienicie jakiekolwiek ogniwo złożonego łańcucha. W innym wypadku możecie usunąć mechanizmy kompensujące i wprowadzić porażkę do systemu, który wcześniej całkiem nieźle sobie radził.
- Nie zapomnijcie o tym, że rozwiązania działają w różnych skalach. Bądźcie świadomi, że zmniejszenie lub zwiększenie skali może wymagać przeprojektowania rozwiązania.
- Widząc pozornie sprzeczne cele różnych interesariuszy pomyślcie, czy da się tak zaprojektować rozwiązanie, by dostarczyć wszystkim jakąś wartość. Najczęściej jest to możliwe - różne strony mają różne cele i zwykle da się znaleźć obszar wspólnie korzystny.
To odpowiada na pytanie “jak zaprojektować i zbudować rozwiązanie, które dostarcza tego, co miało być dostarczone”. Nie odpowiada jednak na kolejny problem, jaki może Was teraz gnębić:
“Jak to wszystko zrobić, mając ograniczony czas i środki, a tak w ogóle to gdy wszyscy czegoś ode mnie chcą?!”
Odpowiedź na to pytanie znajdziecie w następnym artykule, w którym skoczymy do roku 2017.
