Z zatrudnieniem dobrego developera do firmy produktowej jest jak z zakupem roweru. Na rynku masz do dyspozycji setki różnych konfiguracji, ale finalnie sam musisz zdecydować, gdzie na tym rowerze będziesz jeździć i jaki model oraz rodzaj wybierzesz.
Na początku tego wpisu uciekłem się do analogii z rowerami (dzięki Michał Bieńko! 😉 ) w konkretnym celu. Otóż w żadnym wypadku nie wskażemy Ci uniwersalnego przepisu pt. “Jak zatrudnić dobrego developera do firmy produktowej”. Podobnie jak głupotą byłoby kupować rower według poradnika pt. “Najpopularniejsze rowery 2020”. Najpopularniejszym rowerem 2020 roku mógłby bowiem okazać się rower miejski, na którym można się zabić, jeśli Twoim celem jest jazda po górskich ścieżkach.
Co możemy więc zrobić, by Ci pomóc? Otóż możemy pochylić się nad określonymi kompetencjami i umiejętnościami specjalisty IT, które mogą okazać się kluczowe, jeśli chcemy zatrudnić go do pracy nad produktem (nie zawsze muszą one być typowe tylko dla firmy produktowej). W tym konkretnym przypadku, poza wymaganymi w każdej organizacji umiejętnościami technicznymi i wiedzą techniczną, należy jeszcze mocniej zwrócić uwagę na:
Dziś skupiamy się na tym drugim – “product mindset”, który kojarzy nam się nierozerwalnie z 4 pytaniami, które zadajemy i na które odpowiadamy poniżej na podstawie naszych doświadczeń. Dorzucamy również do każdego punktu przykładowe pytanie (wraz z komentarzem), jakie możesz zadać na rozmowie rekrutacyjnej, by sprawdzić “product mindset” kandydata.
Praca nad określonym produktem w danej organizacji, najczęściej wciąż tym samym, charakteryzuje się jego nieustannym usprawnianiem, aktualizowaniem i naprawianiem wszelkich występujących w nim błędów. Część firm co prawda oferuje wewnętrzną rotację pomiędzy zespołami, ale nie zmienia to faktu, że określony czas należy w danym teamie przepracować, zanim ruszymy gdzieś indziej. Można się więc “znudzić”.
Dlatego podczas rekrutacji zwróć uwagę, jak długo Twój kandydat pracował w poprzednich organizacjach i ich zespołach oraz co się wydarzyło podczas tego okresu. Bardzo ważne jest to, z jakimi wyzwaniami mierzył się developer i jak sobie z nimi poradził, a także z jakimi wyzwaniami chciałby zmierzyć się w przyszłości.
Przykładowe pytanie rekrutacyjne: Opowiedz o wybranym projekcie, w który byłeś zaangażowany przez dłużej niż rok czasu. Co stanowiło w nim dla Ciebie największe wyzwanie oraz co było najciekawsze?
Komentarz: podczas rozmowy zwracamy uwagę (lub w razie potrzeby: dopytujemy), za co dokładnie odpowiadał nasz kandydat w danym projekcie. Staramy się jak najlepiej zrozumieć, co go męczy, a co sprawia największą satysfakcję i radość w pracy. Jeżeli nie wyniknie to z rozmowy, możemy zapytać także, czy jest coś, czego obawiałby się w pracy nad tym samym produktem przez okres 2 lub 3 lat? Dzięki rozmowie wokół tego tematu możemy również sprawdzić, jak nasz developer reagował na poszczególne wyzwania. Jeżeli wystarczy na to czasu, na końcu rozmowy warto także zapytać: z jakimi wyzwaniami chciałbyś się mierzyć w nowej pracy?
Co prawda za bezpośredni kontakt z klientem odpowiada zazwyczaj Customer Success Manager, Product Manager/Product Owner lub/i UX Designer, ale odpowiednie wyczucie biznesowe powinien posiadać także developer. Z jednej strony musi on bowiem dysponować solidną wiedzą techniczną i dążyć do ciągłego rozwoju (swojego oraz produktu), ale z drugiej nie może zapominać, że kierunek, w jakim idzie produkt, jest uzależniony od wymagań rynku, użytkowników lub z góry nakreślonej strategii firmy bądź też ograniczony budżetem.
Dobrym przykładem (często, choć nie zawsze występującym) jest potrzeba wypuszczenia na rynek MVP (ang. Minimum Viable Product) lub prototypowanie nowej funkcjonalności w obrębie już istniejącego produktu. Wtedy developer w firmie produktowej powinien być skupiony na rozwiązywaniu konkretnych problemów w możliwie najszybszym tempie. Mniejszy nacisk kładzie się na dopracowywanie szczegółów do perfekcji (do tego etapu wraca się już po wypuszczeniu produktu i w momencie skalowania), z czego część developerów niechętnie rezygnuje.
Inny przykład to case, w którym dobrze widać uwzględnienie potrzeb rynku i użytkownika. Otóż wyobraźmy sobie, że na zaawansowanym już etapie projektowania dodatku do aplikacji, okazuje się, że w międzyczasie zniknęło zapotrzebowanie na taki feature. Dzieje się tak choćby ze względu na jakąś zmianę natury geopolitycznej (taką jak np. obecnie panująca pandemia). Wtedy rozwój produktu może przyjąć zupełnie inny kierunek. Przykładowo: aplikacja wspomagająca organizację czasu, zamiast usprawniać biurową formę pracy (dotychczas skupiano się na tym zagadnieniu), musi wypuścić feature koncentrujący się na home office. Nie każdy developer odbierze to pozytywnie. Możemy otrzymać odwrotny skutek i doprowadzić do frustracji developera w związku z teoretycznie zmarnowanym czasem pracy nad wcześniejszym, niewprowadzonym ostatecznie rozwiązaniem. Jakie więc podejście prezentuje Twój kandydat? Ma świadomość tych ograniczeń i mnogości zmiennych?
Przykładowe pytanie rekrutacyjne: Co brałbyś pod uwagę podczas rozpoczynania prac nad MVP lub prototypem nowej funkcjonalności?
Komentarz: przemyślane prowadzenie projektu w firmie produktowej odgrywa bardzo ważną rolę. Dlatego developer powinien pamiętać o rozpoczęciu prac od przeanalizowania potrzeb użytkownika, biznesu, możliwości technicznych czy dostępnych zasobów (to wszystko również przy wsparciu innych zespołów w organizacji). Wymaga to wysokopoziomowego podejścia. Podczas rozmowy staraj się więc uzyskać odpowiedź, jak developer postrzega rolę użytkownika końcowego w procesie tworzenia oprogramowania, czy uwzględnia formę szybkiego testowania, czy pamięta o zachowaniu zdrowych proporcji pomiędzy wdrożeniem określonych technologii a budżetem oraz czy jest otwarty na współpracę z innymi zespołami organizacji, z którymi często będzie miał styczność, biorąc pod uwagę tak wiele zmiennych.
W firmie produktowej developer jest bezpośrednio odpowiedzialny za coś, co daje namacalne, widoczne efekty w świecie. Do tego typu organizacji nada się więc człowiek, który ceni sobie fakt, że jest częścią czegoś większego i zarazem nie przerośnie go to. Rozwijając produkt, tworzymy bowiem coś, co przekłada się na życie konkretnych osób, ich przedsiębiorstwa, pracę czy codzienne funkcjonowanie.
W tym miejscu poszukujemy więc u kandydata cechy, którą możemy określić jako “desire to impact”. Czyli motywacji pt. “mam realny i widoczny wpływ na efekty prac”. Jeśli mielibyśmy podać przykład “obecnych czasów”, to tego typu “desire to impact” pojawia się choćby w przypadku prac nad aplikacją do zdalnej medycyny. Dzięki tak sformułowanej motywacji jest duża szansa, że developer będzie mocno brał pod uwagę to, z jakimi problemami zmaga się użytkownik produktu i czego obecnie potrzebuje. A co za tym idzie – dużo lepiej na te potrzeby odpowie nasza aplikacja.
Przykładowe pytanie rekrutacyjne: Z jakiego projektu jesteś najbardziej dumny i dlaczego?
Komentarz: w tym miejscu chcemy zwrócić uwagę na to, co motywuje naszego kandydata. Czy ważne jest dla niego to, jak realizowany przez niego projekt wpłynie na użytkowników oraz czy wprowadzi realną zmianę w świecie? Jeżeli jest to projekt, z którego naprawdę jest najbardziej dumny, to zapewne prowadziła do niego droga pełna sporej ilości wyzwań i – być może – fascynujących rozwiązań. Staraj się być dobrym słuchaczem oraz z drugiej strony – dopytywać o jak najwięcej szczegółów. W tym miejscu możesz również dowiedzieć się, jak kandydat reagował na ewentualne niepowodzenia i w jaki sposób stawiał im czoła, a także jak przebiegała jego współpraca z zespołem. To jeszcze mocniej uwypukli, co motywuje go do działania.
Eric Ries w swojej książce “Lean Startup” napisał, że startup to nic innego jak „ludzka instytucja stworzona z myślą o budowaniu nowych produktów lub usług w warunkach skrajnej niepewności”. Wymusza to na nas ciągłe poszukiwanie najlepszych rozwiązań. To z kolei sprawia, że narażeni jesteśmy na błędy. Mnóstwo błędów.
Developer w firmie produktowej (nie tylko w startupie) musi wyróżniać się proaktywnością i otwartością na “nowe”. Przy tym zaś nie może bać się popełniania błędów i musi potrafić wyciągać z nich wnioski, które przełożą się na rozwój produktu. Dodatkowo devowie, choć samodzielnie nie przeprowadzają badań rynku i analiz, mogą je opiniować. Powinni również zgłaszać swoje sugestie i – jeśli taką dostrzegają – potrzebę zmian. Z kolei na podstawie wiedzy technicznej mogą proponować konkretne działania analityczne, które pchną rozwój produktu do przodu.
Przykładowe pytanie rekrutacyjne: Jakie największe trudności napotkałeś w ostanio realizowanym/-ch projekcie/-tach?
Komentarz: niech powyższe pytanie rozpocznie dyskusję nt. tego, jak kandydat reagował na te trudności. Zwróć uwagę, czy developer brał czynny udział w ich pokonywaniu (proaktywność, wychodzenie przed szereg, proponowanie i opiniowanie rozwiązań) czy też był “biernym słuchaczem”.
Kwestia doboru odpowiednich wymagań wobec kandydata przy zatrudnieniu go do firmy produktowej nie jest łatwym zadaniem. Przede wszystkim dlatego, że nie istnieje żaden gotowy przepis na „idealnego developera” do tego typu organizacji.
Nie oznacza to jednak, że nie ma w tym temacie żadnych drogowskazów. Otóż są nimi cechy kandydata, które możemy sprawdzić lub zauważyć podczas rozmów rekrutacyjnych. Począwszy od dobrego podejścia do pracy wciąż nad tym samym produktem przez dłuższy okres czasu, przez odpowiednie wyczucie biznesowe i świadomość realnego wpływu swoich działań na świat, aż po proaktywność. Niewątpliwie są to kompetencje, które ułatwiają developerowi odnaleźć się w pracy nad produktem.
Powyższa publikacja ma za zadanie wesprzeć Twoje procesy rekrutacyjne, ale by tak się stało, musisz pamiętać o dwóch rzeczach. Po pierwsze: musisz potrafić słuchać i otworzyć się na to, co ma do powiedzenia Twój kandydat. I po drugie: budując proces rekrutacyjny, przejrzyj ten artykuł raz jeszcze i przy każdym z 4 wymienionych w nim punktów zadaj sobie pytanie „jak on odnosi się konkretnie do mojej organizacji?” Jeśli będziesz potrzebował wsparcia w tym zakresie lub masz dodatkowe pytania – pisz śmiało 🙂
Na końcu wielkie słowa podziękowania kieruję do Michała Bieńko, byłego IT Rekrutera Humeo, obecnie mieszkającego i pracującego w Berlinie. Wiele godzin rozmów online i konsultacji sprawiły, że mogliśmy finalnie podzielić się z Wami tą publikację w obecnej formie. Wierzę, że to nie ostatnia tego typu współpraca 🙂 Raz jeszcze: dzięki Michał!